Dale's Homemade Robots

Improvements June 2009

 

Post 2009 Robot Rally bug fixes

The 2009 Robot Rally spotlighted all the flaws that result from a quick 3 week engineering and building project.  Time saving shortcuts in code and hardware bit my butt several times.  Failed edge detectors - Ouch!  Failed beacon tracker ... chomp!  Ow!  Line follower reversal - Arrrg!  I'm happy to report I've investigated all the issues that cropped up and fixed them all. The bot still isn't perfect but it's a whole lot better than before.  I've also cleaned up the software code and documented it better.  Here's what has been changed and fixed.  Source code and schematics may be downloaded from links at the bottom of this page.

New CPU chip

The Atmel AVR ATMEGA8535P was full.  I used all 8192 bytes of program space.  There was no room left for enhancements or bug fixes.  So,  I ordered some ATMEGA644P chips from DigiKey.  Only Five bucks each, such a deal!  These are hardware pin compatible with the old 8535 so no hardware changes were needed.  They have 64K program memory and 4k RAM.  This is 8 times the memory of the old CPU.  They are mostly software compatible too.  Yeah, "mostly".  That means spending a lot of time going over the code and finding the differences in the names and bit functions of all the internal configuration registers.  Also, the avr-gcc open source compiler and avrdude program downloader I had didn't support the 644 so I had to hunt down the latest version for the Mac. I downloaded and installed AVR Crosspack.  Several days were spent hunting down bugs caused by the CPU upgrade.

New H-Bridges

L293D h-bridge chips suck.  They have nearly 2 volts of drop across them and run hot as hell.  I was using two in parallel for each motor and they still ran very hot.  Due the voltage drop the motors only got 10 volts out of 12 that was available.  This means that top speed is reduced by about 20%. So, I removed them and mounted a pair of LMD18200T chips on the aluminum chassis.  These are MOSFET based chips and have 0.3 ohm resistance.  The motors can receive almost full battery voltage.  Robot speed increased considerably.  Hear that 3pi bot guys?   Lower voltage drop and chassis heatsinking means no more smoking hot h-bridges.

 

Two more AA cells

More Power!  I still needed more speed to have a chance against the 3pi robots in line following.  I crammed  two more cells in the battery pack for a total of 14.4 volts.  The motors are now 2x over volted.  Yet, they hardly get warm.  And, yes, the bot still tracks the line at full speed!  Now we have a chance of beating the 3pi in basic line following.

Staggered line tracker LEDs

Originally I had 8 red LEDs aligned with 8 photocells to track the line.  They were spaced 0.7 inches apart.  The line we need to follow is 0.75 inches wide.  When the line was between photocells it would sometimes "dissappear" and the bot would think there was no line present.  For basic line following this wasn't a problem.  Small side to side movements self corrected the situation.  However, the maze contest required taking action when T intersections and dead ends are found.  The bot needs to know for certain if it's on a line or not.  This problem was fixed by using 9 LEDS and putting them between the photocells.  The blind spots are filled in and the line present and centroid code is much happier now.

 

Slotted hood over the beacon tracking photocells

Since I had problems with stray room lighting in the beacon killer contest I decided to add some shielding to the beacon sensor photocells.  The slot covers 120 degrees and is 3/16 inch wide.   I machined it from a piece of round PVC stock on a lathe and mill.  Major changes in software were still required to make the beacon tracker "bullet proof".  More about that later.

Also shown in the photo on the left are the 6 IR LEDs for object detection and the pair of PIN photdiodes above them.  They worked great and didn't need any changes.

 

 

 

Edge Detectors

The bulldozer contest involves driving around on a surface 4 inches off the floor while pushing objects off without driving yourself off.  Originally I used an off-the-shelf reflective IR sensor consisting of a phototransistor and IR LED.  These were mounted near the front and outside the left and right wheel track.  Electrically, I simply connected the LED to a current limited 5 volt source and read the phototransistor current across a 1 meg load resistor.  This particular circuit was non-linear and saturated in fairly low light.  The result was falsly detecting the room light shining on the floor as reflected IR and driving off the cliff. Even the self calibrating feature in the software didn't completely solve the issue.   So, I ripped them out.  Time for pulsed IR edge detectors that ignore ambiant light completely.

I had two unused channels in the pulsed active IR object detector circuit which I could use.  All I needed was two IR LEDs and two photodiodes.  Also I needed a way to mount and aim them.  I made mounts from solid PVC using a bandsaw and mill (as a drill press).  I drilled holes for the LED and photodiode.  As the photo above shows, the IR LED is angled at 45 degrees and the black photodiode points straight down.  The spot of light from the LED hits the surface directly under the photodiode.

I connected the LEDs to the two spare drivers and the photodiodes in parallel with the existing ones for object detection.  This failed.

The bright surface 1/2 inch from the photodiode/LED produced way too much signal and overloaded the high gain log amplifier.  The amplifier was designed to detect objects up to 12 inches away!  Since the reflected light falls off as the 4th power (square law going and coming) I had like 330,000 times more light at 1/2 inch than at 12.  Bummer.   But, luck was on my side again.  I had one spare op-amp left and used it to make a lower gain linear amplifier dedicated for the edge detectors.  Works great now and room lighting has no effect at all.  Because they also detect black tape these same sensors are now used to detect zero radius turns in advanced line follower and intersections in maze.

Now that I have a dedicated amplifier for the edge detectors I suppose I could have used the original off the shelf reflective IR sensors and pulsed them instead of making my own.

Beacon tracker improvements

The ambient room light at the Robot Rally was at least 50% brighter than the room I tested in at home.  The simplistic software to detect and track the beacon depended on absolute brightness levels and failed in the Robot Rally environment.  The software simply rotated the bot in place until the beacon tracker photocells detected light above a preset brightness level and then started moving in that general direction guided by the difference between the left and right photocells.  Excessive room lighting exceeded that threshold in all directions.  The beacon seemed to be everywhere at once!

A better way is to spin around 360 degrees to find the brightest direction then return to that heading before starting.  But it can still be faked out by large widows or bright white walls.   An even better way is to spin 360 degrees while looking for a distinctive change in light levels that indicate a sweep past a bright point source of light.  The sudden change in light levels on the left and right photocells as they sweep past the beacon provide the clue.

 

To make this work I needed to graph the angle vs photocell response for 360 degrees to find out what pattern I needed to look for.   I taped a protractor to the bot and used a ruler clamped in a Panavise as a pointer.  I wrote some test code to dump the left minus right beacon photocell values to the debug LCD display.   I turned on the beacon and wrote down the reading for every 10 degree change in rotation.  The result is shown in the graph below (blue line).  As you can see the pattern is very distinctive.  I used a correlator to compare the pattern to a square wave.  The green line on the graph below  shows the correlator output.

Blue: Left minus Right photocell response    Green: Correlator response

Correlator code

int correlate(int s)
{   uint8_t i;
    int a;

   for(i=15;i > 0; i--) samples[i] = samples[i-1];  // shift old data by 1 place 
   samples[0] = s;	// put in new data
   a = 0;              //clear accumulator
   for(i=0;i<8;i++) a = a - samples[i];		// sum the negative half
   for(i=0;i<8;i++) a = a + samples[i+8];	// sum the positive half
   return a / 16;			// return correlation value divided by 16
	
}

 

The process for finding the beacon heading now works like this:  Rotate 360 degrees taking left minus right light readings every 5 degrees.  Quadrature encoders are used to measure the rotation angle.   Process the most recent 16 values in the correlator and remember the heading of the highest correlator reading.  Stop then rotate back to the heading with the highest correlation using the quadrature encoders.  An offset of 40 degrees needs to be applied to compensate for the 8 sample correlator delay.   Drive towards the beacon guided by the left and right photocells difference readings.

This works very well.  The bot can now find and track a flashlight beam projected on a wall in a fully lighted room.

What's Next?

I'm planning to install a SparkFun Bluesmirf Bluetooth module and write some code that allows me to receive telemetry from and send commands to the Polymax from my laptop.  Once that's working debuging will be easier and I'll eventually start working maze reduction code.

Schematics and Source code

Here are the latest schematics and source code for the Polymax 9000.  They have all the improvements and modifications discussed above.

Schematics: page 1 and page2 (Updated June 9th, 2009) [Obsolete]

Source code: polyathlon-6-8-09.zip (Updated June 9th, 2009) [Obsolete]

 4 pages of schematics updated Dec 28 2013  (Zip file of pdfs 1.7 megs)

2013 source code (zip file)

Hit Counter 10062

 

---