Spent a fantastic weekend in Boulder for the 2nd annual Sparkfun Autonomous Vehicle Competition 2010. We went to the 2009 AVC and had a blast, but this year we entered a vehicle and saw a whole new dimension of the event through a competitor’s perspective. We were “Team Buzzcut” and my wife named our vehicle “Roscoe”.

“Roscoe” - the ESawdust Team Buzzcut autonomous vehicle

We came in 6th for ground vehicles out of 13 ground vehicle teams which actually started the race. Numerous teams dropped out at the last minute as they were debugging right up to the first heat - there were 30 entrants including ground vehicles and UAVs.

Think of the Sparkfun AVC as the DARPA Grand Challenge on a mini (affordable) scale. Sparkfun AVC has two categories, ground vehicles and UAVs.  I have to say the UAVs stole the show this year with some picture perfect autonomous landings and one even performed a vertical autonomous takeoff with some autonomous aerobatics.   It's really quite a spectacle for the geek-minded.

There were vehicles built on all kinds of physical platforms including a beer cooler, an electric wheelchair, kiddy cars, and some truly dangerous looking stuff that had no name and probably should have been in battle-bots instead.   There was one team who entered but for some reason couldn't come, but they had built their autonomous vehicle based on a riding lawn mower. That would have been a hoot to see - too bad they couldn’t come.

Teams came from all over, including Great Britain.  The best UAV team was from the University of Arizona engineering school...they were simply awesome but all the UAV teams were really fantastic.

My son, Nakoa, helped me out with Roscoe and this is a shot of Nakoa taken by my friend, Oleg Mazurov (circuitsathome.com), on race day. Nakoa’s setting the vehicle down on the starting line for heat #2:

Here’s another shot taken by Oleg of the vehicle, Roscoe, just after launch:

We were on the standby list of competitors until after the first of April as some teams couldn’t produce the requisite video showing their vehicle in autonomous motion or dropped out for other reasons. So, fortunately, we got moved up and into the competition but rather a late start for serious development - especially for the navigation code.

I’ve been writing this series on autonomous cars and even a week before the competition thought we’d be going with an 1/18 scale R/C car but changed horses mid-stream and it’s been a frenetic pace to try to get everything running for the competition - not much blogging about it, just heads down trying to get it done.

The horse we changed to was a 1/10th scale Losi Rock Crawler (model “Night Crawler”). The reasons were several-fold. 1) the 1/18th scale only had about a 1/4” of clearance once I had everything installed on it. 2) even the slowest speed I could make the car go was too fast for getting things debugged. We were so close to the event I didn’t have time to mod the car, so I looked for a naturally low-geared vehicle and thought about the crawler. It was the fast way to a robust mechanical platform for the race and had the added benefit of handling some curbs.

I had to move the autonomous electronics platform from the Team Associated car to the Rock Crawler. Found out first thing that the Losi signals for forward and backward were reverse from the Team Associated. It was an easy fix in my firmware, and after that it wasn’t long before I had the new vehicle moving.

Ours was about the only vehicle that didn't have wires and poles poking out of it like a porcupine - turned out to be a good thing because the 3rd heat was ran in the rain so we had a good lid. All the firmware was written in C.  Was up late every night last week trying to cram it all together...felt like a senior design project in engineering school.

Here's a shot of me in the team pit area inside Sparkfun:

The vehicle communicates diagnostic data and also takes the start and kill commands from the MacBook via an XBee Pro 900. I wasn’t sure if I was going to see interference from other XBee users and had the system live for about 45 minutes before the start of the race when I saw my first evidence of someone on my channel. I quickly reprogrammed the XBee radios for a different channel and did not see any further interference.

Here’s a shot of the general pit area inside Sparkfun before it got completely filled up:

Our second heat on the 2nd leg, Roscoe headed for a curb, climbed the curb with its front right, then back right wheel and drove half the length of the building with two wheels on the asphalt and two wheels on the curb.   The second milestone was at the end of the drive along this curb, so I thought maybe he'd gotten lucky and would ride the rail all the way to the 2nd checkpoint. Here’s a video of Roscoe riding the curb until he dumped on his lid:



The electronics sat on top of the aluminum cage that houses the motor and transmission.  Not sure if you can see it in this picture, but I put a piece of black non-conductive foam layered between the board and the battery.  Then, on each corner of the board I attached a spring to the cage.  So, the board could move around, but was pretty secure.  

(I only noticed later after taking this picture the “Fresh Step” in the background. Thought it actually fit this picture pretty well :-)
The picture below you can make out the springs that fastened the electronics to the metal cage.

Because the board added extra height to the chassis, we punched new holes in the body to lift the body above and protect the electronics.  So, when the vehicle rolls, the electronics aren't touched.  You can see the cotter pins in the body in the new holes with the old holes about an inch above them.


I think he looked pretty handsome on race day - one of the few bots that didn’t look like Jetson’s Rosie: - We were not bristling with sensors (to a fault - we only had GPS.)

I spent at least two nights working on two different Sparkfun digital compass modules, but unless I mounted them very high, the motors perturbed them so much I couldn’t use them. I had all my navigation code written to use headings and GPS waypoints. The digital compass wasn’t accurate when it was attached so closely to the vehicle, the crawler goes slow enough that GPS heading isn’t accurate, and I simply ran out of time, so I ended up ripping all my heading based compass code out and going with a very simple steering algorithm.

Each leg of the journey had a different rule set for steering. It more or less worked but it was 1am of the morning of the competition and I ran out of gas trying to refine it further. I was in my brother’s garage near Sparkfun the night before doing mission after mission refining an algorithm based on relatively inaccurate GPS data.

I’ll go into the steering algorithm in a different blog post as well as present code for communicating with at least two of the Sparkfun digital compass modules.

It was a blast - stressful fun, actually - to come up with something that wouldn’t flop in front of a couple hundred spectators.

We’ll definitely be back next year - wiser, smarter, and possibly more Rosie-looking.

Team Buzzcut Rosoe the Rock Crawler on Heat #1:

Heat #2

Heat #3


Landon Cox
www.ESawdust.com

Other articles in this series:
Building Bots with Kids
Autonomous R/C Car - Part 1 - Reverse Engineering Signals
Autonomous R/C Car - Part 2 - Taking Control
Autonomous R/C Car - Part 3 - GPS
Autonomous Vehicle - Part 4 - Mechanical, Firmware

Tags: Sparkfun, AVC, Buzzcut, Autonomous, Vehicle, Rock crawler, Losi, Night Crawler, Steering

Synopsis: This is the first part of a series of articles written to share the experience of my son and me hacking an R/C car into an autonomous vehicle. This article will focus general observations around picking an appropriate R/C vehicle and identifying the signals and characteristics of those signals needed to control the car.

Picking a Vehicle

The original impetus for this was the Sparkfun Autonomous Vehicle competition whose course is a parking lot loop around the Sparkfun building in Boulder. So, the vehicle didn’t need to be off-road or aqueous unless it really went off track like some did last year.

What Not to Use

When we first started thinking about an autonomous R/C vehicle, we thought we’d hack one of the 4x4 R/C trucks that we had sitting in the garage which we bought from RadioShack 10 years ago. What the heck? We haven’t run it for a long time and it was pretty beefy - if it got hacked beyond recognition, who cares?

One of our first observations after tearing it down is that RadioShack R/C vehicles are not good candidates for an autonomous vehicle. A couple reasons stood out:

• They’re built too safe: RadioShack is bound and determined to be safe and therefore anything that could shock or burn is well protected. They’re so well protected, components like the motor and controller are effectively inaccessible without major disassembly. We would have had to remove the end and complete gearbox to get to the motor. That’s silly - not conducive to hacking.
• After “liberating” the electronics, our R/C truck had a relay instead of an electronic speed controller. This makes the speed control finicky and jerky - and electrically noisy. It was also all on the same PCB as the radio, so we would have had to hack the board or substitute our own speed controller. Either way, it wasn’t the best choice and we had others.

What We’ll Use for an R/C Platform

Our second choice turned out to be much better. We own two, RC18R, 1/18th scale 4WD rally cars from Team Associated which look like this:


These little buggers are screamingly fast. They are so fast they could not be run top-speed at a competition without some serious unintended carnage. Nice features of these vehicles are:

• Relatively inexpensive, though still a lot more money than a RadioShack toy - they’re “serious” R/C vehicles (as much as “serious” and “R/C” can be used in the same sentence.)
• Electronic speed control
• All the components are easily accessible and parts readily available via Team Associated (not that we would ever crash one, no.) There is an active aftermarket for components which was definitely not the case with RadioShack toys.
• Very responsive and super maneuverable all wheel drive drivetrains
• They can be hacked without ruining the vehicle for its designed purpose as everything is modular and pluggable.
• The vehicle has both forward and reverse which would be required to potentially get out of a pickle

The final thing about this product is there are off-road versions of it as well, the RC18T series, so the same basic control and electronics we come up for the autonomous component could easily fit onto other types of vehicles if we wanted an offroad autonomous Grand Challenge.



While 1/18th scale vehicles are very small, they’re still large enough to fit microcontrollers, GPS, and sensors without overloading the platform and making them too top-heavy.

General Electronics of the RC18R

Our basic approach to taking control of the vehicle will be to bypass the stock radio control which is a 27MHz typical R/C transceiver system. Yet, we wanted to use as much of the existing car and electronics as possible to keep costs low.

That immediately implies that the signals which are sent to the motor controller and steering servo by the existing radio receiver are the signals our autonomous controller needs to emulate in order to make the car work under autonomous control.

So the first order of business is to figure out how to make the car move and how to control its steering by reverse engineering how it works as designed.

The receiver in the RC18R has two 3-wire plugs coming into it. One is connected to the motor controller which is, in turn, connected to the NiMH battery pack. The second is connected to the steering servo. There is no separate power to the receiver like some R/C cars which use a 9V battery to power the receiver and another large battery to power the motor.



In the photo above, the receiver is the blue and silver component on the spine of the chassis. The motor controller is just above the receiver and has the toggle switch for powering on the vehicle. The motor is above and to the right. The battery pack is the blue and yellow rectangle running the length of the chassis. The main pinion gear of the motor is on the right side gear box and there’s a central drive shaft that runs down the middle of the chassis to drive the front gear box making it AWD.

The 3-wire plug going from the motor controller to the receiver carries 5V (red), GND (black), and signal (white) where the signal is one-way from the receiver to the motor controller. The other 3-wire plug is a standard 3-wire servo connection.

I knew that servos were controlled using pulse width modulation (PWM), but I wasn’t sure how the speed control worked. In either case, we wanted to look at the signals for steering and speed control even though the servo was likely standard.

Steering Servo Signal

We started with the servo signal because I knew to expect a PWM type signal. I made a 3-pin servo connector with a 3-wire pigtail that had bare ends. Unplugging the steering servo and plugging in the 3-wire pigtail, we had a simple “tap” we could use to put a scope on and view the signals.




The first thing was to bracket the servo signal and figure out its basic period and duty cycle (the % on vs % off time in one period.) You could look this up and be pretty sure this vehicle was identical, but part of this exercise is to go through the process of actually doing the work and seeing how it works. Here’s a o-scope waveform of the steering servo signal:



A couple things to note. 1) I was using a nearly depleted battery in the car when I took the image above, so the signal amplitude is not full - it’s about 3V to 3.3V typically as you’ll see below. 2) The full period of the wave is slightly less than 20ms...something about 18ms. If you google PWM and servos you’ll quickly learn that most run at 20ms periods.

Next we needed to figure out the duty cycle of the wave so we zoomed in on one cycle above and then manipulated the steering control on the transmitter to see what neutral and full right and full left looked like.

With the transmitter wheel in a neutral position, hands-off, this is the signal we saw:



Not quite 1600 microseconds (1.6ms) of the 20ms wave asserted high.

When the wheel was full left we saw:



A little over 1ms on full left.

and when the wheel was full right we saw:



A little over 2ms when full right.

So, we measured and verified what is common knowledge amongst anyone who’s worked with servos before: the typical period is about 20ms and the neutral position is half way between 1 and 2 ms (1/20th and 1/10th duty cycles) or about 1.5ms for straight ahead steering. Finally, the servo signal level is just over 3V...call it 3.3V.

Speed Control Signal

The next order of business was to examine the speed control signal. We could not use the simple 3-wire pigtail for this signal because the power for the receiver and servo came in via the 3-wire strand with the signal I needed to measure. There was no choice but to cut the signal wire to tap it, leave the plug in place and then splice it back together later to keep the car intact so it could be used as a normal R/C car, too.



After stripping the end coming from the receiver, we fired up the vehicle and measured the motor control signal. I don’t know why I was surprised by this, but the motor control signal had exactly the same characteristics as the steering servo just applied to speed. Instead of left, right and straight, it was forward, reverse and neutral.

Here’s neutral speed control wave form:



Here’s neutral, 0 speed from a duty cycle perspective:



Approximately 1500us asserted high.

Here’s full throttle forward:



A little over 1800us asserted high.

Here’s full throttle reverse:



A little over 1200us asserted high.

So, the summary of the throttle signal is this: a period of about 18ms similar to the steering servo, a neutral duty cycle at around 1.5ms, full throttle about 1.8ms and full reverse 1.2ms. So, the band on either side of neutral is about 300us.

The throttle signal was just slightly different from steering in terms of duty cycle - it didn’t go through the 1 to 2ms range of steering, but it followed a similar pattern.

In the case of both the steering servo signal and throttle signal, as we turned the wheel or squeezed the throttle trigger on the transmitter we could see the wave form smoothly transition from longer or shorter duty cycles. That’s what we’ll need to emulate to make slight steering or throttle adjustments with our autonomous controller...it’s not all or nothing as these waves seem to imply - it’s a graduated duty cycle from end to end.

Our test setup was our kitchen table and it looked like this:



Since I wanted Nakoa to be able to repair our intentional damage to the wiring for testing purposes, he needed to practice some soldering. He’d done some in prior years, but hadn’t done any for a time, so I gave him a perf board, a bunch of wire, some wire strippers, my good soldering iron and solder and he went to town on solder practice. It almost looked like a work of art when he got done:






We call him “Harry”. I’m not sure why people buy soldering practice kits - this is a lot cheaper and just as fun for the kid.

So, he’s all tuned up to do the splice to put the single wire back together from the motor controller.

I think if Nakoa had his pick of autonomous vehicles, it would be this nitro buggy we saw at an R/C Hobbies store in Boulder. Maybe when he gets older...and a good job.

Summary

This article has shown how to reverse engineer the internal motor control and steering signals needed to control an R/C car. While a specific R/C car was shown in the example, nearly any modern R/C car will work in a similar way. The next installment in this series will demonstrate how to emulate these signal wave forms using Pulse Width Modulation (PWM) features available on an ATMega AVR microcontroller.

Landon Cox
www.ESawdust.com

Other articles in this series:
Building Bots with Kids
Autonomous R/C Car - Part 1 - Reverse Engineering Signals
Autonomous R/C Car - Part 2 - Taking Control
Autonomous R/C Car - Part 3 - GPS
Autonomous Vehicle - Part 4 - Mechanical, Firmware
Autonomous Vehicle - Part 5 - Race Day

Tags: Autonomous, PWM, Pulse Width Modulation, Soldering, Sparkfun