Wed Aug 11, 2004
I decided to do a little work on the bot over the summer but at a VASTLY reduced pace! With my new digital camera I can document the process more effectively.
I snagged an Analog Devices rate sensor. I am going to install it to measure rate of angular motion (i.e. how fast the bot is turning) and ditch the magnetic compass. The rate sensor (which is, really, a piezo electric gyroscope like that used on remote control helicopters) will keep the bot on course most of the time. I will install a beacon in the finish area right along one edge. Whenever the bot nears the edge it will use the beacon to recalibrate which direction it thinks it is pointing in.
I've decided to add another set of wheels instead of switching to tracks. Although that means having six sets of encoders to measure wheel RPM I remembered that I am not very good with the mechanical part of robotics. I've calculated that with the extra wheels and some weight reduction I can decrease the ground pressure by about 46 percent. That should easily keep the bot from sinking especially since the formulation of the soft terrain is likely to change to just sand.
Being able to measure the speed of the wheels is going to have a huge impact on the performance. This will enable the bot to deal MUCH better with different surfaces without me having to program in special propulsion profiles for different types of terrain.
I snagged some GM14s from Solarbotics and will switch to those for the MFDs instead of the GM1s. That should save quite a lot of space and weight. I am also going to completely redesign the mine warfare platform.
During the PCB design I debated whether or not to go with a mega128 instead of the mega32. Back then, I figgered the board design was too far along to make the switch. With perfect hindsight I realize that I could have saved a lot of time by making the switch. I added multiplexors and addressable latches to fulfill my need for more I/O pins. Looking back I have only one question for myself:
WHAT THE HELL WAS I THINKING?!?!?!?!
Clearly, when I designed this I had not learned the true Zen of microcontrollers. The board would have been so much simpler and easier to program with the larger microcontroller. I think this is something that everyone who gets into these devices will figure out sooner or later.
Mon March 28, 2005
Well, time to get back at it!
I decided to design and build a new bot and motherboard from the ground up. For the processor I went with a mega64. I did away with serial-based LCD controller and hooked the display up directly to the processor (gotta love having lots of I/O pins), use two SN754410 dual h-bridges like before, same dual power, same lm339 comparator with 4 inputs, same config for the ADC, etc.
Here is the PCB for the motherboard. The left side is the top and the right is the bottom. Blue is ground and red is regulated +5 from the primary regulator. Click on the image for a BIG view.
Here is the daughterboard that fits right above the processor and holds the connector the peripherals and the circuitry for the ADXRS300 angular rate sensor. Again, click on it for the big view.
These PCBs are my first real double sides boards I have made at home. While it doesn't have plated thru holes the experience went better than I had expected.
On of the biggest differences, besides the processor and LCD, is that external devices are now on a different power circuit than the microcontroller. It's mostly by itself now.
The reason I did this is that during many diabolical experiments with the ADC for the last of a 3 part series on AVR microntroller programming seminars I put on for the WCRS I found that even the presence of noisy devices like the Sharp infrared range finders really screwed up the ADC. Even if I wasn't actually measuring the range finders the mere presence of them on the same power bus added mega noise to the readings. This, I am sure, is what was hosing my range finders last year.
I also made the servo headers and I2C network powered on a different circuit. I hope this will deal a death blow to noise when using the ADC and make the range finders useful again.
Another big change is ditching the magnetic compass. I am going to use intertial navigation with an Analog Devices ADXR300 angular rate sensor (i.e. a gyro). With this baby I can determine how fast I am turning and if I know how fast I am turning and how long I have been doing it then I know which direction I am facing. To deal with the expected cumulative error each time the bot zags to one side of the area it will turn to face a beacon I have placed on the exit zone. When looking straight at it I can then reset the direction heading for the next pass.
The bot is also going to get much lighter to cut down on the ground pressure. I am still debating over adding an third set of wheels. I might make them non-driven to save weight and power but still reduce the ground pressure.
The new motherboard is a few millimeters wider than the old one meaning I had to do some major mods to the chassis. That's ok. I am also going to use a lithium polymer battery pack to cut back on the weight. For safety, I've designed in a voltage detection circuit. It will measure the voltage and signal the processor when the battery (2 cell) gets down to 6 volts. The processor will drop down to low power mode and cut off power to the motors and peripherals after writing a battery low mesasge to the LCD. This way if I accidentaly leave the power on overnight the odds are good the battery won't be dead when I next work on the bot. If a lithium polymer battery gets run down it will never take another charge.
Right now the motherboard is all etched and I've started stuffing it. I put on power first and after testing it I added the ISP, the processor and whatever it needs to go. I had trouble programming it until taking a closer look at the manual I found out that the pins labeled MISO and MOSI on the pin configuration are not the MISO and MOSI pins needed when programming the chip! Grrrrrrr. RTFM. After a quick little but of PCB surgery it now takes a program download without problem.
This time the very first thing I did was program the fuses to use the 16 MHz resonator. That went without a hitch. Well, almost. The stupid resonator only actually runs at 15.9 MHz. Accuracy-wise that is pathetic. Because having accurate time is so important to navigation and the wheel encoders I will have to adjust the timebase in software. This definitely marks the very last time I buy a resonator. Once this batch is used up it is crystals or death! No, death is too harsh. How about: Crystals or go drink beer! Yeah, that's the ticket.
I am reusing the 5-way navigation switch that I used on the last sweeper. I just love these things. It rocks for user input. I also have 4 ultra-bright surface mount LEDs and two auxilliary buttons. I did away with the dip switch. I will use a menu for the LCD instead for such settings.
I am so looking forward to getting to use the encoders on the wheels. All four are going to be hooked up to interrupt pins on the processor through an analog comparator. Whenever the pin goes from a high to a low the interrupt pin will measure the time since the last routine was called and use that to measure the wheel RPM. The handler will then adjust the wheel's PWM cycle to match the RPM desired by the processor. This will greatly aid in controlling the bot as I then don't have to have arbitrary speed settings to deal with turn rates on different surfaces. In the city sweep this wasn't a big deal as the surface was quite consistent with the exception of possibly driving over an unexploded cluster bomb.
However, in the desert the surface was quite variable ranging from high friction astroturf to boggy sang and little foam pellets (which I understand are going away for 2005). Clearly, wheel encoders are a must. If the purpose of the contest is to improve a roboticist's skill then this one is doing it for me in spades!
I intend to keep the mine sweeping algorithms the same. During testing in my basement the technique worked wonderfully and I see no reason to change it.
The angular rate sensor is going to be carefully handled. I want as much accuracy as possible. The output of the sensor produces a differential voltage. The faster the turn the higher or lower the voltage. I am going to measure it using a I2C-based 16 bit ADC I snagged. It will sample the voltage as fast as it can. The processor will ask for a sample 25 times a second. I am hoping these measures will allow me to get an accurate reading whenever I ask for one. The processor is large enough in that, if necessary, I can add a Kalman filter to the software to clean up the signal from the rate sensor if need be.
I am ahead of schedule at the moment. I plan to have all of the hardware for this bot completely done before April 12 leaving programming the only development to be done before the games. I am also planning to build a much faster line follower and need to get that done too. However, it's priority isn't as high. My other line follower, Gunnagitcha, still works pretty well and, I suspect, is still quite competitive. It's the minesweeper that needs the big work.
I just have to think about what to do around the motors and drive train. Do I want to think about switching to a tracked design? There's a lot going for it. Lower ground pressure and only one motor and encoder per side. The down: can throw a track and is much more complex mechanically. Some of the tank toys that I have are equipped with excellent track mechanisms but are either too large or too small for the sweeper. I have the Tamiya tank track kit but it's debatable if I could make it mechanically reliable enough for the contest. The astroturf that's part of the desert field is very high friction and could drag a track off without too much trouble.
Wed April 6, 2005
The bot's coming along nicely. The board is getting well stuffed. I am pretty much down now to just adding headers for all of the connectors. The surface mount LEDs are so bright they are almost painful to look at and that's with just 10 mA!
I am really glad I provisioned "breadboard" type layout area on the board beneath the LCD display. I've already used it to add an LCD backlight control circuit. The backlight makes the display MUCH more readable in almost any lighting conditions but I wanted a way for the processor to turn it off to save power if the battery gets low.
Speaking of power usage I made another RTFM mistake. I should have paid more attention to the data sheets for the SN754410. I programmed in and measured the power drain while the bot was in "low power." mode. 80 MILLIAMPS! I don't think many bots after this are going to use the SN754410 as it appears that's what's eating most of the current. If I can find a good Canadian supplier I might switch to the Si9986 chip for future bots. It looks really nice. Besides being FREAKY small it can also do an amp but with a 200 KHz switching rate! It had only two I/O pins so if I want to make use of coast, brake and all other modes that I like to use with an H-bridge but without "stupid software tricks" I have to use megas equipped with timers that have two output pins each like the mega88 or mega64+.
Wed April 6, 2005
I've decided to try and reuse the mine warfare platform and chassis from sweeper1 since all that work was done. Last year the platform performed extremely well except for the navigation and ground pressure. Everything else was just skookum. The only problem is the new motherboard is 4mm wider than the old one. I've considered cutting the chassis in half lengthwise and splicing in some wood to make it wider (one of the many advantages of using wood as a building material). That might throw off the mounts for the mine platform so I will probably, instead, cut holes in the side of the chassis to fit bulges so the motherboard will fit. Right after that I will add mounts and axles for a third set of non-driven wheels to lower the ground pressure.
Sun April 10, 2005
Things are coming along very nicely. The new motherboard has been mounted into the reburbished chassis. I am also very pleased with my decision to switch from GM2 gearmotor to the GM14 for the mine flag dispensers. Besides dropping a lot of weight it also means I can make the mine warfare platform much smaller saving even more weight and making the access to the motherboard even easier.
I found these really nice R/C car suspension springs that I am going to use in the MFDs. Their coils are tighter together meaning the pennies are held more firmly and they won't jiggle around as much. I was worried that it might be possible for a penny to turn sideways and jam the mechanism before it has a chance to drop out. That hasn't happened yet but I thought it might be worth taking into consideration. I also intend to widen the drop slot ever so slightly. Last year I modified a stack of pennies by smearing on a thin layer of silicon caulk around their edges. This absorbed a great deal of the energy when the penny dropped and hit a hard surface. I found that the sweeper would drop the flag right on top of the mine. While I was extremely pleased with the accuracy (actually, I was ecstatic) it meant the flag could bounce off the top of the mine and roll far enough away to get negative points! I didn't use these modified pennies because they could jam themselves into the drop slot. Once that happened it was game over since the bot would never move from that spot and try to drop all the rest of the flags from that magazine. The MFD motors will be controlled with NPN transistors.
I am truly amazed at all of the little things that need considering for this contest!
I've fallen behind in my hardware. I wanted to have it all done by tomorrow but I don't think that will come to pass. However, I am confident I will get a good three weeks to develop and test the software.
Sun April 17, 2005
After having fiddle with wheels and encoders and ground pressure I thought I should try and put together a tracked base for this bot. Problem is finding a decent base that's the right size. I can't be bothered to try and fabricate everything myself so I quested for a kit or toy that could be adapted. I have two copies of the Tamiya tracked kit but I was really worried about it throwing a track. The astroturf part of the desert stage is very high friction.
I decided to try and use one of the Radio Shack "megatech" missile launchers as a platform. The base itself is too long to fit within the contest regulations. For a long I debated trying to make the chassis shorter and this last weekend I decided to go for it.
Once I had stripped the chassis of wheels and other stuff and covered up the motors and gearboxes to protect them from dust and debris I went medieval on this sucker and cut 4.5cm out of the center using my manual compound miter saw. I also removed the battery compartment and glued the battery hatch on to give it, more or less, a flat bottom on the inside. After treating the edges with some sandpaper glued it together with medium CA and clamped it over night. After coming out of the clamps I reinforced the joint with strips of unidirectional carbon fibre. After deal with the bits of plastic that protrude from the ends the overal reduction in length came to about 6 cm. Beauty. That, however, was the easy part.
The tough part is the tracks. They are molded out of a solid rubber compound. I was worried about how to cut out a section and splice them together. In the end I cut a piece out using my "chopper" which is a sort of rasor-blade guillotine I use for making mitre joints out of pieces of balsa for my airplanes. It worked *fabulously*. The edges were smooth, clean and, most importantly, square. After roughing them up with sandpaper I glued them together with regular epoxy and clamped them overnight. The first track was too loose but the second is just about perfect. I will redo the first track by removing one link monday night.
I plan to install a large wooden platform over the top to mount everything too. The interior is too narrow to accomodate my motherboard so I will have to mount it over the top of the tracks. This doesn't bother me as I had planned to at least install fenders to prevent the tracks from throwing debris into the interior.
So far it looks really good. The only issue I can see is that the new platform will be 6-7cm longer than last year's. This could cause could me trouble in the city arena. However, that doesn't concern me overmuch. The majority of the contest points is in the desert arena. All I need is a positive score in the city arena to move on.
The next big challenge for the chassis is to figure out to add an encoder. Currently, my line of thought is to paint the links with alternating back and white stripes and use a reflective surface sensor. The trouble is that it is too granular. The chassis moves too far between each on-off sensor cycle meaning the RPM adjustments might take too long to do any good.
I have been toying with the idea of measuring the motor's back EMF to determine it's RPM. When the PWM cycle goes to off the motor becomes a generator. My measuring the voltage at that instant and knowing the motor's RPM/volt constant I should be able to determine the rpm. I could have an interrupt routing that when each PWM channel get a compare match I could check the voltage using one of the ADC channels. However, I don't know if I will have enough time to develop this technology before the games.
Thu May 19, 2005
Game day has come and gone. My minesweeper took 2nd place this year. The winner was Tom Grey. Way to go, Tom!
It seems like each year I solve one major problem. Last year I had the mine detection and flagging very much figured out and that part worked easily as well this year. The only change I made was to have a timeout for mine flag drop detection. If the dispenser jams the software will detect that, logically disable it, move the bot and use another.
The problem I solved this year was navigation. The Analog Devices ADXRS300 angular rate sensor (i.e. a gyro) worked fabulously. During trials in the morning the bot navigated a near perfect search pattern and the bot ended up square in the finishing area. I still had the compass installed but I didn't even use it once. I also didn't need to use my calibration beacon. My software controlling the gyro was able to keep a near true heading for the entire 2 minutes or so it took to run the course.
However, one big problem remained from last year: my bot's traction sucks.
Even with the 30% weight reduction and a third set of fully powered drive wheels it still got bogged down. When going straight it had no problem but when turning it could bog down. I can't raise the bot and still be able to pick up UXBs. So, on to tracks it is!
The problem is finding good tracks. I have abandoned trying to use the Megatech launcher platform since it is simply too big. So, what I am going to do is try the Tamiya track set but fuse two sets together to make double wide tracks. I figure the new tracks will further reduce the ground pressure by a good 50%. I don't think the Tamiya tracks are as likely to stay on the wheels as well as the megatech (which are VERY robust) but it's worth a try.
One other problem I encountered was the foward range finder was getting blinded by something. I use the range finder to detect the buildings and walls and know when to turn. On the city arena there was something that fooled the range finder into thinking there was something very close even when there wasn't anything nearby. I was extremely lucky in that the starting position was such that I could do the course without encountering that problem.
In the desert the range finder was getting fooled by a mound of sand someone built up. Either that or the spotlights they were using was messing up the sensor. In either case I am going to raise the range finder to a height of 70mm and move it back so that the max range (4 cm) is two cm beyond the perimeter of the bot. I will also increase the value the reading is compared against to help it from getting fooled by interferance. I am also going to add another sensor to the front so that I can better deal with the buildings when the bot hits the building with the fender. Finally, I am going to cut back the mine warfare platform even more so it will be easier to maneuver.
Going to a tracked chassis has two other benefits. First, I can reduce the number of motors from six to just two. This frees up I/O pins and also means I don't need multiple encoders for measuring wheel RPM. I prefer to use an interrupt-basd system for reading the wheel encoder. When the signal goes from low to high an interrupt will be called and a timestamp taken. It prevents wasting processor time that polling does. I only have 4 such I/O pins set up so going to tracks solves this.
Another advantage is that I can have the drive motors in the rear which will help balance the bot. The current version is nose heavy. When it turns it swivels on the two forward sets of wheels forcing the back end to swing out wildly. Not good on a minefield!
Now that I think about it, since the compass is no longer needed I can switch to using a magnetized UXB pickup bar instead of just a regular steel one. This can mean I can raise the bar and th ground clearance up a little.
I am extremely happy with the software that drives the whole thing. During tests and assuming the system that handles navigation is working properly the bot does an excellent job of traversing the course, flagging mines and driving around them. There were very few changes I needed this year and I see no need for a rewrite. There are, however, a few enhancements going in.
The biggest one is I am going to add a Kalman filter to the system that controls the angular rate sensor. I have been studying Kalman filters and, so far, they the descriptions have made very little sense to me. I am a programmer, not a mathematician. However, I found this very nice page that describes a one dimensional filter with source code that might be just what I need. All of the other examples and explanations on the net assume the reader has far more math under their belts than I (I only took 9 university math courses for my comp sci. degree >:-).
I am also going to make better use of the facilities onboard the rate sensor such as the temperature sensor to try and get a better idea of the sensor's null value (i.e. the voltage that it sends out when it is not turning). I wish the designers of the rate sensors themselves would deal with such nonsense. They should have a pin that, when held low, would force the sensor to adjust the null value so that it matches the internal 2.5 volt reference exactly. Before the bot starts moving it would do this since it knows it is not turning and can calibrate the sensor.
This first iteration of my software does a pretty good job of keeping the true heading under motion for a couple of minutes. With good software and a better understanding of how it works that can get extended to much longer periods.
All this effort is important because I have been finding that under game conditions it is very difficult to get decent readings of anything from the surroundings. I am mean, damn, it's harsh. Magnetic compasses are useless. The range sensors are all screwed up. Heck, ALL optical sensors were seriously degraded by the spotlights and whatever else was out there. Of the four different navigation systems on my bot (range finders, angular rate sensor, magnetic compass and 56 kHz beacon in the termination zone) only the rate sensor proved to be reliable. All of these systems were 100% during testing indoors and out. I think my bot might find it easier going on a real minefield!
However, just like a real mine sweeper the bot has to deal with where
it is put. If the conditions are harsh I just have to make better
minesweeper! (and hope the conditions don't drive away competitors so the
event stays alive).
Last modified: Oct 23, 2006. STOP BUGGING ME