Andi Lamprecht ·2026-05-11· 11 min read· Draft

CONFIDENTIAL | DroneUp | April 2026

1. Problem

Uncrew utilizes drone simulations in two forms:

• PX4 Sitl when integration testing its onboard software. By default PX4 Sitl wires in Gazebo as the underlying physics engine.
• Virtual Skynodes when executing manual system tests, product demos, training, exploration and sometimes debugging. Virtual Skynode features a APX4 Virtual-FMU launched in the SIH mode.

Using these off-the-shelf simulators has been a pragmatic choice, but it also surfaced a number of problems:

• Virtual Skynodes come as qemu virtual machines packaging Ubuntu-based Auterion OS, Docker and Mender. The packages are multiple gigabytes heavy and we only managed spawning them on GCP Virtual Machines away from our default Kubernetes orchestration. This makes Uncrew deployment fragmented, while standalone VMs are way more expensive that K8S pods.
• Virtual Skynodes keep Uncrew Auterion-locked.
• Running on n1-standard-4 (4 vCPUs, 15 GB Memory), Virtual Skynodes are very resource-hungry.
• Gazebo and Virtual FMU SIH are proper physics engines sporting all three derivatives of position, that is: speed, acceleration and jerk. They are great that way, but hardly any of our simulation use cases truly need that. They also seem to have a speed limit at about 10m/s. A simple constant speed progression through space would suffice in most cases and be both quicker and cheaper to execute.
• Gazebo and Virtual FMU SIH are non-deterministic likely trying to simulate environment (wind?) or sensor interference. This often results in erratic motion and integration tests failing for no good reason.
• Our integration tests execute Uncrew missions and each test ends up spending most of its time (tens of seconds) awaiting mission progression milestones so that it can make its assertions. This results in a single integration test run currently exceeding 40mins, while Uncrew integration tests aren’t even quite as thorough as we would like them to be. Discrete-event driven simulation might fit most of these tests equally well and take a small fraction of time to run.
• Neither Gazebo and Virtual FMU SIH are terrain aware, which results in the GPS position reporting conflicting alt (MSL) and alt_ellipsoid (wgs84) altitudes. Specifically the delta between the reported MSL and wgs84 altitudes doesn’t correspond to the GEOID at this place. Because Uncrew reports wgs84 telemetry to UTM for the purpose of conformance monitoring, this results in most of our simulated flights being non-conformant.
• Neither Gazebo, Virtual FMU SIH nor even MAVLINK cares to specify which exact GEOID is used for the reported MSL altitudes. We need to align these GEOIDs, especially between those we use for planning and those we use for execution. And we need to have a freedom to change the GEOID to pick the best one for a use case or region.

2. Background

• Along Onboard Uncrew, we today also deploy (as Auterion OS applications) a number of auxiliary simulators. Insofar as Auterion OS packaging isn’t necessary, we must continue to deploy a single simulation as a collection of docker containers. It is therefore incorrect to equate a simulator with a single docker container and it is probably incorrect to use the term “simulator” as something singular. A single simulation, as a collection of docker containers (including Onboard Uncrew), must be discernable in the K8s resource landscape - maybe by clever usage of namespaces or sidecars.
• Every simulation has a strict max duration, for which it will remain running, but we also need to maintain the freedom of killing ones we no longer need.
• Tests and users will need to be able to spawn simulations and we do this today with the Simulation Controller and the API it exposes.
• Onboard Uncrew may inadvertently rely on the slow progression through the physical derivatives of position and that reliance must be uprooted.
• Onboard Uncrew is deployed with factory certificates so that it can authenticate with the cloud portion of Uncrew.
• Uncrew does have Elevation Service able to not only offer terrain altitudes for specific geographic points, but do so for specific reference, convert between references and serve the underlying terrain and GEOID rasters. It supports a selection of GEOIDs, including NAVD88 and EGM96.

3 Requirements

3.1 Simulation Ensemble

A simulation instance is the full set of Kubernetes resources that together represent one running simulated drone. It includes the light-physics MAVLink component, Onboard Uncrew, and any auxiliary simulators. No single container constitutes a simulation on its own.

SIM-001 — A simulation instance shall be deployable entirely on Kubernetes without requiring a virtual machine or bare-metal host.

SIM-002 — All Kubernetes resources belonging to a single simulation instance shall share a unique instance identifier (via namespace or label set), enabling targeted monitoring, log aggregation, and teardown of that instance without affecting other instances.

SIM-003 — Each simulation instance shall include Onboard Uncrew as a containerised component.

SIM-004 — Each simulation instance shall include the auxiliary simulator components (as defined in uncrew-onboard-test) required for Onboard Uncrew to operate correctly.

SIM-005 — The simulation infrastructure shall provision each Onboard Uncrew instance with factory certificates at launch, enabling it to authenticate with Uncrew cloud services without manual certificate installation.

3.2 Simulation Lifecycle

SIM-006 — Each simulation instance shall be assigned a configurable maximum lifetime at creation time; when that lifetime expires all resources belonging to the instance shall be automatically terminated and reclaimed.

SIM-007 — The simulation infrastructure shall support on-demand termination of any running simulation instance, regardless of elapsed lifetime.

SIM-008 — A simulation instance shall be spawnable and terminable exclusively through the Simulation Controller API; no out-of-band mechanism shall be required.

3.3 Light-Physics MAVLink Component

The light-physics MAVLink component is the containerised service within the simulation instance that emulates an autopilot. It is one container among several in the ensemble.

SIM-009 — The light-physics MAVLink component shall not depend on Auterion OS, Virtual Skynode, or any Auterion-proprietary runtime.

SIM-010 — The light-physics MAVLink component shall not require Gazebo or any other third-party physics engine.

SIM-011 — The light-physics MAVLink component image shall not exceed 500 MB (compressed).

SIM-012 — The light-physics MAVLink component shall declare Kubernetes resource requests and limits of at most 0.25 CPU core and 256 MB of memory under nominal single-drone operation.

SIM-013 — The light-physics MAVLink component shall be ready to accept MAVLink connections within 1 second (±0.5 s) of container launch.

3.4 MAVLink Protocol Compatibility

SIM-014 — The light-physics MAVLink component shall accept inbound MAVLink connections over TCP and UDP on a configurable port.

SIM-015 — The light-physics MAVLink component shall publish a MAVLink HEARTBEAT message at 1 Hz identifying itself as a PX4-compatible autopilot (MAV_AUTOPILOT_PX4, MAV_TYPE_QUADROTOR).

SIM-016 — The light-physics MAVLink component shall publish GLOBAL_POSITION_INT at a configurable rate (default 10 Hz) reporting: latitude, longitude, altitude AMSL (mm), and relative altitude above the takeoff point (mm).

SIM-017 — The light-physics MAVLink component shall publish LOCAL_POSITION_NED at a configurable rate (default 10 Hz) reporting velocity components in the NED frame (m/s).

SIM-018 — The light-physics MAVLink component shall publish ATTITUDE at a configurable rate (default 10 Hz) reporting roll, pitch, and yaw (radians).

SIM-019 — The light-physics MAVLink component shall publish SYS_STATUS at 1 Hz reporting a static simulated battery state (voltage, current, remaining percentage) sufficient to satisfy health checks performed by uncrew-mavlink-shim.

SIM-020 — The light-physics MAVLink component shall publish GPS_RAW_INT at 1 Hz reporting a 3D GPS fix (GPS_FIX_TYPE_3D_FIX) with a configurable satellite count (default 10).

SIM-021 — The light-physics MAVLink component shall publish EXTENDED_SYS_STATE reflecting the current landed state (MAV_LANDED_STATE_ON_GROUND, MAV_LANDED_STATE_IN_AIR, MAV_LANDED_STATE_TAKEOFF, MAV_LANDED_STATE_LANDING).

SIM-022 — The light-physics MAVLink component shall publish HOME_POSITION upon arming, set to the takeoff coordinate.

SIM-023 — The light-physics MAVLink component shall publish MISSION_ITEM_REACHED when the simulated vehicle reaches each mission waypoint, reporting the zero-based waypoint sequence index.

SIM-024 — The light-physics MAVLink component shall publish STATUSTEXT messages for key state transitions (arm, takeoff, waypoint reached, land, disarm).

SIM-025 — The light-physics MAVLink component shall respond to MAV_CMD_COMPONENT_ARM_DISARM with COMMAND_ACK (MAV_RESULT_ACCEPTED) and transition the simulated vehicle to the armed or disarmed state accordingly.

SIM-026 — The light-physics MAVLink component shall respond to MAV_CMD_NAV_TAKEOFF with COMMAND_ACK (MAV_RESULT_ACCEPTED) and simulate a vertical climb to the commanded altitude at the configured vertical speed.

SIM-027 — The light-physics MAVLink component shall respond to MAV_CMD_DO_REPOSITION (GoTo) with COMMAND_ACK (MAV_RESULT_ACCEPTED) and simulate constant-speed horizontal flight to the target latitude/longitude/altitude.

SIM-028 — The light-physics MAVLink component shall respond to MAV_CMD_NAV_RETURN_TO_LAUNCH with COMMAND_ACK (MAV_RESULT_ACCEPTED) and simulate constant-speed flight back to the home position followed by a descent and landing sequence.

SIM-029 — The light-physics MAVLink component shall respond to MAV_CMD_NAV_LAND with COMMAND_ACK (MAV_RESULT_ACCEPTED) and simulate a vertical descent to ground level at the configured vertical speed.

SIM-030 — The light-physics MAVLink component shall respond to MAV_CMD_NAV_LOITER_UNLIM with COMMAND_ACK (MAV_RESULT_ACCEPTED) and hold position until a subsequent command is received.

SIM-031 — The light-physics MAVLink component shall implement the MAVLink mission upload protocol (MISSION_COUNT / MISSION_REQUEST_INT / MISSION_ITEM_INT / MISSION_ACK) and execute uploaded waypoint missions sequentially.

SIM-032 — The light-physics MAVLink component shall implement the MAVLink PARAM_REQUEST_READ protocol so that uncrew-mavlink-shim parameter reads (e.g. HOME_POSITION) complete without error.

SIM-033 — The light-physics MAVLink component shall respond to SET_MODE (or MAV_CMD_DO_SET_MODE) flight mode commands, transitioning to the requested PX4 custom mode and reflecting the new mode in subsequent HEARTBEAT messages.

3.5 Flight Mode Reporting

SIM-034 — The light-physics MAVLink component shall report a PX4-compatible custom main mode and sub-mode in every HEARTBEAT message, accurately reflecting the current phase of simulated flight.

SIM-035 — The following PX4 custom mode transitions shall be reported at the appropriate simulation phases:

3.6 Motion Model

The light-physics MAVLink component shall support three selectable motion models, configurable at simulation launch time:

SIM-036 — Physics model: The light-physics MAVLink component shall support a motion model that simulates all three derivatives of position (velocity, acceleration, jerk), reproducing the kinematic fidelity of Gazebo or Virtual FMU SIH. This model is provided as a compatibility option for test cases or use cases that require it.

SIM-037 — Constant-speed model: The light-physics MAVLink component shall support a motion model that moves the simulated vehicle at a constant configurable horizontal cruise speed (default 10 m/s) and a constant configurable vertical speed (default 3 m/s), with no acceleration or deceleration ramps. Position shall be interpolated along straight-line segments between the current position and the commanded target.

SIM-038 — Discrete-event model: The light-physics MAVLink component shall support a motion model in which simulated time advances instantaneously to the next commanded event (waypoint reached, altitude reached, land complete) without blocking on wall-clock time, enabling integration test suites to complete without real-time delays.

3.7 Altitude Reference Accuracy

SIM-039 — The light-physics MAVLink component shall report GPS_RAW_INT.alt (MSL) and GPS_RAW_INT.alt_ellipsoid (WGS84) with a geoid separation consistent with the actual geoid undulation at the simulated geographic location, as provided by the Uncrew Elevation Service.

SIM-040 — The GEOID model used to compute the MSL/WGS84 altitude separation shall be configurable; the component shall support at minimum the GEOID models available in the Uncrew Elevation Service (currently including NAVD88 and EGM96).

SIM-041 — The GEOID model configured in the light-physics MAVLink component shall match the GEOID model used by Uncrew planning, so that simulated flights are conformant with UTM altitude constraints.

3.8 Determinism

SIM-042 — Given identical initial conditions and identical command sequences, the light-physics MAVLink component shall produce identical telemetry output across repeated runs.

SIM-043 — The light-physics MAVLink component shall not inject random perturbations, simulated wind, sensor noise, or GPS drift unless explicitly enabled by configuration.

3.9 Health Reporting

SIM-044 — While the simulated vehicle is on the ground and disarmed, the light-physics MAVLink component shall report is_armable = true in health status, provided no fault condition has been injected.

SIM-045 — The light-physics MAVLink component shall report GPS health as good at all times unless a fault has been explicitly injected.

3.10 Fault Injection

SIM-046 — The light-physics MAVLink component shall support externally-triggered fault injection (via a control API or environment variable) for at least the following conditions: GPS loss, low battery, geofence breach.

SIM-047 — When a fault is injected, the light-physics MAVLink component shall reflect the fault state in the appropriate MAVLink telemetry messages within one telemetry publish cycle.

3.11 Onboard Uncrew Compatibility

SIM-048 — Before the light-physics simulation can replace PX4 SITL in uncrew-mavlink-shim integration tests, Onboard Uncrew shall be audited for code paths that depend on physics-accurate position derivatives (velocity ramping, acceleration, jerk); all such dependencies shall be removed or replaced with logic compatible with constant-speed motion.

SIM-049 — The audit required by SIM-048 shall produce a documented list of affected code paths and the remediation applied to each, traceable to the components in which the changes were made.