Grove G1 met en ligne une pile d’autonomie ROS 2 pour l’humanoïde Unitree G1, avec une promesse claire : développer en simulation, puis rapprocher le même graphe logiciel du robot réel sans réécrire les couches de navigation et de manipulation.
Le projet, publié sur GitHub et mis à jour le 16 août, cible ROS 2 Humble et s’appuie sur unitree_mujoco. Son intérêt n’est pas seulement de lancer une démonstration dans MuJoCo. Le dépôt décrit une architecture où le simulateur parle les mêmes topics DDS que le robot, ce qui doit permettre de conserver la couche de pont, la navigation et la logique d’autorité de contrôle lors du passage au matériel.
Navigation, bras et mission complète
Dans l’état documenté du dépôt, Grove G1 fait cartographier un environnement au G1 avec SLAM Toolbox, localise le robot sur une carte sauvegardée et l’envoie vers une pose cible avec Nav2. Pour les bras, les trajectoires passent par ros2_control vers l’interface rt/arm_sdk d’Unitree, afin de laisser le contrôleur embarqué gérer l’équilibre des jambes pendant les mouvements du haut du corps.
La partie manipulation s’appuie sur MoveIt, avec planification pour un bras ou les deux, prise en compte d’un octomap issu du LiDAR et groupes séparés pour les mains Dex3-1. Le dépôt expose aussi des actions de pick and place et une orchestration BehaviorTree.CPP. Le scénario décrit enchaîne navigation vers un établi, approche finale en boucle fermée, saisie d’un cube, transport dans le bâtiment puis dépôt sur un autre banc.
Ce n’est pas encore une pile de manipulation apprise pour scènes non structurées. Le README précise même que la source de pose objet utilisée en simulation refuse de tourner sur matériel, faute de pipeline de détection réel à ce stade. Cette limite est importante : Grove G1 documente un chemin d’intégration robotique, pas un robot domestique autonome prêt à être déployé.
Pourquoi c’est utile
Pour les équipes qui travaillent sur humanoïdes, l’enjeu concret est la séparation entre locomotion, bras et décision de mission. Les commandes bas niveau directes sur un humanoïde bipède déplacent vite la responsabilité de l’équilibre vers l’intégrateur. Grove G1 impose donc deux règles : un seul éditeur commande chaque canal bas niveau, et les mouvements de bras ou de locomotion passent par le service prévu pour composer avec l’équilibre embarqué.
Le projet fournit aussi un environnement de développement conteneurisé, des configurations Nav2 et MoveIt, une simulation MuJoCo, des scènes et une palette Groot2 pour suivre l’arbre de comportement. Sur un robot réel, le dépôt prévoit de remplacer la carte simulation par le service de mouvement embarqué d’Unitree et le frontal LiDAR par livox_ros_driver2.
Notre analyse
La valeur éditoriale de Grove G1 tient moins à sa notoriété actuelle qu’à sa granularité. Le dépôt documente les compromis que beaucoup de démonstrations humanoïdes masquent : domaine DDS, autorité de contrôle, fenêtre de manipulation réduite, synchronisation entre navigation et bras, et passage d’une perception simulée à une perception réelle. Cela en fait une base intéressante pour les développeurs ROS 2 qui veulent expérimenter sur Unitree G1 sans repartir d’une page blanche.
La prudence reste nécessaire. Le projet est jeune, peu étoilé et sans validation industrielle indépendante. Mais il donne un exemple concret de ce que devient l’IA physique lorsque l’on descend au niveau des packages, des topics et des contrôleurs : une somme de petites décisions d’intégration qui conditionnent autant le résultat que le modèle d’IA utilisé au-dessus.
