SDK robotiques, ROS 2 et environnements de simulation

Une plateforme robotique de 2026 — humanoïde ou quadrupède — arrive avec trois couches logicielles à traiter avant que la moindre ligne de votre propre code ne tourne. Le SDK du constructeur, qui parle aux articulations. Le wrapper ROS 2, qui parle à tout le reste. Et le simulateur, parce qu'envoyer un Unitree G1 EDU à 43k $ dans un mur est une façon coûteuse de déboguer une faute de frappe.

Ces trois couches ne sont pas interchangeables. Le SDK est temps réel et propriétaire. ROS 2 est la lingua franca qui permet au reste du code robotique mondial de fonctionner avec votre plateforme. Le simulateur, c'est là que vous faites le travail que vous ne voulez pas faire sur le robot réel : apprentissage par renforcement, génération de données à grande échelle, conception de scènes, intégration continue sans affichage. La plupart des équipes sous-investissent sur les trois.

Cet article détaille ce que chaque couche apporte réellement en 2026, où passent les frontières et quelles combinaisons méritent d'être mises en place avec le budget réel d'un laboratoire de robotique. Les plateformes de référence sont celles de R01 et R02. Le calcul de référence est la gamme Kentino AI (4× ou 8× RTX 5090 ou RTX Pro 6000 Blackwell, hôte EPYC ou Xeon).

La couche SDK — ce que les constructeurs vous donnent vraiment

Tout fabricant de robots crédible livre un Software Development Kit. Le nom est le même, le contenu non. Voici ce qu'il y a réellement dans la boîte.

Deux clivages comptent plus que les autres.

Ouvert ou verrouillé. Unitree, Booster, EngineAI et DeepRobotics vous donnent un accès au niveau des articulations. Vous pouvez envoyer des commandes de couple de 500 Hz à 1 kHz directement aux actionneurs. C'est ce qu'il faut pour déployer une politique d'apprentissage par renforcement, mener des recherches sur une locomotion sur mesure et aborder tout ce qui est dynamique. Boston Dynamics et ANYbotics gardent le contrôle articulaire fermé : vous disposez de primitives de haut niveau (marche jusqu'ici, escalade ceci, manipule cela), le SDK les expose sous forme d'appels RPC et c'est le contrôleur maison qui fait le travail articulaire. C'est un choix délibéré. La pile fermée est plus fiable, et le logiciel d'autonomie est précisément ce que vous payez 74k $ à 200k $. C'est aussi la mauvaise pile si votre recherche porte sur le contrôle bas niveau.

Temps réel ou non. Unitree SDK2 utilise Cyclone DDS sur une interface réseau dédiée et vous offre un aller-retour sous la milliseconde sur la boucle articulaire. La pile de Booster est comparable. Le SDK Spot repose sur gRPC au-dessus de HTTP/2 : parfait pour commander un comportement, inutile pour fermer une boucle de contrôle à 1 kHz. Si votre travail exige une boucle sous 2 ms, l'architecture compte davantage que le langage.

Un mot sur la question Python. Tous les constructeurs proposent des bindings Python. Aucun d'eux n'est le langage dans lequel tourne la boucle de contrôle. Le schéma est partout le même dans le secteur : C++ pour le contrôleur temps réel, Python pour tout ce qui se trouve au-dessus. Les SDK constructeurs le reflètent : les bindings C++ exposent davantage, s'exécutent plus vite et c'est dans ce langage que sont écrits les exemples officiels. Les bindings Python sont de premier ordre pour le travail de haut niveau et ne sont qu'une enveloppe pour le chemin bas niveau. Choisissez C++ quand vous écrivez la boucle de contrôle interne, et Python pour l'orchestration, la colle de perception et l'intégration avec le serveur d'inférence.

ROS 2 — pourquoi tout le monde s'y rallie

Le SDK natif vous donne accès au robot. ROS 2 vous donne accès à l'écosystème.

Trois raisons expliquent que toute intégration sérieuse finisse par parler ROS 2, même quand le SDK du constructeur suffirait :

1. Interopérabilité. Votre pile de perception, votre SLAM, votre navigation, votre planificateur de manipulation, votre téléopération : tous disposent d'implémentations ROS 2 maintenues par des centaines de contributeurs. Aucun ne parle nativement le format de topics DDS d'Unitree. Encapsulez le SDK une seule fois dans des messages ROS 2 et c'est tout l'écosystème qui s'ouvre.
2. Flottes multi-constructeurs. Le jour où vous ajoutez un second robot d'une autre marque, l'approche par SDK natif s'effondre. ROS 2 est la seule abstraction qui permette à un Spot, un ANYmal et un G1 de partager le même serveur de cartes, le même graphe de tâches et la même interface homme-machine.
3. Recrutement. Les gens connaissent ROS 2. Ils ne connaissent pas les conventions de nommage des topics DDS d'Unitree. Une équipe qui bâtit sur ROS 2 peut recruter dans un vivier mondial. Une équipe qui bâtit sur une pile propriétaire, non.

État des distributions ROS 2, mai 2026 :

Le constat honnête. Les déploiements de production tournent encore sur Humble aujourd'hui. Humble est la LTS visée par les constructeurs : unitree_ros2 d'Unitree, la pile de Booster, le spot_ros2 communautaire et le grid_map d'ANYbotics disposent tous de branches Humble stables. C'est sur Jazzy que les nouveaux projets devraient démarrer : il lui reste trois ans de vie LTS et l'outillage de migration est mature. Lyrical Luth est trop récente pour qu'on s'y engage — laissez-lui jusqu'à la fin 2026 avant d'y monter un système de production.

Si vous démarrez un projet en mai 2026, prenez Jazzy. Si vous en prolongez un lancé en 2023, restez sur Humble jusqu'à ce que le prochain achat de robot impose la migration. Ignorez complètement Iron et Kilted : les versions non-LTS sont faites pour ceux qui veulent suivre de près les montées de version de Gazebo Harmonic et acceptent d'en payer le coût de maintenance.

La séparation des boucles de contrôle

C'est le choix d'architecture qui prend la plupart des équipes au dépourvu.

La séparation des boucles de contrôle : en bas la couche SDK C++ temps réel, en haut l'orchestration Python ROS 2, reliées à 10–50 Hz par des messages d'état DDS.

La boucle de contrôle reste sur le robot, en C++. La couche de haut niveau tourne dans des nœuds ROS 2, soit sur le processeur applicatif du robot (Jetson Orin AGX), soit, pour les traitements plus lourds, sur le serveur d'inférence déporté (voir I01). Les deux couches dialoguent à 10–50 Hz via DDS. Elles ne partagent pas le même processus.

Cette séparation n'est pas facultative. Un nœud ROS 2 en Python ne peut pas fermer une boucle articulaire à 1 kHz — le ramasse-miettes suffit à rendre la chose impossible. Essayer quand même est l'erreur la plus courante de la première année de travail sur un humanoïde. Le SDK du constructeur existe justement pour que vous n'ayez pas à le faire.

Quand un simulateur est nécessaire (et quand il ne l'est pas)

Un simulateur est indispensable pour quatre types de travaux :

• Apprentissage par renforcement. Vous ne pouvez pas entraîner une politique de locomotion depuis zéro sur un robot réel. Le robot casserait, l'entraîneur démissionnerait, le coût serait indécent. L'apprentissage par renforcement se fait en simulation : des millions d'épisodes, des milliers d'environnements en parallèle.
• Génération de données à grande échelle. Données synthétiques pour le fine-tuning de VLM, la compréhension de scène, les prises de manipulation. Les équipes les plus avancées (R09) génèrent des centaines de milliers de scènes annotées en une nuit.
• Intégration continue sans affichage. Vous voulez que chaque git push vérifie que le robot marche toujours. Le faire sur du matériel réel n'est pas réaliste. Une exécution nocturne en simulation qui sollicite les piles de locomotion et de perception, si.
• Conception d'environnements. Agencer un entrepôt, une cellule d'usine, un laboratoire — et savoir si le robot saura y naviguer avant même de le construire.

Vous n'avez pas besoin d'un simulateur pour :

• Le prototypage initial. Si vous écrivez une démo « fais saluer le robot », le simulateur est un surcoût. Servez-vous du robot réel.
• La manipulation simple. Saisir un carton, ouvrir un tiroir. L'écart simulation-réel sur ces tâches coûte souvent plus cher que le temps que vous auriez passé à les faire sur le robot réel.
• Le développement de la téléopération. Tout l'intérêt de la téléopération est d'avoir l'humain dans la boucle. La simulation n'y aide pas.
• Les comportements ponctuels. Tout ce que vous lancerez deux fois avant de le jeter.

L'erreur des équipes consiste à faire du simulateur l'option par défaut. Il ne l'est pas. C'est un outil pour les quatre cas ci-dessus, auxquels s'ajoute l'évidente raison de sécurité : « je ne veux pas emboutir le robot réel ».

Le paysage des simulateurs en 2026

Quatre simulateurs comptent en robotique à pattes en 2026. Ils ne sont pas équivalents et le choix est affaire de parti pris.

Les chiffres de la colonne des environnements parallèles sont pratiques, pas théoriques. Ils dépendent de la complexité du modèle. Un bras Franka tourne à des niveaux de parallélisme plus élevés qu'un humanoïde à 41 degrés de liberté doté de mains dextres.

Isaac Sim et Isaac Lab — le pari de NVIDIA

Isaac Sim est le simulateur photoréaliste accéléré par GPU bâti sur la pile Omniverse. Isaac Lab est le framework d'apprentissage robotique qui vient par-dessus. Ensemble, ils constituent la réponse de NVIDIA à toutes les questions de simulation robotique.

Ses points forts :

• Rendu photoréaliste. Éclairage en ray tracing, matériaux fidèles, modèles de caméra réalistes. Si votre pile de perception doit apprendre à quoi le monde ressemble vraiment, c'est le seul simulateur qui le fournit à grande échelle.
• Physique accélérée par GPU. Les environnements parallèles résident en mémoire GPU. Une seule RTX 5090 fait tourner des milliers d'instances d'humanoïde à plusieurs centaines de pas de physique par seconde.
• Isaac Lab. Un framework de RL propre, avec prise en charge intégrée de RSL RL, RL-Games, SKRL et Stable Baselines3. Les 16 modèles de robots préconstruits et plus comprennent G1, H1, Spot, ANYmal, Franka et une liste croissante de nouveaux venus.
• Intégration GR00T. La pile de modèles de fondation pour humanoïdes de NVIDIA vit ici. Si vous voulez entraîner une politique vision-langage-action et la déployer sur plusieurs plateformes, c'est la voie à suivre.

Ses points faibles :

• Une installation Omniverse pénible. Le runtime Omniverse impose ses choix, il est lourd et peu accueillant pour une installation Ubuntu par défaut. Comptez une journée de bataille avec le launcher, le serveur Nucleus et le cache d'assets avant votre première simulation.
• Dépendant du GPU. Isaac Sim ne tourne pas sur un CPU. Il tourne mal sur une seule 4090. La configuration de référence, c'est une 5090 au minimum, une Pro 6000 Blackwell de préférence, et un hôte EPYC pour alimenter les données.
• Rigide dans ses choix. Les formats d'assets sont en USD. La physique, c'est PhysX. Le rendu, c'est RTX. Si vous voulez un autre moteur physique, vous n'êtes pas dans le bon simulateur.

La réalité du calcul. Un serveur Kentino AI à 4× RTX 5090 mène confortablement un entraînement d'humanoïde sous Isaac Lab : 4,000 à 8,000 environnements parallèles, photoréalisme complet à 30–60 FPS de rendu, convergence de la politique sur une tâche de locomotion en 6 à 24 heures. Avec 8× 5090, vous élargissez l'échelle ou menez plusieurs expériences en parallèle. La Pro 6000 Blackwell s'impose quand la mémoire est la contrainte décisive (grands lots, bibliothèques d'assets humanoïdes plus volumineuses).

MuJoCo et MJX — la réponse qui met la physique d'abord

MuJoCo est le simulateur physique de DeepMind. MJX en est la réécriture XLA / JAX, qui fait tourner MuJoCo sur GPU avec un batching complet. MJWarp est un effort conjoint NVIDIA-Google plus récent, qui réécrit MuJoCo en Warp et passe mieux à l'échelle sur les scènes à contacts nombreux.

Ses points forts :

• Vitesse. De la physique de corps rigides à contacts nombreux, écrite pour le GPU dès l'origine. Sur une seule RTX 5090, MJX fait tourner des milliers d'environnements humanoïdes à un nombre de pas de physique par seconde qu'Isaac Sim ne peut égaler à complexité de scène égale.
• Déterminisme. Même graine, même trajectoire. Un RL reproductible est une fonctionnalité à part entière.
• Le soutien de DeepMind. Toutes les publications robotiques majeures de DeepMind des cinq dernières années reposent sur MuJoCo. Les bibliothèques de modèles (MuJoCo Menagerie) incluent G1, H1, Spot, ANYmal, le bras Franka et la Shadow Hand.
• Plus simple. Pas d'Omniverse, pas d'USD, pas de Nucleus. Un pip install, et ça tourne.

Ses points faibles :

• Le rendu visuel. Le moteur de rendu de MuJoCo date de l'ère OpenGL. Convenable pour visualiser, inutile pour générer des données photoréalistes.
• L'écosystème d'assets. Plus restreint que celui d'Isaac. Les imports URDF fonctionnent, mais la finition est moindre.
• Les modèles de capteurs. Les modèles de caméra, de profondeur et de LiDAR sont sommaires. Si votre politique dépend d'un bruit de capteur réaliste, ces modèles seront à votre charge.

La réalité du calcul. Une seule RTX 5090 fait tourner de 4,000 à 16,000 environnements humanoïdes MJX en parallèle selon la complexité des contacts. Un serveur Kentino AI à 4× 5090 peut en mener plus de 50,000 en parallèle pour du RL de locomotion. C'est ce calcul qui maintient DeepMind et la plupart des laboratoires académiques sur MuJoCo pour la boucle interne d'entraînement des politiques.

Gazebo Harmonic — le natif ROS 2

Gazebo est le simulateur open source qui sert de référence à ROS depuis deux décennies. Gazebo Harmonic en est la LTS actuelle et s'associe proprement à ROS 2 Humble et Jazzy.

Ses points forts :

• L'intégration ROS 2. De premier ordre. Le pont ros_gz fait que vos nœuds ROS 2 fonctionnent en simulation sans aucune modification.
• Ouvert et gratuit. Aucune licence, aucun Omniverse, aucune dépendance à NVIDIA. Il tourne sur CPU, sur GPU AMD, sur n'importe quoi.
• Taillé pour les tests d'intégration. Quand votre objectif est de « vérifier que la pile de navigation et le planificateur fonctionnent toujours après un refactoring », Gazebo est le bon choix.

Ses points faibles :

• Lent. Physique mono-thread, rendu logiciel par défaut. Paralléliser les environnements revient à lancer plusieurs processus Gazebo. On n'entraîne pas des politiques de RL dans Gazebo, on y fait des tests de fumée.
• Peu compatible avec le GPU. Aucun batching GPU. Accélérer le rendu aide, mais ne change rien à la montée en charge de fond.
• Un écart simulation-réel plus marqué. Le modèle de contact est moins rigoureux que celui de MuJoCo, les modèles de capteurs moins réalistes que ceux d'Isaac.

La réalité du calcul. Gazebo tourne sur ce que vous avez sous la main. Le serveur Kentino AI est surdimensionné pour lui. Un portable suffit. La contrepartie, c'est que pour toute charge de RL un peu sérieuse, vous aurez dépassé Gazebo en quelques jours.

Genesis — le prétendant académique à haut débit

Genesis est le simulateur multi-institutions arrivé fin 2024 avec des promesses de performance audacieuses, dont il a depuis tenu l'essentiel. CMU, Stanford, le MIT CSAIL, NVIDIA et Tsinghua y ont tous contribué.

Ses points forts :

• Débit. Genesis dépasse les 40 millions de FPS sur une seule RTX 4090 pour une charge de cinématique inverse sur un Franka. Pour les humanoïdes, le chiffre est plus bas mais reste en millions. L'architecture est pensée dès le départ pour la simulation massivement parallèle.
• Multi-physique. Rigide, fluide, corps souples, granulaire, MPM. Si votre tâche fait intervenir autre chose que du contact rigide (manipulation de déformables, versement de liquide, interaction granulaire), Genesis est le seul simulateur de cette liste à le gérer nativement.
• Outillage génératif de scènes. Genesis embarque une génération de scènes pilotée par prompt. Vous décrivez un environnement en texte, vous obtenez une scène.

Ses points faibles :

• Un écosystème plus jeune. Moins de modèles préconstruits, moins de tutoriels, une communauté plus réduite que celles de MuJoCo ou d'Isaac.
• Moins éprouvé pour le transfert vers le réel. La physique est rapide ; savoir si elle se transfère aussi bien que MuJoCo sur du matériel reste à établir par la communauté.
• Des trous dans la documentation. Chose courante pour un projet de recherche en évolution rapide.

Sa place en 2026. Genesis est le bon choix pour un RL de type académique, quand vous cherchez le débit d'environnements maximal et acceptez d'écrire davantage de code de liaison. Pour une chaîne de transfert vers le réel en production aujourd'hui, MuJoCo ou Isaac reste plus sûr. À suivre de près.

La réalité du transfert vers le réel, édition 2026

L'état pratique du transfert simulation-réel en mai 2026 :

• La randomisation de domaine est obligatoire. Vous ne pouvez pas entraîner sur un seul jeu de paramètres physiques et espérer un transfert. Masse, frottement, retards moteur, bruit de capteur, latence : tout cela est tiré au hasard dans une plage pendant l'entraînement.
• Le retard d'action compte plus qu'on ne l'admet. Les actionneurs d'un robot réel présentent de 5 à 25 ms de retard entre la commande et le couple. Une simulation qui ignore ce retard produit des politiques qui oscillent sur le matériel. Intégrez ce retard à la simulation dès le premier jour.
• Le bruit de capteur doit être injecté. Dérive de l'IMU, bruit de caméra, décrochages du capteur de profondeur. Les publications de 2026 qui fonctionnent intègrent tout cela à l'entraînement.
• L'entraînement multi-simulateur est à la pointe. PolySim et les frameworks du même genre entraînent simultanément sur MuJoCo + Isaac + parfois Gazebo. Les premiers résultats sont bons. Le coût en calcul est de 2 à 3× celui d'un entraînement sur un seul simulateur.
• Le mouvement humanoïde fortement chargé reste difficile. Porter une charge, se rétablir après une poussée en transportant quelque chose : ces tâches se dégradent encore de 50 à 80 % entre la simulation et le réel sur les plateformes de R01.

Prévoyez que les deux tiers de votre performance en conditions réelles viendront de la simulation. Prévoyez que le dernier tiers relèvera du réglage fin sur matériel, de l'identification système et d'un débogage têtu.

Recette concrète : G1 + ROS 2 Humble + Isaac Lab sur un serveur Kentino AI

Matériel :
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DDL)
  - Kentino AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (la Pro 6000 pour la simulation, les 5090 pour l'entraînement par lots)
  - Point d'accès Wi-Fi 6E, en vue directe de la zone de travail
  - Switch 10 GbE, liaison filaire du Kentino AI vers le point d'accès

Logiciels sur le serveur Kentino AI :
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (runtime Omniverse, Nucleus en local)
  - ROS 2 Humble (ou Jazzy, pour un projet neuf aujourd'hui)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM servant un VLM pour la perception de haut niveau (voir I02)
  - MuJoCo + MJX comme second simulateur, pour la validation croisée

Logiciels sur le G1 :
  - Unitree SDK2 (boucle de contrôle articulaire en C++)
  - unitree_ros2 (Humble) sur le Jetson
  - Nœuds ROS 2 sur mesure : command_router, perception_relay
  - Client gRPC vers vLLM sur le serveur Kentino AI

Déroulement :
  1. Entraîner une politique de locomotion ou de corps complet dans
     Isaac Lab sur la Pro 6000 (4,000+ instances G1 en parallèle, RSL RL).
  2. Valider la politique dans MJX (4× 5090 par lots) avec différentes
     graines de randomisation de domaine.
  3. Déployer la politique via TorchScript sur le Jetson du G1, encapsulée
     dans un nœud ROS 2 appelé par la boucle de contrôle Unitree SDK2.
  4. Les commandes ROS 2 de haut niveau partent du graphe de tâches du
     laboratoire et passent par le command_router jusqu'à la politique.
  5. La perception lourde (VLM) réside sur le serveur Kentino AI, jointe
     en Wi-Fi 6E + gRPC.

Le temps total de mise en place est de deux à trois semaines pour une équipe déjà expérimentée en ROS 2, et de deux à trois mois pour une équipe qui apprend ROS 2 depuis zéro. Planifiez en conséquence. Le volet calcul du serveur Kentino AI est la partie la plus simple.

L'avis sans détour

Trois opinions, sans détour :

1. ROS 2 est la bonne couche d'abstraction. Les SDK natifs sont nécessaires mais pas suffisants. Construisez sur le wrapper ROS 2 et traitez le SDK du constructeur comme un service que ce wrapper consomme. Partir sur du propriétaire ne vous apporte rien et vous coûte tout le reste de l'écosystème.
2. Isaac Sim est l'avenir, mais le présent, pour la plupart des équipes, c'est MuJoCo + ROS 2. Si votre travail porte sur le RL en locomotion et en manipulation dextre, MuJoCo / MJX est le choix le moins cher, le plus rapide et le plus simple à déployer. Si votre travail porte sur la perception photoréaliste, la génération de données à grande échelle ou le fine-tuning de modèles de fondation de type VLA, Isaac est la seule option. La plupart des laboratoires ont besoin des deux, et le serveur Kentino AI a la marge nécessaire pour faire tourner les deux.
3. Les laboratoires de pointe utilisent les quatre. Isaac pour le rendu et la chaîne des modèles de fondation. MuJoCo pour la boucle interne de RL. Gazebo pour les tests d'intégration ROS 2. Genesis pour le travail multi-physique. Se persuader qu'un seul suffira, c'est ainsi que des équipes finissent par réécrire toute leur pile un an plus tard.

---

Cet article fait partie du Kentino Wiki, une série de référence sur le calcul IA, la robotique et les systèmes qui les relient. Commentaires et corrections bienvenus à info@kentino.com.