Platform
SITL powertrain testing.
Every completed ThrustLab simulation can be exported as an FMI 3.0 co-simulation FMU and connected directly to flight-controller SITL. Instead of a generic motor and battery approximation, the controller flies against the thrust, torque, electrical load, battery sag, thermal state, and operating limits of the simulated powertrain.
The SITL bridge maps firmware outputs to individual rotors, integrates a six-degree-of-freedom rigid body, and returns battery voltage, current, and airspeed as firmware sensor inputs. A small vehicle YAML defines the mass properties, rotor positions, and spin directions.
Quick start with ArduPilot.
The Python SDK includes the FMI runtime and SITL bridge. No separate bridge package is required.
pip install thrustlab
Export the completed simulation from Share → Export FMU, or download it through client.fmu in the Python SDK. Start the bridge with the FMU and vehicle definition:
thrustlab-sitl --fmu my_aircraft.fmu --vehicle vehicle.yaml --rpm-log flight_rotors.csv
Then start ArduPilot SITL with its JSON physics backend pointed at the bridge:
sim_vehicle.py -v ArduCopter -f quad --model JSON:127.0.0.1 --map --console
ArduPilot sends servo commands over the JSON backend. The bridge advances the FMU and rigid-body state once per new control frame, then returns motion and sensor data.
Betaflight.
The same FMU and vehicle YAML can drive Betaflight SITL. Select the Betaflight wire protocol with one option:
thrustlab-sitl --target betaflight --fmu my_aircraft.fmu --vehicle vehicle.yaml
The propulsion and six-degree-of-freedom physics remain unchanged; only the firmware protocol differs.
Ready-to-run examples.
The SDK repository bundles ready-to-fly FMUs, vehicle definitions, and complete missions under examples/fmu/:
- ardupilot_sitl — quadcopter mission with telemetry reconciliation and replay rendering
- ardupilot_sitl_y6 — coaxial Y6 with per-rotor wake coupling
- ardupilot_sitl_tilttri — tilt-tricopter VTOL transition
- betaflight_sitl — Betaflight hover demo
- endurance — hover-endurance study straight from the FMU
- simulink — MATLAB/Simulink co-simulation
- gazebo — Gazebo propulsion plugin
The ArduPilot example records firmware telemetry alongside per-rotor data for plotting and reconciliation. Per-rotor RPM is written by the bridge because the ArduPilot JSON protocol has no RPM sensor lane.
See it fly.
Replay renderings from the bundled missions — per-rotor thrust, battery sag, and state of charge drawn from the FMU during the flight.
Quadcopter mission (ardupilot_sitl)
Coaxial Y6 mission (ardupilot_sitl_y6)
Tilt-tricopter transition (ardupilot_sitl_tilttri)
Other FMI hosts.
The exported FMU also drives the ThrustLab Gazebo plugin and imports into MATLAB/Simulink, verified with R2025a. It runs in any FMI 3.0 co-simulation host; compatibility is validated with fmpy and the FMI reference implementation.
What the FMU contains.
The FMU is the exported powertrain model, not a flight controller or complete scene simulator. It carries per-rotor thrust, torque, and current; battery voltage, current, and state of charge; thermal state; and per-rotor validity-envelope flags. The SITL bridge supplies the vehicle geometry and rigid-body integration, while the firmware supplies control and sensor processing.
Envelope flags identify whether each rotor evaluation remains inside the exported model's supported operating region. Treat an out-of-envelope result as a diagnostic condition, not as validated powertrain behavior. This makes closed-loop testing useful for both mission execution and model-limit detection.