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.
chfritz•4h ago
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.
xmas123•38m ago
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?