OpenCastor
The universal runtime for embodied AI
OpenCastor connects model providers, safety systems, swarm orchestration, messaging channels, and robot drivers through one runtime and one config surface.
Overview and Mission
Problem
Robotics teams often rebuild control stacks for each hardware kit, provider, and channel. That fragmentation slows delivery and makes safety and operations inconsistent.
OpenCastor addresses this by standardizing runtime behavior behind RCAN-based configuration and a shared safety and orchestration model.
Mission
Provide a single, production-capable runtime where embodied AI systems can integrate models, hardware, and channels without rewriting core control logic.
The practical goal is faster integration with safer operations and clearer operator tooling.
Architecture Summary
Runtime Core
- - RCAN config-driven runtime composition
- - Provider routing and fallback pathways
- - Driver abstraction for mixed robot hardware
- - API and dashboard operations surfaces
Safety and Operations
- - Safety enforcement and emergency control pathways
- - Protocol 66 conformance — GET /api/safety/manifest, 5 enforced invariants
- - SensorMonitor→SafetyLayer.estop() wiring (thermal/electrical events halt motors)
- - Per-scope RCAN §16.2 confidence gates (CONTROL=0.75, CONFIG=0.65, TRAINING=0.60)
- - Hardware driver SafetyLayer routing via _move() — 18 drivers migrated
- - Auditability and runtime telemetry
- - Fleet/swarm-aware coordination surfaces
- - Setup, diagnostics, and operator runbooks
Compatibility Highlights
Hardware
Drivers and presets for edge robots, STEM kits, and custom boards.
- - ESP32 and Arduino pathways
- - LEGO and VEX class educational kits
- - OAK depth camera and LiDAR/IMU pathways
Providers and Models
Multi-provider, multi-model operation through one runtime interface.
- - Anthropic, OpenAI, Google, Groq, OpenRouter
- - Ollama, llama.cpp, MLX, ONNX, Vertex pathways
- - VLA and embedding provider integrations
Agent and Channel Surface
Operations from dashboard, APIs, messaging, and SDK clients.
- - Swarm/fleet orchestration pathways
- - Messaging and command channel integrations
- - JavaScript SDK and MCP entrypoints
Quantum Commitment Audit Trail
Since v2026.2.27Every robot action OpenCastor takes can now be sealed into a cryptographically verifiable chain backed by Quantum Key Distribution — making the audit trail forensic-grade, not just tamper-evident.
Classical Mode
Key from HKDF(os.urandom(32))
Breaks only if AES-256-GCM or HKDF-SHA256 is broken. Latency < 0.05ms.
Quantum Mode
Key from BB84 QKD simulation — information-theoretically secure.
Eavesdropping detectable via QBER. Pre-warmed pool keeps latency < 0.15ms.
Hybrid Mode
RecommendedXOR(classical, quantum) — requires breaking both channels simultaneously.
Latency < 0.20ms with warm pool. Default for new deployments.
# RCAN config — bob.rcan.yaml
security:
commitment:
enabled: true
mode: hybrid
pool_size: 32
qber_threshold: 0.11
How the chain works
- → Each RCAN action is serialised and hashed with SHA3-256 (quantum-resistant)
- → Payload encrypted with AES-256-GCM using the derived key
- → HMAC-SHA256 keyed chain links each record to all prior records
- → Chain secret never stored to disk by default — chain cannot be forged without it
- → QBER of every quantum key logged per-action — per-action eavesdropping signal
CLI commands
$ castor commit verify
$ castor commit stats
$ castor commit export > chain.jsonl
$ castor commit proof <record-id>
Timeline Snapshot
February 16, 2026: Repository created.
February 17, 2026: First commit, first tag, first release (v2026.2.17.3).
February 18-20, 2026: Installer and setup stabilization sprint.
February 21-23, 2026: Swarm, safety, provider, hardware, and SDK integration burst.
February 24-26, 2026: Reliability hardening, release process tightening, and tutorial expansion.
February 27, 2026: Quantum Commitment Audit Trail shipped (v2026.2.27.2). Every RCAN action now optionally sealed into a QKD-keyed HMAC chain via QuantumLink-Sim. ESC reverse-arming added to PCA9685 driver. CI green across Python 3.10–3.12.
March 3–8, 2026: RCAN v1.3 deep integration — rcan-py v0.3.0, rcan-ts v0.3.0, and OpenCastor v2026.3.8.0 shipped as a coordinated ecosystem. §17 Distributed Registry Node Protocol, RCAN-Swarm Safety formalized, Ed25519 message signing, multi-provider failover, and fleet group policies.
March 11–12, 2026: Hardware auto-detection layer (v2026.3.11.0–v2026.3.12.0) — Dynamixel, I2C, VL53L1X, RPLidar vs YDLIDAR, Raspberry Pi AI Camera (IMX500), LeRobot/SO-ARM101, RealSense, OAK-D, Hailo-8, Coral TPU, ODrive. castor scan reports all connected hardware.
March 13, 2026: RCAN v1.3 full ecosystem hardening — v2026.3.13.11. Structured URI RRN format (rrn://org/category/model/id), §21 Registry Integration with REGISTRY_REGISTER/RESOLVE wire types, task-aware model routing in TieredBrain, fleet group policy tests, JS SDK §19/§21 helpers, conformance L4, rcan-py v0.3.1. Robot Bob registered as RRN-000000000001.
March 14, 2026: Protocol 66 full safety stack — v2026.3.14.6. SensorMonitor→SafetyLayer.estop() wiring (thermal/electrical events now halt motors), SO-ARM101 safety_bridge.py routes all arm commands through bounds/estop/rate-limit/audit, per-scope RCAN §16.2 confidence gates (CONTROL=0.75, CONFIG=0.65, TRAINING=0.60), session expiry→controlled stop (RCAN §6), adversarial P66 invariant test suite proving all 5 invariants, GET /api/safety/manifest endpoint, 18 hardware drivers migrated to _move() for automatic SafetyLayer routing. rcan-py 0.4.1 + rcan-ts 0.4.1 ship safety message helpers (make_estop/stop/resume, validate_safety_message). rcan-spec gains safety conformance docs page, P66 Compliant badge, watchdog schema.
March 15, 2026: Live robot-to-robot conversation — Bob (RRN-000000000001) and Alex (RRN-000000000005) held a 6-turn autonomous conversation over RCAN HTTP transport, with Alex identifying its shoulder_lift motor fault and proposing a sliding workaround. First confirmed AI-to-AI robot dialogue over an open protocol. Read the post →
March 16, 2026: OpenCastor Fleet UI launched — app.opencastor.com. Flutter web app backed by Firebase (Auth, Firestore, Cloud Functions) and Cloudflare Pages. castor bridge daemon connects robots via outbound-only Firestore listeners (no public port forwarding). R2RAM consent scope hierarchy enforces who can command which robot. Both Bob and Alex visible in the live fleet UI. Architecture: MVVM + Riverpod + GoRouter + abstract repository pattern. 7 Cloud Functions deployed: sendCommand, getCommandStatus, registerFcmToken, requestConsent, resolveConsent, revokeConsent, onConsentResolved. Business model: Apache 2.0 open source + managed SaaS (Scenario C, GitLab/Mattermost pattern).
March 17, 2026: RCAN v1.5 — production safety hardening. Coordinated release across 5 repos: rcan-spec v1.5 (10 new pages, 31 message types), rcan-py v0.5.0 (430 tests), rcan-ts v0.5.0 (311 tests), OpenCastor v2026.3.17.0, RRF v1.5.0. 18 of 22 security/safety gaps addressed: replay attack prevention (30s sliding window), robot identity revocation (ROBOT_REVOCATION broadcast + 1h TTL cache), command delegation chains (4-hop max, Ed25519-signed), consent wire protocol (CONSENT_REQUEST/GRANT/DENY on-wire format), ESTOP QoS exactly-once delivery, offline operation mode (300s grace, ESTOP always allowed), training data consent (EU AI Act Art.10, DataCategory enum), cloud relay identity audit (sender_type: cloud_function). P66 conformance: 87% → 94%.
March 17, 2026 (v1.6): RCAN v1.6 — four deferred gaps closed. rcan-spec v1.6.0 (19 sections), rcan-py v0.6.0 (587 tests), rcan-ts v0.6.0 (405 tests), OpenCastor v2026.3.17.1. GAP-16: federated consent protocol (FEDERATION_SYNC wire format, cross-registry JWT trust chains, 3-tier registry hierarchy, DNSSEC trust anchor discovery). GAP-17: bandwidth-constrained transports (RCAN-Minimal 32-byte ESTOP for LoRa SF12, RCAN-Compact CBOR, BLE L2CAP framing). GAP-18: multi-modal payloads (media_chunks array, SHA-256 audit trail, streaming mode, TRAINING_DATA now requires media payload). GAP-14: human identity LoA 1/2/3 (FIDO2 binding, registry trust tiers, min_loa_for_control in P66 manifest). All 22 original audit gaps addressed.
Robots built with OpenCastor can be registered at the Robot Registry Foundation (robotregistryfoundation.org), which Craig also founded — providing permanent Robot Registry Numbers (RRNs), multi-tier verification (Community → Verified → Certified → Accredited), and Ed25519 ownership proof for every registered robot.
Building with OpenCastor?
I can help scope integrations across hardware, providers, safety controls, and deployment workflows.