How Does Offboard Software Send Flight Commands?

• External control computer
• Flight controller receiving requests
• Controlled drone

What you will learn

• Trace states from application setup to offboard mode.
• Distinguish a sent target from state reported by the controller.
• Define success conditions and handle a timeout in simulation.

Before you start

No flight experience is needed. Offboard means the source of control targets is outside the flight stack, such as an application on a companion computer.

What must the application prepare?

PX4 accepts offboard mode only after it has received a proof-of-life stream and continues to receive it while active. The interface can be MAVLink setpoints or ROS 2 OffboardControlMode; the setpoint type and coordinate frame must be supported by PX4. A desired position is not enough if the vehicle lacks the position source required for that target type.

In current PX4 documentation, the proof-of-life stream must reach at least 2 Hz and be sent before changing mode. In the ROS 2 interface, OffboardControlMode provides proof of life while TrajectorySetpoint carries the target, so their publishing cycles can differ as described by the guide. Do not generalize this requirement to another firmware or interface without checking its version.

Which states should the application track?

An illustrative application can manage software states like these:

1. Disconnected: no fresh PX4 state has arrived; do not request offboard.
2. Priming: start the proof-of-life stream and a valid target; record each message time.
3. Requesting mode: send a mode request after preparation is ready; wait for PX4 mode state.
4. Active: mark offboard active only when telemetry reports that mode; keep streaming and monitor vehicle state.
5. Lost: when proof of life or telemetry becomes stale, stop reporting the command as tracked, record the timeout and wait for the configured failsafe behavior.

A mode request being accepted is a response; mode telemetry confirms the current state. The application should check both before displaying “offboard active.”

What should a simulation verify?

An illustrative model can use PX4 SITL in a simulator, a separate control process and an event logger. The process inputs include requested mode, setpoint type, send times and the configured timeout; observations include mode telemetry, request replies and last receive time. No control operation outside simulation is needed.

Scenario success means the log shows the stream being sent, a mode-change reply, telemetry entering offboard, continuing state updates and a correctly recorded end. Failure scenario deliberately stops the sender; the log should detect silence, move the software state to Lost and record the failsafe action reported by PX4. The exact action depends on configuration and is not a fixed result.

Why is a setpoint not the outcome?

A setpoint describes what the application wants. The controller also needs a supported mode, appropriate position data and refreshed messages. If the mode does not change, the command should not be reported as active. If the mode changes but position telemetry does not behave as expected, investigate state and coordinate frame before drawing a conclusion.

When the stream is lost, PX4 uses the offboard timeout and configured link-loss action. The companion application must recognize the transition, while vehicle behavior must be read from the correct version's configuration and tested in simulation.

Common misunderstandings

Sending one target once does not necessarily maintain offboard. PX4 needs a continuous proof-of-life stream; target updates depend on the interface.

A lost stream does not mean every drone lands. The action after timeout depends on configuration and vehicle state.

Frequently asked questions

When should software request offboard mode?

After the proof-of-life stream and a supported target are running; verify the request requirements for the exact version.

How can I tell offboard has started?

Read mode telemetry and the request response, not just the command that was sent.

What happens when setpoints stop?

PX4 exits offboard after loss beyond its configured timeout and performs the selected offboard-loss action.

Summary

• Start the proof-of-life stream, request the mode and confirm state through telemetry.
• Track send times, replies and actual vehicle state.
• Define clear log criteria for both success and lost connection in simulation.