Certains robots peuvent être contrôlés en continu par un système extérieur. C’est tout simplement une télécommande comme en radiomodélisme. Une approche différente de la robotique mobile autonome qui est privilégiée dans nos projets.
Cependant la mise en oeuvre est intéressante et certains cas s’y prêtent tout particulièrement : c’est le cas d’un humanoïde comme celui que nous étudions au club. Au moins dans un premier temps, il est plus facile de lui faire exécuter des positions et des enchainements que nous pouvons définir à distance, et ainsi apporter une correction continue et temps réel afin d’apprendre les premiers pas de marche.
Ce fonctionnement a été théorisé par une équipe de docteurs en robotique coréens et mis en pratique dans un environnement de programmation de robots (basé sur Eclipse) : Roboid Studio destiné à toute une gamme d’appareils robotiques (semblables à des robots, d’où le nom "rob-oid" comme dans "human-oid") mais qui ne sont pas autonomes.
L’approche
Je vous invite à lire (en anglais) le document "manuel partie 2" de Roboid Studio disponible sur cette page. Je n’en fais pas une traduction complète mais je vais essayer d’en présenter les grandes lignes. Merci à Thomas de Robopolis pour me les avoir fait connaitre, et merci à Kwang-Hyun Park pour ses explications.
Le roboïde, un presque-robot
Un système roboïde est pensé comme une marionnette. Pour mémoire, il s’agit d’un jouet articulé entièrement contrôlé par des fils, avec une poignée (croix en bois par exemple) qui représente les mouvements de la marionnette, tenue par un marionnettiste qui transmet en continu à la poignée les mouvements qu’il veut faire exécuter.
Dans le cas d’un roboïde, la marionnette est l’objet électronique et mécanique, les fils sont le réseau sans-fil ou le câble USB et le manipulateur humain est le programme exécuté sur une machine connectée.
L’élément que je n’ai pas cité est le plus important : c’est la poignée. Il s’agit d’une représentation intermédiaire qui transite entre la machine et l’objet électronique. C’est une "vue" de l’objet sans être forcément fidèle : "lever la main de la marionnette" devient "pencher la poignée sur le côté".
Dans Roboid Studio, ils l’appellent "simulacrum" et en donnent une définition très intéressante d’un point de vue modélisation. C’est ce qu’en génie logiciel on appelle une MDA : Model Driven Architecture.
Le contrôle par bitmap
La conception d’un roboïde ayant pour but de simplifier la conception et la réalisation de l’objet électronique et/ou mécanique (et faire baisser son prix tout simplement), il n’y a plus de place pour une électronique autonome. Tout est réservé pour le dispositif de communication et la traduction en entrées/sorties/contrôleurs.
Il faut donc pouvoir indiquer au robot ce qu’il doit faire en continu, et de même recevoir l’intégralité de ses capteurs puisqu’il n’y a pas de boucle interne de réaction aux événements extérieur.
Pour cela, il existe plusieurs systèmes : on connait déjà (avec l’interface ligne de commande de nos robots de la Coupe de France ou même du Pobot Easy) le "command control" qui consiste à envoyer des ordres plus ou moins haut niveau (avance de 30 centimètres, fait tourner le moteur gauche, cligne des yeux, fait le haka) qui vont durer un certain temps et vont correspondre à un enchainement d’actions élémentaires connus de la mémoire du robot.
Le système par "bitmap" consiste à envoyer un flux continu des représentations (ou simulacrum) de l’objet afin de lui faire connaitre les états successifs qu’il doit prendre. Comme pour une séquence animée d’images, on gère ainsi à une fréquence fixe le fonctionnement du robot. On va pouvoir faire intervenir des concepts empruntés à la vidéo : timeline, key frame, interpolated frame, etc...
Protocole réseau
Ce type de commande change radicalement la communication avec le robot : la fréquence des messages est fixe et la taille des messages est fixe. Si le canal (réseau, câble) est suffisament bien dimensionné, il n’y aura pas de surprise : pas de "flood" (inondation de messages simultanés).
La similitude avec la gestion de "bitmaps" ou d’images est de nouveau observée : on va pouvoir compresser les informations, utiliser un buffer, voire implémenter une gestion d’erreur du côté du roboïde, en lui demandant de reconstruire les images manquantes !
Je ne rentrerai pas dans les détails, notamment je ne vais pas présenter le protocole particulier utilisé par Roboid Studio car ce n’est pas l’objet de cet article et vous verrez dans la partie pratique qu’on ne va pas l’utiliser.
La mise en oeuvre 1
Essayons d’implémenter un contrôle bitmap avec notre robot bipède : on va se contenter de 4 pixels, qui seront les 4 articulations possibles, donc les 4 positions des servomoteurs des hanches et des genoux. Ce n’est pas la meilleure approche, car il faudrait définir dès le début un "simulacrum" fidèle à l’ensemble des entrées/sorties du robot : les deux capteurs de distance, l’état des batteries, etc... etc... afin qu’ensuite il n’y ait plus de mise à jour du logiciel embarqué, et seulement générer une plus grande variété d’images possibles.
Voici le simulacrum correspondant :
Le protocole de communication ne va pas changer. On reste avec une liaison série asynchrone bidirectionnelle comme on sait le faire.
Et voici les flux de données pour chaque image (bitmap) montante ou descendante :
La mise en oeuvre 2
On peut également utiliser le firmware "Firmata" pour Arduino, qui implémente toutes les entrées sorties de la carte Arduino, y compris les servomoteurs, accessibles et modifiables en continu par liaison série.
On avait déjà testé Firmata sur le bipède, pour des tests avec Pure Data (voir l’article "servomoteurs et puredata". Nous avons donc repris le code et implémenté un séquenceur.