Onboard Base

Andi Lamprecht ·2026-05-11· 4 min read· Accepted

OnBoard Base Architecture

Context

Uncrew needs to start furnishing the drone’s onboard computer with more software (monitoring, alerting, perception, autonomy) and it thus has to start charting the onboard architecture. Putting all that function into our (to date) only onboard service; MAVLINKShim, would:

• Turn it into a monolith;
• Made it difficult to manage its resource consumption;
• Increase the blast radius of every failure/crash/restart;
• Produce code more complex than the sum of all its parts;
• Produce code more difficult to test;
• Prevent us from splitting the function between safety and non-safety critical and let us distribute it among the available HW domains (e.g.: Skynode and Skynode AI)

Auterion

Auterion Skynode and OS are a good reference for both the hardware and software architecture for a drone.

This specific datasheet reveals two CPUs:

• STM32F765 ARM microcontroller at the heart of the Flight Management Unit where the PX4 Flight Controller runs.
• ARM Cortex-A53 at the heart of the Mission Computer - a generic “compute” where Auterion OS orchestrates the Auterion Applications.

Auterion OS is mostly about orchestrating Auterion Apps, i.e.: have them run within its context. An Auterion App is a docker-compose file that can be installed on the Auterion OS either manually or via the Auterion Suite - an OTA solution that matches software releases with specific (groups of) drones.

ROS

The Robot Operating System is another excellent reference for a software architecture on a drone (being a robot). It

• offers the mathematical frameworks that helps the robot orient itself,
• is an orchestrator
• is a DDS-based message bus allowing Nodes publish messages other Nodes can read.
• a collection of services exposing request/response interfaces so one of those can represent a camera that can be told to look left.

The PX4 flight controller itself is organized around (seemingly custom) uORB messaging system that only resemble ROS, but can be mapped to ROS as PX4 starts to adopt ROS and its concepts.

ROS is a data-centric system and it is so recognizing that robots are distributed (cameras, actuators) systems that continuously analyze the sensor input and turn it into decisions. The camera captures 60 images per second putting each onto a ROS topic. There is a node that feeds these images into a visual odometry system that calculates the motion vector from the previous image thus producing a position fix that it puts on a ROS topic. There is also a node that reads the same images, passes them through the DDN-based object classification engine putting now named (cat, bird, tree) and localized objects onto a ROS topic. There is a node that that passes the same images through a Structure from Motion producing point clouds, which some other node downstream turns into a continuously updated digital surface model. Like our brains do it, ROS arranges for low level stimuli to be turned to higher level, semantically rich perception that can feed decisions of an autonomous system.

Spleenlab (the precision landing system fitted onto the PRISMSKY drones at DroneUp) chose to use ROS as their internal orchestration and message bus. They would be happy if the other onboard components they need to communicate with also spoke ROS. The only reason they attest they still speak MAVLINK with PX4 is lack of maturity of the PX4 ROS interface.

Decision

The Uncrew on-board presence aims at producing a fully autonomous system and we accept that a data-centric, distributed architecture is the correct model for it.

We conclude that roslaunch, the orchestration system for ROS, lacks containerization. Replacing roslaunch with docker compose is an alternative ROS itself “endorses”. We therefore think Auterion OS makes a better choice choosing docker-compose.

ROS is the industry standard and so seems the implementation of its message bus: DDS. We think the onboard actors/components of Uncrew should be ROS 2 Nodes.

Consequences

None that aren’t plainly visible here.

Alternatives Considered

Kubernetes

Kubernetes has been developed for horizontally scalable apps that run in the cloud. One can’t horizontally scale a Skynode. Kubernetes lacks the robot- and data-centrism and it doesn’t come with a message bus.