Introducing OpenCastor: The Universal Runtime for Embodied AI

Every robotics project starts the same way. You pick a brain (OpenAI? Claude? a local model?), wire it to a camera, bolt on motor control, and spend three weeks debugging why your servo library conflicts with your inference pipeline. Then you switch models and start over.

OpenCastor exists so nobody has to do that again.

What Is OpenCastor?

OpenCastor is a universal runtime for embodied AI — an open-source Python framework that connects any AI model to any robot hardware through a single YAML configuration file. One config describes your robot’s brain, body, and behavior. The framework handles the rest: provider abstraction, safety enforcement, motor control, camera pipelines, and messaging.

curl -sL opencastor.com/install | bash

That’s the entire install. A wizard walks you through provider selection, authentication, model choice, and hardware detection. Five minutes from curl to a running robot brain.

The Origin Story

OpenCastor grew out of ContinuonAI — my home lab project building autonomous robots on Raspberry Pi hardware. ContinuonAI validated the core thesis: a world-model architecture with hierarchical memory can operate on consumer-grade hardware in real environments. But the tooling was bespoke. Every time I changed providers, added a camera, or reconfigured safety bounds, I was rewriting infrastructure instead of building intelligence.

The insight was simple: the hard part of embodied AI isn’t the model — it’s everything between the model and the motors. Provider authentication, frame encoding, action parsing, safety interlocks, graceful shutdown, watchdog timers, hardware abstraction. That’s what OpenCastor handles.

The safety architecture draws directly from ContinuonAI’s work on robot constitutions, RCAN (Robot Configuration and Autonomy Notation) spec compliance, and the principle that safety modules should never be optional — they’re structural.

The Tiered Brain: Why It Costs $0 to Start

The most common question about AI robotics is cost. Cloud API calls at 1Hz add up fast. OpenCastor solves this with a three-layer brain architecture:

Layer 0 — Reactive (< 1ms, $0) Rule-based safety. Blank frame? Wait. Obstacle at 30cm? Stop. Battery critical? Halt. No AI needed, no latency, no cost. On hardware with a Hailo-8 NPU, this layer also runs YOLOv8 object detection at ~250ms — 80 COCO classes of obstacle awareness without a single API call.

Layer 1 — Fast Brain (~500ms, $0) The primary perception-action loop. By default, this runs Qwen2.5-VL-7B — an open-source vision-language model hosted for free on HuggingFace’s Inference API. It sees through the camera, understands the scene, and produces JSON actions. Sub-second response times, zero cost.

Layer 2 — Planner (~10-15s, pay-per-use) Complex reasoning, scene understanding, multi-step planning. Runs every 15 ticks or when the fast brain signals uncertainty. This is where Claude, GPT-4o, or Gemini Pro earn their keep — but only when needed. If you have a Claude Max subscription, the planner runs on your existing plan with zero marginal cost via OAuth.

The wizard presents five cost-tier presets:

Tier	Monthly Cost	Configuration
Free & Open Source	$0	HuggingFace API + Ollama fallback
Budget Smart	~$0	HF primary + Gemini Flash-Lite (free tiers)
Balanced	~$5	HF primary + Claude planner
Performance	~$10-20	Gemini Flash primary + Claude planner
Maximum Intelligence	$$$	Claude primary + Claude Opus planner

Most users will never need to leave the free tier for development and testing.

Seven Providers, One Interface

OpenCastor abstracts provider differences behind a single think(image, instruction) → action interface:

Anthropic — Claude 4 family (API key or OAuth setup-token)
Google — Gemini 2.5 Flash, Flash-Lite, Pro
OpenAI — GPT-4o, o1
HuggingFace — Any Hub model (Qwen-VL, Llama 4, etc.) via free Inference API
Ollama — Any GGUF model, local inference
llama.cpp — Direct GGUF loading or Ollama’s OpenAI-compatible API
Claude OAuth — Max/Pro subscription users, zero per-token billing

Switching providers is a one-line YAML change. No code modifications, no redeployment.

Hardware Support

The framework runs on anything with Python 3.10+, but it’s optimized for the Raspberry Pi ecosystem:

Hailo-8 AI Hat — On-device YOLOv8 for reactive obstacle avoidance
OAK-D / OAK-D Lite — Stereo depth camera via DepthAI v3 (RGB + depth)
PCA9685 — 16-channel PWM for servo and motor control
CSI cameras — Via picamera2
USB cameras — Via OpenCV
I2C sensors — IMU, environmental, distance sensors

Hardware detection is automatic. The installer scans for connected devices and configures drivers accordingly.

Safety Is Structural

OpenCastor doesn’t treat safety as a feature flag. Safety modules are always present, always active:

Physical bounds enforcement — Speed limits, workspace boundaries, torque caps
Anti-subversion detection — Monitors for prompt injection attempts in model outputs
Work authorization — RCAN role-based access (Owner, Leasee, Observer)
Tamper-evident audit log — Cryptographic chain of every action and decision
E-stop — Hardware and software kill switches with guaranteed motor shutdown
Rate limiting — Prevents runaway API calls and action floods
Watchdog timer — Auto-stops if the brain becomes unresponsive

This design is informed by the ContinuonAI safety audit — a 520-line analysis mapping Ring 0 kernel invariants, RCAN spec requirements, and gap analysis against production standards.

Community Hub

OpenCastor includes a built-in recipe system for sharing robot configurations:

castor hub browse          # See available recipes
castor hub install <name>  # Install a community recipe
castor hub share           # Package and share your config

Recipes are YAML configs + metadata packaged for easy distribution. Want to share your Raspberry Pi rover setup? castor hub share creates a pull request on the community repository.

How to Contribute

OpenCastor is Apache 2.0 licensed and welcomes contributions:

Code: The repository is at github.com/craigm26/OpenCastor. We use conventional commits, ruff for formatting, and every PR runs against Python 3.10, 3.11, and 3.12. The test suite has 1,322 tests covering providers, safety modules, hardware abstraction, and the wizard.

Recipes: Share your robot configuration via castor hub share --submit or the recipe submission template.

Providers: Adding a new AI provider means implementing a single class with a think() method. The HuggingFace provider is a good reference at ~160 lines.

Documentation: The docs live alongside the code. Improvements to guides, examples, and translations are always welcome.

Bug reports: Open an issue or run castor doctor to generate a diagnostic report.

Community

GitHub: github.com/craigm26/OpenCastor — Stars, issues, and PRs
PyPI: pip install opencastor — 36,758 lines of battle-tested code
Website: opencastor.com — Documentation and guides
Discord: Join the community for support, demos, and discussion

What’s Next

The roadmap includes:

RCAN conformance test suite — Formal validation against the specification
Hailo LLM inference — When NPU support expands beyond vision models
Simulation bridge — Gazebo/Isaac Sim integration for sim-to-real transfer
Multi-robot coordination — Fleet management via RCAN role hierarchy
Edge training — On-device fine-tuning from operational data

Getting Started

# Install (Linux, macOS, Windows, Docker)
curl -sL opencastor.com/install | bash

# Or via pip
pip install opencastor

# Run the wizard
castor wizard

# Start your robot
castor run --config my_robot.rcan.yaml

# Check system health
castor doctor

The framework is production-ready, the community is forming, and the mission is clear: make embodied AI accessible to everyone with a Raspberry Pi and a dream.

Build something.