DimOS

Python-Robotik-Laufzeit mit Agenten, SLAM und Teleoperation — ohne ROS

Lizenz

Apache-2.0

Überblick

DimOS ist eine Python-Laufzeitumgebung für Roboteranwendungen, die ohne ROS auskommt. Teilsysteme sind Module mit typisierten In[]- und Out[]-Strömen; Blueprints verdrahten sie mit autoconnect(), das Ströme nach Name und Nachrichtentyp zusammenführt und sich komponieren, umbenennen oder auf einen anderen Transport umstellen lässt. Darauf sitzen die Fähigkeiten, die die meisten Stacks von Hand zusammensetzen: SLAM- und Costmap-Navigation mit A*-Planung und Frontier-Exploration, Wahrnehmung mit Detektoren und VLMs, ein raumzeitliches Gedächtnis, das Objekte über die Zeit verortet, und Agenten, die als native Module laufen und jeden Strom abonnieren können. Die dimos-CLI startet Blueprints, folgt Logs, schickt einem Agenten einen Befehl und ruft Skills über MCP auf. Replay- und MuJoCo-Simulationsmodus sorgen dafür, dass die Quickstarts ohne Roboter auf dem Tisch funktionieren.

Die agentischen Robotikeinträge dieses Katalogs sitzen fast alle auf ROS 2 auf — RAI, AgenticROS, ROS-MCP und die übrigen behandeln ROS als Substrat und legen eine Sprachschicht darüber. DimOS setzt auf das Gegenteil: Es ersetzt auch die Middleware. Module, typisierte Ströme, Blueprints und eigene Transporte (LCM, WebRTC, ein gehosteter Broker) sind eine vollständige Alternative zu ROS-Knoten, -Topics und -Launch-Dateien, geschrieben in Python, mit Rust und C++ dort, wo Tempo zählt. Ob diese Wette aufgeht, ist genau die Frage, die man abwägen sollte, und das Repository liefert genug zur Beurteilung: 4.500 Sterne, tägliche Commits, ein Dutzend namentliche Mitwirkende und eine Hardware-Matrix, die offen sagt, was stabil ist.

Diese Matrix ist die nützlichste Seite der README. Unitrees Go2 ist die einzige als stabil markierte Plattform; der Humanoide G1, xArm und AgileX Piper sind Beta; MAVLink und DJI sind Alpha; B1 und Kraft-Momenten-Sensorik sind experimentell. Die Installation ist ähnlich abgestuft — Ubuntu 22.04 und 24.04 sind der unterstützte Weg, NixOS und allgemeines Linux sind nicht CI-getestet, macOS ist Alpha. Ein Projekt, das seine eigenen Supportstufen ehrlich benennt, lässt sich leichter bewerten als eines, das alle Plattformen gleichrangig auflistet — und über dem gesamten Repository steht ein Pre-Release-Beta-Banner.

dimTELE, die Teleoperationshälfte, verdient eine eigene Anmerkung. Der Roboter wählt sich zu einem gehosteten Broker heraus, sodass keine eingehenden Ports geöffnet werden müssen, und eine Bedienperson steuert aus dem Browser oder einem Quest-Headset über WebRTC. Es funktioniert gut und ist die klarste Demonstration des Stacks, verlangt aber ein Konto und einen API-Schlüssel aus Dimensionals eigener Konsole. Client und Transportcode liegen im Apache-2.0-Repository; der Broker am anderen Ende nicht.

Warum es wichtig ist

Jedes andere nennenswerte agentische Robotik-Framework setzt ROS 2 voraus und baut eine Sprachschicht darauf. DimOS ist das einzige, das fragt, ob nicht die Middleware selbst ersetzt gehört — und es ist weit genug, um beurteilt statt bloß bespekuliert zu werden: typisierte Python-Ströme statt Topics, ein funktionierender Navigations- und Gedächtnisstack, Agenten als Module erster Klasse und Replay-Daten, mit denen sich die Behauptungen ohne Hardware prüfen lassen. Ob man es übernimmt oder nicht: Es ist das derzeit stärkste Argument dafür, dass der ROS-förmige Standard eine Wahl ist und kein Gesetz.

Welches Problem es löst

Eine Roboteranwendung zu bauen heißt normalerweise, erst ROS 2 samt allem Drumherum zu übernehmen — Buildsystem, Nachrichtendefinitionen, Launch-Dateien — bevor auch nur eine Verhaltenszeile entsteht. DimOS liefert dieselbe Schicht als gewöhnliches Python: typisierte Ströme zwischen Modulen, eine CLI zum Starten und Inspizieren und darauf bereits aufgebaute Navigation, Wahrnehmung, Gedächtnis und Agentenanbindung.

Wichtigste Punkte

• Eine Python-Robotiklaufzeit, die bewusst kein ROS verwendet — Module mit typisierten In[]/Out[]-Strömen, von autoconnect() zu komponierbaren Blueprints verdrahtet
• Bringt Navigation (SLAM, Costmaps, A*-Planung, Frontier-Exploration), Wahrnehmung und ein raumzeitliches Gedächtnis mit, das festhält, wo Objekte wann waren
• Agenten sind native Module mit MCP-Werkzeugen, daher sind dimos agent-send "explore the room" und dimos mcp call move_to CLI-Verben erster Klasse
• Replay- und MuJoCo-Simulationsmodus führen die vorgestellten Quickstarts ganz ohne angeschlossenen Roboter aus
• Die Hardware-Matrix benennt die eigenen Supportstufen ehrlich: Unitree Go2 stabil, G1 und xArm Beta, MAVLink und DJI Alpha, B1 experimentell
• dimTELE bietet Browser- und Quest-Teleoperation über WebRTC, indem sich der Roboter zum Broker herauswählt — keine eingehenden Ports im Roboternetz nötig
• Apache-2.0 von Dimensional Inc., mit rund einem Dutzend regelmäßiger Mitwirkender und täglich landenden Commits

Für wen

• Python-Entwicklerinnen und -Entwickler, die Roboterverhalten schreiben wollen, ohne zuerst ROS 2 zu lernen
• Teams mit Unitree-Vierbeinern oder -Humanoiden, die einen Stack oberhalb des Hersteller-SDK suchen
• Alle, die LLM- oder MCP-Agenten bauen, die echte Sensorströme abonnieren statt einen REST-Endpunkt aufzurufen
• Betreiber, die ferngesteuerte Teleoperation durch ein NAT brauchen, ohne eingehende Ports zu öffnen
• Forschende, die Middleware-Entwürfe vergleichen und eine ernstzunehmende Nicht-ROS-Referenz zum Widersprechen suchen

Einschränkungen

• Das Repository bezeichnet sich selbst als Pre-Release-Beta und PyPI steht noch bei 0.0.x — mit Schnittstellenänderungen ist zu rechnen
• Rund 700 Issues sind offen — ein aktives Projekt, aber ein großer Rückstand, den man vor einer Festlegung lesen sollte
• Kein ROS zu nutzen schneidet vom ROS-Ökosystem ab: keine vorhandenen Treiber, kein Nav2, kein MoveIt, kein rosbag — was das Projekt nicht gebaut hat, baut man selbst
• Die Hardwareunterstützung ist schmal und überwiegend instabil — Unitrees Go2 ist die einzige als stabil markierte Plattform, alles andere ist Beta, Alpha oder experimentell
• Der Broker von dimTELE ist ein gehosteter Dimensional-Dienst mit Konto und API-Schlüssel; das Apache-2.0-Repository liefert den Client, nicht die Gegenstelle
• Ubuntu 22.04/24.04 ist der getestete Weg; macOS ist Alpha und allgemeines Linux ausdrücklich nicht CI-getestet
• Das ist ebenso die Produkt-Roadmap eines Unternehmens wie ein Community-Projekt — offenes Repository und gehostete Konsole werden gemeinsam entwickelt