Software

Technology Development Plan

In a first iteration a preliminary concept/Technology Development Plan was developed. This plan foresaw to implement the critical Software needed to provide the robots with the capabilities (e.g. autonomy, cooperation, interaction) on each individual robot, made use of the SW building blocks inherited from the previous SRC OGs as much as possible and used a HW architecture that foresaw multiple CPUs dedicated to specific tasks.

The SW ran on three different boards:

  1. UltraScale Board (same hardware used in OG’s ICU), contained OG4 (sensor pre-processing) and OG3 (Perception). This not only provided a low-cost equivalent to the ICU developed in OG4 but also reduced the need to perform large data transfers from OG4 to OG3 (since they ran on the same board), in practice accelerating the perception process.
  2. Intel board (Intel NUK) hold the multi-agent planner: acting as the “brain” of the system, it decided what to do in order to accomplish the plan. It could also re-plan when needed
  3. Intel board that holds the low-level drivered for some sensors and actuators of the robot
Review and Modification of OG Building Blocks
OG1 ESROCOS

was the framework to develop robot control software applications developed in the 1st PERASPERA SRC call. It included a set of tools that support different aspects of the development process, from architectural design to deployment and validation. In addition, it provided a set of core functions that are often used in robotics or space applications.

For CoRob-X, key elements of ESROCOS that we used were the TASTE Middleware, the ASN.1 Data Types, Logging Services, PUS Services, as well as OBCPs and the High-reliability layer, which had been enhanced in OG10 to support ARM processors, that provided a higher TRL that the Lab Level LINUX.

OG2 ERGO

is the software module for autonomy developed in the 1st SRC call. It is a generic toolset that allowed developing robotic systems that operate at different levels of autonomy, from tele-operations (E1) to full on-board autonomy (E4). For CoRob-X, the components of ERGO updated in OG11 to support multi-agent were re-used and adapted to the architecture of OG14. At REU level reused the Stellar planner, and we reused partially the code for the planetary (SW3) used in ERGO (that was running on the SherpaTT), this package currently being enhanced for OG10 ADE.

·       Moreover, ERGO  extended to cover UAV Guidance as well as 3D Guidance for the REU-2 (Coyote III). UMA  extend and found tune the combined motion of the robotic arm and the SherpaTT developed in OG10 ADE but adapted to the tether system.

OG3 InFuse

implements a Common Data Fusion Framework (CDFF) for the development, evaluation, and deployment of space robotics data fusion technologies. Any data fusion process developed with CDFF is portable to ESROCOS with minimal efforts due to a standardized interface among Data Fusion Nodes (DFN) and Data Fusion Processing Compounds (DFPC).

CDFF provides mechanisms to select DFPCs based on requests by ERGO and supply them with fused data products. It has interfaces to the OG4 I3DS sensors suite for controlling OG4 operational modes and configuring a limited set of sensor specific internal parameters.

OG4 I3DS

is a multi-sensor framework and module developed in OG4 within the 1st SRC call, for both orbital and planetary applications. I3DS provides a processing middleware that connects cameras, IMUs and other devices for example to the InFuse perception and navigation module. The I3DS avionics is based on the Zynq ICU (Instruments Control Unit) software module. Zynq pre-processes the sensor data and routes the information from each sensor to the OBC (On-Board Computer). Zynq connects to the OBC (On Board computer) and to the sensors through custom I/O interfaces, specifically tailored to each sensor that is part of the I3DS. In CoRob-X the I3DS suite in CoRob-X will be based on a selection of mission-relevant but relatively low-cost COTS sensors.

The suite will vary for each REU, depending on the specific role the REU plays in the exploration mission and the physical constraints (dimensions, payload limits etc.) it imposes. New (scientific) sensors, like the WISDOM GPR, will be included. This requires the adaptation of the OG4 ICU software and the development of new interfaces to the COTS sensors. In CoRob-X, SINTEF (who was core partner of OG4) will be responsible for this task. This approach, despite the additional effort for the software adaptation/development, could be beneficial for the sensor suite exploitation for terrestrial utilization, since the result would be a first functional prototype of the sensor suite based on commercial equipment and suitable for use on commercial ground applications.

OG5 SIROM

is a standard interface developed in the 1st SRC call in OG5. The preliminary analysis of the SIROM interface and experience in OG11 Pro-Act revealed that for the purpose of CoRob-X the interface is too bulky and complex. In CoRob-X, we will use HOTDOCK to connect REU-1 and REU-2 via a tether. HOTDOCK is a light and compact standard interface that was developed in OG11 by SPACE as a derivation of SIROM specifically for planetary robots.

HOTDOCK features a passive mechanical guidance mechanism that reduces the need for precision of manipulator positioning during the coupling. This makes the coupling process, which will be guided by a visual serving control loop, simpler and more robust.

OG11 CREW

In CoRob-X, the Cooperative Robotics for Enhanced Workforce (CREW) module developed in OG-11 Pro-Act were reused and enhanced into the Cooperative Robotics for Exploration of Extreme Environments (CRE-X) module, as the core component of the CoRob-X ADRES. CREW governed the de-centralized hierarchical decision making and joint activities of the REUs as the core of the cooperative robot team control system. This included joint decisions on the objectives of a mission (mission planning) and the steps needed to accomplish the mission (task planning). The concrete trajectories each robot had to follow (path planning) is done by each robot individually, using the guidance component from ERGO.

Each robot was equipped with the full capability-set of the software. However, depending on the operational mode of the specific robot (leader, follower, disconnected), only a sub-set of capabilities ws activated (Figure 1-16). A follower, for example, leaves the overall mission coordination to the leader. However, should it get disconnected or switch to a leader role, it was re-activated to  the mission coordination function.

In CoRob-X, the command hierarchy was to be implemented for three robots in the Space use case, and two robots in the terrestrial use case. In general, the CREW module, available at the end of OG11, was able to be easily reused and adapted for CoRob-X. GMV was performing the maintenance of ERGO in OG10 and will be responsible for its availability once OG11 is finished.