Building a Fire-Fighting Robot

Introduction
Competing in the Trinity Fire Fighting Home Robot Contest is an excellent way to hone your robotics skills. The competition is
extremely popular, and nearly every event across the country offers a variant of it. The overall goal is to build an autonomous robot
that is capable of intelligently searching a "house" (small maze) and extinguishing a "fire" (candle). To accomplish this goal will
require:
• The construction of a reliable power train: speed is important, but secondary to reliability. A robot that finishes three runs will
always beat a robot that fails a trial.
• The construction of a reliable electronics suite: including a microcontroller and a sensor package suited for fire-fighting, in
particular:
○ Range sensors for detecting the maze and navigating
○ Sensors for detecting a candle
• The development of reliable code to navigate the maze and search each room.
This tutorial will walk through each of these steps discussing how Crater, the 2009 Contest winner, solved these problems. Along the
way, I will also impart some knowledge gained during several years of competing.

Viva La Crate
Crater was my entry into the 2009 Contest. He was intended to be a low-cost entry, coming in around $120 in parts. While he wouldn't
typically be fast enough to win the contest, it was a particularly hard time on most contestants and he was the only non-kit bot in the
Senior division to complete all 3 runs. He also won the Cost-Effective prize.

Crater was built out of a mini milkcrate, with surplus gear motors for a drivetrain. He used an AVR microcontroller. A servo drove a
panning-head which carried his fan, an IR ranging sensor for wall detection, and a photodiode for fire detection. The bill of materials
is attached below as a PDF.

Figure 1 - Crater, winner of the 2009 Senior Division at the Trinity Fire Fighting Robot Contest.

The Navigating of the "House"

Clearly, the first item we must address is navigating. We need motors that can drive the robot, and sensors that can tell us where we
are. Motors are fairly easy to come by these days, I've built fire fighting robots using larger gearhead motors from Lynxmotion, small
gear motors from Solarbotics, and surplus motors like those I put in Crater.

I would highly recommend avoiding continuous rotation servos. The major issue here is that these servos use an RC (resistor-
capacitor) timing element in their feedback loop, which means they will lose their center position as they change temperature. The
gym at Trinity will be busy, and will heat up through the course of the day. One of my earliest fire fighters used continuous rotation
servos, and we were constantly re-calibrating the stop positions.

Wheel size and motor speed are important for Trinity. We need to move quickly, but in a controllable manner. A wheel that is too
large will build up too much inertia, making stopping difficult. A wheel that is too small may hang up on the carpets. I suggest a wheel
of 2.5-3.5" in diameter. Crater used 2.875" foam wheels, because of the low cost, and availability of hubs.

Once we have our motors, we need feedback on where our motors are taking us, likely in the form of encoders. I've built bots in the
past without encoders. You CAN do it, but it is significantly harder since you won't have any idea how far you've gone. This is most
important when you need to turn in the corners. I did not use the encoders to regulate motor speeds, just to determine how far the bot
had gone, especially when it was making turns. You might be thinking, what about a GPS or compass? Forget them. GPS is generally
not usable indoors, and we are dealing with distances of less than 8 feet, well below the real accuracy of a GPS module. A digital
compass can easily be thrown off by metal in the floor, or even the magenetic field of your bot's own motors.

For navigating, Crater used a single IR sensor. He navigated mainly by following walls. From his starting position, he would follow
the wall until it ran up, or he detected a forward wall (end of a hallway) [Read my Tutorial On Wall Follwing]. Clearly, we could do
this with multiple sensors, but a moving head is just so cool for the audience, and saves money on sensors. So then, how did Crater
know when to worry about a forward wall? Remember those encoders? Since the map is known before the competition, we
programmed it right into Crater:

Figure 2 - Crater's map. Red nodes are rooms, blue nodes are hallways. Arrows indicate a valid path through the map.

Now, mapping is not standard equipment on most fire fighters. Most of the fire fighters have their moves pre-programmed: go down
the first hallway, turn left when you reach the end, turn left when you reach the end of this hallway... and so on. It's definitely easier to
implement at first, but if you are like me and take your bot to different events that each use slightly different maps, using an easily
changeable map is a great idea.

This map was a topological map, each intersection was a node in the map. We stored the distance between nodes in the map. When
Crater was getting close to his next node, he would start looking for it's defining feature, such as a forward wall or an opening in a side
wall. [Read my Tutorial on Maps].

A final consideration on navigation is the overall size of the robot. I've built bots that were the entire 12x12" size limit -- trust me,
navigation is much easier with a smaller bot. Most of my bots are about 8"x8" footprint. Minimum height is clearly dictated by the
height of the candle, and thus your fan. Obviously, at high speed, a lower COG is better.

The Finding of Fires

The most important part of the competition is to put out the candle, but before we can do this, we need to find the candle!

There are a variety of ways to find and localize a candle. The Green Machine Reloaded (GMR), my high-dollar fire fighting bot, used
a UVTron ($75) and a Thermopile ($110). The UVTron detects UV light in any direction, giving a very quick indication of whether a
candle is located in a particular room - GMR didn't even need to enter a room to check it! Once a candle was detected, the thermopile
tells where the candle is, by scanning with the head. Previous versions of Green Machines used a Pyro-electric sensor to detect the
candle's location, but I much preferred the Thermopile. (A note on the UVTron: the pulses it puts out are VERY short. I suggest using
an interrupt to detect them).

Crater replaced both those sensors with an OP599A IR photodiode and a 47K pull up resistor, that costs less than a dollar. Obviously,
he had to enter the room, and pan his head around to see if the fire was there, so he was gonna be a little slower than GMR. But, this
sensor works really well. I can't take credit for discovering this combo, another competitor found it in 2008.

Once we have localized the fire within the room, we can roll right up and put the fire out - or can we? There is a severe penalty - 50
seconds - for hitting the candle or base supporting it. Crater was slapped with this penalty during all 3 runs, he just couldn't see the
candle. The IR ranging sensor on his head was washed out from the IR of the fire. In testing, the IR ranger I had added last minute
near the base worked to avoid running the candle over. But my candle base for testing was far larger than the actual one, and Crater's
IR sensor was too narrow, he missed the base. On GMR and other bots, I've found that using a sonar ranging sensor for the approach
to the candle works well.

The Fighting of Fires

Actually putting the fire out may be one of the easiest tasks yet. Most competitors use a fan. I've come to like the ducted fans used on
model airplanes. They're fairly low cost and pack a heck of a punch. A simple Darlington transistor can be used to switch the fan on
and off. I typically buy the 9.6V version and use a 9V battery.
The Importance of Testing
The most important thing you can do is to test, test, test! Your bot should run nearly perfect at home before you arrive with it. Test
time on site should be used for calibrating sensors, not debugging navigation code.

Case Study: Green Machine Reloaded

As I mentioned above, Crater was my low-cost entry to the 2009 Contest but I also had another bot. The Green Machine Reloaded
(GMR), was supposed to be my very fast, very reliable robot. An earlier robot of mine, the Little Green Machine won the 2008
Canadian National Robot Games in November 2008. By the time I was done testing and coding LGM, he was quite reliable. GMR
was intended to be a redesign with several goals:
• First and foremost, LGM's electrical wiring was a mess. He used an ARC robot controller, with several circuits attached via
protoboards. Overall, electrical wires breaking were a huge issue.
• A head was to be added to GMR, with most of the fire sensory in the head.
• I had reasoned that smaller size was always going to be an advantage. LGM was 8x8" square, due to the location of his drive
motors, he still required almost 12" of clear space to turn. GMR was reduced to 6.5"Wx6"L, with rounded back corners, he
could turn in about 9" of space.
• The lynxmotion drive train stayed identical from LGM to GMR.
GMR was fast, but it failed at reliability. The major problem with GMR is that he is unstable at high speed. His wheels are 2-7/8" in
diameter, even bigger than LGM's, and his track width is only 6.5" to the outside of the wheels. When traversing corridors, tiny
changes in speed cause huge differences in heading, it's tough to keep this bot driving in a straight line.

However, GMR is a good example of a high-end sensor suite:

At Trinity, GMR crashed into a wall on each of his 3 runs, and become stuck. He had not shown such terrible issues during testing, but
I had skimped on testing somewhat. I eventually slowed him down, and spent extensive time tuning his wall following. I also ported
much of Crater's head panning into GMR, to give him more personality. He returned to the arena at Robogames 2009, where he
completed all 3 runs and won a hard-fought 2nd place medal.

You can also see the poster from Trinity describing GMR.

Case Study: Crater's Control Software

How then, do we tie together a high-level mapping and planning agent, with lower level stuff like navigating a hallway and putting out
a candle? Crater uses a hybrid deliberative-reactive architecture, where his high-level planner is tightly coupled to low-level reactive
behaviors.

His default behavior is following the wall. When either the Avoid Wall or Detect Opening behaviors are triggered, they stop the robot
and notify the planner, so that it can make a decision of where to go:
Extra Modes
There are numerous extra operating modes that can be applied to lower your score without making the robot faster. One of the most
common is the audio start. The SRS has a great tutorial on constructing such an audio detection circuit:
http://www.seattlerobotics.org/encod...03/larryb.html

Conclusion
Obviously, this is a competitive environment at Trinity, and you may ask, why have I posted all this stuff? Well, I believe that we will
move forward much faster if we share designs. It typically takes a team a year or two to learn the ins-and-outs of difficulties they may
have designing a robot. I don't expect anyone to outright copy this design and win, but at least it's a starting point to get some ideas.
Maybe if we share some information, we can see competitiveness and innovation right out of the gates... human beings don't work in a
vacuum...

I have full source code for Crater on my SVN server: http://svn.blunderingbotics.com , or you can download a ZIP file of the code and
docs. Please note, there really isn't a complete schematic yet.

There are additional robots documented on my website: http://www.blunderingbotics.com. I am not the first person to share my
design, heres a few links to other bots that have been well documented:
• Snuffy - Winner of the 2001 Senior division. Excellent documentation, although the design is slightly out of date, the general
guidelines are still VERY applicable.
• Rockhopper - Winner of the 2007, 2008 Expert division.
• Fire Marshall Bill - an interesting balancing bot.