raspberry-pi-pico-w5500-mavlink-bridge
This project uses a Raspberry Pi Pico and WIZnet W5500 to extend a Flight Controller’s MAVLink communication over Ethernet.
0
Components
Hardware components
WIZnet - W5500
x 1
Raspberry Pi - Raspberry Pi Pico
x 1
Arduino - Arduino IDE
x 1
Project description
MAVLink Ethernet Bridge with WIZnet W5500
Project Overview
In drones and autonomous robots, reliable communication is just as important as motor control. Data such as GPS position, speed, attitude, battery status, and mission information must be continuously exchanged between the vehicle and the Ground Control Station. This project uses a Raspberry Pi Pico and WIZnet W5500 to bridge MAVLink communication from a Flight Controller to Ethernet using UDP.
The key idea is to extend UART-based communication into a standard IP network without making major changes to the existing Flight Controller.
What Are MAVLink and a Flight Controller?
MAVLink stands for Micro Air Vehicle Link and is a lightweight messaging protocol widely used in drones and robotics. In simple terms, it is a common language that allows a vehicle and external systems to exchange information. MAVLink can carry GPS position, altitude, speed, attitude, battery status, sensor data, mission information, waypoints, system status, and control commands. Ground Control Station software such as QGroundControl uses this data to monitor the vehicle and can also send missions or commands back to the Flight Controller.
A Flight Controller is the embedded controller that acts as the brain of a drone or autonomous vehicle. It uses data from devices such as IMUs, GPS receivers, and barometers to determine the vehicle’s state and control motors or servos. Typical functions include attitude stabilization, GPS navigation, position hold, automatic takeoff and landing, waypoint navigation, mission execution, and failsafe handling. Platforms such as ArduPilot and PX4 are used not only in drones but also in rovers, UGVs, boats, and other autonomous vehicles, which means MAVLink is not limited to aerial applications.
MAVLink Protocol and Packet Format
MAVLink is a lightweight messaging protocol widely used in drones, robots, and autonomous vehicles. It allows Flight Controllers, Ground Control Stations, companion computers, and payload devices to exchange telemetry, commands, mission data, and system status information.
A MAVLink packet is composed of a header, message ID, payload, checksum, and optional signature.
| Field | Description |
|---|---|
| Header | Packet length, sequence, system ID, component ID |
| Message ID | Defines the type of MAVLink message |
| Payload | Actual data such as GPS, attitude, battery, or command values |
| Checksum | Detects transmission errors |
| Signature | Optional authentication field in MAVLink 2 |
MAVLink traffic on this link runs in two directions. The vehicle continuously streams telemetry to the Ground Control Station, while the Ground Control Station sends missions and commands back to the Flight Controller.
Vehicle → Ground Control Station (Telemetry)
| Message | Description |
|---|---|
HEARTBEAT | Vehicle type, flight mode, and armed status; sent continuously so the GCS can detect a live connection |
SYS_STATUS | Battery voltage/current and sensor health |
ATTITUDE | Roll, pitch, yaw, and their rates |
GLOBAL_POSITION_INT | Latitude, longitude, altitude, and ground speed |
GPS_RAW_INT | Raw GPS fix type, satellite count, and HDOP |
VFR_HUD | Airspeed, altitude, heading, and throttle summary |
NAV_CONTROLLER_OUTPUT | Distance to target and navigation error |
MISSION_CURRENT | Index of the waypoint currently being executed |
RC_CHANNELS | Remote control input values |
STATUSTEXT | Human-readable status or warning messages |
Ground Control Station → Vehicle (Commands and Missions)
| Message | Description |
|---|---|
MISSION_ITEM_INT / MISSION_COUNT | Upload or download of mission waypoints |
COMMAND_LONG / COMMAND_INT | Container for discrete commands such as arm/disarm, takeoff, land, or mode changes |
MAV_CMD_COMPONENT_ARM_DISARM | Arm or disarm the vehicle |
MAV_CMD_NAV_TAKEOFF / MAV_CMD_NAV_LAND | Takeoff or landing |
MAV_CMD_DO_SET_MODE | Change flight mode (e.g. Stabilize, Auto, RTL) |
PARAM_SET / PARAM_VALUE | Read or write Flight Controller tuning parameters |
SET_POSITION_TARGET_LOCAL_NED | Real-time position or velocity targets, typically from a companion computer |
In this project, the Raspberry Pi Pico does not decode each MAVLink message. It forwards the MAVLink byte stream directly between UART and UDP through the W5500, so both directions of traffic — telemetry going out to QGroundControl and commands coming back to the Flight Controller — travel over the same UDP socket, keeping the gateway simple while supporting the full range of MAVLink messages.
Why Ethernet and W5500?
MAVLink from a Flight Controller is often available through UART, which works well for direct device-to-device communication. Ethernet changes the architecture by allowing the Flight Controller to become part of a standard IP network, making it easier to connect with PCs, servers, monitoring systems, and other gateways.
| UART-Centered Connection | Ethernet-Based Connection |
|---|---|
| Direct device-to-device link | Connected to an IP network |
| Focused on local communication | Can communicate with PCs, servers, and gateways |
| Limited expansion options | Can use existing network infrastructure |
| Best suited for point-to-point links | Easier to expand into monitoring and distributed systems |
In this project, the W5500 acts as the key interface between the embedded controller and the network. It connects to the Raspberry Pi Pico over SPI and provides Ethernet connectivity for MAVLink UDP communication. The system also includes a web-based configuration interface, allowing users to change settings such as Device IP, Target IP, Gateway, UDP Port, and UART Baud Rate without rebuilding the firmware.
This is especially useful in environments where Wi-Fi is not always the best option, such as industrial facilities, laboratories, test benches, ground vehicles, or systems that require a stable wired network connection.
Applications and Scalability
This architecture is not limited to a single drone application. In UAV development, it can provide a wired telemetry link between the Flight Controller and Ground Control Station for development and testing. In autonomous rovers or UGVs, it can be used to send position, battery, and driving status to a control station. In industrial robots or inspection platforms, it can act as a gateway between the robot controller and an existing factory Ethernet network. In research environments, it can connect Flight Controller data to PCs, logging servers, and simulation tools for long-term testing and analysis.
From a broader perspective, the project is not simply about converting MAVLink to Ethernet. The more important idea is turning a UART-based embedded system into a network-connected device. That architecture can be expanded into central monitoring, fleet management, telemetry logging, remote control, edge gateways, simulation and digital twins, cloud integration, and industrial monitoring systems.
| Expansion Direction | Example Application |
|---|---|
| Central Monitoring | Monitor multiple robots from one dashboard |
| Fleet Management | Manage multiple drones, rovers, or UGVs |
| Data Logging | Store telemetry data on a server |
| Remote Control | Control vehicles over an IP network |
| Edge Gateway | Connect embedded controllers to higher-level systems |
| Simulation / Digital Twin | Link real vehicles with simulation platforms |
| Cloud Integration | Forward telemetry data to cloud services |
| Industrial Monitoring | Monitor autonomous robots on a factory network |
The same concept is also applicable beyond MAVLink. Sensors, motor controllers, measurement equipment, and industrial embedded devices that communicate through UART can be connected to Ethernet using a similar gateway architecture.
Comparison with Similar WIZnet Maker Projects
WIZnet Maker includes several projects that use the W5500 to connect embedded controllers to external networks. Three particularly relevant examples are Flight Control Unit, Canique Pico Gateway, and GLITCH-Software. Each one shares a different part of the architecture used in this project.
| Category | This Project | Flight Control Unit | Canique Pico Gateway | GLITCH-Software |
|---|---|---|---|---|
| Main Purpose | MAVLink Ethernet Bridge | Flight Control Telemetry | IoT Sensor Gateway | Telemetry & Telecommand |
| Main MCU | Raspberry Pi Pico / RP2040 | Teensy-class controller | Raspberry Pi Pico / RP2040 | ESP32 + FPGA |
| Ethernet | W5500 | W5500 | W5500 | W5500 |
| Main Data | MAVLink | IMU / FCU status | Sensor data | FPGA telemetry |
| Network Protocol | UDP | UDP | MQTT / TCP / HTTP | TCP |
| Web Configuration | Yes | Not a main feature | Yes | Not a main feature |
| Main Application | Drone / Rover / Robotics | Flight control research | IoT monitoring | Aerospace telemetry |
Flight Control Unit is the closest example in terms of application area. It also uses W5500 and UDP in a flight-control environment, mainly to send FCU status and telemetry data to a PC or ground system. The main difference is that it focuses on observing and analyzing data generated inside the Flight Controller, while this project acts as a network gateway for an already existing MAVLink interface.
Canique Pico Gateway is the closest example in terms of hardware architecture because it also combines a Raspberry Pi Pico with W5500 and includes an embedded web interface. However, its purpose is closer to an IoT sensor gateway, while this project is designed as a robotics and vehicle communication gateway. The comparison shows how the same Pico + W5500 combination can be reused across very different industries.
GLITCH-Software is the closest example in terms of communication architecture. It receives telemetry data over UART and forwards it through W5500 to a Ground Station, while also supporting commands in the opposite direction. The overall gateway concept is very similar, but GLITCH uses its own telemetry data structure and TCP, whereas this project uses MAVLink and UDP, allowing direct integration with the drone and autonomous-vehicle ecosystem.
What Makes This Project Different?
The comparison makes the position of this project clearer. It shares the flight-control application domain with Flight Control Unit, the Raspberry Pi Pico + W5500 hardware platform with Canique Pico Gateway, and the bidirectional UART-to-Ethernet gateway architecture with GLITCH-Software.
This project combines all three aspects:
RP2040 + W5500 Hardware + UART-to-Ethernet Gateway + MAVLink / Autonomous Vehicle Application
A particularly important difference is direct compatibility with QGroundControl. This means the project is not only a network communication demo, but a practical gateway that can operate inside an existing drone and robotics software ecosystem.
