Skip to content

ENH: Simulink Integration #275

Open

Description

@giovaniceotto

With the implementation of full support for controllers in RocketPy (see issue #274), there will be a need to integrate RocketPy with commonly used control system design tools, such as Simulink.

Therefore, this issue proposes the possibility of using RocketPy as one or more Simulink blocks.

Requirements

  1. A Simulink block shall be created, based on, for example, a MATLAB Function block. Such MATLAB Function shall be responsible for running RocketPy under the hood. As already known, RocketPy can already be used in MATLAB. See the useful links below for more info.

  2. The end-user should not need to know how to code in Python nor how to use Python.

  3. An example with detailed documentation must be created.

Proposed Milestone

This feature should be implemented in a major release with full support for controllers.

Therefore, it can be released with v2.0.0.

Useful Links

Activity

  1. added this to the Release v2.0.0 milestone on Nov 5, 2022
  2. moved this from Long-Term to Long-Term in LibDev Roadmapon Nov 5, 2023
  3. changed the title [-]Simulink Integration[/-] [+]ENH: Simulink Integration[/+] on Oct 11, 2024
  4. ting-hong-shieh commented on Aug 14, 2026

    @ting-hong-shieh

    RocketPy already documents calling its Python objects from MATLAB, but a Simulink integration needs a narrower real-time contract than the current interactive workflow. I suggest an RFC comparing three adapters:

    Adapter Main benefit Main constraint
    MATLAB System block calling Python Smallest implementation and closest to the existing MATLAB workflow Python lifecycle and call latency must be controlled
    C/C++ S-function Strong control over sample time and data layout Requires a stable native ABI and a separate build/toolchain
    MATLAB/Simulink bridge to a separate Python process Isolates Python failures and dependencies Adds transport, synchronization, and process-management complexity

    For a first milestone, I recommend a deterministic discrete-step Python contract and a MATLAB System block adapter. The contract should be usable without MATLAB so its behavior can be tested in public CI.

    The minimum interface should define:

    • one owner for the simulation state;
    • a fixed SI-unit input/output schema;
    • initialization, step(t, input), and shutdown operations;
    • a declared sample time with rejection of out-of-order or duplicate steps;
    • how solver errors and Python exceptions cross the boundary; and
    • the supported RocketPy, Python, MATLAB, and Simulink version matrix.

    The first acceptance case can exchange a small deterministic state vector at a fixed sample time and compare the Simulink trace with a Python reference trace. Python-side contract tests should cover sample-time enforcement, state ownership, units, and failure propagation. Because MATLAB/Simulink cannot normally run in this project's public CI, any proprietary-side verification should report the exact product versions and commands rather than being represented as automated coverage.

    If maintainers prefer an S-function or process bridge, the same transport-neutral step contract can remain the first deliverable. I can draft that schema once the adapter direction and supported product versions are chosen.

  5. Gui-FernandesBR commented on Aug 14, 2026

    @Gui-FernandesBR
    Member

    @ting-hong-shieh we need time to evaluate the possible architecture solutions. There are many PRs being opened to our repo right now and we need time to handle everything. I hope you understand that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ControllersControlling rocket flight methods

    Projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions