Skip to content

2.2.1 — Telemetry on a whisper, and three models rebuilt

Choose a tag to compare

@github-actions github-actions released this 06 Aug 17:26
· 319 commits to main since this release

Low-bandwidth telemetry

  • ArduPilot passthrough over CRSF / ExpressLRS — flight mode and the real armed bit, GPS fix and satellites, battery voltage / current / consumed mAh, distance and altitude to the actual home, velocity, attitude, throttle and status texts, over a plain ELRS link with no FrSky hardware. Both frame types (0x80, legacy 0x7F), single- and multi-packet forms. Native CRSF frames stay authoritative for what they already carry; passthrough fills their silences and wins for what only it knows. Autopilot side: RC_OPTIONS += 256, receiver serial on protocol 23.
  • MAVLink High Latency (HIGH_LATENCY2) — the one 42-byte message per five seconds a satellite- or LoRa-class link carries: position, MSL altitude, heading, speeds, throttle, battery, mode and armed state, in MAVLink 1 or 2 framing. A checksum-table bug had rejected every such message as corrupt since forever; fixed. Autopilot side: SERIALn_PROTOCOL = 43.
  • A MAVLink High Latency (UDP) network preset completes the loop: an autopilot boots with that stream off, so the preset sends MAV_CMD_CONTROL_HIGH_LATENCY to the typed modem address until telemetry answers, and a courtesy disable on disconnect. The protocol is pinned rather than detected (detection would stare at nothing for ten seconds), and sensor timeouts stretch to fifteen seconds on this link only — one dropped frame no longer greys the panel. The command frame is verified byte for byte against an independent X.25 implementation.
  • The copter mode table now knows LOITER — every LOITER flight over MAVLink used to show no mode at all.
  • tools/simflight.py speaks both: --passthrough weaves ArduPilot frames into its CRSF stream, --protocol mavlink-hl sends HIGH_LATENCY2, and --wait-enable makes it behave like a real high-latency port — silent until the app's enable command arrives, checksum verified, streaming to whoever asked. The simulator's own byte streams are replayed through the real parsers in the unit tests, and the full enable handshake was rehearsed on loopback with the app's exact bytes.

Three models, rebuilt

Model type now offers Helicopter beside Quad and Plane — same colour, same heading, both views, with its own nose-up map marker. All three 3D models were rebuilt in one design language and approved shape by shape from renders before ever being built into the app:

Quad Plane Helicopter
quad plane heli
  • Quad: a faceted military-style hull over plate arms with rounded tips flush at the motors, stacked motor bells, the sensor pod set into the chin, aerials on the tail deck.
  • Plane: tapered swept wings and tailplane, a swept fin, a fuselage that narrows to a wedge of a nose.
  • Helicopter: lofted cabin, tapering boom with tailplane, swept fin carrying a hubbed tail-rotor disc, skids on struts that meet the belly.

Since 2.2.0, also in here

Everything shipped into 2.2.0's replaced asset along the way: replay seek that places instead of inventing lines, one-world replay opening with playback held until the terrain is dressed, terrain tile caches that retry a bad network moment instead of remembering it forever, flight plans that settle onto ground as it arrives, the playback speed control (3× slower to 10× faster, never squeezed under ten seconds), and 3D memory roughly halved — terrain textures at half the bytes and no heap-side copies at all.