{"schema_version":"1.0","service":"Publicasta","type":"article","id":625,"slug":"openarm_2_reproducible_physical_ai_research_stack","title":"OpenArm 2.0 fait de la reproductibilité des expériences d’IA physique le véritable projet open source","excerpt":"OpenArm 2.0 ne se résume pas à un bras à sept degrés de liberté. Le projet relie matériel ouvert, ROS 2, simulation, téléopération, jeux de données et cellule d’évaluation dans un flux de travail que d’autres laboratoires peuvent réellement reprendre.","language":"fr","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=fr","image":{"url":"https://publicasta.com/storage/projects/10/pages/625/2026/09/e99395d4-f3a9-45ec-876e-344b3e9b036c.webp","alt":"Un bras robotique collaboratif générique dans une cellule d’évaluation de recherche standardisée, avec des caméras et des objets de calibration."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-09-16T13:58:14+00:00","updated_at":"2026-09-16T13:58:14+00:00","content_markdown":"Un bras robotique est facile à photographier, beaucoup plus difficile à reproduire. Deux laboratoires peuvent acheter un matériel officiellement identique, exécuter la même politique et pourtant recueillir des données avec des positions de caméra, des éclairages, des procédures d’étalonnage, des réglages de contrôleur et des définitions de tâche différents. Quand le résultat s’améliore, il devient difficile de savoir si le modèle a progressé ou si l’expérience a simplement changé autour de lui.\n\n ![Un bras robotique collaboratif générique dans une cellule d’évaluation de recherche standardisée, avec des caméras et des objets de calibration.](https://publicasta.com/storage/projects/10/pages/625/2026/09/e99395d4-f3a9-45ec-876e-344b3e9b036c.webp)\n\n C’est le problème auquel OpenArm 2.0 tente de s’attaquer. Le projet d’Enactic est présenté comme un bras humanoïde open source à sept degrés de liberté, mais l’évolution importante dépasse largement le mécanisme. La gamme 2.0 associe le bras à une cellule d’évaluation, un format de données, des environnements de simulation, des paquets ROS 2, des flux de téléopération et, à terme, un dispositif d’enseignement passif. L’objectif est de rendre les expériences d’IA physique transférables d’une machine à l’autre et, à terme, d’un laboratoire à l’autre.\n\n Le projet attire l’attention parce que son matériel est particulièrement accessible selon les standards de la robotique de recherche : il annonce un système bim manuel complet à 6 500 dollars, avec une voie assemblée et une voie DIY. Le prix compte, mais ce n’est pas la raison la plus forte de s’y intéresser. L’idée la plus lourde de conséquences est qu’un robot devrait être traité comme une plateforme logicielle et de données reproductible, plutôt que comme un montage de recherche fabriqué une seule fois.\n\n OpenArm est encore en développement actif. Sa propre documentation signale des ponts matériels instables, un travail toujours en cours sur MoveIt 2 et un dispositif maître KER qui n’est pas encore publié. La bonne question n’est donc pas de savoir s’il est prêt à remplacer toutes les plateformes de laboratoire. Il faut plutôt déterminer s’il est déjà utile à une catégorie précise de chercheurs et si ses limites sont assez visibles pour être gérées.\n\n ## Ce qu’OpenArm 2.0 ajoute réellement\n\n OpenArm 1.0 avait posé la proposition de base : un bras à taille humaine avec des plans matériels, des logiciels et une documentation publics. La version 2.0 conserve l’enveloppe mécanique principale, mais réorganise le projet autour d’un flux de travail. La [présentation de la version 2.0](https://docs.openarm.dev/overview/whats-new-in-2.0/) d’Enactic décrit trois éléments reliés : le bras OpenArm 2.0, l’OpenArm Cell et OpenArm KER. Ce dernier n’est pas encore commercialisé ; il faut donc le considérer comme un composant prévu, et non comme un élément utilisable aujourd’hui par les acheteurs.\n\n Le bras reste une conception à sept degrés de liberté montée sur une base en profilés MISUMI. Les spécifications publiées indiquent une charge nominale de 4,1 kilogrammes et une charge de pointe de 6,0 kilogrammes, effecteur compris. Ces chiffres aident à comprendre le domaine de recherche visé, mais ne garantissent pas que toute charge sera sûre dans chaque posture ou pour chaque mouvement. La documentation définit la valeur nominale dans une posture défavorable, sur une durée d’une minute, et la distingue d’une charge maximale de courte durée. Une pince, une caméra, un outil ou un montage personnalisé consomme une partie de cette marge.\n\n L’OpenArm Cell est l’ajout le plus important pour la reproductibilité. Elle fournit un environnement standardisé avec un arrière-plan, un éclairage et une position de caméra cohérents. Cela paraît banal jusqu’au moment où une équipe essaie de comparer des démonstrations enregistrées à plusieurs mois d’intervalle. Modifier la hauteur d’une caméra au plafond peut changer la taille apparente d’un objet. Une lumière différente peut modifier les reflets sur une tasse ou le contraste autour d’un câble. Une nouvelle surface de table peut transformer une prise apprise en simple astuce propre au banc d’essai.\n\n Une cellule ne supprime pas toutes les variations, mais elle crée une référence commune. Le [site du projet](https://enactic.ai/) décrit la cellule comme un moyen de soutenir l’évaluation automatique et de comparer les politiques robotiques au fil des itérations. C’est une promesse plus utile que l’affirmation habituelle selon laquelle le matériel ouvert démocratisera la robotique. Réduire le coût d’une plateforme aide davantage de personnes à l’obtenir ; standardiser l’expérience les aide à apprendre les unes des autres.\n\n Le troisième élément, KER, est conçu comme un dispositif d’enseignement passif, sans moteur. Enactic indique que cette conception sans actionneur est assez légère pour être portée ou installée près de l’opérateur et qu’elle vise à réduire la fatigue pendant les longues sessions de téléopération. Elle n’est explicitement pas encore disponible. Cette distinction compte, car la collecte de données actuelle repose sur les outils déjà publiés : téléopération VR/WebXR, simulation et commande directe du bras physique.\n\n ## La véritable offre est la pile logicielle\n\n Le dépôt est divisé en éléments qui correspondent à des tâches de recherche reconnaissables. Le projet principal renvoie vers la CAO du matériel, une description du robot, une bibliothèque de commande CAN, l’intégration ROS 2, des nœuds de téléopération, des environnements de simulation, une bibliothèque de jeux de données et des connexions avec Dora, un framework de flux de données. Le [guide logiciel](https://docs.openarm.dev/api-reference/) décrit une pile composée de modules pour la description du robot, la commande moteur haute fréquence, la configuration CAN, le middleware ROS 2 et des processus Python indépendants pour la commande, l’enregistrement et l’inférence.\n\n Cette modularité est précieuse parce que les équipes de robotique s’accordent rarement sur un framework complet unique. Un groupe peut vouloir ROS 2 pour les contrôleurs et MoveIt 2 pour la planification, MuJoCo pour les expériences de dynamique, un serveur de politique personnalisé pour l’inférence et un format de stockage distinct pour les démonstrations. OpenArm ne force pas ces usages dans une application monolithique. Il expose plutôt des interfaces que l’on peut remplacer ou étendre.\n\n Le revers est que l’utilisateur récupère le travail d’intégration. Ouvert ne signifie pas installation en une commande, puis résultat final. Le guide d’installation s’appuie sur Ubuntu et recommande ROS 2 Humble, tandis que la prise en charge de Jazzy est décrite comme un travail en cours, potentiellement instable. Le paquet ROS 2 exige des dépendances pour le contrôleur et l’interface matérielle. Le matériel réel nécessite des interfaces CAN et la bibliothèque bas niveau appropriée. Une équipe sans expérience de ROS passera du temps à apprendre le middleware avant d’atteindre l’expérience qui l’intéresse.\n\n La [documentation de contrôle ROS 2](https://docs.openarm.dev/api-reference/ros2/control/) rend la limite explicite. Le paquet peut exposer des commandes de position, de vitesse et de couple, et fonctionner avec un matériel simulé, ce qui facilite les tests. Mais la même page avertit que les composants de pont matériel sont en cours de mise à jour, que le pont de la pince évolue particulièrement vite et que l’intégration de MoveIt 2 est encore en développement. Ces avertissements ne sont pas une note de bas de page ; ils définissent la différence entre une plateforme de recherche prometteuse et un robot de production mature.\n\n Une évaluation pratique devrait commencer par le chemin du faux matériel. Si une équipe ne peut pas lancer la description du robot, inspecter les états articulaires et exécuter une boucle de contrôle simulée, acheter le bras ne supprimera pas le problème logiciel. Cela y ajoutera des moteurs, de l’électronique de puissance, de l’étalonnage, des limites mécaniques et des procédures de sécurité.\n\n ## La simulation est utile avant l’arrivée du robot\n\n La prise en charge de MuJoCo donne à OpenArm un point d’entrée plus solide qu’un kit limité au matériel. Le [guide de simulation](https://docs.openarm.dev/simulation/mujoco/) fournit des fichiers MJCF pour le bras et la configuration bimanuelle, puis explique comment les charger dans le simulateur de MuJoCo. Le projet utilise une commande en couple dans la simulation, plus proche du problème de contrôle qu’une simple animation d’angles articulaires.\n\n La documentation décrit aussi la simulation comme un lieu où tester le flux de collecte de données. Avec WebXR, un chercheur peut utiliser des contrôleurs VR pour piloter une version MuJoCo du bras, enregistrer des épisodes, inspecter les données produites et les convertir dans un format d’entraînement sans posséder le matériel physique. Le [tutoriel WebXR](https://docs.openarm.dev/tutorial/data-collection-webxr/) propose un parcours complet avec une interface locale de collecte, un contrôleur VR dans le navigateur, des étiquettes de réussite et d’échec et un répertoire de sortie OpenArmDataset.\n\n Cet ordre des opérations change la manière dont un laboratoire peut réduire le risque d’un projet. Une équipe peut d’abord demander si un opérateur réalise la tâche de façon fiable. Elle peut vérifier si la représentation de la tâche enregistre les observations nécessaires. Elle peut construire une chaîne d’entraînement et déterminer si l’interface d’inférence est assez rapide. Ce n’est qu’ensuite qu’elle doit affronter le coût et les exigences de sécurité du bras réel.\n\n La simulation ne révélera pas tout. La dynamique des contacts, la traînée des câbles, la température des moteurs, le jeu mécanique, le bruit des capteurs, la variabilité des objets et le comportement de l’arrêt d’urgence peuvent invalider une politique qui semble bonne dans MuJoCo. Le guide indiquait lui-même que le pont ROS 2 destiné à simuler plus fidèlement le matériel devait encore être développé après la version précédente. La simulation doit donc être considérée comme un outil d’intégration et d’itération, pas comme la preuve qu’un déploiement physique fonctionnera.\n\n Il existe une autre difficulté pratique : WebXR exige HTTPS. Le tutoriel demande de générer un certificat, d’ouvrir une page locale et d’accepter un certificat auto-signé sur l’appareil VR. C’est gérable pour un laboratoire, mais c’est exactement le genre de détail qui disparaît d’une annonce de lancement et consomme un après-midi lors de la configuration. La documentation est utile parce qu’elle expose ce détail avant l’expérience.\n\n ## La couche de données s’attaque à un problème négligé\n\n Les projets de robotique publient souvent un modèle et une courte vidéo de démonstration en laissant implicite la chaîne de données. Reproduire l’expérience devient alors difficile, même lorsque le matériel est disponible. Le travail d’OpenArm sur les jeux de données tente de faire de l’épisode un artefact de première classe.\n\n La [documentation des jeux de données](https://docs.openarm.dev/dataset/) décrit une arborescence contenant les épisodes, les données d’action et d’état, les flux caméra, les métadonnées et les informations de tâche. L’API s’organise autour d’un répertoire sur disque plutôt que d’un service de base de données. Les métadonnées sont lues au début, tandis que le reste peut être consulté au besoin. C’est une forme adaptée aux enregistrements volumineux : les équipes peuvent déplacer un jeu de données avec des fichiers ordinaires, inspecter ses métadonnées et ne traiter que les caméras ou les épisodes nécessaires à un travail donné.\n\n La référence de l’API documente les changements apportés à la structure 0.3.0. Les données d’état sont réparties entre des tables de position, de vitesse et de couple pour chaque côté du bras, tandis que les anciennes structures peuvent n’exposer que les positions. La bibliothèque comprend également une conversion vers LeRobot v2.1, depuis Python comme au moyen d’une commande. Ce pont compte, car un format propre au projet n’est utile que si les chercheurs peuvent emporter leurs données dans l’écosystème plus large.\n\n Le format ne rend pas magiquement un jeu de données comparable à un autre. Les chercheurs doivent encore enregistrer l’étalonnage des caméras, la version du robot, la configuration de la pince, l’identité des objets, les consignes de tâche, les informations sur l’opérateur, le calendrier, les tentatives échouées et les conditions de l’environnement. Une arborescence cohérente est un socle, pas un aboutissement. L’avantage est qu’OpenArm donne à ces champs un emplacement et fournit une API, au lieu de demander à chaque laboratoire d’inventer ses conventions.\n\n Les commandes de réussite et d’échec du tutoriel WebXR sont également importantes. Les systèmes d’apprentissage sont sensibles à ce qui est considéré comme un épisode réussi. Si une équipe arrête l’enregistrement après une prise presque réussie et qu’une autre ne marque comme réussite que les placements terminés, leurs jeux de données ne sont pas interchangeables, même si les robots et les caméras correspondent. Le marquage explicite des épisodes ne supprimera pas la subjectivité, mais rend la décision visible et lisible par machine.\n\n ## L’inférence est séparée de l’exécution robotique\n\n Le flux d’inférence d’OpenArm établit une frontière utile entre le code de la politique et le contrôle du robot. Le [guide d’inférence](https://docs.openarm.dev/tutorial/inference/) décrit un serveur de politique qui reçoit un paquet d’observations contenant les données caméra et les positions articulaires, exécute un modèle et renvoie un bloc d’actions en positions articulaires. L’exécution est organisée comme un flux Dora, tandis que le code propre au modèle se trouve derrière un contrat de socket local.\n\n Cette séparation offre plusieurs avantages. L’auteur d’une politique peut adapter un modèle sans réécrire le transport matériel. Une équipe peut remplacer le serveur de modèle en conservant la plomberie des observations et des actions. Une défaillance du processus de modèle peut être traitée comme un événement au niveau du processus, sans être mêlée à chaque fonction de commande moteur. L’interface est aussi plus facile à inspecter : entrées, sorties, horodatages et dimensions des actions peuvent être testés indépendamment.\n\n Cette frontière ne constitue pas un système de sécurité complet. Renvoyer un bloc d’actions JSON valide ne rend pas l’action sûre. Le contrôleur doit toujours gérer les limites, le comportement du chien de garde, les collisions, un arrêt d’urgence physique et la présence d’un opérateur capable d’intervenir. Un modèle performant lors d’une relecture hors ligne peut produire des commandes dangereuses si une caméra est masquée ou si l’état d’une articulation est retardé. La pile ouverte permet d’examiner ces couches, mais la responsabilité reste celle de l’intégrateur.\n\n C’est aussi ainsi qu’il faut interpréter avec prudence les affirmations d’OpenArm sur la conformité et la possibilité de déplacement manuel. Elles décrivent des propriétés mécaniques destinées à faciliter le travail avec contact et l’interaction plus sûre. Elles ne suppriment ni l’évaluation des risques, ni les essais protégés, ni les vitesses prudentes, ni la définition claire d’un domaine d’utilisation. Un robot que l’on peut déplacer à la main n’est pas automatiquement sûr autour de toutes les personnes, de tous les objets ou de toutes les politiques de commande.\n\n ## Qui devrait l’essayer maintenant\n\n OpenArm 2.0 peut convenir aux chercheurs qui veulent étudier l’apprentissage par imitation, la téléopération, la manipulation bimanuelle, l’apprentissage robotique à partir de démonstrations ou l’évaluation de politiques dans une cellule contrôlée. Le projet intéresse aussi les ingénieurs qui construisent des outils autour des jeux de données d’IA physique, du transfert simulation-réel, du contrôle ROS 2 et de l’inférence locale. La possibilité de commencer dans MuJoCo puis de passer au matériel offre à ces groupes un chemin de développement concret.\n\n Il peut être particulièrement intéressant pour les petits laboratoires universitaires et les chercheurs indépendants qui ne peuvent pas justifier une plateforme de recherche propriétaire, mais qui peuvent construire un système autour d’une CAO publique, de composants courants et d’un middleware ouvert. L’option DIY change aussi la relation entre le chercheur et la machine. Une équipe peut inspecter la nomenclature, adapter les montages, comprendre le chemin de contrôle et contribuer en amont. C’est un environnement d’apprentissage plus fécond qu’un robot fermé dont le mode de panne se résume à contacter le fournisseur.\n\n Le projet convient moins à une équipe qui a besoin d’une cellule de production prête à l’emploi, d’un contrat de support à long terme, d’une certification de sécurité industrielle validée ou d’une compatibilité garantie avec une pile d’automatisation commerciale figée. Il constitue aussi un mauvais premier projet de robotique pour une personne qui ne souhaite s’occuper ni de Linux, ni de ROS 2, ni du débogage électromécanique, ni de l’ingénierie des données. Le prix d’achat relativement bas par rapport aux robots de recherche ne rend pas le coût total faible. Le laboratoire a toujours besoin d’ordinateurs, de matériel d’alimentation et de communication, d’outils, de caméras, d’équipement VR s’il utilise WebXR, de pièces de rechange, de montages et de temps.\n\n Un premier projet raisonnable devrait rester étroit : un objet, un espace de travail, une configuration de pince et un petit nombre de démonstrations opérateur. Le but devrait être de mesurer toute la boucle — enregistrement, annotation, entraînement, inférence et récupération — plutôt que de produire une démonstration spectaculaire. Si l’équipe peut reproduire son propre résultat après avoir changé de machine ou reconstruit l’espace de travail, elle aura appris quelque chose d’important sur la plateforme.\n\n ## Ce qu’il faut examiner avant d’acheter\n\n Le premier examen doit porter sur les licences. Le dépôt principal réunit plusieurs licences : le dépôt matériel utilise CERN-OHL-S-2.0, tandis que plusieurs dépôts logiciels utilisent Apache-2.0. Le [dépôt OpenArm](https://github.com/enactic/OpenArm) relie chaque composant majeur et indique sa licence. Un laboratoire qui prévoit de modifier la CAO, de redistribuer une construction, d’intégrer un firmware ou de publier un dérivé commercial doit lire la licence de chaque composant, plutôt que de considérer l’expression matériel entièrement open source comme une catégorie juridique unique.\n\n Le deuxième examen doit porter sur l’alignement des versions. OpenArm comprend des modèles v1.0 et v2.0, plusieurs dépôts, des sous-modules, des distributions ROS 2 et une documentation qui évolue. Un tutoriel peut fonctionner pour une révision du bras et demander des ajustements pour une autre. Épingler les commits des dépôts, noter la distribution ROS et conserver une nomenclature lisible par machine sont des pratiques élémentaires de reproductibilité. Elles sont particulièrement importantes pour une plateforme physique, où une petite modification mécanique peut changer l’étalonnage et le comportement du contrôle.\n\n Le troisième examen doit mesurer l’écart entre un système simulé et un système réel. Lancez les fichiers de démarrage du faux matériel. Chargez le MJCF. Collectez un petit jeu de données. Convertissez-le dans le format d’entraînement prévu. Implémentez un serveur de politique qui émet des actions sans déplacer de moteur. Puis lisez les instructions destinées au matériel réel et identifiez chaque élément encore ambigu : adaptateurs CAN, configuration des moteurs, comportement de la pince, étalonnage, limites, séquence de démarrage et récupération après une perte de communication.\n\n Le quatrième examen doit concerner la maintenance du projet. GitHub montre des dépôts actifs et des travaux récents dans l’organisation OpenArm, mais l’activité ne se confond pas avec la maturité du support. Examinez les problèmes ouverts, les notes de version, le guide de contribution, les changements incompatibles, la couverture de tests et la manière dont les régressions matérielles sont communiquées. Une plateforme robotique est une dépendance aux conséquences physiques. Si une mise à jour modifie un paramètre de contrôleur, le résultat peut être plus grave qu’une compilation échouée.\n\n L’[historique des versions](https://github.com/enactic/OpenArm/releases) montre un projet qui évolue par révisions matérielles et logicielles successives, avec notamment des changements concernant le boîtier, la pince, les paquets ROS 2, des composants liés à la charge et les fichiers de simulation. C’est normal pour une jeune plateforme. Cela signifie aussi qu’un acheteur doit prévoir la maintenance et ne pas supposer qu’un instantané du dépôt équivaut à une version produit prise en charge.\n\n ## Les alternatives et la question laissée ouverte par OpenArm\n\n Les chercheurs disposent d’alternatives, mais chacune optimise une contrainte différente. Les bras commerciaux peuvent fournir un support mature et une intégration industrielle. Les plateformes universitaires établies disposent parfois d’un corpus plus important de travaux publiés, de procédures d’étalonnage connues ou d’un écosystème de données plus stabilisé. Les manipulateurs éducatifs à bas prix réduisent le seuil d’entrée, sans offrir nécessairement la charge utile, la conformité ou le flux bim anuel visés par OpenArm. Les plateformes limitées à la simulation évitent le coût matériel, mais ne répondent pas aux questions liées aux contacts et à la perception réels.\n\n Le choix distinctif d’OpenArm consiste à réunir matériel, simulation, collecte de données et évaluation au sein d’un même projet ouvert. Cela crée une possibilité de benchmarks partagés, à condition que la communauté résiste à la tentation de publier des démonstrations isolées. L’unité utile du progrès n’est pas seulement une nouvelle politique qui fonctionne sur un robot. C’est une tâche, un jeu de données, une description d’environnement, un script d’évaluation et une pile logicielle versionnée qu’un autre groupe peut exécuter et mettre à l’épreuve.\n\n Le projet révèle aussi une tension plus large de la robotique ouverte. Rendre la CAO publique ne crée pas automatiquement une communauté. Celle-ci apparaît quand les composants sont documentés, assez abordables pour être obtenus, assez stables pour être utilisés et assez structurés pour permettre la comparaison. Le travail d’OpenArm 2.0 sur la Cell et le Dataset vise précisément cette couche intermédiaire entre une conception ouverte et un véritable écosystème de recherche.\n\n Cette couche prendra du temps. Le dispositif KER n’est pas encore sorti. Le pont matériel et l’intégration de la pince sont toujours signalés comme des travaux actifs. La prise en charge de Jazzy n’est pas présentée comme complètement stabilisée. La sécurité physique, la disponibilité des composants, la qualité de l’assemblage et l’étalonnage varieront d’une construction à l’autre. L’ouverture du projet rend ces risques plus faciles à examiner, mais ne les réduit pas automatiquement.\n\n ## Le verdict pratique\n\n OpenArm 2.0 mérite un essai si l’expérience que vous voulez mener porte sur l’apprentissage à partir d’interactions physiques et si vous êtes prêt à prendre en charge l’intégration. Sa contribution la plus forte n’est ni la revendication d’un format humanoïde ni le prix annoncé. C’est la tentative de relier des éléments qui restent habituellement séparés : un robot inspectable, un modèle de simulation, une interface de téléopération, un jeu de données structuré, une frontière de politique et un environnement d’évaluation reproductible.\n\n Pour un chercheur, le meilleur point de départ est le parcours logiciel. Utilisez le faux matériel, inspectez la description du robot, lancez le modèle MuJoCo, collectez des démonstrations WebXR et examinez la sortie OpenArmDataset. Vérifiez quelle part de la tâche visée survit à la conversion vers le framework d’entraînement. Ce n’est qu’ensuite que le laboratoire devrait décider si le bras et la cellule physiques répondent à une question que la simulation ne peut pas résoudre.\n\n Pour un acheteur, le conseil est tout aussi concret : épinglez les versions, lisez les licences, prévoyez l’ingénierie de sécurité et traitez les avertissements actuels de la documentation comme une partie de la spécification du produit. OpenArm n’est pas un robot industriel prêt à l’emploi. C’est une pile de recherche publique et évolutive, dont la valeur se mesurera à la capacité d’autres équipes à reproduire, modifier et prolonger le travail.\n\n C’est une exigence élevée, mais c’est la bonne. L’IA physique ne gagnera pas en crédibilité parce qu’un robot supplémentaire produit une vidéo soignée. Elle en gagnera lorsque la même expérience pourra être inspectée, répétée, interrompue sans danger et améliorée par des personnes qui n’ont pas construit la machine d’origine.\n\n ## Sources\n\n - [Dépôt OpenArm](https://github.com/enactic/OpenArm) — Enactic, Inc.\n- [Nouveautés d’OpenArm 2.0](https://docs.openarm.dev/overview/whats-new-in-2.0/) — documentation OpenArm\n- [Site du projet Enactic OpenArm](https://enactic.ai/) — Enactic, Inc.\n- [Documentation de contrôle ROS 2](https://docs.openarm.dev/api-reference/ros2/control/) — documentation OpenArm\n- [Guide de simulation MuJoCo](https://docs.openarm.dev/simulation/mujoco/) — documentation OpenArm\n- [Collecte de données par téléopération VR avec WebXR](https://docs.openarm.dev/tutorial/data-collection-webxr/) — documentation OpenArm\n- [Présentation d’OpenArm Dataset](https://docs.openarm.dev/dataset/) — documentation OpenArm\n- [Référence de l’API OpenArm Dataset](https://docs.openarm.dev/dataset/api/) — documentation OpenArm\n- [Guide d’inférence OpenArm](https://docs.openarm.dev/tutorial/inference/) — documentation OpenArm\n- [Historique des versions OpenArm](https://github.com/enactic/OpenArm/releases) — GitHub\n- [Bibliothèque de contrôle CAN OpenArm](https://github.com/enactic/openarm_can) — GitHub\n- [Enactic publie OpenArm, un bras humanoïde à 7 degrés de liberté pour la recherche en IA physique](https://deniz.in/enactic-open-sources-openarm-a-7dof-humanoid-arm-for-physical-ai-research) — Deniz Genc","available_translations":[{"language":"ar","title":"OpenArm 2.0 يجعل تجارب الذكاء الاصطناعي الفيزيائي القابلة لإعادة الإنتاج هي المشروع الحقيقي مفتوح المصدر","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=ar"},{"language":"de","title":"OpenArm 2.0 macht reproduzierbare Physical-AI-Experimente zum eigentlichen Open-Source-Projekt","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=de","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=de","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=de"},{"language":"en","title":"OpenArm 2.0 makes reproducible physical-AI experiments the real open-source project","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=en","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=en","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=en"},{"language":"es","title":"OpenArm 2.0 convierte los experimentos reproducibles de IA física en el verdadero proyecto de código abierto","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=es","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=es","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=es"},{"language":"fr","title":"OpenArm 2.0 fait de la reproductibilité des expériences d’IA physique le véritable projet open source","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=fr"},{"language":"pl","title":"OpenArm 2.0 sprawia, że powtarzalne eksperymenty z fizyczną AI stają się właściwym projektem open source","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=pl"},{"language":"ru","title":"OpenArm 2.0 превращает воспроизводимые эксперименты с физическим ИИ в настоящий open-source-проект","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=ru"},{"language":"zh","title":"OpenArm 2.0：让可复现的实体 AI 实验成为真正的开源项目","html_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=fr","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=fr","html":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=fr","canonical":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=fr","markdown":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=fr","json":"https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=fr","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}