Les moteurs de chaque bras SO-101 reçoivent un identifiant distinct et partagent le débit de communication du contrôleur. Ils sont réglés un par un avant leur raccordement en chaîne. Le bras pilote et le bras suiveur sont ensuite calibrés séparément pour faire correspondre leurs valeurs de position.
Sur Reachy Mini Wireless, le SDK JavaScript établit une session WebRTC après authentification Hugging Face. Vidéo, audio et commandes passent ensuite directement entre le navigateur et le robot.
Avec `playMove`, le navigateur transmet une fois le mouvement enregistré et son audio éventuel au Reachy Mini Wireless. Le démon cadence ensuite les positions et lit le son sur une même horloge locale, sans échange réseau pour chaque position.
Sous ROS 2 Humble, Bringup fonctionne sur le TurtleBot3 et Nav2 se lance sur le PC distant. L’exemple ROBOTIS pour un Burger définit TURTLEBOT3_MODEL=burger et transmet une carte existante avec map:=$HOME/map.yaml.
Avec un LeKiwi filaire, les programmes du robot et du bras pilote se lancent sur l’ordinateur, sans installer de Raspberry Pi ni configurer SSH. Il faut encore assembler le robot, installer les composants logiciels, configurer les moteurs et calibrer les deux bras ; les roues ne nécessitent pas de calibration.
Dans le SDK Python xArm, UFACTORY associe en 1.17.0 de nouveaux noms aux appels du capteur de force et de couple et du moteur linéaire, puis en 1.17.1 à cinq appels RS485. La liste indique les noms et les versions, sans établir à elle seule la compatibilité d’un ancien script.
Le bras suiveur du SO-101 utilise six moteurs au rapport de 1/345. Le bras pilote combine des rapports de 1/191, 1/345 et 1/147 pour soutenir son poids et rester déplaçable à la main, selon LeRobot.
OpenCR est la carte de commande du TurtleBot3 : elle communique avec ROS, pilote les moteurs DYNAMIXEL et offre des connexions pour des capteurs et périphériques. L’ordinateur embarqué assure le calcul principal. Les interfaces et alimentations indiquées par ROBOTIS ne garantissent pas la compatibilité d’un composant particulier.
Sous ROS 2 Humble, Bringup démarre sur le TurtleBot3 avant Cartographer sur le PC distant. La carte apparaît dans RViz pendant le déplacement, puis map_saver_cli l’enregistre en fichiers map.pgm et map.yaml.
VENTUNO Q associe un microprocesseur destiné à Linux et ROS 2 à un microcontrôleur chargé de fonctions proches des roues et des capteurs. Une bibliothèque RPC relie les deux. Arduino propose cette architecture pour prototyper une base mobile, sans présenter son exemple comme un robot construit.
Le SDK Python d’UFACTORY propose des commandes pour le bras xArm et sa pince, ainsi que des lectures de position, d’état et d’erreur. Il permet aussi de lire les données du capteur de force et de couple, de l’activer et de le mettre à zéro.
Stretch 3 peut tenter de ramasser un objet et de le déposer dans un récipient désignés par des mots. Avec le serveur Stretch AI sans prise en charge de la caméra D405, Hello Robot indique que les mouvements simples et l’affichage d’images restent possibles, contrairement à ce ramassage et à l’apprentissage par démonstration.
ROBOTIS présente TurtleBot3 comme une base mobile pour apprendre ROS, personnalisable sur les plans mécanique et électronique. Le Raspberry Pi 4 est annoncé comme ordinateur embarqué standard. Le Jetson Nano est également pris en charge matériellement, avec une configuration préalable de son kit de développement.
Reachy Mini Wireless exécute ses logiciels sur un Raspberry Pi CM4 embarqué, tandis que Lite les exécute sur un ordinateur externe et reçoit son alimentation du secteur. Le tableau de bord permet d’ajouter des applications ; une interface dans le navigateur sert à commander le robot, tandis que Python permet d’en programmer le comportement. La compatibilité des applications avec chaque version et leur fonctionnement entièrement hors ligne restent non vérifiés.
Aletta, développé par Vitestro, combine proche infrarouge, échographie et Doppler pour repérer le vaisseau avant de prélever le sang et de manipuler les tubes. IEEE Spectrum le présente comme autonome et rapporte une autorisation américaine pour les adultes hors hospitalisation. La différence de méthode décrite ne démontre pas de supériorité clinique sur le geste manuel.
Le bras pilote commande celui du LeKiwi, tandis que le clavier déplace sa base. Ce pilotage fonctionne sous X11, sur un bureau Windows et sous macOS avec les autorisations requises, mais pas sous Wayland ni dans une session sans interface graphique. Les touches de contrôle de l’enregistrement ont des conditions différentes.
Les fabricants du Roomba Max 875 Combo et de Matic annoncent des fonctions de navigation, d'évitement ou de recharge pour le nettoyage. Leur fiabilité dans des logements variés, leur maintenance et leurs volumes de production restent insuffisamment documentés de manière indépendante.
La disponibilité commerciale n'est pas mondiale par défaut. Au 2 septembre 2026, iRobot annonce le Roomba Max 875 Combo en Amérique du Nord, tandis que Matic expédie uniquement aux États-Unis. Les prix locaux, services et volumes de production ne peuvent pas être déduits de ces annonces.
Un robot domestique associe capteurs, logiciel et mécanismes pour accomplir une action physique dans un logement. Le Roomba Max 875 Combo et Matic montrent comment navigation, nettoyage et retour à la station peuvent former une autonomie limitée à une mission.
Un robot domestique agit physiquement dans le logement et reste généralement spécialisé dans une tâche. Le Roomba Max 875 Combo et Matic illustrent le nettoyage autonome, avec des fonctions annoncées de navigation ou de recharge. Leur accès dépend du territoire et les données examinées ne permettent pas d'établir indépendamment leur maturité ni leurs volumes de production.
Pour confirmer prix et disponibilité, il faut identifier le mode d'accès, la version, le pays, la date, les services et le délai. Atlas, Unitree H1, Go2 et UR16e illustrent des situations différentes : accès partenaire, devis ou achat annoncé avec variantes et frais exclus.
Capacité d'usine, objectif, commande, livraison et unités en service ne sont pas interchangeables. Les volumes d'Atlas, du Unitree H1 et du B2 restent non vérifiés dans les sources actuelles. Une mesure solide doit préciser la période, la version du robot et l'étape réellement atteinte.
Un prototype vérifie une architecture, une démonstration montre une capacité, un pilote teste l'intégration, un accord engage les parties et l'exploitation produit des mesures. Ces étapes ne doivent pas être fusionnées en une seule étiquette de maturité.
La maturité d'un robot progresse par étapes qui doivent rester distinctes. Une démonstration montre une capacité, un pilote teste un usage, un accord fixe un cadre commercial et l'exploitation mesure la durée et les résultats. Atlas et Digit illustrent des positions différentes sur ce chemin.
Un robot peut être programmé, entraîné en simulation, guidé par des démonstrations ou combiner ces approches. S1 illustre l'utilisation d'une vidéo comme contexte, mais la preuve d'apprentissage exige des essais répétés, des variations et une mesure claire des échecs et interventions humaines.
La robotique désigne le système physique complet. Physical AI met l'accent sur la perception et l'action dans le réel, tandis qu'Embodied AI insiste sur le rôle du corps et de l'environnement. Les modèles vision-langage-action constituent une couche logicielle, pas un robot complet ni une garantie de performance.
Physical AI décrit une intelligence artificielle reliée à des capteurs et à des actionneurs. Le robot perçoit, décide, agit puis observe les conséquences. Cette catégorie ne garantit pas la fiabilité : le corps, les contrôleurs, les conditions d'essai et les interventions humaines restent déterminants.
Physical AI relie perception, raisonnement et action dans le monde réel. Embodied AI insiste sur le rôle du corps, de ses capteurs et de ses limites. Des modèles comme Gemini Robotics ou S1 illustrent cette évolution, mais leurs démonstrations doivent encore être confrontées à des mesures indépendantes et prolongées.
Téléopération et autonomie forment un continuum. Atlas est présenté comme fonctionnant avec une supervision minimale, tandis que la locomotion autonome annoncée du Unitree H1 ne suffit pas à établir l'autonomie d'une mission complète. Les reprises humaines et leur durée doivent être mesurées dans la tâche réelle.
Les principaux humanoïdes industriels ne sont pas tous proposés sous la forme d'un achat classique. Atlas passe par des partenaires sélectionnés, le Unitree H1 par un devis et Digit apparaît dans un contrat de robots-as-a-service. Le coût utile doit inclure configuration, intégration, supervision, maintenance et conditions de service.
La disponibilité d'un robot humanoïde peut prendre la forme d'un accès partenaire, d'un contrat de service, d'un devis ou d'une vente plus ouverte. Atlas reste réservé à des utilisateurs sélectionnés, Digit apparaît dans des contrats industriels nommés, le Unitree H1 passe par une discussion commerciale et la disponibilité du G1 reste à qualifier.
Un robot humanoïde reprend une partie de l'organisation du corps humain afin d'agir dans des espaces conçus pour des personnes. Cette morphologie ne garantit ni autonomie, ni polyvalence, ni maturité industrielle. Les différences de taille, de masse et de charge entre Atlas, Digit, Unitree G1 et H1 montrent pourquoi chaque machine doit être examinée à partir de sa tâche réelle.
Agility Robotics annonce un accord de service avec Toyota au Canada après un pilote de Digit. Face à lui, le Unitree G1 suit une trajectoire plus compacte, encore principalement décrite par sa fiche technique.