DPRG mailing list archives: DPRG: Fire fighting FleaBot

Fri Apr 3 18:32:55 CST 1998

Well, the necessary mods to bring FleaBot up to fire-fighting stance are
earnestly underway.

The increased number of I/O devices needed for the fire fighter have
convinced me to add an I/O board of substantial size.  It fits on top of
the controller and is actually about 10% larger than the controller.

I'm moving the batteries into the space vacated by the old motor driver
board so there will no longer be any cells hanging off every available
surface.  This should help redistribute the weight in a friendlier
manner.  Previously, there was enough weight resting on the little
swivelling wheel to occasionally make it hang in a less than neutral
location, forcing the chassis to turn undesireably.  It will also
locallize the welding current that these cells provide, perhaps
preventing the future welding of any more I/O pins on the controller.  

Even though the motors I was using for the DPRG contest were performing
adequately, a rogue screw jammed one of the wheels and since then, that
motor is noisy.  Perhaps the (very small) gears were partially
stripped.  No matter, for I wanted to use the modified servo anyway and
this give me a good opportunity to additionally redistribute the weight.

I have not yet decided exactly how I will count wheel rotations.  The
optical encoders lifted from the mouse are a little less elegant than I
prefer, considering that they are friction driven by the relatively soft
rubber tires.  The original encoder I put inside a modified servo
suffered from such allignment problems as to have me abandon it.  I have
another scheme up my sleve involving Hall effect switches and magnets. 
I'll keep you posted!

Due to time contraints, I think I will probably use IR for collision
avoidance unless I can get my prototype ultrasonic working this
weekend.  The IR scheme is very good for maintaining a fixed distance
>from the nearest wall and does not require any timing by the controller.

As occurred for the DPRG contest, I suspect that I will spend a lot more
time finishing the hardware than I care to, leaving less quality time
for the software, which will be critical.  So far, I've worked on a
navigation method that is a hybrid of dead reconning and maze solving,
hoping to enter under the non-dead reconning rules.

The desired path through the maze is a list of waypoints.  The world is
a 100x100 array, each byte representing a 1" square.  The lowest 3 bits
of each square represent which of the 3 primary directions *should*
return an obstacle if FleaBot is really on this square.

In the contest, the waypoints are of a known distance, but competing in
the non dead reconning mode introduces ramps which effectively lengthen
the real path between two waypoints.  While traveling, FleaBot will
compare the stored information describing each square with empirical
data gathered to determine whether he is really at the square he thinks
he is at.  Once a match is made, he will assume that he is where he
belongs and make the necessary turn or scan for fire or whatever.  

After some yet to be determined number of failed attempts to locate
himself, he will "default" to a wall following right-hand-touching maze
solving algorithm, all the the while looking for fire.

For locating the flame, I have been unable to acquire adequate UV
detectors and will likely use the passive infrared detector method.  I
am very intrigued by Ed Koffeman's image processing method, but I do not
have the development time to follow suit!  :)

As for puting that fire out once found, I found something compact that I
hope to be able to use, but it requires a lot of mechanical force to
activate.  I have a reliable backup if I can't solve the force vs size
issue.

That is the status as it stands.... More details as they develope!

Robert

slugmusk at alias.flash.net

------------------------------