One runtime. Many robot bodies.
CenterOS puts arms, hands, gloves and cameras behind one versioned Cell, and records every session as synchronized, replayable evidence.
Hardware-independent orchestration. Hardware-specific truth.
CenterOS unifies sessions, clocks, recording and access. Each device keeps its own kinematics, force control and safety limits.
- Native adaptersEvery device declares its own action and observation contract. Nothing is flattened into a fake universal robot.
- Local safety gateMotion needs an open local session and an explicit opt-in. A catalog listing never grants control.
- Evidence by defaultActions, state, video and operator events are recorded against the exact Cell version.
How a session runs
- Compose a Cell. Pin the exact assets, serial numbers, firmware, drivers and calibration into a versioned manifest.
- Run preflight. The edge host checks health, clocks and calibration before any mode is allowed. Preflight never enables or moves the robot.
- Open a session. Calibration, teleop capture, shadow or canary mode, each with its own authority. High-frequency commands stay local.
- Record. Actions, joint state, RGB-D, tactile and operator events become one replayable episode.
- Evaluate. Runs are scored against acceptance criteria and stay bound to the Cell and environment version they ran on.
Architecture
- CloudCenterOS PlatformOrganizations, Cell configuration, datasets, evaluation runs, fleet view.
- EdgeCell RuntimeSession gate, preflight, time sync, recorder, local buffer, native adapters.
- HardwareVendor SDK + safety controllerArm, hand, camera, glove. Hardware e-stop and safety PLC stay in charge of real-time safety.
Bring the hardware your task needs.
Support is tracked per model and per configuration. The status shown is what the runtime code says today.
Full support matrix
| Device | Cell Runtime level | Capture / teleop agent |
|---|---|---|
| UFACTORY xArm 7 | Experimental control | Optional official-SDK adapter, local opt-in |
| Wuji Hand | Experimental control | Joint-position SDK prototype |
| Intel RealSense D455 | Observe only | Camera agents: D405, D435, D435i, D455 |
| UFACTORY xArm 6 | Catalog | — |
| Franka FR3 | Catalog | — |
| Universal Robots UR3e, UR5e, UR10e | Catalog | — |
| AgileX PiPER | Catalog | SDK interface, mock mode only |
| OpenArm | Catalog | Teleop and collection agent |
| ALOHA (bimanual) | Catalog | SDK interface, mock mode only |
| Trossen Interbotix arms | Catalog | — |
| Unitree Z1 · Flexiv Adaptive · AGIBOT industrial arm | Catalog | — |
| BrainCo Revo hand | Catalog | Hand agent |
| Linkerbot · Sharpa dexterous hands | Catalog | — |
| SCHUNK EGK, EGP, EGH, Co-act EGP-C grippers | Catalog | — |
| Wuji Glove | Catalog | Glove agent |
| MANUS Gloves Pro · Linker glove | Not in runtime catalog | Glove agents |
| Intel RealSense D435 | Catalog | Camera agent |
| Stereolabs ZED 2i | Catalog | Camera agent (ZED, ZED 2, ZED Mini) |
| Orbbec Femto Bolt · Gemini 335Lg / 345Lg | Catalog | Camera agents for Gemini 335Lg, 345Lg |
| GoPro HERO | Catalog | — |
Catalog: model is known; no CenterOS driver. Observe only: telemetry may be read, never commanded. Experimental control: an adapter exists behind the local session gate; not production-validated. Certified control: no device holds this level today. Agents are the platform's separate teleop and capture processes; they do not change a device's runtime level.
Use it where your team works.
A CLI, an MCP server for AI agents, and a Python SDK, all on the same platform API and the same login.
# Not on PyPI yet. Install the preview package we send you.
$ pip install ./centeros-cli
$ centeros login # browser sign-in; --device for headless hosts
$ centeros whoami
$ centeros hardware list
$ centeros datasets list
$ centeros eval list
$ centeros safety active # list active e-stopsCLI command groups
The centeros command covers the platform end to end. Run centeros --help for the full list.
- login · logout · whoami
- hardware
- teleop
- safety
- fleet · robot
- datasets · dataset
- eval
- training · models
- vla
- sim
- slam
- mission
- ota
- share · sharing
- skill
- health · stats
MCP tools for AI agents
The server reads your token from CENTEROS_TOKEN. Motion commands are checked against the robot's safety profile, velocity-clamped, and refused while an e-stop is active.
- list_hardware_catalog
- get_hardware_entry
- list_robots
- get_robot_twin
- list_teleop_sessions
- get_teleop_session
- send_robot_command
- get_safety_profile
- list_active_estops
- emergency_stop
- start_rc_sim
- rc_sim_status
- list_slam_sessions
- list_missions
- fleet_overview
- browse_datasets
- search_wiki
- list_available_actions
Robot agent SDK
Write an adapter for your own robot by subclassing BaseTeleopAgent. The bundled PiPER, OpenArm and ALOHA agents are interfaces that run in --mock mode; hardware drivers are not included in the package.
$ centeros-robot list-robots
$ centeros-robot run piper --mock
$ centeros-robot run openarm --mock --recordEvery run leaves a usable record.
Recordings, evaluation runs and findings stay bound to the Cell they came from, so a result always says which hardware, firmware and calibration produced it.
What an evidence record contains
- Cell
- manifest@version
- Policy
- model@release
- Mode
- teleop · shadow · canary
- Verdict
- pass · fail · inconclusive
- Acceptance criteria: metric, threshold, required or not.
- Synchronized streams: actions, joint state, RGB-D, tactile, operator events.
- Findings: failure class, evidence link, next action.
Clear boundaries.
What exists today, what is in preview, and who owns safety.
Is CenterOS hardware agnostic?
It orchestrates across hardware without erasing what is specific to each device. Adapters, kinematics, limits, firmware and safety behaviour stay configuration-specific.
Can I install CenterOS with pip today?
Not from PyPI yet. The CLI, MCP server and Python SDK are Python packages we distribute to developer-preview participants. Request access for the current install path.
Does CenterOS replace the robot safety controller?
No. CenterOS handles session orchestration, authorization, recording and adapters. Vendor controllers, safety PLCs and hardware emergency stops keep real-time functional-safety responsibility.
Which configurations are certified?
None yet. The highest level any device holds in the runtime today is experimental control (xArm 7 and Wuji Hand).
Tell us what you want to build.
Share your hardware and goal. We will reply with its current integration status and the safest next step.