Jeeves: A Firefighting Robot

Anindita Das
Department of Electrical and Computer Engineering
University of Texas at Austin
Austin, TX 78712-1188, USA.
EMAIL: `dasanuiit@gmail.com`

Hello and welcome. Meet Jeeves, the fire-fighting robot. (Apologies to the real Jeeves.) Jeeves is the white Roomba iRobot shown in the picture above. Jeeves is a fire-fighter. It accepts data from SunSPOT sensors This Web page discusses how Jeeves is designed, and what it can and cannot do.

Motivation behind Jeeves

Fire-fighting is a frequent, critical, and life-threatening emergency activity performed by humans. Even small fires can become dangerous if not controlled soon enough. We lose several brave humans each year, in attempts to extinguish fires or rescuing people from a fire that was not detected and controlled soon enough. As autonomous mobile agents and sensor technologies get more and more sophisticated, one of their key applications will be to bear the responsibility of such critical yet life-threatening activities.

Vision Our vision is of a future in which this dream is a reality. The picture to the left shows one such possibility. In particular, sensors will be deployed in areas likely to originate fires and will automatically detect a fire and communicate with a network of robotic fire-agents. The fire-agents will respond to the communication with a xbstrategy (e.g., the nearest available agent may respond to the fire call, and the number of agents involved may depend on the scale of fire as communicated from the sensors) and take appropriate action, all without the need for a human intervention.

Design Assumptions

The above vision requires both a network of sensors and a distributed network of mobile robots, a strategy for sensors to determine the scale of fire, and a programmed strategy for the robots to respond to a request based on this scale. Doing all this is beyond the scope of the class project, given the limited time as well as our limited familiarity with the domain itself. The following are the key simplifying assumptions.

Instead of considering a network of both sensors and robots, we consider a single robot responding to requests from a sensor network. This saves us from having to code up a distributed strategy for robot response.

We assume that the sensors themselves are immovable and their locations are pre-assigned and hard-coded. This obviates the need for a GPS system with the sensors to determine the location of the fire, and on-the-fly routing on the robot side to attend to the request from a specific sensor.

We assume that the fire is detected by light intensity going past a certain threshold. In practice, detection would require computation of some combination of light intensity, ambient temperature, humidity, and smoke concentration, and would probably be influenced by the time of the day, location, season, etc. However, we consider focusing on a heuristic measure of "what exactly is fire" to be orthogonal (and complementary) to our focus.

Typical Activity of Jeeves

The picture on the left is a block diagram showing how Jeeves actually performs. The SunSPOTs continually send fire data to the base station, which communicates with the laptop. The player running on the laptop monitors this data and activates Jeeves when the light intensity exceeds a threshold. Jeeves moves to the location of the designated SunSPOT in the attempt to extinguish fire. When the fire is extinguished (simulated by a decrease in the light intensity), Jeeves will return to its original location. In order to account for possible noise in fire data as well as the possibility of the flames returning after having been initially subdued, Jeeves remains in the location until "no fire" is received for a substantial period of time. Since Jeeves is incapable of physical fire-fighting activity, it merely "speaks" the phrase "I am extinguishing fire." to simulate fire-fighting activity and signals completion with the phrase "My work is done.".

Implementation Notes

The sensors communicate with the base station using the devices radio (TI CC2420) connected to a laptop. Jeeves is executed by the player running on the laptop.

The configuration and processing of SunSPOT data is implemented through a Java program, while the actions of Jeeves are controlled through a C++ program. The communication between these two programs is file-based. The Java program writes fire data to a file, which is read by the C++ program to determine whether Jeeves needs to be activated (if it was idle and fire is detected), or returned (if it was fighting a fire and the fire data says that the fire has been extinguished). All the implementations have been done on a Linux laptop running Ubuntu 10.04.

Jeeves is constrained in its activity in a number of ways. Many of these constraints arose because of practical difficulties given the resources we worked with for this project.

Since Jeeves does not have arms or legs, it can only "go" to a location of fire, not actually perform any fire-fighting activity. A more sophisticated robot can, of course, mitigate this problem. However, coordination of body movements (e.g., walking, picking fire hose, etc.) is a difficult problem, which has not been considered within the scope of this project.

Jeeves is connected to the laptop through a wired connection; consequently, the length it can travel is constrained by the length of the cable connecting it. This could have been possibly mitigated by placing the laptop on top of Jeeves. That possibility had to be, unfortunately, rejected because of the aging battery of the laptop used; furthermore, initial experiments with the idea suggested that the location error increases when Jeeves needs to carry a heavy laptop on its ``back'' (see below). Another possibility, not considered in this project due to unavailability of a wireless transmitter for the robot, is to make Jeeves communicate with the laptop through wireless.

Finally, since Jeeves is not equipped with a location detection system, the locations of the different SunSPOTs with respect to the initial position of Jeeves are hard-coded in the program controlling Jeeves; once Jeeves is done fighting fire, it always returns to the initial position before attending to a subsequent fire call. An unfortunate consequence of this, of course, is that location errors can accumulate. For instance, suppose that on return from a fire call Jeeves is diverted from its course due to the presence of an obstacle. Then its response to a subsequent fire call will be based on an erroneous assumption about its initial position. This problem can, of course, be mitigated by equipping Jeeves with a location system; however, this project did not investigate that possibility.

Conclusion and Future Work

The project has been motivated by the desire to design a system that can detect fires and take appropriate action, without any human intervention. The development of sensor networks and the maturity of robotics suggests that we can use mobile agents for tasks that involve perception of an external stimulus and reacting to the stimulus, even when the reaction involves a significant amount of mechanical actions. This provides us the opportunity to pass on to robots tasks that traditionally humans had to do but were inherently life-threatening. Fire-fighting is an obvious candidate for such automation. Given the number of lives lost regularly in fire-fighting, the system we envision is crying for adoption. Our experience suggests that designing a fire-fighting system with sensors and robots is within the reach of the current sensor network and mobile agent technologies. Furthermore, we believe that the techniques developed in this work will carry over to other areas involving sensing and reacting to stimulus, where we desire to replace the human with an automated mobile agent.

Of course, this project has only scratched the surface. As in the design simplifications and the implementation constraints in suggest, our project is very much a proof-of-concept. In particular, a practical autonomous fire-fighting system must include a collection of robots, communicating and cooperating in the mission; furthermore, such a system requires facilities for going through obstacles in the presence of fire, and ability to receive instructions on-the-fly during an operation. All such concerns were outside the scope of this project. However, there has been research on many of these pieces in different contexts, e.g., coordination among mobile agents, techniques for detecting and avoiding obstacles, on-the-fly communication between humans and mobile agents, etc. It will be both interesting and challenging to put all this together into a practical, autonomous fire-fighting service.

Further Resources

A report providing more details on Jeeves and a thorough discussion of related research
A talk about Jeeves
A demo of Jeeves working
Source Code and a README