AVC Bot Hardware & Source Published

Everything about Data Bus is completely open: hardware, software, everything. Needless to say there are no guarantees that it works... because obviously it didn't *grumble*  But anyway...

I think when we can build on—or learn from—the work of others it speeds progress and advancement. I think robotics contests should further everyone's knowledge. New participants should never have to reinvent the wheel.

Here's the code I ran on the mbed MCU:

http://mbed.org/users/shimniok/programs/AVC_20110423/lqaj8i

I released a number of libraries on the mbed.org site as part of the project.

GeoPosition does lat/long calculations: bearing, distance, movement
IncrementalEncoder handles calculations for the wheel encoders
Steering provides a platform independent way to calculate steering angle corrections
Schedule is a handy utility for scheduling events by polling Timer values
SimpleFilter implements a simple "leaky integrator" filter for integers
ADC128S is a driver for the 8-ch analog to digital converter I used
LSM303DLH is a driver for the so-named tilt compass
TinyGPS is a port of the Arduino library to mbed with some methods added
TinyCHR6dm parses yaw output from the AHRS I chose

I've placed a snapshot of documentation, electronics designs, software from April 23, 2011 on my Google Code repository here:

http://code.google.com/p/bot-thoughts-ugv/source/browse/#

Here's the mbed code:
http://code.google.com/p/bot-thoughts-ugv/source/browse/#svn%2Ftags%2FApril%2023%202011%2FSoftware%2Fmbed

Here are the analysis scripts I used to plot dead reckoning, gps, compass calibration, etc.:
http://code.google.com/p/bot-thoughts-ugv/source/browse/#svn%2Ftags%2FApril%2023%202011%2FSoftware%2FAnalysis

All the schematics and board layouts are here:
http://code.google.com/p/bot-thoughts-ugv/source/browse/#svn%2Ftags%2FApril%2023%202011%2FElectronics

Various documents like the BOM, are here:
http://code.google.com/p/bot-thoughts-ugv/source/browse/#svn%2Ftags%2FApril%2023%202011%2FDocumentation

AVC 2011 Pictures

A few pictures from the 2011 AVC...

This is my absolute favorite robot of the day. It's a micro scale RC truck. Yes, it is sitting on a regular-sized coffee mug.

Inside the creator has packed an unbelievable amount of electronics including an OLED on the bed. Just astonishing. And he said the thing will do 20mph top speed!  That's faster than my 1:10 truck.

Amazing work!!

Me, in the pouring rain, about to botch the 1st heat start...

Rawr. What else can be said?

Above and below is team Zyzzyx's autonomous Traxxas Rustler tearing through a water-filled pothole on its way to a 3rd place run.

The legendary Team Tobor robot ready to claim another first place victory. I had a chance to talk to Scott during the competition; we were in the same heat. Really great guy, and obviously smart as hell.

Anyone who dresses in a gorilla suit for the AVC deserves mention. This is Team "Dr. Zaius' Magnificent Flaming Banana"

Team Blue Blaze. Awesome work on the car, guys. Lot of detail on this one, plus (unlike mine) it works! And there's a little surprise action... hint: think "Class D" ...

Daisy Rover did really well, I thought. They were sitting right behind me in the pits.

Back again this year was the cooler of doom...

And a big thank you to team Donuts Coffee Muffins!!  Thanks!  I had a donut. I needed and should've had some coffee too. I was barely conscious for the first couple hours of the event.

My pit area. I won nothing at all, except the pride in knowing I was the only one with an antiquated oscilloscope on site...

Scott H posted a video on his blog. Check it out! http://scottrharris.blogspot.com/2011/04/sparkfun-avc-2011-video.html

Sparkfun AVC 2011 is over

What happened to Data Bus, you may ask?  One word.

FAIL.

For more detail, add the word "EPIC"

Still more detail:

Heat 1: immediately veered into building
Heat 2: slightly less immediately veered into curb
Heat 3: immediately veered into building

Never made it around the first corner.

Bummer.

But, it was a blast of a time! Met and talked to loads of great people, saw awesome robots, learned a lot, etc.

Congrats to Scott (Team Tobor) for winning again this year!  Congrats to the UAV winner (I was so distracted I have no idea who won, but will edit this post as soon as I find out).

Will post more about my experience soon. Time for (early) bed. I'm pooped.

AVC Bot: Data Bus is Ready to Race!

111's my lucky number...

:) What do you think?  Now the name makes sense, huh?  I picked this RC body out months ago.

Technically there are still a number of bugs and issues and you'll notice the distinct lack of object detection sensors. But, the sensor merging finally seems to be doing a little better now (or did I just jinx myself)?

At rest, it keeps the AHRS yaw in sync with the compass. When it first takes off it uses the AHRS for heading, then when vehicle speed reaches 2 mph when GPS heading information stabilizes, then it switches over to GPS, assuming there's a good fix.

If the fix (HDOP) goes above 2, which typically makes the position information highly suspect, it switches over to dead reckoning, the heading and position of which will be kept synced to GPS while a good fix is available. Hopefully the dead reckoning can pick up where the GPS left off at least for a short time.

Also the robot starts at a known position and the robot calculates the distance/bearing offset between the GPS initial readings and the known start point and uses that fixed bias to adjust future GPS position information.

Of course the approach and implementation are fraught with issues and I'm sure you can think of many without trying, including ones I've not considered.

C'est la vie. Tomorrow should be a blast.

AVC Bot: Another Update

First of all, a big thank you to all of you who have written and commented along the way. I really appreciate your support and great advice. I've tried to check it all out and where my brainpower was sufficient, implement.

Second, look for a picture of Data Bus in race-ready configuration posted later today! EDIT: here it is

Not surprisingly, I've been very busy the last few nights...

• Tested out longer, lighter mast. Handling went into the toilet
• Rerouted motor wires and wrapped motor in magnetic shielding; slight improvement
• Experimented some more with IR and Sonar sensors without much progress made
• Fixed a major coding bug with calculating encoder distance traveled
• Finally, at long last, introduced code to sorta-kinda merge the different sensors
• Fought for hours and hours with bugs (see above)
• It rained Wed night. I tested anyway. The robot handles really well on wet asphalt!
• Discovered that inkjet labels with light coating of acrylic spray aren't waterproof
• Printed new decals on the inkjet and sprayed with automotive clear coat to waterproof
• Uncovered an intermittent problem with the right encoder skipping counts

So, still struggling with navigation. Figures.

Thoughts and Reflections

I posted a couple weeks ago that it was during that week I'd win or lose. I realize that actually every week before that, all the way back to November, was a win/lose thing.

I could've spent time on navigation basics instead of learning the Kalman Filtering and associated math. I don't regret it because I never would've been motivated to slog through that stuff otherwise.

I can take this learning forward to other projects. Same's true for really everything I've done. I've learned a little more about analog circuits, wheel encoders, various navigation sensors. I can build on all that later.

Given that I'm still struggling a day before the competition, it's clear that I've been reaching way beyond my capabilities, but that's when you really learn a ton. There have been dozens of mountainous learning curves to climb. So, yeah, learned a lot. Such as...

• The mbed environment
• Passable C++ (I've stuck to C all these years)
• Gnuplot (wildly complex/feature-rich tool)
• Kalman Filtering of course
• Behavior, faults, errors of GPS, gyro, accelerometer, compass
• Compass tilt compensation and calibration
• Interfacing various devices: Maxbotics Sonar, various compasses, AHRS, etc.
• Various "new" regulators: e.g., LM4941
• Wheel encoder interfacing
• Doxygen syntax
• CMUcam1
• NMEA sentences
• Improved Eagle techniques (BOM-EX, board layout, etc.)
• DIY PCB fab techniques (SMD, Silkscreen)
• Painting lexan RC bodies
• RC car suspension tuning
• And probably a dozen other things I'm forgetting

Yikes. Well it's been fun. Now I have to go try to sort out the remaining nav bugs and issues. I still am not entirely sure what to do about object avoidance. I sure hope we know where the barrels are going to be before each heat. But that would just be too easy, huh? :)

AVC Bot: Update

Here's where I'm at with the robot...

• Body is painted, some detail to finish. Pics forthcoming. Hope you like it :)
• Infrared sensors aren't working as expected, still no idea why
• AHRS (gyro+accel) is only able to track very, very slow heading changes
• I suspect motor magnetic field compass interference more and more...
• If so, compass heading distortion may be proportional to current (and, roughly, speed)
• Added a CMUcam v1 and Arduino serial-to-i2c board to detect red barrels
• Attempted to collect some data when CMUcam approaches red 'barrel'
• Also attempted to collect data on compass vs. speed to test motor field theory
• While trying to collect this data, found that my software is hanging again ARGH!
• While debugging I discovered the CMUcam/Arduino RF interference is killing GPS reception. Double ARGH!
• My power supply has auto cutoff which kicks in with low battery and heavy throttle
• I had a nightmare about the competition. I think it was the Nyquil.

I'm a bit frustrated by the issues. At this point there's not a lot more I can get done on the robot except get it partially operational again and do something with obstacle avoidance.

After all this time, I still haven't been able to come up with a satisfactory way to merge compass, gyro/AHRS, and GPS data primarily because the errors in compass and gyro/AHRS are pretty big and obliterate dead reckoning accuracy, and I've spent all this time just trying to understand the nature of the errors.

Compass

For the compass/magnetic issues, I'm draining the remainder of my robot funds to try a solution to address the magnetic interference. It's on order, 2-day delivery, to arrive tomorrow. It's a total hail mary play. It probably won't work. Meanwhile, the cheap option is to raise the compass/gps mast... along with the center of gravity.

GPS

Raising the mast should also reduce RF interference. Enough? Don't know. I may try to get or make a metal enclosure but there's precious little time for that now.

Obstacle Detection

For obstacle avoidance, a couple of options present themselves. If we know where the barrels will be well in advance of running, I can attempt to plot waypoints around the barrels.

If not, I have a second sonar ranger setup that just came in, enabling the robot to--maybe--localize the barrel.. Or maybe by some miracle I can get the IR rangers working properly.

Navigation

For navigation, worst case I will run GPS plus some simplistic error correction which I've tested to some degree. If the GPS fix gets too bad (in the urban canyon on the west side of the building), the navigation accuracy will suffer, too.

I may be able to just do some rudimentary logic to get usable heading/position values when the GPS fix gets bad.  I'm finding heading is the most crucial aspect of my robot's ability to navigate by dead reckoning. (thanks for that illuminating insight, Captain Obvious...)

I may take a page out of Scott's (Team Tobor's) book and try to use odometry to provide more info on heading.


Whatever merging I do, there's still the GPS lag to deal with.

All of this above, of course, only possible if I can stamp out the latest giant bug very soon.

I've reverted to code from the 5th and it seems to be running. But I've got to re-de-bug all that code now.

This sucks.

But I'm not giving up. Not by a long shot.

Quick and Dirty Compass Calibration in 3d!

No, you don't need funny glasses to read this.

As I continue to wage epic, nightly battles against the army of problems on my robot, Data Bus, I thought I'd share my simplistic approach towards 3d compass calibration that hopefully is "good enough" to get you started.

The problem: incorrect headings from 2- and 3-axis magnetometers not only in absolute terms, but also relative. When the compass is rotated 180 degrees, the resulting heading changes by more or less than 180 degrees.

References:
Using LSM303DLH for a tilt compensated electronic compass (pdf)
Compensating for Tilt, Hard Iron, Soft Iron Effects
http://www.varesano.net/blog/fabio/first-steps-hmc5843-arduino-verify-accuracy-its-results

Types of Correctable Distortion

Two types of correctable distortion affect magnetometers like the ST Microelectronics LSM303DLH and 2-axis Honeywell HMC6532 that I've been experimenting with: hard iron and soft iron distortions.

Hard iron distortions are caused by magnetized objects in a fixed location relative to the mounting point of the compass.  Soft iron distortions are caused by magnetically soft objects or PCB traces that alter the magnetic field around the compass depending on the direction the compass is pointing.

If you plot the x, y and z magnetic readings at various positions in a 3d scatter plot, in a perfect world you'd see a sphere surface mapped out by the points.

Hard iron distortions will offset the sphere along the x, y and z axes. Soft iron distortions turn the sphere into a tilted ellipsoid.

There's also scale distortion. All the axes should have equal sensitivity but they rarely, if ever, do. Correcting this is a question of normalizing the reported results of each axis.

Simpleton Calibration

The ST Datasheet explains the mathematical equations and approaches required to identify hard and soft iron distortions and corrections. I'm still coming up to speed on matrix math, linear algebra, etc., and time is running out very quickly so I decided to try a quick and dirty (read: simpleton) approach.

To wit: simply taking maximum and minimum values for each axis to compute offset and scale. That's assuming no significant soft iron distortion.

To verify that assumption, I needed to visualize the measurements from my LSM303DLH breakout from Pololu. I modifed an example program on mbed.org to print out X, Y and Z readings in a form that could be plotted easily by gnuplot.

I manually spun the compass around for a few minutes to collect a reasonable number of data points then I plotted the results in a 3d scatter plot (in gnuplot: splot "file.csv") I don't have a handy way to create an anaglyph so let me show you the X-Y, X-Z and Y-Z plots.

You can see that there is a pretty big x-axis offset and obvious Y scale distortion. I couldn't tell by eyeballing if the Y or Z axes were offset or mis-scaled.

A pretty simple perl script calculated the answers for me:

Xmax =  98.00  Xmin = -157.00 Xoff = -29.50
Ymax = 124.00  Ymin = -123.00 Yoff =   0.50
Zmax = 101.00  Zmin = -109.00 Zoff =  -4.00
Max  = 127.50  Min  = -127.50
Xsca =   1.00  Ysca =   1.03  Zsca =   1.21

------------8<--- cut here ---8<------------

#!/usr/bin/perl

open(FIN, "<$ARGV[0]") || die "can't open: $ARGV[0]";

$label{0} = "X";
$label{1} = "Y";
$label{2} = "Z";

$count = 0;
while () {

    s/^\s+//;
    @data = split(/\s+/);
    for ($i = 0; $i < 3; $i++) {
        $sum[$i] += $data[$i];
        $max[$i] = $data[$i] if ($data[$i] > $max[$i]);
        $min[$i] = $data[$i] if ($data[$i] < $min[$i]);
    }
    $count++;
}
close FIN;

for ($i = 0; $i < 3; $i++) {
    $med[$i] = ($max[$i]+$min[$i])/2.0;
    printf STDERR "%smax = %6.2f  %smin = %6.2f %soff = %6.2f\n",
      $label{$i}, $max[$i],
      $label{$i}, $min[$i],
      $label{$i}, $med[$i];
    $max[$i] -= $med[$i];
    $min[$i] -= $med[$i];
    $max = $max[$i] if ($max[$i] > $max);

    $min = $min[$i] if ($min[$i] < $min);
}

printf STDERR "Max  = %6.2f  Min  = %6.2f\n", $max, $min;

for ($i = 0; $i < 3; $i++) {
    $scale[$i]=$max/$max[$i];
    printf STDERR "%ssca = %6.2f  ", $label{$i}, $max/$max[$i];
}
printf STDERR "\n";

Results

The C++ library that I'm writing/porting/adapting on mbed.org for the LSM303DLH features two member functions, setOffset() and setScale() to which I can provide the offset and scale numbers from above.

A simple test program exercises the library and tests the scale and offset values.  Rough tests show improved results in heading as well as when swinging the compass 180 degrees.  The true test will happen when I mount the new compass onto my robot and collect data. Hopefully the calibration is close enough to significantly improve dead reckoning position calculations.

AVC Bot: Barrels!

I see red / And it hurts my head*

Sparkfun released their 2011 course tour video.  Here is a screen capture of the barrel obstacles:

Ok, so they are all bright, Sparkfun Red.  One thing I did learn from Pokey is that vision sensors work really well in certain circumstances.

This is one of them. I have a line on a color camera sensor with blob tracking.

I'd love to roll my own but no can do in only 8 days with all the other problems I have to resolve.

I'll continue the "systems integration" strategy with my robot.

* Rush, Red Lenses

AVC Bot: Ups and Downs

A few quick notes: (1) pictures of the robot are forthcoming, don't worry! I want to finish painting and mounting the body, first. (2) I'll tell you all about the AHRS and other sensors I bought in a future post. I purchased several options and wanted to wait until I had something working before talking about it.

Building this robot has been quite an exhausting roller-coaster ride. Repeatedly cresting the triumph of success followed by stumbling face first into the muddy ditch of failure.

Just when I was about to give up, I got the robot to navigate autonomously. Then when I was finally feeling hopeful and tested the robot at the nearby school, everything went to crap again. That was Tuesday. The robot consistently veered wildly off course.

Compass Problems

Light green: actual path, Dark Green: confused robot path

I drove the robot manually between points A, B, E, D, and back to A to collect data. The rectangular, light green plot above is the GPS reading and is very, very close to the real path.

The dark green path is the dead reckoning plot based on using the robot's compass and as you can see it is severely distorted from reality.  Talk about disheartening

The bogus plot has all the signs of a magnetic field distortion to my eye. And a bad distortion at that. But it's not a hard iron distortion from the robot chassis; the compass headings looked nearly perfect when I tested them at starting point A.

As some readers have suggested, there may be a distortion introduced by the motors' magnetic fields. I'll have to test that theory. I'd placed the compass on a mast 40cm from the motors hoping to reduce that effect.

I can always move the mast forward. I can increase the height, too, with the tradeoff of a higher center of gravity. The robot exhibits pretty serious body lean around corners already.

Whatever the case, I need decent dead reckoning. GPS is going to be unreliable through at least 1/4 of the SFE course.  I'd like better accuracy than pure GPS can provide to increase the robot's chances of circumnavigating the building while dodging barrels.

GPS Success

On the upside, the GPS seems to be providing very good fixes since I installed a silly little-- actually I better keep that detail to myself for now. I don't want to give everything away to the competition :)

Anyway, the result of the modification is that I'm now getting up to an 8-satellite lock in my basement and a 10-sat lock in the garage. That's pretty amazing, if you ask me.

So, worst case, I may be able to navigate part way around the SFE building purely by GPS.

And I still have the high zoot AHRS I bought. I've been unable to resolve its magnetometer issues. But I can turn off that sensor and run the AHRS purely on gyro and accelerometer. That might be just enough...

Hmm... a plan is forming...

Obstacle Detection Problems

Meanwhile I'm having big problems with one of my only two long range IR sensors which dashes my original plans for obstacle avoidance. Another letdown, unless I can get to the cause of the problem fast or order a new sensor with expedited shipping.

I'm also considering using two sonar sensors. I've got the necessary parts on order, but they won't arrive until a few days before the competition leaving little time to code a solution.

Doomed?

Navigation issues have eaten up the last month that I'd hoped to devote to obstacle avoidance.

I'm pretty much past the point where there's time left to make major changes.  I'll have to hope I can find some clever way to cobble together the myriad mess of stuff I have now into something that halfway works.

I'm really on the precipice of failing to pull everything together. Which sucks given how long I've worked on this robot. There's quite a few problems to diagnose and fix, a lot of code left to write, test, and refine.

Sadly this is about the same situation I ran into with Pokey.  Last week and still working on the basics. Maybe I didn't learn anything from that experience, after all.

Just over a week left.

Sparkfun AVC 2011: The Competitors

Time to size up the competition. Some great videos are showing up on Youtube. Here's a random sampling...









And the quickest robot is easily this one:

http://jessejay356.blogspot.com/2011/03/my-rc-truck-is-out-of-control.html

On top of that, last year's winner, Team Tobor, is back with the extended kalman filter, Tamiya Grasshopper dune buggy, and various improvements, to defend his title.

I am so doomed! :D

AVC Bot: Bug Melee

Just as my patience and gumption were almost completely tapped out, as defeat loomed large in my thoughts, at 2am this morning....

I FINALLY GOT THE ROBOT TO NAVIGATE!!!!

Here is a summary of my recent bug battles that keep draining away hour after hour

• RF interference degrading GPS signal and affecting compass, placed both on 'mast'
• Sensor 'mast' was way too heavy, significantly raising CoG. I dumped the truck on its side during testing. Lightened the 'mast' by about 75%
• Still getting slightly degraded GPS signals, contemplating RF isolation of the main electronics
• Battery refused to fast charge, so had to take a few hours to slow charge
• Major bugs in geo calculation code: jacked up both the onboard nav and offline analysis and plotting.
• Switched to LSM303DLH tilt compass but experienced strange distortions in compass reading; calibrated and fixed only to find...
• Massive noise in LSM303DLH accelerometers causing massive compass heading noise, which I couldn't trace because...
• The addition of compass code was hanging the main bot program unpredictably. Reverted to earlier version.
• Implemented low pass filter (leaky integrator) and increased mast mount rigidity
• Glitch in analysis scripts causes strange speed values, may be affecting plots, not sure
• Continuing to experience occasional filesystem errors on the microSD but am able to fumble around them. I can't wait for that to hold me up two minutes before the beginning of a race... that should be fun (read: not fun and very stressful)
• High zoot AHRS exhibits similar heading distortions as LSM303DLH but was unable to correct by setting offsets and scale matrices or by using the built in calibration. Very disappointed in AHRS.
• AHRS pc client code keeps crashing. Very, very disappointed in AHRS.
• Other stuff I'm forgetting

Where the robot thought it was

So, after fixing the nav computation bugs and implementing the accelerometer low pass filter, the robot finally navigated through three waypoints along my street!

Purely with dead reckoning!

Three times in a row!

It wasn't perfect, there's still imprecision in heading due to side angles (far less an issue at the SFE building), but the navigation was repeatable and seemed to be accurate to at least 3 meters across a distance traveled of about 40 meters.

Hopefully, combining position and heading info from both dead reckoning and GPS in some semi-intelligent fashion will improve navigation accuracy to the sub-meter range. We'll see.

The next two weeks (!) are going to go by fast.

Interfacing MaxSonar EZ1 with mbed

Libby carefully inspects my wiring...

Introduction

MaxBotics makes the LV-EZ series of sonar rangers. The devices are aptly named and provide very flexible interfaces: TTL serial, analog, and pulse width to represent distance. The rangers can be chained together so that they read and output results sequentially. Pretty neato.

Several weeks ago, while facing problems getting my new GPS to work, I decided to try something easier: working with a recently purchased MaxSonar EZ1 ranger (datasheet, PDF).

MCU of choice for the interfacing project was the ARM Cortex M3-based mbed.  The mbed is the brains on board my AVC competition robot Data Bus.

Wiring

One first has to solder header pins onto the ranger module. Not a big deal. The pins are clearly labeled GND, +5, TX, RX, AN, PW, BW. The module can take any voltage from 2.5-5.5V so standard 3.3V and 5.0V will work. My mbed runs on 3.3V.  The EZ1 datasheet provides scaling information for 3.3V and 5.0V supplies.

For the mbed, connect VOUT (3.3V, pin 40) to +5, GND (pin 1) to GND, p20 (pin 20) to AN. That's all there is to it on the hardware side.

Connecting an mbed to the EZ1 sonar

Software

Initially I tried reading serial data out of the EZ1 but for some reason I was not getting the output indicated in the datasheet. So I thought I'd try reading the analog values.

Use the mbed library's AnalogIn API, read the analog value as a float. Then convert the analog reading to voltage, and finally convert to inches using the scaling factor provided in the datasheet (6.4mV/inch for 3.3V supply)

Source code on mbed.org

AnalogIn ain(p20);
Serial pc(USBTX, USBRX); // tx, rx

int main() {
    float adc, volts, inches;
    int feet, in;
    
    pc.baud(115200);
    
    while (1){
        adc = ain.read();           // read analog as a float
        volts = adc * 3.3;          // convert to volts
        inches = volts / 0.0064;    // 3.3V supply: ~6.4mV per inch
        feet = (int) inches / 12;   // inches to feet (trunc)
        in = (int) inches % 12;     // remainder: in(ches)
        
        pc.printf("%8.2f adc %8.2fV %8.2f in %d'%d\"\n", 
                  adc, volts, inches, feet, in);

        wait(0.05);                 // ~20Hz update rate ; note we aren't
                                    // truly synchronized ...   
    }
}

Moving the sonar around the room, pointing at various objects:

0.11 adc     0.35V    54.77 in 4'6"
    0.11 adc     0.35V    54.77 in 4'6"
    0.03 adc     0.10V    15.36 in 1'3"
    0.05 adc     0.17V    26.32 in 2'2"
    0.02 adc     0.07V    10.58 in 0'10"
    0.07 adc     0.23V    36.39 in 3'0"
    0.02 adc     0.07V    10.58 in 0'10"
    0.03 adc     0.11V    17.63 in 1'5"
    0.02 adc     0.06V     9.19 in 0'9"
    0.02 adc     0.06V     9.07 in 0'9"
    0.01 adc     0.05V     7.43 in 0'7"

Testing and LCD

To test the unit outside, I hooked up a serial-enabled LCD to the mbed, and transmitted the foot and inch data to the LCD. The LCD uses a common HD44780 controller.(For wiring, see the wiring diagram above)

Send 0xFE to indicate a command followed by 0x01 to clear the screen. To position the cursor, send 0xFE followed by 0x80|n where n is the cell number (0x00 is the top left, 0x40 is row 2, left, 0x10 is row 3, left and 0x50 is row 4 left.

I added the following to the code above to print out feet and inches.

        lcd.putc(254);
        lcd.putc(0x80 | 0x00);
        lcd.printf("%2d'%2d\"             ", feet, in);

I powered the mbed by connecting a 9V batter on VIN (pin 2) and GND (pin 1) (see wiring diagram above)

The test session was intended to determine the feasibility of using the sonar on my AVC robot for detecting barrels, people, cars, and other UGVs.

Results

The maximum detection distance appears to be approximately 22 feet (6.7m). The device can detect a variety of objects, narrow to wide: my Jeep Grand Wagoneer is huge and hard to miss, my mailbox is much smaller but the sonar found it too.

The ranger will sit only a few inches off the ground and I found that the beam pattern causes echoes from the ground in front of the ranger. That's because the propagation pattern expands both vertically and horizontally.

A week or two ago, I ordered a parabolic reflector for the Parallax Ping sonar that may help to reduce the vertical dispersion while increasing the range of the EZ1.

New Compass

I've been struck by inspiration. Here's the design mock up for a far more reliable compass than the one I'm using now.

417072696c20466f6f6c7321

AVC Bot: Progress, Caffeine, More to do

I've been pretty busy, not sleeping a lot, drinking an enormous amount of coffee. And that's no foolin' :)

Only 20-some days left and the tendrils of sleep-deprived madness claw at the edges of my frayed mind...

I've been here before...

Data Bus with second deck and IR rangers mounted

Done

• Added a second deck for mounting navigation sensors
• Remounted GPS, gyro and compass
• Revised the power supply. Twice.
• Redesigned the RC kill/takeover board, built and installed it
• Installed larger skidplate / bumper
• Ordered, received, and mounted Sharp long range IR sensors
• Interfaced EZ1 Sonar to the main code base
• Installed body mounting posts and test fit the body
• Repaired the broken RC receiver antenna
• Revised code for Vcc-independent gyro rate calculation
• Experimented offline with simple position estimation
• Ordered a fancy AHRS and some other enhanced sensors

To Do

• Mount Sonar
• Code up IR Ranger distance calculation
• Implement obstacle detection
• Mount and interface the new AHRS and/or other sensors
• Complete GPS/AHRS/Dead Reckoning sensor fusion
• Experiment with obstacle avoidance navigation options

Down to the Wire

For the last several days, I've been telling myself that I will win or lose this competition this week.

Not on April 23. But now.

I've been here before with Pokey a few years ago, working on crucial, high level functionality until the bitter end, the day of, in fact. The result was catastrophic, albeit entertaining, failure.

Prior experience says that if I don't push hard and get the navigation buttoned up and the obstacle detection in place in the next few days I am probably not going to pull this off at all. It all rides on what else I can get done this week. So I've been going all out.

What seems like 3 weeks left is more like one because I need a week or two of testing, debugging and refining, and a few days to get all my tools, supplies, and equipment organized for the event.

Compass Errors

Some of my readers have offered some great insights on compass errors and other issues. Thanks!!

• Magnetic field distortions from vehicle electrical systems, particularly motors
• Mapping and correcting for errors at multiple compass headings
• Tilt compensation may be an issue

I will test the first, implement the second, and for the third I've ordered new sensors, including a complete off-the-shelf AHRS.

Gyro Errors

The gyro's bias and scale factor are proportional--and very sensitive--to supply voltage, so I realized I should have calculated gyro rate using a voltage-independent value for Scale Factor. Like the datasheet said. RTFM.

I hope this will eliminate most of the gyro error I've been seeing. I'm preparing the robot to run more tests to find out for certain.

Last Minute Changes

As alluded to above, I'm changing the AHRS design for Data Bus.

There's inherent risk in changing the design this late in the game. I can think of at least one example of a 2010 AVC entrant who was bitten by last minute changes.

On the other hand, the risk of failure due to inadequate sensors is real, high, and quite familiar to me from my experiences with Pokey. I think it outweighs the risk of implementing a new design.

AHRS Options

So I have a few AHRS options on order. The key was to find options that were relatively low risk to implement and which would provide short cuts versus continuing along the current path.

• Supplement: add 2dof of gyro, 3dof of accelerometer, and 3dof of compass to the system
• Replacement: replace the compass with 3-axis magnetometer & accelerometer, with code available
• Wholesale Change: replace gyro and compass with complete 9dof AHRS with developed firmware

Oddly enough, the last option, wholesale change, is probably the least risky. It requires nothing more than reading some serial data to receive heading information periodically. All the sensor fusion is written in the sensor's firmware.

There's some pride lost in doing it all myself, true. But from the very beginning, I've viewed this project as one of COTS systems integration rather than from-scratch development.

The other two options still require sensor fusion but should eliminate, first and foremost the tilt errors from the compass.