user requirements document - icarus project · deliverable 100.1 – v 8.0 page 3 acronyms &...
TRANSCRIPT
User Requirements Document
D100.1
Final Version
Grant Agreement number 285417 Project Acronym ICARUS Project title Integrated Components for Assisted Rescue and
Unmanned Search operations Funding Scheme Collaborative Project Project Starting date February 01, 2012 Project Duration 48 months Project Coordinator Royal Military Academy – Geert De Cubber
[email protected] Deliverable reference number and full name D100.1 – User Requirements Document Delivery Date M24 – January 31, 2014 Issue 8.0 Issue Date M24 – January 31, 2014 Document produced by RMA – Daniela Doroftei; INESC – Anibal Matos Document validated by RMA – Geert De Cubber Dissemination Level PU
Dissemination list:
ICARUS Partners
End-user respondents to the questionnaires
Deliverable 620.1 – V1.0 Deliverable 100.1 – V 8.0
Deliverable 620.1 – V1.0
Page 2
Applicable documents
Ref. / Document Title Issue Date
ICARUS Description of Work – Annex 1 10 22/11/2011
ICARUS Grant Agreement – Annex 2 1 n.a.
ICARUS Consortium Agreement 1 20/01/2012
Document Change Record
Issue Date Page / paragraph affected
1.0 April,27th 2012 Initial Draft, focused mainly on feedback from the USAR community
2.0 July,31st 2012 Updated Draft, including updated user feedback from the USAR community and including user feedback from the MSAR community
3.0 January, 31st 2013 Updated Draft, including updated user feedback from the USAR & MSAR community
4.0 November 30, 2013 Updated Draft, including updated feedback from the USAR and MSAR community and B-FAST, WP320, WP230, WP220, WP310, WP510
5.0 December 31, 2013 Updated Draft, including updated feedback from B-FAST
6.0 January 21, 2014 Version submitted to coordinator, including updated data from MSAR
7.0 January 31, 2014 Final Version, submitted to EU, including final QA by the coordinator and including feedback of end-users on C2I system during WP320 meeting on 28/01/2014
8.0 January 31, 2014 Public Version
Deliverable 100.1 – V 8.0
Page 3
Acronyms & Definitions
AIIMS Australasian Inter-Service Incident Management System
C2I Command, Control & Intelligence
C4I Command, Control, Communications, Computers and Intelligence
CMC Crisis Management Centre Finland
CRASAR Center for Robot-Assisted Search and Rescue
EC European Commission
ESRIF European Security Research and Innovation Forum
EU European Union
EUB End-Users Board
FAST First Aid and Support Team
FCSS Field Coordination Support Section
FP Framework Programme
FRF Frontline Responses Finland
GDACS Global Disaster Alert and Coordination System
GIS Geographical Information System
GPS Global Positioning System
ICS Incident Command System
INSARAG International Search and Rescue Advisory Group
IP Ingress Protection
IR Infrared
JPG Joint Photographic Experts Group
KML Keyhole Markup Language
LEMA Local Emergency Management Authority
LUGV Large Unmanned Ground Vehicle
MSAR Maritime Search And Rescue
MST Management Support Team
NIMS National Incident Management System
NLOS Non-line-of-sight
OCHA Office for the Coordination of Humanitarian Affairs
OSOCC On Site Operations Coordination Centre
PMB Project Management Board
PMP Project Management Plan
RDC Reception Departure Centre
REA Research Executive Agency
RPA Remotely Piloted Aircraft
Deliverable 100.1 – V 8.0
Page 4
SAB Security Advisory Board
SAR Search And Rescue
SLAM Simultaneous localization and mapping
SRAD System Requirements & Architecture Definition
STAB Scientific and Technical Advisory Board
SUGV Small Unmanned Ground Vehicle
TETRA Terrestrial Trunked Radio
THW Technisches Hilfswerk
UAS Unmanned Aerial System
UGV Unmanned Ground Vehicle
UMP Unmanned Marine Platforms
UN United Nations
UNDAC United Nations Disaster Assessment and Coordination
URD User Requirements Document
USAR Urban Search And Rescue
USB Universal Serial Bus
USV Unmanned Surface Vehicle
VHF Very high frequency
VO Virtual On Site Operations Coordination Centre
WFS Web Feature System
WMS Web Mapping System
WP Work Package
WPC Work Package Committee
Deliverable 100.1 – V 8.0
Page 5
Table of Contents
Part 1 - Introduction ................................................................................................................... 11
1. Introduction ....................................................................................................................... 12
1.1. Project Context ...................................................................................................................... 12
1.2. Purpose of this document ..................................................................................................... 13
1.3. User Characteristics ............................................................................................................... 13
1.3.1. National vs. International Intervention Teams ............................................................. 13
1.3.2. Urban SAR vs. Maritime SAR ......................................................................................... 14
2. Methodology of Information Gathering .............................................................................. 15
Part 2 – Urban Search & Rescue Operations requirements ........................................................... 21
3. Application Scenarios and Use Cases for Unmanned Search And Rescue Tools ...................... 22
4. Typical organization of USAR teams .................................................................................... 24
5. General User Requirements ................................................................................................ 29
5.1. Prioritization of developments ........................................................................................... 29
5.2. Operational Preparedness and Mission Planning Requirements .................................... 30
5.3. (Fast) Deployment Requirements ....................................................................................... 30
5.4. Required manpower to operate the tools ..................................................................... 30
5.5. Energy Requirements ........................................................................................................ 31
5.6. Operational temperature range ........................................................................................ 32
5.7. Water resistance ............................................................................................................... 32
5.8. Packaging ........................................................................................................................... 33
5.9. Weight ............................................................................................................................... 34
5.10. GPS Availability .............................................................................................................. 34
5.11. Daytime / Nighttime operation ..................................................................................... 35
6. Functional Requirements – Sensing ..................................................................................... 37
7. Functional Requirements – UAS .......................................................................................... 38
7.1. Level of autonomy ............................................................................................................... 38
7.2. Required sensing modalities ............................................................................................... 39
7.3. Weather resistance .............................................................................................................. 40
7.4. Deployment & operations ................................................................................................... 41
Deliverable 100.1 – V 8.0
Page 6
8. Functional Requirements – UGVs ........................................................................................ 42
8.1. Level of autonomy ............................................................................................................... 42
8.2. Required (sensing) modalities ............................................................................................ 43
8.3. Required modalities for making structural changes to the environment ....................... 44
8.4. Environmental resistance .................................................................................................... 45
8.5. Robot mobility ...................................................................................................................... 45
8.6. Deployment & operational requirements ......................................................................... 49
9. Functional Requirements – Heterogeneous Teams ............................................................... 51
10. Functional Requirements – Communication ......................................................................... 52
10.1. Communication technology currently in use .................................................................... 52
10.2. Distance of communication ............................................................................................... 52
10.3. Bandwidth ......................................................................................................................... 54
11. Functional Requirements – C2I ............................................................................................ 55
11.1. Current C4I / C2I systems .................................................................................................. 55
11.2. Human-machine interfacing .............................................................................................. 55
11.3. Mapping ............................................................................................................................. 56
11.3.1. Need .............................................................................................................................. 56
11.3.2. Current tools .................................................................................................................. 56
11.3.3. Map size ......................................................................................................................... 57
11.4. Data exchange ................................................................................................................... 57
11.5. Software deployment ........................................................................................................ 59
11.6. Mobile applications ........................................................................................................... 60
12. Functional Requirements – Training & Support .................................................................... 62
13. Fine-tuning of Functional Requirements for USAR tools using end-user evaluation of
operational trials ........................................................................................................................ 63
13.1. Introduction ....................................................................................................................... 63
13.2. Operational Land Trial in Belgium ..................................................................................... 63
13.2.1. Scenario Description .......................................................................................................... 63
13.2.2. End-user feedback on Generic / Deployment issues ........................................................ 64
13.2.3. End-user feedback on Sensing ........................................................................................... 64
13.2.4. End-user feedback on UAS ................................................................................................ 64
Deliverable 100.1 – V 8.0
Page 7
13.2.5. End-user feedback on UGVs .............................................................................................. 64
13.2.6. End-user feedback on Heterogeneous Teams .................................................................. 70
13.2.7. End-user feedback on Communications ............................................................................ 72
13.2.8. End-user feedback on C2I .................................................................................................. 74
13.2.9. End-user feedback on Training and Support ..................................................................... 74
13.3. Operational Aerial Trials in Switzerland ............................................................................ 75
13.3.1. Scenario Description .......................................................................................................... 75
13.3.2. End-user feedback ............................................................................................................. 76
Part 3 – Maritime Search & Rescue Operations requirements ...................................................... 77
14. Application Scenarios and Use Cases for Unmanned Search And Rescue Tools ...................... 78
15. Typical organization of MSAR teams ................................................................................... 80
15.1. The MSAR system .............................................................................................................. 80
15.2. Levels of co-ordination ...................................................................................................... 80
15.3. MSAR stages ...................................................................................................................... 81
16. General User Requirements ................................................................................................ 82
User requirements for MSAR were mainly established from the information gathered through the
questionnaire but also from Portuguese navy officers working on MSAR. .................................... 82
16.1. Prioritization of developments .......................................................................................... 82
16.2. Operational Preparedness Requirements ...................................................................... 83
16.3. Mission planning Requirements ..................................................................................... 83
16.4. (Fast) Deployment Requirements ................................................................................... 84
16.4.1. Timing ........................................................................................................................... 84
17. Functional Requirements – USV .......................................................................................... 85
18. Functional Requirements – Unmanned Capsules (UCAPs) ..................................................... 89
19. Functional Requirements –UAS ........................................................................................... 94
20. Functional Requirements – Sensing ..................................................................................... 98
21. Functional Requirements – Heterogeneous Teams ............................................................... 98
22. Functional Requirements – Communications ....................................................................... 99
23. Functional Requirements – C2I ........................................................................................... 100
24. Training and support ......................................................................................................... 104
Deliverable 100.1 – V 8.0
Page 8
25. Fine-tuning of Functional Requirements for MSAR tools by end-user evaluation of operational
trials 106
25.1. Introduction ..................................................................................................................... 106
25.2. Trial Scenario ................................................................................................................... 106
25.3. End-user feedback ........................................................................................................... 107
Part 4 – Wrap up & Conclusions ................................................................................................. 109
26. Ethical / Legal / Security / Exploitation Issues .................................................................... 110
26.1. Ethical issues .................................................................................................................. 110
26.2. Legal issues ..................................................................................................................... 110
26.3. Security issues ................................................................................................................ 110
26.4. Exploitation issues ......................................................................................................... 110
27. Conclusions ....................................................................................................................... 112
27.1. Deployment Issues .......................................................................................................... 112
27.2. Sensing ............................................................................................................................ 113
27.3. UAS .................................................................................................................................. 113
27.4. UGVS ................................................................................................................................ 114
27.5. USVS AND RESCUE CAPSULES .............................................................................................. 115
27.6. Heterogeneous Teams ................................................................................................... 116
27.7. Communication .............................................................................................................. 116
27.8. C2I.................................................................................................................................... 117
27.9. Training & Support ......................................................................................................... 118
27.10. Ethical / Legal / Security / Exploitation Issues ................................................................. 118
APPENDIX A – REFERENCES ............................................................................................................ 120
APPENDIX B – USAR QUESTIONNAIRE FORM .................................................................................... 121
APPENDIX C – MSAR QUESTIONNAIRE FORM ................................................................................... 138
APPENDIX D – INSARAG EXTERNAL CLASSIFICATION REQUIREMENTS ................................................... 155
APPENDIX E – AIR TRANSPORT CAPACITY ......................................................................................... 168
Deliverable 100.1 – V 8.0
Page 9
List of Figures
Figure 1: ICARUS stand at the INSARAG Team Leaders Meeting in Den Haag, The Netherlands ......... 17
Figure 3 - User Prioritization of ICARUS developments ........................................................................ 29
Figure 4 - Manpower Requirements for USAR ...................................................................................... 31
Figure 5 - Battery Recharge ................................................................................................................... 32
Figure 6 - Water resistance for unmanned platforms ........................................................................... 33
Figure 7 - GPS availability ...................................................................................................................... 35
Figure 8 - Daytime / Nighttime operations ........................................................................................... 36
Figure 9 - Level of autonomy for the UAS ............................................................................................. 38
Figure 10 - Maximum wind speed for land operations ......................................................................... 40
Figure 11 - Level of autonomy for the UGVs ......................................................................................... 43
Figure 12 - Drop height for the different UGVs ..................................................................................... 46
Figure 13 - UGV slope-climbing ability .................................................................................................. 47
Figure 14 - UGV gap-crossing ability...................................................................................................... 48
Figure 15 - UGV height-crossing ability ................................................................................................. 49
Figure 16 - Maximum communication distance .................................................................................... 53
Figure 17 - Amount of data traffic allowed per day .............................................................................. 58
Figure 18 - Technology used for data-sharing ....................................................................................... 59
Figure 19 - Possibility to install software on PCs ................................................................................... 60
Figure 20 - Usefulness of mobile devices .............................................................................................. 61
Figure 21 - Usefulness of different training methodologies ................................................................. 62
Figure 22: Operational Land Trial test area ........................................................................................... 63
Figure 23: ICARUS SUGV inside the "school building" ........................................................................... 65
Figure 24: ICARUS SUGV on the staircase ............................................................................................. 66
Figure 25: Outdoor exploration ability .................................................................................................. 67
Figure 26: Tunnel-crossing ability .......................................................................................................... 67
Figure 27: Slope climbing ability ............................................................................................................ 68
Figure 29: Visual Perception system on the validation platform .......................................................... 69
Figure 30: Hazardous terrain inspection ............................................................................................... 70
Figure 31: UGV-UAV collaborative system ............................................................................................ 71
Figure 32: UAV during collaborative victim search and mapping operation ........................................ 71
Figure 33: Real-time imagery from the test UAS .................................................................................. 72
Figure 34: ICARUS Communication tools: Simulation of Test Site. ....................................................... 73
Figure 35: ICARUS Communication tools: measuring communication bandwidth using different
communication modalities as a function of the terrain ........................................................................ 73
Figure 36: Results of the 3D scan of the trial environment: Dense 3D point clouds (first 2 rows) and
rendered reconstructions (bottom row) ............................................................................................... 75
Figure 37: ICARUS UAS active during the operational trials in Switzerland. From left to right: the
ASCAMM rotorcraft, the Skybotix rotorcraft and the ETHZ fixed wing test platform .......................... 76
Figure 38– Usefulness of technologies for MSAR operations ............................................................... 83
Figure 39 - Number of extra team elements to operate unmanned platforms (MSAR) ....................... 84
Figure 40 - Battery autonomy for USVs ................................................................................................. 85
Deliverable 100.1 – V 8.0
Page 10
Figure 41 - Minimum USV range ........................................................................................................... 85
Figure 42 - Minimum USV speed ........................................................................................................... 86
Figure 43 - USV’s operational temperature range ................................................................................ 86
Figure 44 - Water resistance required for electronic enclosures in USV .............................................. 87
Figure 45 - Level of autonomy of USVs ................................................................................................. 87
Figure 46 - Maximum USV length .......................................................................................................... 88
Figure 47 - Maximum USV weight ......................................................................................................... 88
Figure 48 - USV deployment methods .................................................................................................. 89
Figure 49 - UCAPs battery autonomy .................................................................................................... 90
Figure 50 - Minimum range for UCAPs .................................................................................................. 90
Figure 51 - UCAPs minimum speed ....................................................................................................... 91
Figure 52 - UCAP operational temperature range ................................................................................ 91
Figure 53 - UCAP maximum weight. ...................................................................................................... 91
Figure 54 - UCAP maximum size ............................................................................................................ 92
Figure 55 - Number of people carried by UCAPs ................................................................................... 92
Figure 56 - UCAP Water resistance ....................................................................................................... 93
Figure 57 - UCAP operation at night/darkness ...................................................................................... 93
Figure 58 - Autonomy level of the UCAPs ............................................................................................. 94
Figure 59 - UAS Battery Autonomy (MSAR) .......................................................................................... 94
Figure 60 - UAS operational temperature range (MSAR) ...................................................................... 95
Figure 61 - UAS level of autonomy (MSAR) ........................................................................................... 95
Figure 62 - UAS sensing technologies (MSAR) ....................................................................................... 96
Figure 63 - Maximum wind speed for UAS operations (MSAR) ............................................................ 97
Figure 64 - UAS water resistance .......................................................................................................... 97
Figure 65 - Communication range for platforms (MSAR) ...................................................................... 99
Figure 66 - Technology currently used for communications (MSAR) .................................................. 100
Figure 67 - GPS reliability for MSAR end-users ................................................................................... 100
Figure 68 - GIS tools (MSAR)................................................................................................................ 101
Figure 69 - Map resolutions (MSAR) ................................................................................................... 101
Figure 70 - Map size (MSAR) ............................................................................................................... 101
Figure 71 - C2I framework (MSAR) ...................................................................................................... 102
Figure 72 - Data sharing services (MSAR) ............................................................................................ 102
Figure 73 - Satellite communications data traffic for a day (MSAR end-users) .................................. 103
Figure 74 - Ability of installing ICARUS software during an intervention (MSAR) ............................... 103
Figure 75 - Mobile applications usefulness (MSAR) ............................................................................ 103
Figure 76 - Training tools developments (MSAR) ................................................................................ 104
Figure 77 - Unmanned tools, required training time for MSAR end-user ........................................... 104
Figure 78 – Portuguese Navy ship Bacamarte. .................................................................................... 106
Figure 79 – Deployment of UCAP from ROAZ USV. ............................................................................. 107
Deliverable 100.1 – V 8.0
Page 11
Part 1 - Introduction
Deliverable 100.1 – V 8.0
Page 12
1. Introduction
1.1. Project Context In the event of a large crisis, a primordial task of the fire and rescue services is the search for human
survivors on the incident site. This is a complex and dangerous task, which, too often, leads to loss of
lives among the human crisis managers themselves. The introduction of unmanned search and rescue
devices can offer a valuable tool to save human lives and to speed up the search and rescue process.
Therefore, ICARUS concentrates on the development of unmanned search and rescue technologies for
detecting, locating and rescuing humans. In this context, there is a vast literature on research efforts
towards the development of unmanned search and rescue (SAR) tools, notably in the context of EU-
sponsored projects such as View-Finder, Guardians, SGL for unmanned SAR, etc. This research effort
stands in contrast to the practical reality in the field, where unmanned search and rescue tools have
great difficulty finding their way to the end-users.
The ICARUS project addresses these issues, aiming to bridge the gap between the research community
and end-users, by developing a toolbox of integrated components for unmanned search and rescue.
The objective of the ICARUS project is to develop robots which have the primary task of gathering data.
The unmanned SAR devices are foreseen to be the first explorers of the area, as well as in situ
supporters to act as safeguards to human personnel. In order not to increase the cognitive load of the
human crisis managers, the unmanned SAR devices will be designed to navigate individually or
cooperatively and to follow high-level instructions from the base station. The robots connect wirelessly
to the base station and to each other, using a wireless self-organising cognitive network of mobile
communication nodes which adapts to the terrain. The unmanned SAR devices are equipped with
sensors that detect the presence of humans and will also be equipped with a wide array of other types
of sensors. At the base station, the data is processed and combined with geographical information,
thus enhancing the situational awareness of the personnel leading the operation with in-situ processed
data that can improve decision-making. The Haitian experience has shown the importance acquired by
the geographic component in the management of human and technical resources in crisis situations.
Similarly, it has highlighted that a suitable distribution (through interoperable standards) and real-time
generation of thematic maps (demolished buildings, destroyed bridges, etc.) allows optimisation and
interoperability of these resources and accelerates the access to victims. All this information will be
integrated in existing C4I systems, used by the forces involved in the operations.
In line with the current bottlenecks, nine main objectives are defined for the ICARUS project. These
objectives address the operational needs of rescue and civil protection services and are defined and
evaluated by the end-users and are in line with the conclusions of the ESRIF Working Group on Crisis
Management, according to the ESRIF Final report of 2009. These objectives may be summarised as
follows:
Objective 1: Development of a light sensor capable of detecting human beings
Objective 2: Development of cooperative Unmanned Aerial System (UAS) tools for
unmanned SAR
Objective 3: Development of cooperative Unmanned Ground Vehicle (UGV) tools for
unmanned SAR
Deliverable 100.1 – V 8.0
Page 13
Objective 4: Development of cooperative Unmanned Surface Vehicle (USV) tools for
unmanned SAR
Objective 5: Heterogeneous robot collaboration between Unmanned Search And Rescue
devices
Objective 6: Development of a self-organising cognitive wireless communication network,
ensuring network interoperability
Objective 7: Integration of Unmanned Search And Rescue tools in the C4I systems of the
Human Search And Rescue forces
Objective 8: Development of a training and support system of the developed Unmanned
Search And Rescue for the Human Search And Rescue teams
Objective 9: Communication and dissemination of project results
1.2. Purpose of this document This document formally describes the user requirements for the different ICARUS developments. The
aim is to gather information from the end-users on the desired / expected capabilities of the ICARUS
system.
All technical developments within the ICARUS project will take this user requirements document (URD)
into account in order to ensure that solutions are developed which are acceptable and exploitable by
the end user community. Therefore, multiple draft versions of the URD are made available to the
ICARUS partners, even already at very early stages of the project, such that all partners can synchronize
their developments on a timely basis with the actual needs of the end-users.
The URD is intended as a base document for composing the ICARUS System Requirements &
Architecture Definition (SRAD) document, which will describe the architecture of the different ICARUS
subcomponents.
1.3. User Characteristics A thorough understanding of the end-user community is a key preliminary factor in order to be able to
define a correct set of end user requirements. In the case of ICARUS, it is clear that the tools to be
developed are targeted towards the international Search and Rescue (SAR) community. Two important
differentiating factors must be considered within the SAR community to denote the actors for certain
types of disasters:
1.3.1. National vs. International Intervention Teams
Crises which are handled at a national level (e.g. a collapsed high-rise) are generally handled
by the country’s civil protection/defense services, which depend in generally on the Ministry
of Internal Affairs. For international crisis relief operations (e.g. disaster relief after a major
earthquake or flooding), (multi-) national disaster response teams are sent to the disaster-
struck country. These disaster response teams can depend on other ministries like the Ministry
of Foreign Affairs or a collaboration of multiple ministries (e.g. B-FAST in Belgium).
Deliverable 100.1 – V 8.0
Page 14
It is evident that the needs of both communities are often the same, but sometimes also very
different. For disaster response teams, air transportability is for example a key factor, which
puts heavy constraints on the weight and size of all components to be carried along to the
disaster zone. This is less an issue for civil protection/defense services, which can generally
rely on road transport to get to the disaster zone.
ICARUS focuses its main attention towards the international SAR operations, however, without
forgetting the national crisis intervention troops, as they are considered to be possible early
adopters of the ICARUS tools. This approach gives the opportunity to deploy new technology
first at national level, and later, when it is better developed, also for international operations.
Indeed, for many new technologies, downsizing the weight and size of components is very
difficult early in the technological life-cycle, which impedes the deployability for disaster
response teams, but not that much for civil protection/defense services. Therefore, deploying
these tools first to the national civil protection/defense teams, and later, when they get
smaller and lighter to first aid and support teams, is a sensible solution.
1.3.2. Urban SAR vs. Maritime SAR
Another important distinction to be made depends on the terrain where the rescue operations are
taking place. There exists a separate urban SAR (USAR) and maritime SAR (MSAR) community and
both operate in a total different environment.
The international USAR community is organized at UN-level via the INSARAG secretariat. INSARAG has
established a world-wide network of USAR teams, developed a standardized set of Guidelines and
established an External Classification (IEC) system for USAR teams (see
http://www.insarag.org/en/methodology/guidelines.html). INSARAG provides a single point of entry
to access nearly (not every country is a member) the whole international USAR community.
For the MSAR community, such an international (regulatory) organization like INSARAG does not seem
to exist. Instead, collaboration is organized through bilateral collaboration between different naval
forces or marine rescue centres of individual nations.
The ICARUS project clearly targets both the USAR and the MSAR community. This is also reflected by
the inclusion of end users from both communities inside the consortium: for USAR there is the Belgian
First Aid and Support Team (B-FAST) and for MSAR, there is the Portuguese Maritime Rescue Command
Centre.
As the USAR and MSAR communities are quite separate, this means that it is required to foresee
separate user contact and user dissemination activities specifically targeted towards each of these
distinct communities. This is also the reason why this document is split up in a part (2) which
concentrates on the requirements of the USAR community and a part (3) which focuses on the needs
of the MSAR community.
Deliverable 100.1 – V 8.0
Page 15
2. Methodology of Information Gathering Figure 1 sketches the general methodology which was followed for obtaining the user requirements
and which will be explained in the following paragraphs.
A first step in the process of information gathering was to determine the optimal methodology for
information gathering. As the user requirements document is a critical document, which kick-starts
most of the technical developments within the project, it was really important to deliver a draft version
of this document to the project partners really soon (at M3). Providing such a document so early in the
project lifetime is made difficult by the diversity of the end-user community targeted by the ICARUS
project and the important duality which exists within this end-user community (see also section User
Characteristics). Therefore, to be able to provide a meaningful draft document early in the project, we
decided to follow a dual approach specifically tailored towards the different USAR and MSAR user
communities.
In a first stage (M1-M3), this information gathering methodology targeted only the USAR community,
in order to have a clear focus. We collected end-user requirements from previous research efforts
within the field of robotics for USAR. Among the numerous sources of information which were
collected, the most important ones, which contain information which was directly integrated in this
URD are:
The URD of the EU-FP6-IST project View-Finder (GA 045541): This research project considered
the development of chemi-resistor equipped robots for search and rescue applications. While
targeted at a smaller scale than ICARUS, the user requirements noted for this project are partly
also valid for ICARUS.
The UN-INSARAG guidelines: A comprehensive handbook, listing all requirements where
(human) USAR teams should adhere to in order to obtain an official INSARAG classification
code. In this URD, we translated – as much as possible – these requirements for human USAR
teams, towards requirements for robotic USAR teams. The philosophy behind this is that if
human and robotic USAR teams are to work in collaboration with one another, the
requirements for both must be on the same scale.
Chapter 50 “Search and Rescue Robots” of the Handbook of Robotics, edited by Bruno Siciliano
and Oussama Khatib and written by Robin R. Murphy, Satoshi Tadokoro, Daniele Nardi, Adam
Jacoff, Paolo Fiorini, Howie Choset,and Aydan M. Erkmen
In a following stage, we prospected the USAR end-user community to select key players that would be
willing to collaborate with us. We foresaw two levels of collaboration:
By becoming member of the end-user board: 5 USAR end-users were initially selected, paying
attention that their competences cover the whole area of USAR activities
By responding to questions we may pose them by web or mail: a database of contacts with 30
key players in the USAR community was composed and these people were contacted at regular
intervals
Deliverable 100.1 – V 8.0
Page 16
In a next stage, we decided to personally interview a select number of key USAR players, in order to
get a good “feel” of the requirements of this community.
Based on this very preliminary set of interviews, we developed a questionnaire, listing some key
questions we have for the end-users. This questionnaire received a first review by the end-users listed
above who helped to compose it. An iterated and updated version was then spread to the persons in
the database of contacts of key players in the USAR community, and this in the form of a web
questionnaire. This questionnaire can be found at the following web address
http://surveymonkey.com/s/ICARUS-USAR and at the end of this document in the Appendix B – USAR
Questionnaire Form.
Using this questionnaire, we were able to collect the views and opinions of key players in the user
community. As such, 37 responses were collected from the USAR community. It is possible to fill in the
questionnaire anonymously, so we cannot state the affiliations of all respondents.
Based on the first set of interviews, the preliminary results gathered from the web questionnaire and
the pre-existing data sources, a first draft of the URD was produced at M3. This draft version was sent
to the members of the consortium and was reviewed by the members of the end-user board at the
first meeting of the EUB on May 15th 2012. A second draft was released at M6 and reviewed at the
second EUB meeting of August 2nd 2012. A third draft was released at M12.
The third draft was extensively presented towards end-users and discussed with them at several
events:
ASEAN-meeting on urban search and rescue organization in Jakarta, Indonesia on 03/07/2013
B-FAST met with the ASEAN secretariat and delegates from the ASEAN group for a
workshop about disaster management. During the workshop B-FAST gave a
presentation about the ICARUS project highlighting the most important challenges in
technological development to be integrated in our project. ASEAN members showed
interest in the project and project flyers were distributed. Follow up by the Belgian
Ministry of Foreign Affairs resulted in a very positive feedback from all ASEAN
participants and a next (follow-up) meeting (probably in the Philippines) might be
organized in 2014.
DACH (Deutschland – Austria - Chweiz) - meeting on organizational and communication issues
in urban search and rescue, held in Schimpach, Luxemburg on 24/09/2013
The feedback received from this meeting was that the ICARUS URD fits very well to the
needs of the end-user community. Some recommendations are listed below:
Some of the ICARUS requirements on communication issues are based upon
possible future integration of the ICARUS communication framework in a
larger communication context like for example the Emergency.lu initiative,
providing satellite communication for (humanitarian) operations like SAR in
developing countries. The end-users pointed out that the timelines of both
projects are quite different: while Emergency.lu is already operational now,
ICARUS is a development for the future. They thus advised us not to constrain
ourselves too much with respect to these integration requirements, as it may
Deliverable 100.1 – V 8.0
Page 17
very well be that the technological choices in Emergency.lu have already
evolved further when ICARUS becomes operational.
The end-users did voice their concerns on the topic of the business model for
bringing the ICARUS tools to the market (which was also discussed during this
meeting) and where the URD suggests as one of the options to have a sharing
or pooling of resources, such that several USAR teams can use the same
robotic systems. The users explained that USAR teams have to be completely
self-reliant and are very keen on their “own” material, so a pooling system is
not popular in this context. We pointed out that resource pooling is only one
of the proposed exploitation models (based on experience in the USA with this
model) and forwarded the concern of the end-users to the exploitation WP
(WP520) such that they can start a dialogue with the end users to find an
exploitation model fitting as much clients as possible.
INSARAG team leaders meeting in Den Haag, Netherlands from 16/09/2013 to 18/09/2013. At
this meeting, the ICARUS project was present with an information stand (Figure 1), where the
end-users could collect information on the project and where they could get the draft URD
document. The content of this draft URD document was then discussed with them during one-
on-one meetings. All persons participating to these meetings also expressed their interest in
participating to the First European End User Conference on Unmanned Search and Rescue
organized in February 2014 by ICARUS and DARIUS and all their contact details were added to
the dissemination list (WP510) and list of possible exploitation targets (WP520).
Figure 1: ICARUS stand at the INSARAG Team Leaders Meeting in Den Haag, The Netherlands
The feedback received from this meeting was that - in general - the URD corresponds very well with
the requirements as the users do experience them. Some recommendations are listed below:
Deliverable 100.1 – V 8.0
Page 18
Many end-users did ask for the addition of a smaller scale ground robotic system in the
toolbox, preferably a snake-like robot. It is true that this would be very beneficial, but the
development of such systems goes beyond the scope of ICARUS, so this suggestion was not
followed up upon in the URD.
Many end-users also expressed their intent to start operations with unmanned aerial systems
for urban search and rescue operations and were very interested by our developments in this
area. We informed the end-users about these developments, the realistic capabilities to expect
from UAS and the legal framework which is to be taken into account. Some end-users pointed
out that – while the ICARUS URD constrains many of the capabilities of the UAS to be in line
with (upcoming) European regulation for the introduction of RPAS in European airspace (as
put forward in the European RPAS Roadmap) – many urban search and rescue operations take
place outside of Europe and in such a search and rescue context, the local UAS legislation (if
existent) often allows exemptions for access to airspace for UAS dedicated to search and
rescue. As a result, they advised us not to restrict ourselves too much to pure (upcoming)
European legislation (e.g. on maximum flight altitude) in this sense.
B-FAST Rep stressed again the importance of integrating the UAS within the INSARAG
guidelines to provide a worldwide common used standardized way of integrating UAS within
USAR activities and command structures as well as all necessary legal bases to obtain flight
permissions.
The end-users were generally very interested in the capabilities of the human detector sensor.
However, they advised us not to limit the use of this device to purely unmanned systems and
suggested that it could be a good idea to mount such sensors on search dogs (which can for
the moment still reach places within semi-demolished building where no robot can go).
Following up on this advice, ICARUS took contact with the International Rescue Dogs
Organisation (IRO) and put them into contact with the team developing the human detection
sensors, such that a test with ICARUS sensor on search dogs can be organized.
The users highly appreciated the ICARUS effort done on training and support, a topic often
overlooked by research projects. They did advise to make the training methodologies as
realistic as possible.
For further validation of the URD document, the final version of the URD document will be presented
at the First European Unmanned Search and Rescue End-Users' Conference organised by the ICARUS
and DARIUS consortia at RMA, Brussels, Belgium in February 2014. During this workshop, the DARIUS
and ICARUS efforts on user requirements gathering will be presented to the public and discussed with
them for final validation.
Starting from M3, we also turned our attention towards the MSAR community, where we followed a
similar approach to retrieve the user requirements for the MSAR community.
Deliverable 100.1 – V 8.0
Page 19
We collected end-user requirements from previous research efforts within the field of robotics for
MSAR. Among the numerous sources of information which were collected, the most important ones,
which contain information which was directly integrated in this URD are:
CRASAR (Center for Robot-Assisted Search and Rescue), Texas A&M University, that provides
information about opportunities and real world experiments of robotic tools in search and
rescue operations; and
AGaPas (Autonomous Galileo-supported Rescue Vessel for Persons overboard) – a national
German project lead by University of Rostock that aims at developing an autonomous vessel
for man overboard rescuing.
In the next stage, CINAV, INESC and RMA organized in May 2012 the Workshop “Technologies for
Maritime Search and Rescue”. This workshop joined member of ICARUS consortium (RMA, CINAV,
INESC, ESRI), the Maritime Rescue Coordination Centre (MRCC) Lisboa, and other stakeholders of
maritime search and rescue. It should be referred that MRCC Lisboa coordinates maritime search and
rescue operation over an area exceeding 5.7x106 km2 (about ten times the area of France). The
workshop was organized as a series of presentations from the participants followed by discussions
about the role of new technologies and more specifically of unmanned tools in search and rescue
operations. The discussion covered not only large scale SAR but also specific problems related to man
overboard or accidents with small fishing or leisure vessels. A presentation entitled “Training and
Coordination of SAR Operations”, presented by and officer of the Portuguese Navy was of very high
relevance for ICARUS as it discussed the organization of MSAR missions.
Based on both the questionnaire prepared for the USAR and on the discussions held at the workshop
we developed a questionnaire covering the most relevant identified issues. Initially, CINAV received
from MRCC Lisboa some feedback about the questionnaire and later on an updated version was
published. A set of key players was contacted and invited to answer it in the form of a web
questionnaire. This questionnaire can be found at the following web address
http://surveymonkey.com/s/ICARUS-MSAR and at the end of this document. This way it was possible
to collect feedback from key players in the user community. As such, 33 responses were collected from
the MSAR community. It is possible to fill in the questionnaire anonymously, so we cannot state the
affiliations of all respondents. A large number of respondents were from MRRC Lisboa or MRCC Ponta
Delgada (Portugal), but we also got some responses from Italy and Spain.
Deliverable 100.1 – V 8.0
Page 20
Figure 2: Methodology of Information Gathering
Deliverable 100.1 – V 8.0
Page 21
Part 2 – Urban Search & Rescue
Operations requirements
Deliverable 100.1 – V 8.0
Page 22
3. Application Scenarios and Use Cases for Unmanned Search And
Rescue Tools Before requirements can be given for robots executing certain SAR tasks, it is required to have
an idea on the effective tasks the robots would be able to do. In this context, CRASAR, the Centre
for Robot-Assisted Search and Rescue from the Texas A&M University, compiled a list of distinct
activities for rescue robots. This list was compiled based on feedback from responders and what
they’ve asked for or speculated on based on 15 CRASAR deployments and more than 30 exercises they
have participated in. This CRASAR list was used as a starting point and extended with data obtained
from interviews with key players of the end-user community. The activities and tasks relevant to
ICARUS are:
Area reduction. In the early stages of a disaster, there is in general a large area which must be labeled
as “possibly affected”. In order to deploy the USAR teams correctly and to spread the allocation of
efforts effectively, it is required to map as soon as possible which areas are more affected and which
areas are less affected. Satellite data is in general of no use for this, at there is too much delay on the
arrival of this data. Light UAS, able to fly below cloud cover, as the ones to be developed in ICARUS
WP220, could play a great role for this.
Sectorization. Incoming USAR teams need to be designated a sector in the disaster area. For this
reason, the disaster- struck area must be subdivided into sectors. Light UAS, as the ones to be
developed in ICARUS WP220, could help to get a good initial map of the area, such that it can be divided
into sectors intelligently.
Search. Robotic tools could speed up the search for victims or dangerous goods in indoor and
outdoor environments. This is one of the main overall focus points within ICARUS.
Reconnaissance and mapping. Robotic tools can help to increase the common operation picture
and situational awareness of the deployed teams by mapping the terrain. This is also one of the
main overall focus points within ICARUS.
Rubble removal. Robots can remove heavy rubble faster than humans. In ICARUS, this is a task
for the Large UGV in WP230.
Debris estimation. After a major crisis, there is in general a lot of debris lying around, impeding
the proper deployment of rescue operators and goods. Robots could help with a quicker and
better assessment of the most affected zones, which would allow rescue workers to seek
alternative routes. In ICARUS, this is a potential task for the UAS in WP220 and the UGVs in
WP230.
Structural inspection and shoring. USAR teams need to assess the structural integrity of a building
and may need to stabilize it before entering. This is a task an indoor robot can help with. In
ICARUS, this is a task for the indoor UAS in WP220 and the small UGV in WP230.
In situ medical assessment and intervention. Robots can provide doctors a means to inspect a
victim remotely via video or audio and to provide the victim life support (e.g. by deploying water) .
In ICARUS, this is a potential task for the small UGV in WP230.
Deliverable 100.1 – V 8.0
Page 23
Evacuation of casualties. Robots may act as carriers to evacuate victims from the disaster area.
In ICARUS, this is a potential task for the UGVs in WP230 and the intelligent life rafts in WP240.
Acting as mobile beacon or repeater. Robots can help with extending the mobile communication
range, by acting as a repeater. In ICARUS, this is a task for the UAS in WP220.
Over the horizon applications. Often, SAR teams want to know the damage in a nearby village / suburb
/ town. It would be highly convenient to be able to send a light UAS, as the ones to be developed in
ICARUS WP220, to inspect these areas. On the other hand, one must not forget that there is no current
legal framework for permitting such operations in beyond line of sight operations, so this must not be
the prime priority.
Deliverable 100.1 – V 8.0
Page 24
4. Typical organization of USAR teams International USAR activities are coordinated by the International Search and Rescue Advisory Group
(INSARAG), a network of disaster-prone and disaster-responding countries and organizations
dedicated to urban search and rescue (USAR) and operational field coordination.
This chapter gives an overview of the organization of SAR services and details the elements and
organization of these services. For a more detailed overview, the reader is referred to the INSARAG
guidelines document.
INSARAG activities are guided by United Nations General Assembly Resolution 57/150 of 2002 on
"Strengthening the Effectiveness and Coordination of International Urban Search and Rescue
Assistance" along with the INSARAG Hyogo Declaration adopted at the first INSARAG Global Meeting
in 2010 held in Kobe, Japan. INSARAG is mandated to:
Render emergency preparedness and response activities more effective and thereby save
more lives, reduce suffering and minimize adverse consequences.
Improve efficiency in cooperation among international USAR teams working in collapsed
structures at a disaster site.
Promote activities designed to improve search-and-rescue preparedness in disaster-prone
countries, thereby prioritizing developing countries.
Develop internationally accepted procedures and systems for sustained cooperation between
national USAR teams operating on the international scene.
Develop USAR procedures, guidelines and best practices, and strengthen cooperation between
interested organizations during the emergency relief phase.
UN OCHA
UN OCHA serves as the INSARAG Secretariat of the INSARAG Steering Group and is mandated
to coordinate international assistance in disasters and humanitarian crises exceeding the
capacity of the affected country. Many actors such as governments, Non-Government
Organizations (NGOs), UN Agencies and individuals respond to disasters and humanitarian
crisis. UN OCHA works with all participants and responds to disasters to assist the government
of the affected country in an effort to ensure the most effective use of international resources.
INSARAG Secretariat
Through structured reporting the INSARAG Secretariat facilitates coordinated communications
between the different elements of INSARAG including channeling through the INSARAG
Steering Group as required. On the practical side, the Secretariat ensures all events are
arranged in cooperation with identified hosts. The Secretariat also administers the INSARAG
website and the INSARAG USAR Directory. The Secretariat is hosted in the Field Coordination
Support Section (FCSS) of the Emergency Services Branch (ESB) of the United Nations Office
for the Coordination of Humanitarian Affairs (UN-OCHA) in Geneva.
Deliverable 100.1 – V 8.0
Page 25
LEMA
LEMA is the term used to describe the Local Emergency Management Authority and is the
ultimate responsible authority for the overall command, coordination and management of the
response operation. LEMA can refer to national, regional or local authorities, or combinations
thereof, which are collectively responsible for the disaster response operation.
UNDAC
The United Nations Disaster Assessment and Coordination (UNDAC) Team is a UN OCHA tool
used for deployment to sudden-onset emergencies. UN OCHA will dispatch an UNDAC Team
when requested to do so by the affected Government or the UN Resident Coordinator in the
affected country. UNDAC Team personnel are available around the clock and are able to
respond at very short notice. The UNDAC Team is provided free of charge to the affected
country.
UNDAC Team members are trained emergency managers from countries, international
organisations and UN OCHA. The UNDAC Team is managed by FCSS in UN OCHA Geneva and
works under the umbrella authority of the UN Resident Coordinator and in support of and
close cooperation with the LEMA.The UNDAC Team assists the LEMA with the coordination of
international response including USAR, assessments of priority needs and information
management by establishing an OSOCC.
International USAR Teams
Urban Search and Rescue teams are response assets from the affected country or from the
international community that respond to carry out search and rescue activities in collapsed
structures.
All USAR teams, irrespective of their capacity classification and operational involvement,
should comprise of the following components: Management, Logistics, Search, Rescue,
Medical.
It must not be forgotten that the majority of people affected by a disaster causing structural
collapse will be rescued by the community. This is done in the immediate aftermath of the
disaster and requires very little equipment. However, when victims are trapped in structures,
particularly heavily reinforced concrete structures, highly specialized skills and equipment are
required to locate, gain access and rescue victims.
Deliverable 100.1 – V 8.0
Page 26
The INSARAG Response Framework follows this diagrammatic representation of all levels of
response, starting with spontaneous community actions immediately following the disaster,
which is supplemented initially by the local emergency services and then by national rescue
teams. Finally, there is the response of international USAR teams, supporting national rescue
efforts.
To be able to respond to the varying needs at the incident site, ISARAG composed a USAR team
classification system, which identifies three levels of classification. These are Light, Medium
and Heavy USAR teams.
o Light USAR Teams have the operational capability to assist with surface search and
rescue in the immediate aftermath of the disaster. Light USAR teams usually come
from the affected country and neighbouring countries. It is normally not
recommended that Light USAR teams deploy internationally to emergencies.
o Medium USAR Teams have the operational capability for technical search and rescue
operations in structural collapse incidents. Medium USAR teams are required to be
able to search for entrapped persons. International Medium USAR teams travelling to
an affected country should be operational in the affected country within 32 hours of
the posting of the disaster on the VO. A medium team must be adequately staffed to
allow for 24 hour operations at 1 site for up to 7 days.
Deliverable 100.1 – V 8.0
Page 27
o Heavy USAR Teams have the operational capability for difficult and complex technical
search and rescue operations. Heavy USAR teams are required to be able to search for
entrapped persons use both canine and technical systems, and are envisaged for
international assistance in disasters resulting in the collapse of multiple structures,
typically found in urban settings, when national response capacity has either been
overwhelmed or does not possess the required capability. International Heavy USAR
teams travelling to an affected country should be operational in the affected country
within 48 hours of the posting of the disaster on the VO. A heavy team must be
adequately staffed to allow for 24 hour operations at 2 separate sites for up to 10 days.
Reception Departure Centre (RDC)
The RDC, an extension of the OSOCC, is established at points of entry into an affected country
(e.g. airports) for international response. The RDC is set up by the UNDAC team or by first
arriving USAR teams with the primary responsibility of facilitating the arrival and then later,
the departure of international response teams. The RDC works in close cooperation with
immigration, customs and other local authorities. If the RDC has been set up by a USAR team,
it will be handed over to the UNDAC team when they arrive.
Countries are encouraged to incorporate the establishment, staffing and operation of a RDC
into disaster preparedness plans and this should be practically tested during routine disaster
preparedness exercises.
On Site Operations Coordination Centre (OSOCC)
The OSOCC is established close to the LEMA and as close to the disaster site as is safely
possible. It provides a platform for the coordination of international responders and LEMA.
The OSOCC is established by the UNDAC team or by the first arriving international USAR team
who will then hand over the OSOCC to the UNDAC team when they arrive. The main purpose
of the OSOCC is to assist LEMA with the coordination of international and national USAR teams
as well as establishing inter-cluster coordination mechanisms (e.g. health, water/sanitation,
shelter).
In disasters where the devastation covers huge areas and there is a need for international
coordination at remote disaster sites, the UNDAC team or first arriving USAR teams in these
areas will establish a sub-OSOCC. When this situation arises, the main OSOCC will generally be
established in a major national coordination centre with one or more sub-OSOCC’s being
established at various disaster sites as required.
Virtual OSOCC (VO)
The VO is a web-based information management tool at http://ocha.unog.ch/VirtualOSOCC.
The VO is an information portal to facilitate information exchange between responders and
the affected country after sudden onset disasters. Access to the VO is restricted (requires a
password) to disaster managers from governments and disaster response organisations. The
VO is managed by FCSS, UN OCHA.
Global Disaster Alert and Coordination System
Deliverable 100.1 – V 8.0
Page 28
The Global Disaster Alert and Coordination System (GDACS) at http://www.gdacs.org, provides
the international disaster response community with near real-time alerts about natural
disasters around the world and tools to facilitate response coordination.
GDACS will be activated in major natural, technological and environmental disasters, which
overwhelm the affected country’s response capacity and require international assistance.
Deliverable 100.1 – V 8.0
Page 29
5. General User Requirements
5.1. Prioritization of developments
The end users were asked to rate the usefulness of the different technologies to be developed within
ICARUS. The results are presented in Figure 3, where the different developments are sorted from most
useful to less useful.
It must be taken into account that for this study, only the USAR community was targeted, so it must
come as no surprise that the marine platforms are deemed less useful, this is a result which can be
safely ignored.
Figure 3 - User Prioritization of ICARUS developments
What is striking is that, whereas it is clear that users see great value in most of the ICARUS
developments, this is less the case for the unmanned ground vehicles. This result of our own
questionnaire coincides with the results reported by CRASAR. The reason for this lies in the fact that
ground robots are handicapped by the sheer number of buildings that must be explored at least as
rapidly as a human team, compounded by the need to often break down a door or window in order to
insert the robot. It is unlikely that ground robots will be able to compete in the near future with canines
and their ability to smell the presence of survivors without having to break and enter intact buildings.
Deliverable 100.1 – V 8.0
Page 30
UAS, on the other hand, provide large opportunities, because they can offer a view of the situation
which is impossible to obtain by humans (because it is in general not possible to quickly get a lot of
large manned airplanes in the air) or even by satellites (because satellite data in general arrives too
late to still be of any use). Or, as one of our respondents put it: “Unmanned Aerial Systems will provide
the most effective tool to make an operational situation picture and to improve the situational
awareness of the affected area in a short timeframe”.
5.2. Operational Preparedness and Mission Planning Requirements
The International Search and Rescue Advisory Group has adopted an extended policy on operational
preparedness of crisis intervention teams and their tools. As it has no sense to develop a separate set
of requirements, ICARUS works in close collaboration with INSARAG to build upon the existing
framework of INSARAG requirements and extend these to unmanned platforms.
Depending the arrival time of USAR teams, authorities will most probably already have identified
priorities of potential USAR sites which have been selected on basis of potential survivability, number
of trapped persons and level of environmental danger on/around the site. Depending on information
available and distance to cover of the identified site(s), UAV assets can collect additional (missing)
information in order to analyse and prioritise USAR deployment (identify need of heavy or medium
teams, whether or not with CBRN capacity,…). Providing situational updates by means of UAV can also
be used for establishing the different USAR sectors with USAR coordination cells by the UNDAC team
during the USAR build-up phase.
5.3. (Fast) Deployment Requirements
Unmanned SAR tools which need to be deployed in a remote area, must meet the requirements
of air transportability. This poses great constraints on the weight and size of all unmanned
components. A number of important issues which must be carefully considered in order not to
impede the practical deployability of the developed tools are listed in this section.
Unpacking time as well as connection times should remain as short as possible in order not to
delay significantly the ongoing operation. Ideally, both activities (set-up time for unmanned tools
and individual preparation of USAR crisis workers) should be done in parallel with other
preparation activities of the USAR team.
5.4. Required manpower to operate the tools
SAR teams are invariably faced with a massive overload of work, so “sacrificing” people to operate
the robotic tools is not an easy compromise. The respondents were asked to indicate how many
extra team members they would be willing to include in their teams for operating the unmanned
platforms. The results are presented in Figure 4.
Deliverable 100.1 – V 8.0
Page 31
These results are of course dependent on the type of team: medium teams would have fewer places
in their team than heavy teams (to give an idea: medium teams have s suggested personnel count of
38 people, for heavy teams this is 55 people). However, as a general conclusion one can deduce from
Figure 4 that it is clear that no more than 2 people should be required to operate all robotic tools.
Figure 4 - Manpower Requirements for USAR
5.5. Energy Requirements
Continuous electrical power supply is not a certainty in disaster areas. In general, SAR teams need to
count on their own power sources. In general a power generator is used for these purposes, and –
more and more – also solar panels. Care must be taken that the robotic tools do not require more
electrical power (e.g. for recharging) than can be given by these power generators. The user survey
(illustrated by Figure 5 - Battery RechargeFigure 5) showed that most teams have access to power
generators of up to 2kVA, so this should be seen as an upper limit for electrical power draw.
Deliverable 100.1 – V 8.0
Page 32
Whereas this former value must be seen as the absolute maximum power draw, it would be wise to
foresee the possibility to charge on solar panels, which would limit the maximum power to about
200W.
In any case, energy consumption should be minimized as much as possible. If possible, self-sufficient
tools and standard batteries, which are available worldwide, are preferred. Users also reported that
the batteries should be rechargeable within 2 hours (or at least within 4 hours) and the maximum
weight in kg of exchangeable spare batteries should be around 6kg and in any case no more than 10kg.
Figure 5 - Battery Recharge
5.6. Operational temperature range
Users reported the mean operational temperature range to be between -20°C and +50°C.
5.7. Water resistance
SAR teams are often working in wet conditions. As a result, also the unmanned systems should be
water-resistant. To assess the required level of water resistance, the end users were asked to indicate
Deliverable 100.1 – V 8.0
Page 33
the desired level of water resistance they would desire for the UAS and UGVs separately, according to
the Ingress Protection Rating or IP code. The results are presented in Figure 6.
As shown on Figure 6, the requirements on level water resistance are in general higher for UGVs
compared to UAS. The mean desired IP level for UAS is around IP4, whereas the mean desired IP level
for UGVs is around IP5.
Figure 6 - Water resistance for unmanned platforms
5.8. Packaging
Goods to be transported over the air must fit in the cargo bay of standard aircraft used for rescue
operations. Aircraft cargo space is very expensive, certainly at the moment of a crisis operation when
many airplanes are demanded in a short period of time. As such, also the size of the package must be
kept to a minimum. Appendix E lists the capacities of typical aircraft and helicopters used for rescue
operations. Realistically, it can be put that the whole package should fit on 2 standard euro-pallets,
which limits the dimensions to 120cm x 160cm x 95cm.
Robotic tools which are transported over the air must also convey to a number of other requirements:
Deliverable 100.1 – V 8.0
Page 34
Everything must be able to be packaged in a convenient and easy-to-handle package
The package must not only contain the robotic tools themselves, but also the tools to repair
them
The package may not contain any dangerous goods, to avoid problems and delays with
customs
It must be possible to deliver this package at the national airport, within 6 hours after getting
notice of deployment.
5.9. Weight
The weight of the total package is an important issue and must of course be brought to a minimum.
The maximum mass for a package can be estimated at 100kg. This is the maximum weight for a package
to still be offloaded from a cargo plane by 2 humans. If the mass exceeds this number, then a fork lift
is likely necessary, which is often problematic in crisis areas.
(Spare) batteries are likely to account for a sizeable fraction of the total package weight. The end users
were asked to give an estimate on the weight of the batteries they would be able to take along, but no
conclusive results could be drawn from the responses, as they showed too much incoherence. Of
course, battery weight should be minimized as well, seeking a compromise between platform
autonomy (see also later) and weight.
5.10. GPS Availability
The end-users indicate that whereas GPS reception is generally available, this availability is sometimes
only partial, so this should be taken into account.
Deliverable 100.1 – V 8.0
Page 35
Figure 7 - GPS availability
5.11. Daytime / Nighttime operation
The end-users indicate that both UGVs and UAS should be able to operate in total darkness. This
requirement is mostly relevant for the indoor platforms, as – in many cases – USAR operations are
paused during the nighttime for security reasons, although some teams note that they work 24/7.
Some USAR teams also report that the night time would be the ideal time for robot interventions, as
it is calmer and unmanned vehicles could be less constrained by security problems.
Deliverable 100.1 – V 8.0
Page 36
Figure 8 - Daytime / Nighttime operations
Deliverable 100.1 – V 8.0
Page 37
6. Functional Requirements – Sensing The end users were asked what sensor (technology) is currently mostly missing for USAR operations.
The most prevalent responses (in decreasing order of times that they were mentioned) are:
(small) IR cameras [31%]
Reliable deep-penetrating radar technology [23%]
Imaging (video/ still cameras) technology (e.g. for on dogs)) [15%]
Breathing sensor [15%]
Chemical sensing technology [7.5%]
Aerial reconnaissance technology [7.5%]
Artificial sniffer replicating dog scent [7.5%]
The results of this question clearly show the need for a small IR human detection camera, which
reinforces the focus ICARUS places on the development of this sensor technology. From the user point-
of view, it is useful to have the possibility to create an overlay of visible light + IR data in order to detect
trapped people covered by dust and estimate at the same time effort for rescue out of the rubble
Any machine-learning based detection methodology will need to make a compromise between
detecting absolutely all occurrences (e.g. of human signatures) and having a large number of false
positives on the other hand. As this will likely be a key parameter in the detector tuning process, the
end users were asked what % of missed victims (false negatives) they would be able to accept. The
results are surprisingly quite unanimous: a false negative ratio of 23% would still be accepted.
However, the end-users noted that when dogs are used, the accepted level of false negatives is 0%
(dogs must achieve 100% detection), so the ICARUS developments should also strive towards this
figure.
To achieve such a high detection rate, the end users suggests to reduce the sensitivity bandwidth of
the camera drastically, e.g. to between 20°C and 45°C, such that humans can be easily discerned.
As the sensor will likely operate in difficult environmental conditions (dust, wet environments …), it is
essential that the sensor is well protected against dust and water and that the lens system can easily
be cleaned.
The end-users would like to be able to operate the sensor as a handheld device. This means that the
weight should be maximum about 7kg and the dimensions (length/width/height around
(20cm/20cm/20cm). Also for this reason, the power consumption should be minimized to maximum
30W.
Deliverable 100.1 – V 8.0
Page 38
7. Functional Requirements – UAS As reported before, the end-users see great opportunities for the use of UAS in a SAR context.
Possible applications which were specifically mentioned by the end users are helping with
sectorization, wide area mapping, damage assessment and over-the-horizon applications for post
earthquake / tsunami / flood / cyclone / building collapse SAR operations. In summary, small and
light UAS are seen as tools with great opportunities for quickly increasing the situational
awareness of the SAR workers. Next to this, also the application for the UAS to act as a as
communication relay system is deemed very interesting by the end-users, as communication is
often very difficult on the crisis site. However, in order to enable the use of UAS in SAR operations,
a number of technological, legal and deployment issues need to be considered.
7.1. Level of autonomy A first compromise which needs to be sought is the level of autonomy for the UAS. Many end -
users indicated us that in practical SAR operations, the UAS will always need to be flown manually
(tele-operated within line of sight) for safety and legal reasons. Evidently, this request clashes
with the desire of scientists wanting to equip their platforms with intelligent autonomous
navigation systems. In order to seek a compromise between these 2 views, the end-users were
asked to indicate the level of autonomy they would see feasible to work with depending on the
different UAS platforms. The results are presented on Figure 9.
Figure 9 - Level of autonomy for the UAS
Deliverable 100.1 – V 8.0
Page 39
It can be noted from Figure 9 that – especially for the larger outdoor UAS like the endurance
airplane and the gyropendulum – the end-users would accept a level of autonomy where the UAS
flies a predefined GPS trajectory without much user intervention. The introduction of this level
autonomy would be used mainly for alleviating the task of the operator, not for replacing the
operator. Whereas the users see the advantage of having auto-piloting on UAS, many users report
that they will always keep an operator on the UAS, because it would be unforgivable to miss a
victim which was actually seen by the camera(s) of the UAS. For the smaller and certainly the
indoor platforms, the end users tend to rely more on tele-operation, maybe just aided by some
local obstacle avoidance or autonomous takeoff and landing.
Whereas these are the wishes from the end-users, one must not forget that legal issues also play
a role in this matter. Allowing unmanned aircraft in airspace is already a delicate issue and
allowing autonomous aircraft will be even more so. As a result, it must be foreseen that –at all
time - the ICARUS UAS can switch to complete tele-operation and act as Remotely Piloted Aircraft
(RPA) in order not to limit their deployability in the field.
7.2. Required sensing modalities The end-users were asked to indicate and prioritize the required sensing modalities they would
like to see installed on the UAS. In order of priority, the following sensing modalities were
mentioned:
1. Visual sensing. As vision is the primary human sensing modality, a still camera or video
camera remains the most important sensory input one can get from a mobile platform.
ICARUS does not explicitly tackle the development of new visual sensing technologies, as
they are considered mature technologies. However, the users do request more powerful
tools for co-registration of visual images to obtain a visual map of the environment. Open
source initiatives in this direction do exist (e.g. Bundler
http://phototour.cs.washington.edu/bundler/ ), so it may be a good idea to integrate this.
2. IR camera. Visual cameras are blind in darkness, so IR vision is required, certainly as it
provides an efficient means of detecting victims. In ICARUS, a small IR camera is
developed for use on UAS systems.
3. Human victim detection sensor. The users want to know fast where there are survivors to
be found. This is considered by ICARUS through the development of an IR-camera-based
human detector.
4. 3D Mapping. Users request this sensing modality mostly for indoor platforms, as it can
give them an idea of the (structural integrity of the) damaged building before entering. It
must be noted that the end-users do not request this sensing modality to be absolutely
real-time, in contrast to the other sensing modalities.
5. Positioning. Spatial information on the place where data was recorded is essential. In an
outdoor setting, GPS provides ample positioning information, but for indoor use,
techniques like Simultaneous Localization and Mapping (SLAM) will need to be
incorporated to provide positioning information.
Deliverable 100.1 – V 8.0
Page 40
7.3. Weather resistance UAS to be used in a SAR context will require a certain ability to operate in difficult weather &
environmental conditions, as compared to pure research platforms. The users were asked to
indicate these operational conditions for the different usage scenarios. These are some
conclusions:
All indoor systems must be able to operate in total darkness
All outdoor systems must be able to operate in twilight conditions
In land operations, normally one is supposed to be able to work with wind speeds up
until 40-50 km/hr. This is a very hard constraint for most small and low-altitude UAS,
but is already a compromise between the desires of some end users who request even
operability up until 60km/hr, as depicted on Figure 10.
All UAS should have protection level 3 for liquid ingress protection
The indoor UAS should have protection level 6 for solid particle (dust) protection
The outdoor UAS should have protection level 5 for solid particle (dust) protection
It may seem strange that the level of water resistance is not so high. This is due to the fact that
– in any case – it is not possible to operate these systems in really bad weather because of the
poor visibility. The water resistance must therefore be seen more as a safety measure to enable
the device to return to the base when bad weather arrives.
Figure 10 - Maximum wind speed for land operations
Deliverable 100.1 – V 8.0
Page 41
7.4. Deployment & operations Battery autonomy is a critical issue in the design of UAS due to the important compromise to be
made between weight and operational time. The required level of battery autonomy largely
depends on the mission and the distance to be covered by the UAS. To assess this issue, the end
users were asked to describe some typical usage scenarios.
Scenario 1: Over the horizon
This scenario is the most demanding one on the level of battery autonomy and on the required
communication range, so only the endurance airplane is concerned for this application. The
scenario considers the application where the SAR teams would want to assess the level of damage
in a nearby city by flying a UAS to this city (a situation which occurred during the earthquake in
Padang, Indonesia). The distance to be covered in this application is 50km (one way).
Scenario 2: Sectorization
This scenario considers the initial mapping of a destroyed area to obtain a map, used for
deploying SAR teams. This is a necessary step in each crisis deployment, and assistance of UAS
would be very valuable for this. The distance to be covered here is in general the area of a city
(e.g. Port-au-Prince after the earthquake, Brazzaville after the explosion of an ammunition
depot), meaning that the UAS should operate within a radius of about 15km.
Scenario 3 & 4: Area mapping & Victim search
These two scenarios are bundled, because they have more or less the same requirements from
an autonomy point of view. The area mapping scenario considers the topological mapping o f a
destroyed area, whereas victim search considers overflying a designated area while searching for
human survivors. In both of these scenarios, the end users prefer to keep the UAS within eyesight
which would limit the operation to a radius of about 1 to 2 km.
Scenario 5: Indoor mapping & victim search
This indoor scenario considers an UAS entering a semi-destroyed building to search for victims
and to give the human SAR workers a view on the structural integrity of the building. Typically,
the UAS would be operated from nearby the inspected building, making the operational range
about 500m.
In all scenarios, it should be possible to recharge the batteries within 2 hours to maximize the
operational efficiency of the UAS.
Deliverable 100.1 – V 8.0
Page 42
8. Functional Requirements – UGVs ICARUS foresees the development of two UGVs:
A large UGV (LUGV) equipped with a crane arm which is capable of navigating through
rough terrain and making structural changes to the environment.
A small UGV (SUGV), which is capable of entering buildings while searching for human
victims
It is clear that the requirements for both systems are quite different, so these systems are
treated separately in this section.
Whereas the USAR teams see great use in the LUGV system, they doubt the deployability of the
system for “international” disasters, due to the difficulty of air transportability. Nevertheless,
the LUGV is regarded as a great tool for disaster relief; the USAR teams noted several examples
of crises in Europe where the existence of a system like the LUGV would have saved human lives
(L’Aquila earthquake in Italy, Building collapse in Liege, Belgium) . Therefore, they suggest an
exploitation scenario where developed nations (e.g. EU countries) would each buy one unit
which is put on guard to intervene when a disaster strikes at national level. For crises where
international rescue teams are sent to the disaster site, the SUGV is seen as a valuable tool , if it
can be made robust enough to deal with the difficult operational conditions.
8.1. Level of autonomy Also for the UGVs, the level of autonomy to be incorporated in the system is a delicate exercise.
The end-users were asked to indicate the level of autonomy they would see feasible to work with
depending on the different UGV platforms. The results are presented on Figure 11.
The results of Figure 11 show that nearly no end-users are willing to accept a level of autonomy
for the LUGV which goes beyond some local obstacle avoidance. Probably, this is due to safety
considerations, as the LUGV is a heavy machine.
For the SUGV, there is a slightly wider acceptance of the introduction of autonomy, even up to
the level of high-level semantic task execution.
Deliverable 100.1 – V 8.0
Page 43
Figure 11 - Level of autonomy for the UGVs
8.2. Required (sensing) modalities The end-users were asked to indicate and prioritize the required (sensing) capabilities they would
like to see installed on the UGVs. In order of priority, the following capabilities were mentioned:
1. Visual sensing. As vision is the primary human sensing modality, a still camera or video
camera remains the most important sensory input one can get from a mobile platform.
ICARUS does not explicitly tackle the development of new visual sensing technologies, as
they are considered mature technologies. However, the users do request more powerful
tools for co-registration of visual images to obtain a visual map of the environment. Open
source initiatives in this direction do exist (e.g. Bundler
http://phototour.cs.washington.edu/bundler/ ), so it may be a good idea to integrate this.
2. Human Victim Detection sensor. The users want to know fast where there are survivors
to be found. This is considered by ICARUS through the development of an IR-camera-
based human detector.
3. IR camera. Visual cameras are blind in darkness, so IR vision is required, certainly as it
provides an efficient means of detecting victims. In ICARUS, a small IR camera is
developed for use on UGV systems.
Deliverable 100.1 – V 8.0
Page 44
4. Loudspeaker and microphone. Bidirectional communication with (trapped) victims is
essential to assess the needs of the victims and to give life-saving advice, so audio
communication tools are high on the priority list.
5. Air quality sensor (oxygen / toxic gasses). Before entering a building, the SAR workers
want to know whether the atmosphere inside the building is safe to enter or whether
they must wear protective equipment.
6. Medical: heartbeat measurement. SAR workers want to assess whether trapped victims
are dead or alive (for triage purposes). A heartbeat measurement sensor would be ideal
for this, but it remains to be seen whether this request is realistic.
7. Radioactivity measuring device (dosimeter). Radioactivity measurement is high on the
agenda, especially after the Tohoku earthquake in Japan and the dramatic collapse of the
Fukushima power plant caused by this earthquake and subsequent tsunami.
8. 3D Localization & Mapping. Users request this sensing modality mostly for the indoor
SUGV platform, as it can give them an idea of the (structural integrity of the) damaged
building before entering. It must be noted that the end-users do not request this sensing
modality to be absolutely real-time, in contrast to the other sensing modalities Chemical
sensor (explosives, ...). Before entering a building, the SAR workers want to know whether
the atmosphere inside the building is safe to enter or whether there are dangerous
products in the environment.
9. Small drilling system with fiber optical camera. Having the possibility to drill a small hole
in a wall and insert a fiber optical camera to see what’s hiding behind the wall is an
interesting capability. However, it must be noted that this capability received a low
priority grade among the mentioned capabilities. As such, it remains to be seen if it is
useful / economical to invest in the development of such a technologically challe nging
(and weight-increasing) system
10. Small basket (water, food, medicine deployment). This - fairly easy to implement and low-
tech – capability is judged potentially interesting by the end-users.
8.3. Required modalities for making structural changes to the environment This section focuses more specifically on the capability of the robotic tools to drill holes in walls ,
break or replace rocks ... This capability is mostly important for the LUGV. The end-users were
asked whether they deemed it useful to equip the SUGV with a crane arm (which would enable
such operations on a small scale). Surprisingly, 94% of the respondents indicated that they prefer
to have no arm on the SUGV, as this would add to the weight of the device.
In order to define the requirements for the tools for making structural changes, the optimal work
plan is to align the requirements of the ICARUS with the requirements of the USAR teams as
defined by the INSARAG guidelines. On this topic, the INSARAG classification requirements define
two levels of capability, depending on the classification level of the USAR teams:
Medium team: The team’s rescue component will be equipped with hydraulic, pneumatic
and mechanical equipment for lifting and lowering loads up to 12 metric tons, for cutting
Deliverable 100.1 – V 8.0
Page 45
metal debris up to 10mm, timber up to 450mm and for breaking concrete up to 300mm
thick.
Heavy team: The team’s rescue component will be equipped with hydraulic, pneumatic
and mechanical equipment for lifting and lowering loads up to 20 metric tons, for cutting
metal debris up to 20mm, timber up to 600mm and for breaking concrete up to 450mm
thick. In addition, the team will have the equipment and capability to assemble vertical,
horizontal and diagonal shoring systems.
8.4. Environmental resistance UGVs deployed in a crisis environment need to withstand operational conditions which are very
technology-unfriendly. The users were asked to indicate these operational conditions for the
different usage scenarios. These are some conclusions:
The SUGV must be able to operate in total darkness
The LUGV must be able to operate in twilight conditions
All UGVs should have at least protection level 4 for liquid ingress protection
All UGVs should have protection level 6 for solid particle (dust) protection
All UGVs should be capable of withstanding a fall of about 1.0m, which is the height of a
typical table. (see also Figure 12 - Drop height for the different UGV)
All sensors on the UGVs should be easily cleanable, as they are likely to get covered with
dust.
All UGVs should be able to operate within a temperature range of -10°C to +50°C
8.5. Robot mobility In crisis areas, the terrain where the unmanned vehicles have to navigate over is often totally
devastated, which poses heavy requirements on the mobility capabilities of the UGVs. The users
were asked to give an idea on these mobility requirements, based on typical usage scenarios.
Here are some results:
As indicated by the results presented by Figure 13, the slope climbing ability for both the
SUGV and the LUGV should be between 30° and 45°.
As indicated by the results presented by Figure 14, the gap-crossing ability should be about
20cm (maximum 45cm) for the SUGV, whereas the LUGV is expected to traverse larger
voids, even up to 80cm.
As indicated by the results presented by Figure 15, the height-crossing ability should be
around 20 cm for the SUGV, and around 50cm for the LUGV
Deliverable 100.1 – V 8.0
Page 46
Figure 12 - Drop height for the different UGVs
Deliverable 100.1 – V 8.0
Page 47
Figure 13 - UGV slope-climbing ability
Deliverable 100.1 – V 8.0
Page 48
Figure 14 - UGV gap-crossing ability
Deliverable 100.1 – V 8.0
Page 49
Figure 15 - UGV height-crossing ability
8.6. Deployment & operational requirements For easy deployment of the SUGV in an international crisis context, air transportability is a key
issue, which means that the size and weight of the device must be kept under control. As the
LUGV is more seen as a road transportable device, used for crises at national level, weight and
size are less an issue. We did ask the end users about possible weight and dimensions of the
LUGV, and apparently they see it as a car-like device (width and height of about 1.5m, length of
about 3.0m and weighing about 1 ton).
The end-users indicate that a mass of 100kg is an absolute maximum for a SUGV, otherwise a
forklift would be needed for disembarking the robot from the cargo plane, which would slow
down the deployment too much. However, the end-users would largely prefer a SUGV which is
easy to handle and man-packable, meaning that it can be lifted by one operator, which would
limit the mass to around 50kg.
Following the same reasoning, the SUGV should preferably fit on 1 standard euro -pallet (80cm x
120cm). If this is not possible, two euro-pallets (160 cm x 120cm) must be seen as an absolute
maximum dimension.
Deliverable 100.1 – V 8.0
Page 50
Every crisis is different, and it is probably not possible to construct a one-size-fits-all robotic
solution to handle all crises. Therefore the robot design should be modular, to be able to
incorporate different capabilities on-the-fly.
When in operation, all UGVs should have a battery autonomy of at least 2 hours and it should be
possible to recharge the batteries within 4 hours.
While operating, a remote operator will always keep an eye on the robot. In typical conditions,
this operator would be no more than 500m away from the robot. However, as e.g. the SUGV will
likely enter buildings, one cannot assume a line-of-sight communication between the operator
and the robot. Communication across reinforced concrete building rubble needs to be
considered.
The end-users deem it useful to store a local backup of all recorded data on the robot itself. This
(raw) data, which would probably require too much bandwidth to send to the operator while in
operation, can then later be downloaded and analyzed at a base station, as it could contain useful
information for the SAR workers.
Deliverable 100.1 – V 8.0
Page 51
9. Functional Requirements – Heterogeneous Teams This section is underdeveloped in this first draft as little qualitative user feedback was recorded on this
topic. The main reason for this is that most end users have never worked with robotic SAR tools, so
they have no idea on the interoperability problems required to be solved in order to enable
heterogeneous systems to collaborate together.
The end-users did see multiple interesting application scenarios for heterogeneous teams. For multiple
UAS, this would mainly be collaborative mapping and damage assessment. Despite these application
scenarios which were mentioned, there is a fear in the user community that focusing on
heterogeneous collaboration strategies would over-complicate the overall system. Some users also
doubt the usefulness of having multiple collaborative UAS, as 1 unit is already capable of covering a
large area. The ICARUS partners will probably have to explain better to the end users that the different
UAS platforms also have different capabilities (e.g. endurance airplane for wide area mapping,
rotorcraft for a more targeted approach).
Also for collaborative UAS and UGVs, the end users saw different usage scenarios, like damage
assessment and aerial reconnaissance, followed by ground intervention. However, it must be noted
that due to the organization of a typical USAR team, ground and air robots would be always handled
by separate people. USAR teams have people working on situation assessment (and these would use
the UAS) and other people working on searching (and these would use the UGVs). As a result, there
would be no common operator for UGVs and UAS.
Deliverable 100.1 – V 8.0
Page 52
10. Functional Requirements – Communication Communication is an essential aspect for keeping the different subsystems working well. In the event
of a major crisis, a lack of communication between SAR teams is often the primary factor which slows
down the SAR operations or reduces the efficiency. Therefore, improving the communication
technology is deemed extremely useful by the end-users. Luxemburg is already working on such a
communications solution specifically targeted for crisis management: http://www.emergency.lu
ICARUS should seek synergies.
One must be aware that in a disaster-affected area, the local communication infrastructure is often
largely dysfunctional. Often, mail and telephone connections do not work. Skype chat is one of the
most robust services to keep a conversation. This clearly shows that ad-hoc communication tools are
required.
10.1. Communication technology currently in use Nowadays, SAR tools mostly use voice communication to communicate between teams or inside the
team. The end-users were asked to indicate the current communication technology they use on the
field. These are the results:
100% of the end-users use communication over the local mobile phone network
94% of the end-users use communication over satellite phones
72% of the end-users use WiFi for communication
67% of the end-users use VHF for communication
39% of the end-users use TETRA for communication
0% of the end-users use WiMax for communication
In order to be able to integrate with existing equipment in use, the end users were also asked what
communication middleware they currently use. 100% of the end-users reported that they currently
use no form of communication middleware whatsoever, so it seems like - on this aspect – the ICARUS
partners are free to choose their communication middleware.
10.2. Distance of communication The distance over which data needs to be transmitted plays a major role in the choice of a
communication technology. Therefore, the end-users were asked to sketch likely usage scenarios, as
already briefly described in sections 3 and 7.4.
The command strategy which is used in general in the event of a major disaster, calls for the installation
of a base of operations in a safe place, which can be up to 50km from the intervention zone. At this
base of operations, high-level data is gathered (and integrated on situational maps). It is clear that
sending high-bandwidth data like video over such a distance is not easy, but this is also not deemed
indispensable by the end-users.
Deliverable 100.1 – V 8.0
Page 53
Closer to the intervention zone, there would be robot operators of the SAR teams. The end-users were
asked to estimate the maximum distance between these operators and the unmanned platform(s).
The results can be seen on Figure 16. As these results were gathered from data provided by the USAR
community, the results concerning the marine platforms should better be disregarded, as they are not
very meaningful.
Figure 16 - Maximum communication distance
As can be noted from Figure 16, the maximum communication distance between the robot operator
and the UGVs would never exceed 1km and would be in most cases maximum 500m (as reported
before). As the UGVs, and more specifically the SUGV, will most likely enter semi-destroyed buildings,
it should be considered that this communication between the operator station and the robot will need
to traverse (reinforced) concrete structures and will be heavily NLOS in any case.
For the aerial vehicles, the results of Figure 16 are more varied, as this depends on the platforms and
the application scenarios. The reader is referred to section 7.4 of this document, where the maximum
communication distance between the operator and the UAS is detailed for a number of typical UAS
usage scenarios.
Deliverable 100.1 – V 8.0
Page 54
10.3. Bandwidth The analysis of the required bandwidth for the ICARUS tools must be split into two parts:
“External” communication to the internet.
This type of communication must be seen as unreliable, as in a crisis area, it is not possible to
guarantee a permanent uplink to the world wide web. This type of communication is typically
also excessively expensive (see also section 11.4 on C2I), so any data traffic must be limited to
the maximum.
“Internal” communication between ICARUS tools.
The ICARUS developments on communication technology must see to it that this type of
communication is made reliable; otherwise it will not be possible to control the different
platforms. To assess the bandwidth requirements for internal communication, the
requirements of the end-users concerning the different platform capabilities were analyzed.
Following this analysis, it was shown that the amount of live video data will probably be the
most important factor in the equation for determining the bandwidth. The end-users require
a live video feed of at least 20 frames per second to control the unmanned platforms.
Depending on the camera resolution and the compression technology, this will decide on the
required bandwidth.
Deliverable 100.1 – V 8.0
Page 55
11. Functional Requirements – C2I
11.1. Current C4I / C2I systems One of the main objectives of ICARUS WP320 is to ensure that all developed technologies are well
integrated with the standard operating procedures of first responders. Therefore, the end-users were
asked to give an idea on the C4I infrastructure they are normally confronted with. Many users reported
that in general, there is no C4I capacity present in crisis areas, as these crises often happen in
underdeveloped countries, which have no disaster response infrastructure. If a C4I capability does
exist, it is often the national military who organizes this using closed source services, and it is
impossible to integrate with those. Few countries do seem to have a standardized approach towards
command and control or management of crisis response. The most cited ones are:
ICS. The Incident Command System (ICS) was developed in the mid-1970s in the USA and has
become the national standard in the USA among emergency response agencies. More
information on ICS can be found here:
http://www.fema.gov/emergency/nims/IncidentCommandSystem.shtm
NIMS. After the 9/11 terrorist attacks on the United States, the National Incident Management
System (NIMS) was established. The NIMS builds on ICS and establishes a framework for crisis
management regardless of scale of the emergency. Local, state, and federal USA response
entities are required to adopt and implement NIMS. More information about NIMS can be
found here: http://www.fema.gov/emergency/nims/
AIIMS. The Australasian Inter-Service Incident Management System (AIIMS) is based on NIMS
and also describes a structured command, control and coordination framework to facilitate
cross-organizational cooperation by describing common roles concepts and processes for
incident management. More information about AIIMS can be found here:
http://training.fema.gov/EMIWeb/edu/docs/cem/Comparative%20EM%20-
%20Session%2021%20-%20Handout%2021-1%20AIIMS%20Manual.pdf
FRS Command and control. The Fire and Rescue Service (FRS) is the UK counterpart of ICS
11.2. Human-machine interfacing Up until today, there are few hi-tech tools in a SAR context. This is mainly due to the fact that SAR
workers are reluctant to introduce new technologies in the field, as the crisis environment is extremely
technology unfriendly. Crisis managers are under huge stress to carry out a lot of work. As a result, all
technology they are required to use must be made extremely user-friendly (and fisher-price easy as
one end-user put it). This requirement calls for simple interfacing technologies, where most of the
background processing tasks are hidden from the user, such that the user only has to give high-level
(task) commands.
Remark: It is clear that this demand is someway in contradiction with the other desire of the end-users
to be able to tele-operate most platforms at all times, so a delicate compromise will need to be sought
here.
Deliverable 100.1 – V 8.0
Page 56
11.3. Mapping
11.3.1. Need
In the beginning of a crisis, there is no common operational picture between the different deployed
teams. Mapping is essential to remedy this. It provides a common operational picture, which is used
for the correct allocation of efforts.
When a major disaster strikes a developed country, it is in general the national GIS information service
that provides map data to the different incoming teams. When, on the other hand, the disaster
happens in a developing country, with a deployment of UNDAC, it is in general MapAction as associated
partner of UNDAC who will provide mapping facilities. MapAction is a non-governmental organization
that specializes in providing mapping for humanitarian emergencies. MapAction has a staff of highly
trained GIS-professionals, working as volunteers. In either case, the mapping specialists set up a base
of operations within the OSOCC.
As mapping is seen as a gradual (pyramidal) process, it is better to first have a low resolution map of a
large area than to have a high resolution map of a small area, certainly at the start of an operation,
when the needs need to be assessed clearly. The mapping process then follows a pyramidal structure
which is gradually refined with priority for the most affected zones. UAS are seen as a very valuable
tool for this mapping need. Currently, SAR teams need to rely on pre-existing GIS data (which is of
course outdated after the disaster struck) or on satellite imaging. However, the problem with satellite
imaging is the huge delay on the arrival of this data, compared to the fast-paced evolution on a
disaster-site. As a result of this delay, satellite data is in practice not used very often during the
immediate crisis response. The end-users report that small and light UAS could fill in this void and
provide early mapping support for the SAR teams. Post-disaster mapping by light UAS is for example
seen as an interesting means of assessing the level of damage by applying co-registration and change
detection to pre and post disaster maps.
11.3.2. Current tools
Currently, USAR teams use mostly paper maps they get on a daily basis from the OSOCC. Digitized static
maps are deployed in JPG or KML format.
These current maps contain almost no meta-data. The data is often originally available, as the GIS
people very often use ESRI shapefiles as input, but the metadata of the deployed static maps is in
general not populated. Examples of metadata to be found on actual maps can be found on:
http://www.mapaction.org/map-catalogue/mapdetail/2055.html
There does exist a so-called Humanitarian Data Model (see full description on the website
http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Model), which is
used to describe all aspects of crisis management and which allows to share GIS data between
organizations. Ideally, the ICARUS tools should produce data, compatible with the Humanitarian Data
Model, such that it can be easily integrated and shared.
Deliverable 100.1 – V 8.0
Page 57
The Humanitarian Data Model is also used for handling security, privacy and copyright issues, as the
humanitarian data mode allows to flag certain (map) data as classified / copyrighted.
Maps are in general updated when new data is available. For USAR applications, this is in general once
or twice a day. USAR teams are (in theory) required to report once a day to the OSOCC, so they can
retrieve new map data on a daily basis.
A main data source of map data is Google Mas and Earth. 100% of the end-users indicated that they
use these tools. In general, ESRI tools (like ArcGIS) are used for map processing by the GIS specialists,
because the ESRI tools provide the best integrated environment for map data processing (note: this
was reported by end-users without them knowing that ESRI is a partner in the ICARUS project). UK
intervention teams also use the “Blue 8“ mapping system. Other end-users report on using Microsoft
Live mapping data (http://maps.live.com/) and OpenStreetMap (http://www.openstreetmap.org/).
Whereas mapping tools requiring on-line access are not evident to use in a crisis context where
internet connections cannot be guaranteed, there is a tendency to work more and more with such
tools. In the near future, MapAction will deploy a web mapping tool over WLAN which makes data
feeds available over WMS (Web Mapping System), WFS (Web Feature System) and KML. This opens
the door towards accessing map data over handheld devices (see also below).
For examples of current maps used for crisis management, have a look at http://www.mapaction.org
and http://www.reliefweb.int
11.3.3. Map size
The size of the area that needs to be scanned largely depends on the disaster. In general, the whole
disaster area needs to be scanned. To give an idea, during the Ban-earthquake in Iran, this area was
more than 10.000km². While this represents an extreme case, one must take into account that the
area to be mapped can be quite large.
The size of the maps which are sent from the headquarters to the local operations center varies
between 500kB and 5MB. Maps which are larger than 5MB would absolutely never be sent to the local
operations center, as there is little chance that they would arrive, due to the connectivity problems.
Following the needs of the end-users, the resolution of the provided maps goes up to (maximum)
street level, with a pixel resolution between 1 and 5 megapixels.
11.4. Data exchange Data exchange is extremely expensive in crisis management environments, as the end-users often
need to use expensive satellite phone connections to retrieve data from the internet. To give an idea:
1MB costs $5. As a result, the amount of data to be sent over such networks must be reduced
drastically. This poses a heavy constraint on the amount of data (in general: a map scaled down and
compressed maximally with some vector data) which can be uploaded or downloaded from the
internet. To have an idea on the allowed network traffic, the users were asked to indicate how much
Deliverable 100.1 – V 8.0
Page 58
data traffic they would be prepared to pay for a day for handling the ICARUS tools (on top of their
normal operational networking costs). The results are shown on Figure 17.
Figure 17 - Amount of data traffic allowed per day
The results of Figure 17 show that most end-users are only prepared to pay for about 10MB a day for
handling the ICARUS tools. This is a very low figure and it poses a severe constraint on the data traffic
up and from the internet.
The end-users were also asked what technology they use for data sharing. The results are shown on
Figure 18.
As can be noted from Figure 18, 90% of the end-users use DropBox (free version) as a means of
information sharing. Multiple users reported that they used the Microsoft Groove service before, but
switched to DropBox after Microsoft started discontinuing this service. DropBox provides multi-
platform SDKs (see https://www.dropbox.com/developers/reference/sdk) for integrating to its
product, so it is possible and maybe inetersting to develop an integrated solution with this data
exchange service.
Deliverable 100.1 – V 8.0
Page 59
Figure 18 - Technology used for data-sharing
There is a certain amount of users reporting to use Google tools (Google Docs / Drive) as a means of
data sharing. However, many other end-users report that using Google tools is completely out of the
question, due to the Google company policy on intellectual property.
11.5. Software deployment A problem many intervention organizations have is that they are agencies with strict security policies.
As such, it is not always evident to install new (ICARUS) software on their laptops. The users were asked
whether they would be able to install ICARUS software on their PCs depending on the licensing model
(open source / proprietary). The results are shown on Figure 19.
As shown by Figure 19, “only” 50% of the end-users report that they would be able to install ICARUS
software without any problem, whereas 25% responded that would be out of the question. The third
most important category (about 19% of the end-users) reported that they would only be able to install
proprietary contracted software, so there does seem to be a reluctance in the (management section
of the) end-user community for open-source tools.
Deliverable 100.1 – V 8.0
Page 60
A web service would solve this problem, but would rely on web connectivity, which is not evident, so
a compromise must be sought here.
Figure 19 - Possibility to install software on PCs
11.6. Mobile applications During the interviews with the end-users, an ever-increasing demand for access to data on mobile
devices was noted. Mobile devices could be part of the C2I system and e.g. be used to update maps
with information regarding hazards and localizations. This could be used for improving the human-
robot cooperation modalities, e.g. by sending sharing data and intelligence results between human
team members and the UXVs. As a result, the end-user community was asked to indicate the usefulness
of developing applications for such mobile devices. The results of this are shown on Figure 20 and
clearly indicate that there is a great need here, certainly for tablet-based applications.
The problem with mobile devices and developing applications for them is that there is no
standardization. Everybody has his favorite tool (iPad, Android-device, iPhone, mobile GPS, …) which
makes it hard for the mapping specialists to cater to all these needs. There is a big need for a
standardized app for these mobile tools. If this would exist, then it would not be too difficult for the
mapping specialists to put a geo-referenced map (or several maps) of the affected area on the mobile
Deliverable 100.1 – V 8.0
Page 61
devices of the SAR workers. As the SAR workers need to report daily to the OSOCC, this map could be
updated daily via (USB) cable, as such avoiding communication problems for streaming large datasets.
In any case, offline access to downloaded data must be made possible, because in the field, the internet
connectivity cannot be guaranteed.
Figure 20 - Usefulness of mobile devices
As these maps are geo-referenced, the information on these mobile devices would be very interesting
for integrating with geo-referenced robotic applications. However, one must be careful not to forget
the technologically less savvy USAR nations.
Another issue with mobile devices may be their dependability on GPS reception. Although GPS is
nowadays nearly always available, also in crisis environments (see before), a problem with using GPS-
equipped mobile devices is also that their batteries run out very quickly once the GPS is turned on. As
a result, it is certainly required to ensure continued operation when the GPS signal drops or is turned
off to save the batteries.
Deliverable 100.1 – V 8.0
Page 62
12. Functional Requirements – Training & Support All end-users indicate that the operator skill is main factor deciding on the success of a mission. As a
result, the “train as you fight” mentality is key. Intervention troops focalize on “real training”, as a crisis
is so difficult to simulate. This is also reflected by the results shown in Figure 21, indicating the
usefulness end-users see for different training methodologies. Figure 21 shows that, as the training
tools become more and more realistic (and less virtual) they are deemed more useful.
Figure 21 - Usefulness of different training methodologies
The end users also indicate that training for working with the different tools should be possible within
one week (the duration of a typical SAR training). If training for the ICARUS tools requires more than
one week, it is very likely that the technology will not be adopted.
Deliverable 100.1 – V 8.0
Page 63
13. Fine-tuning of Functional Requirements for USAR tools using
end-user evaluation of operational trials
13.1. Introduction Most technical ICARUS developments started at M4, after the delivery of the first draft of the
URD at M3. As such, these developments are based upon the requirements expressed in this
document, which is updated at several time-instances (M6, M12, M24). However, it is often
hard to express requirements without evaluating the practical operational repercussions of
these requirements by doing field tests with the produced material. Therefore, the ICARUS
consortium has opted to organize, together with the end users, operational trials already very
early in the project stage, showcasing the capabilities of early developments and prototypes,
in order to get valuable feedback from the end-users, allowing the designers to improve their
systems and in order to allow the end-users to re-iterate their requirements. The result of
these exercises for the USAR aspects of the project is discussed in the following sections.
13.2. Operational Land Trial in Belgium
13.2.1. Scenario Description The land trials consisted of an exercise of an USAR intervention on the training site used by the Belgian
First Aid and Support Team (B-FAST) for training. The site comprises 2 areas: one area simulating a
town with skeleton houses useful for indoor training (Figure 22 left); and another area with a rubble
field simulating a destroyed structure, with an underground tunnel system (Figure 22 right).
Figure 22: Operational Land Trial test area
During this exercise, the following assets were presented, tested and discussed with the B-FAST end-
users:
Deliverable 100.1 – V 8.0
Page 64
The ICARUS SUGV by Allen Vanguard (see Figure 25)
The RMA Validation platform (see Figure 27 )
A small UAS for testing collaborative mapping and victim search operations. (see Figure 31). It
is to be stressed that it is by no means the idea to use this specific UAS as a final ICARUS
platform, the device was just used for data gathering and testing UGV-UAV collaborative
operations.
ICARUS communication assets
ICARUS training assets.
It is to be noted that during these first tests, the ICARUS tools were under control by expert operators,
not yet by the end-users themselves (this is our plan for a future iteration of these tests, after giving
the end-users the appropriate training).
13.2.2. End-user feedback on Generic / Deployment issues Deployment time:
The set-up and deployment time of the ICARUS SUGV was under 30 minutes, which was
satisfactory for the end-users
The set-up and deployment time for the RMA validation platform was around an hour. The
end-users noted that this is unacceptable in real operations. ICARUS developers need to
make sure that the set-up time is reduced. However, in a way this is normal, because the
RMA validation platform is not meant to be a final USAR platform, but a platform to test
and validate the novel perception and navigation methodologies on.
13.2.3. End-user feedback on Sensing As foreseen in the test and validation plan, the ICARUS victim detector wasn’t part yet of this
operational test in the field. We also plan to use an oxygen level sensor on the SUGV in later phases,
but this sensor was not installed yet. Therefore, the end user feedback on the requirements after
operational trials cannot be given yet for the sensing aspect.
13.2.4. End-user feedback on UAS The UAS which was tested here is technically not part of the UAS-WP (WP220), but was used for
investigating UGV-UAS collaboration possibilities, which is discussed in 13.2.6. The reader is
referred to section 13.3 for the ICARUS UAS operational trials.
13.2.5. End-user feedback on UGVs Several aspects of the robots capabilities were presented and discussed with the end users:
Deliverable 100.1 – V 8.0
Page 65
Indoor exploration ability
Indoor exploration was tested in 2 different areas:
o A one-level warehouse / school-building type of construction (see Figure 23): Here
no major problems were observed. The end-users were happy with the
exploration speed, the quality of the (visual) sensor feedback and the
controllability of the vehicle.
Figure 23: ICARUS SUGV inside the "school building"
o A three-story apartment building (see Figure 22 left): Here, some problems were
observed as the openings inside the building are very narrow at many places,
requiring expert control. The experienced robot operator was able to remote
control the vehicle through the building, but the end-users expressed their doubts
as to whether a regular (even trained) USAR team member could have done the
same. They thus advised us to investigate more in depth:
better perception methodologies which can enhance the understanding
of the environment where the robot is in.
better C2I interfaces, which would make the robot easier to control
These recommendations are completely in line with the ICARUS objectives and
were forwarded to the different WP’s which were concerned.
The end-users also indicated that in many cases, semi-demolished buildings can
be entered from the basement (often the least damaged part of the construction).
The three-story apartment building does have a basement, but in order to descend
into the basement, it would have been necessary to winch the robot into the
basement (or to let it drop for 2m, which goes beyond its specifications). This
feature (winching possibility) was not yet foreseen in the requirements and
because was added as an optional requirement to the user requirements based
on this user comment.
Deliverable 100.1 – V 8.0
Page 66
Stair-climbing ability
Inside the three-story apartment building, the stair-climbing ability was tested. The robot
successfully climbed the first staircase, but then had a problem turning into the next
staircase. As the passage is very narrow, there was not enough room for turning. After a
small manual intervention, the robot was able to make the turn and continued the second
staircase to the first floor.
Figure 24: ICARUS SUGV on the staircase
In response to this test, the design of the ICARUS SUGV will be further studied to see
whether it is possible to optimize the design to enable the SUGV to make turns in narrower
spaces.
The end-users appreciated the stair-climbing ability of the robot, but where again a little
worried about the operator skills it requires. The same recommendations as for the indoor
exploration ability apply.
Outdoor exploration ability
The ICARUS SUGV was tested on the terrain through vegetation and rocky areas (see Figure
25). The end-users were generally pleased with the terrain crossing abilities of the vehicle.
They did recommend to provide a modular track system, as certain types of tracks are
more suitable for smooth terrain, whereas other tracks are more suitable for rocky or
sandy areas. This recommendation will be taken into account for the platform design.
Deliverable 100.1 – V 8.0
Page 67
Figure 25: Outdoor exploration ability
Tunnel-crossing ability
The test area contains a network of standard-sized sewage system pipes. To test the ability
of the SUGV to navigate in confined spaces, the system was tested inside such sewage
pipes (see Figure 26). The current prototype of the SUGV system fitted in the sewage pipe
and could cross it. However, for future upgrades of this system, it is foreseen to mount
extra perception ability and the communication system, which would impede the passage
of the robot through the tunnel system.
Figure 26: Tunnel-crossing ability
The end users advised to:
Provide modular add-on components (for perception, communication, …) such
that tunnel-crossing remains possible, as this is an important feature
Deliverable 100.1 – V 8.0
Page 68
Provide the robot with a cutting mechanism, such that it is possible to clear itself
a path through obstructions the tunnel system. This was discussed with the WP230
responsibles for the SUGV, but it is technically impossible (due to restrictions on
power and recoil) to provide such a capability for the SUGV.
Slope climbing ability
The slope climbing ability of the validation platform was tested on multiple types of ground
surface (see Figure 27): through vegetation and on a loose rocky slope. Loose rocks do of
course pose more problems to avoid slippage, but the platform was able to climb slopes
of over 30° as specified in the requirements. The end-users were generally quite pleased
with the level of performance of the UGV with respect to this requirement.
Figure 27: Slope climbing ability
Gap-crossing ability
The gap crossing ability was not really fully tested as the weight division of the platforms
is not final yet. Initial tests on uneven terrain showed that the validation platform is able
to cross small voids, but it is to be taken into account that this ability comes together with
important shocks imposed on the control and perception system, which may negatively
affect robustness of the system over a long term.
Figure 28: Gap-crossing ability
Deliverable 100.1 – V 8.0
Page 69
The end-users advised us to augment the robustness of the perception and control system,
such that more important shocks can be absorbed and larger gaps can be crossed. The
feasibility of this requirement will be studied by the WP230 platform developers.
Sensing capability
The validation platform was equipped with a double visual perception system co-
developed by UKL and RMA, consisting of:
A stereo camera system
A Time-Of-Flight (TOF) camera
Both of these sensing modalities provide a 3D perception of the environment, each with
their advantages and disadvantages. Synchronized datasets were recorded during this
exercise, which will allow to select the best sensing modality and data fusion approach
depending on the environmental conditions.
Figure 29: Visual Perception system on the validation platform
The end users were shown the output of each of the sensing modalities, such that they
could have an impression of what is possible with these systems. The end-users found it
quite difficult to understand the raw sensor output (3D point clouds) and thus
recommended us to work further on the integration of the 3D data, in order to provide
them with visually appealing (and more “understandable”) environmental descriptions.
Hazardous area inspection ability
The test site features an abandoned oil truck, which inspired the end users to ask us if it
would be possible to inspect the vehicle from the underside to detect leakages. The limited
height of the validation platform made it possible to carry out this operation without much
difficulties.
Deliverable 100.1 – V 8.0
Page 70
Figure 30: Hazardous terrain inspection
The end-users noted that this is a kind of operation they would likely need to carry out during real
USAR operations and were satisfied with the operation of the UGV. They also noted that additional
sensing modalities (chemical sensor, …) would be useful for these kind of operations and advised
us to keep our platforms modular and open for the possible integration of such COTS sensors.
13.2.6. End-user feedback on Heterogeneous Teams As foreseen in the test and validation plan, this activity wasn’t part yet of a full operational test in
the field. Therefore, the end user feedback on the requirements after operational trials cannot be
given yet for the heterogeneous collaboration aspect. However, partial aspects of this effort were
tested together with the land trials. These aspects included the collaborative victim search and
mapping of crisis areas by combined UGV and UAV systems. The RMA validation platform was
therefore extended with an UAS (see Figure 31). It is to be stressed that it is by no means the idea
to use this specific UAS as a final ICARUS platform, the device was just used for data gathering and
testing UGV-UAV collaborative operations. As an operational tool, this type of UAS would be too
much subject to wind, making it uncontrollable in all but ideal operational conditions. However,
the device is equipped with two cameras, one even with a high-definition resolution and is
controllable by a PC.
Deliverable 100.1 – V 8.0
Page 71
Figure 31: UGV-UAV collaborative system
A dataset was recorded with the UAS flying and the UGV driving over the same terrain (see Figure
32). Simulated victims were hidden in the debris (invisible to the UGV) in order to test the
capabilities of the UAS to locate the victims.
Figure 32: UAV during collaborative victim search and mapping operation
The end-users were shown the real-time imagery coming back from the UAS (see Figure 33).
Assisted by the end-users, the UAS operator sought for the victims hidden in the debris using the
real-time imagery. Notwithstanding the windy conditions, which made the small UAS difficult to
control, they were able to find back all hidden victims (to be clear: this was done purely relying on
human visual recognition from the real-time imagery, no automated processing as developed in
WP210 yet). The end-users highly appreciated this capability of the UAS. Of course, they noted
Deliverable 100.1 – V 8.0
Page 72
that we should have more wind-resistant platforms, for which we pointed them to the ones
developed in WP220 and discussed in section 13.3.
Figure 33: Real-time imagery from the test UAS
13.2.7. End-user feedback on Communications As a part of the operational field trial, parts of the ICARUS communication tools were tested on the
test site. It is to be noted that this was a non-integrated test, meaning that the communication tools
and robotic tools were tested separately in this early stage of the project, there was no integration yet.
The communication team surveyed the communication bandwidth across the test site using different
communication modalities, measuring outside as well as inside (in the tunneling system), in order to
select the optimal communication strategy (see Figure 35).
As a part of this exercise, the end users were presented the proposed ICARUS communication tools
and were shown how they operate. The end-users were happy to learn about the cognitive aspects of
the ICARUS communication strategy, as selecting manually the optimal communication strategy is
often very difficult on the terrain. They were a little concerned that the communication tools in their
current state are still quite bulky, which means that it may be difficult to deploy them on actual
missions. They thus advised us to focus also on the miniaturization of the tools.
Other tests regarding bandwidth and connectivity have been carried out with a simulation tool which
incorporates a digital 3D balloon. The tool allows simulating the test site (see Figure 34Figure 34).
Deliverable 100.1 – V 8.0
Page 73
Figure 34: ICARUS Communication tools: Simulation of Test Site.
Figure 35: ICARUS Communication tools: measuring communication bandwidth using different communication modalities as a function of the terrain
Deliverable 100.1 – V 8.0
Page 74
13.2.8. End-user feedback on C2I The WP320 WP leader developed a first prototype of the Robot Command and Control (RC2) base-
station and tested it at the Eurathlon competition held in Bertschesgarden, Germany on 21st
September. The RC2 software was integrated with company's Husky platform (integrated with
sensors and a manipulator arm) only for purpose of the competition. Concepts like mapping,
mission planning, tele-operation, and force-feedback robotic arm control were implemented in
the software and tested. The software helped the team achieve 3rd place in the manipulation task
and the team was very successful in completed a number of other realistic search and rescue
simulations.
It must be noted that the users in this case were the company's engineers and therefore they
cannot be considered end-users. However the realism of the scenarios have the system developers
identify the needs for the C2I user interfaces. The outcomes of the Eurathlon trials and lessons
learnt were shared with B-FAST along with other recent C2I developments at a workshop at Space
Applications Services on 28th January, 2014. A main point of discussion was the optimization of
the graphical user interface (GUI) of the C2I systems to make them easy to operate by the end
users. In this context, end users requested an ability to localize detected victims in 3D maps in the
GUI. Concerning iconography, end users advised to use the base icon set for building markings as
provided by the INSARAG standard marking system. End users advised not to overload the maps
with data, but to concentrate on the most common dangers for human search and rescue workers:
electricity, gas, water and hazardous materials. The end users also noted that some of the more
advanced concepts of the ICARUS mission planning tools (like for example the automated resource
allocation system) are a bit ahead of their time, as it is unrealistic to think that search and rescue
managers will leave such an important task up to a software algorithm in the foreseeable future.
The end users advise to concentrate on introducing the more generic mission planning tools to the
community getting the search and rescue workers to learn and trust the system before taking next
steps. The results of this meeting with the end users will further be used to enhance the
development of the RC2 base station and mobile phone applications in WP320.
13.2.9. End-user feedback on Training and Support As a part of the operational field trial, the ICARUS training and support team mapped the
intervention area in 3D. During the trials, the end-users were shown the results of these scans,
which will be used to form the basis of the training platform (see Figure 36). The end-users were
very impressed with the level of realism which was attained by the reconstructed 3D model. In
fact, one of the main fears of the end users when confronted with virtual training is that the
training model would be too far from reality (see also section 12). After seeing the level of realism
which can be attained by the ICARUS training model, they were convinced that this could provide
a very useful basis for developing training tools.
Deliverable 100.1 – V 8.0
Page 75
Figure 36: Results of the 3D scan of the trial environment: Dense 3D point clouds (first 2 rows) and rendered reconstructions (bottom row)
13.3. Operational Aerial Trials in Switzerland
13.3.1. Scenario Description The ICARUS Unmanned Aerial Systems trials took place in Zurich, Switzerland between 28/10/2013 to
31/10/2013. ICARUS participants from ETHZ, ASCAMM, Skybotix as well as STP were present.
The main goal within the framework of these trials was:
• The integration of the ETHZ common sensing and processing module to the ASCAMM
unmanned quadrotor.
Deliverable 100.1 – V 8.0
Page 76
• Conducting autonomous navigation experiments using the Skybotix multirotor with the ETHZ
common sensing and processing module
• Illustrate the automatic control capabilities on fixed wing unmanned aerial vehicles.
Figure 37: ICARUS UAS active during the operational trials in Switzerland. From left to right: the ASCAMM rotorcraft, the Skybotix rotorcraft and the ETHZ fixed wing test platform
13.3.2. End-user feedback The end users were generally pleased with the flying capabilities of the tested platforms, but
asked for more priority going towards:
Rain resistance
Operations in difficult weather (wind) conditions
Picture (photo) quality
Deliverable 100.1 – V 8.0
Page 77
Part 3 – Maritime Search & Rescue
Operations requirements
Deliverable 100.1 – V 8.0
Page 78
14. Application Scenarios and Use Cases for Unmanned Search And
Rescue Tools Some of the possible application scenarios for the unmanned tools in the scope of ICARUS MSAR might
be situations in which people are swept to sea in situations as coastal floods or tsunamis, and situations
of shipwreck in rivers, estuaries, lakes and coastal sea.
Having in mind the causes of flooding affecting the coastlines and some of representative flooding
events, we may lay out scenarios for possible future flooding events, susceptible of sweeping people
as the water flows towards or into the sea.
The tsunami flooding situation, even rare, is always possible and may be a big catastrophe along the
shore, as seen in the Indian Ocean 2004 and recent Japan 2011 events. They may reach the coast in
short time, if from close source, or may take some hours, if originated from a far source, in the oppose
side of the Atlantic. From close source the time for detection and warning is very short. There are
always chances of sweeping people into inundated areas inland or even to the coastal ocean offshore.
Fast flooding situations, particularly during winter storms, are likely to be frequent and having also the
potential for sweeping people into inundated areas and offshore. Not specifically described above, the
flooding from the river beds, during high rainfall winters, along the main rivers happened several times
in the past and are always possible future situations to be handled by the civil protection agents,
requiring search and rescue and humanitarian relief.
Other scenarios might be in shipwreck situations. Cruise ships, ferryboats among others are examples
of vessels with which accidents can happen involving a great amount of people, and possible to happen
in offshore sea as well as in coastal and inland waters as estuaries, lakes and rivers. Currently SAR
operations might be very conditioned with scenarios with low visibility as during the night or fog, so in
that situations the actuation of adapted robots could considerably improve the efficiency of SAR
operations.
The roles of the robots in the mentioned scenarios can be separated in different platforms such as the
aerial and the maritime platforms.
So in the mentioned scenarios the aerial vehicles could complement the search operations by
sweeping areas where victims might be, contribute for the sectorization and reduction of the search
area, localizing victims, tracking them and providing real time and precise information about victim
locations to maritime teams. These platforms could also act as mobile beacons or repeaters, helping
with extending the mobile communication range. Over the horizon applications might be relevant as
well.
Maritime teams can also participate in the search operations, although their main role could be in the
rescue operations. With the information provided by the aerial segment, the maritime segment would
be in charge of assisting located victims, providing them floatation, shelter from sea and weather
conditions (as a life raft does), allowing as well, for example, in situ medical assessment and
intervention. This would extend the time of life of victims increasing the survival possibilities and
allowing its rescue in safety as soon as the safe conditions are ensured.
Deliverable 100.1 – V 8.0
Page 79
Deliverable 100.1 – V 8.0
Page 80
15. Typical organization of MSAR teams
15.1. The MSAR system ICAO and IMO are the international entities that coordinate all Search and Rescue global efforts of
their member states.
The SAR system, like any other system, has individual components that must work together to provide
the overall service. Development of a SAR system typically involves establishment of one or more SRRs,
along with capabilities to receive alerts and to co-ordinate and provide SAR services within each SRR.
Each SRR is associated with an RCC. For aeronautical purposes, SRRs often coincide with flight
information regions (FIRs). The goal of ICAO and IMO conventions relating to SAR is to establish a global
SAR system.
Operationally, the global SAR system relies upon States to establish their national SAR systems and
then integrate provision of their services with other States for world-wide coverage.
15.2. Levels of co-ordination There are three levels of coordination within the SAR.
SAR coordinators (SCs)
Have the overall responsibility for establishing, staffing, equipping, and managing the SAR
system, including providing appropriate legal and funding support, establishing RCCs and
rescue sub-centers (RSCs), providing or arranging for SAR facilities, coordinating SAR training,
and developing SAR policies. SCs are the top level SAR managers; each State normally will have
one or more persons or agencies for whom this designation may be appropriate.
SAR mission coordinators (SMCs)
SAR operations are normally carried out under the direction and supervision of an SMC, who
is usually the supervisor of the RCC or RSC watch team. In multiple-incident situations this
officer could be SMC for all incidents, or, for some of those incidents, the SMC role could be
delegated to another suitably qualified member of the watch team. The SMC should in all cases
be supported by RCC watch team members to undertake functions in the coordinating process
such as communications, plotting, logging and search planning. For complex cases or those of
long duration, the assisting team must be replaced at regular intervals as well as the SMC. The
SMC must be able to competently gather information about emergencies, transform
emergency incident information into accurate and workable plans and dispatch and co-
ordinate the facilities that will carry out the SAR missions. The SMC is also responsible to
provide information about the incident to other RCC or RSC as well as to competent
authorities. It also the role of the SMC to monitor the SAR operations and to re-plan them
whenever required.
On-scene coordinators (OSCs)
Deliverable 100.1 – V 8.0
Page 81
When two or more SAR units are working together on the same mission, there is sometimes
an advantage if one person is assigned to co-ordinate the activities of all participating units.
The SMC designates this on-scene coordinator (OSC), who may be the person in charge of a
search and rescue unit (SRU), ship or aircraft participating in a search, or someone at another
nearby facility in a position to handle OSC duties. The person in charge of the first SAR facility
to arrive at the scene will normally assume the function of OSC until the SMC directs that the
person be relieved. Conceivably, the OSC may have to assume SMC duties and actually plan
the search if the OSC becomes aware of a distress situation directly and communications
cannot be established with an RCC. The OSC should be the most capable person available,
taking into consideration SAR training, communications capabilities, and the length of time
that the unit the OSC is aboard can stay in the search area. Frequent changes in the OSC should
be avoided. Duties which the SMC may assign to the OSC, depending on needs and
qualification, include any of the following: coordinate local SAR operations, keep a
communication link with the coordinating RCC and receive the SAR plan, coordinate
communications with SAR teams, produce situation reports, keep a record of the operations,
assign and control SAR areas, monitor operational risks, and control efforts of the SAR teams.
It seems natural that the interaction of each one of these coordination levels with unmanned SAR tools
will be distinct. At the SC level, the issues are more related to identifying needs or opportunities of use
of such tools, possibly perform the adequate procurement actions, and establish policies for their use.
At the SMC or OSC levels, these tools are seen as available assets for a given operational. That way, it
would be required to properly characterize unmanned tools in order to take full advantage of their
features in real operations. An important issue that should be taken in account is the interaction
between the unmanned tool and the established levels of coordination in a specific SAR operation.
Several levels of interaction can be considered. In the simplest case, the field agent supervising or
controlling an unmanned tool (or set of unmanned tools) will be responsible for the interaction of the
coordination hierarchy. Nonetheless, to take full advantage of the capabilities of unmanned tools
automatic interactions between coordination levels (OSC or SMC) should be also considered. This
topic, which is directly related to the concept of operations of unmanned tools in SAR operations,
should also be discussed.
15.3. MSAR stages The response to a SAR incident usually proceeds through a sequence of five stages, as described
below:.
1. Awareness
Knowledge by any person or agency in the SAR system that an emergency situation exists or
may exist.
2. Initial Action
Preliminary action taken to alert SAR facilities and obtain more information. This stage may
include evaluation and classification of the information, alerting of SAR facilities,
Deliverable 100.1 – V 8.0
Page 82
communication checks, and, in urgent situations, immediate performance of appropriate
activities from other stages.
It is in this stage that we include the three Emergency phases (Uncertainty, Alert and Distress
phases) based on the level of concern for the safety of persons or craft which may be in danger.
They are not sequential, i.e. we can jump from Uncertainty to Distress phase or if there is
assurance of the incident we can start at Distress phase)
3. Planning
The development of operational plans, including plans for search, rescue, and final delivery of
survivors to medical facilities or other places of safety as appropriate.
4. Operations
Dispatching SAR facilities to the scene, conducting searches, rescuing survivors, assisting
distressed craft, providing necessary emergency care for survivors, and delivering casualties to
medical facilities.
5. Conclusion
Return of SRUs to a location where they are debriefed, refueled, replenished, and prepared
for other missions, return of other SAR facilities to their normal activities, and completion of
all required documentation.
16. General User Requirements User requirements for MSAR were mainly established from the information gathered through the
questionnaire but also from Portuguese navy officers working on MSAR.
The first set of requirements The first set of questions was related to the overall activities envisaged
within the scope of ICARUS, namely the most useful technologies for SAR operations and the number
of additional team members that should be included to operate unmanned platforms.
16.1. Prioritization of developments Figure 38 below presents the results concerning the prioritization of developments. The results tend
to show that the listed technologies (the ones addressed within the scope of ICARUS) are similarly
valued, high significantly high scores. The one that receives less preference (robotic life rafts) is valued
only about 15% below the one with the highest score (human-friendly command and control system).
It is also significant that unmanned aerial systems also receive one of the highest scores, possibly
resulting from the fact that these systems can provide a global view of the area and, if endowed with
adequate sensors, can perform efficient searches for victims which is probably the most hard job in a
lot of disasters at sea.
Deliverable 100.1 – V 8.0
Page 83
Figure 38– Usefulness of technologies for MSAR operations
16.2. Operational Preparedness Requirements
In what concerns operational preparedness, unmanned tools should be subject to the same kind of
requirements as any other SAR equipment. As the use of these technologies is still in its early stages
and it might be natural to overlook these issues at this phase, it should be kept in mind that traditional
SAR equipment is subject to periodic maintenance procedures, and is sometime characterized by a
precise lifetime, beyond which it should not be used. It is suggested, therefore, that similar procedures
and characterizations should be defined for unmanned tools. Although a proper definition of such
issues might not be within the scope of ICARUS project, maintenance procedures, consumables
replacement and lifetime of equipment or its parts should be part of their operational characteristics.
16.3. Mission planning Requirements MSAR operations are planned at a higher level by the SMC or more locally by the OSC. Such plans
include the assignment of teams and equipment to one or more SAR areas, according to their
capabilities. In a scenario where unmanned tools are used possibly at the same of manned teams, the
same high level planning should be performed, now taking into accounting the specific characteristics
of the unmanned tools. At that level it is required to assess characteristics such as endurance, area
coverage rate, maximum speed, operational range, mission support requirements, and environmental
operation conditions, so that and effective and efficient assignment of tools can be performed, as
pointed above. Another relevant issue here is possibility of having tools to automate operations of
each unmanned platform of set of related platforms. Of great relevance are capabilities of autonomous
Deliverable 100.1 – V 8.0
Page 84
planning and motion towards a given destination, as well as autonomous planning of the sweeping of
specified area, following one of a set of patterns. Such characteristics will allow the agent controlling
the platform(s) to focus his/her attention on the gathered data on a search operation or on the specific
procedures of a rescue operation.
16.4. (Fast) Deployment Requirements
16.4.1. Timing
Deployment time is a very important characteristic of any equipment so it should be also considered
for unmanned SAR tools. Nonetheless, the overall deployment time of any asset can only be evaluated
with respect to a specific operation. It was therefore decided not to consider any requirement directly
related to deployment time, but only to consider that unmanned tools should have short deployment
times, as well as simple deployment procedures. Furthermore, fast deployment time should be one of
its main characteristics that should be taken into account when evaluating the possibility of using such
tool, at any operational planning level.
16.4.2. Required manpower to operate the tools
The number of additional operators for auxiliary SAR tools certainly has a great impact on the structure
and internal organization of SAR teams. End-users were asked to tell how many additional members
they were willing to include in their team to operate unmanned platforms. The results are presented
in Figure 39.
The answers clearly show than the maximum number of extra team members should be 2. In fact, in
some cases, MSAR are conducted on-board ships where physical space is always scarce, therefore
imposing a hard constraint on the number of SAR team members.
Figure 39 - Number of extra team elements to operate unmanned platforms (MSAR)
Deliverable 100.1 – V 8.0
Page 85
17. Functional Requirements – USV The second set of questions was directed to the functional requirements of USV platforms. These
platforms were described as carriers of first aid devices to the area of the accident.
Figure 40 presents the results concerning battery autonomy of the USVs. The great majority of the
respondents selected 6 hours as the minimum battery autonomy for these assets, while a significant
number of others selected higher autonomies. It should be mentioned here that one the major
difficulties in maritime disasters is related to the fast decrease of body temperature. Therefore, first
aid devices, such as flotation and thermal insulation, should be provided as fast as possible, after the
location of victims.
Figure 40 - Battery autonomy for USVs
In the next question, end-users were asked about the minimum range of USVs. The results are
presented in Figure 41, where it can be seen that 10km, 20km and 50km where equally selected by the
larger number of respondents, resulting on an average of 27km. It should, nonetheless, be noticed that
this figure should be understood as the maximum distance of the USV from a base (harbor, shoreline,
mother vessel) with relevance for establishment of communication links, and not as the maximum
distance that one USV should cover in a given SAR operation. This one should be significantly greater
(about 200km), as the USV might need to deploy assets in different locations within the operation area.
Figure 41 - Minimum USV range
Deliverable 100.1 – V 8.0
Page 86
Concerning the speed of the USV, the end-users are pretty well distributed among 5, 10, or 20 knots
choices, with no one selecting a higher velocity (see Figure 42). The average of the results is 12 knots,
which seems to be an adequate value. It should however be noticed that the USV autonomy (in amount
of total energy) needs to take into account the possibility of motions at higher speeds.
Figure 42 - Minimum USV speed
Figure 43 presents the results about the operational temperature range. End-users selected the
mean temperature range to be between –10oC and 40oC.
Figure 43 - USV’s operational temperature range
Operations at sea always require some level of water protection. End-users were asked to select the
required water resistance of electronic enclosures, with results presented in Figure 44. The majority of
respondents selected IP8 protection (immersion beyond 1m) followed by IP7 protection (immersion
up to 1m). It should be noticed that this levels of protection don’t need to apply to the USV as a whole,
for which a typical liquid ingress protection IP6 (powerful water jets) seems to be adequate and also
feasibly within the scope of this project, given the USVs operated by the ICARUS partners.
Deliverable 100.1 – V 8.0
Page 87
Figure 44 - Water resistance required for electronic enclosures in USV
The next question is related to daytime/nighttime operation. Almost 70% of the end users indicated
that the USV should be able to operate in total darkness, while 23% selected operations in twilight
condition, and the remaining only daylight operations. One of the major difficulties of current MSAR
operations is directly related to visibility conditions, and the possibility of extending current operation
into the night period is highly valued by SAR teams.
End-users were also asked to select the level of autonomy (on-board decision mechanisms) of the USV
platforms, among a set of options (Figure 45). The most selected one was GPS Trajectory Following,
followed by Complete Autonomy, and Complete Tele-Operation. Besides these desirable levels of
autonomy, that should be translated into different modes of operation, it should be possible to switch
the current mode to fully manual operation at any moment in time, either for legal of safety issues.
Figure 45 - Level of autonomy of USVs
The next question is related to the sensing capacity of the USVs. End users were given a set of different
sensors/technologies and asked to prioritize them. Averaging the results for the top 3 priorities, the
end users ranked the most relevant sensors/technologies as:
Video camera (22%)
GPS / INS (20%)
Infrared camera (14%)
Human victim detection sensor (11%)
Radar (11%)
Hydrocarbons detection (7%)
Deliverable 100.1 – V 8.0
Page 88
The results show that end-users value the visual contact with the victims (video cameras) and that the
geo-referencing of the victims is also of high importance. The next more selected answers were related
to detection sensors (infrared and other detection sensors).
The end users were also asked to indicate the maximum length and the maximum weight of the USV.
The results are presented in Figure 46 and Figure 47. They were more favorable to small sized USVs –
maximum length of 3 meters and maximum weight of 80 kg. Platforms with such characteristics
wouldn’t be able to carry robotic capsules and could only operate on rather calm sea states or in
interior waters. In fact, more realist figures would be a length of about 7 meters and a maximum weight
exceeding 1000kg.
Figure 46 - Maximum USV length
Figure 47 - Maximum USV weight
Considering the deployment method of the USV, the end users were asked to select one or more
options: beach, harbor, ship, or airplane/helicopter. According to results presented in Figure 48, the
deployment from a ship was the most selected option, followed by the deployment from a beach,
while the other two options were selected by about 40% of the respondents. It should be noted that
Deliverable 100.1 – V 8.0
Page 89
the deployment for an airplane or helicopter might be hard to accomplish due to required size and
dimensions, as commented above.
Figure 48 - USV deployment methods
The survey also included a question where the end users were asked to indicate the maximum wave
height the USV should be able to operate in. The answers average was 3.5 meters, with a standard
deviation of 2.1 meters, showing a great dispersion of indicated values. According to the USV
characteristic already mentioned, it might be reasonable to consider that the USV should be able to
operate under sea state 3 (wave height up to 1.25m – Douglas Sea Scale). A related issue, that was not
included in the survey, is the wind condition. According to this maximum wave height, the USV should
withstand wind speeds up to 6 Beaufort (22 to 27 knots).
End users were also asked to identify possible scenarios where USV were likely to be used and also to
include any comment about the use of USVs. In the first case, some answers identified SAR operations
at night, general operations at sea, but also pointed out that USVs could be useful in area searching.
Another interesting answer pointed out the usefulness of developing “low cost” USV units that could
be spread along coastlines.
18. Functional Requirements – Unmanned Capsules (UCAPs) The third set of questions was directed to the functional requirements of Unmanned Capsules (UCAPs).
These platforms were described as the first aid devices, therefore these platforms are the ones which
will interact directly with castaways.
Figure 49 presents the results concerning battery autonomy of the UCAPs. The great majority of the
respondents selected 6 hours as the minimum battery autonomy for these assets, while a significant
number of others selected higher autonomies. It should be mentioned here that one the major
difficulties in maritime disasters is related to the fast decrease of body temperature. Therefore, first
Deliverable 100.1 – V 8.0
Page 90
aid devices, such as flotation and thermal insulation, should be provided as fast as possible, after the
location of victims.
Figure 49 - UCAPs battery autonomy
In the next question, end-users were asked about the minimum range of UCAP’s. The results are
presented in Figure 50, where it can be seen that 1Km was the response of the majority of the
responders. It should, nonetheless, be noticed that this figure should be understood as the maximum
distance of the UCAP from a base (could be the larger USV in this case) with relevance for
establishment of communication links, and not as the maximum distance that one UCAP should cover
in a given SAR operation. This one should be significantly greater as the UCAP might need to do
nonlinear paths to reach victims.
Figure 50 - Minimum range for UCAPs
Concerning the minimum speed of the UCAP, the speed of 2 Knots was the most responded by the
end-users (see Figure 51). It is relevant to mention that the UCAP should have enough power and
capable of navigate with enough speed to overcome drifts caused by wind or currents.
Deliverable 100.1 – V 8.0
Page 91
Figure 51 - UCAPs minimum speed
Figure 52 presents the results about the operational temperature range. End-users selected the mean
temperature range to be between –10oC and 30oC. It is a reasonable range, but since higher
temperatures were also significantly referenced by responders, an optional maximum temperature of
40oC might be good for specific operational scenarios.
Figure 52 - UCAP operational temperature range
Figure 53 presents the results about maximum weight of the UCAPs. Although the average response is
about 129Kg, the maximum weight of the capsules should not exceed the 80kg regarding that several
of these UCAPs must be carried by a single larger USV.
Figure 53 - UCAP maximum weight.
Deliverable 100.1 – V 8.0
Page 92
Concerning the maximum size of the UCAP (Figure 54), end-users responded for length, width and
height 3.4, 1.3 and 1.1 meters respectively which seems reasonable values regarding that UCAPs might
have two configurations, before and after inflation. These values are referring UCAP’s configuration
after inflation.
Figure 54 - UCAP maximum size
Figure 55 presents the responses about the minimum number of victims each UCAP should be able to
take. Five people was the most responded option followed by two people. As it is a minimum number
it seems reasonable to consider four as a minimum number of people to take, regarding it is a standard
number for life rafts occupants and notwithstanding that dimensions and weight of life rafts for two,
four and six people do not vary much.
Figure 55 - Number of people carried by UCAPs
Operations at sea always require some level of water protection. End-users were asked to select the
required water resistance of electronic enclosures, with results presented in Figure 56. The majority of
Deliverable 100.1 – V 8.0
Page 93
respondents selected IP8 protection (immersion beyond 1m) or IP7 protection (immersion up to 1m),
equally voted. IP8 seems to better fit for this application. It should be noticed that this levels of
protection don’t need to apply to the UCAPs as a whole, for which a typical liquid ingress protection
IP6 (powerful water jets) seems to be adequate and also feasibly within the scope of this project.
Figure 56 - UCAP Water resistance
Figure 57 presents the responses about the ability of UCAPs to work at night. The Great majority of
responders (75%) considered that UCAPs should work in total darkness. So it reflects the importance
for end-users of the ability of UCAPs to work in such conditions.
Figure 57 - UCAP operation at night/darkness
About the level of autonomy of the UCAPs, Figure 58 shows that the majority of end-users answered
that the platforms should be able to move to a designated target autonomously. The response was
followed by the complete autonomy level with about 29% of responses. Therefore it seems reasonable
to consider that the UCAPs should be able to move autonomously to a designated target position,
although it might be desirable that these platforms could operate fully autonomously. Even though its
autonomy, it should at any moment in time be possible to operate the Capsule under full manual
operation, either for legal or safety issues.
Deliverable 100.1 – V 8.0
Page 94
Figure 58 - Autonomy level of the UCAPs
The survey also included a question where the end users were asked to indicate the maximum wave
height the UCAPs should be able to operate in. According to the UCAPs characteristic already
mentioned, and the above considered for USV’s, it might be reasonable to consider that the UCAPs
should be able to operate under sea state 3 (wave height up to 1.25m – Douglas Sea Scale). A related
issue, that was not included in the survey, is the wind condition. According to this maximum wave
height, the UCAP should withstand wind speeds up to 6 Beaufort (22 to 27 knots).
19. Functional Requirements –UAS Another set of questions is related to the use of different unmanned aerial systems (endurance
airplane, quadrotor, gyropendulum) on maritime search and rescue operations. The question involved
functional requirements and also operational conditions for the UAS operation.
The first question was directed at the battery autonomy of the UAS. For each system (airplane,
quadrotor, gyropendulum) the majority of the respondents selected the highest option – 6 hours. It
should be noted, however, that for the shorter endurance systems (quadrotor, gyropendulum), the
most selected option is closely followed by the next one, as can be observed in Figure 59.
Figure 59 - UAS Battery Autonomy (MSAR)
Concerning the operational temperature range, the end users answers pointed to a – 0oC to 40oC
range, as presented in Figure 60. These values are almost in line with the ones indicated for the USVs
and the robotized capsules.
Deliverable 100.1 – V 8.0
Page 95
Figure 60 - UAS operational temperature range (MSAR)
When asked about the level of autonomy of the UAS, end users mainly stated that these systems
should be able to operate in complete autonomy. Nonetheless, GPS trajectory tracking and complete
tele-operation were also chosen by a significant number of respondents, as shown in Figure 61. It
should be noted, however, that complete autonomy, mainly in airborne systems, stills arises significant
legal and safety issues, and therefore, these levels of autonomy should be seen as different modes of
operation that could be activated in a certain field operation. In fact, it is desirable that at any moment
of time the (fully or partial) automatic operation could be switched to manual control to ensure the
fulfillment of all the constraints on the use of these systems. Another relevant issue is the possible loss
of communication link between the remote operator and the aerial system. Although maximum ranges
of operation should be defined, the development of automatic safe behaviors in case of loss of the
communication link should be considered.
Figure 61 - UAS level of autonomy (MSAR)
End users were also asked to prioritize the sensing technologies onboard the UAS. The options
available for selection and prioritization were: visual camera, infrared camera, 3D mapping system,
GPS based positioning, human victim detector, and hydrocarbon and gas detectors. The results are
presented in Figure 62. They clearly show that the most important device for the end users is a video
camera, directly followed by an infrared one. The 3D mapping device is given a low priority, as the
Deliverable 100.1 – V 8.0
Page 96
maritime search and rescue teams usually operate in open area where mapping is of reduced
significance. On the other hand, a GPS based positioning system is also of significant interest due to
the need of pinpointing the location of survivors in search operations – one of the major roles to be
played by the aerial segment of the ICARUS tools, at least in the maritime domain.
Figure 62 - UAS sensing technologies (MSAR)
Weather conditions also constrain the operation of UASs. The next question is directly related to that,
and asked the end users to defined maximum wind speed that these systems are required to work in.
The results are presented in Figure 63. The most selected option is 60 to 70 km/h with an average of
the answers slightly above 50 km/h. The upper limit of 70 km/h is stronger than the maximum wind
speed referred above for the case of USVs, and needs to be balanced with other constraints on the
operation of the UASs, namely payload capacity and battery autonomy to make sure that the final
design is feasible.
Deliverable 100.1 – V 8.0
Page 97
Figure 63 - Maximum wind speed for UAS operations (MSAR)
The next question addresses water resistance for the UASs. End users were asked to select the level of
resistance and the results are shown in Figure 64. The answers are spread from IP3 (spraying water)
up to IP6 (powerful water jets). During flights, and if takeoff and landing take place inshore, there is no
reason to consider a liquid ingress protection higher than IP3. On the other hand if takeoff or landing
might take place on board a mother vessel a higher level of protection should be considered. Again,
the final decision on the protection level has to take into account the balance between the
characteristics of the operational scenarios and the developments feasible within the scope of the
ICARUS project.
Figure 64 - UAS water resistance
In the last question related to the aerial segment, end users were asked to defined likely scenarios for
usage of an UAS. This was an open question and the answers given point to the use of UASs to search
for victims in the disaster area. More specifically, it was mentioned the high interest of using these
assets under hard weather conditions. This is surely a relevant issue, but it should be kept in mind that
the adaptation of existing UASs systems for operation in harsh conditions might quickly become out of
the scope of this project.
Deliverable 100.1 – V 8.0
Page 98
20. Functional Requirements – Sensing A set of specific question related to the functional requirements of sensing devices for maritime SAR
operations was also included in the survey. In the first question end users were asked to point out the
sensing technology mostly missing in SAR operations. This was an open question, and almost all
answers indicated infrared cameras. These results clearly show the relevance of developing a small
size human detection infrared camera, which is precisely one of the major objectives of this project. It
should be noted that human detection in maritime environments might require a higher sensitivity of
the device due to the fast decrease of body temperature of victims at the surface.
End users were also asked to estimate the percentage of missed victims (false negatives) in search
operations. It should be noted that very low percentages of false negatives usually give rise to a high
number of false positives. The average of the responses 29%, but very opposite numbers were pointed
out, ranging from 0% up to 75% (the standard deviation of the answers was 25%).
End users were also asked to defined maximum size, weight and power consumption of a human
detection camera. Answers given by the respondents were distributed by a wide range of numbers.
Nonetheless, a significant number of respondents pointed to dimensions in the order of 50 cm, weights
ranging from 10 to 50 kg, and power consumptions from 10 to 50W. Although a camera with
characteristic like those could fit in a medium sized USV, it couldn’t be carried by an aerial system as
the ones envisaged here.
21. Functional Requirements – Heterogeneous Teams The ICARUS concept comprises the use of heterogeneous tools of robotic assets, developed by
different teams. Therefore the effort to put those platforms working together has to take into account
interoperability issues and/or standardization of communications and protocols. Interoperability is a
key issue in the development of any technology that will be field deployed as compliance with existing
standards should be pursue whenever possible. With this in view, end users were asked to tell, from a
list of technologies, the ones their (robotic) platforms comply to. The last majority of respondents said
they have never used robots before. Only STANAG (a standardization agreement from NATO) was
report to have been used by 2 respondents. This result shows that a further effort needs to be made
to carefully select the standards that ICARUS tools should comply to.
Still within the scope of heterogeneous teams of robots, end users were asked to identify scenarios
where multiple aerial systems of aerial and surface cooperating systems might be employed. Only a
few answers were collected, and in those cases the respondents stated that the major interest in
multiple assets could be in disasters spread over large areas, where the area search should be divided
among the multiple platforms available.
Deliverable 100.1 – V 8.0
Page 99
22. Functional Requirements – Communications The seventh set of questions was related to the overall communications within the scope of ICARUS
maritime scenario, namely the communication ranges for the several platforms as well as the
technologies and middleware already used in maritime SAR operations.
Figure 65 is about the communication range for each of the different platforms in the scope of the
maritime scenario. It should be noticed that these communication ranges must be consistent with the
ranges of each platform previously mentioned.
Regarding that all of these platforms will operate in the same areas, it should be noticed as well that
these communication ranges must be consistent among themselves. The figure shows that responders
considered ranges considerably larger for aerial platforms than for maritime platforms. Fifty kilometers
was the most responded for aerial, while for maritime 15km was the most considered. Therefore it
seems reasonable regarding the mentioned to consider that the communication tools should allow
maritime platforms to execute missions up to 30 km from the operator and should allow aerial
platforms to execute missions up to 50km from the operator. These ranges might be achieved using
communication transponders.
Figure 65 - Communication range for platforms (MSAR)
End-users were also asked to provide information about the currently used network technologies. As
it can be seen in Figure 66, VHF communications are the most widely used by the enquired End-users,
85% of whom use this technology. Satellite phones and mobile phone networks are also widely used
(70% and 66% percent of usage respectively) while WiFi technology is used by 30% of the enquired
End-users. Finally TETRA and WiMax technologies are not used by any enquired responder. Therefore
it is pertinent to consider that ICARUS communication tools should be able to integrate with VHF,
satellite phone, mobile phone and WiFi networks.
Deliverable 100.1 – V 8.0
Page 100
Figure 66 - Technology currently used for communications (MSAR)
The last question of this set of questions about communications was about the communication
middleware currently used by the enquired End-users. All of whom responded that they do not use
any communication middleware.
23. Functional Requirements – C2I This set of questions was concerning command and control Interfaces systems, with the aim of
understanding what is currently used by the end-users, and how could ICARUS systems be integrated
in their systems.
In the first question, end-users were asked about reliability of GPS availability. The great majority (95%)
considers that GPS availability is reliable, while the remaining 5% considers that it is only partially
reliable.
Figure 67 - GPS reliability for MSAR end-users
The end-users were also asked about currently used GIS tools. The Figure 68 presents their answers
where it can be seen that Google Maps/Earth are the widely used (more than 93% of responders use
Deliverable 100.1 – V 8.0
Page 101
it) followed by ArcGIS which is used by 25% of the respondents. So it is reasonable to consider that
future ICARUS MSAR C2I systems should be able to import data from both GIS tools mentioned, as well
as importing from OpenStreetMap might be important.
Figure 68 - GIS tools (MSAR)
The following question was about the map resolution end-users normally work with. The Average
response was about 104MegaPixels (Figure 69). It might be noticed that only two of the responders
answered this question.
Figure 69 - Map resolutions (MSAR)
The following question was about the map size end-users normally work with. The Average response
was about 250 km2 (Figure 70). It might be noticed that only four of the responders answered this
question.
Figure 70 - Map size (MSAR)
Deliverable 100.1 – V 8.0
Page 102
Responders were also asked about what command and control frameworks they are currently using.
Most of them indicated that don´t use any. The responders that are using a framework indicated ISC
and NIMS. Therefore ICARUS C2I efforts should be compatible with existing ICS, NIMS and eventually
AIIMS systems.
Figure 71 - C2I framework (MSAR)
About data sharing, end-users were asked about what technologies they use. The majority of whom
uses Google Docs and DropBox. In the other hand, Skyfile is only used by 25% of the inquired end-
users. Therefore it might be pertinent to consider that ICARUS tools should integrate with Google Docs
and DropBox services for sharing data.
Figure 72 - Data sharing services (MSAR)
The following question was about how much data traffic end-users organizations were prepared to
pay for handling the ICARUS tools. Most of the end-users (about 45%) respond 10 MB (Figure 73). So,
for MSAR scenarios in the ICARUS scope, it is pertinent to conclude that all communication requiring
satellite connections must be extremely limited and compressed to about 10MB a day to reduce the
costs.
Deliverable 100.1 – V 8.0
Page 103
Figure 73 - Satellite communications data traffic for a day (MSAR end-users)
When asked about the possibility of installing ICARUS software on their PCs during interventions, most
of the end-users responded yes they would be able of installing it (Figure 74).
Figure 74 - Ability of installing ICARUS software during an intervention (MSAR)
End-users were also asked about the usefulness of a mobile application (Figure 75) on a mobile phone
or tablet. Regarding the responses rates, most of the responders consider that a mobile application
would be extremely useful.
Figure 75 - Mobile applications usefulness (MSAR)
Deliverable 100.1 – V 8.0
Page 104
24. Training and support This set of questions is related with the support and training of the end-users for the best and faster
use of ICARUS unmanned tools.
In the first question of this set, end-users were asked to rate the usefulness of the developments
mentioned in the Figure 76. Regarding the responses it is obvious the importance of such training tools
for end-users, and the importance of the “real(istic)” approach in these training tools.
Figure 76 - Training tools developments (MSAR)
Figure 77 presents the time that end-users considered needed to train with the unmanned tools before
taking them to real mission for both situations, when robotic search and rescue tools were already
used, and when these tools were not used before. So considering only the training for ICARUS specific
robotic tools (considering that-users had contact with SAR robotic tools before), It should be possible
to complete the training within two weeks, even though it should be desirable that the training could
be complete within one week.
Figure 77 - Unmanned tools, required training time for MSAR end-user
Deliverable 100.1 – V 8.0
Page 105
Deliverable 100.1 – V 8.0
Page 106
25. Fine-tuning of Functional Requirements for MSAR tools by end-
user evaluation of operational trials
25.1. Introduction The sea trials that took place off Sesimbra, Portugal, in July 2013, within the scope of WP240 with the
main objective of testing the technical solution developed so far, were also used to obtain feedback
from end users. For that purpose, CINAV joined together an expert panel composed by navy officers
working in areas directly related to MSAR to attend part of those trials.
25.2. Trial Scenario These trials were conducted 2km off the coast of Sesimbra. All equipment and people involved was on
board the Portuguese Navy ship Bacamarte.
Figure 78 – Portuguese Navy ship Bacamarte.
With direct relevance for the end user feedback the following operations were performed:
Deployment of ROAZ (medium size USV developed at INESC) from Bacarmarte;
Autonomous behavior of ROAZ in area sweeping;
Gathering of video data sets with cameras integrated in ROAZ for autonomous detection of
victims on water;
Autonomous navigation of ROAZ towards a given destination;
Autonomous deployment of UCAP from ROAZ;
Autonomous navigation of UCAP towards a given destination.
Deliverable 100.1 – V 8.0
Page 107
These operations form just a subset of the all operations with unmanned tools that are foreseen for
MSAR within the scope of ICARUS. Nonetheless they have great relevance in the use of these tools and
give to experts an overall picture of the ICARUS approach.
It should be mentioned here that all these operations were performed using the command and control
tools as well as the communication infrastructure that are usually used by the development team of
INESC in their trials.
Figure 79 – Deployment of UCAP from ROAZ USV.
25.3. End-user feedback The experts were able to attend all the operations described above and offered their opinions about
different topics, as summarized below. Part of these information resulted also from discussions that
took place between researchers of the project and those experts during the trials, about topics not
directly covered in these set of trials.
Topic Information provided by experts
Deployment issues USV deployment from ship requires too much effort and is a complex operation to perform in emergency scenarios.
Manpower to operate tools It might be advantageous to have an operator looking at payload data and no directly focused on piloting or supervising the motion of the platform.
USV/UCAP navigation Environmental data (wind and water current direction and speed, wave height, period and direction) should be provided to operator and taken into account in automatic control to ensure that deployed assets (life rafts) do not drift away from victims.
USV/UCAP navigation Safety measures should be taken to avoid collisions of unmanned tools with victim on the water.
Deliverable 100.1 – V 8.0
Page 108
Sensing Tagging and counting of detected victims should also be considered.
Sensing/Communications/C2I Video feeding from USV/UCAP to operator is highly recommended.
C2I Availability of hydrographic information (bathymetry maps, tide information, etc.) at command and control interfaces can be quite relevant.
Training and Support Operation of unmanned tools should be standardized.
The information collected from the experts is mainly in accordance with the requirements already
established, as it was somehow expected. This way, and besides the requirement of deploying
USVs from ships which was changed to “optional”, no other requirement was changed, deleted or
created.
Deliverable 100.1 – V 8.0
Page 109
Part 4 – Wrap up & Conclusions
Deliverable 100.1 – V 8.0
Page 110
26. Ethical / Legal / Security / Exploitation Issues
26.1. Ethical issues
Like their human counterparts, unmanned platforms must respect the local ethical rules of the place
where they are deployed. For human SAR workers, INSARAG lists a long list of ethical issues to consider.
The ones also relevant to unmanned platforms are:
Taking of and showing pictures of victims or structures;
Defacing property such as occurs with the use of instruments making structural changes to
the environment;
The value that the local community attaches to life;
Access into sensitive (e.g. religious) areas.
Acceptance of working with unmanned tools
Cooperative behavior of victims
26.2. Legal issues Unmanned platforms should abide by the local laws and standards. A main impeding factor for the use
of UAS is for example the regulation on the access to the airspace by UAS. Other issues to be considered
are:
Local law enforcement practices;
Access into restricted (e.g. Military) areas;
Local communication restrictions and accepted use;
Handling of copyrighted data. Copyright is mostly a problem for satellite data. Copyright
protected material can in general be used for the actual crisis handling (in the sense that
copyright owners do not object, without giving a formal consent), but cannot be copied
further. In the case of Google Maps / Earth, it is an unwritten convention that Google allows
to use their map material for free for humanitarian means.
26.3. Security issues
Unmanned platforms must be able to correctly deal with any sensitive information they process.
26.4. Exploitation issues
The USAR community is a limited world, without too much spending capacity to buy expensive robotic
systems. An interesting idea to promote the use of robots is the “Roboticists Without Borders”
program by CRASAR (http://crasar.org/roboticists-without-borders/). The idea of this initiative is to
foster the adoption of search and rescue robots by demonstrating of the usability of these systems by
deploying them during real disasters worldwide at no cost to responders and agencies. Equipment
providers loan their rescue robots at no cost for up to 10 days during an incident and – in return – get
Deliverable 100.1 – V 8.0
Page 111
a great insight of the usefulness of their equipment in a real disaster, next to the publicity for their
product which this generates. Seeing the proven robotic tools in action in such a way could generate a
strong demand in the end-user community.
Dual use applications should be considered, because the military are in general also very interested
in SAR robots platforms and they have more spending capacity.
In any case, the end-users propose to make all systems modular, such that the system can be bought
piece by piece.
Deliverable 100.1 – V 8.0
Page 112
27. Conclusions
This section summarizes all the users’ functional requirements of the ICARUS system. Each requirement is prioritized as follows:
M - Mandatory requirement. This feature must be built into the final system. D - Desirable requirement. This feature should be built into the final system unless its cost is
too high. O - Optional requirement. This feature can be built into the final system at the Project
Manager's discretion. E - Possible future enhancement. This feature is recorded here so that the idea is not lost. The
decision on whether to include it in the system will depend on progress on the mandatory requirements.
27.1. Deployment Issues
Label Requirement Necessity
R1.1 No more than 2 to 3 operators should be required to operate the unmanned tools
M
R1.2 The combined ICARUS tools should at no time draw more than 1500W electrical power
M
R1.3 The unmanned tools should have the possibility to charge on (200W) solar panels.
D
R1.4 The unmanned tools should be self-sufficient from an energy point of view E
R1.5 All tools should work in an operational temperature range between -10°C and +40°C
M
R1.6 All tools should work in an operational temperature range between -20°C and +50°C
D
R1.7 Everything must be able to be packaged in a convenient and easy-to-handle package
M
R1.8 The developed tools may not contain any dangerous goods, to avoid problems and delays with customs
M
R1.9 It must be possible to deliver this package at the national airport, within 6 hours after getting notice of deployment.
D
R1.10 The weight of the total package must be under 100kg D
R1.11 The dimensions of the package should fit on two euro-pallets (120 x 160 x 95 cm)
D
Deliverable 100.1 – V 8.0
Page 113
27.2. Sensing Label Requirement Necessity
R2.1 The detector should have a false negative ratio of no higher than 23% (of course, we must strive to having it as low as possible)
M
R2.2 The sensor and the lens in particular should be easily cleanable M
R2.3 The weight of the sensor should be below 7kg M
R2.4 The weight of the sensor should be below 2kg D
R2.5 The dimensions of the sensor should be no larger than 20cm x 20cm x 20cm D
R2.6 The power consumption of the sensor should be below 30W D
R2.7 The sensor should have protection level 4 for liquid ingress protection and should be dust-tight (at least IP64)
D
27.3. UAS
Label Requirement Necessity
R3.1 It should at any moment in time be possible to operate the UAS under full manual control (certainly for legal issues)
M
R3.2 Indoor UAS systems should have a basic obstacle avoidance capability (but would mostly be tele-operated)
D
R3.3 Outdoor UAS systems should be able to fly a GPS-defined trajectory or map a GPS-defined zone
D
R3.4 All UAS must be equipped with a visual sensor M
R3.5 The indoor UAS must be equipped with an IR sensing device M
R3.6 There should be a possibility to do an automatic co-registration of visual images O
R3.7 Outdoor UAS should be equipped with a GPS system D
R3.8 Indoor UAS should be able to estimate their position within the building D
R3.9 Indoor UAS should have the ability to make 3D maps of the environment to assess the structural integrity of the building
D
R3.10 A human victim detection sensor should be integrated on the UAS D
R3.11 The indoor UAS must be able to operate in total darkness D
R3.12 All outdoor systems must be able to operate in twilight conditions D
R3.13 Outdoor UAS should be able to fly up to wind speeds of 50km/h D
R3.14 The indoor should have protection level 3 for liquid ingress protection and should be dust-tight (at least IP63)
D
R3.15 The outdoor UAS should have protection level 3 for liquid ingress protection and protection level 5 for solid particle (dust) protection (at least IP53)
D
R3.16 The endurance airplane must be able to fly an over-the-horizon mission to a point 50km away and back
E
R3.17 The endurance airplane must be able to fly a sectorization mission within a radius of 15km
O
R3.18 The outdoor UAS must be able to fly a mapping & victim search mission within a radius of 2km
D
R3.19 The indoor UAS should be able to fly an indoor mapping & victim search mission within a radius of 500m
D
R3.20 It should be possible to recharge the batteries within 2 hours D
Deliverable 100.1 – V 8.0
Page 114
27.4. UGVS
Label Requirement Necessity
R4.1 It must be possible to operate the SUGV using a range of shared autonomy levels
D
R4.2 The LUGV should have a local obstacle avoidance capability (but not higher-level AI)
D
R4.3 All UGVs must be equipped with a visual sensor M
R4.4 There should be a possibility to do an automatic co-registration of visual images O
R4.5 The SUGV must be equipped with an IR sensing device M
R4.6 The SUGV should be equipped with a loudspeaker and a microphone D
R4.7 The SUGV should be equipped with an air quality sensor D
R4.8 The SUGV should be equipped with a human victim detection sensor D
R4.9 The SUGV should be equipped with a dosimeter O
R4.10 The SUGV should be equipped with a heartbeat measurement sensor E
R4.11 The SUGV should be equipped with a chemical sensor O
R4.12 The SUGV should be equipped with a small basket O
R4.13 The SUGV should have the ability to make 3D maps of the environment to assess the structural integrity of the building
D
R4.14 The SUGV must be equipped with a small drilling system, enabling to insert a fiber-optical camera through a hole in a wall
E
R4.15 The LUGV should have a powerful manipulator arm M
R4.16 The SUGV should have no manipulator arm D
R4.17 The LUGV should have the capacity to cut through 4mm of structural steel O
R4.18 The LUGV should have the capacity to cut through 450mm of timber O
R4.19 The LUGV should have the capacity to break concrete walls and floors up to 150mm thick
O
R4.20 The LUGV should have the capacity to cut through 6mm of structural steel E
R4.21 The LUGV should have the capacity to cut through 600mm of timber E
R4.22 The LUGV should have the capacity to break concrete walls and floors up to 300mm thick
E
R4.23 The SUGV must be able to operate in total darkness M
R4.24 The LUGV must be able to operate in twilight conditions D
R4.25 All UGVs should have at least protection level 5 for liquid ingress protection D
R4.26 All UGVs should have protection level 6 for solid particle (dust) protection D
R4.27 All UGVs should be capable of withstanding a fall of 1.0m D
R4.28 All UGV sensors should be easy cleanable D
R4.29 All UGVs should be able to operate within a temperature range of -10°C to +50°C
D
R4.30 All UGVs should be able to operate within a temperature range of -30°C to +50°C
O
R4.31 All UGVs should have the ability to climb slopes between 30° and 45° D
R4.32 The SUGV should have a gap-crossing ability of about 20cm D
R4.33 The LUGV should have a gap-crossing ability of about 80cm D
R4.34 The SUGV should have a height-crossing ability of about 20cm D
R4.35 The LUGV should have a height-crossing ability of about 50cm D
R4.36 The SUGV should have a gap-crossing ability of about 40cm O
Deliverable 100.1 – V 8.0
Page 115
R4.37 The SUGV mass should not exceed 100kg M
R4.38 The SUGV should be man-packable (maximum mass around 50kg) D
R4.39 The SUGV should fit on 2 euro-pallets (160cm x 120 cm) M
R4.40 The SUGV should fit on 1 euro-pallet (80cm x 120 cm) D
R4.41 All UGVs should feature a modular design M
R4.42 All UGVs should have a battery autonomy of at least 2 hours D
R4.43 It should be possible to recharge the UGV batteries within 4 hours D
R4.44 The SUGV must be able to execute missions up to 500m from the operator within reinforced concrete building rubble
D
R4.45 The LUGV should have dimensions of 1.5m x 1.5m x 3.0m and a weight of about 1 ton
D
27.5. USVS AND RESCUE CAPSULES
Label Requirement Necessity
R5.1 The USV shall have at least 6 hours of battery autonomy. M
R5.2 The USV range shall be at least 40km. M
R5.3 The USV shall be capable of navigating at a minimum speed of 15Knots. D
R5.4 The USV should be able to operate within an air temperature range of 0°C to +30°C.
M
R5.5 The USV should be able to operate within an air temperature range of -10°C to +40°C.
D
R5.6 The USV should have protection level 8 for liquid ingress protection (IP8: Immersion beyond 1m).
D
R5.7 The USV shall be able to work in total darkness. M
R5.8 It should at any moment in time be possible to operate the USV under full Tele-Operation, either for legal or safety issues.
M
R5.9 The USV shall be able to follow autonomously GPS Trajectories. M
R5.10 The USV shall be able to operate fully autonomously. D
R5.11 The maximum length of the USV shall be 5 meters. D
R5.12 The maximum weight of the USV should be 1000kg. O
R5.13 The USV should be able to be deployed from a ship. D
R5.14 The USV should be able to be deployed from a beach. D
R5.15 The USV should be able to be deployed from a harbor. D
R5.16 The USV should be able to be deployed from an aircraft. O
R5.17 The USV shall be capable of operating under conditions of 3 meters wave height.
D
R5.18 The USV shall be equipped with a camera. M
R5.19 The USV shall be equipped with a GPS/INS. M
R5.20 The USV shall be equipped with an IR (Infrared) camera. M
R5.21 The USV shall be equipped with Radar. D
R5.22 The USV shall be equipped with Sonar. D
R5.23 The USV shall be equipped with a Human detection sensor. M
R5.24 The USV should be equipped with a hydrocarbons detector. D
R5.25 The USV should be equipped with a tomographic camera. D
R5.26 The USV should be equipped with water quality sensors. D
Deliverable 100.1 – V 8.0
Page 116
R5.27 The USV should be equipped with air quality sensors. O
R5.28 The USV should be equipped with a dosimeter. O
R5.29 The USV should be equipped with a loudspeaker and a microphone. O
R5.30 The Capsule shall have at least 6 hours of battery autonomy. M
R5.31 The Capsule range shall be at least 1km. D
R5.32 The Capsule shall be capable of navigating at a minimum speed of 2Knots.
D
R5.33 The Capsule should be able to operate within a temperature range of 0°C to +30°C.
M
R5.34 The Capsule should be able to operate within a temperature range of -10°C to +40°C.
O
R5.35 The maximum dimensions of the Capsules shall be 3.4x1.3x1.1 meters. D
R5.36 The maximum weight of the Capsules should be 80kg. D
R5.37 The capsule should be able to provide assistance to at least 4 people. D
R5.38 The Capsule should have protection level 8 for liquid ingress protection (IP8: Immersion beyond 1m).
D
R5.39 The Capsule shall be able to work in total darkness. M
R5.40 It should at any moment in time be possible to operate the Capsule under full Tele-Operation, either for legal or safety issues.
M
R5.41 The Capsule shall be able to move autonomously to a designated target position.
M
R5.42 The Capsule shall be able to operate fully autonomously. M
R5.43 The Capsules shall be capable of operating under conditions of 3 meters wave height.
D
27.6. Heterogeneous Teams
Label Requirement Necessity
R6.1 Multiple UAS systems should be able to collaborate for a collaborative mapping application scenario
O
R6.2 Multiple UAS systems should be able to collaborate for a damage assessment application scenario
O
R6.3 UGVs and UAS should be able to collaborate for a collaborative damage assessment scenario.
O
R6.4 UGVs and UAS should be able to collaborate for a scenario of aerial reconnaissance, followed by ground intervention
O
# TO BE UPDATED AFTER M3 #
27.7. Communication
Label Requirement Necessity
R7.1 ICARUS communication efforts should integrate with www.emergency.lu D
Deliverable 100.1 – V 8.0
Page 117
R7.2 The communication tools must allow an UGV to execute missions up to 500m from the operator, possibly within reinforced concrete building rubble
D
R7.3 The communication tools must allow the endurance airplane to fly an over-the-horizon mission to a point 50km away and back
E
R7.4 The communication tools must allow the endurance airplane to fly a sectorization mission within a radius of 15km
O
R7.5 The communication tools must allow the outdoor UAS to fly a mapping & victim search mission within a radius of 2km
D
R7.6 The communication tools must allow the indoor UAS to fly an indoor mapping & victim search mission within a radius of 500m
D
R7.7 For all missions, a live video feed of at least 20 fps from the unmanned platform to the operator is required
M
R7.8 The ICARUS communication tools should be able to function, even when the local communication infrastructure (telephone, internet) is crippled
D
R7.9 ICARUS communication equipment should be able to integrate with local mobile phone networks
D
R7.10 ICARUS communication equipment should be able to integrate with satellite phone networks
D
R7.11 ICARUS communication equipment should be able to integrate with local WiFi networks
D
R7.12 All communication requiring satellite connections must be extremely limited and compressed to about 10MB a day to reduce the costs
D
27.8. C2I
Label Requirement Necessity
R8.1 ICARUS C2I efforts should be compatible with existing ICS, NIMS and AIIMS systems
D
R8.2 HMI should be kept extremely simple D
R8.3 ICARUS tools should produce data compatible with the Humanitarian Data Model.
D
R8.4 Map updates should be possible once or twice a day D
R8.5 It should be able to import map data from Google Maps/Earth M
R8.6 It should be able to import map data from ESRI tools D
R8.7 It should be able to import map data from OpenStreetMap O
R8.8 The ICARUS mapping tools should be able to work with a wide range of map scales: from 10km² to 10.000km²
D
R8.9 The size of the maps to be sent over internet connections should never exceed 5MB
M
R8.10 All communication requiring satellite connections must be extremely limited and compressed to about 10MB a day to reduce the costs
D
R8.11 ICARUS tools should integrate with the DropBox service for sharing data D
R8.12 A software deployment model ensuring the widest possible exploitability must be chosen
D
Deliverable 100.1 – V 8.0
Page 118
R8.13 A standardized ICARUS C2I app for mobile GPS-enabled devices should be developed
D
R8.14 The mobile app should have an offline operational capability D
R8.15 The mobile app should have an operational capability without continuous GPS reception
D
27.9. Training & Support
Label Requirement Necessity
R9.1 ICARUS training developments should focus on “real(istic)” training tools D
R9.2 It should be possible to complete the training within one week M
27.10. Ethical / Legal / Security / Exploitation Issues
Label Requirement Necessity
R10.1 ICARUS tools must respect the local policies on taking and showing of pictures of victims or structures
D
R10.2 ICARUS tools must respect the local policies on defacing property such as occurs with the use of instruments making structural changes to the environment
D
R10.3 ICARUS tools must respect the value that the local community attaches to life D
R10.4 ICARUS tools must respect the local policies on access into sensitive (e.g. religious) areas
D
R10.5 ICARUS tools must respect the local law enforcement practices D
R10.6 ICARUS tools must respect the local policies on access into restricted (e.g. Military) areas
D
R10.7 ICARUS tools must respect the local policies on communication restrictions and accepted use
D
R10.8 ICARUS tools must respect the local policies on the handling of copyrighted data
D
R10.9 ICARUS tools must respect the local policies on the access to the airspace by unmanned vehicles
D
R10.10 Unmanned platforms must be able to correctly deal with any sensitive information they process
D
R10.11 ICARUS should connect with the “Roboticists Without Borders” program by CRASAR
O
R10.12 ICARUS should consider dual use applications to maximize exploitability D
R10.13 All ICARUS subsystems should feature a modular design M
R10.14 For reasons of acceptance, Icarus tools must be able to evoke a cooperative behavior of victims through technical means
D
Deliverable 100.1 – V 8.0
Page 119
Deliverable 100.1 – V 8.0
Page 120
APPENDIX A – REFERENCES “User Requirements Document”, EU-FP6-IST project View-Finder (GA 045541), Edited by Yvan
Baudoin, October 2007
“International Search and Rescue Advisory Group, GUIDELINES AND METHODOLOGY”, UNITED
NATIONS OFFICE FOR THE COORDINATION OF HUMANITARIAN AFFAIRS, Field Coordination
Support Section (INSARAG Secretariat), March 2011
“Search and Rescue Robots”, Book chapter of the Handbook of Robotics, edited by Bruno
Siciliano and Oussama Khatib and written by Robin R. Murphy, Satoshi Tadokoro, Daniele
Nardi, Adam Jacoff, Paolo Fiorini, Howie Choset,and Aydan M. Erkmen, Published by Springer
in 2008
Deliverable 100.1 – V 8.0
Page 121
APPENDIX B – USAR QUESTIONNAIRE FORM
Deliverable 100.1 – V 8.0
Page 122
Deliverable 100.1 – V 8.0
Page 123
Deliverable 100.1 – V 8.0
Page 124
Deliverable 100.1 – V 8.0
Page 125
Deliverable 100.1 – V 8.0
Page 126
Deliverable 100.1 – V 8.0
Page 127
Deliverable 100.1 – V 8.0
Page 128
Deliverable 100.1 – V 8.0
Page 129
Deliverable 100.1 – V 8.0
Page 130
Deliverable 100.1 – V 8.0
Page 131
Deliverable 100.1 – V 8.0
Page 132
Deliverable 100.1 – V 8.0
Page 133
Deliverable 100.1 – V 8.0
Page 134
Deliverable 100.1 – V 8.0
Page 135
Deliverable 100.1 – V 8.0
Page 136
Deliverable 100.1 – V 8.0
Page 137
Deliverable 100.1 – V 8.0
Page 138
APPENDIX C – MSAR QUESTIONNAIRE FORM
Deliverable 100.1 – V 8.0
Page 139
Deliverable 100.1 – V 8.0
Page 140
Deliverable 100.1 – V 8.0
Page 141
Deliverable 100.1 – V 8.0
Page 142
Deliverable 100.1 – V 8.0
Page 143
Deliverable 100.1 – V 8.0
Page 144
Deliverable 100.1 – V 8.0
Page 145
Deliverable 100.1 – V 8.0
Page 146
Deliverable 100.1 – V 8.0
Page 147
Deliverable 100.1 – V 8.0
Page 148
Deliverable 100.1 – V 8.0
Page 149
Deliverable 100.1 – V 8.0
Page 150
Deliverable 100.1 – V 8.0
Page 151
Deliverable 100.1 – V 8.0
Page 152
Deliverable 100.1 – V 8.0
Page 153
Deliverable 100.1 – V 8.0
Page 154
Deliverable 100.1 – V 6.0
Page 155
APPENDIX D – INSARAG EXTERNAL CLASSIFICATION REQUIREMENTS
Deliverable 100.1 – V 8.0
Page 156
Deliverable 100.1 – V 8.0
Page 157
Deliverable 100.1 – V 8.0
Page 158
Deliverable 100.1 – V 8.0
Page 159
Deliverable 100.1 – V 8.0
Page 160
Deliverable 100.1 – V 8.0
Page 161
Deliverable 100.1 – V 8.0
Page 162
Deliverable 100.1 – V 8.0
Page 163
Deliverable 100.1 – V 8.0
Page 164
Deliverable 100.1 – V 8.0
Page 165
Deliverable 100.1 – V 8.0
Page 166
Deliverable 100.1 – V 8.0
Page 167
Deliverable 100.1 – V 8.0
Page 168
APPENDIX E – AIR TRANSPORT CAPACITY
Deliverable 100.1 – V 8.0
Page 169
Deliverable 100.1 – V 8.0
Page 170