|Fred, Robot #2|
|Robot Home Page|
Here's Fred, my robot #2. He's good at wandering aimlessly around the house simply trying
to avoid getting stuck. He can typically go for a good hour
before having an encounter with
a chair or something. He always looks for the longest forward path and then heads in that
direction. If he encounters an object,
either by I/R distance sensors, by high motor amps
(indicating a stall) or by front distance not changing, he takes evasive action, then continues
Theoretically, carrying on will evolve into doing something useful, like bringing
a beer from the kitchen. He has advanced to performing dead reckoning navigation
on wheel encoder measurements. He can almost do a circuit around the house and arrive
where he started.
Thats a Tech Arts 68HC912B32 board, stacked with a memory card, at the back that is the main processor. I also have a 68HC11 doing RF packetizing which allows me to communicate with my PC. In the front is another 68HC11 set up as a slave I/O module to the 68HC12. This adds 8 analogs and 20 some discrete I/O points. Also in front is thePolaroid sonar unit (round black thing) that can sense distance from about 2' to 25'. Under the top board is a Sharp GP2D12 that can sense from 4" to 2'as an analog value - the two work together as a continuous measurement from 4" to 25'. The sensor right at the front is another GP2D12 aimed at a 45 degree angle downward used for stairs detection. I got tired of him trying to go down the stairs. This works very well. I get less false trips than I did with the basic I/R modules and can adjust the trip point.
The main motor control board is on the bottom level at the back. It uses two L293D H-bridge chips to control the two 12VDC gear head motors using PWM control signals. I sense motor current to each motor with a resister/op amp/schmidt trigger circuit - this was a tough one due to the extremely noisy signal resulting from the PWM control. Each wheel is run by a motor via a belt and pullies. On the wheel shaft is an encoder disk (100 slots/rev) that is read by an I/R sensor. The battery is a sealed lead acid 12V 2.3 ah camcorder battery. 5 volt power is provided by a switching regulator (National Simple Switcher) - this is efficient and helps reduce the noise from the motors. This is a better solution that separate supplies.
I also have a Dinsmore compass module (still in R&D) that hopefully will correct my dead reckoning rotational errors.
The robot plays a tune that changes depending on its mode (mood?). The happy, nothin' in my way tune is a random note selection based on Lucy Tuning thats sounds pretty good.
The robot is programmed in Imagecraft C. I decided last summer to make the great leap from the 68HC11 and SBasic to the 68HC12 and C. I really wasn't looking forward to learning C, but it really wasn't too bad. SBasic is a great, simplified programming language. It provides much of the power you will ever need and insulates you from some of the most difficult programming concepts, such as multiple variable types. But I wanted floating point math and the advantages of the different variable types. I'm very happy with the decision. C is easy to understand and has the power to do virtually anything the processor can do. I also like using standard ANSI C. I can test routines using a Borland compiler on my PC and can see doing simulations using my actual robot code. In addition, if I stick with C, much of my code will be reusable. And goodbye to Basics peeks and pokes and gosubs. Floating point math chews up memory and time, but so far its not a problem in my 32K code space on my 68HC12. Imagecraft has done a pretty good job with an ANSI C implementation. Their new compiler is $200 which is at the upper end of my budget, however.
The 68HC912B32 is definitely a nice machine. More I/O, simplified register structure, PWM, flash memory, at least 4 times the execution rate, nominal cost increase over a 68HC11. This is the ideal robot controller - I wouldn't start with a 68HC11. The new version with 60K flash, more I/O, more than one pulse accumulator (a good thing), CAN and I2C support, looks even better. I'm using a Technological Arts board along with a RAM expansion - to save my flash. I've programmed the flash at least 400 times so far but I started getting nervous. The RAM works OK but doesn't completely agree with Kevin Ross' BDM module - sort of works. The BDM board works great with flash. I plan to set the RAM board up as 32K RAM along with the flash - this will enable me to get MicroC/OS-II, a real time operating system, working. With all the things happening in the controller, I see linear program execution as being the next bottleneck. Anyway, that's my next project.
|Kevin Ross' BDM|