Announcing Gorai! A Modern Robotics Framework

gorai / robotics / go / golang / nats / ai / open-source / emerging-robotics

I’ve been teasing this for a while. Time to stop teasing. Meet Gorai — a modern, open-source robotics framework written in Go.

If you read my Why Go for Robotics? post, or my rant on Agentic Python, you already know where my head’s been at. I kept asking the same question: why not do foundational robotics work in Go? Well, I’ve been building. Gorai is the answer.

What Is Gorai?

Here’s the one-liner: a robot is a distributed system — so build it like one.

Even a single robot is really a pile of microcontrollers, single-board computers, sensors, and motors all talking to each other. Most frameworks consider that to be one monolithic blob. Gorai doesn’t. It treats every sensor as a resource you read and every actuator as a tool you call — discoverable services on a message mesh, addressed by name, not by hardwired cables.

If “resources and tools” sounds like how AI agents already think about the world — yes. That’s the whole point. Gorai speaks capability-model semantics natively over NATS, so the same interface a human uses to drive the robot is the interface an AI agent uses to drive it tomorrow. No rewrite. No firmware surgery. Same mesh.

And because it’s Go, the whole thing compiles to one static binary with NATS embedded inside it. No containers. No K8s. No pip, no venv, no wheel lottery. You scp a single file to a Raspberry Pi or an Orange Pi and run it. That’s the deploy story. That’s it.

  • Sensors as resources, actuators as tools — an AI-agent-ready capability mesh
  • Single static binary, embedded NATS, zero external services
  • Composite robots — one logical robot can span a rover, a drone, a sensor mast, all joined at runtime
  • Action logs and replay as first-class primitives, because autonomy without replay is folklore
  • Safety enforced at the capability node, not trusted to the agent

Now, before you start yelling: yes, you can extend beyond the one binary (using NATS, of course!). And yes, you can move real-time/latency critical components onto a microcontroller and join that to the mesh using gorai-gsp to do the serialization. There’s even an example firmware for the RP2040. But that’s a subject for another post!

To be clear about scope: I’m not trying to replace ROS 2. Different tool, different crowd. Gorai is for software-first folks who want to build robots the way we build modern distributed systems — and who want AI to be a first-class citizen, not a bolt-on.

See It Drive: the PiCar-X Example

Talk is cheap. So there’s a working reference robot you can build today: gorai-gopicar-example.

The PiCar-X is a little four-wheeled robot car kit from SunFounder — steering servo, drive motor, an ultrasonic distance sensor, a line/cliff sensor, and a camera on a pan/tilt mount. It’s a genuinely great little “better an a plastic toy” robot, and the best part is you can just buy one: it’s about $90 on Amazon — minus the Raspberry Pi, which you supply yourself. No custom PCBs, no soldering iron, no waiting on a fab. Order it, assemble it with a Pi, and you’ve got real hardware to run Gorai on.

Take a SunFounder PiCar-X, cross-compile the binary, scp it over, and run:

./picarx run robot.json

One command spins up the robot. I has an embedded NATS server, opens the hardware, and serves a web control UI at http://<pi>:8080/. Drive it with the arrow keys. Pan and tilt the camera. Watch live telemetry stream back. Hit spacebar to stop the motors, and ’s’ for an emergency stop.

Here’s the beautiful part: the browser is just another agent on the mesh. The exact same interface a planning agent or a fleet coordinator would use. The car is teleoperable today and agent-drivable tomorrow — with zero changes to the capability layer. That’s not a slide. That’s running code.

And it’s safe by construction: a watchdog stops the car within about half a second if control input drops, the e-stop latches until you clear it, cliff detection keeps it off the edge of your desk, and every command gets clamped to the servo and throttle limits. All of that lives in the component, not the UI — because you never trust the thing sending commands.

But wait - what about using Claude Code?

Of course. Why not develop directly on the Pi? That’s how I built this robot. Claude runs fine on a Pi. You should try it!

Let an Agent Poke at It: gorai-mcp

Now here’s where it gets fun. Because Gorai already models the world as resources and tools, exposing it to an LLM is almost embarrassingly natural. That’s what gorai-mcp is: an MCP server that bridges your robot’s mesh to any MCP client. Point Claude at it and the model can see the robot — read the sensors as resources, call the actuators as tools — no glue code, no custom shim. It just shows up as capabilities the agent can reason about.

It’s genuinely magic the first time you watch a model discover your robot and start asking it questions.

But — and I want to be crystal clear here — you don’t want to control the robot for real with this. It is way too slow. Think about the round trip: your command goes through the MCP transport, up to a model, waits on inference, comes back down. That’s hundreds of milliseconds to seconds per decision. That is fine for “what do you see?” or “plan me a route.” It is absolutely, categorically not fine for the tight control loop that keeps a moving car out of the wall. Real-time control stays where it belongs: down on the node, in typed Go, running at mesh speed with the safety watchdogs I mentioned above.

So think of gorai-mcp as the robot’s conversation layer, not its reflexes. High-level reasoning and experimentation up top; fast, deterministic control down low. Don’t mix those up, or you’ll drive a very smart robot straight off your desk.

This Is Emerging Robotics

Gorai is the foundation of what I’m building for Emerging Robotics: Open-Source Robotics for the Real World. The PiCar-X is the friendly “hello, world.” But the framework is aimed at real robots doing real jobs.

Which brings me to the thing I probably shouldn’t tell you about yet…

One More Thing… 🌊

There’s a boat.

Multi-rotor drones democratized the sky — fleet management, autonomous waypoints, modular payloads, all at hobbyist prices. So why is the water still locked behind $50,000 price tags, proprietary hardware, and industrial gatekeeping?

Meet SURF — an open-source, open-hardware, 3D-printable autonomous surface drone. Radically open: every CAD file, every line of code, every line of the BOM. Modular by design. Fleet-ready out of the box. It self-rights if it capsizes. It fits in your car trunk. And it runs on Gorai.

Surface Unmanned Reconnaissance Frame. Or maybe we just like the ocean. You decide. And yes, we will use this for recording whale song this winter!

It’s about to go in the water for its first operational testing. I’m not going to say more yet — but keep an eye on this space, because when SURF gets wet, you’ll hear about it.

Try It

Gorai and the PiCar-X example are open source, right now:

Build the car. Drive it from your browser. Then imagine an agent holding the same controls. That’s the future I’m building toward — reliable, predictable, single-binary robotics that’s ready for AI. It brings the ease of Arduino, but kicked up a level in capability, and lets you do real robotics without having to learn the complexity of ROS 2.

If you build something with it, or you just want to argue about it, drop me a note on LinkedIn. And pay it forward.

 Share!