UNCREW-26-OnBoard-ROS-2-Interfaces Stage

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

Stage 1 Integration Plan

Context

We have to decide how to execute the first step of migrating the Uncrew onboard architecture to ROS2 multi-service reality. We have to do this to fulfil the business needs in a lock-step with executing sensible architectural changes.

Decision

The balance we aim to strike is to start breaking up MAVLINK-Shim iteratively without embarking on a rewrite-all marathon and risk being late. To take advantage of the existing divisions and pick low-hanging fruits.

To stay on this course we propose this basic rule-of-thumb; new features land in new services. Old features stay in old services, unless it prevents applying the rule;

At the time of writing, the only new feature we have to implement on-board is the smart RTL and we will have to accommodate it in this first stage. Smart RTL goes to the Uncrew Flight Controller and so we must be bring it to live.

Uncrew Flight Controller

• Written in Python

• Offers C2 Interface to the UAV Avatar Client (and thus demands that UAV Avatar Client is brought to live too), exposing:

  • Land, Hold, GoTo

  • Assign Mission

  • RTL - calculates Smart RTL path and calls MAVLINK-Shim’s Assign Mission thus overriding the current active mission. UFC calculates the Smart RTL either by:

    • finding the nearest landing point in the currently active mission;
    • calling the on-board pathfinder the moment it is available to be called;

Avatar Client Node

• Requires the Inventory Client to publish mTLS certificate.

• Needs to be brought to life because UFC demands it.

• C++ has problems with Protobufs, so we will write Avatar Client Node in Python;

• Calls Avatar the same way as MAVLINK-Shim’s Avatar Client does today.

  • Services C2 commands coming from Avatar and forwards them to UFC ROS2 Service;
  • Forwards telemetry and alerts from the respective telemetry and alert topics that MAVLINK-Shim writes to.

MAVLINK-Shim

• MAVLINK-Shim becomes a ROS2 Node

  • exposing ROS2 C2 Actions;
  • emitting throttled telemetry and alerts to ROS2 topics (instead of to Avatar as it does today)

• No new feature calls for the Monitoring Service, so we will not write it in Stage.

• MAVLINK-Shim remains responsible for

• Operator Action Request

• Breaking Uncrew missions into PX4 missions around delivery points;

• Crouching

Inventory Client

The UAV Inventory Client is already very well encapsulated. Has no exotic dependencies, but will have to start depending on and linking ROS2 so that it can fulfil its duties. Is already written in C++ and thus can remain this way.

Alternatives Considered

One alternative we have considered is to mitigate the risk (of being late) by:

• retrofitting the current requirements into existing MAVLINKShim AND
• embarking on full rewrite (in Python) of the onboard services with correct feature assignment.

It continues to be an attractive option as retrofitting Smart RTL to MAVLINKShim should still be relatively easy (2-3 weeks). That 2-3 weeks effort would eventually need to be written off as wasted.