L’Open Source Robotics Alliance publie la feuille de route de son groupe Physical AI pour faire évoluer ROS vers les robots pilotés par modèles. Le plan vise deux points très concrets : collecter des données exploitables sur des machines réelles et exécuter des politiques d’IA avec les contraintes de latence, de contrôle et de sécurité propres à la robotique.
ROS veut rester le langage commun des robots physiques
Dans son billet publié le 18 août, l’OSRA part d’un constat simple : les modèles d’imitation, les politiques entraînées par renforcement et les agents capables d’orchestrer des tâches avancent vite, mais ils ne remplacent pas les couches qui relient un modèle à une machine réelle. Il faut toujours décrire la morphologie du robot, piloter ses actionneurs, lire ses capteurs, enregistrer ses données et valider ses mouvements dans un environnement matériel contraint.
C’est précisément le terrain historique de ROS. L’alliance rappelle que le Robot Operating System reste l’un des cadres open source les plus déployés en robotique, parce qu’il fournit des abstractions standard, des pilotes matériels, des outils de supervision et un écosystème partagé entre industriels, laboratoires et intégrateurs. L’enjeu n’est donc pas de remplacer ROS par une pile Physical AI isolée, mais de combler les manques qui ralentissent aujourd’hui son usage avec les modèles modernes.
Des données de démonstration aux buffers zéro copie
Le SIG Physical AI concentre d’abord ses travaux sur la collecte de données. Les équipes veulent faciliter les démonstrations par téléopération, qu’elles viennent de bras maîtres en espace articulaire, de manettes, de téléphones ou de dispositifs en coordonnées cartésiennes. Ces trajectoires doivent ensuite pouvoir alimenter des contrôleurs conformes et des jeux de données compatibles avec les outils d’apprentissage, notamment LeRobotDataset, sans multiplication de scripts ad hoc.
Autre chantier : le transport de données lourdes. Les robots Physical AI manipulent des images, des tenseurs, des signaux tactiles et des flux capteurs à haute fréquence. L’OSRA met en avant le support de buffers natifs dans ROS 2 Lyrical et la proposition REP-0157, qui vise des messages avec une disposition mémoire compatible avec le partage à faible surcharge entre processus et langages. Le but est d’éviter que les copies CPU et la sérialisation ne deviennent le goulot d’étranglement entre perception, apprentissage et contrôle.
Exécuter les politiques sur de vrais robots
La feuille de route distingue aussi les niveaux d’exécution. Les politiques de bas niveau peuvent viser des fréquences de l’ordre de 100 à 1000 Hz, tandis que des modèles d’action intermédiaires produisent des trajectoires ou des blocs d’actions plus lents. Au-dessus, les modèles de décision peuvent orchestrer des compétences comme la navigation ou la prise d’objet sans commander directement chaque articulation.
Pour passer du prototype à la production, le groupe travaille sur deux voies. La première garde Python au centre, afin de tester rapidement des modèles entraînés avec PyTorch ou des outils proches. La seconde rapproche l’inférence de la boucle temps réel, par exemple via des runtimes portables comme ONNX dans la pile ros2_control. C’est une orientation importante : une politique apprise ne peut pas être seulement “branchée” à côté du contrôleur, elle doit participer au même cycle de validation et de suivi que les autres composants critiques.
Notre analyse
Cette publication n’annonce pas un robot spectaculaire, mais elle est structurante pour l’industrie robotique. Les démonstrations d’humanoïdes et de bras manipulateurs se multiplient, tandis que les équipes doivent encore résoudre des problèmes moins visibles : formats de scène, compatibilité entre simulateurs, collecte propre des démonstrations, latence des tenseurs et exécution sûre des politiques.
En ouvrant ce travail autour de REPs, de dépôts publics et d’un SIG dédié, l’OSRA cherche à éviter une fragmentation où chaque laboratoire réinventerait son pont entre ROS, les simulateurs, les jeux de données et les modèles. Pour les fabricants de robots, c’est un signal pragmatique : l’IA physique aura besoin de logiciels d’intégration solides autant que de nouveaux modèles.
