Stabilizing the ARES-01 Telemetry Pipeline

The problem was ambiguous ownership

The first ARES-01 telemetry prototype could wait indefinitely for a heartbeat while reporting only that it was connecting. The configured UDP endpoint was valid syntax, but it had no value unless another application was actually forwarding MAVLink packets to it. A second TCP endpoint could be open without carrying a configured MAVLink stream. The interface therefore needed to distinguish an open socket from a verified aircraft connection.

Mission Planner commonly uses the primary ArduPlane SITL endpoint on TCP port 5760. Secondary simulated serial endpoints appear on 5762 and 5763. Treating those numbers as interchangeable obscures which process owns a connection and whether a heartbeat is present. ARES now avoids competing for 5760 during automatic discovery and reports the endpoint it is evaluating.

An open port is not the same as a healthy MAVLink link. A verified connection requires a current heartbeat and a recognized vehicle context.

Bounded connection discovery

The connection service evaluates a configurable candidate list with bounded timeouts, closes failed sockets, and moves to the next candidate instead of freezing the UI. Local UDP forwarding remains the preferred separation model when Mission Planner can provide it; secondary SITL TCP ports remain practical fallbacks for the local research environment.

Diagnostics make the distinction visible: the active candidate, endpoint type, heartbeat timeout, system and component identifiers, detected vehicle type, reconnect attempt, and heartbeat age are reported independently. This turned connection troubleshooting from guesswork into an observable state machine.

• TCP 5760: commonly owned by Mission Planner as the primary SITL connection.
• TCP 5762 and 5763: secondary local SITL endpoints that must still provide a valid heartbeat.
• UDP 14550: useful only when a MAVLink source forwards packets to the listener.
• Localhost-only resolution: automatic command authority is never broadened to a remote endpoint.

Verify the aircraft before trusting the stream

ARES does not promote a socket to an operational connection solely because data arrives. It checks that the heartbeat identifies a fixed-wing vehicle and the ArduPilot autopilot family. Heartbeat age is monitored so a stale link cannot retain an apparently healthy status.

Read-only telemetry and simulation command control are separated. Telemetry can be observed without enabling commands. Simulation commands remain unavailable unless the endpoint resolves to localhost, the port is on the approved SITL list, the heartbeat is current, the vehicle is fixed-wing, ArduPilot is detected, and the operator explicitly enables Simulation Control Mode. Replay is always command-disabled.

Thread ownership and clean shutdown

Early dashboard closure exposed a Qt worker-lifecycle defect: the UI could be destroyed while a telemetry thread was still running. The corrected lifecycle uses cooperative cancellation, closes the MAVLink connection, signals completion, quits the thread, and waits for bounded shutdown. Telemetry acquisition remains outside the UI thread, while Qt signals carry normalized updates to visible widgets.

CSV logging and replay further separate acquisition from presentation. Recorded telemetry can be inspected without a running simulator, and bounded graph buffers prevent long sessions from growing UI memory without limit.

What was actually validated

ARES received live MAVLink telemetry from local ArduPlane SITL on TCP 127.0.0.1:5762. The observed stream included position, relative and mean-sea-level altitude, airspeed, groundspeed, heading, throttle, attitude, vertical speed, battery state, GPS fix, satellites, mode, and armed state. A simple waypoint mission was also executed in Mission Planner during development. This was an operator-observed SITL milestone, not a formal real-aircraft flight test.

The desktop application was also exercised at multiple supported screen resolutions, while later website work separately verified mobile and desktop layouts. These UI checks demonstrate presentation behavior, not flightworthiness.

The main lesson was that telemetry reliability depends less on adding more interfaces and more on making connection state, endpoint ownership, and command authority explicit.