Remote control via MSP proxy and websockets

Beyond the configurator

BetaFlight’s Master System Protocol (MSP) is designed for use with the BetaFlight Configurator application — a Chromium-based desktop tool that communicates with the flight controller over USB serial. But for our use case, we needed a way to send RC commands to the TFC1 from a Raspberry Pi companion computer, without being tethered by USB.

The solution: an MSP proxy that bridges WebSocket connections to the TFC1’s serial port.

The protocol stack

The architecture looks like this:

[Remote Client] <-> [WebSocket] <-> [MSP Proxy on RPi] <-> [UART/USB] <-> [TFC1]

The MSP proxy listens on a WebSocket endpoint and translates incoming MSP messages to serial protocol frames sent to the flight controller. Replies flow in the opposite direction. This allows any client that speaks WebSocket (including web browsers, Node.js scripts, or Python applications) to send MSP commands to the TFC1.

RC commands via MSP v1

The key capability is SET_RAW_RC, an MSP v1 command that sends stick positions directly to the flight controller. This is the same protocol used by the BetaFlight Configurator’s manual RC tab — four channel values (aileron, elevator, throttle, rudder) sent at the update rate expected by BetaFlight.

Combined with the MSP2_SENSOR_OPTICALFLOW_MT protocol (MSP v2) for sending optical flow data from the PiCamera back to the flight controller, the full loop is established:

Optical flow (PiCamera -> PX4-Flow algorithm -> MSP v2 -> TFC1)
RC commands    (WebSocket -> MSP v1 -> TFC1)

The demo

A video demonstration showed the complete system in action: optical flow data from a Raspberry Pi camera was processed and sent to the TFC1 via the MSP proxy, while RC stick commands were sent through the same WebSocket connection. The flight controller responded to both inputs simultaneously, demonstrating the viability of this architecture for autonomous hovering and position hold.

Open source considerations

The MSP proxy implementation is a lightweight Node.js service that could benefit from open-sourcing. It fills a gap between the BetaFlight ecosystem (designed for USB-serial connectivity) and networked companion computer architectures, enabling use cases like:

• Custom web-based ground stations
• Autonomous flight scripts running on a companion computer
• Integration with ROS2 for advanced mission planning
• Remote operation over network or internet (with appropriate latency considerations)

The PX4 port design discussed during development suggests similar proxy approaches could work with PX4’s MAVLink protocol, providing a parallel path for teams using the PX4/ArduPilot stack instead of BetaFlight.