Overview

Shinro is a development environment for robotics. Describe your robot, wire its behavior from visual modules, and compile it to one native binary that runs on the cake kernel across heterogeneous hardware — Jetson, ESP32, and custom boards. Run ROS as a module for debugging and interop. Shinro Studio is source-available under fair-code terms and free to use; community modules carry their authors’ licenses; the cake kernel is commercial, distributed as-is.

Shinro Studio is the operator-facing application: where you observe, debug, execute, and deploy robotics systems.

Operators (engineers, scientists, and entrepreneurs) use Studio to inspect system state, express intent, and run lifecycle operations against Shinro.

Its core responsibilities span the full software lifecycle:

Runtime telemetry: track software behavior and hardware state
Execution analysis: audit and debug control flow, data flow, and failure paths
Workload orchestration: execute and deploy software across heterogeneous hardware targets
Resource visibility: expose CPU, memory, storage, network, device access, and deployment state as system data

No hidden hardware cost

Resource usage stays visible to the operator during design, execution, and deployment.

Concepts and terminology

Studio sits at the boundary between human operators and an underlying distributed system. Before detailing its function, it helps to define the terms involved, since each one maps to a specific software engineering concept.

Data-driven application: behavior and presentation are derived from data (state, schemas, telemetry) rather than hardcoded logic. Studio’s UI reacts to the system’s data, not the reverse
Front-end application: the client-facing layer, distinct from backend orchestration. It renders state and forwards operator intent (commands, configs) to the system
Intermediary (interface layer): Studio decouples the operator from the system’s internals. Operators interact with abstractions (dashboards, controls) instead of raw APIs or infrastructure
Heterogeneous hardware architecture: a computing environment composed of non-uniform resources (CPU, GPU, TPU, edge devices, distinct instruction sets or memory models). Software deployed here must target multiple execution backends
Lifecycle operations (track, measure, audit, debug, execute, deploy): these correspond to stages of the DevOps/MLOps pipeline: observability (track, measure), verification (audit, debug) and operationalization (execute, deploy)
No hidden cost in hardware utilization: resource consumption (compute, memory, energy) that is opaque to the operator, often due to abstraction layers masking allocation decisions. Studio’s design goal is to keep this cost observable and attributable

Together, these terms describe Studio’s purpose: give operators of varying backgrounds (engineering, science, business) a unified, transparent interface to a system running on non-uniform hardware.

Modules, descriptors, and catalogs

A descriptor declares two independent contracts for the module lifecycle: what it exposes for composition, and what data flows through it at runtime

Provides: capabilities, resources, or interfaces a module exposes (a driver, a toolchain, a sensor abstraction). Other modules resolve their requirements against this
Requires: capabilities or dependencies a module needs to build or run. Resolution matches requires against provides across the module set, structurally, before anything executes
Input/output: the data ports a module reads from and writes to during execution. This is a runtime concern (the execution graph), distinct from the structural provides/requires match
Catalog: a collection of descriptors that can be browsed and resolved against (what a marketplace would host, or a local set curated by a team)

The problem

Robotics development today is fragmented. ROS for the runtime graph. A separate deterministic runtime for hard timing guarantees. Vendor SDKs for each sensor and board. A separate simulator for each kind of physics. A bespoke control stack — controllers, estimators, trajectory planning — rebuilt per robot (see Control Architecture for how Shinro addresses this specific primitive). And a pile of deployment scripts that no one fully understands and no one wants to touch.

The learning curve is steep, and deploying to mixed-fleet hardware is manual and error-prone.

Shinro centralizes these primitives, so teams can keep their specialists focused on the behavior that differentiates the product.

Three wedges

Ease of use

A visual Blueprint Editor for hardware composition. A flow canvas for behavior design. An embedded code editor for everything that needs to be code. An in-Studio simulator. A deployment manager. One tool, five modes, one mental model.

Teams compose their first robot in an afternoon, not a quarter.

AI-native

AI assistance is woven across the development lifecycle — at composition, at flow design, in the editor, in the simulator, and at deployment. Bring your own model: a perception module can run an on-device VLM while the deployment manager calls out to a hosted LLM for troubleshooting.

Engineers describe behavior in natural language and refine in code.

Deployment

Hot-swap module deployment lets you update a live system in place. Designed to cross-compile; validated targets grow incrementally — Linux, Windows, Android, ESP32, Jetson, and Raspberry Pi today. Fleet-wide updates are on the roadmap.

Update a module in production without halting the rest of the system.

Status

The Cake kernel and Shinro Studio are built as parallel workstreams; wiring them end-to-end is the current critical path. The kernel, module system, and CLI work today; Studio ↔ kernel integration is in progress. Until that integration lands, treat any end-to-end description in these docs as architectural, not operational.