Modeloop - model-based design with ROS 2 node generation

Projects
1

Hi developers,

I’ve been building Modeloop (https://www.modeloop.app/) , a browser-based environment for
model-based design: you connect blocks into a diagram, simulate the
dynamics, and generate code. Think Simulink-style modeling, but the
editor runs entirely in the browser and the model format is plain,
git-friendly text.

A note on how to try it, to be upfront:

  • The modeling + simulation experience runs in the browser — you can
    play with it instantly, no install.
  • The ROS 2 toolbox runs in the desktop app. A browser sandbox can’t
    speak DDS / connect to a live ROS graph, so the ROS workflow needs to
    run natively. That’s exactly why I’m posting: I’m sharing the desktop
    build so you can try the full ROS workflow on your own setup and tell
    me where it breaks.

So, if you want to try it please let me know signing to the waitlist.

What the ROS toolbox does:

  • Imports .msg / .srv directly from your existing ROS workspace
  • Native Publisher / Subscriber blocks for drag-and-drop topic wiring
  • ROS 2 Humble / Iron / Jazzy support, with QoS settings
  • Generates standalone C++ (rclcpp) or Python (rclpy) nodes
  • Hardware-in-the-Loop: run the model locally while connected to a
    live ROS network or Gazebo — debug against real sensor data with no
    compile step during design

I’d genuinely value feedback from people doing real robotics/control
work:

  1. Does generating ROS 2 nodes from block diagrams fit how you’d
    actually work, or is it solving the wrong problem?
  2. Is the HIL-against-live-ROS workflow useful, or do you debug
    differently?
  3. What’s missing for it to be worth trying on a real project?

It’s still early and I’m actively shaping the roadmap, so critical
feedback is appreciated.

Article: :backhand_index_pointing_right: Unlocking Robotics: A Guide to the Modeloop ROS Toolbox — Modeloop

2

Hi,
The ability to do HIL directly against a live ROS graph without compiling is a huge workflow accelerator.
my main feedback centers around your question #3 (“What’s missing for it to be worth trying on a real project?”): When you generate a standalone node (e.g., pulling from /odom and pushing to /cmd_vel), the diagram assumes a mathematically deterministic closed-loop. But on real hardware, What happens when the physical execution collapses? For example:
• The generated node commands v = 1.0 m/s.
• The robot hits an oily patch (wheel slip) or the SLAM stack resets (localization jump).
• The physical feedback /odom suddenly breaks causal alignment with /cmd_vel.
In hand-written C++, we often have to write painful custom state-estimators to catch this. In a block-diagram paradigm, how do you envision users handling these physical anomalies? Do they have to build complex residual-check logic using math blocks, or do you plan to offer “Kinematic Anomaly” blocks out of the box?
I recently open-sourced runtime_integrity, a pure observe-only ROS 2 tool that audits this exact problem—it watches the /cmd_vel and /odom causality and logs physical execution collapses (like slips and jumps) into machine-readable CSVs for ML/Sim2Real debugging.

1 Like
3

Hi zc_Liu,

First of all, thank you for the feedback!

One clarification: Modeloop is not only generating a standalone math node. The ROS2 toolbox already generates real ROS2 nodes from the diagram interface with QoS profiles, lifecycle support and more. However, in your case, such protections aren’t useful.

Our philosophy in Modeloop is heavily based on the Separation of Concerns, rather than trying to hide real-world noise behind “magic” blocks within the controller itself.

From an architectural standpoint, we believe this should be handled by a dedicated State Estimation, separate from the pure control logic. Instead of wiring raw sensor data directly into the controller, the architecture involves creating an Observer subsystem that actively monitors the signal’s integrity. You can model a Finite State Machine (FSM) that continuously evaluates the state of the incoming signals (e.g., checking the causality between /cmd_vel and /odom). When the FSM detects an anomaly (like a slip or a jump), it transitions the signal state from “valid” to “faulty”. The integrated observer then uses this FSM state to decide how to filter or reconstruct the data. The main controller then simply consumes these cleaned, filtered values integrated within the observer, completely abstracting the physical anomalies away from the core control logic.

Thanks again for the great question and for sharing your work,

Luca Marchionna