19 / GAZEBO · EXTERNAL PHYSICS · CLOSED-LOOP FLIGHT
The world pushes.
The controller responds.
Gazebo advances a simulated quadrotor through an external physics world. ArduPilot estimates its motion and commands the motors. Replay a hover, introduce a recorded lateral disturbance, and inspect world motion alongside the autopilot’s estimate.
Predict: if the hover target stays fixed while an external force pushes the vehicle, does it return immediately? Will the estimated position and the physics-world pose be identical?
Gazebo physics + ArduPilot closed-loop control.
Know the layers ↗- Physics simulator / model
- Gazebo · external vehicle dynamics
A simulated quadrotor has mass, inertia, motors and sensor interfaces. Gazebo advances the world. The browser renders the recorded result.
- Estimator / controller
- ArduCopter · Guided flight
The autopilot estimates the vehicle state and closes its control loops. A companion requests the flight stages; an external force challenges the same controller.
- Software interfaces
- MAVLink + ArduPilot JSON bridge
MAVLink carries companion requests and autopilot telemetry. The Gazebo integration exchanges simulation inputs and outputs with SITL. These interfaces have different roles.
- Observation / timing
- World truth and received estimates
Gazebo IMU-link pose is evaluator data. Telemetry is the autopilot’s reported estimate. Simulation timestamps and host receipt times remain separate, with their alignment stated explicitly.
One recorded experiment: 2D, 3D and the inspectors use one replay cursor. Rendering does not recompute physics or alter the controller. An estimator–truth difference is meaningful only with the stated coordinate transform and sample timing.
FIXED TARGET → EXTERNAL FORCE → MEASURED RESPONSE
Watch the hover recover.
The flight runs in the recorded external simulator. This page controls playback and inspection.
Drag to orbit · scroll to zoom. The two poses retain their actual recorded scale.
One cursor follows the recorded events.
EXTERNAL DISTURBANCE / WORLD COORDINATES
A force request is an event to inspect.
Inspect the event and the subsequent physics response.
Latest force event / exact record
The force is an explicit simulator intervention. It does not model weather, a wireless failure or a controller command.
HOVER RESPONSE / GAZEBO WORLD POSE
Displacement is not recovery.
The chart shows recorded horizontal distance from the fixed hover target. Recovery additionally requires the declared speed and dwell conditions.
CLOCKS / COORDINATES / AVAILABLE INFORMATION
Compare the same state carefully.
World pose and autopilot telemetry have separate clocks and coordinate conventions. Their recorded alignment is shown here.
Latest pose and telemetry / exact records
COMPANION / MAVLINK / EXECUTION
Follow the flight stages.
| Stage | Request / s | Response | Observation |
|---|
Request envelope at the cursor
Recording provenance, simulation versions and measured criteria
Completion and recovery criteria
Imported metadata is untrusted provenance. Validation checks internal consistency; it does not authenticate the simulator or recorder.
TWO RECORDED CASES / MEASURED RESPONSE
Compare the disturbance with its baseline.
This table describes complete recordings, including observations beyond the cursor. A recovered hover is a bounded result under these physics, timing and controller settings.
| Recorded case | Applied disturbance | Peak target error | Observed recovery | Flight outcome |
|---|
PREDICT · INSPECT · EXPLAIN
Read the response through three layers.
Hold the target. Push the vehicle.
Stop at the force event. Inspect its direction and watch the world pose change while the hover target remains fixed.
Compare pose and estimate.
Toggle the estimate overlay, inspect the sample ages and read the coordinate transform. Two nearby meshes alone do not establish estimator accuracy.
Return is a condition over time.
Find the recovery observation. Check position, speed and dwell evidence, then compare the nominal hover over its observation window.
METHOD PROFILE / EXTERNAL SIMULATION
Different processes.
One physical response.
Gazebo supplies the external physics world and simulated sensor interfaces. ArduPilot SITL runs the autopilot’s estimator and controller. The ArduPilot Gazebo plugin connects the two through the JSON simulation interface.
MAVLink carries the companion’s flight requests and the autopilot’s telemetry. World pose and the force intervention belong to the evaluator; they are not quietly substituted for the companion’s telemetry checks.
The scene is a teaching visualization of recorded poses. Its decorative yard does not add collisions, obstacles, sensor coverage or aerodynamic effects to the actual simulator.
↓
ArduPilot / estimator + controller
↕ JSON simulation bridge
Gazebo / sensors + motors + rigid-body physics
← bounded external force
Evaluator: world pose + received telemetry
Browser: one shared recorded cursor
- Physical truth
- The simulator’s reported IMU-link pose is ground truth within its model, not a measurement from physical hardware.
- Estimated state
- ArduPilot telemetry describes its filtered estimate. Coordinate alignment and sample timing are part of any comparison with world pose.
- Recovery
- A bounded observer condition on error, speed and sustained good samples. It is separate from a force-service response or MAVLink acknowledgement.
Record another local simulation
Use npm run record:gazebo to run the optional isolated simulator recorder, then import its JSON output here. The first setup downloads the pinned runtime dependencies.
The documented runner owns its simulated processes and uses local interfaces. Unexpected execution failures do not become successful flight records.
Method and implementation sources
ArduPilot: Using SITL with Gazebo · ArduPilot Gazebo plugin · Gazebo physics · MAVLink command protocol
Experiment assumptions and method · Recorded results and verification