Jeeves: A Firefighting Robot
Department of Electrical and Computer Engineering
University of Texas at Austin
Austin, TX 78712-1188, USA.
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.
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.
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
- 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.".
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
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.
- 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