Embed Doc
Copy Link
Readcast
Collections

CommentGo Back

Download

An Autonomous Firefighting Robot

William Dubel Hector Gongora Kevin Bechtold Daisy DiazDepartment of Electrical and Computer EngineeringFlorida International University, Miami, FL 33199

Abstract

Firefighting is an important butdangerous occupation. A firefighter must beable to get to a fire quickly and safelyextinguish the fire, preventing furtherdamage and reduce fatalities. Technologyhas finally bridged the gap betweenfirefighting and machines allowing for amore efficient and effective method of firefighting. Robots designed to find a fire,before it rages out of control, could one daywork with firefighters greatly reducing therisk of injury to victims. The

IEEE SOUTHEASTCON 2003

HardwareCompetition

tests the minds of collegestudents all over the nation with thechallenge of extinguishing a fire located in asimulated house autonomously. To anyoneunfamiliar with robotics, for a robot to beautonomous means the robot must operateon its own independent of any humanintervention. The competition requires arobot to activate upon the sound of anaudible tone (the fire alarm), locate andextinguish the simulated fire. (The fire issimulated by an array of red LEDs hiddensomewhere inside the house.) This paperdescribes such a robot, covering thecomponents and logic required tosuccessfully locate and extinguish thesimulated fire.

1. Introduction

The firefighting robot is designed to searchfor a fire in a small floor plan of a house,extinguish the fire (by placing a cup over theLEDs), and then return to the front of thehouse. This mission is divided into smallertasks, and each task is implemented in themost efficient manner. The navigation of the robot throughout the house is achievedby data provided by a line tracker andultrasound transducers. The targetacquisition is achieved by data provided bya camera. The deployment of theextinguishing device is implemented with acustom arm controlled by servos. Alongwith these crucial tasks were other designconstraints, such as the size, speed, andsupply of power. Each definingcharacteristic of the robot is described inmore detail in this document.

2. Software Design

The software for the robot was coded in C,because of compiler availability, ourfamiliarity with the language, as well as thegreater control of the system offered ascompared to other higher languages. Whileour Microcontroller supports assembly, itwas avoided because it’s a difficult tomaintain, and varies greatly from processorto processor. C allowed us to easily break apart the components of software design sothat different members of the team couldcode the system. The software design hadfour major components, includinginterfacing its peripherals, control of itsmotors and servos, navigation, and targetacquisition.

2.1

Peripheral Interfacing

Peripheral interfacing included reading thefour ultrasonic transducers and interpreting adistance, reading the state of the infraredline trackers, and communicating with thecamera. A keypad and display were alsointerfaced, as well as a small speaker andstatus indicators, to allow the user to interactwith the robot more effectively. The mostprogramming sensitive sensor was theultrasound. The ultrasound requires a startpulse, which then holds a line high until anecho is received. The length of time that theline is held is proportional to the distancethat the sensor is reading. The ultrasoundmust be carefully coded with accurate delaysto prevent reading incorrect distances. Wehandled this with timed interrupts. Aninterrupt is set to trigger every 50us, to giveus an accuracy of about 1 cm. Userinteraction was not a requirement of thisrobot, but having a keypad and displayinterfaced accelerated the debuggingprocess, as well as adding flexibility to therobots programming. Multiple routinescould be loaded at once, and the user is ableto choose the routine of interest from a menusystem.

2.2

Motor Control System

Feedback from ultrasound and line trackerControl system block diagram

2.3

Navigation

The robot is programmed for a knownenvironment that is not expected to change.This allowed us to use a simplerprogramming technique to navigate therobot to each of its possible destinations.Instead of providing the robot with a map of the area, and coding an algorithm that coulddetermine the best path to take for anydestination, the actual known routes wereprogrammed in. While not as elegant, actualroutes can be ‘hard-coded’ in much lesstime, and also requires less RAM(something rather limited on aMicrocontroller). However, a newenvironment would mean recoding all of thepath routines, instead of loading a new mapfile. The routines are coded to look forlandmarks, such as the absence or presenceof certain walls, lines, or distances, todetermine its current location. This is a stepabove dead reckoning, where the robotwould blindly track its distance traveled todetermine its locations. Dead reckoningpresents problems on different surfaces andwhen there are slight variations in thelocations of the doorways, as could happenduring the competition. For our coding, theonly routine that was left to dead reckoningwas a 90-degree turn (when not assisted by aline). The degree of error was noticeable,but not enough to cause problems for thenavigation. To facilitate coding the routesbased on landmarks easier, a map was drawnwith particular points of interest marked ascoordinates. While the coordinates had nomeaning to the Microcontroller, they gavethe programming team common ground towork from. One member could reuse aroutine to go from one coordinate to another,even though their final destinations weredifferent.

2.4

Target Acquisition

The CMUcam is used for video processing.The CMUcam provides a way to recognizeif the candle is in the robot’s field of view,and the position of the candle relative to therobot. On entering a room, the camera isused to detect the presence of a candle,based on whether or not an object in viewmeets the color criteria. The robot makesone rotation in search of the candle. If therobot detects the candle, robot proceeds totrack the candle until it is at the correctdistance. Otherwise, the robot exits theroom and continues with the navigationroutine.The robot tracks towards the candle basedon the position of the candle in the camera’sfield of view and the distance from thecandle as measured by the ultrasound. If atany point the camera fails to recognize acandle in its field of view, the robot repeatsits initial search. Only the horizontaltracking position from the camera isanalyzed. If the robot is centered on thecandle within an allowable range of degreesthe robot moves forward or backwards untilthe distance from the ultrasound is correct.If the robot is too far to the right of thecandle, the robot moves left. If the robot istoo far to the left of the candle, the robotmoves right. Since the data from the camerais in pixels, the following equation was usedto determine the threshold values (solved forthe left threshold):

HorizontalViewCandle MaxView Left

sF Dist DF P

Re*tan2

       

−=

−

px pixelscmcmP

Left

3780*9081tan290

   

   

−°=

−

The camera’s field of view is 90 degrees,horizontal resolution was 80 pixels, themaximum deviation was 1 cm, and thedistance from the candle was 8 cm. Whenthe robot is centered at the candle at thecorrect distance, the arm is lowered todeploy the cup.

Platform