How Does a Companion Computer Link to a Flight Controller?

• Input camera
• Companion computer
• Flight controller

What you will learn

• Trace the interface, protocol and data direction between the two computers.
• Distinguish command messages from state feedback.
• Explain how an architecture can detect stale data or a lost connection.

Before you start

No flight experience is needed. The flight controller runs software that stabilizes and manages the vehicle; a companion computer adds application computing.

Which computer handles which work?

In the PX4 architecture, the flight controller runs the flight stack and real-time software; the companion computer commonly runs a general-purpose operating system for applications such as computer vision. It does not replace the controller. Separating roles lets an application propose a target while the flight stack continues to check and control the vehicle.

The data path has three layers: a wire or network joining the devices; a protocol that packages messages; and the meaning assigned to each message. PX4 describes serial or Ethernet connections and choices such as MAVLink or uXRCE-DDS. A physical interface can work while the application still fails because the endpoints use incompatible protocols, versions or message types.

How do commands travel and feedback return?

In a MAVLink design, software on the companion computer creates a command or setpoint and sends a message over the configured connection. The controller checks the request against its protocol and operating state, then emits a reply or telemetry. A “setpoint” is a desired value, such as a position target; it is not proof that the vehicle reached that target.

In a ROS 2 design with uXRCE-DDS, a client runs on PX4 and an agent runs on the companion computer; they exchange data in both directions over serial or UDP. The agent bridges topics into the ROS 2 network. This exposes status and control through ROS interfaces, but still requires correct topic configuration and compatible versions.

Companion software should track three separate outcomes: whether the connection is alive, whether a message was accepted, and whether actual state is progressing as expected. A heartbeat or status message can indicate that the other endpoint is still sending; an ACK reports a protocol reply to a command; state telemetry reports what the flight stack says. These signals are not interchangeable.

How can software detect a lost connection?

The application should monitor the most recent receive time, client/agent state or heartbeat, and replies for pending requests. If data exceeds the timeout configured by the system, the application marks the link unhealthy, stops treating new setpoints as delivered, records the event and waits for the fallback behavior designed for the flight stack. Do not assume a particular failsafe action without knowing the vehicle configuration.

Consider an illustrative simulator scenario: an application sends “hold the observation target” and receives position and mode state. When a cable interruption is simulated, heartbeats stop and the last received state becomes stale. The application records connection_lost and does not report “target reached,” while the controller follows its separately configured link-loss behavior. The result to inspect is whether the log distinguishes the last state received from the time data stopped.

What conditions and limits apply to the interface?

PX4 handles only message types or topics supported by the interface and configuration. Matching topic names do not guarantee matching data types, coordinate frames, units or timestamps. A ROS 2 network can expose topics unintentionally if deployment is not isolated; the uXRCE-DDS guide warns that the DDS network must be kept protected. Network topology and security therefore need attention alongside the physical connection.

Choosing MAVLink or uXRCE-DDS depends on application software, ROS 2 needs, data flows and support in the exact PX4 version. Choosing serial or Ethernet depends on available ports, configuration and required bandwidth. There is no single companion board or power budget for every task.

Common misunderstandings

Sending a setpoint does not mean the controller acted on it. Read the appropriate reply and state feedback.

A cable does not make the system safe by itself. Protocol, port configuration, bidirectional data and network protection all affect the result.

Frequently asked questions

What connects a companion computer to the flight controller?

PX4 describes serial and Ethernet connections, using protocols such as MAVLink or uXRCE-DDS.

How can I tell that a command arrived?

Check the protocol reply and flight-stack state; receiving a packet does not mean a request completed.

Which computer acts after the connection is lost?

The flight stack runs on the flight controller; behavior after link loss depends on the vehicle's configured failsafe.

Summary

• A companion computer and flight controller exchange data bidirectionally through a configured interface and protocol.
• Commands, ACKs/heartbeats and state telemetry answer different questions.
• A timeout should report link loss and hand over to the configured fallback behavior.