The short answer
Keep everything the aircraft needs to stay flyable on the Pixhawk (attitude and position control, failsafes, the RC link and motor outputs) and give the companion computer the vision, mapping, planning and payload work. Link them with MAVLink over a serial telemetry port for most projects, or over Ethernet when the data rate needs it, and power the companion from its own regulator.
- Running the companion computer off the autopilot's supply is the most common integration mistake.
- Don't hang the companion's weight on the autopilot's vibration isolation.
- A Pixhawk 6X can sit on a Jetson or Raspberry Pi CM4 baseboard that carries both computers.
Building an AI research drone: integrating a companion computer with Pixhawk
Getting a Jetson or a Raspberry Pi to talk to the autopilot is the easy part. The hard part is deciding what each computer is responsible for, and making sure the one running experimental code can't bring the other down with it.
Draw the responsibility split before you buy anything
The autopilot keeps everything the aircraft needs to stay flyable: attitude and position control, arming, geofence, failsafes, the RC link and the motor outputs. The companion computer gets work that is useful but not flight-critical: camera and sensor processing, detection, mapping, path planning, payload control and data recording.
For every function you move across, ask one question: if the companion computer stops responding mid-flight, what happens? If the answer is that the aircraft falls out of the sky, the split is wrong. A research aircraft should be able to lose its companion computer completely and carry on under the autopilot's own failsafe: hold position, return or land, whichever you set.
This matters more on a research aircraft than a production one, because the code on the companion computer is the code under development. It will crash, hang, and eat all the memory at the worst moment. Design as if that is normal, because it is.
The link: serial for most projects, Ethernet where the data justifies it
The common path is MAVLink over a serial connection between one of the autopilot's telemetry ports and a UART on the companion computer. It is well supported by both PX4 and ArduPilot, and by the standard MAVLink libraries on the companion side. Three details decide whether it works: the port you use and its configured baud rate, the logic level, and flow control.
Logic level is the one that damages hardware. Pixhawk telemetry ports use 3.3 V logic. Connecting them to anything at 5 V without a level shifter puts the autopilot at risk, and a level shifter costs far less than a controller. Cross the transmit and receive lines, share a ground, and set the same baud rate at both ends.
Set the baud rate and telemetry stream rates yourself. The defaults suit a radio link and are cautious for a wire. If your application needs fast state updates, such as a controller running at tens of hertz or precise timestamps, serial starts to struggle, and an Ethernet-capable baseboard with a DDS-based interface is worth the extra complexity. Choose it when the data rate needs it.
Power: never run the companion computer off the autopilot's supply
This is the most common integration mistake, and it is easy to avoid. The flight controller's regulated supply is sized for the controller and its peripherals. A companion computer under load draws far more, and in spikes, because the current jumps whenever the processor and its accelerator wake from idle.
Give the companion computer its own regulator from the battery, sized for its peak draw rather than its average, and join the grounds so the serial link has a common reference. Then watch what happens at power-up. On a shared supply, the companion computer's inrush at boot is a classic reason for a flight controller that resets every time you power up on the bench and never otherwise.
Add two things to the electrical drawing. First, which loads pass through the power module's current sensor: if the companion computer is fed separately, the autopilot's consumption figure no longer covers the whole aircraft and your endurance estimate will be wrong. Second, the power-up order, if either device needs one, written on the checklist so nobody has to remember it.
Mounting, vibration and cooling
Mount the companion computer so its weight doesn't hang on the autopilot's vibration isolation. The autopilot is isolated to protect its IMUs. Adding a heavy board to that isolated mass changes how it resonates, and you see it as a position estimate that gets worse as the payload grows.
Cooling problems usually show up in flight. A single-board computer running vision work gives off real heat, and an electronics bay is often a sealed box of still air. A bench test in an open lab at 22 °C tells you nothing about a closed bay in the sun at 38 °C. Thermal throttling gives no warning: the aircraft flies normally and the frame rate quietly halves.
Plan how the heat gets out: a heatsink, a duct, or a metal mounting plate that conducts into the frame. Then test it under load, in the closed bay, at the temperature you will fly in. Log the processor's temperature and clock alongside your frame rate, so throttling shows up in the data instead of being guessed at from a bad result.
A baseboard that carries both, or two boards and a harness
Because the Pixhawk 6X-class controllers are compute modules on a separate baseboard, one of the baseboard options can carry the companion computer as well. We sell a Jetson baseboard and an RPi CM4 baseboard, both for the 5X, 6X, 6X-RT and 6X Pro modules.
The combined board does away with the hand-built harness between two separately mounted boards, which is where intermittent faults hide, and it fixes the two computers in place so they can't be put back together wrongly. The downside is that the pairing is fixed: changing the companion computer means changing the baseboard.
The separate route, a Standard Baseboard or Mini Baseboard plus a carrier mounted on its own, keeps both choices open and lets you put each board where the airframe has room. That usually suits a project whose payload is still changing; the combined board suits one where it has settled. Either way, the module and the baseboard are two lines on the order.
If you haven't chosen the aircraft yet, the development kits are a sensible starting airframe. Read the kit name carefully, because it names the autopilot and radio included, and no kit comes with a companion computer set up.
The bench-test checklist, before it leaves the ground
Do all of this with the propellers off and the motors made safe. Each line is a fault that has turned up on a bench, and would otherwise have turned up in the air.
1. Link up. The companion computer receives the autopilot's heartbeat, and the autopilot sees the companion as a connected system. 2. Read and write. Read a parameter and receive the stream rates you configured, at the rate you configured them. 3. Command path. Send whichever offboard or guided command your application uses and confirm the autopilot accepts it and reports the mode it entered.
4. Failure of the companion. Power the companion computer off mid-session and confirm the autopilot behaves as configured, does not reset, and that its logs record the loss. Then kill your application process rather than the power, and confirm the same. 5. Failure at power-up. Power-cycle the whole aircraft ten times and confirm the flight controller never resets on the companion's boot inrush.
6. Thermal soak. Run the real workload in the closed bay for longer than your intended flight, logging processor temperature and clock, and confirm no throttling. 7. Vibration. With everything mounted as flown, check the autopilot's vibration levels against the flight stack's own guidance before and after adding the companion computer.
8. Record the configuration. Firmware versions on both sides, changed autopilot parameters, baud rate and port, the companion's operating-system image and your application's commit. If you can't say what was running, you can't reproduce the result, and it isn't one.
What to send with an enquiry
The autopilot model and baseboard, or that you need both selected; the companion computer you intend to use, or the workload if you have not chosen one; the interface you want between them; the battery voltage and the companion's peak current draw; the space available in the electronics bay with a rough sketch; and your operating ambient temperature.
Include the temperature even though it seems unrelated to a parts list. It decides whether you need a heatsink or a duct, and designing that in is much cheaper than finding out later.
Ways to put a companion computer next to a Pixhawk
All five baseboards below take the same module family, so any of them will work. The difference is how much of the integration is done for you and how much freedom you keep.
| Route | Holybro SKU | Companion computer | What you still specify |
|---|---|---|---|
| Jetson baseboard, with case | 11072A | NVIDIA Jetson, on the same board | Jetson module, storage, cooling |
| Jetson baseboard, no case | 11072 | NVIDIA Jetson, on the same board | Enclosure, Jetson module, storage, cooling |
| RPi CM4 baseboard | 18080 | Raspberry Pi CM4, on the same board | CM4 variant (RAM and eMMC), storage, cooling |
| Standard Baseboard V2B | 18125 | Separate, your choice | Companion board, carrier, mounting, harness, power |
| Mini Baseboard | 18074 | Separate, your choice | As above, in less space |
Connector counts, board sizes and the supported Jetson and CM4 variants change between revisions, so take them from Holybro's documentation for the exact SKU. The autopilot module is a separate line on every row.
Parts in this guide.
Check the exact variant and revision before you order.
Pixhawk Jetson Baseboard (with case)
Autopilot and Jetson on one board, enclosed. SKU 11072A.
RPi CM4 Baseboard
Autopilot and Raspberry Pi CM4 on one board. SKU 18080.
Pixhawk 6X
The compute module these baseboards take. SKU 11073.
Pixhawk Standard Baseboard V2B
Keeps the companion computer separate. SKU 18125.
Holybro X650 ARF Kit
650 mm airframe and propulsion. You choose the avionics separately.
Development drone kits
Airframes and kits to build a research aircraft on.
Sources.
- Baseboard part numbers and the Pixhawk module family each one serves, and the development-kit range, from the manufacturer's published specifications.
- Pixhawk telemetry ports are 3.3 V logic; confirm the level, pinout and flow-control support for your exact autopilot and baseboard in the manufacturer's documentation before wiring.
- PX4 companion-computer connection (accessed 2026-09-07)
- PX4 1.16 Pixhawk Jetson baseboard setup (accessed 2026-09-07)
- Pixhawk Jetson baseboard overview and specification (accessed 2026-09-07)
- Pixhawk RPi CM4 baseboard overview (accessed 2026-09-07)
- Pixhawk RPi CM4 baseboard connections and ports (accessed 2026-09-07)
- Pixhawk Jetson baseboard dimension and weight (accessed 2026-09-07)
Published 7 September 2026. Last revised 25 September 2026. Corrections to sales@vebixautomation.com.
Planning a companion-computer build?
Send us your controller model and the interfaces you need, the companion computer or its workload, the peak current draw and the space you have. We will reply with a shortlist of parts that work together, covering the baseboard, power and cabling. Ask for a quote, or ask about integration help in Pune.
More on drones and autopilots
- Pixhawk 6C, 6C Mini, 6X or 6X Pro: which flight controller should you choose?Compare Holybro Pixhawk 6C, 6C Mini, 6X and 6X Pro: integrated versus separate baseboard, case and variant options, and an exact-SKU checklist to order from.
- Analog, digital or DroneCAN: choosing a Pixhawk power moduleMatch a Pixhawk power module to its controller: analog sensing, I2C digital sensing and DroneCAN, plus voltage, current and wiring checks before ordering.
- Drone GPS, RTK and dual-antenna heading: which do you need?Choose drone GNSS by positioning and heading needs. Compare standard GPS, RTK corrections and dual-antenna yaw, with a Holybro sourcing checklist.
- How to choose a UAV telemetry radio: data rate, range and ground-station compatibilityChoose a UAV telemetry radio: data rate against range, a worked 915 MHz link budget, antennas and ground-station fit.
- Choosing a drone ESC: PWM, DShot, telemetry and programming compatibilityChoose a drone ESC by control protocol, telemetry path and firmware family: PWM versus DShot, BLHeli-32 versus AM32, configuration tools and troubleshooting.
- Holybro S500, X500 V2 or X650: choosing a drone development kit for researchCompare Holybro S500 V2, X500 V2 and X650 drone kits: wheelbase, included propulsion and avionics, frame versus ARF versus development format.