IEEE Robotics & Automation Magazine - September 2022 - 19

talk to another component. A component defines the interfaces
to communicate and receive data and fulfills the specific
task or function for which it is meant. A developer can
focus on a library to implement a particular function and
easily embed this within the framework's component to
transmit or receive data. The modularity of this development
approach is inherently implied, allowing the ease of replacement
or switching between components with the same interface
and providing a standardized component configuration.
Additionally, the deployment of a modular system can be
such that a crashed component does not bring down the
entire system, and FDIR can be more efficient.
When our time to make a decision on which framework
to use arrived (in the early 2010s), the shortlisted finalists
were ROS, Robot Construction Kit (RoCK), and Generator
of Modules. Eventually, the RoCK framework developed by
German Research Center for Artificial Intelligence (DFKI)
ranked at the top due to its more formal and structured
approach in software engineering. Based on the ORoCoS
Real-Time Toolkit, RoCK includes real-time logging capabilities,
modular deployment and component introspection,
and a state machine implemented at the component
level that allows for the control of its lifecycle. Despite the
larger ROS community, having a direct line of contact with
the RoCK developers at the DFKI turned out to be a significant
advantage. While we have also used ROS for some
particular developments and testing, the core software
stack of our lab rovers has grown and developed in the
RoCK framework.
However, during recent years, the RoCK framework community
and development activity have been significantly
reduced, with limited updates and overall releases. On the
other side, ROS published the second generation of its
framework, integrating many of the formal approaches and
software engineering aspects that RoCK included. Eventually,
in the last year, we have started migrating some components
to ROS2 and are currently considering a full migration
to the second generation of this popular framework.
Human
Interfaces
Joystick
Waypoint
Navigation
3DROCS
TM/TC
Mapping
Trigger*
DEM
Generation
Figure 6. A simplified overview of ExoTeR's principal TM/TC components. TC: telecommands; TM: telemetry; DEM: digital elevation map.
SEPTEMBER 2022 * IEEE ROBOTICS & AUTOMATION MAGAZINE *
19
Camera
Odometry
Without detailing the entirety of our software architecture
stack, Figure 6 shows a setup of some components that
has been of interest for some project support activities and
test campaigns that are detailed later in the " Test Campaigns "
section. This configuration was used for the assessment
of operational aspects, mainly utilizing, switching
between, and potentially blending various operation modes.
From left to right, the figure visualizes the remote interfaces
for human interaction down to the drivers to access the different
hardware elements.
3D Robot Operations Control System (3DROCS) represents
the rover monitoring and control station (MCS),
which is the base development from which the flight MCS
for the ExoMars mission has been derived [12]. The telemetry/telecommand
component running onboard the rover
takes care of implementing the communication protocol
with 3DROCS by translating and passing the telecommands
further down to the lower-level components and
gathering all relevant data from different sources to generate
the telemetry packets. The operators can also use a joystick
to control the rover, and an arbiter makes sure that
mutually exclusive access by either of the components is
guaranteed to avoid conflicts.
The rover can be controlled by direct body-level motion
commands or using higher-level navigation functions following
waypoints. The perception chain models the environment
and increases the awareness of the rover surroundings, both
onboard and at the remote station by forwarding the generated
maps. The localization estimate is computed by the odometry
component, which fuses the data from different sensors.
Further details about the implementation and theoretical
principles behind several of the components shown in Figure
6 can be found in the references given throughout the
" Test Campaigns " section.
Bridging the Gap to Space
As already stated in this section's introduction, we do not seek
space qualification, nor is our objective to produce or develop
HW Access
Motion
PTU
Control
Command
Arbiter
Locomotion
Switcher
Wheel
Walking
Locomotion
Control
IMU
Platform
Driver

IEEE Robotics & Automation Magazine - September 2022

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - September 2022