Pixhawk · Companion Computers · Flight Architecture
Pixhawk vs Companion Computer Drone Architecture
By Aeroniti Engineering · Published 2026-07-19 · Updated 2026-07-19
Pixhawk and a companion computer are complementary rather than competing computers. Pixhawk is designed for real-time vehicle control, flight-state estimation, sensor integration, motor output, and configured safety behavior. A companion computer such as Jetson Orin Nano or Raspberry Pi is suited to Linux applications, AI inference, mapping, high-level mission logic, payload workflows, and network services.
Confusing these roles produces fragile systems. The companion computer should not become an unbounded replacement for the autopilot, and the flight controller should not be expected to run computationally heavy perception workloads. A clear command and failure boundary lets both devices perform the work they are designed to do.
Architecture flow
The following simplified flow shows where information is interpreted and where flight-safe execution remains separated. Actual interfaces, rates, redundancy, and authority depend on the aircraft and mission.
What Pixhawk companion computer means in practice
A Pixhawk companion computer architecture separates deterministic flight control from high-level computation. The two systems exchange telemetry and command intent, commonly through MAVLink, while power, timing, authority, and loss-of-link behavior are deliberately engineered.
01 — Pixhawk
reads flight sensors, estimates vehicle state, stabilizes attitude, and drives supported outputs For Pixhawk companion computer, verify this against the aircraft, mission objective, compute budget, sensors, communication link, and flight-safety boundary.
02 — ArduPilot
supplies vehicle firmware, navigation modes, mission execution, geofence, RTL, and failsafe logic For Pixhawk companion computer, verify this against the aircraft, mission objective, compute budget, sensors, communication link, and flight-safety boundary.
03 — Companion computer
runs perception, data processing, decision logic, payload services, and application networking For Pixhawk companion computer, verify this against the aircraft, mission objective, compute budget, sensors, communication link, and flight-safety boundary.
04 — Ground system
plans work, supervises state, receives evidence, and preserves human intervention For Pixhawk companion computer, verify this against the aircraft, mission objective, compute budget, sensors, communication link, and flight-safety boundary.
Architecture and component responsibilities
A useful architecture assigns each component a narrow responsibility and makes every authority transition visible. For Pixhawk companion computer, system quality depends less on one device than on how data, commands, acknowledgements, and failures move between components.
01 — Serial or USB transport
requires correct electrical levels, baud rate, grounding, connector retention, and device identity For Pixhawk companion computer, verify this against message ownership, update rate, latency, stale-data handling, command acknowledgement, and operator authority.
02 — MAVLink identity
systems and components need distinct identifiers and deliberate message routing For Pixhawk companion computer, verify this against message ownership, update rate, latency, stale-data handling, command acknowledgement, and operator authority.
03 — Command acknowledgement
requests must be checked for acceptance, rejection, mode compatibility, and timeout For Pixhawk companion computer, verify this against message ownership, update rate, latency, stale-data handling, command acknowledgement, and operator authority.
04 — Power and restart behavior
a companion reboot must not remove autopilot control or create persistent commands For Pixhawk companion computer, verify this against message ownership, update rate, latency, stale-data handling, command acknowledgement, and operator authority.
End-to-end operating workflow
The workflow should describe the system from mission preparation through execution and recovery. The sequence below is deliberately operational: it connects software behavior with checks that an engineering team and an operator can observe.
01 — Boot and discover
verify heartbeats, vehicle identity, firmware state, time base, and message rates For Pixhawk companion computer, verify this against mission state, pre-flight readiness, environmental conditions, flight mode, telemetry freshness, and the defined recovery path.
02 — Observe first
read telemetry and validate health before allowing the companion computer to request actions For Pixhawk companion computer, verify this against mission state, pre-flight readiness, environmental conditions, flight mode, telemetry freshness, and the defined recovery path.
03 — Request bounded actions
use mission items or supported setpoints appropriate to the active flight mode For Pixhawk companion computer, verify this against mission state, pre-flight readiness, environmental conditions, flight mode, telemetry freshness, and the defined recovery path.
04 — Recover cleanly
expire commands, reject stale decisions, and allow Pixhawk failsafes to operate independently For Pixhawk companion computer, verify this against mission state, pre-flight readiness, environmental conditions, flight mode, telemetry freshness, and the defined recovery path.
Engineering design considerations
A technically credible system is built around constraints rather than ideal demonstrations. These considerations shape hardware selection, software boundaries, test coverage, and the conditions under which the capability should or should not be enabled.
01 — Timing separation
Linux workloads can stall, while flight-control loops require deterministic scheduling For Pixhawk companion computer, verify this against power, mass, thermal limits, vibration, electromagnetic compatibility, timing, maintainability, and safe degradation.
02 — Thermal and power design
companion compute needs measured power supply quality, cooling, and reserve capacity For Pixhawk companion computer, verify this against power, mass, thermal limits, vibration, electromagnetic compatibility, timing, maintainability, and safe degradation.
03 — Authority arbitration
ground control, remote pilot, mission engine, and onboard AI cannot issue ambiguous competing commands For Pixhawk companion computer, verify this against power, mass, thermal limits, vibration, electromagnetic compatibility, timing, maintainability, and safe degradation.
04 — Logging
synchronize flight-controller and companion logs so decisions and vehicle responses can be reconstructed For Pixhawk companion computer, verify this against power, mass, thermal limits, vibration, electromagnetic compatibility, timing, maintainability, and safe degradation.
Limitations and failure modes
No autonomy or sensing capability should be presented as certain in every environment. Identifying limitations early prevents a promising prototype from becoming an unsafe or unreliable field workflow.
01 — Transport interruption
cables, USB enumeration, serial configuration, or network bridges can fail For Pixhawk companion computer, verify this against sensor uncertainty, occlusion, weather, range, vehicle dynamics, communications, human factors, and regulatory operating limits.
02 — Compute overload
inference or recording can starve application threads and delay mission decisions For Pixhawk companion computer, verify this against sensor uncertainty, occlusion, weather, range, vehicle dynamics, communications, human factors, and regulatory operating limits.
03 — Mode mismatch
a valid MAVLink message may be rejected or unsafe in the wrong vehicle mode For Pixhawk companion computer, verify this against sensor uncertainty, occlusion, weather, range, vehicle dynamics, communications, human factors, and regulatory operating limits.
04 — Unsafe coupling
depending on the companion process for basic stabilization or failsafes removes an important protection layer For Pixhawk companion computer, verify this against sensor uncertainty, occlusion, weather, range, vehicle dynamics, communications, human factors, and regulatory operating limits.
Verification before flight
Verification should progress from repeatable software tests to integrated hardware and controlled flight. Passing a nominal demonstration is only one result; the team must also test missing, delayed, contradictory, and out-of-range inputs.
01 — Software-in-the-loop
test messages, state transitions, command rejection, timeouts, and restart recovery For Pixhawk companion computer, verify this against acceptance criteria, traceable logs, repeatability, safe abort behavior, manual override, and evidence that each fallback occurs within its allowed time.
02 — Hardware bench
confirm voltage, ports, message rates, CPU load, thermals, and link-loss behavior For Pixhawk companion computer, verify this against acceptance criteria, traceable logs, repeatability, safe abort behavior, manual override, and evidence that each fallback occurs within its allowed time.
03 — Propeller-off integration
exercise commands, payloads, and overrides with the physical stack restrained For Pixhawk companion computer, verify this against acceptance criteria, traceable logs, repeatability, safe abort behavior, manual override, and evidence that each fallback occurs within its allowed time.
04 — Controlled flight
verify bounded authority and fallback behavior before adding perception-driven actions For Pixhawk companion computer, verify this against acceptance criteria, traceable logs, repeatability, safe abort behavior, manual override, and evidence that each fallback occurs within its allowed time.
Deployment and operator supervision
Field deployment combines the technical system with procedures, permissions, training, maintenance, and review. Human supervision is most effective when the interface explains what the aircraft is doing, why it is doing it, and which intervention remains available.
01 — Configuration record
preserve port settings, IDs, firmware, parameters, services, models, and wiring revisions For Pixhawk companion computer, verify this against site authorization, checklists, crew roles, data handling, maintenance intervals, incident review, and change control.
02 — Health display
expose both autopilot and companion status instead of representing them as one black box For Pixhawk companion computer, verify this against site authorization, checklists, crew roles, data handling, maintenance intervals, incident review, and change control.
03 — Override path
ensure pilot control and configured RTL do not rely on the companion computer For Pixhawk companion computer, verify this against site authorization, checklists, crew roles, data handling, maintenance intervals, incident review, and change control.
04 — Maintenance review
inspect connectors, cooling, storage, logs, time synchronization, and software versions For Pixhawk companion computer, verify this against site authorization, checklists, crew roles, data handling, maintenance intervals, incident review, and change control.
Frequently asked questions
These concise answers summarize common engineering questions. They do not replace the selected hardware documentation, flight testing, operating approval, or a mission-specific safety assessment.
Is Pixhawk a companion computer?
No. Pixhawk is primarily a flight controller; a companion computer runs higher-level applications and AI workloads.
Can a drone fly if the companion computer stops?
It should retain safe flight-controller behavior, with the exact response defined by the active mode and failsafe configuration.
How do Pixhawk and Jetson communicate?
They commonly exchange MAVLink over serial, USB, or a managed network transport.
Which computer should run object detection?
Object detection normally runs on the companion computer because it requires application-level CPU or GPU resources.
Who controls return-to-launch?
ArduPilot on Pixhawk executes RTL; the pilot, ground system, or companion computer may request it through an authorized path.
Continue with Aeroniti engineering resources
Explore the related product and solution architecture, or bring Aeroniti a specific aircraft, sensor, payload, mission, and operating constraint for a focused technical discussion.