Every robot manufacturer ships a different SDK and a different protocol. A Boston Dynamics Spot speaks nothing like a Universal Robots arm. Every team building on top of robots rewrites the same integration layer from scratch. This is a massive tax on the industry.
RoboAPI is a unified API layer that abstracts all of that into one clean developer experience. One SDK, one API key, any robot — simulated or real hardware.
You can connect a simulated robot and read live telemetry in under 5 minutes:
pip install fastapi uvicorn roslibpy
uvicorn api.main:app --reload
curl -X POST localhost:8000/v1/robots/connect -d '{"robot_id":"bot-01","brand":"simulated"}'
curl localhost:8000/v1/robots/bot-01/sense
The architecture is pluggable — each robot brand is a separate adapter implementing a common interface (like a payment gateway in Stripe). Adding a new brand means one file.
Currently supports: simulated robots and any ROS2 robot. Boston Dynamics and Universal Robots adapters are next.
Would love feedback from anyone working in robotics — especially on the API design and what's missing for real-world use.
The problem is not that there is no standard -- there is, it's called ROS. The problem is that manufacturers are not interested in opening their robots up to that degree.
Also, REST is a terrible idea for interacting with robots. REST is call-response based. But with Robots a pub/sub (like ROS or MQTT) or a blackboard data architecture (like what we used in Transitive Robotics) is much more efficient and natural.
Fair points, and appreciate the pushback.
On ROS being the standard — you're right that ROS exists, but adoption outside research/academia is still fragmented. Boston Dynamics, Universal Robots, and most industrial arms don't natively speak ROS — teams still write glue code. RoboAPI is trying to be that glue as a managed layer rather than a DIY problem.
On REST being wrong for robots — completely agree on the pub/sub point. REST is the entry point for developer familiarity but RoboAPI already has WebSocket streaming for telemetry. The next step is moving commands to pub/sub too. Interesting that you mention Transitive Robotics — the blackboard pattern is something I've been thinking about for the fleet layer.
What would the ideal architecture look like from your experience? MQTT for commands, WebSocket for telemetry, REST only for configuration?