thrustlab 0.5.0__tar.gz → 0.6.0__tar.gz

{thrustlab-0.5.0 → thrustlab-0.6.0}/CHANGELOG.md

@@ -8,6 +8,42 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.6.0] - 2026-09-09
+
+### Added
+
+- `client.simulations.cancel_selected(run_ids)` cancels up to 1000 runs of any
+  kind (`sim_`, `sweep_`, `dyn_`) in one call and reports which were canceled,
+  which were asked to stop, and which were skipped and why.
+  `client.simulations.cancel_queued(project_id=...)` cancels every queued run
+  you own, optionally within one project.
+- `client.simulations.run_queued()` and
+  `client.simulations.run_selected(simulation_ids)` dispatch runs parked with
+  `launch_intent="queue"` — all of them, or a named subset. Both accept sweep
+  ids as well as single-point ids.
+- Generated models for the batch cancel response (`CancelBatchResult`,
+  `CancelSkipped`) and request body (`CancelSelectedBody`).
+- Two runnable examples. `examples/sweeps/component_axis_grid.py` crosses a
+  propeller component axis with a throttle range in one submission and reads
+  the propeller name back off each point.
+  `examples/dynamic/watch_and_cancel.py` watches a mission's `progress` and
+  cancels it part-way through.
+
+### Changed
+
+- Cancelling a running sweep is now a durable request: the server records it
+  and the worker stops after the point it is computing, even if the stop takes
+  longer than a minute to reach.
+- Cancelling a RUNNING dynamic mission now reports under `requested` rather
+  than `canceled`. The mission keeps its partial result (`run_meta.partial`,
+  `run_meta.canceled_at_t_s`), the credits are refunded, and the execution slot
+  frees when the worker stops at its next integration window.
+- Run resources carry `started_at`, the instant the solver began, alongside
+  `created_at`, `dispatched_at` and `completed_at`. Queue wait is
+  `started_at - dispatched_at`.
+- Dynamic run resources carry `progress` and `cancel_requested_at`. Sweep
+  resources carry `cancel_requested_at` and `credits_breakdown`.
+
 ## [0.5.0] - 2026-08-31
 
 ### Added

{thrustlab-0.5.0 → thrustlab-0.6.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: thrustlab
-Version: 0.5.0
+Version: 0.6.0
 Summary: Official Python SDK for the ThrustLab API
 Project-URL: Homepage, https://thrustlab.com
 Project-URL: Documentation, https://thrustlab.com/docs
@@ -93,6 +93,33 @@ Runnable end-to-end examples for every simulation type live in
 [`sweeps/run_and_poll.py`](./examples/sweeps/run_and_poll.py), and
 [`dynamic/run_and_poll.py`](./examples/dynamic/run_and_poll.py).
 
+## FMU export and SITL
+
+Export a completed simulation as an FMI 3.0 co-simulation FMU:
+
+```python
+job_id = client.fmu.export(sim_id)["id"]
+client.fmu.wait(job_id)
+client.fmu.download(job_id, "powertrain.fmu")
+```
+
+The FMU exposes per-rotor inputs and outputs, battery and thermal state, and a
+validity envelope; it runs in any FMI 3.0 co-simulation host and is verified
+in Simulink.
+
+`thrustlab-sitl`, installed with the SDK, flies the FMU in ArduPilot SITL or
+Betaflight SITL (`--target betaflight`). See
+[`thrustlab/sitl/README.md`](./thrustlab/sitl/README.md) for the full
+documentation.
+
+```shell
+thrustlab-sitl --fmu powertrain.fmu --vehicle quad_x.yaml --target betaflight
+```
+
+See [`examples/fmu/`](./examples/fmu/) for bundled ready-to-fly FMUs with
+quadcopter, Y6 coax, and tilt-tricopter missions, an endurance study, and
+replay rendering.
+
 ## Why the SDK (and not `urllib` / `wget`)?
 
 The SDK gives you automatic retries with backoff, idempotency keys, cursor
@@ -131,6 +158,7 @@ client.submissions
 client.starred_components
 client.compute_units
 client.webhook_endpoints
+client.fmu
 ```
 
 ## Error handling

{thrustlab-0.5.0 → thrustlab-0.6.0}/README.md

@@ -57,6 +57,33 @@ Runnable end-to-end examples for every simulation type live in
 [`sweeps/run_and_poll.py`](./examples/sweeps/run_and_poll.py), and
 [`dynamic/run_and_poll.py`](./examples/dynamic/run_and_poll.py).
 
+## FMU export and SITL
+
+Export a completed simulation as an FMI 3.0 co-simulation FMU:
+
+```python
+job_id = client.fmu.export(sim_id)["id"]
+client.fmu.wait(job_id)
+client.fmu.download(job_id, "powertrain.fmu")
+```
+
+The FMU exposes per-rotor inputs and outputs, battery and thermal state, and a
+validity envelope; it runs in any FMI 3.0 co-simulation host and is verified
+in Simulink.
+
+`thrustlab-sitl`, installed with the SDK, flies the FMU in ArduPilot SITL or
+Betaflight SITL (`--target betaflight`). See
+[`thrustlab/sitl/README.md`](./thrustlab/sitl/README.md) for the full
+documentation.
+
+```shell
+thrustlab-sitl --fmu powertrain.fmu --vehicle quad_x.yaml --target betaflight
+```
+
+See [`examples/fmu/`](./examples/fmu/) for bundled ready-to-fly FMUs with
+quadcopter, Y6 coax, and tilt-tricopter missions, an endurance study, and
+replay rendering.
+
 ## Why the SDK (and not `urllib` / `wget`)?
 
 The SDK gives you automatic retries with backoff, idempotency keys, cursor
@@ -95,6 +122,7 @@ client.submissions
 client.starred_components
 client.compute_units
 client.webhook_endpoints
+client.fmu
 ```
 
 ## Error handling

{thrustlab-0.5.0 → thrustlab-0.6.0}/examples/components/create_component.py

@@ -18,8 +18,8 @@ Notes on validation:
     one resistance figure (c_rating or pack_resistance_mOhm), and bounding-box
     dims; form_factor is derived from chemistry when omitted.
   * Propeller: per-station radius/chord/twist and rotation are required, and
-    persisting a propeller needs the hobbyist tier or higher — the create below
-    reports the tier gate cleanly on a free account.
+    persisting a propeller needs the Pro plan — the create below reports the
+    tier gate cleanly on a free account.
 """
 
 from thrustlab import Client

thrustlab-0.6.0/examples/dynamic/watch_and_cancel.py

@@ -0,0 +1,132 @@
+"""Dynamic progress + cancel: submit -> watch `progress` -> cancel -> read the partial.
+
+Run it:
+    export THRUSTLAB_API_KEY=key_...        # never hard-code the key
+    python examples/dynamic/watch_and_cancel.py
+
+Submits a mission that flies until the pack is empty, watches `progress` while
+it runs, cancels it part-way through, and reads the partial result.
+
+`progress` is {fraction, sim_time_s, sim_time_total_s, wall_s, updated_at}, and
+is None until the worker picks the run up.
+
+Cancelling a RUNNING dynamic mission does not stop it instantly. The response
+keeps status "running" and sets `cancel_requested_at`; the worker stops at its
+next integration window, at most 20 seconds of mission time. What comes back is
+a real partial result: `run_meta.partial` is true, `run_meta.canceled_at_t_s`
+gives the mission time it stopped at, and the credits are refunded.
+
+This mission runs to depletion, so `fraction` is an estimate rather than an
+exact ratio.
+"""
+
+import time
+
+from thrustlab import Client
+
+client = Client()  # reads $THRUSTLAB_API_KEY from the environment
+
+project = client.projects.create(name="sdk dynamic progress example")
+
+motor = client.components.find(name="BadAss 2826-820Kv")
+prop = client.components.find(name="10.5x4.5")
+battery = client.components.find(
+    name="Liperior 5000mAh 4S 35C 14.8V Lipo Battery With XT90 Plug"
+)
+
+# A hover flown until the pack is empty.
+#
+# The schedule steps to 15% before it ramps, rather than ramping up from rest.
+# One external study observed ramps starting at near-zero duty producing a
+# handful of non-converged rows in their first milliseconds; as a fraction of a
+# short flight's rows that was enough to get a run rejected with
+# `solver_no_convergence`. Stepping to a working throttle first avoided it.
+dyn = client.dynamic_simulations.create(
+    project_id=project["id"],
+    battery_component_id=battery["id"],
+    density_kg_m3=1.225,
+    battery_charge_pct=100,
+    ambient_temp_c=25,
+    rotor_groups=[
+        {
+            "label": "main",
+            "count": 4,
+            "motor_component_id": motor["id"],
+            "propeller_component_id": prop["id"],
+        }
+    ],
+    schedule={
+        "mode": "segments",
+        "segments": [
+            # Step to the ESC's working range first.
+            {
+                "duration_s": 0.2,
+                "airspeed_target": 0.0,
+                "per_group": {"main": {"throttle_target": 15, "throttle_ramp": "step"}},
+            },
+            # Then ramp from there to the hover setting.
+            {
+                "duration_s": 2.0,
+                "airspeed_target": 0.0,
+                "per_group": {"main": {"throttle_target": 65, "throttle_ramp": "linear"}},
+            },
+            # Hold until the pack is empty. `until_depleted` takes no duration.
+            {
+                "until_depleted": True,
+                "airspeed_target": 0.0,
+                "per_group": {"main": {"throttle_target": 65}},
+            },
+        ],
+    },
+    # The total mission time is not known in advance, so progress["fraction"]
+    # is an estimate rather than an exact ratio.
+    termination={"mode": "until_depleted", "soc_cutoff_pct": 20.0},
+)
+print(f"created {dyn['id']}, status={dyn['status']}")
+
+# Watch progress. 2-5 s is the right cadence; anything faster spends requests
+# on a value the worker only rewrites once per integration window.
+CANCEL_AFTER_S = 45.0
+deadline = time.monotonic() + CANCEL_AFTER_S
+
+while time.monotonic() < deadline:
+    time.sleep(3.0)
+    run = client.dynamic_simulations.retrieve(dyn["id"])
+    if run["status"] not in ("queued", "running"):
+        break
+    # `progress` is None until the worker picks the run up.
+    p = run.get("progress")
+    if p is None:
+        print(f"  {run['status']}, no progress yet")
+        continue
+    frac = p.get("fraction")
+    pct = f"{frac * 100:5.1f}%" if frac is not None else "   ? %"
+    print(f"  {pct}  sim {p['sim_time_s']:.1f} s  wall {p['wall_s']:.1f} s")
+
+run = client.dynamic_simulations.retrieve(dyn["id"])
+if run["status"] in ("queued", "running"):
+    # Cancel whatever state the deadline caught it in. A queued run comes back
+    # `canceled` immediately, with the compute units refunded and no result. A
+    # running one comes back still `running` with cancel_requested_at set, and
+    # the worker stops at its next integration window.
+    #
+    # Cancelling both matters here: with every execution slot busy this run can
+    # still be queued at the deadline, and skipping it would leave it to
+    # execute later against a script that has already exited.
+    accepted = client.dynamic_simulations.cancel(dyn["id"])
+    print(f"\ncancel accepted: status={accepted['status']}, "
+          f"cancel_requested_at={accepted.get('cancel_requested_at')}")
+    run = client.dynamic_simulations.wait(dyn["id"], timeout=300)
+
+print(f"final status: {run['status']}")
+
+blob = run.get("result")
+if blob:
+    meta = blob["run_meta"]
+    if meta.get("partial"):
+        print(f"partial result, stopped at t = {meta['canceled_at_t_s']:.1f} s of mission time")
+    sc = blob["scorecard"]
+    print(f"flight time:      {sc['flight_time_s']:.1f} s")
+    print(f"energy:           {sc['energy_wh']:.1f} Wh")
+    print(f"peak winding:     {sc['peak_winding_temp_c']:.1f} C")
+    print(f"samples returned: {len(blob['samples'])}")

{thrustlab-0.5.0 → thrustlab-0.6.0}/examples/fmu/ardupilot_sitl/README.md

@@ -22,7 +22,7 @@ state of charge — all from the `.fmu` you exported.
    ```sh
    mkdir -p mission_out
    python -m thrustlab.sitl \
-     --fmu my-powertrain.fmu --vehicle quad_x.yaml \
+     --fmu ../validation-quad.fmu --vehicle quad_x.yaml \
      --rpm-log mission_out/mission_rpm_log.csv
    ```
 
@@ -78,3 +78,12 @@ RPM lane — so the bridge logs it to `mission_out/mission_rpm_log.csv` for
 reconciliation against flight logs. If you changed the vehicle mass in
 `quad_x.yaml`, set `WEIGHT_N` at the top of `plot_mission.py` to match — it
 aligns the two recordings' clocks on the takeoff event.
+
+## The bundled FMU
+
+This example ships with a ready-to-fly FMU exported from ThrustLab
+(`../validation-quad.fmu`). The exact powertrain it reproduces is documented
+in the archive's own `resources/README.md`; unzip the FMU to read it. To
+recreate the FMU, build the same powertrain in ThrustLab or through the
+API/SDK, then export it with **Export → FMU** or `client.fmu`; your export
+will fly these examples identically.

{thrustlab-0.5.0 → thrustlab-0.6.0}/examples/fmu/ardupilot_sitl_tilttri/README.md

@@ -31,7 +31,7 @@ Everything the quad example needs (`../ardupilot_sitl/README.md`), plus:
 ```sh
 mkdir -p mission_out
 python -m thrustlab.sitl \
-  --fmu my-tri-powertrain.fmu --vehicle tilttri.yaml \
+  --fmu example-tri.fmu --vehicle tilttri.yaml \
   --rpm-log mission_out/mission_rpm_log.csv
 ```
 
@@ -74,3 +74,12 @@ physics. And a stopped rotor's flag means nothing: the rear rotor is
 deliberately stopped for most of the circuit while the wing carries the
 weight, so judge the envelope over spinning rotors only — the replay video
 does exactly that.
+
+## The bundled FMU
+
+This example ships with a ready-to-fly FMU exported from ThrustLab
+(`example-tri.fmu`). The exact powertrain it reproduces is documented in the
+archive's own `resources/README.md`; unzip the FMU to read it. To recreate
+the FMU, build the same powertrain in ThrustLab or through the API/SDK, then
+export it with **Export → FMU** or `client.fmu`; your export will fly these
+examples identically.

{thrustlab-0.5.0 → thrustlab-0.6.0}/examples/fmu/ardupilot_sitl_y6/README.md

@@ -22,7 +22,7 @@ Same three terminals as the quad example, swapping in this directory's files:
 ```sh
 mkdir -p mission_out
 python -m thrustlab.sitl \
-  --fmu my-y6-powertrain.fmu --vehicle y6.yaml \
+  --fmu example-y6.fmu --vehicle y6.yaml \
   --rpm-log mission_out/mission_rpm_log.csv
 ```
 
@@ -32,15 +32,19 @@ python -m thrustlab.sitl \
 ```
 
 ```sh
-python ../ardupilot_sitl/fly_mission.py --out-dir ./mission_out --speed-scale 0.3
+python ../ardupilot_sitl/fly_mission.py --out-dir ./mission_out --speed-scale 0.42
 ```
 
-`--speed-scale 0.3` matters here: a coax lane's sampled envelope is tighter
-than a solo rotor's map — edgewise speed caps near 5 m/s at this scale and
-descent states are not sampled at all — so the full-speed mission spends
-most of its time flagged `all_in_envelope=false` (outputs clamp to the
-envelope edge instead of being measured). Scaled down, the flight stays on
-sampled physics except for brief descents.
+`--speed-scale 0.42` uses the bundled FMU's wider sampled coax envelope: at
+hover rotor speed, it covers level edgewise flight to about 7 m/s, descent to
+3 m/s, and gentle approach legs (about 1.5 m/s down) to about 4.5 m/s
+edgewise. The entire 397-second demo mission stays on measured physics, with
+99.2% of armed frames `all_in_envelope`; the remainder are brief arm/disarm
+spool transients. The binding limit is the slowest rotor because the edgewise
+axis scales with rotor speed, advance-ratio style: in forward flight the
+unloaded rear-lower rotor reaches the envelope edge near 6.3 m/s, while
+loaded rotors remain covered to about 7.3 m/s. Beyond the envelope, outputs
+clamp to its edge and set `all_in_envelope=false` rather than extrapolating.
 
 ## The plots
 
@@ -60,3 +64,12 @@ python plot_coax_split.py ./mission_out ./mission_out/plots
 Its bottom panel is the point of the whole example: the lower rotor's share
 of each stack's thrust sits below 50% for the entire flight — the wake
 coupling, resolved per rotor, in a model the autopilot drives at 400 Hz.
+
+## The bundled FMU
+
+This example ships with a ready-to-fly FMU exported from ThrustLab
+(`example-y6.fmu`). The exact powertrain it reproduces is documented in the
+archive's own `resources/README.md`; unzip the FMU to read it. To recreate
+the FMU, build the same powertrain in ThrustLab or through the API/SDK, then
+export it with **Export → FMU** or `client.fmu`; your export will fly these
+examples identically.

{thrustlab-0.5.0 → thrustlab-0.6.0}/examples/fmu/betaflight_sitl/README.md

@@ -81,7 +81,7 @@ ls eeprom.bin
 ```bash
 python -m thrustlab.sitl \
   --target betaflight \
-  --fmu ~/validation-quad.fmu \
+  --fmu ../validation-quad.fmu \
   --vehicle betaflight_quad_x.yaml \
   --rpm-log mission_rpm_log.csv \
   --truth-port 9005 \
@@ -240,3 +240,12 @@ servo channels at all. The error reports the received size.
 - Betaflight master provides waypoint navigation through `BOX_AUTOPILOT` and
   `waypoint insert` in the CLI. The bridge supplies the required data, but this
   example does not test it.
+
+## The bundled FMU
+
+This example ships with a ready-to-fly FMU exported from ThrustLab
+(`../validation-quad.fmu`). The exact powertrain it reproduces is documented
+in the archive's own `resources/README.md`; unzip the FMU to read it. To
+recreate the FMU, build the same powertrain in ThrustLab or through the
+API/SDK, then export it with **Export → FMU** or `client.fmu`; your export
+will fly these examples identically.

{thrustlab-0.5.0 → thrustlab-0.6.0}/examples/fmu/endurance/README.md

@@ -16,7 +16,7 @@ of extrapolated.
 
 ```sh
 pip install fmpy numpy matplotlib
-python hover_endurance.py my-powertrain.fmu --mass-kg 1.20
+python hover_endurance.py ../validation-quad.fmu --mass-kg 1.20
 ```
 
 `--mass-kg` is the all-up mass WITHOUT payload (airframe + battery).
@@ -29,3 +29,12 @@ each flight — the spread between the two is the battery sag made visible.
 
 Export an FMU with `examples/fmu/export_and_download.py` or the dashboard's
 Share menu.
+
+## The bundled FMU
+
+This example ships with a ready-to-fly FMU exported from ThrustLab
+(`../validation-quad.fmu`). The exact powertrain it reproduces is documented
+in the archive's own `resources/README.md`; unzip the FMU to read it. To
+recreate the FMU, build the same powertrain in ThrustLab or through the
+API/SDK, then export it with **Export → FMU** or `client.fmu`; your export
+will fly these examples identically.

{thrustlab-0.5.0 → thrustlab-0.6.0}/examples/fmu/gazebo/README.md

@@ -7,7 +7,7 @@ links — spin-up dynamics, battery state and envelope flags included.
 
 ## What you need
 
-- An exported FMU, **unzipped** (`unzip my-powertrain.fmu -d my-powertrain/`).
+- An exported FMU, **unzipped** (`unzip ../validation-quad.fmu -d validation-quad/`).
 - The `fmu-gz-plugin` ThrustlabFmuSystem plugin, built against gz-sim ≥ 9
   (see its README for the CMake build; it dlopens the FMU's own
   `binaries/x86_64-linux/*.so`).
@@ -61,3 +61,12 @@ For an ArduPilot- or PX4-controlled Gazebo vehicle, keep their standard
 Gazebo integration for control surfaces and use this plugin as the
 propulsion + battery physics; the ArduPilot JSON bridge
 (`thrustlab.sitl`) is the lighter path when you don't need a 3D world.
+
+## The bundled FMU
+
+This example ships with a ready-to-fly FMU exported from ThrustLab
+(`../validation-quad.fmu`). The exact powertrain it reproduces is documented
+in the archive's own `resources/README.md`; unzip the FMU to read it. To
+recreate the FMU, build the same powertrain in ThrustLab or through the
+API/SDK, then export it with **Export → FMU** or `client.fmu`; your export
+will fly these examples identically.

thrustlab-0.6.0/examples/fmu/simulink/.gitignore

@@ -0,0 +1,2 @@
+slprj/
+*.slxc

thrustlab-0.6.0/examples/fmu/simulink/README.md

@@ -0,0 +1,53 @@
+# Simulink co-simulation
+
+`run_fmu_simulink.m` builds a Simulink model programmatically, imports the
+bundled quadcopter FMU, commands a fixed throttle on every rotor, and runs
+FMI 3.0 Co-Simulation. It plots thrust, bus voltage, and battery state of
+charge to `fmu_cosim.png`.
+
+![Thrust, bus voltage, and battery state of charge](fmu_cosim.png)
+
+## Requirements
+
+MATLAB + Simulink, verified on R2025a. No toolboxes beyond Simulink are
+required.
+
+## Run it
+
+From this folder:
+
+```sh
+matlab -batch "run('run_fmu_simulink.m')"
+```
+
+Or open `run_fmu_simulink.m` in MATLAB and run it interactively.
+
+## FMU import gotchas
+
+Three things that will silently ruin the model if changed:
+
+- The FMU Import block lives in the Simulink Extras library
+  (`'simulink_extras/FMU Import/FMU'`), NOT in User-Defined Functions.
+- The block wants a BARE file name with the FMU's folder on the MATLAB
+  path — a full path in `FMUName` is not accepted.
+- Every FMU output you care about must be wired to a root Outport;
+  unconnected outputs are removed by block reduction and the simulation
+  proves nothing about them.
+
+Port order follows the FMU's `modelDescription.xml` declaration order and is
+the same for every ThrustLab export regardless of rotor count. The full
+input and output list is in the script header.
+
+## Use your own FMU
+
+Export an FMU from a completed simulation through **Share → Export FMU** or
+`client.fmu`. Put its folder on the MATLAB path, then set `FMU_FILE` to the
+bare archive name and `N_ROTORS` to its rotor count in
+`run_fmu_simulink.m`.
+
+## The bundled FMU
+
+This example ships with a quadcopter FMU exported from ThrustLab
+(`../validation-quad.fmu`). The exact powertrain it reproduces is documented
+in the archive's own `resources/README.md`; unzip the FMU to read it. An
+equivalent export will fly this example identically.

thrustlab-0.6.0/examples/fmu/simulink/run_fmu_simulink.m

@@ -0,0 +1,93 @@
+% run_fmu_simulink.m — co-simulate a ThrustLab FMI 3.0 FMU in Simulink.
+%
+% Builds a model programmatically, imports the bundled quadcopter FMU,
+% commands a fixed throttle on every rotor, runs 30 s of co-simulation, and
+% plots thrust, bus voltage, and battery state of charge.
+%
+% Requires MATLAB + Simulink (verified on R2025a). Run from this folder:
+%
+%     matlab -batch "run('run_fmu_simulink.m')"
+%
+% Three things that will silently ruin the model if changed (all measured):
+%   * The FMU Import block lives in the Simulink Extras library
+%     ('simulink_extras/FMU Import/FMU'), NOT in User-Defined Functions.
+%   * The block wants a BARE file name with the FMU's folder on the MATLAB
+%     path — a full path in FMUName is not accepted.
+%   * Every FMU output you care about must be wired to a root Outport;
+%     unconnected outputs are removed by block reduction and the simulation
+%     proves nothing about them.
+%
+% Port order follows the FMU's modelDescription.xml declaration order and is
+% the same for every ThrustLab export regardless of rotor count:
+%   inputs : 1 throttle[N]  2 v_axial_m_s[N]  3 air_density_kg_m3
+%            4 v_edge_m_s[N]  5 ambient_temp_C  6 v_body_m_s
+%            7 omega_body_rad_s  8 tilt_rad[N]  9 wind_m_s
+%   outputs: 1 thrust_N[N]  2 torque_Nm[N]  3 force_inplane_N[N]  4 rpm[N]
+%            5 current_A[N]  6 motor_temp_C[N]  7 voltage_bus_V
+%            8 current_bus_A  9 power_bus_W  10 battery_soc
+%            11 battery_temp_C  12 force_total_N  13 moment_total_Nm
+%            14 sub_steps  (+ per-rotor envelope flags and the rotor manifest)
+
+FMU_FILE = 'validation-quad.fmu';   % bundled one folder up
+N_ROTORS = 4;                       % rotor count of THIS FMU
+THROTTLE = 0.65;                    % commanded on every rotor, 0..1
+STOP_S   = 30;
+
+here = fileparts(mfilename('fullpath'));
+addpath(fullfile(here, '..'));      % FMU block needs the folder on the path
+
+mdl = 'tl_fmu_cosim';
+try close_system(mdl, 0); catch, end
+new_system(mdl);
+blk = [mdl '/powertrain'];
+load_system('simulink_extras');
+add_block('simulink_extras/FMU Import/FMU', blk);
+set_param(blk, 'FMUName', FMU_FILE);
+ph = get_param(blk, 'PortHandles');
+fprintf('FMU ports: %d in, %d out\n', numel(ph.Inport), numel(ph.Outport));
+
+% Drive throttle (input 1, an N-wide array) and air density (input 3).
+add_block('simulink/Sources/Constant', [mdl '/throttle'], ...
+    'Value', sprintf('%g*ones(1,%d)', THROTTLE, N_ROTORS));
+add_block('simulink/Sources/Constant', [mdl '/rho'], 'Value', '1.225');
+th = get_param([mdl '/throttle'], 'PortHandles');
+rh = get_param([mdl '/rho'], 'PortHandles');
+add_line(mdl, th.Outport(1), ph.Inport(1));
+add_line(mdl, rh.Outport(1), ph.Inport(3));
+
+% Root Outports on every FMU output (see the block-reduction note above).
+for p = 1:numel(ph.Outport)
+    op = sprintf('%s/out%d', mdl, p);
+    add_block('simulink/Sinks/Out1', op);
+    oph = get_param(op, 'PortHandles');
+    add_line(mdl, ph.Outport(p), oph.Inport(1));
+end
+
+set_param(mdl, 'StopTime', num2str(STOP_S), ...
+    'SolverType', 'Fixed-step', 'FixedStep', '0.01');
+out = sim(mdl);
+y = out.yout;
+
+thrust  = y{1}.Values;   % thrust_N, N columns
+voltage = y{7}.Values;   % voltage_bus_V
+soc     = y{10}.Values;  % battery_soc
+
+fprintf('final per-rotor thrust [N]: %s\n', mat2str(thrust.Data(end, :), 5));
+fprintf('final bus voltage [V]:      %.3f\n', voltage.Data(end));
+fprintf('final state of charge:      %.4f\n', soc.Data(end));
+
+fig = figure('Visible', 'off', 'Position', [0 0 900 700]);
+subplot(3, 1, 1);
+plot(thrust.Time, thrust.Data); grid on;
+ylabel('thrust [N]'); title(sprintf('%s at %.0f%% throttle', FMU_FILE, 100 * THROTTLE));
+subplot(3, 1, 2);
+plot(voltage.Time, voltage.Data); grid on;
+ylabel('bus voltage [V]');
+subplot(3, 1, 3);
+plot(soc.Time, soc.Data); grid on;
+ylabel('state of charge'); xlabel('time [s]');
+saveas(fig, fullfile(here, 'fmu_cosim.png'));
+fprintf('wrote %s\n', fullfile(here, 'fmu_cosim.png'));
+
+close_system(mdl, 0);
+disp('FMU_COSIM_DONE');