Platform Agnosticism
We don’t replace. We orchestrate.
Shinro Studio does not replace ROS, MuJoCo, Isaac Sim, Gazebo, or any of the other connective tissue your team already depends on. It orchestrates them. Each integration is itself a module, and the depth of integration is a choice you make per project.
Black-box integration
Wrap an external system as a black box. Shinro Studio launches it, supervises it, and treats its inputs and outputs as opaque.
Example: ROS2 as a black box. Shinro Studio launches and supervises a ROS graph, but it doesn’t introspect every message that flows between ROS nodes. This is the right pattern for teams who want to keep their ROS investment intact without re-architecting around Shinro.
Native integration
Compose external systems directly into the Shinro module graph. ROS2 components can be wrapped as native Shinro modules with bidirectional access to the descriptor graph; MuJoCo can be compiled in as a simulator module the kernel manages directly. Native integration gives you full visibility, hot-swap, and lower latency than black-box wrapping — at the cost of more upfront work. For most ROS users this is the long-term destination, but rarely the starting point.
The depth is your choice
The same external system can be wrapped as either a black-box or a native integration depending on how much your team wants to invest. The two patterns share the same module interface — migrating from one to the other is a module replacement, not a rewrite.
”Coming home is easy” — easy in, easy out
A team using ROS2 can adopt Shinro Studio incrementally by wrapping their ROS workspace as a module. If they later decide to leave, their ROS code remains standard ROS and runs without Shinro. There is no Shinro-specific dialect of ROS, no required port, no rewrite to leave.
This is the explicit anti-lock-in commitment. The integration is yours to make and yours to unmake.