Uppsala University
Department of Information Technology
Requirements specification:
Autonomous, Three-Wheeled Rescue Robots
Revision history
Revision
0.1
0.2
0.3
0.3.1
0.3.2
0.3.3
Date
2004-11-11
2005-01-14
2005-01-19
2005-01-23
2005-01-27
2005-02-07
Author
Jakob Carlström
Jakob Carlström
Jakob Carlström
Jakob Carlström
Fredrik Hellman
Fredrik Hellman
Comment
First draft
Restructured document
Added requirement on Player API
Minor adjustments
Adjustments prior to negotiations
Minor adjustments before sending to buyer
Summary
This document provides requirements for the project semester, spring 2005. The requirements are
divided into three sections:
 General requirements
 Hardware requirements
 Software requirements
1 General requirements
This section lists requirements that are neither specific hardware nor software requirements, as well
as requirements that are both hardware and software directed.
1.1 RoboCup RescueRobot League rules compliance
The robots shall comply with all rules (year 2005 version) of the RoboCup RescueRobot League.
1.2 Communication
The robots shall use IEEE 802.11a WLAN, configured in infrastructure mode (using a base station).
Robot operation shall be robust to communication failure and congested communication
channels.
1.3 Autonomous operation
A team of up to 8 robots shall be able to solve a rescue robot task in autonomous cooperation.
The distributed system of robots shall have no single point of failure.
In autonomous operation, a robot shall keep track of its location relative to the start point and
build a map of its environment (the rescue arena) and its victims without assistance by humans.
1.4 Remote operation
A human operator shall be able to operate robots remotely using an operator panel, implemented in
software running on a computer connected to the robot over the WLAN.
When the robots operate in autonomous mode, the operator panel shall serve as a control and
management interface, displaying status and allowing an outside operator to query and modify
parameters. (Jacob: Vilka sorts parametrar??)
An operator shall be able to override autonomous operation.
1
Uppsala University
Department of Information Technology
1.5 Reset
An operator shall be able to reset each subsystem within a robot, the system in a single robot or the
distributed system of robots from the operator panel.
The boot time for the entire system should be as short as possible, but less than a minute.
Each robot shall have a physical reset button. The effect of pressing this button shall be
determined by the robot software. For example, it could be implemented such that a robot is reset
without losing its state (information about the environment).
Resetting one robot must never stop the operation of any other robot in the system.
After reset, a robot shall get state information from other robots in the system, and start
working as part of the system.
1.6 Safety
The robots shall be designed such that the risk of injury on human operators, victims or spectators is
minimal.
2 Hardware requirements
Based on the hardware platform of the Hermod project, a next generation autonomous rescue robot
shall be developed.
Two complete physical rescue robots shall be built. The hardware requirements are given for a
single robot but apply to all robots.
These “hardware requirements” include requirements on software in local microprocessors in
sensors and other subsystems.
2.1 Electrical and mechanical
2.1.1 General
The robot shall be as small as the chassis with motors and wheels allow.
The robot shall not be heavier than <FFS>
The robot, including its cabling and internal and external design, shall make a neat and
professional visual impression.
2.1.2 Safety
An easily accessible and highly visible physical switch which immediately cuts the power to the
engines shall be placed on the outside of the robot.
All cables, sockets and switches shall be dimensioned for twice the maximum currents.
Systems shall be designed such that electric and electro-mechanic components are not
accidentally harmed. For example, the motor control circuits shall contain protection from excessive
currents.
A main fuse shall protect the power system in case of short-circuit <is this necessary?>.
2.1.3 Robustness
A hood shall cover and protect the electronics.
Sensors and other fragile components shall be mounted such that they do not get damaged in
case of collision.
Batteries, motors and motor controllers shall be electromagnetically shielded from other
electronic systems.
2
Uppsala University
Department of Information Technology
2.1.4 Stability
When the wheels are locked, the robot shall be able to stand on a floor tilted in any direction up to
30 degrees without sliding or toppling over.
2.1.5 Accessibility
All components shall be quickly and easily accessible for measurements, repair and replacement.
2.1.6 Power supply
The robot shall be able to perform rescue operation with all systems alive for at least 30 minutes.
2.2 Navigation and movement
2.2.1 Speed
<FFS>
2.2.2 Turnaround radius
The robot shall be able to rotate around the centre of the driving wheels' axis.
2.2.3 Accuracy
During a 20 minute rescue mission, the robot must be able to maintain its position with an accuracy
of 0.5 m.
2.2.4 Climbing
The robot shall be able to roll over a 75 mm high obstacle such as a plank or a brick.
2.2.5 Obstacle and hazard avoidance
The robot shall not collide with obstacles (objects or humans) when moving.
The robot shall avoid falling down on surfaces lower than 150 mm from its vertical position.
2.3 Sensors
2.3.1 Localization and mapping
The robot shall have sensors supporting the requirements in section 1. To support simultaneous
localization and mapping (SLAM), a roof-mounted omni-directional video camera should be used.
2.3.2 Victim discovery and positioning
The robot shall be able to discover a victim emitting body heat at a distance of up to 5 m.
The robot may be able to estimate the angles to the boundaries of the victim with an accuracy
of <FFS>.
2.3.3 Visualization of victims
The robot shall be able to take single snapshots of victims for later identification or send visual
feedback to the operator.
2.3.4 Obstacle ranging and classification
The robot shall be able to measure distances to obstacles within three meters from the robot.
All obstacles shall be classified as transparent (glass etc) or non-transparent.
3
Uppsala University
Department of Information Technology
2.3.5 Sound classification
<FFS>
2.4 Actuators and indicators
An externally visible LCD display shall show the status of subsystems for debugging purposes.
If required by the navigation system, the robot shall be equipped with lights for illuminating the
environment. These lights shall be switched on if the ambient light is too weak.
3 Software requirements
Software for a distributed system of autonomous rescue robots shall be developed.
To support development of navigation control software, the project shall develop a threedimensional simulator of rescue robot scenarios based on the USARsim rescue robot simulator
(which is based on Unreal Tournament).
3.1 Autonomous mode
3.1.1 Navigation
In autonomous mode, it shall be possible to drop the robots anywhere in the rescue arena. From the
starting point, they shall successively negotiate larger areas and dynamically increase the mapped
world with no other constraints than physical obstacles.
Each robot shall perform simultaneous localization and mapping (SLAM) based on input from
a video camera and other sensors.
For the purpose of RoboCup Rescue competitions, the robots shall classify any area where the
distance to obstacles is more than five meters in any direction as outside the rescue arena, and move
from there into the arena and continue the search inside.
3.1.2 Map
The map constructed by the robots shall indicate physical obstacles, human victims and suggested
paths for rescue personnel to follow to the victims.
For each victim, state and situation information shall be presented in accordance to RoboCup
Rescue rules.
In the map, transparent walls (windows) shall be marked as “glass”.
Map building shall be distributed. Map information acquired by one robot shall be shared with
other robots to speed up search, and prevent a robot from unnecessarily searching areas already
covered by other robots.
3.2 Operator mode
In operator mode, the difference from autonomous mode is that a single human operator controls
the distributed system of robots via an operator interface showing the map and other status
information.
3.3 Real-time
Processing and communication shall be analysed for real-time requirements, and designed to
comply with these requirements.
4
Uppsala University
Department of Information Technology
3.4 Communication
To ensure robustness to failure of wireless communication, no software shall be stuck in a waiting
state if communication fails. Instead, operation shall continue in black-out mode, with the
possibility to restart communication again at a later stage.
A transport protocol shall be employed that is robust to congestion; for example, environments
where uncontrolled sources transmit at the same channel. The only part that uses a protocol not
robust to congestion is the connection between the remote controller (OpGUI) and the robot.
3.5 Simulator
3.5.1 Graphics
The simulation shall be shown in 3D. The “world map” shall be read from a given arena definition
file.
3.5.2 Communication
A wireless transport protocol that is robust to congestion shall be used, to ensure best possible
communication also in environments where uncontrolled sources transmit at the same channel.
The communication between the operator panel and the robot shall be based on the Player
(http://playerstage.sourceforge.net/player/player.html) API for robot control. This API is also
supported by USARsim.
3.5.3 Sensors
The signals from the sensors shall be generated from the simulator.
3.6 Operator panel
The operator panel shall implement all requirements found in section 1 of this document.
The operator panel shall visualize robot data and provide controls, allowing efficient operation
by trained humans.
Specifically, the operator panel shall present data gathered from potential victims in a single
view per potential victim. This data shall be presented in a way that makes it possible for an
operator to make a quick and correct decision on whether a victim was found and, in this case, what
the situation of the victim is. This view may contain machine generated decision support.
The operator panel shall be platform independent; i.e., it shall work on any common
combination of computer and operating system.
Robot operation shall not be dependent on communication with the operator panel.
The operator panel shall provide debug features, such as querying and modifying the status of
subsystems.
5