Uppsala University
Department of Information Technology
Requirements specification:
Autonomous, Three-Wheeled Rescue Robots
Revision history
Revision / Date / Author / Comment0.1 / 2004-11-11 / Jakob Carlström / First draft
0.2 / 2005-01-14 / Jakob Carlström / Restructured document
0.3 / 2005-01-19 / Jakob Carlström / Added requirement on Player API
0.3.1 / 2005-01-23 / Jakob Carlström / Minor adjustments
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.
For every robot added to the team the time required to solve the task shall decrease.
The distributed system of robots shall have no single point of failure.
In autonomous operation, a robot shall find its location 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.
An operator shall be able to override autonomous operation.
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.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 shall 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.
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 three-dimensional 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.
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.
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 in a user-friendly way, allowing efficient operation by 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.
1