Apollo Avatar Apis

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

Avatar APIs

Context

MAVLINK(Micro Air Vehicle Link) is a lightweight communications protocol spoken by two leading UAV flight controllers: ArduPilot and PX4. Their popularity - inflated by them being open sourced and coolness of drones - have raised MAVLINK to the ranks of the de-facto standard for communicating with UAVs. Yet MAVLINK doesn’t scale well beyond powering toys:

• It has no structure - it’s a flat list of messages meant to be exchanged over a single UDP or TCP socket pair;

• It gives little attention to security:

  • It supports optional message signing with a single shared secret, implying single trusted party and thus equating authentication with authorization;
  • Encryption is something being slowly worked on.

• It is a list of fixed-sized messages and it would use flexible binary layout (protobufs?),

• It has no means of implementing Quality of Service (separate C2 from telemetry and video);

• It only pays attention to discoverability (of UAVs) on the same IP subnet with the UDP broadcast, but not over the Internet;

MAVLINK maintainers, Auterion, agree on every account and are looking for business cases to start evolving the protocol. Doing so is in our interest and having Auterion at the steering wheel is too - as only this way MAVLINK 3.0 (latest at 2.0) has a chance of becoming a new standard. This means we shouldn’t design it here and have to consider this evolution off-band for AirBoss.

We therefore have to keep evolving AirBoss over MAVLINK 2.0, but we need to hide it. MAVLINK cannot be spoken by browsers and since we know it will disappear we don’t want it to spread.

Decision

We postulate Apollo Pilot RPC a gRPC-based UAV control API tailored for remote pilots on solid broadbands and web browsers.

Apollo Pilot RPC should be modular clearly separating aspects into different gRPC services as coarsely illustrated below:

service GuidedFlightMode {
  rpc Stop() returns (Done);
  rpc GoTo(Location) returns (Done);
  rpc Land(Location) returns (Done);
  rpc Takeoff() returns (Done);
  rpc SetGroundSpeed(Speed);
  rpc SetVerticalSpeed(Speed);
}

service MissionFlightMode {
  rpc Put(Mission) returns (stream Progress);
  rpc Start() returns (stream Progress);
  rpc Stop() returns;
}

service Telemetry {
  rpc Subscribe() returns (stream TelemetryFrame);
}

service VideoFeed {
  rpc Start(Format) returns (URL);
  rpc Stop(URL);
}

Please note, the above is not the Apollo Pilot RPC specification. It’s only here to illustrate modularity, general spirit and direction. The actual specification will take many iterations to evolve and settle.

MAVLINK Shim

MAVLINK Shim is a shim/adaptor library translating to and from MAVLINK 3.0 to MAVLINK 2.0. It is also a process (i.e.: a self-contained proxy executable running the library). Its final resting place is on the UAV’s on-board compute where it could remain just a MAVLINK shim process or it could grow to become a more general reverse proxy (or part of thereof) admitting traffic into the UAV’s network and routing it into respective subsystems.

MAVLINK 3.0 Stopgap

We haven’t got MAVLINK 3.0 and won’t have it for quite some time. In the meantime we will reuse Apollo Pilot RPC in its place and have the first version of the MAVLINK Shim translate between Apollo Pilot RPC and MAVLINK 2.0. We need to be a bit careful though as the Pilot shouldn’t have the means of uploading a mission to the UAV, while the Avatar (on behalf of the Mission service) should.

Until we have means of deploying our software onto the UAV’s on-board computer, we will run the MAVLINK Shim on the backend just below the Avatar.

Avatar could just link and use the MAVLINK Shim in-process, though that would call for an exotic (albeit supported) in-process gRPC transport. This would cut out a network hop, but only in the development-interim. It wouldn’t be representative of the target setup and would thus complicate Avatar beyond reasonable.

Consequences

We’ve already decided to go with gRPC - consequences if any, will stem out that decision.

Putting Apollo Pilot RPC as the Avatar<->UAV forces that interface onto http, which may not scale to work in a high packet-loss cellular networks, but:

• This is only a guess that we need to verify in a test bed and with a flying drone;
• The interface should be replaced with MAVLINK 3.0 and we have to start the talks with Auterion.

Alternatives Considered

None beyond those mentioned above.