PX4 and ArduPilot integration

PX4 or ArduPilot: what changes for integration

Both stacks talk to the outside world over MAVLink, so a companion computer or ground station can usually be written to work with either. Internally they are different. PX4 is built from modules that communicate over an internal publish/subscribe bus called uORB, and recent releases can expose that bus to ROS 2 through a DDS bridge. ArduPilot ships vehicle-specific firmware (Copter, Plane, Rover, Sub), exposes a very large parameter set, and supports on-board Lua scripts on flight controllers with enough memory.

Licensing differs too. PX4 is BSD-licensed; ArduPilot is GPLv3. If you modify the firmware itself and distribute it with a product, the licence affects what you must publish, so it is worth deciding early whether your changes belong inside the firmware or outside it on a companion computer. (TODO: confirm licence implications for your distribution model with your own legal advice.)

Typical integration work

• A companion computer (for example a Raspberry Pi or Jetson) exchanging MAVLink with the flight controller over serial or UDP.
• Commanding the vehicle from software: offboard mode in PX4, guided mode in ArduPilot, using position, velocity or attitude setpoints.
• Feeding external data into the estimator, such as external vision or odometry messages for flight without GNSS.
• Payload control: camera triggering, gimbal control over the MAVLink gimbal protocol, servos and relays.
• Mission upload and download through the MAVLink mission protocol, including geofences and rally points.
• Parameter work: failsafes for RC loss, datalink loss and low battery, geofence limits, and per-airframe parameter files kept under version control.

Where integrations usually go wrong

Timing. PX4 will not stay in offboard mode unless it keeps receiving setpoints; if the stream stops, it falls back to a failsafe. Companion software therefore has to treat the setpoint stream as a heartbeat, not as occasional commands.

Frames and units. PX4 and ArduPilot use NED (north, east, down) frames, while ROS uses ENU (east, north, up). Some MAVLink messages carry latitude and longitude as integers scaled by 10 million, and altitude references differ between messages. A sign error or wrong frame field produces a vehicle that flies confidently in the wrong direction.

Identity. Every node on a MAVLink network needs a unique system and component ID. Two components with the same IDs produce intermittent, confusing behaviour that looks like a radio problem.

Version drift. Message support and parameter names change between firmware releases. An integration tested against one release should pin it, and upgrades should be re-tested rather than assumed.

How I approach it

I start in software-in-the-loop simulation, running the real autopilot firmware against a simulated vehicle, so that integration code is exercised before any hardware is involved. Parameter files and firmware versions go into version control alongside the integration code. Each behaviour the integration depends on gets a scripted check, such as entering offboard mode, recovering from a dropped link, or uploading and flying a mission.

Flight testing is done with your pilots and your aircraft. Afterwards I work from the flight logs (ULog for PX4, DataFlash logs for ArduPilot) to confirm the integration behaved as intended rather than relying on how the flight looked.