Skip to content
SHINR

The development environment for robotics.

Describe your robot, wire its behavior from modules. Compile it to a native binary for your hardware. Run ROS as a module for deeper debugging metrics.

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.

THE PROBLEM

Teams rebuild the same plumbing instead of shipping what makes their robot unique.

Every robotics team writes its own drivers, deployment pipelines, debug tooling, and hardware abstraction. Vendor SDKs lock you to one platform. Internal stacks take years to develop. Physical AI requires fast iteration

Too much robotics engineering time disappears into non-differentiating infrastructure.

WHAT MAKES EACH ROBOT UNIQUE
01
AUTONOMOUS VEHICLES
fleet-scale autonomy
02
ROBOTIC ARMS
sub-millimetre manipulation
03
HUMANOID ROBOTS
whole-body control
THE PLUMBING THEY EACH REBUILD
IN-HOUSE STACK×3
HALdriversvendor SDKslaunch filessim bridgesdeploy hackslogging glue

Different robots. The same plumbing, rebuilt from scratch, every time.

WHY NOW

Two shifts created the gap.

HARDWARE IS HETEROGENEOUS NOW

Five years ago a team picked one platform. Today every team spans compute targets: Jetson for perception, ESP32 for low-level control, custom boards for accelerators. Existing tooling assumes one target.

AI IS THE APPLICATION LAYER

Robot behavior is composed from learned policies, perception models, and controllers. Every team builds the integration plumbing itself. The development environment for AI-native robotics does not exist yet.

every tech wave produced the company that owned the workbench. games got Unreal. code got GitHub. data got Databricks. robotics still rebuilds the workbench project by project.

WHY SHINRO

Same stack. New foundation.

Shinro sits between robotics frameworks and hardware targets: one consistent way to compose, build, deploy, and observe robot software across runtimes. Run your stack with less runtime plumbing.

Build once, run on anything.

L4APPLICATION
fleetui
L3PLANNING
navbehaviors
L2STATE ESTIMATION
slamperception
L1DRIVERS
controldds
SHINRO KERNEL· no restart
L0HARDWARE
computesensorsmotors

A traditional layered stack. Each layer talks to its neighbors, and a change means rebuild and restart.

One thin layer above hardware. Connecting any module to every layer.

Studio

One environment: describe the machine, compose behavior, simulate, deploy native, swap live.

See everything.

01Model
02Program
03Simulate
04Deploy
05Modify
Visual Programming

Drag, drop, and link blocks to map hardware and orchestrate behavior.

HIGH-FIDELITY FEEDBACK

Real-time physics for pre-hardware validation, live telemetry after deployment.

JOINT TORQUE / Nm
2.14
CODE-TO-HARDWARE PIPELINES

Pick your target device and settings, then swap live modules at low latency.

target architecture
THE ARCHITECTURE

Where composition happens.

MOST FRAMEWORKS
Composed at runtime

Components find each other and exchange messages while the robot runs.

camera driverSLAMplannermotor control
message bus · shared memory

Wiring is resolved while the robot runs. Every hop crosses the bus.

SHINRO
Composed at compile time

The toolchain reads your module descriptors and generates the inter-process plumbing into one binary.

MODULE DESCRIPTORS
$ cake build
generates the plumbing
one native binary
cross-compiled for the target

generated plumbing: shared memory, pipes, concurrency

cake kernel
distributed as-is

target hardware: any architecture

Deploying updates a module on the kernel, at runtime. The rest keeps running.

THE RESULT
less runtime discoveryfewer moving partsmore auditable buildscleaner deployment boundarieslive module updates

Shinro moves the hard part from runtime to compile time.

THE WORKFLOW

The developer loop.

01
Develop

Compose in Shinro Studio, or reuse existing modules.

02
Build

The kernel toolchain cross-compiles your modules for the target architectures.

$ cake build
03
Deploy

Ship to the device, or hot-swap a module at runtime without stopping the robot.

04
Observe

Telemetry streams back from the robot.

back to Studio: simulate, iterate

Develop, build, deploy, observe. Then iterate.

THE PLATFORM

Three components.

DEVELOP
Shinro Studio

The AI-native visual programming and development platform.

SHARE & REUSE
Reusable modules

Community-published modules, ready to drop into your build.

ROS wrapperSLAMtelemetrysimulation
RUN
cakethe Shinro kernel

A low-latency, cross-platform executable. Distributed as-is, deployable to any architecture.

arm64 · x86-64 · MCU-class

Develop in Studio · run on cake · share what you build.

LIVE MODULES

Live module updates without downtime.

Add hardware capabilities or replace software behaviour without stopping the task.

grippercameraforce controlmobile baseplanner

A digital twin of a desktop robot arm continuously picks a block and places it on a target marker. Drag the block anywhere and the arm replans without stopping.

Mount modules while it runs: a gripper enables carrying, a camera adds live perception, force control softens contact, a mobile base extends reach, and swapping the planner changes trajectory quality mid-motion.

No restart at any point.

LICENSING

What is open. What is licensed.

Shinro Studio

Source in the open, free to use. Fair-code terms.

FAIR-CODE
Modules

Each module carries its author's license. Open source encouraged.

PER-MODULE
cakethe kernel

Commercially copyrighted, distributed as-is.

CLOSED SOURCE

Open tools to build with, a dependable kernel to run on.

Come build robot software that stays live.