Un projet publié sur Open Robotics décrit un poste de travail ergonomique piloté par ROS 2, où des bras PiPER ajustent un écran et un clavier à partir de données de vision 3D. Le prototype associe un bras robotique AgileX PiPER, une caméra Orbbec RGB-D et des briques de perception pour suivre la position du visage ou des mains.
Le principe est simple à formuler, plus délicat à exécuter : faire bouger des éléments de bureau en fonction de la posture de l’utilisateur. Dans la chaîne « écran », la caméra détecte le visage, estime sa position 3D, publie une transformation TF, puis calcule une pose cible pour le bras qui porte ou oriente l’écran. Dans la chaîne « clavier », une caméra placée en bout de bras et MediaPipe Hands servent à faire suivre un plateau de clavier par la main.
ROS 2 comme colonne vertébrale du prototype
Le dépôt GitHub associé présente deux espaces de travail séparés : un pour le clavier, un pour l’écran. Cette séparation n’est pas cosmétique. Les deux chaînes réutilisent des paquets au même nom, avec des versions différentes, et les auteurs préviennent qu’il ne faut pas les superposer dans le même environnement ROS sans précaution.
Le matériel cité reste accessible à un laboratoire ou à une équipe d’intégration : Ubuntu 22.04, ROS 2 Humble, Python 3.10, le SDK ROS 2 d’Orbbec, le pilote PiPER et une liaison CAN. Pour l’écran, le projet prévoit d’abord une vérification perception seule, sans envoyer de commande au bras. Pour le clavier, la documentation mentionne une boucle de servo-vision à 150 Hz, des distances de sécurité et un verrouillage d’un axe du bras.
Un prototype utile, pas un produit certifié
Le point fort du projet est sa transparence technique. Les auteurs détaillent les limites de sécurité : pas de certification fonctionnelle, pas de détection complète de collision, noms ROS globaux par défaut, même interface CAN par défaut, et nécessité de ne lancer qu’une chaîne de commande réelle à la fois. Ils recommandent aussi des espaces de noms séparés, des ports CAN distincts et des préfixes TF avant toute intégration multi-bras.
Cette prudence est importante. Un bras qui déplace un écran ou un clavier près d’un humain n’est pas un gadget logiciel : il peut heurter l’utilisateur, coincer un câble ou créer un mouvement inattendu. L’intérêt du projet vient précisément de ce réalisme. Il montre comment une idée d’interface physique intelligente peut être reconstruite avec des composants robotique standard, tout en exposant les points qui manquent pour passer du laboratoire à un usage sûr.
Notre analyse
Ce type de prototype donne une bonne lecture de la robotique de service à court terme. Avant les assistants humanoïdes généralistes, il existe un terrain plus concret : des machines spécialisées qui adaptent l’environnement de travail, réduisent les postures pénibles et collectent de la donnée sur des interactions simples.
La publication ne prétend pas présenter un produit industriel prêt à vendre. Elle vaut plutôt comme démonstrateur reproductible pour les équipes ROS qui veulent tester perception, TF, commande de bras et contraintes de sécurité dans un cas lisible. C’est souvent par ces briques modestes que les systèmes robotiques utiles progressent réellement.
