What is HiroSim™?
HiroSim™ is a high-performance control, modeling, and simulation stack for AI-assisted aerospace, robotics, and industrial engineering — helping simulation, GNC, flight software, and telemetry teams build, test, and visualize closed-loop systems before they touch hardware.
The stack combines a deterministic, multivehicle, realtime (or faster), thread-pool-backed event-driven simulator with nanosecond precision, native control-code execution, a telemetry pipeline, and a live browser dashboard. Components are connected through standard formats and a language-neutral plugin boundary, so models and controllers can evolve independently without needing to recompile the simulator. A thin Hardware Abstraction Layer (HAL) closes the loop: the same control code you validate in simulation runs unchanged on real Linux hardware — only the implementation behind the HAL changes between flying in sim and flying on metal.
HiroSim™ is designed for the kind of iterative work simulation engineers do every day: adjust a model, run a scenario, inspect telemetry, refine the controller, and repeat. It supports composable models, JSON-defined scenarios, variable-rate execution, commanding, save/restore, and integrations with tools such as Zenoh, ROS 2, DuckDB, PyArrow, OpenTelemetry, HLA, and native C/C++/Rust/Python plugins. Models can be physics-based or Machine Learning trainable, fitted from data, and run in the same deterministic scheduler.
HiroSim™ is designed around modularity, deterministic execution, strong interfaces, local model isolation, and fast headless feedback. That makes it a natural foundation for AI-assisted model generation, controller testing, test-case creation, and automated verification workflows.
Why now?
AI-Assisted Physical Engineering is the next frontier. Aerospace, robotics, and industrial systems companies are moving faster than their test infrastructure. Hardware is expensive, field tests are risky, and software complexity keeps growing. Teams need deterministic, high-fidelity simulation before they touch real hardware. Every company is reinventing the wheel and engineers are stuck with obsolete tools or half-baked solutions. What we have created is an end-to-end, state-of-the-art solution that operates using modern standards and is very fast to iterate with using ML and LLMs. This is a step towards a future of fully automated engineering.
Who built HiroSim™?
HiroSim™ was built by Massimo Di Pierro — Ph.D. in Physics, former Senior Engineer & Manager of Simulations at SpaceX, Professor of Computer Science at DePaul University and UCSC.
See it in action
Built with AI, for AI
HiroSim™ is config-first: vehicles and flight computers are described in JSON and a Python-like DSL — which compiles down to native code. This is the medium AI assistants are most fluent in. In the video we show how an entire vehicle (three rigid bodies on rods, downward thrusters, noisy sensors, a generated mesh, and a four-state lift–hover–land flight computer) is produced from a handful of natural-language prompts.
Every primitive composes by name, per-model docs are the source of truth, and the stack rebuilds in seconds — so an assistant can read, edit, rebuild, and re-fly the sim inside a single conversation.
Building a lander, end-to-end, without AI
A complete tour of the stack through a single example. Write the flight computer as
small Python-like algorithms — a sensor pass-through and a four-phase
ASCENT → COAST → BRAKE → LANDED state machine — wire
them together in JSON, and compile the whole thing into a single native
controller with fcslc.
Plug it into the simulator's vehicle, sensors, actuator, and integrator, then fly it and stream telemetry to a live browser dashboard. The same flight-computer binary can be driven deterministically from pytest via twins.
Deploy the same code on your hardware
The same flight-computer algorithm you validate in sim runs unchanged on real hardware via a customizable Hardware Abstraction Layer. A one-line swap chooses the backend: one that exchanges data with the simulator over Zenoh, or another that talks to the board through Linux drivers (for example IIO, PWM, evdev, power-supply and sysfs).
One path from software-in-the-loop, through hardware-in-the-loop, to on-vehicle flight.
Live dashboards, customizable in JSON
The telemetry visualizer is configured entirely from a JSON file — edit it, press a button, see the change. Mix existing widgets or make your own.
Transmission diagnostics surface dropped packets and emit-to-receive latency, while command tables write back to the running simulator and alerts watch the wire and light up when a condition trips. All data is also accessible from notebooks using a Python client API.
Reproducible testbeds with rigx capsules
We use Rigx as a build system. A single TOML file declares every component — a Zenoh router, the telemetry service, the visualizer, the simulator, and the compiled flight computer — and a single target builds them all and brings them up in order over the Zenoh bus.
One shell command boots the whole topology; one Python script reads the columnar telemetry the receiver wrote and asserts touchdown — fully end-to-end and pluggable into pytest. The Python API has the ability to inject faults for testing.
For a live demo or to partner, contact us.
Whitepapers
- Designing a Simulation Stack for Large-Language-Model Collaboration: The HiroSim Experience
- HiroSim: A Modular, Deterministic Simulation Stack for Closed-Loop Control-Software Development
- FCSL: A Compiled, Statically-Scheduled Specification Language and Hardware Abstraction Layer for Simulation-to-Flight Continuity in Flight Computers
- A Stable Gray-Box Surrogate for Unsteady Aerodynamic Coefficient Prediction in Real-Time Simulation
- A Stable Gray-Box Surrogate for Engine Spool Dynamics in Real-Time Propulsion Simulation
- Learn Nim - start here