Rover: a robot you can make at home

I’ve got a new robot in the pipeline:

Read below for more details, and watch the latest video on it here:

It’s a mostly 3D printed four wheel drive off road robot called Rover. Why a rover? Well, after I built the robot arm joint, I needed a way to drive the motor.

I started working with motor controllers, built a test fixture, and eventually started playing with planetary gearboxes. Bonus slow motion video of the fixture here.

Once I started to look at mounting a motor in a planetary gearbox, it became clear that a) I could make a four wheel drive robot by just putting some wheels on such an assembly, and b) I’d prefer to use planetary gearboxes in my robot arm.

Thus, my new robot “Rover” was born.

It’s still very much a work in progress. The suspension design is currently “how can I get all four wheels stuck together?” and I really made no effort for the suspension to work properly. I’ll improve that in the coming weeks, but what I’ve got for now is enough for me to mount the electronics and start writing software.

The robot will use a Raspberry Pi with a real-time kernel patch running a motion control loop that sends out motor commands over a CAN bus. That way all four wheels will be closely controlled. It will use four VESC motor controllers which are designed in KiCAD and are totally open source. They support CAN bus natively and I’m using an open source CAN bus adapter called CANable from Protofusion for comms. While I could have used the onboard USB, CAN is really a superior protocol here due to lower latency and better high speed behavior. I’ve tested the adapter with the VESC and it works well. Note that linux users will want to upgrade the firmware on the CANable to show up as a native CAN device - it ships with a serial based firmware to satisfy Windows users.

My current next steps are to mount the last two motors (more of my 3D printed stainless steel shaft adapters just arrived from Shapeways) and bring up the drive system electronics and software.

After basic remote control is functional, I’m going to use a Movidius/Intel Neural Compute Stick to run NVIDIA’s TrailNet for trail following. That just requires a monocular camera and I’m hoping will be relatively easy to bring up. Beyond that I’m interested in using an NVIDIA TX2 and a stereo camera for some more advanced work. I have no plans to run ROS on the robot but I may go that route depending on how I end up using it. If it’s just doing trail following ROS isn’t necessary.

Ultimately I’ll be happy if I can make the robot follow me on hiking trails, but it will be fun to see what else I can do with the platform.

I’ve got a gallery of more pictures here:

And you can fork and edit the design yourself for free using OnShape in the browser.

The design is open source and licensed CC0.

You may also notice that Rover is beginning to seem a little like R34. I’m building robots you can build in a small shop so that we can have a new kind of socialism. Read more about this in The Machine.

This weekend I worked on the motor control system.

A part of this project is to see if I can make a suitable control system that runs in Python on the raspberry pi. Certainly C or C++ would work, but the fun is the challenge of writing high performance code in Python. And in not having to use C++.

On my laptop the code works well. I shot a few videos covering the progress.

First I show the basic proportional speed control system running over CAN bus here:

I then took the proportional speed control loop and tied it to my acceleration profiler. This means I can issue target speeds with defined acceleration values and the speed command will ramp as per the desired acceleration. The speed control system is still proportional control only so it oscillates rapidly around the speed setpoint.

Finally I added a derivative term to the control loop. This successfully damped the oscillation and dramatically improved things. Here I ramp to different velocities with different acceleration limits specified.

You’ll still see some artifacting in the control. My current guess is that those artifacts come from my control loop occasionally being interrupted by the OS. If the derivative measurement is delayed, it would see a higher than normal difference and apply extra control current to the motor, causing the glitches. I can verify this by measuring jitter on the CAN bus.

For now however I’m setting up a raspberry pi with a real-time kernel (RT_PREEMPT) so I can guarantee a 1kHz loop. Learning how to properly patch and build kernels is fun!

I now have a raspberry pi with the PREEMPT_RT patch running multiple motors. I need to update my code to support negative velocities :joy: but it’s very close to being able to drive around.

See some test video from last night here:

Rover took its first steps today!

See another slower speed test here:

The code now supports negative velocities and has a few other stability improvements.

Check out the rover software on GitHub here:

In other news I brought up bluetooth LE on the raspberry pi using a freshly compiled BlueZ stack with experimental mode enabled (that is to say, it’s a minor pain to set up). This means I can send control commands from a python program on my phone using the Pythonista app.

Lastly I made a power wire harness for Rover to plug 4 VESC motor controllers in to one battery, and I got two more VESCs in the mail and soldered on the extra capacitor they need for proper motion control.

Next steps are to build a proper remote control interface, find something better than tape to hold the electronics on to the robot, and do some initial off road testing.

Rover is coming along!


I got rover driving finally! I’ve uploaded two new videos.

In “Rover’s first day out”, we follow Rover as it explores the parking lot and tries to overcome a few obstacles.

In “Rover visits a farm”, we follow Rover as it seeks out the sunset and plays in the wood chips at the UCSC research farm.

Happy 2018 everyone!