OpenCastor is an open-source Python runtime that connects AI models to robot hardware through a single YAML config file. You pick your brain (Claude, Gemini, GPT, or a local model via Ollama), pick your body (Raspberry Pi, Jetson, Arduino, Dynamixel servos), and it handles the wiring between them.
Origin story: I've been building ContinuonAI — a cognitive architecture for personal robots with on-device learning, memory, and safety systems. Deep stuff: HOPE dynamics, episode-based training, cloud pipelines. Along the way I kept hitting the same problem: every time I wanted to test a new AI model or swap hardware, I was rewriting integration code. The "connect brain to body" layer was always bespoke.
OpenCastor is that layer, extracted and generalized. It's modeled after the approach OpenClaw takes with personal AI assistants — practical, runs on your own hardware, minimal friction — but applied to robotics.
What it does:
- Define your robot in an RCAN config file (an open standard for robot capability descriptions)
- Swap AI providers by changing one YAML field — no code changes
- Built-in drivers for common hardware (PCA9685, Dynamixel, GPIO, serial)
- Safety validation layer sits between the AI and your motors — actions are checked against physical constraints before execution
- Continuous perception-action loop: observe → reason → act → repeat
- Optional messaging integration (WhatsApp, Telegram, Discord) to control your robot from your phone
The wizard walks you through model selection and hardware setup. Works on macOS, Linux (including Pi), and Windows. Pre-made config presets exist for popular ~$50 robot kits (Waveshare, Adeept, SunFounder) so you can get something moving quickly.
There's also castor demo which runs a simulated robot with no hardware or API keys needed, if you just want to see what the runtime does.
Where it's at:
Still early. 1,286 tests, the core loop is solid, but there's plenty of rough edges. I'd love feedback on the RCAN config format, the driver abstraction, and whether the safety layer is paranoid enough (or not enough). The project came out of real needs building ContinuonAI and I'm hoping it's useful to others working in the same space.
github.com/craigm26/OpenCastor
Happy to answer questions about the architecture, the ContinuonAI connection, or how it compares to ROS/other frameworks.
Origin story: I've been building ContinuonAI — a cognitive architecture for personal robots with on-device learning, memory, and safety systems. Deep stuff: HOPE dynamics, episode-based training, cloud pipelines. Along the way I kept hitting the same problem: every time I wanted to test a new AI model or swap hardware, I was rewriting integration code. The "connect brain to body" layer was always bespoke.
OpenCastor is that layer, extracted and generalized. It's modeled after the approach OpenClaw takes with personal AI assistants — practical, runs on your own hardware, minimal friction — but applied to robotics.
What it does:
- Define your robot in an RCAN config file (an open standard for robot capability descriptions) - Swap AI providers by changing one YAML field — no code changes - Built-in drivers for common hardware (PCA9685, Dynamixel, GPIO, serial) - Safety validation layer sits between the AI and your motors — actions are checked against physical constraints before execution - Continuous perception-action loop: observe → reason → act → repeat - Optional messaging integration (WhatsApp, Telegram, Discord) to control your robot from your phone
Install and try it:
curl -fsSL opencastor.com/install | bash castor wizard castor run --config my_robot.rcan.yaml
The wizard walks you through model selection and hardware setup. Works on macOS, Linux (including Pi), and Windows. Pre-made config presets exist for popular ~$50 robot kits (Waveshare, Adeept, SunFounder) so you can get something moving quickly.
There's also castor demo which runs a simulated robot with no hardware or API keys needed, if you just want to see what the runtime does.
Where it's at:
Still early. 1,286 tests, the core loop is solid, but there's plenty of rough edges. I'd love feedback on the RCAN config format, the driver abstraction, and whether the safety layer is paranoid enough (or not enough). The project came out of real needs building ContinuonAI and I'm hoping it's useful to others working in the same space.
github.com/craigm26/OpenCastor
Happy to answer questions about the architecture, the ContinuonAI connection, or how it compares to ROS/other frameworks.