DimOS

Environnement d'exécution robotique en Python avec agents, SLAM et téléopération, sans ROS

Licence

Apache-2.0

Aperçu

DimOS est un environnement d'exécution Python pour construire des applications robotiques sans ROS. Les sous-systèmes sont des Modules dotés de flux typés In[] et Out[] ; les blueprints les câblent avec autoconnect(), qui apparie les flux par nom et par type de message et se laisse composer, remapper ou basculer sur un autre transport. Par-dessus viennent les capacités que la plupart des piles assemblent à la main : navigation SLAM et cartes de coût avec planification A* et exploration de frontières, perception avec détecteurs et VLM, une mémoire spatio-temporelle qui localise les objets dans la durée, et des agents qui tournent comme des modules natifs abonnés à n'importe quel flux. La CLI dimos lance des blueprints, suit les journaux, envoie une consigne à un agent et appelle des compétences via MCP. Les modes rejeu et simulation MuJoCo font que les démarrages rapides fonctionnent sans le moindre robot sur le bureau.

Les entrées de robotique agentique de ce catalogue reposent presque toutes sur ROS 2 — RAI, AgenticROS, ROS-MCP et les autres traitent ROS comme le substrat et ajoutent une couche de langage par-dessus. DimOS fait le pari inverse : il remplace aussi l'intergiciel. Modules, flux typés, blueprints et transports maison (LCM, WebRTC, un courtier hébergé) forment une alternative complète aux nœuds, topics et fichiers de lancement de ROS, écrite en Python avec du Rust et du C++ là où la vitesse compte. Savoir si ce pari est gagnant est exactement la question à peser, et le dépôt donne de quoi juger : 4 500 étoiles, des commits quotidiens, une douzaine de contributeurs identifiés et une matrice matérielle franche sur ce qui est stable.

Cette matrice est la page la plus utile du README. Le Go2 d'Unitree est la seule plateforme marquée stable ; l'humanoïde G1, le xArm et l'AgileX Piper sont en bêta ; MAVLink et DJI en alpha ; le B1 et la mesure d'effort-couple sont expérimentaux. L'installation est graduée de la même façon : Ubuntu 22.04 et 24.04 sont la voie prise en charge, NixOS et Linux générique ne passent pas par l'intégration continue, macOS est en alpha. Un projet qui étiquette honnêtement ses propres niveaux de support est plus facile à évaluer qu'un projet qui met toutes les plateformes sur le même plan, et l'ensemble du dépôt porte un bandeau de bêta avant publication.

dimTELE, la moitié téléopération, mérite une note à part. Le robot compose vers un courtier hébergé, de sorte qu'aucun port entrant n'a besoin d'être ouvert, et l'opérateur pilote depuis un navigateur ou un casque Quest via WebRTC. Cela fonctionne bien et c'est la démonstration la plus nette de la pile, mais il faut un compte et une clé d'API de la console de Dimensional. Le client et le code de transport sont dans le dépôt Apache-2.0 ; le courtier à l'autre bout ne l'est pas.

Pourquoi c'est important

Tous les autres cadres de robotique agentique dignes d'être répertoriés présupposent ROS 2 et empilent une couche de langage dessus. DimOS est le seul à demander si l'intergiciel lui-même ne devrait pas être remplacé, et il est assez avancé pour être jugé plutôt que supposé : des flux Python typés au lieu de topics, une pile de navigation et de mémoire qui fonctionne, des agents comme modules de plein droit et des données de rejeu permettant de vérifier les affirmations sans matériel. Qu'on l'adopte ou non, c'est aujourd'hui l'argument le plus fort pour dire que le défaut en forme de ROS est un choix et non une loi.

Le problème résolu

Construire une application robotique impose d'ordinaire d'adopter ROS 2 et tout ce qui l'accompagne — le système de compilation, les définitions de messages, les fichiers de lancement — avant d'écrire la moindre ligne de comportement. DimOS fournit la même couche en Python ordinaire : des flux typés entre modules, une CLI pour les lancer et les inspecter, et navigation, perception, mémoire et intégration d'agents déjà construites dessus.

Points clés

• Un environnement robotique Python qui n'utilise délibérément pas ROS : des Modules à flux typés In[]/Out[], câblés par autoconnect() en blueprints composables
• Livre la navigation (SLAM, cartes de coût, planification A*, exploration de frontières), la perception et une mémoire spatio-temporelle qui retient où se trouvaient les objets et quand
• Les agents sont des modules natifs dotés d'outils MCP, si bien que dimos agent-send "explore the room" et dimos mcp call move_to sont des verbes de CLI à part entière
• Les modes rejeu et simulation MuJoCo exécutent les démarrages rapides mis en avant sans aucun robot connecté
• La matrice matérielle note honnêtement son propre support : Unitree Go2 stable, G1 et xArm en bêta, MAVLink et DJI en alpha, B1 expérimental
• dimTELE offre la téléopération navigateur et Quest par WebRTC en composant vers un courtier, donc sans port entrant sur le réseau du robot
• Apache-2.0 de Dimensional Inc., avec une douzaine de contributeurs réguliers et des commits qui atterrissent chaque jour

Pour qui

• Développeuses et développeurs Python qui veulent écrire du comportement robotique sans apprendre ROS 2 d'abord
• Équipes travaillant avec des quadrupèdes ou humanoïdes Unitree et cherchant une pile au-dessus du SDK constructeur
• Toute personne construisant des agents LLM ou MCP devant s'abonner à de vrais flux de capteurs plutôt qu'appeler un point de terminaison REST
• Exploitants ayant besoin de téléopération à distance à travers un NAT sans ouvrir de ports entrants
• Chercheuses et chercheurs comparant des conceptions d'intergiciel et voulant une référence non-ROS sérieuse à laquelle se confronter

Limites

• Le dépôt se déclare en bêta avant publication et PyPI en est encore à 0.0.x : il faut s'attendre à des interfaces mouvantes
• Environ 700 tickets sont ouverts — projet actif, mais arriéré important à parcourir avant de s'engager
• Ne pas utiliser ROS coupe de son écosystème : pas de pilotes existants, pas de Nav2, pas de MoveIt, pas de rosbag, et ce que le projet n'a pas construit, vous le construirez
• Le support matériel est étroit et majoritairement instable : le Go2 d'Unitree est la seule plateforme marquée stable, tout le reste est bêta, alpha ou expérimental
• Le courtier de dimTELE est un service hébergé par Dimensional nécessitant compte et clé d'API ; le dépôt Apache-2.0 vous donne le client, pas l'autre extrémité
• Ubuntu 22.04/24.04 est la voie testée ; macOS est en alpha et Linux générique explicitement hors intégration continue
• C'est autant la feuille de route produit d'une entreprise qu'un projet communautaire : dépôt ouvert et console hébergée sont développés de concert