Oct 16, 2006
Because of the sheer size of this blog and because of some new information I wanted to post here for Chris MacNab's 4th year students at UofC I've decided to break this blog up into years. This page will hold all of the development on the first incarnation to compete in the 2004 games and the others to compete in the 2005 - 2008 games. I've also added links at the top of this page for relevant references.
If you are just looking for hints and suggestions on building and competing with a minesweeper robot here is my minesweeper quick start guide.
Minesweeper blog for 2005 games
Minesweeper blog for 2006 games
Minesweeper blog preparing for 2007 games
I built this robot to compete in the "minesweeping" competition for the 2004 Western Canadian Robot Games. I thought the event idea was so cool I just had to go for it.
Before I go into it here are some links that may be of use if you are building your own:
Craig Maynard's company has mine kits. It's the same mines I use and the same mines used in previous events.
Lee Valley tools is where I got the honkin magnets used to pick up UXBs.
Mark III Robot store is where I got the idea for the proximity sensors. They are much like their "proxdots."
avr-libs is the AWESOME gcc-based tools for the avr. However, if you use winderz you might be better heading over to avrfreaks instead.
Solarbotics is where I got all of the motors and where you can get sintra, a lightweight yet tough plastic material good for making all sorts of things.
My design philiosphy was to make a robot as general purpose as possible but still be small and light enough to navigate the course and traverse any obstacles. I intend to use this robot for other projects so I made sure there was plenty of room for expansion in the form of accessible ports on the microcontroller, lots of power and a quick-mount system for various servos, robot arms, etc. By making the robot general purpose I can boil the task at hand down to make it conducive to software solution instead of a hardware solution. This isn't because I think hardware solutions are bad. It's just that I am much better at software than hardware and I am just capitalizing on my strengths!
About halfway down this web page is a description of the development progress starting just before I etched the mainboard.
The chassis consists of a box-jointed "lightply" (model airplane wood) case about 10cm wide, 16cm long and about 6cm high. Motive power comes from 4 copal 60:1 gearmotors hooked up to 4 Tamiya off-road tires using custom hubs made from brass and held on with 2mm bolts. I found the stock Tamiya tires too squishy so I inserted "inner tubes" I cut from a block of foam. Now they are just right. They flatten a little for traction but not so much that I lose too much ground clearance. With the tires in place the 'bot measures about 18cm wide and 16.5cm long. I am a little worried about weight because with the chassis, populated mainboard and battery it weighs about 600 grams. Add to that the minesweeping gear and sensor array I figger the weight could climb up to about 1000 grams. The robot is quite fast (for a bot that is supposed to be constrained into an 8' x 4' playing field) and can go about 40cm a second at full tilt.
Here is the PCB layout I designed for it as seen from above
through a "transparent" substrate. Blue is ground, red is regulated +5
volts. Click for a view of the image at the resolution I edit it at.
Power comes a 7 cell pack of 800 mAh nicad AA cells. This gives me about 8.4 volts prior to regulation. On the mainboard I have two 7805 regulators (in TO-220 case with heatsinks) to provide power. One regulator is for the logic and mainboard components and the other is for expansion and to power servos (in case I add any) and the LCD backlight. If the bot gets too heavy I can switch to using nimh or even lipoly cells to save weight.
Power is controlled through a DPDT toggle switch. When mainboard power is off the battery is electrically accessible through a connector on the mainboard where I can attach a fast, peak-detecting charger. From dead flat, I can charge the bot in about an hour. *ALL* my battery powered bots have something like this so I can have a very well secured battery but not have to take anything apart to charge it.
The brains of the bot is an Atmel ATmega32 processor (40 pin DIP package) running at 8 mHz with a crystal. Programming goes through a 6 pin ISP connector on the mainboard to the parallel port of my computer. I almost went with an Atmel ATmega128 but the PCB board design was too far along to make the change and still have time for writing the software before the games on May 15, 2004.
On the mainboard I have two SN754410 H-bridges controlled through a 74HCT259 8 bit addressable latch. I found that with all of the expansion I wanted to do I ran out of pins on the microcontroller. The 8 bits on the latch control the 8 direction pins on the H-bridges. The address pins on the latch are shared with the address pins on the CD4067 used to control the digital input lines. The 4 enable pins on the H-bridges are hooked up to the mega's PWM channels. The two 16-bit PWM (OC1A and OC1B) channels are also hooked up to two three-pin connectors that are electrically compatible with my collection of servos in case I wanted to add some in the future. On Cleansweep two h-bridge channels will control the locomotion motors and the other two are for the mine marker dispensers.
I found the only problem with using the latch is that the motors may come on when the CPU gets programmed or the power is cycled depending on what was last set on the latch. I think I will add some pull downs or something for the next one so that won't happen. For now, I just have to keep that in mind and take the bot off it's feet when powering on or programming the CPU. The third mine flag dispenser motor is controlled through a MOSFET on a small expansion board I mounted on the bot's mine warfare platform.
For user input I have a 5-way navigation switch like that on the
AVR Butterfly, 3 simple pushbuttons and a 4-position dip switch. One
of the pushbuttons shares the input of one of the dip switches
positions because I ran out of inputs. All of the outputs from these
except for one pushbutton (which I use as the start switch) are fed
into a CD4067 16-1 analog multiplexer along with the digital outputs
from the mine sensor array. The output from the multiplexer goes into
1/4 of an LM339 quad comparator and compared against a 10k
potentiometer set up as a voltage divider. I did this just in case I
wanted to hook up sensors that don't necessarily exceed the CMOS
voltage thresholds for logic "1" and "0."
The other 3 comparators have a potentiometer each on the "+" pins and each of the "-" pins are hooked up to a 3 pin expansion port (each with power and ground). The outputs of these three comparators connect to the three external interrupt pins on the microcontroller. I will use the mega32's built-in pullup resistors. One of these is used to read an ORed output from the sensors that detect if a mine flag has been dropped and the other two are for "bumper feelers" to detect if the left or right front corners are crunching into something.
For output I have a 16x2 character LCD display using a serial-LCD converter chip attached to the TX pin on the mega32. The LCD was a MONSTROUS help in the software development and testing. I also have a pair of LEDs on two of the mega32 pins. I *NEVER* build a microcontroller project without at least one LED to aid in initial debugging.
I have two other expansion ports set up each with power, ground and two mega32 I/O pins. One just uses generic I/O ports and the other is hooked up to the two-wire interface. I added this in case I wanted to add an I^2C network in the future. Turns out, I ended up using it right away to interface to a Devantech digital compass. The other expansion port has a pin running to the mine warfare platform's expansion board.
Mine detection is handled through six 38khz sensors arranged in a row on the front of the 'bot. I mounted them far out and up enough to detect a mine but (hopefully) not trip it no matter which direction the 'bot approaches from. I use 6 because I understand the mine LEDs shine upwards in a fairly narrow cone and I wanted to make sure there were no "dead zones" between my sensors.
Building and field edge detection is through an array of 4 Sharp GP2D120 range senors, one on each side. I was originally going to use 8 sensors (4 short and 4 long range) and multiplex between them but I found the circuitry I was going to use to control the power introduced a HUGE amount of noise on the ADC channels so I ditched the lone range sensors.
I am using pennies as mine markers. The bot has three mine flag
dispensers out the front (hereafter referred to as MFDs). I use three
to make it more likely an MFD "business end" is close enough to the
mine to score and not have to require moving the 'bot to get it there.
The dispenser itself is just a wire coil in a tube hooked up to a Solarbotics GM2 motor. When a
marker needs to be dropped the gearmotor will spin for one revolution
and drop the penny in the same manner as a coin-operated snack
dispenser. An optical interrupt sensor will stop the motor once it
sees a penny go past. I am using pennies because they are already
made, dense, durable and cheap. If I were to do this again I think I
would have liked to use Solarbotics' GM14 motor instead of the GM2.
The GM is just the right speed and is good quality but is quite heavy.
Turned out weight was a big issue as during the event it got stuck
in the soft terrain.
To pick up the cluster bombs I will have a metal bar on the back and the front of the bot. This has proven to be a significant design problem. The bar has to be massive enough to easily attract the UXBs but at the same time not too massive to weigh the bot down too much. I want the UXBs to snap up onto the bar without facing down where they might get scraped off by an obstacle. I found there was very little tolerance between a bar high enough to pass over the cluster bomb but is still low enough to pick it up.
The software is the most complex part. Getting the bonus points for picking up all the cluster bombs and/or marking all the mines will likely be enough victory points clinch a win. The city field is the most difficult as writing an algorithm that will traverse the entire field but not knock over any buildings is proving challenging. The desert arena is a little easier as a simple zig-zag pattern with some basic mine marking and avoidance should be sufficient. Being able to stay parallel to an edge should help keep it straight when traversing the obstacles.
This is the most complex electronics project I have yet undertaken.
Progress log:
Mon April 19, 2004
I decided to start keeping a log of my progress. At this point I have
the hull structure complete with motors mounted and wheels attached.
The circuit board design is pretty much complete and I checked all
of the traces. I laid out the majority of the components through
a full-sized printout into a piece of conductive foam. I always do
this if I can. It's amazing how useful this step is in identifying
parts that won't fit. I use discarded parts that are the
same size if I have any to prevent any static discharges from ruining
the parts I am planning on using.
I could etch the board tonight but, by tradition, I usually sleep on it and do the board the following day. There always seems to be a change I need to make that comes apparent after a good snooze.
Tue April 20, 2004
Yup, a sleep showed a few changes I wanted to make. I etched the board and soldered in components for power and just enough bits to be able to install the processor and program it. ALAS! Something is wrong! I can get at the processor only occasionally. A check of the power showed the voltage was about 4.5 volts and the circuit was only drawing 10 mA. It would stay that way until a random period of time when the power would pop up to 5 volts and I could program the processor. Dang, power debugging time!
By the way, here is an example of the kind of quality in printed
circuit board someone can achieve in their basement. Not bad, eh? It
might look slightly lumpy here but this photo is highly enlarged and
the PCB looks quite smooth to the naked eye. This picture was taken
with my macro flash held behind the circuit board. Photos take from
the front didn't do a very good job of revealing how the PCB came out.
Thu April 22
FIGURED IT OUT! After replacing the power switches, regulators and whatnot I found it was that I needed a capacitor on the 5 volt side of the regulator. The processor wasn't "starting." As soon as I added the .1uf bypass cap by the processor it would start every time after a power cycle and getting reset. I am guessing it was oscillating and that was somehow affecting my measurement of the power. So, more proof of the value of bypass capacitors. My design included them but I just hadn't added them when I started my first tests. I won't make that mistake again.
Fri April 23
More board stuffing and testing as I added components. That was when I encountered another mysterious problem. My mainboard has two LEDs. I wanted to light one but found it wouldn't. The processor seemed to be ignoring my attempts to change the state of the pin it was attached to! Turns out that particular pin was used for the JTAG interface and it was enabled by default overriding anything I wanted to do with that pin. I could turn off JTAG either with a fuse setting or by doing this in my code:
sbi(MCUCSR, JTD); // turn off the jtag devices sbi(MCUCSR, JTD); // gotta do it twice
Sat April 24
Board has all components installed now. As always, when the board is populated I find there are booboos I made and things I want to change. The most embarrassing one is I *totally* forgot to add pullup resistors to the switch inputs! I also forgot to add a track to run ground to the secondary voltage regulator. A couple SIP package resistor arrays and some wires on the bottom of the board later and I am in business. I document all of the changes I want to make and mistakes I found. I want to build at least one more of these boards to control other projects and the improvements are worth making for the second one.
Now it was time to change the AVR "fuses" to use a 16 meg crystal. BUMMER! I somehow screwed it up and I can't use SPI to program the CPU any more! UGH! I have a single spare and I installed it so I could keep working. I decide to stick with the default 1 MHz internal RC oscillator for now so as not to risk screwing up my only spare. This decision would later loop around and bite me in the ass. I also decided to bite the bullet and get the Atmel STK500 development kit so I can fix CPUs that I hose like this. I also ordered another couple of atmega32s giving me four total. I have lots and lots of AVRs now!
Time to wire up and test the LCD. Yet another problem. The LCD works but I am getting gibberish on my display. I hook up the output to another serial driven LCD and get the same thing so it's probably not the LCD interface circuit. Last time I saw this was when I found the internal RC oscillator didn't give me USART timing that was compatible with the LCD driver chip I was using. Because I didn't dare set the fuses at the risk of losing the ability to work on this for the rest of the weekend I dug up the manual and tried fiddling with AVR's internal oscillator calibration system. SUCCESS! It was a very annoying and tedious process looping through calibration values. However, having the LEDs and buttons working on the mainboard allowed me to write testing software and keep hitting buttons until the display didn't show gibberish and I could then print out the OSCCAL value that worked (218). I found that any value of 213 to 223 would work so I picked the one in the middle in the hopes that it would give me the most reliable serial communications. I also had to fiddle with the USART "double speed" setting and UBRR register values to get something that worked reliably.
Sun April 25, 2004
Now that the mainboard is all stuffed I got down to wiring up the motors, batteries and putting it all together. I had lots of life maintenance to do so all I was able to get done was final chassis assembly. I did take some time to give the hull three coats of varathane to help it resist dirt and moisture.
Mon April 26, 2004.
I finally got this bot motivated. To test the motor control and differential drive I adapted the joystick controller I used to test my omnidirectional robot. I had a great time driving it around after my cat who was not at all impressed. I was pleased at how well it is able to traverse obstacles although because the wheels stick out the front a little if the bot encounters an immovable object it will attempt to climb it and eventually flip over and possibly damage the LCD and power switch. Hopefully once all the sensors are in place it won't do that. I wanted to have the bulk of the programming completed and my minesweeper able to detect and flag mines by the end of April. Only four more evenings left in my schedule to design and build the dispensers and mine detectors! UGH! Where does the time go?
Tue April 27, 2004.
The STK500 arrived along with some spare ATMEGA32s. I reset the fuses on the one I hosed and tried setting the correct fuses on the one in my bot. DOH! Still doesn't work! The microcontroller appears to be ok but still no go. I tried putting an 8 meg crystal in instead and it works.
The crystal I wanted to use is a 16.000 megahertz crystal designed for 20pf load caps. I put in 18pf caps as I figger the traces and whatnot will add up to 20pf. No go. I went the other way and tried 22pf and 15pf caps but no go for them either. So, back to an 8 meg crystal. I reset the timers and whatnot for 8 megahertz and everything was working again as I expected. The baud rate settings for the LCD worked right off the bat. Crystals rock.
For dealing in real time I wanted the processor to interrupt itself every millisecond. I decided to use timer 2 to do that. Timer 2's PWM pin is hooked up to H-bridge #3's enable pin which powers one of the mine flag dispensers. This is ok because since I am using timer 2 internally I can use this pin for on/off output and the dispensers don't need PWM control.
H-bridge number 2 is for another dispenser and the last two H-bridges control the motors using the two 16 bit timers with both channels set to produce 8 bit PWM. The center dispenser is controlled through the second expansion port. It means the center dispenser is slower because the power for the motor comes from the secondary 5 volt supply but that's ok. It doesn't need to change speed or even reverse direction.
As the marker falls out of a dispenser it will pass through an optical interrupt sensor. The outputs are ORed together with a 4001 quad NOR chip on the expansion board. I didn't have any ORs in stock but we all know any logic circuit can be built with enough NORS (or NANDS). Because I know only one dispenser will be active at a time I can get away with doing that.
Wed April 27, 2004.
I've been finding that dealing with the ADC is proving problematic. My interrupt handler for the ADC would start the next conversion for the next AD channel. However, that seemed to be too close together. Values from one conversion would seem to spill over to the adjacent channel. The documentation appears to say that you should just be able to multiplex the channels one right after another but not from what I am seeing. I am considering that in the future I might go with a dedicated ADC chip and say phooey on the on-board ADC or, at least, try to get a better understanding of how it works. I was willing to sacrifice all those I/O pins because I was worried that adding my own multiplexing circuitry would add noise. I really hope this won't prove to be a huge problem. Those ADC channels are used to detect buildings and the edge of the playing field. It's vital to navigation!
Saturday and Sunday May 1 and 2, 2004.
Lots and lots of progress this weekend. I managed to catch up a little although I am still at least a week behind.
I have the Mine Warfare Platform for the sensors and flag dispensers all built. Two of the dispensers are complete and the third is almost ready. I found that a xx brad point bit and an yy Forstner drill bits were just perfect to make the holder for the spring that holds and drops the markers. I countersunk a hole with the Forstner bit and drilled through with the xx bit and got this. With some epoxy and cutting around the edge I got a great spring holder that fits very snugly over the motor shaft. During my tests running the dispenser motors would cause funny characters to appear on the LCD display. Putting some .1 uf caps on the motor solved that one. I've been adding caps like that to my R/C motors for over a decade but this is the first time I have actually had hard evidence that it makes a difference.
I ran into some apparent input problems. The up and right actions on the navigation switch appeared to have a bad connection. I tried replacing every part between my finger and the comparator but it turns out what it was is that the CD4067 analog switch is SLOW!! The datasheet says it takes at least 325 nanoseconds before the output is ready after applying the address. In my code I was trying to read it right after that and at 8 MHz that's only 125 nanoseconds later! That also doesn't take into account the time the signal takes to propagate through the voltage comparator. Of course, it worked until I bumped the clock up to 8 MHz.
So, after setting the address on the analog switch I do a 20 loop of NOPS to delay and then read the value. Problem solved. This particular problem was a PAIN to figure out and cost me a full half day of work and one of my apparently perfectly good navigation switches which was ruined when I desoldered it to put in a new one. It's also the very first time I ever ran into this sort of timing problem. I checked the datasheets for all the other chips and parts just in case! <> So, the problems I was having with my crystals earlier have really slowed me down as, besides the time wasted trying to get the crystals to work, I blew all that time calibrating the RC timer for the LCD and then this issues with the analog switch. Grumble, grumble. On the up side I got some very good practice lifting surface mount pins using a soldering iron and a stainless steel razor blade.
So, at this time the hardware is nearly complete. I just need to finish off the last flag dispenser, wire up the sensors that detect a flag has been dropped and mount the mine sensors.
I think for the second controller board like this I make I will add a pullup resistor to the LE pin on the latch and attach the MR to the processor reset. That way when the processor resets so will the latch and the motors won't come on.
Monday May 3, 2004.
A little more assembly happened today. I have circuit board to make for the mine detectors. I am also going to make a little circuit board for the platform handling all the mine gear.
Tuesday May 4, 2004.
More assembly. I etched the circuit boards for the mine and other sensors and started to attach them. DOH!!! My circuit design on the PCB had the wrong pinout for the pna4602 sensor. So, I have to cut some traces and solder in some wires for the mine sensors to fix it. Starting to get near the end of the constructions. I need to wire up a few more sensors, put transparent lids on the dispenser magazines, make some more mines for testing and do a few little things to finish it up. Of course, that still leaves the bulk of the sweeping software; no small task. I have the majority of the support software in for user interaction, reading sensors and whatnot so that's in pretty good shape.
Wednesday May 5, 2004.
Still more assembly. Fixed the polarity thing with the 38khz sensors and the whole assembly seems to detect mines. Started to wire up the interrupt sensors for the MFDs. That should be done by tomorrow. So, if all goes well, I should have every last bit of hardware completed by the weekend making the whole project three weeks late. *sigh* At least I should have a week to tweak the software. Of course, I still have to build another Art and Innovation entry (Rexinator) and complete my solar roller and race track for my grudge match with Dave H. from Solarbotics. At least I got my line follower done early!
Thursday May 6, 2004.
I decided not to use interrupts to handle turning off the motors on the MFDs. That's because in order to address the motor control latch I have to change the address lines which are also shared with the analog switch. If the address changes while the switch is being used to check the digital sensors then everything gets all screwed up. So, I added the interrupt sensors to the range of digital sensors to check and use the turnon/turnoff functions for them and pass that to the switch debounce routines to clean it up. Or, so I thought.
An interesting calculation I made was to determine if the penny that is being dropped by the MFD is going to be visible by the interrupt sensor long enough to get detected if the sensor software. Because I have it under the control of the debouncing algorithm that means the signal has to be held low for at least 40 milliseconds.
When it is going by the sensor it will have fallen an average of 10mm and and will be going about 441mm/second. The length of the penny where it goes by the sensor is about 14mm. So, it will take a less than 30 milliseconds to pass by the sensor. Uh oh. That's below my threshold. I think I will write a small program to measure the time the penny is actually being detected by the sensor to verify my calculations.
Yes, this seems silly to have bothered with this question but this could have been really hard to debug if the period the penny was visible to the sensor was shorter than I think! YUP! I was right, the penny as it passes through the sensor is visible for only 20- 24 milliseconds, too short for my debounce routine to catch it. It also means the math that I did above was crappy. I think that part hurts more. To fix it (the timing problem, not the math) I added special code in the timer interrupt routine to check for the mine flags going by the sensors.
All tolled, this bot has 19 sensors! If I were to do it again I think I would shorten the axles and with the reduction in width I could drop down to two MFDs and four or five mine sensors. However, that would mean it would require more passes (and longer time) to cover the playing field. I guess we'll see what happens when the games arrive.
One new thing I decided to add to the software was the ability to keep an event log that I can access with the user interface menu. I will keep it in RAM for now and it can hold 250 entries. That should really come in handy for the debugging.
Monday May 11, 2004.
Long time between updates. My bot is still totally not done and with the games so close panic mode has officially settled in. My documentation tends to suffer when I panic.
All the mine sensors are attached. I found that their angle of sensitivity was too wide for my purposes so I enclosed them in a housing with holes drilled to admit the signal from the mines. I have four different lids for the enclosures with holes ranging from two to seven millimeters and they are very easy to swap in and out. I will select the best one to use on game day. I found that reflections from the underside of the bot to the ground would give me false positives on several of the adjacent sensors. Painting the front and underside of the bot and mine warfare platform with Testor's flat black enamel worked great. So, at this time my mine sensors are accurate and reliable. Good deal.
However, all is not rosy in climber's minesweeping land. The analog to digital conversion is still causing me grief. I just can't get a steady reading from the range sensors. I have added every noise reducing thing I could think of but the range sensor readings still flop all over the place. It totally bites. Still pondering how I am going to fix that one.
Since the range sensors are bad I decided I needed to add some secondary navigation and broke out my Devantech CMPS03 digital compass. I used some code I found on www.bdmicro.com that was written for the AVR in avr-libc using the two wire interface. Worked right off the bat. Sweet. The compass is SUPER sensitive to ferrous metals and magnetic fields around it so getting an accurate reading is going to be hard. However, I don't need to know where north is, I just need to keep my bot aligned with the playing field. So, when the bot is turned on it takes a reading and sets that to "north." I just have to place the bot on the starting platform so that it is initially aligned with the rest of the playing field and then fire it up. So, hopefully, if I can get a reliable 90 degree orientation on my bot then I only really need the forward range sensor used to keep it from smacking into the sides and buildings.
I am soooooo glad I wired in a provision for the I^2C (two-wire) interface.
I think in the future I will add a stabilized platform on to the bot to keep the compass and whatnot level. The adxl series of accelerometers from Analog devices look interesting. I could also use that platform for a system to use beacons to navigate. I also think the E2XB magnetic compass might be a better choice in the future (if I somehow manage to map my itty-bitty brain around it's documentation. YEEEIKES!).
Wednesday May 12, 2004.
Wow, progress. Got the ADC figured out. My circuitry that switches the range sensor banks totally screwed it all up. That plus the resistor in the low-pass "filter" added noise! Grrrrr. I decided to say "phooey" on the long range sensors and will depend on just the four GP2D120 4-30cm sensors instead. My bot is now "down" to 16 sensors.
The hardware is all done. IT'S ABOUT FREAKING TIME!!!! WHEW! Two more development days to go. I got a lot of the software done today. The compass is neat. I just wish it wasn't so sensitive to the ambient magnetic fields. The bot started to wander when it went by the fridge looking for the cat, for example. Hopefully the magnetic fields at the games are relatively even.
It was neat taking it outside and letting it drive around the pavement in front of my house. It does a great job of keeping it's course or getting back on to course if I pick it and move it.
Before bed today I got the bot to stop at a mine and drop a flag from the right dispenser. Way cool. The rest of the software development will be around navigating the minefields. At least (with an even magnetic field from earth) the bot will hold a course. I also have it so if it wants to change directions it will do so automatically. Neat.
Well, those 800 mah nicads are too dang small. During development I have to charge them twice a day. This bot eats power. I can't be bothered to take it apart to measure the draw but I would put it around 400 ma. At least the voltage regulators don't want to heat up that much.
The bot is also just TOO DANG fast. It tends to steamroll the mines before coming to a stop and I would guess the word "steamroll" is not a good word to use in the mine clearing business.. Gonna have to both slow it down a little and add some code to reverse direction for a bit. Alas, my design leaves little space from the sensors to the bar that picks up the UXBs. Also, it wasn't until THIS VERY FREAKIN NANOSECOND that it occurred to me that if there are UXBs stuck on my pickup bar they could trigger a mine before the bot rolls to a stop. *sigh* Hope this won't mean more annoying hardware changes.
One thing for sure is I think this will be the very last bot I make to not have encoders to measure wheel RPM. A speed that makes it possible to turn well on carpet is like greased lightning on lino and we get that annoying "mine steamrolling" affect again.
I re-used a huge chunk of code from my line follower (in fact, so far, about 1/3 of the code in my minesweeper is common or very similar to code from my previous bot). HOLY CRAP does the LCD make debugging easier. This project would take AT LEAST 10 times as long for software development without it. From now on, if it will fit, ALL of my bots will have an alphanumeric display of some form (preferably LCD).
Fri May 14, 2004.
With the pre-game panic updates to my blog fell by the wayside.
Came across a very strange problem. While testing my navigation the bot would run for 45 seconds or so and sort of die off. Turns out that when I upped my clock speed above 1 MHz I forgot to increase the pre-scale on the PWM timers. This meant that the PWM frequency to the propulsion motors was about 32 kHz. That's WAY too high for the SN754410 H-bridge. I think it was overheating and doing the thermal shutdown thing. When I increased the prescale the PWM frequency came down to just over 4 kHz and it started running like a champ.
One thing I added was a way for the user to calibrate directions. Although I already made an automatic "north" calibration I added a way to enter directions for east, west and south. I just need to rotate the bot, select the right menu on the LCD and hit a button. My bot can tolerate a good 20 degree variance in the actual direction. All I need to do is know where north, east and west sort of are to an accuracy that will have the bot heading sort of in the right direction.
At home, I was extremely pleased with how well it navigated. I set up a play area on my big work table with 2x4 perimeter and my mines. I programmed a little zig zag course and it handled it very well. I took it outside to let it play in the dirt. The stuff in my yard was well-packed and not nearly as soft as the sand I expect to see at the games. But I don't have any sand to try out so ON TO THE GAMES!
Quentin came over thursday night to help out with the media bots. While he was there he pointed out that some new Canadian pennies are attracted by magnets. So, I carefully selected my pennies so that my flags wouldn't get picked up by the UXBs the bot has collected. Nice one, dude.
Sun May 14, 2004.
Well, the games are over. While it didn't catch fire the minesweeper event showed me a major flaw in my design. The floor of the Heart building we were competing in appears to have major amounts of ferrous metals. That rendered the the magnetic compass completely useless. BUMMER!
However, my butt got pulled out of the fire when I learned there was more than one round in the competition. So, I sat down, deleted the compass navigation and just added a sort of dead reconning system and "drive by braille" and careful aiming by my bot at the beginning. The panic-mode programming was just like being back in University when the projects were due! Amazingly, I was able to get a good enough score to place third! The two mines it found before it got mired were very well flagged.
I can't believe how much I learned about electronics during the development and deployment of this bot. Timing, noise, design, programming. Wow. That alone was worth the price of admission to the games.
For next time, assuming there is one, I plan to make several changes. First, I want to make the bot a little narrower. I will reduce the length of the axles to the wheels and make the mine flagging platform narrower. I want to also switch from GM2s for the flaggers to GM14s. I made that decision after the very first attempt to navigate the city arena during the games. DOH! In my programming panic I didn't look in the bag of stuff competitors get and didn't make use of the one-day Solarbotics coupon.
My bot totally bottomed out in the soft terrain. I think I will have to do something about the propulsion. I will either add a third set of wheels or perhaps go to a tracked system. I am out of Copal 60:1 gearmotors and getting more might be problematic. Hopefully I won't have to buy a whole new system of motors. I also want to reduce the weight of the bot to make it a little less prone to sinking into the soft terrain.
For sure, I am going to add encoding to the motors. Also, I am going to switch to a new method of navigation. The compass just can't be relied upon. For sure, a piezo-electric gyroscope is going to get added. I also think I will add a secondary processor (probably a tiny26) who's whole job is to handle the motor control and encoding and communicate with it using a I^2C network.
WHEW! It's over til next time.
Last modified: Oct 23, 2006. Does this work?