AVC Bot: Frustration

Sometimes things just go to crap.

Here's a position plot from a recent test run up and down my street. I'm pretty sure the robot didn't travel through houses to a cul-de-sac two blocks east.

Since I need precision that's considerably tighter than a city block... if you can tell me how to use this garbage to reliably navigate to 10' precision I'll kiss you. (Not really, that would be weird).

GPS: I'm screwed.

The GPS is supposed to be really sensitive and high performance (hmph). Horizontal Dilution of Precision is a pseudo measurement of GPS fix quality and 1.0 is excellent, with larger numbers indicating decreasing accuracy. Here's my plot:

GPS: Yup, I'm screwed.

So, basically my GPS fix bites.

The irony here is that my cheapie, piece of crap Garmin eTrex Legend taped to the RC chassis with electrical tape was reliably performing far, far better than this high-zoot, fancy-pants GPS. What's up with that?!

On to other sensors. Here's my plot of Gyro, Compass, and GPS headings, fraught with problems.

Heading data: Yup, screwed

The GPS fix data is lagging reality by about 1 second. Meanwhile, compass readings are haywire as soon as the initial turn starts.

Of course those are minor issues next to the fact that error between the three sensors are on the order of 100 degrees. I need 1 degree precision. Only 2 orders of magnitude. I'm in great shape, aren't I?!

Ok, I did stack the compass module on the GPS module with double stick tape for convenience so that probably hurt the performance of both units.

I decided to move them... and the shield ripped off the GPS! (*&!@#!

I had to resolder the shield. I hope it works or I'm out a $60 GPS module. For that matter, I hope it works better than before. EDIT: nope, it's trashed. Doesn't even power up properly. *sigh*

I guess I can still try the 1Hz, 4800 bps, iGPS 500 and hope it can get a better fix.

On top of the problems with sensor data being wildly inaccurate I can't even troubleshoot properly because I can't get the bot to reliably log data to the microSD card. I end up missing huge chunks of time.

I spent 5 minutes driving the truck around and I looked at the logs and find 60 seconds of data.

Uh... ok. Thanks.

Piece of crap.

Oh, and last week, I bashed the RC truck into a parked van (good thing the Robot will do all the driving), broke the front body post mount and dented the crap out of my FPV camera.

And I still don't have the Kalman filter going. Mostly because I don't have useful data to work with.

Time for serious measures. Time to bring in the magic rubber chicken!

So in summary, things are just freakin' peachy.

Are we having fun yet?  Ok, driving it is fun...

AVC Bot: Picking a GPS Module

Selecting a GPS Module

GPS is the heart of any robomagellan-esque robot; my AVC bot is no different. I wanted a high performance GPS that could deal with the challenges around the Sparkfun building including an urban canyon on the west side, trees, and very little tolerance for error all around the course.

Sparfkun did a comparison between various GPS modules they sell. The long and short of it is that of all the modules tested, the Locosys LS20031, based on a MediaTek chipset, seems to have dealt best with the challenges around the building.

Another factor of importance was update rate. Most GPS modules update at 1Hz but a few provide fixes more frequently. The LS20031 is one of those, providing fixes at 5 Hz out of the box.  Adjustable baud rate is helpful, too, so that the data sent by the GPS is sent quickly, reducing lag between fix time and processing, and ensuring sufficient time between updates for processing.

Locosys LS20031

Locosys LS20031

Thanks to Sparkfun's Free Day I ordered a Locosys LS20031. Unfortunately the first one was never able to get a proper fix on satellites.

The replacement (thanks SFE) didn't work at first either. It couldn't pick up a single satellite. Now I was really frustrated and wondering if it was time to bring in the good luck rubber chicken to ward away the evil gremlins. More on this momentarily.

iGPS-500

Pharos iGPS 500,
geocaching.com

I ran across a source for an $18 Sirf Star III GPS, the Microsoft Pharos iGPS-500, from an online surplus seller. The upside is the sensitive chipset (although the EM406, also a Sirf III, didn't perform quite as well as the Locosys in SFE's testing).

The downside is the fixed 1Hz update rate and 4800bps data rate. EDIT: After the 2011 AVC I contacted Pharos support and obtained the pinout. I can now adjust baud rate and choose which NMEA sentences are transmitted. Cool.

Upon arrival, I got a solid fix using the device as originally intended, hanging off a USB to serial adapter.  After converting to pin headers, performance degraded considerably and I was worried that somehow I was jinxing GPS modules.

But performance improved when I constructed an extension cable and moved the module away from the breadboard. It still wasn't great.

Finally I decided to power it with the same 5V as the USB adapter, instead of 3.3V.  That did the trick.  The fix was as good as ever.

Back to the LS20031

I decided to try the same approach with the Locosys. The module either really doesn't like to sit next to a breadboard, or next to the mbed, or maybe both. With long wires attaching it to the breadboard, it quickly got a solid fix outdoors and works beautifully.  Now I'm in business!

Postponing Maiden Voyage

Unfortunately, I have to postpone the maiden voyage of the AVC robot due to a family situation that requires me to be out of town for most of the week.

I've made a lot of progress in the last week but still have a lot of software to write to get the robot driving and navigating autonomously.

For giggles, here's a video I did with my "gumstick" camera, driving the truck around in remote control mode in a fruitless attempt to collect some usable gyro and gps data...

AVC Bot: Gyro Noise and Accuracy

Last we left off, the first data captures from the LISY300AL rate gyro on my RC truck robot were really noisy!

See? I can't use that to navigate around the Sparkfun building for the Autonomous Vehicle Competition.

Accuracy
I need accurate heading data.  According to basic trigonometry, if E is the cross-track error in feet and L is the length of one side of the Sparkfun building, then heading precision, theta, is given by:

Each long side of the AVC course is about 73m and the short sides are about 56m, for a total of about 260m. A maximum error of 5m over that distance requires heading accuracy of about 1°. So an accurate, low noise gyro is going to be critical to success.

Finding the Noise Source
Here's a plot (generated by gnuplot this time) showing detail between 10 and 20 seconds (click to see the full sized image)

That's really bad.

So what was the cause? Mechnical vibration or EM noise?

A quick experiment indicated that mechanical vibration definitely played a role. I put the RC truck in the passenger's seat of my Grand Wagoneer, drove around the block, and obtained a much smoother gyro plot, below.

One more experiment was needed to isolate the effects, if any, of EM noise from the motor. I set the truck up on a box and ran the motor and steering servo.

But I wasn't able to isolate the EM effects after all because the truck chassis vibrated all over the place.

I ran the motor twice, then turned the steering back and forth lock to lock. Then slowly turned the servo back and forth.

Vibrating, unbalanced rear wheels and vibrations from the steering wheels whisking back and forth clearly set off the gyro.

A Better Gyro
I could have experimented with the rear wheels off, but I was pretty sure vibration was the major contributor of the noise. I was also pretty sure that the LISY300AL is overly sensitive to vibration.

ADXRS610 Gyro

So I bought an Analog Devices ADXRS610 rate gyro breakout board from Sparkfun (discontinued shortly after my purchase). The datasheet claims high vibration rejection. Just what I needed.

I wired it up, mounted it between two foam pads for further isolation, and performed the servo / motor experiment again. Here's the plot.

Much better! I powered up the RC truck and after about 6 seconds, I moved it by hand to it's test stand (see "Moved the truck" above between the 6-12 second timeframe).

After that I ran the servo and the motor a few times. The truck vibrated around and changed its heading slightly. I pushed it back into place. You can see these subtle events on the plot.

What you can't see are the massive output swings like the LISY300AL exhibited. Cool! I think this sensor is a winner. High vibration rejection indeed!

Real World Driving Test
Next, I tested to see how it performed in a real driving test. The results were promising. Here's a plot of a subset of the data from an extended test run.

It's a little noisy, sure, but you can easily discern heading changes from periods with a static heading.  Were the readings anywhere close to reality?

Verifying Heading With GPS
To find out, I compared gyro heading to GPS heading.  I tweaked some Perl code to convert the raw gyro readings to heading and plotted that against GPS heading data from the test run.

I initialized the gyro heading to align initially to the gps values and then subtracted the fix age time from the gps heading readings to time align both plots.

You'll have to click the plot to see a larger image and make out the relevant detail.

Heading data from the gyro (red) is fairly smooth and it matches the general shape of the gps plot (green) which is great news, even if the scale and absolute heading are off.

This result suggests that the gyro readings may get quite a bit closer to the GPS readings by calibrating the gyro for temperature, null point and scale.

In the end, the noise issue was specific to the LISY300AL gyro and seems to be alleviated.

AVC Bot: A Deadline

The AVC bot is coming together slowly.  I am farther along than the blog posts would indicate because they lag the actual work by a few weeks.  Even so I've simply not made enough progress.

To give myself a kick in the butt, I've invited some friends over to witness the maiden voyage (and/or catastrophic failure) of the AVC bot on Saturday, February 26.

Crap, I gotta get busy now!

I owe Sparkfun a video of the robot driving forward and turning left on its own but if that's all the robot can do on April 1, I'm screwed.

But, if I have that functionality in two weeks, that gives me several more weeks to refine and build upon it so I'll have a functional robot come April 23, competition day.

The path ahead to the maiden voyage:

• Port GPS NMEA parsing software to mbed
• Port data logging software to mbed
• Finish software for Kalman Filtering of gyro data
• Build "motherboard" for mbed MCU to interface with the goodies
• Implement 5V ADC to adapt IR rangers and gyro to 3.3V MCU
• Software to calculate bearing and distance to waypoint
• Software to manage the precise timing of sensor polling and navigation
• Software to adjust steering and speed based on actual vs. desired heading

Even after I get all that done I'm still only about halfway home.

AVC Bot: First Data Captures

I still don't have a name for my AVC Robot. Got any ideas? Post them in the comments!

With the gyro, GPS, and SD card integrated with the Arduino, all the electronics stuck to a platform bolted to the RC chassis, and with code to grab the data and log it, all that was left was to strap down the GPS and take the truck out for a spin.

And that's just what I did. Even though it was 10:00pm...

You can see the GPS strapped to the back, the SD card up front, and the Arduino in the middle. I strapped the cheap LED flashlight I used in the picture above onto the front of the truck so I could see it in the dark.

I'm happy to report that I successfully collected logs that evening!  I repeated the experiment the following day around noon.  I wrote some simple perl scripts to parse the CSV files off of the robot's MicroSD card.

Here's the track plot from the next day (via GPS Visualizer and Google Earth). The GPS was reporting 15-25 feet accuracy. I have to say, the tracks are actually fairly close to reality.

But not close enough that the robot can rely on the GPS alone. You can see below that the tracks generated during bad GPS fixes are too far off for the kind of precision navigation required to circumnavigate the Sparkfun building. 

After this real world experience, it's even more abundantly clear to me why the AVC was hard for so many robots.

Incidentally, the GPS only updates at a 2 Hz rate instead of a more normal 1Hz rate. That's because it takes more than one second to send all the NMEA-0183 strings at 4800 baud. I can't change the baud rate, either.

Meanwhile, here's a plot of the speed as reported by the GPS during one of the daytime runs. If it's to be believed, the little RC truck can do about 18mph on a fresh battery. Cool!

The plot below shows mph on the y-axis and milliseconds on the X axis.

Here's the heading data from the GPS from one of the four daytime runs. Looks about right: I did a number of north-south runs, with quick turns in between. Note that the two outliers near 360 degrees are only a few degrees off from their neighboring points in the 0-10 degree range.

This is a plot of gyro data from another of the day runs. Wow. That is really noisy. I doubt I can use that kind of data for precision navigation!

The x axis plots time in seconds. The y axis is the gyro data, captured every 20-30ms and converted to degrees per second in this plot. The data looks like a mess.

You can see the truck was pointing in one, static direction up until about 6 seconds, then the heading rate change bounced all over the place, probably at the same time I started accelerating the vehicle.

Is the noise caused by mechanical vibration?  Electromagnetic noise?  Both?  Something else?

Yup, it's another cliffhanger!  You'll have to tune in next time to find out.

Robotifying an RC Truck

I've spent plenty of time playi-- err... experimenting with the RC truck I bought for the Sparkfun AVC.

And, I'd gotten an Arduino to control the steering and throttle, prototyped interfaces to a gyro, GPS, and SD card, and was ready to capture data, but before I could do so, it was time to modify the RC Truck and mount the control electronics more permanently.

I didn't want to drill a bunch of holes in the truck if I didn't have to and I wanted to keep a plastic body shell on the truck to protect the electronics from rollovers and weather.

I decided to use a sheet of Lexan® (polycarbonate) I had laying around as the base for the electronics, mounted to the RC truck chassis in a solid but non-destructive manner.

In the front of the truck, there is a plastic frame screwed into the top of the chassis, encapsulating the servo steering mechanism. I decided to use two of this frame's mounting holes as attachment points.

Luckily I happened to find a couple of longer screws of the exact size and thread pitch.  I needed longer screws to accommodate PCB spacers under the polycarbonate sheet.

As for the rear, I built a bracket out of sheet brass to fit over the rear body studs. These studs have two clip holes so I can clip down the bracket then clip the body on top of the bracket.

I have a tabletop sized Harbor Freight sheet metal brake that I used to get nice clean bends on the bracket.  I drilled the required 5 holes in the plastic using a step drill (I can no longer live without one!). Four holes for mounting, and one hole for the antenna.

I used the step drill for the brass bracket, too. Two holes for the studs, two for mounting to the plastic.

I stuck my breadboard to the plastic sheet and started working on protoyping.

I wanted a way to tie the microcontroller to the ESC / BEC and steering servo.  The Electronic Speed Control is the throttle. The Battery Elimination Circuit puts out a regulated 5V that can power the microcontroller and sensors.

I made a simple servo connector adapter using a Radio Shack copper clad perfboard, pin headers, and wire. Now I can plug the steering and throttle connectors into the microcontroller with ease. You can see it in the picture above, just left of center, in the foreground.

It's the gizmo with a bunch of orange and yellow wires and a black and red wire pair for power.  The black, red, and white servo wires are plugged into it.

A side project: The RC truck travels about 15mph and I already know from experience with Pokey that my robots have a penchant for crashing into things.  The RC truck robot won't be stuck in a maze so it might run into cars, cats, dogs, people...

To provide a remote kill switch, I wanted the robot to halt itself if I turn on the RC transmitter. I added one more 3-wire connector: from the microcontroller INT0 pin to the radio receiver.  That's the black, red, and yellow wire set are plugged into the receiver, which is the blue device in the center foreground.

I coded the microcontroller to interrupt if it sees a high signal from the radio receiver. When it does, it disables the throttle and steering and aborts operation.

With the electronics mounted securely, it was time for a test run to capture some data...