User Requirements Document D100.1 Final Version
Grant Agreement number Project Acronym Project title Funding Scheme Project Starting date Project Duration Project Coordinator Deliverable reference number and full name Delivery Date Issue Issue Date Document produced by Document validated by Dissemination Level
Dissemination list:
ICARUS Partners
End-user respondents to the questionnaires
285417 ICARUS Integrated Components for Assisted Rescue and Unmanned Search operations Collaborative Project February 01, 2012 48 months Royal Military Academy – Geert De Cubber
[email protected] D100.1 – User Requirements Document M24 – January 31, 2014 8.0 M24 – January 31, 2014 RMA – Daniela Doroftei; INESC – Anibal Matos RMA – Geert De Cubber PU
Deliverable 620.1 – V1.0 Deliverable 100.1 – V 8.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 620.1 – V1.0
Page 2
Deliverable 100.1 – V 8.0
Acronyms & Definitions AIIMS C2I C4I CMC CRASAR EC ESRIF EU EUB FAST FCSS FP FRF GDACS GIS GPS ICS INSARAG IP IR JPG KML LEMA LUGV MSAR MST NIMS NLOS OCHA OSOCC PMB PMP RDC REA RPA
Australasian Inter-Service Incident Management System Command, Control & Intelligence Command, Control, Communications, Computers and Intelligence Crisis Management Centre Finland Center for Robot-Assisted Search and Rescue European Commission European Security Research and Innovation Forum European Union End-Users Board First Aid and Support Team Field Coordination Support Section Framework Programme Frontline Responses Finland Global Disaster Alert and Coordination System Geographical Information System Global Positioning System Incident Command System International Search and Rescue Advisory Group Ingress Protection Infrared Joint Photographic Experts Group Keyhole Markup Language Local Emergency Management Authority Large Unmanned Ground Vehicle Maritime Search And Rescue Management Support Team National Incident Management System Non-line-of-sight Office for the Coordination of Humanitarian Affairs On Site Operations Coordination Centre Project Management Board Project Management Plan Reception Departure Centre Research Executive Agency Remotely Piloted Aircraft
Page 3
Deliverable 100.1 – V 8.0
SAB SAR SLAM SRAD STAB SUGV TETRA THW UAS UGV UMP UN UNDAC URD USAR USB USV VHF VO WFS WMS WP WPC
Security Advisory Board Search And Rescue Simultaneous localization and mapping System Requirements & Architecture Definition Scientific and Technical Advisory Board Small Unmanned Ground Vehicle Terrestrial Trunked Radio Technisches Hilfswerk Unmanned Aerial System Unmanned Ground Vehicle Unmanned Marine Platforms United Nations United Nations Disaster Assessment and Coordination User Requirements Document Urban Search And Rescue Universal Serial Bus Unmanned Surface Vehicle Very high frequency Virtual On Site Operations Coordination Centre Web Feature System Web Mapping System Work Package Work Package Committee
Page 4
Deliverable 100.1 – V 8.0
Table of Contents Part 1 - Introduction ................................................................................................................... 11 1.
2.
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
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
Page 5
Deliverable 100.1 – V 8.0
8.
9.
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
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
Page 6
Deliverable 100.1 – V 8.0
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
Page 7
Deliverable 100.1 – V 8.0
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 C APSULES .............................................................................................. 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
Page 8
Deliverable 100.1 – V 8.0
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
Page 9
Deliverable 100.1 – V 8.0
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
Page 10
Deliverable 100.1 – V 8.0
Part 1 - Introduction
Page 11
Deliverable 100.1 – V 8.0
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 EUsponsored 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
Page 12
Deliverable 100.1 – V 8.0
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 disasterstruck 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).
Page 13
Deliverable 100.1 – V 8.0
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.
Page 14
Deliverable 100.1 – V 8.0
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
Page 15
Deliverable 100.1 – V 8.0
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
Page 16
Deliverable 100.1 – V 8.0
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 oneon-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:
Page 17
Deliverable 100.1 – V 8.0
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.
Page 18
Deliverable 100.1 – V 8.0
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.
Page 19
Deliverable 100.1 – V 8.0
Figure 2: Methodology of Information Gathering
Page 20
Deliverable 100.1 – V 8.0
Part 2 – Urban Search & Rescue Operations requirements
Page 21
Deliverable 100.1 – V 8.0
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.
Page 22
Deliverable 100.1 – V 8.0
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.
Page 23
Deliverable 100.1 – V 8.0
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.
Page 24
Deliverable 100.1 – V 8.0
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.
Page 25
Deliverable 100.1 – V 8.0
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.
Page 26
Deliverable 100.1 – V 8.0
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
Page 27
Deliverable 100.1 – V 8.0
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.
Page 28
Deliverable 100.1 – V 8.0
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.
Page 29
Deliverable 100.1 – V 8.0
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 h ow 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.
Page 30
Deliverable 100.1 – V 8.0
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.
Page 31
Deliverable 100.1 – V 8.0
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
Page 32
Deliverable 100.1 – V 8.0
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:
Page 33
Deliverable 100.1 – V 8.0
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.
Page 34
Deliverable 100.1 – V 8.0
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.
Page 35
Deliverable 100.1 – V 8.0
Figure 8 - Daytime / Nighttime operations
Page 36
Deliverable 100.1 – V 8.0
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 pointof 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.
Page 37
Deliverable 100.1 – V 8.0
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
Page 38
Deliverable 100.1 – V 8.0
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 pl atform. 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 ess ential. 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.
Page 39
Deliverable 100.1 – V 8.0
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 so me 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
Page 40
Deliverable 100.1 – V 8.0
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 as sess 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.
Page 41
Deliverable 100.1 – V 8.0
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.
Page 42
Deliverable 100.1 – V 8.0
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 -camerabased 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.
Page 43
Deliverable 100.1 – V 8.0
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 lowtech – 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
Page 44
Deliverable 100.1 – V 8.0
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
Page 45
Deliverable 100.1 – V 8.0
Figure 12 - Drop height for the different UGVs
Page 46
Deliverable 100.1 – V 8.0
Figure 13 - UGV slope-climbing ability
Page 47
Deliverable 100.1 – V 8.0
Figure 14 - UGV gap-crossing ability
Page 48
Deliverable 100.1 – V 8.0
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.
Page 49
Deliverable 100.1 – V 8.0
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.
Page 50
Deliverable 100.1 – V 8.0
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.
Page 51
Deliverable 100.1 – V 8.0
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.
Page 52
Deliverable 100.1 – V 8.0
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.
Page 53
Deliverable 100.1 – V 8.0
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.
Page 54
Deliverable 100.1 – V 8.0
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.
Page 55
Deliverable 100.1 – V 8.0
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.
Page 56
Deliverable 100.1 – V 8.0
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
Page 57
Deliverable 100.1 – V 8.0
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 multiplatform 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.
Page 58
Deliverable 100.1 – V 8.0
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.
Page 59
Deliverable 100.1 – V 8.0
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 humanrobot 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
Page 60
Deliverable 100.1 – V 8.0
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 GPSequipped 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.
Page 61
Deliverable 100.1 – V 8.0
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.
Page 62
Deliverable 100.1 – V 8.0
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 endusers:
Page 63
Deliverable 100.1 – V 8.0
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:
Page 64
Deliverable 100.1 – V 8.0
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.
Page 65
Deliverable 100.1 – V 8.0
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.
Page 66
Deliverable 100.1 – V 8.0
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
Page 67
Deliverable 100.1 – V 8.0
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
Page 68
Deliverable 100.1 – V 8.0
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 codeveloped 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.
Page 69
Deliverable 100.1 – V 8.0
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.
Page 70
Deliverable 100.1 – V 8.0
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
Page 71
Deliverable 100.1 – V 8.0
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).
Page 72
Deliverable 100.1 – V 8.0
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
Page 73
Deliverable 100.1 – V 8.0
13.2.8.
End-user feedback on C2I
The WP320 WP leader developed a first prototype of the Robot Command and Control (RC2) basestation 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.
Page 74
Deliverable 100.1 – V 8.0
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.
Page 75
Deliverable 100.1 – V 8.0
•
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
Page 76
Deliverable 100.1 – V 8.0
Part 3 – Maritime Search & Rescue Operations requirements
Page 77
Deliverable 100.1 – V 8.0
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.
Page 78
Deliverable 100.1 – V 8.0
Page 79
Deliverable 100.1 – V 8.0
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 coordinate 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)
Page 80
Deliverable 100.1 – V 8.0
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,
Page 81
Deliverable 100.1 – V 8.0
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.
Page 82
Deliverable 100.1 – V 8.0
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
Page 83
Deliverable 100.1 – V 8.0
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)
Page 84
Deliverable 100.1 – V 8.0
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
Page 85
Deliverable 100.1 – V 8.0
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.
Page 86
Deliverable 100.1 – V 8.0
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%)
Page 87
Deliverable 100.1 – V 8.0
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
Page 88
Deliverable 100.1 – V 8.0
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
Page 89
Deliverable 100.1 – V 8.0
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.
Page 90
Deliverable 100.1 – V 8.0
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.
Page 91
Deliverable 100.1 – V 8.0
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
Page 92
Deliverable 100.1 – V 8.0
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.
Page 93
Deliverable 100.1 – V 8.0
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.
Page 94
Deliverable 100.1 – V 8.0
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
Page 95
Deliverable 100.1 – V 8.0
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.
Page 96
Deliverable 100.1 – V 8.0
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.
Page 97
Deliverable 100.1 – V 8.0
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.
Page 98
Deliverable 100.1 – V 8.0
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.
Page 99
Deliverable 100.1 – V 8.0
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
Page 100
Deliverable 100.1 – V 8.0
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)
Page 101
Deliverable 100.1 – V 8.0
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 endusers. 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.
Page 102
Deliverable 100.1 – V 8.0
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)
Page 103
Deliverable 100.1 – V 8.0
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
Page 104
Deliverable 100.1 – V 8.0
Page 105
Deliverable 100.1 – V 8.0
25. Fine-tuning of Functional Requirements for MSAR tools by enduser 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.
Page 106
Deliverable 100.1 – V 8.0
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 Deployment issues Manpower to operate tools
USV/UCAP navigation
USV/UCAP navigation
Information provided by experts USV deployment from ship requires too much effort and is a complex operation to perform in emergency scenarios. 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. 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. Safety measures should be taken to avoid collisions of unmanned tools with victim on the water.
Page 107
Deliverable 100.1 – V 8.0
Sensing Sensing/Communications/C2I C2I
Training and Support
Tagging and counting of detected victims should also be considered. Video feeding from USV/UCAP to operator is highly recommended. Availability of hydrographic information (bathymetry maps, tide information, etc.) at command and control interfaces can be quite relevant. 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.
Page 108
Deliverable 100.1 – V 8.0
Part 4 – Wrap up & Conclusions
Page 109
Deliverable 100.1 – V 8.0
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
Page 110
Deliverable 100.1 – V 8.0
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.
Page 111
Deliverable 100.1 – V 8.0
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 R1.1
Requirement Necessity No more than 2 to 3 operators should be required to operate the unmanned M tools R1.2 The combined ICARUS tools should at no time draw more than 1500W electrical M power R1.3 The unmanned tools should have the possibility to charge on (200W) solar D panels. 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 M +40°C R1.6 All tools should work in an operational temperature range between -20°C and D +50°C R1.7 Everything must be able to be packaged in a convenient and easy-to-handle M package R1.8 The developed tools may not contain any dangerous goods, to avoid problems M and delays with customs R1.9 It must be possible to deliver this package at the national airport, within 6 hours D after getting notice of deployment. 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 D cm)
Page 112
Deliverable 100.1 – V 8.0
27.2.
Sensing
Label Requirement Necessity R2.1 The detector should have a false negative ratio of no higher than 23% (of course, M we must strive to having it as low as possible) 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 D should be dust-tight (at least IP64)
27.3. Label R3.1 R3.2 R3.3 R3.4 R3.5 R3.6 R3.7 R3.8 R3.9 R3.10 R3.11 R3.12 R3.13 R3.14 R3.15 R3.16 R3.17 R3.18 R3.19 R3.20
UAS
Requirement Necessity It should at any moment in time be possible to operate the UAS under full M manual control (certainly for legal issues) Indoor UAS systems should have a basic obstacle avoidance capability (but D would mostly be tele-operated) Outdoor UAS systems should be able to fly a GPS-defined trajectory or map a D GPS-defined zone All UAS must be equipped with a visual sensor M The indoor UAS must be equipped with an IR sensing device M There should be a possibility to do an automatic co-registration of visual images O Outdoor UAS should be equipped with a GPS system D Indoor UAS should be able to estimate their position within the building D Indoor UAS should have the ability to make 3D maps of the environment to D assess the structural integrity of the building A human victim detection sensor should be integrated on the UAS D The indoor UAS must be able to operate in total darkness D All outdoor systems must be able to operate in twilight conditions D Outdoor UAS should be able to fly up to wind speeds of 50km/h D The indoor should have protection level 3 for liquid ingress protection and D should be dust-tight (at least IP63) The outdoor UAS should have protection level 3 for liquid ingress protection D and protection level 5 for solid particle (dust) protection (at least IP53) The endurance airplane must be able to fly an over-the-horizon mission to a E point 50km away and back The endurance airplane must be able to fly a sectorization mission within a O radius of 15km The outdoor UAS must be able to fly a mapping & victim search mission within D a radius of 2km The indoor UAS should be able to fly an indoor mapping & victim search mission D within a radius of 500m It should be possible to recharge the batteries within 2 hours D
Page 113
Deliverable 100.1 – V 8.0
27.4. Label R4.1 R4.2 R4.3 R4.4 R4.5 R4.6 R4.7 R4.8 R4.9 R4.10 R4.11 R4.12 R4.13 R4.14 R4.15 R4.16 R4.17 R4.18 R4.19 R4.20 R4.21 R4.22 R4.23 R4.24 R4.25 R4.26 R4.27 R4.28 R4.29 R4.30 R4.31 R4.32 R4.33 R4.34 R4.35 R4.36
UGVS
Requirement Necessity It must be possible to operate the SUGV using a range of shared autonomy D levels The LUGV should have a local obstacle avoidance capability (but not higherD level AI) All UGVs must be equipped with a visual sensor M There should be a possibility to do an automatic co-registration of visual images O The SUGV must be equipped with an IR sensing device M The SUGV should be equipped with a loudspeaker and a microphone D The SUGV should be equipped with an air quality sensor D The SUGV should be equipped with a human victim detection sensor D The SUGV should be equipped with a dosimeter O The SUGV should be equipped with a heartbeat measurement sensor E The SUGV should be equipped with a chemical sensor O The SUGV should be equipped with a small basket O The SUGV should have the ability to make 3D maps of the environment to D assess the structural integrity of the building The SUGV must be equipped with a small drilling system, enabling to insert a E fiber-optical camera through a hole in a wall The LUGV should have a powerful manipulator arm M The SUGV should have no manipulator arm D The LUGV should have the capacity to cut through 4mm of structural steel O The LUGV should have the capacity to cut through 450mm of timber O The LUGV should have the capacity to break concrete walls and floors up to O 150mm thick The LUGV should have the capacity to cut through 6mm of structural steel E The LUGV should have the capacity to cut through 600mm of timber E The LUGV should have the capacity to break concrete walls and floors up to E 300mm thick The SUGV must be able to operate in total darkness M The LUGV must be able to operate in twilight conditions D All UGVs should have at least protection level 5 for liquid ingress protection D All UGVs should have protection level 6 for solid particle (dust) protection D All UGVs should be capable of withstanding a fall of 1.0m D All UGV sensors should be easy cleanable D All UGVs should be able to operate within a temperature range of -10°C to D +50°C All UGVs should be able to operate within a temperature range of -30°C to O +50°C All UGVs should have the ability to climb slopes between 30° and 45° D The SUGV should have a gap-crossing ability of about 20cm D The LUGV should have a gap-crossing ability of about 80cm D The SUGV should have a height-crossing ability of about 20cm D The LUGV should have a height-crossing ability of about 50cm D The SUGV should have a gap-crossing ability of about 40cm O
Page 114
Deliverable 100.1 – V 8.0
R4.37 R4.38 R4.39 R4.40 R4.41 R4.42 R4.43 R4.44
The SUGV mass should not exceed 100kg The SUGV should be man-packable (maximum mass around 50kg) The SUGV should fit on 2 euro-pallets (160cm x 120 cm) The SUGV should fit on 1 euro-pallet (80cm x 120 cm) All UGVs should feature a modular design All UGVs should have a battery autonomy of at least 2 hours It should be possible to recharge the UGV batteries within 4 hours The SUGV must be able to execute missions up to 500m from the operator within reinforced concrete building rubble R4.45 The LUGV should have dimensions of 1.5m x 1.5m x 3.0m and a weight of about 1 ton
27.5. Label R5.1 R5.2 R5.3 R5.4 R5.5 R5.6 R5.7 R5.8
R5.9 R5.10 R5.11 R5.12 R5.13 R5.14 R5.15 R5.16 R5.17 R5.18 R5.19 R5.20 R5.21 R5.22 R5.23 R5.24 R5.25 R5.26
M D M D M D D D D
USVS AND RESCUE CAPSULES Requirement The USV shall have at least 6 hours of battery autonomy. The USV range shall be at least 40km. The USV shall be capable of navigating at a minimum speed of 15Knots. The USV should be able to operate within an air temperature range of 0°C to +30°C. The USV should be able to operate within an air temperature range of 10°C to +40°C. The USV should have protection level 8 for liquid ingress protection (IP8: Immersion beyond 1m). The USV shall be able to work in total darkness. It should at any moment in time be possible to operate the USV under full Tele-Operation, either for legal or safety issues. The USV shall be able to follow autonomously GPS Trajectories. The USV shall be able to operate fully autonomously. The maximum length of the USV shall be 5 meters. The maximum weight of the USV should be 1000kg. The USV should be able to be deployed from a ship. The USV should be able to be deployed from a beach. The USV should be able to be deployed from a harbor. The USV should be able to be deployed from an aircraft. The USV shall be capable of operating under conditions of 3 meters wave height. The USV shall be equipped with a camera. The USV shall be equipped with a GPS/INS. The USV shall be equipped with an IR (Infrared) camera. The USV shall be equipped with Radar. The USV shall be equipped with Sonar. The USV shall be equipped with a Human detection sensor. The USV should be equipped with a hydrocarbons detector. The USV should be equipped with a tomographic camera. The USV should be equipped with water quality sensors.
Necessity M M D M D D M M M D D O D D D O D M M M D D M D D D
Page 115
Deliverable 100.1 – V 8.0
R5.27 R5.28 R5.29 R5.30 R5.31 R5.32
The USV should be equipped with air quality sensors. The USV should be equipped with a dosimeter. The USV should be equipped with a loudspeaker and a microphone. The Capsule shall have at least 6 hours of battery autonomy. The Capsule range shall be at least 1km. The Capsule shall be capable of navigating at a minimum speed of 2Knots. The Capsule should be able to operate within a temperature range of 0°C to +30°C. The Capsule should be able to operate within a temperature range of 10°C to +40°C. The maximum dimensions of the Capsules shall be 3.4x1.3x1.1 meters. The maximum weight of the Capsules should be 80kg. The capsule should be able to provide assistance to at least 4 people. The Capsule should have protection level 8 for liquid ingress protection (IP8: Immersion beyond 1m). The Capsule shall be able to work in total darkness. It should at any moment in time be possible to operate the Capsule under full Tele-Operation, either for legal or safety issues. The Capsule shall be able to move autonomously to a designated target position. The Capsule shall be able to operate fully autonomously. The Capsules shall be capable of operating under conditions of 3 meters wave height.
R5.33 R5.34 R5.35 R5.36 R5.37 R5.38 R5.39 R5.40 R5.41 R5.42 R5.43
27.6.
O O O M D D M O D D D D M M M M D
Heterogeneous Teams
Label R6.1
Requirement Necessity Multiple UAS systems should be able to collaborate for a collaborative mapping O application scenario R6.2 Multiple UAS systems should be able to collaborate for a damage assessment O application scenario R6.3 UGVs and UAS should be able to collaborate for a collaborative damage O assessment scenario. R6.4 UGVs and UAS should be able to collaborate for a scenario of aerial O reconnaissance, followed by ground intervention # TO BE UPDATED AFTER M3 #
27.7. Label R7.1
Communication
Requirement ICARUS communication efforts should integrate with www.emergency.lu
Necessity D
Page 116
Deliverable 100.1 – V 8.0
R7.2
The communication tools must allow an UGV to execute missions up to 500m from the operator, possibly within reinforced concrete building rubble R7.3 The communication tools must allow the endurance airplane to fly an over-thehorizon mission to a point 50km away and back R7.4 The communication tools must allow the endurance airplane to fly a sectorization mission within a radius of 15km R7.5 The communication tools must allow the outdoor UAS to fly a mapping & victim search mission within a radius of 2km R7.6 The communication tools must allow the indoor UAS to fly an indoor mapping & victim search mission within a radius of 500m R7.7 For all missions, a live video feed of at least 20 fps from the unmanned platform to the operator is required R7.8 The ICARUS communication tools should be able to function, even when the local communication infrastructure (telephone, internet) is crippled R7.9 ICARUS communication equipment should be able to integrate with local mobile phone networks R7.10 ICARUS communication equipment should be able to integrate with satellite phone networks R7.11 ICARUS communication equipment should be able to integrate with local WiFi networks R7.12 All communication requiring satellite connections must be extremely limited and compressed to about 10MB a day to reduce the costs
27.8.
D E O D D M D D D D D
C2I
Label R8.1
Requirement Necessity ICARUS C2I efforts should be compatible with existing ICS, NIMS and AIIMS D systems R8.2 HMI should be kept extremely simple D R8.3 ICARUS tools should produce data compatible with the Humanitarian Data D Model. 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 D scales: from 10km² to 10.000km² R8.9 The size of the maps to be sent over internet connections should never exceed M 5MB R8.10 All communication requiring satellite connections must be extremely limited D and compressed to about 10MB a day to reduce the costs 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 D be chosen
Page 117
Deliverable 100.1 – V 8.0
R8.13 A standardized ICARUS C2I app for mobile GPS-enabled devices should be developed R8.14 The mobile app should have an offline operational capability R8.15 The mobile app should have an operational capability without continuous GPS reception
27.9. Label R9.1 R9.2
R10.2
R10.3 R10.4 R10.5 R10.6 R10.7 R10.8 R10.9 R10.10 R10.11 R10.12 R10.13 R10.14
D D
Training & Support
Requirement ICARUS training developments should focus on “real(istic)” training tools It should be possible to complete the training within one week
27.10. Label R10.1
D
Necessity D M
Ethical / Legal / Security / Exploitation Issues
Requirement Necessity ICARUS tools must respect the local policies on taking and showing of pictures D of victims or structures ICARUS tools must respect the local policies on defacing property such as D occurs with the use of instruments making structural changes to the environment ICARUS tools must respect the value that the local community attaches to life D ICARUS tools must respect the local policies on access into sensitive (e.g. D religious) areas ICARUS tools must respect the local law enforcement practices D ICARUS tools must respect the local policies on access into restricted (e.g. D Military) areas ICARUS tools must respect the local policies on communication restrictions D and accepted use ICARUS tools must respect the local policies on the handling of copyrighted D data ICARUS tools must respect the local policies on the access to the airspace by D unmanned vehicles Unmanned platforms must be able to correctly deal with any sensitive D information they process ICARUS should connect with the “Roboticists Without Borders” program by O CRASAR ICARUS should consider dual use applications to maximize exploitability D All ICARUS subsystems should feature a modular design M For reasons of acceptance, Icarus tools must be able to evoke a cooperative D behavior of victims through technical means
Page 118
Deliverable 100.1 – V 8.0
Page 119
Deliverable 100.1 – V 8.0
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
Page 120
Deliverable 100.1 – V 8.0
APPENDIX B – USAR QUESTIONNAIRE FORM
Page 121
Deliverable 100.1 – V 8.0
Page 122
Deliverable 100.1 – V 8.0
Page 123
Deliverable 100.1 – V 8.0
Page 124
Deliverable 100.1 – V 8.0
Page 125
Deliverable 100.1 – V 8.0
Page 126
Deliverable 100.1 – V 8.0
Page 127
Deliverable 100.1 – V 8.0
Page 128
Deliverable 100.1 – V 8.0
Page 129
Deliverable 100.1 – V 8.0
Page 130
Deliverable 100.1 – V 8.0
Page 131
Deliverable 100.1 – V 8.0
Page 132
Deliverable 100.1 – V 8.0
Page 133
Deliverable 100.1 – V 8.0
Page 134
Deliverable 100.1 – V 8.0
Page 135
Deliverable 100.1 – V 8.0
Page 136
Deliverable 100.1 – V 8.0
Page 137
Deliverable 100.1 – V 8.0
APPENDIX C – MSAR QUESTIONNAIRE FORM
Page 138
Deliverable 100.1 – V 8.0
Page 139
Deliverable 100.1 – V 8.0
Page 140
Deliverable 100.1 – V 8.0
Page 141
Deliverable 100.1 – V 8.0
Page 142
Deliverable 100.1 – V 8.0
Page 143
Deliverable 100.1 – V 8.0
Page 144
Deliverable 100.1 – V 8.0
Page 145
Deliverable 100.1 – V 8.0
Page 146
Deliverable 100.1 – V 8.0
Page 147
Deliverable 100.1 – V 8.0
Page 148
Deliverable 100.1 – V 8.0
Page 149
Deliverable 100.1 – V 8.0
Page 150
Deliverable 100.1 – V 8.0
Page 151
Deliverable 100.1 – V 8.0
Page 152
Deliverable 100.1 – V 8.0
Page 153
Deliverable 100.1 – V 8.0
Page 154
Deliverable 100.1 – V 6.0
APPENDIX D – INSARAG EXTERNAL CLASSIFICATION REQUIREMENTS
Page 155
Deliverable 100.1 – V 8.0
Page 156
Deliverable 100.1 – V 8.0
Page 157
Deliverable 100.1 – V 8.0
Page 158
Deliverable 100.1 – V 8.0
Page 159
Deliverable 100.1 – V 8.0
Page 160
Deliverable 100.1 – V 8.0
Page 161
Deliverable 100.1 – V 8.0
Page 162
Deliverable 100.1 – V 8.0
Page 163
Deliverable 100.1 – V 8.0
Page 164
Deliverable 100.1 – V 8.0
Page 165
Deliverable 100.1 – V 8.0
Page 166
Deliverable 100.1 – V 8.0
Page 167
Deliverable 100.1 – V 8.0
APPENDIX E – AIR TRANSPORT CAPACITY
Page 168
Deliverable 100.1 – V 8.0
Page 169
Deliverable 100.1 – V 8.0
Page 170
