Eddie – terrestrial rover

During my time as a member of Washington State University’s Robotics Club, Eddie was my primary focus. Named after the enthusiastic shipboard computer in the Hitchhiker’s Guide to the Galaxy, Eddie is an autonomous outdoor robot built primarily to compete in the Seattle Robotics Society’s Robo-Magellan competition.

The Competition

In Robo-Magellan, the robot is tasked with navigating a diverse outdoor environment. The robot starts at a specified location, and must autonomously find its way to a particular destination. Robots are scored on how quickly they are able to reach this destination. Additional intermediate waypoints can also be present. If reached by the robot, they improve the robot’s final score (the amount by which the robot’s score is improved depends on just how difficult the waypoint is to reach). All of the waypoints in the competition are indicated by orange traffic cones, making them relatively easy to positively identify through visual means.

Design

The design and implementation of Eddie was spearheaded by three major contributors: Nick Juliano was responsible for all of Eddie’s mechanical systems, Brent Allen took charge of the higher level software, and I handled much of Eddie’s electrical systems and low-level software.

In designing Eddie, we wanted to have a robotics platform that could both easily handle the present Robo-Magellan competition, and easily adapt to handle any other competitions in the future.

Mechanical

We spent quite a while investigating the best mechanical platform for the task. Everything from humdrum tank-tread designs on up to the remarkable Shrimp platform. There were two critical features that we were looking for: the ability to climb over curbs and other obstacles, and the ability to turn in place. Size and weight were also of concern, as the Robo-Magellan rules imposed a 50lb weight limit and mandated that the robot had to fit within a 4x4x4ft cube. Aircraft were also disallowed (much to the dismay of those vying for a dirigible based solution).

Ultimately, we settled on a Rocker-Bogie style platform (you may remember it from such wildly successful Mars rovers as Sojourner: the little rover that could and Spirit: stationary science platform). Such a design can scale obstacles upwards of twice the diameter of a single wheel, and can effortlessly rotate in place (by pivoting its outer wheels to form a circle). That, and it’s hard to argue with designs that have been exhaustively tested on not one – but two entirely different planets!

Electrical

Motor Controller

While a basic tank-tread platform would have only required a simple dual-channel motor controller, the rocker-bogie design mandated something rather more robust. With one drive motor per wheel (six total), and one steering motor for each outer wheel (four total), we needed a motor controller that could independently drive at least 10 motors!

Rather than spend a whole bunch of money on an off-the-shelf solution, I wound up developing a custom motor controller board that exactly met our needs. Given the quantity of motors that had to be driven, and the relative low-power of each motor, I opted to use fully integrated H-Bridge chips instead of discrete bridges (with many individual MOSFETs). National Semiconductor LMD18200 devices were selected due to their wide operating voltage (12V-55V), adequate current rating (3A), robust built-in protection (short-circuit and over-temperature), low external component count, easily heat-sunk package – and, crucially, National’s generous free-sample program.

The power ICs were, however, only half the battle. There was also the question of what microcontroller to use to control all of these motors. The vast majority of microcontrollers have ample PWM outputs for controlling motor speed, so that was not a major consideration. Feedback from the motors was, however, of greater concern. We wanted to keep precise track of how far each wheel had turned in order to navigate via dead reckoning, so we made sure Eddie’s six main drive motors had attached quadrature encoders. The particular surplus motors we used had unusually high resolution encoders, which meant that we needed a microcontroller that could handle relatively high-frequency quadrature data. This tended to suggest a controller with hardware quadrature decoding, which, sadly, disqualified use of Atmel’s AVR controllers (my personal preference).

Instead, I opted to use Microchip’s recently-introduced dsPIC line of 16-bit microcontrollers – a decision that I would later come to regret. For this application, the dsPIC’s most notable feature was a dedicated Quadrature Encoder Interface unit, which provided a 16-bit hardware counter that was controlled by an attached quadrature encoder. Since each dsPIC only provided a single QEI, it was thought necessary to use one dsPIC per each of the six main drive motors (even though the actual compute requirements of controlling all six motors were well within a single dsPIC’s capability).

The steering motors did not rely on quadrature encoders for feedback. Typical two-channel encoders provide no absolute reference; they can only measure changes in position. This is fine for drive motors, but a big problem for steering motors (which are expected to hold a particular absolute angle). We attached potentiometers to each of the four outer steering wheels to provide an analog voltage proportional to the heading of each wheel. The dsPIC, like most microcontrollers, has plenty of ADC inputs, so it was practical to drive multiple steering motors with each dsPIC.

In the past, I had built controller boards using perf-boards (for example, for my latest Tesla Coil, Elysium), DIY etched boards (as with Inchoate), and CNC-milled boards (for Nimiety). This time, I wanted to try my hand at having a commercially manufactured PCB made. I used EAGLE to do the PCB layout (but neglected to first draw up a schematic – a poor practice that I have since discontinued). The board was fabbed using Advanced Circuit‘s “33 Each” offer, the results of which were quite good. After this experience, I now prefer to have all of my PCBs commercially made (services I can recommend for small one-off boards are Sparkfun‘s Batch PCB service, and a similar group PCB order run by a member of Portland’s Dorkbot group).