2026-10-08 · Feature

Joystick over CRSF, not MAVLink.

Flying from a gamepad used to mean RC_CHANNELS_OVERRIDE at 10 Hz over the telemetry link. On a digital link that queues MAVLink behind video, the sticks arrive late and arrive lumpy, while the link's own RC channel sails through untouched. So the Joystick tab now has a third mode, CRSF out: groundpost becomes the handset and emits real CRSF RC frames at 50 Hz, the same bytes an ELRS or Crossfire receiver would hand the autopilot.

Where the frames go is a Sharing tab decision. A new RC LINK section holds two row kinds. CRSF RC (UDP) sends one frame per datagram to a host and port, for an air-side companion that writes them into the flight controller's RC UART. That is the pattern fibre-optic stations use: the ground box reads the handset as a USB joystick and the RC channels ride the IP link. CRSF RC (Serial) puts the same frames on a second USB-UART, transmit only, for an STM32 bridge or an RC module's handset input. 115200 baud is plenty: a frame is 26 bytes and takes two milliseconds.

The part worth knowing before you fly is what happens when the stream stops. It stops on purpose. Press STOP, unplug the gamepad, close the app, or let the window stall, and within 0.4 s no more frames leave. Nothing in groundpost repeats the last frame to keep the link happy, so the autopilot sees RC loss and runs its own RC failsafe, exactly as it would if a handset died. The air-side companion has to play by the same rule: forward frames one to one, never replay the last one.

The mapping table is shared with RC_CHANNELS_OVERRIDE mode, so a preset built for one works for the other. Until the first stick moves, the autopilot sees centred sticks with throttle and every switch low. The modes are exclusive by construction: in CRSF out nothing is sent over MAVLink, which stays free for telemetry.

Shipping in the next release · macOS / Windows / Linux