user requirements document - icarus project · deliverable 100.1 – v 8.0 page 3 acronyms &...

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

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

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


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


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


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


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


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


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


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


Part 1 - Introduction


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


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).


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.


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


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


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:


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.


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.


Figure 2: Methodology of Information Gathering


Part 2 – Urban Search & Rescue

Operations requirements


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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


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:


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.


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.


Figure 8 - Daytime / Nighttime operations


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.


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


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.


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


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.


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.


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.


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


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


Figure 12 - Drop height for the different UGVs


Figure 13 - UGV slope-climbing ability


Figure 14 - UGV gap-crossing ability


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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


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.


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.


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:


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:


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.


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.


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


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


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.


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.


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


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).


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


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.


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.


• 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


Part 3 – Maritime Search & Rescue

Operations requirements


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.


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)


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,


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.


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


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)


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


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.


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%)


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


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


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.


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.


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


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.


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.


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


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.


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.


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.


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.


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


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)


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.


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)


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


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.


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.


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.


Part 4 – Wrap up & Conclusions


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


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.


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


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


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


27.4. UGVS


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


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


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


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


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


R7.1 ICARUS communication efforts should integrate with www.emergency.lu D


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


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


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


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


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


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


APPENDIX B – USAR QUESTIONNAIRE FORM


APPENDIX C – MSAR QUESTIONNAIRE FORM


APPENDIX D – INSARAG EXTERNAL CLASSIFICATION REQUIREMENTS


APPENDIX E – AIR TRANSPORT CAPACITY

user requirements document - icarus project · deliverable 100.1 – v 8.0 page 3 acronyms &...

Documents