Kits de développement logiciel pour robots, ROS 2 et environnements de simulation

Une plateforme robotique de 2026 — humanoïde ou quadrupède — est livrée avec trois logiciels à gérer avant même d'exécuter votre propre code. Le kit de développement logiciel (SDK) du fabricant, qui gère les articulations ; l'interface ROS 2, qui gère le reste ; et le simulateur, indispensable car envoyer un robot Unitree G1 EDU à 43 000 $ s'écraser contre un mur est une méthode coûteuse pour corriger une simple faute de frappe.

Ces trois couches ne sont pas interchangeables. Le SDK est temps réel et propriétaire. ROS 2 est le langage commun qui permet aux autres développeurs de logiciels de robotique du monde entier de travailler avec votre plateforme. Le simulateur sert à effectuer les tâches que vous ne souhaitez pas réaliser sur le robot réel : apprentissage par renforcement, génération de données à grande échelle, conception de scènes, intégration continue sans interface graphique. La plupart des équipes sous-investissent dans ces trois éléments.

Cet article détaille les fonctionnalités offertes par chaque couche en 2026, leurs limites et les combinaisons intéressantes à mettre en œuvre avec le budget d'un laboratoire de robotique. Les plateformes de référence sont celles de… R01 et R02. La configuration de calcul de référence est la ligne K-AI (4× ou 8× RTX 5090 ou RTX Pro 6000 Blackwell, hôte EPYC ou Xeon).

La couche SDK — ce que les fabricants vous fournissent réellement

Tous les fournisseurs de robots sérieux livrent un kit de développement logiciel. Le nom est le même ; le contenu, lui, diffère. Voici ce que contient réellement la boîte.

Deux divisions comptent plus que les autres.

Ouvert ou fermé. Unitree, Booster, EngineAI et DeepRobotics offrent 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 vous faut pour le déploiement de politiques d'apprentissage par renforcement, la recherche sur la locomotion personnalisée et tout système dynamique. Boston Dynamics et ANYbotics conservent un contrôle interne des articulations : vous disposez de primitives de haut niveau (marcher jusqu'ici, grimper là, manipuler ceci), le SDK les expose via des appels RPC, et le contrôleur propriétaire de l'entreprise gère le fonctionnement des articulations. Ce choix est délibéré. ​​Cette architecture interne est plus fiable, et c'est le logiciel d'autonomie qui justifie le prix (entre 74 000 et 200 000 $). Cependant, elle n'est pas adaptée aux recherches portant sur le contrôle de bas niveau.

Temps réel ou non. Unitree SDK2 utilise Cyclone DDS sur une interface réseau dédiée et offre un temps de réponse aller-retour inférieur à la milliseconde sur la boucle de jonction. L'architecture de Booster est similaire. Spot SDK utilise gRPC sur HTTP/2 ; idéal pour commander un comportement, mais inadapté pour boucler une boucle de contrôle à 1 kHz. Si votre application requiert une boucle inférieure à 2 ms, l'architecture prime sur le langage.

Remarque concernant la question de Python : tous les fournisseurs proposent des interfaces Python. Aucune n’utilise le langage dans lequel s’exécute la boucle de contrôle. Le schéma est identique dans tout le secteur. C++ pour le contrôleur temps réel, Python pour tout le reste. Les kits de développement logiciel (SDK) des fournisseurs reflètent cette situation : les liaisons C++ offrent davantage d’options, sont plus rapides et servent de langage de prédilection pour les exemples du fournisseur. Les liaisons Python sont idéales pour les opérations de haut niveau et constituent une interface pour les opérations de bas niveau. Privilégiez le C++ pour la boucle de contrôle interne et Python pour l’orchestration, l’interface de perception et l’intégration avec le serveur d’inférence.

ROS 2 — pourquoi tout le monde s'y habitue

Le kit de développement logiciel natif vous permet d'accéder au robot. ROS 2 vous permet d'intégrer l'écosystème.

Il existe trois raisons pour lesquelles toute intégration sérieuse finit par utiliser ROS 2 même lorsque le SDK du fabricant est suffisant :

1. Interopérabilité. Votre pile de perception, votre SLAM, votre système de navigation, votre planificateur de manipulation, votre système de téléopération : tous ces éléments sont implémentés sous ROS 2 et maintenus par des centaines de contributeurs. Aucun ne prend en charge nativement le format de sujet Unitree DDS. Il suffit d’encapsuler le SDK dans des messages ROS 2 pour accéder à l’ensemble de l’écosystème.
2. Flottes multi-fournisseurs. Dès l'ajout d'un second robot d'un autre fournisseur, l'approche par SDK natif devient inopérante. ROS 2 est la seule abstraction permettant à 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. Embauche. Les utilisateurs connaissent ROS 2, mais pas les conventions de nommage des sujets Unitree DDS. Une équipe utilisant ROS 2 peut recruter à l'international, contrairement à une équipe utilisant une architecture propriétaire.

État de la distribution ROS 2, mai 2026 :

La lecture honnête. Les déploiements en production actuels fonctionnent encore sous Humble. Humble est la version LTS ciblée par les fournisseurs — celle d'Unitree. unitree_ros2, la pile de Booster, la communauté spot_ros2Les bibliothèques grid_map d'ANYbotics et Jazzy sont toutes deux stables sur Humble Bundle. Jazzy est la bibliothèque à privilégier pour les nouvelles constructions : elle bénéficie encore de trois ans de support à long terme et les outils de migration sont matures. Lyrical Luth est trop récente pour s'y engager ; il est préférable d'attendre fin 2026 avant de déployer un système de production dessus.

Si vous démarrez un projet en mai 2026, optez pour Jazzy. Si vous prolongez un projet commencé en 2023, restez sur Humble jusqu'à ce que le prochain achat de robot impose la migration. Évitez complètement Iron et Kilted ; les versions non LTS sont destinées à ceux qui souhaitent suivre de près les mises à jour de Gazebo Harmonic et accepter les coûts de maintenance.

La division de la boucle de contrôle

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

La séparation de la boucle de contrôle : couche SDK C++ temps réel en dessous, orchestration ROS 2 Python au-dessus, connectées à 10–50 Hz via des messages d'état DDS.

La boucle de contrôle reste sur le robot en C++. La couche de haut niveau s'exécute sur des nœuds ROS 2, soit sur le processeur d'application du robot (Jetson Orin AGX), soit, pour les tâches plus lourdes, sur le serveur d'inférence externe (voir I01Les deux couches communiquent à une fréquence de 10 à 50 Hz via DDS. Elles ne partagent aucun processus.

Cette séparation est indispensable. Un nœud Python ROS 2 ne peut pas boucler une articulation à 1 kHz ; le ramasse-miettes à lui seul l'empêche. Tenter de le faire est l'erreur la plus fréquente chez les étudiants débutants en modélisation humanoïde. Le kit de développement logiciel (SDK) du fournisseur existe précisément pour vous éviter cette erreur.

Quand vous avez besoin d'un simulateur (et quand vous n'en avez pas besoin)

Un simulateur est obligatoire pour quatre types de travaux :

• Apprentissage par renforcement. Il est impossible d'entraîner une stratégie de locomotion à partir de zéro sur un robot réel. Le robot tomberait en panne, le programme d'entraînement abandonnerait et le coût serait exorbitant. L'apprentissage par renforcement se déroule dans des simulations : des millions d'épisodes et des milliers d'environnements en parallèle.
• Génération de données à grande échelle. Données synthétiques pour le réglage fin du VLM, la compréhension des scènes et la manipulation des données. Les équipes de pointe (R09) générer des centaines de milliers de scènes étiquetées du jour au lendemain.
• CI sans interface graphique. Vous souhaitez que chaque mise à jour Git vérifie que le robot marche toujours. Le faire directement sur le matériel est impossible. Une simulation nocturne qui teste les mécanismes de locomotion et de perception est une solution envisageable.
• Conception de l'environnement. Concevoir l'aménagement d'un entrepôt, d'une cellule de production, d'un laboratoire — savoir si le robot peut s'y déplacer avant même de le construire.

Vous n'avez pas besoin de simulateur pour :

• Prototypage précoce. Si vous développez une démo permettant de faire faire un signe de la main au robot, un simulateur est superflu. Utilisez le vrai robot.
• Manipulation simple. Ramasser une boîte, ouvrir un tiroir. L'écart entre la simulation et la réalité pour ces tâches est souvent plus important que le temps que vous auriez passé à les effectuer avec un véritable robot.
• Développement des téléopérations. L'intérêt principal de la téléopération réside dans la présence humaine. La simulation n'y change rien.
• Comportements ponctuels. Tout ce que vous utiliserez deux fois avant de le jeter.

L'erreur que commettent les équipes est de considérer le simulateur comme la solution par défaut. Ce n'est pas le cas. Il s'agit d'un outil destiné aux quatre cas mentionnés précédemment, auquel s'ajoute la simple précaution de ne pas endommager le robot réel.

La gamme de simulateurs 2026

Il existe quatre simulateurs importants pour la robotique bipède en 2026. Ils ne sont pas équivalents et le choix est subjectif.

Les valeurs de la colonne « parallel-envs » sont pratiques, non théoriques. Elles dépendent de la complexité du modèle. Un bras Franka fonctionne avec un nombre d'exécutions parallèles plus élevé 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 un simulateur photoréaliste accéléré par GPU, basé sur la plateforme Omniverse. Isaac Lab est le framework d'apprentissage robotique qui s'appuie dessus. Ensemble, ils constituent la réponse de NVIDIA à toutes les problématiques de simulation robotique.

Ce qu'il fait bien :

• Rendu photoréaliste. Éclairage par lancer de rayons, matériaux précis, modèles de caméras réalistes : si votre système de perception doit apprendre à reconnaître le monde réel, ce simulateur est le seul à le fournir à cette échelle.
• Physique accélérée par GPU. Les environnements parallèles résident dans la mémoire du GPU. Une seule RTX 5090 exécute des milliers d'instances humanoïdes à des centaines d'étapes physiques par seconde.
• Laboratoire Isaac Un framework RL épuré avec prise en charge intégrée de RSL RL, RL-Games, SKRL et Stable Baselines3. Les plus de 16 modèles de robots pré-construits incluent G1, H1, Spot, ANYmal, Franka et une liste croissante de nouveaux venus.
• Intégration GR00T. La pile de modèles humanoïdes de NVIDIA se trouve ici. Si vous souhaitez entraîner une politique de vision, de langage et d'action et la déployer sur plusieurs plateformes, c'est la voie à suivre.

Ce qu'il fait mal :

• Installation d'Omnivers douloureuse. L'environnement d'exécution d'Omniverse est exigeant, lourd et peu compatible avec une installation Ubuntu standard. Prévoyez une journée entière pour résoudre les problèmes de lancement, de serveur Nucleus et de cache des ressources avant de pouvoir lancer votre première simulation.
• Limité par le GPU. Isaac Sim ne fonctionne pas sur un processeur. Il ne fonctionne pas correctement avec une seule 4090. La configuration de référence comprend au minimum une 5090, de préférence une Blackwell Pro 6000, et un hôte EPYC pour l'alimentation des données.
• Dogmatique. Les ressources sont au format USD. La physique est gérée par PhysX. Le rendu est réalisé avec RTX. Si vous souhaitez un autre moteur physique, vous n'utilisez pas le bon simulateur.

Calculer la réalité. Un serveur K-AI équipé de 4 cartes graphiques RTX 5090 exécute sans problème l'entraînement des humanoïdes d'Isaac Lab : 4 000 à 8 000 environnements parallèles, rendu photoréaliste à 30-60 images/s et convergence des politiques sur une tâche de locomotion en 6 à 24 heures. Avec 8 cartes 5090, vous pouvez augmenter la capacité ou exécuter plusieurs expériences en parallèle. Le Blackwell Pro 6000 est le choix idéal lorsque la mémoire est la principale contrainte (grands lots, bibliothèques d'assets humanoïdes volumineuses).

MuJoCo et MJX — la réponse axée sur la physique

MuJoCo est le simulateur physique de DeepMind. MJX est la réécriture XLA/JAX qui exécute MuJoCo sur le GPU avec un traitement par lots complet. MJWarp est un projet plus récent, fruit d'une collaboration entre NVIDIA et Google, qui réécrit MuJoCo en Warp et offre de meilleures performances pour les scènes riches en interactions.

Ce qu'il fait bien :

• La vitesse. Une physique des corps rigides riche en contacts, conçue spécifiquement pour le GPU. Sur une seule RTX 5090, MJX gère des milliers d'environnements humanoïdes à une vitesse de calcul qu'Isaac Sim ne peut égaler pour une complexité de scène équivalente.
• Déterminisme. Même graine, même trajectoire. La reproductibilité de l'apprentissage par renforcement est une caractéristique.
• Avec le soutien de DeepMind. Toutes les publications majeures de DeepMind en robotique de ces cinq dernières années utilisent MuJoCo. Les bibliothèques de modèles (MuJoCo Menagerie) incluent G1, H1, Spot, ANYmal, le bras Franka et la main Shadow.
• Plus simple. Ni Omniverse, ni USD, ni Nucleus. Installez avec pip, puis exécutez.

Ce qu'il fait mal :

• Rendu visuel. Le moteur de rendu de MuJoCo date de l'ère OpenGL. Suffisant pour la visualisation, il est inutilisable pour la génération de données photoréalistes.
• Écosystème d'actifs. Plus petit qu'Isaac. Les importations URDF fonctionnent, mais la qualité est inférieure.
• Modèles de capteurs. Les modèles de caméra, de profondeur et de LiDAR sont basiques. Si votre politique repose sur un bruit de capteur réaliste, vous devrez créer ces modèles vous-même.

Calculer la réalité. Une seule RTX 5090 exécute entre 4 000 et 16 000 environnements humanoïdes MJX en parallèle, selon la complexité des contacts. Un serveur K-AI composé de quatre RTX 5090 peut exécuter plus de 50 000 environnements humanoïdes en parallèle pour l'apprentissage par renforcement de la locomotion. C'est ce calcul qui a conduit DeepMind et la plupart des laboratoires de recherche à adopter MuJoCo pour la boucle interne d'entraînement des politiques.

Gazebo Harmonic — le natif de ROS 2

Gazebo est le simulateur open source utilisé par défaut pour ROS depuis vingt ans. Gazebo Harmonic est la version LTS actuelle et s'intègre parfaitement avec ROS 2 Humble et Jazzy.

Ce qu'il fait bien :

• Intégration ROS 2. Première classe. ros_gz Le pont permet à vos nœuds ROS 2 de fonctionner en simulation sans aucune modification.
• Ouvert et gratuit. Aucune licence, aucun Omniverse, aucune dépendance à NVIDIA. Fonctionne sur CPU, sur GPU AMD, sur n'importe quelle plateforme.
• Idéal pour les tests d'intégration. Lorsque votre objectif est de « vérifier que la pile de navigation et le planificateur fonctionnent toujours après une refonte », Gazebo est la solution idéale.

Ce qu'il fait mal :

• Lent. Physique monothread, rendu logiciel par défaut. Les environnements parallèles nécessitent le lancement de plusieurs processus Gazebo. Les politiques d'apprentissage par renforcement ne sont pas entraînées dans Gazebo ; elles sont testées de manière préliminaire.
• Non compatible avec les GPU. Pas de traitement par lots sur le GPU. L'ajout d'une accélération du rendu est utile, mais ne modifie pas la mise à l'échelle fondamentale.
• L'écart entre les simulations et la réalité est pire. Le modèle de contact est moins rigoureux que celui de MuJoCo, les modèles de capteurs sont moins réalistes que ceux d'Isaac.

Calculer la réalité. Gazebo fonctionne sur n'importe quelle machine. Le serveur K-AI est surdimensionné pour son utilisation. Un ordinateur portable suffit amplement. En revanche, pour toute charge de travail d'apprentissage par renforcement un tant soit peu conséquente, Gazebo deviendra rapidement insuffisant.

Genesis — le candidat académique à haut débit

Genesis est le simulateur multi-institutionnel qui a fait son apparition fin 2024 avec des promesses de performances ambitieuses et qui, depuis, a prouvé la plupart d'entre elles. CMU, Stanford, MIT CSAIL, NVIDIA et Tsinghua y ont tous contribué.

Ce qu'il fait bien :

• Débit. Genesis atteint plus de 40 millions d'images par seconde sur une seule RTX 4090 pour une charge de travail de cinématique inverse Franka. Pour les humanoïdes, ce nombre est inférieur, mais reste de l'ordre de plusieurs millions. L'architecture est conçue dès le départ pour la simulation massivement parallèle.
• Multiphysique. Rigide, fluide, corps mou, granulaire, MPM. Si votre tâche implique autre chose qu'un contact rigide (manipulation déformable, versement de fluides, interaction granulaire), Genesis est le seul simulateur de cette liste à le gérer nativement.
• Outils de scène génératifs. Genesis intègre une génération de scènes à partir de descriptions textuelles. Vous décrivez un environnement, et vous obtenez une scène.

Ce qu'il fait mal :

• Écosystème plus récent. Moins de modèles pré-construits, moins de tutoriels, une communauté plus petite que MuJoCo ou Isaac.
• Moins éprouvé au combat pour le passage de la simulation à la réalité. La physique est rapide ; la communauté est encore en train de déterminer si elle se transpose aussi bien que MuJoCo sur le matériel.
• Lacunes dans la documentation. Fréquent dans les projets de recherche en évolution rapide.

Où cela se situe-t-il en 2026 ? Genesis est le choix idéal pour l'apprentissage par renforcement académique, où l'on recherche un débit maximal dans l'environnement et où l'on est prêt à développer ses propres fonctions d'interface. Pour un pipeline de production simulant des données réelles, MuJoCo ou Isaac sont des options plus sûres. À suivre.

Du virtuel au réel, édition 2026

État pratique de la simulation vers le réel, mai 2026 :

• La randomisation du domaine est obligatoire. On ne peut pas s'entraîner sur un seul ensemble de paramètres physiques et espérer un transfert. La masse, le frottement, les délais des moteurs, le bruit des capteurs, la latence : tous ces éléments sont randomisés dans une certaine plage pendant l'entraînement.
• Le retard dans l'action a des conséquences plus importantes qu'on ne le croit. Les actionneurs d'un robot réel présentent un délai de 5 à 25 ms entre la commande et l'application du couple. Une simulation qui ne tient pas compte de ce délai génère des comportements instables au niveau matériel. Il est donc essentiel d'intégrer ce délai dès la conception de la simulation.
• Il faut injecter du bruit de capteur. Dérive de l'IMU, bruit de la caméra, déconnexions du capteur de profondeur : les 2026 articles concluants prennent tous en compte ces problèmes lors de l'entraînement.
• La formation multi-simulateurs est à la pointe de la technologie. PolySim et les frameworks similaires effectuent l'entraînement simultanément sur MuJoCo, Isaac et parfois Gazebo. Les premiers résultats sont prometteurs. Le coût de calcul est 2 à 3 fois supérieur à celui d'un entraînement sur une seule simulation.
• La modélisation des humanoïdes lourds reste difficile. Transporter une charge utile, se remettre d'une poussée tout en transportant quelque chose — ces comportements subissent encore une dégradation de 50 à 80 % entre la simulation et la réalité sur les plateformes concernées. R01.

Prévoyez que les deux tiers de vos performances réelles proviendront de la simulation. Le dernier tiers sera consacré à l'optimisation matérielle, à l'identification du système et au débogage fastidieux.

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

Hardware:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - K-AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (the Pro 6000 for sim, the 5090s for batched policy training)
  - Wi-Fi 6E AP, line of sight to working area
  - 10 GbE switch, wired link from K-AI to AP

Software on the K-AI server:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (Omniverse runtime, Nucleus local)
  - ROS 2 Humble (or Jazzy, if starting fresh today)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM serving a VLM for high-level perception (see I02)
  - MuJoCo + MJX as the second sim, for cross-sim validation

Software on the G1:
  - Unitree SDK2 (C++ joint-control loop)
  - unitree_ros2 (Humble) on the Jetson
  - Custom ROS 2 nodes: command_router, perception_relay
  - gRPC client to vLLM on the K-AI server

Workflow:
  1. Train a locomotion or whole-body policy in Isaac Lab on the
     Pro 6000 (4,000+ parallel G1 instances, RSL RL).
  2. Validate the policy in MJX (4× 5090 batched) with different
     domain randomization seeds.
  3. Deploy the policy via TorchScript to the G1's Jetson, wrapped
     in a ROS 2 node that the Unitree SDK2 control loop calls.
  4. ROS 2 high-level commands flow from the lab's task graph
     through the command_router into the policy.
  5. Heavy perception (VLM) lives on the K-AI server, reached over
     Wi-Fi 6E + gRPC.

Le temps de mise en place total pour une équipe ayant déjà une expérience de ROS 2 est de deux à trois semaines. Pour une équipe apprenant ROS 2 à partir de zéro, il est de deux à trois mois. Prévoyez en conséquence. La partie calcul du serveur K-AI est la plus simple.

Le point de vue honnête

Trois opinions, tout simplement :

1. ROS 2 est la couche d'abstraction appropriée. Les SDK natifs sont nécessaires, mais pas suffisants. Utilisez le wrapper ROS 2 et considérez le SDK du fabricant comme un service utilisé par ce wrapper. Opter pour une solution propriétaire ne vous apporte rien et vous prive de tout l'écosystème.
2. Isaac Sim représente l'avenir, mais pour la plupart des équipes, le présent c'est MuJoCo + ROS 2. Pour l'apprentissage par renforcement appliqué à la locomotion et à la manipulation fine, MuJoCo/MJX est la solution la plus économique, la plus rapide et la plus simple à déployer. En revanche, pour la perception photoréaliste, la génération de données à grande échelle ou l'ajustement fin de modèles de base de type VLA, Isaac est indispensable. La plupart des laboratoires ont besoin des deux, et le serveur K-AI dispose de la capacité nécessaire pour les exécuter simultanément.
3. Les laboratoires de pointe utilisent les quatre. Isaac pour le rendu et le pipeline du modèle de base. MuJoCo pour la boucle interne d'apprentissage par renforcement. Gazebo pour les tests d'intégration ROS 2. Genesis pour la gestion de la physique multiple. Croire qu'un seul outil suffit, c'est souvent la mauvaise habitude des équipes de réécrire leur architecture au bout d'un an.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.