Skip to content

Ecosystem & Optional Modules

The module ecosystem is what makes Shinro a platform rather than a tool. Descriptors are the substrate; everything else — community stores, the marketplace, formal-verification modules, simulator backends, debugger integrations — sits on top of them.

The marketplace

Shinro’s marketplace is a surface where users, companies, and Shinro itself publish modules. Some licensed, some free to use. The model is simple: every module is a descriptor, and the descriptor is the contract that lets a module published by one team be composed, audited, and hot-swapped by another without either side coordinating directly.

Three parties contribute:

  • Individual users publish modules they have built for their own robots — hardware abstractions for a specific board, perception primitives, behaviors.
  • Companies publish modules that wrap their products — sensor SDKs, motor controllers, vendor-supported libraries — under whatever licensing terms they choose.
  • Shinro publishes first-party modules: reference toolchains, baseline hardware abstractions, AI integrations, and verification tooling.

The marketplace backend is in active development. A contributor community is forming around it now, ahead of the public launch.

Formal verification as a module class

Formal-verification methods — model checking, theorem proving, automata-based verification — are valuable in late-stage robotics development for testing edge cases, debugging non-deterministic behaviors, and certifying safety-critical paths. Shinro Studio supports modules that integrate formal-verification tools. Verification modules are exactly the kind of high-trust, high-leverage contribution the marketplace is designed to host.

Mununu is one example; others can be added via the same module interface. The point is that the module system makes such integrations tractable — not that Mununu is the only or canonical option.

Other optional module classes

  • Physics engines — MuJoCo and alternatives, for the Simulator mode.
  • Simulator alternatives — Gazebo, Isaac Sim, and others.
  • Debugger alternatives — vendor and open-source debuggers, exposed through debugger modules.
  • Internal-communication alternatives — shared memory by default, with alternative transport modules available.

Contributing a module

Contributors write a descriptor, test their modules locally before submitting to a store (community or self-hosted), and let the kernel validate versioning, capability declarations, and acquisition steps at submission time rather than at runtime. A submission either resolves cleanly against the store’s existing graph or is rejected with a specific error.

100%