OM1: Go-Runtime für Roboter-Agenten mit ROS2-, Zenoh- und CycloneDDS-Anbindung

Welches Problem OM1 adressiert und für wen es gedacht ist

Ein Agent, der Kamera, Mikrofon und LIDAR verarbeitet und daraus Bewegung oder Sprache ableitet, besteht aus vielen Teilen, die normalerweise pro Roboter neu verdrahtet werden. OM1 setzt genau dort an: Es beschreibt sich selbst als modulare AI-Runtime, mit der sich multimodale Agenten über digitale Umgebungen und physische Roboter hinweg erstellen und deployen lassen. Genannt werden Humanoide, Telefon-Apps, Quadrupeden, Bildungsroboter wie der TurtleBot 4 sowie Simulatoren wie Gazebo und Isaac Sim. Der erklärte Anspruch ist, Roboter leicht aufrüstbar und für unterschiedliche physische Formfaktoren rekonfigurierbar zu machen. Adressaten sind damit Entwicklerteams, die dieselbe Agentenlogik auf mehr als einer Plattform betreiben wollen, und nicht jemand, der einen einzelnen Roboter mit fest verdrahteter Steuerung baut. Der Preis für diese Austauschbarkeit ist eine Laufzeit, die zwischen Sensor, Modell und Aktor sitzt und selbst konfiguriert, gebaut und aktualisiert werden muss.

Der Wechsel von Python zu Go und was das für den Code bedeutet

OM1 wurde ursprünglich in Python gebaut. Die Go-Runtime ist eine neuere, auf Leistung ausgerichtete Implementierung. Als Gründe nennt das Repository geringere Latenz, effizientere Nebenläufigkeit, einen kleineren Speicherbedarf auf Edge-Geräten und die einfachere Auslieferung als einzelne Go-Binary, in die die Zenoh-C-Bibliothek eingebettet daneben liegt. Das ist keine reine Portierung mit identischem Funktionsumfang: Die Go-Runtime deckt laut README die Kern-Pipeline des Agenten ab, mehrere Fähigkeiten der Python-Runtime befinden sich noch in Entwicklung. Für neue Projekte empfiehlt das Projekt selbst die Go-Variante. Die Python-Version liegt im Branch python und ist als deprecated gekennzeichnet, sie wird nicht mehr gepflegt. Wer heute auf Python setzt, plant also gegen einen Stand, für den es keine Updates mehr geben soll. Umgekehrt heißt das: Wer eine der noch fehlenden Fähigkeiten braucht, findet sie möglicherweise nur in einem Branch, der nicht weiterentwickelt wird. Diese Spannung ist die wichtigste offene Frage vor einem Einsatz.

Eingang, Modell, Aktion: die Pipeline im Aufbau

Das README beschreibt die Verarbeitung als Abfolge von Eingabe, LLM und Aktion. Als Eingaben nennt es Web-Daten, Social-Media-Inhalte, Kamerafeeds und LIDAR. Auf der Ausgabeseite stehen Bewegung, autonome Navigation und natürliche Konversation. Dazwischen sitzen vortkonfigurierte Endpunkte für Text-to-Speech, mehrere LLMs von OpenAI, xAI, DeepSeek, Anthropic, Meta, Gemini, NearAI und Ollama für den lokalen Betrieb sowie mehrere Visual Language Models. Der konkrete Datenfluss wird im Repository über ein Architekturbild gezeigt, nicht über eine textliche Spezifikation. Belastbar ist damit vor allem die Struktur: Sensoren und Datenquellen sind austauschbare Eingänge, die Modellaufrufe laufen über benannte Endpunkte, und die Aktionen werden über Plugins an die Hardware gegeben. Für die Beobachtung dieser Kette liefert das Projekt einen vorkonfigurierten Prometheus- und Grafana-Stack mit, der Metriken wie LLM- und ASR-Latenzen in Echtzeit erfassen soll. Das ist der Teil, der in vielen vergleichbaren Projekten fehlt und hier ab Werk mitkommt.

Hardware-Anbindung über Plugins statt fester Treiber

Neue Hardware wird über Plugins angebunden, die entweder API-Endpunkte oder konkrete Roboterhardware bedienen. Als Protokolle erscheinen ROS2, Zenoh und CycloneDDS. Für alle neuen Entwicklungen empfiehlt das Projekt Zenoh. Diese Empfehlung ist mehr als eine Präferenz: Sie legt fest, in welche Richtung die Plugin-Arbeit künftig geht, und wer auf CycloneDDS oder ROS2 setzt, bewegt sich in einem Pfad, der im README nur noch als unterstützte Alternative auftaucht. Praktisch relevant ist zudem, dass die Zenoh-Anbindung über die C-Bibliothek libzenohc läuft. Das erklärt, warum die ausgelieferten Archive diese Bibliothek enthalten und warum unter macOS und Linux vor dem Start DYLD_LIBRARY_PATH beziehungsweise LD_LIBRARY_PATH auf das Arbeitsverzeichnis gesetzt werden müssen. Eine reine Go-Binary ist OM1 damit nicht, auch wenn das README die Auslieferung als einzelne Binary als Vorteil nennt. Die C-Abhängigkeit bleibt Teil des Deployments.

Inbetriebnahme: Abhängigkeiten, Schlüssel, Startbefehl

Der schnellste Weg führt über den conversation-Agenten, der Webcam und Mikrofon nutzt und über Sprache antwortet. Zuerst stehen Systemabhängigkeiten an. Unter macOS sind das brew install portaudio ffmpeg, unter Linux sudo apt-get update gefolgt von sudo apt-get install -y portaudio19-dev ffmpeg pkg-config. Danach gibt es zwei Wege. Fertige Binaries liegen für linux-amd64, linux-arm64, darwin-arm64 und darwin-amd64 vor, eine Go-Installation ist dafür nicht nötig. Nach dem Entpacken genügt chmod +x om1 und der Start mit ./om1 -config ./config/conversation.json5, wobei vorher unter macOS export DYLD_LIBRARY_PATH="$PWD:$DYLD_LIBRARY_PATH" und unter Linux export LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH" gesetzt werden muss. Wer aus dem Quellcode baut, braucht Go 1.25.0 oder neuer und make, klont das Repository, führt make deps und make build aus und startet dann mit CONFIG=conversation make run, für Debug-Logging mit CONFIG=conversation make dev. Der API-Schlüssel kommt aus dem OpenMind Portal und wird als export OM_API_KEY="<your_api_key>" gesetzt oder in einer lokalen .env-Datei abgelegt, die aus .env.example kopiert wird. Für Sprache müssen ASR und TTS in config/conversation.json5 konfiguriert sein, sonst bleibt die Interaktion stumm. Optional startet docker-compose up -d grafana prometheus den Monitoring-Stack, erreichbar unter http://localhost:3000 mit admin/admin, das Dashboard OM1 Latency Monitoring wird automatisch bereitgestellt.

OMCU, Abrechnung und die Frage nach dem Offline-Betrieb

OMCU ist laut README die Recheneinheit für die Abrechnung auf der Plattform von OpenMind. Der kostenlose Tarif umfasst 50 OMCU, die monatlich erneuert werden, zusätzliche Kontingente gibt es über das Portal. Damit hängt der Betrieb eines OM1-Agenten an einem externen Konto, selbst wenn Teile der Pipeline lokal laufen. Das Repository nennt Ollama als lokales LLM-Backend, was auf einen teilweise lokalen Betrieb hindeutet, aber nicht belegt, welche Bestandteile ohne OpenMind-Endpunkt auskommen. Wer OM1 in einer Umgebung ohne Internetzugang oder mit Nachweispflichten für Datenflüsse betreiben will, muss das vorab klären. Der Hinweis auf die 50 OMCU ist zudem nur eine Momentaufnahme: Das Modell kann sich ändern, und die Kosten skalieren mit der Nutzung, nicht mit der Anzahl installierter Roboter. Eine belastbare Kostenplanung braucht deshalb die tatsächlich gemessenen Verbräuche, die sich über den mitgelieferten Grafana-Stack beobachten lassen.

Wo OM1 an Grenzen stößt und was stattdessen passt

OM1 ist die falsche Wahl, wenn ein Roboter eine feste, deterministisch getaktete Regelung braucht. Der Agentenaufbau mit Modellaufrufen bringt Latenzen mit sich, die sich nicht wegkonfigurieren lassen, und die Verarbeitungskette ist auf Austauschbarkeit ausgelegt, nicht auf Vorhersagbarkeit. Auch für reine Simulationsarbeit ohne Modell-Backend ist der Aufwand mit Systemabhängigkeiten, Bibliothekspfaden und API-Schlüssel höher als bei einer schlanken Simulationsanbindung. Ein naheliegender Gegenentwurf ist ROS 2 mit Nav2 und einem selbst geschriebenen Knoten, der einen LLM-Aufruf als Dienst kapselt. Der Unterschied liegt im Ansatz, nicht im Funktionsumfang: ROS 2 gibt dem Team die volle Kontrolle über jeden Knoten, jede Nachricht und jeden Zeitstempel, verlangt aber, dass es Eingabeverarbeitung, Modellaufrufe, Aktionsauswahl und Hardware-Ansteuerung selbst schreibt und selbst wartet. OM1 liefert diese Kette fertig und konfigurierbar mit, nimmt dem Team dafür aber die Entscheidung über die Zwischenschichten ab. Wer die Pipeline im Detail steuern muss, ist mit ROS 2 direkt besser bedient.

Wartung, Upgrades und die Lizenz

Das Repository steht unter der MIT-Lizenz. Das ist eine permissive Lizenz: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Lizenztext und der Urheberrechtshinweis beibehalten werden. Wer OM1 in ein eigenes Produkt einbettet, muss diesen Hinweis also mitführen. Das ist keine Rechtsberatung, sondern nur die Einordnung des Lizenzidentifiers aus dem Repository. Wichtiger für den Betrieb ist der Release-Rhythmus. Neben nummerierten Versionen wie v1.0.2-beta.2 und v1.0.2-beta.1 existiert ein nightly genannter Development Build. Die nummerierten Stände tragen Beta-Kennzeichnungen, es gibt also keinen als stabil ausgewiesenen Zweig. Wer den nightly-Build einsetzt, arbeitet auf einem beweglichen Stand. Das Auslieferungsarchiv enthält config/, knowledge_base/ und die libzenohc-Dateien, sodass ein Upgrade nicht nur die Binary betrifft, sondern auch Konfiguration und Wissensbasis, die bei eigenen Anpassungen abgeglichen werden müssen. Ein Upgrade ist damit ein Vorgang, der Konfigurationsdateien einschließt, nicht ein Austausch einer einzelnen Datei.

Redaktionelles Fazit

Für Teams, die einen Agenten mit Sprach-, Bild- und Sensoreingang auf vorhandener ROS2- oder Zenoh-Hardware aufsetzen wollen, ist die Go-Runtime von OM1 der naheliegende Einstieg, solange sie den API-Schlüssel und die OMCU-Abrechnung akzeptieren. Wer eine vollständig offline laufende oder auditierbare Agentenpipeline braucht, sollte zuerst prüfen, welche Teile der Pipeline ohne OpenMind-Endpunkt funktionieren, und ob Ollama als LLM-Backend den eigenen Anforderungen genügt. Vor dem Rollout ist zu klären, ob die im Go-Zweig noch fehlenden Fähigkeiten der Python-Version den geplanten Anwendungsfall berühren, denn die Python-Version wird laut Repository nicht mehr gepflegt.

Offizielle Quellen

1. License: MIT
2. OpenMind/OM1 on GitHub
3. Project website
4. README
5. Releases