The basic idea behind the RAWFIE effort is the automated, remote operation of a large number of robotic devices for the purpose of assessing the performance of different technologies in the networking, sensing and mobile/autonomic application domains. RAWFIE considers three kinds of vehicles; UGVs, USVs and UAVs. The project aims to feature a significant number of UxV nodes in order to establish an extended test infrastructure for RAWFIE related experimentation purposes. All these items will be managed by a central controlling entity which will be programmed per case and fully overview/drive the operation of the respective mechanisms (e.g., auto-pilots, remote controlled ground vehicles). Internet connectivity will be extended to the mobile units to enable remote programming (over-the-air), control and data collection.
Requirements
RAWFIE promotes the experimentation under different technologies of devices (UxVs) that are equipped with different sensors, cameras and network interfaces. The following requirements have been defined on D3.3 to secure the interoperability with the RAWFIE platform, control units and testbeds:
- Compliance of UxVs to RAWFIE specification and interfaces
- to be able to operate in a RAWFIE Tesbed, a RAWFIE UxV interacts with the other Testbed entities (proxy, controllers, other UxV’s). As such the UxV shall conform to the RAWFIE global architecture and conceptual components defined in D4.8
- Each UxV shall have a unique Identification code
- Each UxV shall be able to operate autonomously
- Each UxV node shall ensure a minimum autonomy of 15-30 minutes (UXV-NOD-002
- MOP-7/D3.3)
- Each UxV node shall ensure payloadshall be able to carry additional payload equipment of at least 0.5 to 1 kg in weight. ( UXV-NOD-002 EMC-3/D3.3)
- UxVs shall provide the capability of taking manual remote control of the UxVs(UXV-NET-001(MOP-6/D3.3)
- UxV network interface management:
- each UxV shall be able to manage (detect/configure/control/use) the network interfaces installed, during the setup and execution of a mission (COM-3UXV-INT-014/D3.3)
- UxV communication interoperability with RAWFIE (incoming/outgoing):
- each UxV shall be able to receive/send and decode/encode the incoming/outgoing messages from the testbed and deliver them to the relevant on-board component.
- Each UxV node shall tag location and timing capability to each sensor readings (SSL2)
- UxV location and sensor data shall be made available to the experimenter
- UxVs shall be capable to revert to a safe mode
RAWFIE Support
When the requirements are fulfilled and a new UxV joins the federation, then a contact point form the technical team of RAWFIE is assigned to the newcomer. Regular skype calls between the contact points and the new beneficiaries are established once-per-week for resolving questions and efficiently overview the integration of the UxV in the testbeds.
RAWFIE team provides access to the Gitlab that is created in the project. Examples for the UxV on-board software to interact with the message bus are shared with the third parties. When the integration with Message Bus is completed and tested, the device can be delivered to the testbed. For UAVs a flight insurance for the devices is needed (for ROC2 and ROC3 devices these insurances are provided by the coordinator). When the devices are delivered to the testbeds, a series of validation scenarios – the Operational Safety Scenarios described in D4.9 - are conducted in order to ensure the safe operational behaviour of the UxVs. For this purpose, one or more nodes of the same type and manufacturer will be always verified.
The main failsafe topics addressed by the emergency scenarios are listed below[1]:
- Communication link failsafe
- Battery/fuel failsafe
- GCS[2] failsafe (related to failure in Resource Controller, Testbed Manager, etc.)
- Geofencing issues (Testbed Boundary breaching)
- Localization issues
- Collision issues
For each of these main topics identified, specific Operational Safety Scenarios have been defined by the consortium and are described in Section 6.6 of deliverable D4.9. Those tests ensure that any new vehicle complies with the platform rules, that it is properly interfaced with its testbed through the Message Bus and that it understands the minimal set of commands related to its category. A checklist that summarises the whole new vehicle integration procedure with pointers to the necessary information is available on RAWFIE Wiki tool.
As long as the project is running, the contact point for support is the project coordinator UOA. Once the project is completed, the primary contact point will be established by the organisation that takes over the RAWFIE platform according to the federation policy established in Work Package 2 and deliverable F2.3 – Federation Policy.
Training
New UxVs manufacturers must participate in webinar organized by UoA about RAWFIE ethics requirements as described in 2.3.3.1.3.
Integrated UxVs
Below all the devices delivered to RAWFIE testbeds and allocated in different countries are listed.
UxV\Testbeds
|
Type
|
HMOD
|
HAI
|
Catuav
|
CESA
|
RTART
|
DFKI
|
Total
|
PLADYPOS
|
USV
|
3
|
|
|
|
|
7
|
10
|
FLEXUS
|
USV
|
10
|
|
|
|
|
|
10
|
NIRIIS
|
USV
|
3
|
|
|
|
|
7
|
10
|
VENAC
|
UAV
|
2
|
6
|
4
|
|
|
|
12
|
DOGMA
|
Fixed Wings
|
2
|
4
|
2
|
2
|
|
|
10
|
FIBLE
|
UGV
|
5
|
|
2
|
|
3
|
|
10
|
ITCROWD
|
UAV
|
4
|
|
4
|
4
|
|
|
12
|
Total
|
|
29
|
10
|
12
|
6
|
3
|
14
|
74
|
[1] It must be noted that the failsafe topics addressed by the emergency scenarios are considered in the context of the RAWFIE system. Most UxVs (especially UAVs) provide inherent failsafe mechanisms related to most of these topics. These mechanisms should be regarded as an extra safety umbrella in case the RAWFIE specific ones fail
[2] GCS= Ground Control Station