Grid Navigation
(June 2002-June 14, 2003)

sponsored by the Robotics Society of Southern California (RSSC). Rules Here

M1

June 6, 2002 Until about 8/1/02: Design of "Maze solver-1" (M1) 4" diameter wheels with 2 DC motors (gutted servos) with servo horn attaching 4" diameter wheels. Attached Hammamatsu encoders unto chasis and glued encoder pattern unto wheels. Very rugged design that would have been able to attack even the roughest carpets!

Dec. 15, 2002: Problem was encoders weren't reliable at 90 clicks. Under tests I knew it could also do better than 90 clicks (as high as 180)--so I set out to improve/fix the situation. I agonized about a week trying to get the encoders to work reliably with 180 clicks; then 120 clicks, then realized that the problem was basic to the Hamamatsu--even though under optimal conditions, I can get it to trigger at distances of 1.5-2 cm, but when encoding it only has a range of about 1-2 mm. Assuming you can mount the wheel in exactly the center of range, this gives you about 1 mm wobble max, which just isn't going to cut it with my 4" wheels mounted on servos at one point with a plastic harness. I see this as a drawback in using servos unless you have small wheels because you only have a small about 3mm piece of plastic to mount your wheel, rather than a metal rod that the wheel inserts into and clamps on. In the end, I concluded that the basic wheel design caused the problem. The previous robot had a 2" wheel with a metal axle (not plastic like servo). It also had a 1" flat rubber width; the flat surface tended to also help eliminate bending that is experienced on bicycle-like wheels--the weight of the robot tended to lean toward the inner surface of the wheel. Thus the older robot was able to eliminate almost all of the wobble; what wobble it did have was attributable to the metal axle being slightly bent which can be rebent if necessary. what it did have was a slight variation in distance in the wheel from the axle, but this was caused from not tightening the back nut down completely because it was hard to reach. Thus with much consternation, I decided to return to the old robot design. Yes, the one I had just torn down to built a faster, better one! Since both robots were circular 8", it wasn't too difficult to just unattach the upper platform from current robot and attach to the old lower platform of my older robot. PS: this is odd that you can get the encoders to trigger at 2cm stationary, but only 2-3 mm rotating.

Dec. 18, 2002: Redesigned new configuration with smaller more stable wheels--Maze solver-1 Design-2 (M1D2). Concurrently, I was investigating options for builtin encoded motors. After about a week of searching for options for a better encoder design, I finnaly opted for Some Pittman motor's. The drawback is they are 30 volt motors, but rumor has it they are still pretty good using 9-15 volts. Since I struggled with the original configuration of 3v DC motors with manual encoders. The wheels always had some tilt etc. rendering the encoders unreliable. After much searching, I found and ordered some decent surplus motors with built in encoders at Servo Systems. The motors are bigger than I envisioned using (30 volts), and it seems everything required modification around this. Unfortunately most encoded motors you can buy are pretty large. It was quite difficult to come up with a RPM and size that was satisfactory. I resolved that since most motors were over 6" I would have to gear it to fit within a reasoble size for contests.

Dec. 24, 2002: about a week designing a motor cradle for the Pittman motor's with excess gears from Jeff. Some of the construction is not "production" worthy; may need to redo later--wooden axle mount with tape to keep axle from drifting out of gear range. If mounted Side by side the robot would end up over 12" (probably 13-14) which is too big for most hobby contest.

Dec. 31, 2002: At the competition over near year's eve at Jeff's the old (M1D2) design suffered two problems:

1. the gears became unlocked to the wheel axle. This was fixable, but
2. when putting the wheels back on, the platform must have been slightly off position as now the encoders were not reliable.

Son of M1: M2

Jan 1, 2003: Maze solver-1 Design 3 (M1D3) consequently renamed Maze solver-2 (M2) as Jeff and I decided to change course and enter the RSSC's robot contest and put our maze contest on hold. Tested Pittman motors on new cradle. Both motors are running at about .22-.23 amps (9 volts). Even when putting 2-3 extra pounds on it, it seems to only run about .25-26 amps. Even at 9 volts it has good torque and about 12"/second. This is better current use than expected. Spend several days now looking at motor drivers. Since the new motors have a stall current of 5 amps, thus my preference would be a driver near this capaiblity. The choices come down to whether to buy or build myself, and in among these options are suboptions

1. L293 H-bridge: can be doubled to obtain 2 amp continuous (~3-4 amp spikes); probly insufficient.
2. L298 H-bridge: can be doubled to obtain 3.5-4 amps continuous (5-6 A. spikes)
3. 18200 H-bridge: cannot be doubled. 3 amp continuous about 4-5 spikes.

Jan. 2, 2003: Spent several days researching how to construct the motor driver as best as possible. calculated amps required at each location. Vmotor will use a terminal block (15 amp/14 AWG); Motor outputs will use .156" center headers (7 amp max/18AWG), and rest will use .1" headers (~2 amp/22AWG).

Jan. 6, 2003: Order connectors etc. from Digi-Key.

Jan. 15, 2003: Finished half H-bridge. validated the encoders on the motors worked (why didn't I do this earlier?). I'm getting about 38000 clicks per wheel revolution! This will be tricky to get the exact figure. This also caused me to redesign my software as it would overflow after only a few revolutions.

Jan. 19, 2003: Finished second H-bridge. Began construction on motor casing with H-bridge placement on casing. Ordered some casters.

Jan 20, 2003: Decided rather than extend the encoder A/B channel wires from the motor will plug into the H-bridge board and install and pass-through A/B encoder channel header to MRM.

Feb. 1, 2003: Have 5v direct, and 5v w/ 5K pullup power buses installed.

Feb 6, 2003: These motor controllers worked for a little while, but unfortunately shortly stopped working! In the end, building myself cost about $25-$35. With that much, I figured rather than rebuild I should be able to buy an acceptable controller. There were two final candidates, but my final choice was the New Micros controller which looked like a cleaner connector design and was not a Kit--after all if I blow out mine, why wouldn't I blow out theirs.

Feb 10,2003: Order the New Micros NMIH-0050 H-Bridge motor drivers. At about $29 each for the New Micros controller, it turns out about twice as much as a building my own would be anyways. My criteria was the following:

1. Obviously voltages around 40 volts and prefer Amps 5 or greater.
2. Price: hopefully under 100 for both.
3. No Kits is preferred!
4. No serial protocols unless the processor supports it (SPI). Some required serial to disable the serial (go figure!)
5. Size: a smaller footprint will allow a smaller robot design.

Now that I have the drive system; it was time to run power. Power is always an ugly topic in my book. How do you nicely run all those accessories and still be modular (not solder everything in). I ended up providing a long strip of header off of a 7805 regulator, but I still sometimes have trouble when connecting, the backside header pushes through and breaks the solder connection. I wish the headers required more force to push through! Another change that was required later in my design was switching from a 9.6v to run my 7805 to a 7.2 volts. I find that a 9.6 runs much over 10 volts fully charged and I'm generating a lot of unnecessary heat. Unfortunately, the only switched power supplies in the range I need at Digi-key require me to buy 30! Early on I provided what is probably overkill to the motor power supply--a voltage suppressor, a 5Amp resettable fuse, and a normal 6 amp fuse. Usually if you'll have a problem, it probably will just short out on the other side of your protection anyways--that's Murphy Law of course.

March 15, 2003: Ordered some parts for adding a keypad. This will be necessary to enter the waypoints in the contest as I have no intention of bringing a laptop to the contest. Among these was the EDE1144 from E-lab digital Engineering.

March-April 2003: Now that the drive is connect and running, it was time to add some sensors. Our game plan was to use cameras instead of bottom sensors to allow faster robots. The Gameboy camera is a real nice camera to use, but unfortunately its hard to get enough frames/second. For some reason I was unable to detect the horizonatal lines; I could follow the line in front of me, but not detect (reliably) the side paths. This required me to put in additional photoreflector on the side. About this time, I thought I burnt out my camera and opted for the traditional approach--6 Hammamatsu photoreflectors lined up on the bottom of the robot. After some initial sucesses with the Hammamatsu's, I discovered my camera WAS working after all. This divine intervention was just about exactly what I needed, because now I could leave the camera at a fairly low exposure to get a higher frame rate...when I got near the intersection when things got difficult for the camera, I now switch it off and use the belly sensors as a backup navigation algorithm (but at slower speed). Most of these months doing software as the hardware is finnally stabalizing.

April 14, 2003: I finally ordered another EDE1144 from RobotOz from Australia as I have received no word about my order placed directly with the company (what's with that?)

April 30, 2003: I also finally hear back from RobotOz's technical support confirming they have the DIP version. Boy is this part hard to get!

May 3,2003: Jeff & I had mini-competition at his house. I also received two ideas that improved the overall software design

1. Solve the maze before hand. This greatly simplified the coding as it is now two seperate modules.
2. related to above look ahead and see how far you are going straight instead of slowing down to detect each intersection.

May 5-10,2003: Received the EDE1144 from RobotOz. They included a 4 MHz oscillator, unasked for, which is a nice touch. They were concerned about the package clearing customs, but encountered no problems--overall, I was pleased at their level of responsiveness. Finished hardware on keypad and finnally got encoder working on May 7, and software done on may 10. It is to be noted the Motorola notes on implementing UART is not altogether clear. Some points seem to contradict each other.

May 12-15,2003: For some reason have not been able to download programs. Suspect it is the downloading cable which has been intermitent, but after one attempt to fix, still not connection. Ordered new cable from Mark.

May 15, 2003 Mounted a Sharp IR object detector to detect obstacles.

May 17,2003: Ordered another programming cable from Mark C. the break in the cable appears to be somewhere in the line.

May 17-May 25: Working on software to solve the content. I initially came up with an algorithm that solved the course with no obstacles. After trying to alter the primitive algorithm several times to work with obstacles, I finally concluded it would be more complex than it should be. After relooking at the contest, I decided the line navigation is really a maze with a very symmetrical arrange of walls. With this thought I sought out maze algorithms on the net. I Found no code available, but a couple of algorithms; one using the Bellman flooding algorithm. I did not use the improved method of solving for time as I figured the time improvement would be marginal and probably not worth the effort; besides, once the algorithm was working, there were plenty of other things to deal with!

June 06, 2003: The next problem is being able to store information entered through the keypad between runs. I have tried writing directly to the EEPROM (which seems reasonable) with no luck. I believe as someone suggested it must first be write enabled which would open up potentially overwriting CPU32BUG. To avoid this and to this end I ordered an external SPI EEPROM. So far I have had no luck getting it to work, but may soon retry with the pull-up resistors as suggested on the RSSC mailing list. I have though found I can write to the RAM, and since the RAM is battery backed it actually will retain it between cycling power.

June 10, 2003: Mounted a 10 segment LED display to be able to signal waypoints as they are crossed. I really want to use a beeper, but this was laying around ready to go, so...

June 7-June 13: Arg! in this week I've had the gears come unattached, a cotter pin holding a wheel break, and a wheel fall off (because of a nail that slipped out from the axel). I'm praying for no mishaps the day of the contest.

M2 Specification