DimOS
Python robotics runtime with agents, SLAM and teleop, no ROS required
License
Apache-2.0
Overview
DimOS is a Python runtime for building robot applications without ROS. Subsystems are Modules with typed In[] and Out[] streams; blueprints wire them together with autoconnect(), which matches streams by name and message type and can be composed, remapped, or given a different transport. On top of that sit the capabilities most stacks assemble by hand: SLAM and costmap navigation with A* planning and frontier exploration, perception with detectors and VLMs, a spatio-temporal memory that localises objects over time, and agents that run as native modules subscribing to any stream. The dimos CLI runs blueprints, follows logs, sends an agent a command, and calls skills over MCP. Replay and MuJoCo simulation modes mean the quickstarts work with no robot on the desk.
The catalogue's agentic-robotics entries almost all sit on top of ROS 2 — RAI, AgenticROS, ROS-MCP and the rest treat ROS as the substrate and add a language layer. DimOS makes the opposite bet: it replaces the middleware too. Modules, typed streams, blueprints and its own transports (LCM, WebRTC, a hosted broker) are a complete alternative to ROS nodes, topics and launch files, written in Python with Rust and C++ where speed matters. Whether that bet pays off is exactly the question a reader should weigh, and the repository gives enough to judge it: 4,500 stars, daily commits, a dozen named contributors, and a hardware matrix that is candid about what is stable.
That matrix is the most useful page in the README. Unitree's Go2 is the one platform marked stable; the G1 humanoid, xArm and AgileX Piper are beta; MAVLink and DJI are alpha; the B1 and force-torque sensing are experimental. Installation is similarly graded — Ubuntu 22.04 and 24.04 are the supported path, NixOS and general Linux are not CI-tested, macOS is alpha. A project that labels its own support tiers honestly is easier to evaluate than one that lists every platform as equal, and the whole repository carries a pre-release beta banner.
dimTELE, the teleoperation half, deserves a separate note. The robot dials out to a hosted broker so no inbound ports need opening, and an operator drives from a browser or a Quest headset over WebRTC. It works well and it is the clearest demonstration of the stack, but it requires an account and an API key from Dimensional's own console. The client and transport code are in the Apache-2.0 repository; the broker on the other end is not.
Why it matters
Every other agentic robotics framework worth listing assumes ROS 2 and builds a language layer on top. DimOS is the one that asks whether the middleware itself should be replaced, and it is far enough along to be judged rather than speculated about: typed Python streams instead of topics, a working navigation and memory stack, agents as first-class modules, and replay data so the claims can be checked without hardware. Whether or not you adopt it, it is the strongest existing argument that the ROS-shaped default is a choice and not a law.
Problem it solves
Building a robot application normally means adopting ROS 2 and everything that comes with it — the build system, the message definitions, the launch files — before writing any behaviour. DimOS supplies the same layer as ordinary Python: typed streams between modules, a CLI to run and inspect them, and navigation, perception, memory and agent integration already built on it.
Key takeaways
- A Python robotics runtime that deliberately does not use ROS — Modules with typed In[]/Out[] streams, wired by autoconnect() into composable blueprints
- Ships navigation (SLAM, costmaps, A* planning, frontier exploration), perception, and a spatio-temporal memory that tracks where objects were and when
- Agents are native modules with MCP tools, so dimos agent-send "explore the room" and dimos mcp call move_to are first-class CLI verbs
- Replay and MuJoCo simulation modes run the featured quickstarts with no robot attached
- The hardware matrix grades its own support honestly: Unitree Go2 stable, G1 and xArm beta, MAVLink and DJI alpha, B1 experimental
- dimTELE gives browser and Quest teleop over WebRTC by dialling out to a broker, so no inbound ports on the robot's network
- Apache-2.0 from Dimensional Inc., with roughly a dozen regular contributors and commits landing daily
Who it is for
- Python developers who want to write robot behaviour without first learning ROS 2
- Teams working with Unitree quadrupeds or humanoids looking for a stack above the vendor SDK
- Anyone building LLM or MCP agents that need to subscribe to real sensor streams rather than call a REST endpoint
- Operators who need remote teleoperation through a NAT without opening inbound ports
- Researchers comparing middleware designs who want a serious non-ROS reference to argue with
Limitations
- The repository labels itself pre-release beta and PyPI is still on 0.0.x, so interfaces should be expected to move
- Roughly 700 issues are open — an active project, but a large backlog to read before committing
- Not using ROS cuts you off from the ROS ecosystem: no existing drivers, no Nav2, no MoveIt, no rosbag, and whatever the project has not built you build yourself
- Hardware support is narrow and mostly unstable — Unitree's Go2 is the single platform marked stable, and everything else is beta, alpha or experimental
- dimTELE's broker is a hosted Dimensional service needing an account and API key; the Apache-2.0 repository gives you the client, not the other end
- Ubuntu 22.04/24.04 is the tested path; macOS is alpha and general Linux is explicitly not CI-tested
- This is a company's product roadmap as much as a community project, and the open repository and the hosted console are developed together