**6. Software implementation**

### **6.1. Overview and background (RODOS)**

The underlying software problem with multiple, here three, real‐time processing units interacting with each other is a typical application of the real‐time operation system RODOS (Real‐time Onboard Dependable Operating System). An important aspect in the selection of RODOS is its integrated real‐time middleware. Developing the control and payload software on the top of a middleware provides the maximum of modularity. Different functions can be developed independently and simultaneously and it is very simple to interchange modules later without worrying about side effects because all modules are encapsulated as building blocks (BB) and they interact only through well‐defined interfaces.

RODOS was originally developed for space applications at DLR (German Space Agency) and is now distributed as open source for many applications such as Robotics [31, 32]. RODOS was designed for application domains demanding high dependability (e.g., space) and targets the irreducible complexity in all implemented functions. It follows the quote 'Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.' from Antoine de Saint‐Exupery.

The quadrocopter firmware—ranging from attitude control to route planning, and payload software, e.g., identification of objects—is implemented as a (software) network of communi‐ cating building blocks. A useful feature of the RODOS middleware is the location transparency of building blocks. BBs can interact and communicate in the same way independently of the location of communication partners. This includes the same computer, a different computer in the same vehicle, on a different vehicle or between vehicles and ground station (operator interface).

RODOS was designed as the brain of the Avionic system and introduced for the first time (2001) the NetworkCentric concept. A NetworkCentric core avionics machine consists of several harmonized components, which work together to implement dependable computing in a simple way. In a NetworkCentric system we have a software network of BBs and a hardware Network interconnecting vehicles (radio communication), computers inside of vehicles (buses and point‐to‐point links), intelligent devices (attached to buses) and simple devices attached to front end computers. To communicate with external units, including devices and other computing units, each node provides a gateway to the network and around the networks several devices may be attached to the system. The communication is asynchro‐ nous using the publisher–subscriber protocol. No fixed communication paths are established and the system can be reconfigured easily at run time. For instance, several replicas of the same software can run in different nodes and publish the result using the same topic without knowing each other. A voter may subscribe to that topic and vote on the correct result. Application can migrate from node to node or even to other vehicles without having to reconfigure the communication system. The core of the middleware distributes messages only locally, but using the integrated gateways to the NetworkCentric network, messages can reach any node and application in the network. The communication in the whole system includes software applications, computing nodes and even IO devices. Publishers make messages public under a given topic. Subscribers (zero, one or more) to a given topic get all messages which are published under this topic. As mentioned before, for this communication there is no difference in which node (computing unit or device) a publisher and subscribers is running, and beyond this they may be any combination of software tasks and hardware devices! To establish a transfer path, both the publisher and the subscriber must share the same topic. A topic is a pair consisting of a data type and an integer representing a topic identifier. Both the software middleware and the hardware network switch (called middleware switch) interpret the same publisher/subscriber protocol.

### **6.2. Software design**

A simplified RODOS‐based software design of the AQopterI8 quadrocopter can be seen in **Figure 14**. The different BBs exchange services by middleware topics. These BBs are located on three different CPUs, the on‐board MCU UC3A, the on‐board x86 PC LP‐180 and the ground segment (GS) with an off‐board CPU. The GS provides the user with a GUI and is used for commanding (**Figure 15**).

**Figure 14.** RODOS‐based software design (simplified).

irreducible complexity in all implemented functions. It follows the quote 'Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.'

The quadrocopter firmware—ranging from attitude control to route planning, and payload software, e.g., identification of objects—is implemented as a (software) network of communi‐ cating building blocks. A useful feature of the RODOS middleware is the location transparency of building blocks. BBs can interact and communicate in the same way independently of the location of communication partners. This includes the same computer, a different computer in the same vehicle, on a different vehicle or between vehicles and ground station (operator

RODOS was designed as the brain of the Avionic system and introduced for the first time (2001) the NetworkCentric concept. A NetworkCentric core avionics machine consists of several harmonized components, which work together to implement dependable computing in a simple way. In a NetworkCentric system we have a software network of BBs and a hardware Network interconnecting vehicles (radio communication), computers inside of vehicles (buses and point‐to‐point links), intelligent devices (attached to buses) and simple devices attached to front end computers. To communicate with external units, including devices and other computing units, each node provides a gateway to the network and around the networks several devices may be attached to the system. The communication is asynchro‐ nous using the publisher–subscriber protocol. No fixed communication paths are established and the system can be reconfigured easily at run time. For instance, several replicas of the same software can run in different nodes and publish the result using the same topic without knowing each other. A voter may subscribe to that topic and vote on the correct result. Application can migrate from node to node or even to other vehicles without having to reconfigure the communication system. The core of the middleware distributes messages only locally, but using the integrated gateways to the NetworkCentric network, messages can reach any node and application in the network. The communication in the whole system includes software applications, computing nodes and even IO devices. Publishers make messages public under a given topic. Subscribers (zero, one or more) to a given topic get all messages which are published under this topic. As mentioned before, for this communication there is no difference in which node (computing unit or device) a publisher and subscribers is running, and beyond this they may be any combination of software tasks and hardware devices! To establish a transfer path, both the publisher and the subscriber must share the same topic. A topic is a pair consisting of a data type and an integer representing a topic identifier. Both the software middleware and the hardware network switch (called middleware switch) interpret

A simplified RODOS‐based software design of the AQopterI8 quadrocopter can be seen in **Figure 14**. The different BBs exchange services by middleware topics. These BBs are located on three different CPUs, the on‐board MCU UC3A, the on‐board x86 PC LP‐180 and the ground

from Antoine de Saint‐Exupery.

16 Recent Advances in Robotic Systems

the same publisher/subscriber protocol.

**6.2. Software design**

interface).


**Figure 15.** I8Quatplay (Qt‐based Commanding Software GUI).

The IMU BB updates the IMU readings every 10 ms with already calibrated and conditioned sensor values. The attitude heading reference system (AHRS) computes from these data the 3D orientation of the quadrocopter using a complementary quaternion filter. The control BB performs the six degree of freedom (DOF) position control based on the position and orienta‐ tion given by other BBs. The Steer BB drives the motors and executes the commands of the operator and navigation.

The position is further required by the Object Search BB and sent via the gateway using the serial communication link as well as to the GS via WiFi. Thanks to the Gateway and Middle‐ ware of RODOS, these data can be used in the same way on another device as on the same device. The kernel of RODOS provides support for thread execution, time management, synchronization and transparent access to external devices such as sensors by the HAL (hardware abstraction layer) interface.
