8/9/2019 Building a Fire

1/4

Building a Fire-Fighting Robot

IntroductionCompeting in the Trinity Fire Fighting Home Robot Contest is an excellent way to hone your robotics skills. The competition isextremely popular, and nearly every event across the country offers a variant of it. The overall goal is to build an autonomous robotthat is capable of intelligently searching a "house" (small maze) and extinguishing a "fire" (candle). To accomplish this goal willrequire:

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 theway, I will also impart some knowledge gained during several years of competing.

Viva La CrateCrater 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'ttypically 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 theSenior 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 apanning-head which carried his fan, an IR ranging sensor for wall detection, and a photodiode for fire detection. The bill of materialsis 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 weare. Motors are fairly easy to come by these days, I've built fire fighting robots using largergearhead motors from Lynxmotion

, smallgear 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. Thegym at Trinity will be busy, and will heat up through the course of the day. One of my earliest fire fighters used continuous rotationservos, 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 toolarge will build up too much inertia, making stopping difficult. A wheel that is too small may hang up on the carpets. I suggest a wheelof 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 ofencoders. I've built bots in thepast 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 mostimportant when you need to turn in the corners. I did not use the encoders to regulate motor speeds, just to determine how far the bothad gone, especially when it was making turns. You might be thinking, what about a GPS or compass? Forget them. GPS is generallynot usable indoors, and we are dealing with distances of less than 8 feet, well below the real accuracy of a GPS module. A digitalcompass 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

http://www.trincoll.edu/events/robot/default.asphttp://www.lynxmotion.com/Product.aspx?productID=96&CategoryID=11http://www.lynxmotion.com/Product.aspx?productID=96&CategoryID=11http://www.solarbotics.com/products/gmpw_deal/http://www.solarbotics.com/products/gmpw_deal/http://forums.trossenrobotics.com/tutorials/introduction-129/introduction-to-encoders-3256/http://www.lynxmotion.com/Product.aspx?productID=96&CategoryID=11http://www.solarbotics.com/products/gmpw_deal/http://forums.trossenrobotics.com/tutorials/introduction-129/introduction-to-encoders-3256/http://www.trincoll.edu/events/robot/default.asp

8/9/2019 Building a Fire

2/4

8/9/2019 Building a Fire

3/4

The Importance of TestingThe most important thing you can do is to test, test, test! Your bot should run nearly perfect at home before you arrive with it. Testtime on site should be used for calibrating sensors, not debugging navigation code.

Case Study: Green Machine ReloadedAs 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 2008Canadian 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 viaprotoboards. 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 drivemotors, he still required almost 12" of clear space to turn. GMR was reduced to 6.5"Wx6"L, with rounded back corners, hecould 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" indiameter, even bigger than LGM's, and his track width is only 6.5" to the outside of the wheels. When traversing corridors, tinychanges 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, butI had skimped on testing somewhat. I eventually slowed him down, and spent extensive time tuning his wall following. I also portedmuch of Crater's head panning into GMR, to give him more personality. He returned to the arena at Robogames 2009, where hecompleted all 3 runs and won a hard-fought 2nd place medal.

You can also see the poster from Trinitydescribing GMR.

Case Study: Crater's Control SoftwareHow then, do we tie together a high-level mapping and planning agent, with lower level stuff like navigating a hallway and putting outa candle? Crater uses a hybrid deliberative-reactive architecture, where his high-level planner is tightly coupled to low-level reactivebehaviors.

His default behavior is following the wall. When either theAvoid WallorDetect Openingbehaviors are triggered, they stop the robotand notify the planner, so that it can make a decision of where to go:

http://forums.trossenrobotics.com/tutorials/attachment.php?attachmentid=286&stc=1&d=1251069679http://forums.trossenrobotics.com/tutorials/attachment.php?attachmentid=286&stc=1&d=1251069679http://forums.trossenrobotics.com/tutorials/attachment.php?attachmentid=286&stc=1&d=1251069679

8/9/2019 Building a Fire

4/4