When I first started planning a robot for the recent LVBots dead reckoning competition, it was more or less a conventional design—a flat chassis with motors and circuit boards attached to the top and bottom—and I lost interest in it quickly because it felt like I was just reinventing the 3pi. I looked for a way to make the shape of the robot unique, and I noticed that the three-legged shape of R2-D2, the famous astromech droid from Star Wars, might be a good fit for a typical undercarriage composed of a ball caster and two wheels. The result of continuing along this line of investigation is my dead reckoning robot, R2-DR (you can probably guess what DR stands for).
The base and internal structure of the robot are built from laser-cut acrylic pieces with thicknesses ranging from 1.5 mm (1/16″) to 6 mm (1/4″). As a first step, I planned the design of the entire chassis in SketchUp, using some plans from the R2-D2 Builder’s Club for reference (joining the Yahoo group is required to see the plans).
I used the width of two 32×7mm wheels, a pair of micro metal gearmotors, and their encoders to set the spacing between the droid’s rear feet, and that in turn determined the dimensions of the rest of the robot. R2-DR ended up just about 15 centimeters (6 inches) tall, almost exactly one-seventh scale, and roughly the same size as a can of soda.
From the rear, you can see that I deviated from the movie droid’s design a little by adding a platform between the rear legs to which the motor brackets are mounted.
This platform is an extension of the base of the body, and the rear legs play no role in supporting the weight of the robot; in fact, I designed the legs to be removable to give access to the wheels and motor brackets.
Removing the legs also allows the body shell to be lifted off the chassis. I built the existing makeshift shell out of card stock from a papercraft template, but I plan to replace it eventually with something more sturdy.
R2-DR’s main controller is a Teensy 3.1, which has a 32-bit ARM Cortex-M4 processor running at 96 MHz; this is the large board with the USB connector in the picture below.
To the left of the Teensy is a Pololu Pushbutton Power Switch wired to one of the pushbuttons in the rear. Behind the Teensy is a DRV8835 motor driver carrier for the drive motors, and to the right are two voltage regulators: a 5 V regulator supplying the Teensy and a 9 V regulator boosting the motor supply voltage.
From below, the motors and encoders can be seen clearly. I chose motors with a 100:1 gear ratio (higher than what many other people used) because I was concerned about the weight of all the acrylic parts, and because the droid is too unstable to go exceptionally fast anyway. The ball caster and QTR-3RC reflectance sensor array in the front foot can be seen here as well.
Sometimes, focusing on form over function led to problems: the droid’s tall, narrow shape and high mounting of the batteries make the robot top-heavy and intolerant of uneven surfaces. (You can see it tip over after reaching the edge of the board surface in the competition video). It was even worse with my original design for the front foot, which placed the ball caster behind the line sensors; I had to swap their positions before the robot could even drive at a reasonable speed without losing its balance.
The Teensy 3.1 was easy enough to use, being programmable from the familiar Arduino environment, and I had no trouble getting it to work with the encoders using the provided Encoder library. On the other hand, I didn’t have very long to work on the robot’s programming because building the mechanical structure and making wire connections under the perfboard took so much time. In the end, I copied a lot of Paul’s dead-reckoning code, and I didn’t have much time to tune it before the competition (which might explain why it tried to tackle a camera during its third run). However, I’ve since been able to get it to return to within about two feet of its starting point on the competition course with some more careful tuning. My source code is available on GitHub.
There are reasons I chose a fast microcontroller and left a lot of space unused on the perfboard. I still want to improve R2-DR by adding a rotating dome that turns to face the robot’s estimated starting point while it navigates the line course. I also plan to add a sound module so it can reproduce its movie counterpart’s beeps and whistles. Even in its current state, though, I’m very happy with how my own miniature astromech droid has turned out.