18 / ARDUPILOT · SOFTWARE-IN-THE-LOOP · MAVLINK
A command is a request.
Flight is the evidence.
A companion script asks an autopilot to take off, move to a nearby waypoint and land. The autopilot runs its control and estimation code against a simulated quadrotor. Inspect the gap between command acknowledgement and observed completion.
Predict: does an accepted takeoff command mean the vehicle has reached its target height? What happens when exactly that request arrives while the motors are disarmed?
ArduPilot SITL + MAVLink Guided control.
Know the layers ↗- Execution stack / named method
- Software-In-The-Loop (SITL)
ArduCopter flight software runs on a computer with its built-in vehicle and sensor simulation. Its estimator and flight controller produce the response. This browser replays the resulting telemetry.
- Protocol / available information
- MAVLink 2
The companion sends commands and a position setpoint. It receives COMMAND_ACK, HEARTBEAT, LOCAL_POSITION_NED, ATTITUDE and EXTENDED_SYS_STATE messages. Receipt is recorded on one host clock.
- Decision architecture / control
- Companion → Guided autopilot
One companion requests the flight stages. ArduCopter closes the control loops; the companion checks telemetry against explicit completion criteria. There is one vehicle and no swarm algorithm.
- Frame / physical fidelity
- North–East–Down (NED)
Position uses north, east and down; scene height is the negative down displacement from the recorded origin. Attitude is recorded roll, pitch and yaw. Flight dynamics run inside SITL, without Gazebo, a physical drone or browser flight physics.
Information boundary: the drone and trajectory show autopilot estimates received in telemetry, not an independent ground-truth pose. Each stream holds its latest received sample. Position and attitude may have different receipt times; their age is visible.
REQUEST → ACKNOWLEDGEMENT → OBSERVATION
Watch the response. Check the evidence.
RECORDED ARDUPILOT SITL EXECUTIONValidating recorded events…
Actual autopilot commands and telemetry from independent SITL runs. The browser cannot command a vehicle.
Mode: no heartbeatLanding state: no telemetry
● Received pose estimate◇ Last sent position target┄ Estimated path so far
Drag to orbit · scroll to zoom. Position and attitude come from recorded telemetry; scenery is illustrative.
One cursor follows the recorded events.
COMMANDS / RECORDED RESPONSES
Accepted does not mean completed.
| Request | Sent / s | ACK / result | Evidence |
|---|
Request envelope at the cursor
Select a request row to inspect its exact payload and the responses received by the cursor.
Latest recorded event
ESTIMATED HEIGHT / RECORDED GLOBAL_POSITION_INT
Measure the response over time.
Solid line: received height above home up to the cursor. Dashed line: requested takeoff height after that request is sent. Neither is an independent measurement of real-world accuracy.
A telemetry message can be recent while the command is still executing. Conversely, an old sample stays on screen until a newer message arrives. No interpolation invents a sample between receipts.
OBSERVER CRITERIA / DISTINCT FROM AUTOPILOT ACKS
What counts as completion here?
These bounded telemetry checks belong to the companion experiment. They do not prove obstacle clearance, estimator accuracy, universal flight safety or completion of another mission.
Command and state are different layers.
- Request sentThe companion emitted a MAVLink message.
- Acknowledgement receivedThe autopilot reported a command result. Position setpoints use a separate message path without COMMAND_ACK.
- Telemetry condition observedThe companion measured height, target error or landing state. An accepted request alone does not satisfy the condition.
Recording provenance, autopilot version and runtime
Imported metadata is untrusted provenance. Structural checks establish internal consistency, not authenticity of the autopilot or its environment.
TWO FRESH RUNS / MEASURED OUTCOMES
The same request needs the right state.
These results describe complete recordings, including events beyond the current cursor. The negative case keeps the vehicle disarmed and observes the takeoff response.
| Recorded case | Takeoff ACK | Maximum estimated height | Observed completion | Recording duration |
|---|
PREDICT · INSPECT · EXPLAIN
Follow the evidence through the flight.
Stop at the acknowledgement.
Inspect takeoff’s accepted response. Has the vehicle reached 4 m yet? Compare its current height with the later completion event.
Move north and east.
The waypoint uses NED coordinates. Watch the recorded roll and pitch during translation, then switch 2D / 3D without moving the cursor.
Request takeoff while disarmed.
Inspect the actual command result and estimated height. A process that runs and a command that was sent are not evidence of flight.
METHOD PROFILE / AUTOPILOT INTEGRATION
Where the control loop
actually runs.
Software-In-The-Loop (SITL) runs real autopilot software against a software vehicle model. Here, ArduCopter’s built-in quadrotor simulation supplies simulated dynamics and sensors. Its onboard estimator and controller remain responsible for the response.
MAVLink is the message protocol. Guided mode is the autopilot operating mode that accepts external guidance. Neither is a task allocator, trajectory optimizer or swarm architecture.
The web scene is a replay, with an illustrative yard and quadrotor mesh. Scenery supplies no obstacle sensing, collision constraints or ground truth to the flight controller.
Companion / pymavlink
↓ command or position setpoint
ArduCopter SITL / estimator + controller
↔ built-in vehicle and sensor simulation
↑ ACK + sampled telemetry
NED position = [north, east, down]
scene height = origin down − received down
above-home height = relative_alt / 1000
↓ command or position setpoint
ArduCopter SITL / estimator + controller
↔ built-in vehicle and sensor simulation
↑ ACK + sampled telemetry
NED position = [north, east, down]
scene height = origin down − received down
above-home height = relative_alt / 1000
- COMMAND_LONG + COMMAND_ACK
- The command protocol reports a result for commands such as takeoff. ACCEPTED acknowledges the request; completion still needs an appropriate state observation. The timeline preserves their separate times.
- SET_POSITION_TARGET_LOCAL_NED
- The companion requests a position in the fixed local NED frame. This is a setpoint message, not COMMAND_LONG: the expected evidence is the vehicle’s telemetry response, not a command acknowledgement.
- LOCAL_POSITION_NED + ATTITUDE
- These messages expose autopilot estimates. North and east locate the drone horizontally; negative down is height. Roll, pitch and yaw orient its body in 3D using their recorded radians.
- HEARTBEAT + EXTENDED_SYS_STATE
- Heartbeat reports the mode and arming flag. Extended state supplies the autopilot’s landed-state report. Each field is held from its own most recent receipt and can differ in age.
A meaningful step in fidelity.
Unlike an animated reference path, this response is produced by running autopilot control and estimation against simulated flight dynamics. It remains a software test; simulation success is not a physical flight qualification.
Completion is an explicit contract.
The companion checks declared position, height and landing conditions with bounded timeouts. A timeout or rejected request remains visible instead of being converted into successful flight by the renderer.
Record the experiment again
With Docker available, run npm run record:sitl, then import local/ardupilot-sitl.json. See docs/lessons/18-sitl-mavlink.md for the pinned autopilot, recorder and criteria.
Primary references: ArduPilot SITL simulator and Copter commands in Guided mode; MAVLink command protocol and common message definitions.