Malgré une vie professionnelle particulièrement bien remplie depuis trois mois, j’ai grapillé quelques heures par-ci par-là afin de poursuivre le projet.
J’ai pu progresser sur trois axes.
Le look de REMI.
J’ai effectué de nombreux masques adaptables sur les capteurs ultrasons SR04 du robot. Cela m’a permis de disposer au final d’une série de visages remplaçables et de m’initier avec ma petite fille à la pâte fimo : -)
Essais de visages interchangeables pour capteurs ultrasons SR04.
REMI dispose donc maintenant de son masque d’origine, d’un masque légo, et d’une série de visages adaptables et remplaçables. Au niveau du plastron j’ai également réalisé deux nouveaux modèles. L’un est basé sur une demi boîte de conserve qui protège bien la carte arduino en donnant une allure de science-fiction bricolée, l’autre est en tetrapak et trop “propre” à mon goût. Les deux sont renforcés par une éponge emballée dans du cellophane afin d’absorber les chocs en cas de chute avant lors de la commande du robot tangible à partir du monde virtuel.
Enfin, j’ai mis en couleur les membres du robot. Comme le plastique des armatures de chez robotis est impossible à peindre, j’ai fouiné sur le net et trouvé deux solutions. L’une est de teindre les pièces mais cela nécessite de sacrifier deux casseroles et d’enfumer pas mal la maison. L’autre est tout simplement d’utiliser des marqueurs indélébiles. J’ai opté pour cette deuxième solution en démontant les membres, en appliquant du marqueur de deux couleurs (afin de bien latéraliser les couleurs, ce qui servira plus tard le scénario), et en remontant le robot. J’aime bien le résultat.
Plastron “old school” et visage fimo-diable + marqueur. Utiliser de la fimo “argent”+ marqueur = effet émail.
Comme je l’ai expliqué, j’ai pris du retard car mes scripts sur la francogrid provoquaient le plantage de l’île 3D sur laquelle était le robot. Il me fallait donc attendre que quelqu’un remette l’ile en marche pour continuer, à chaque crash. Tout cela va beaucoup mieux grâce à Gil Rebetez. Gil est un passionné de mondes virtuels contributeur actif de la francogrid, qui a mis au point un système génial d’administration web. En gros, depuis un smartphone ou un navigateur, il vous est possible de redémarrer, stopper une île entière à la demande ! Non seulement Gil a mis gracieusement à ma disposition son système, mais il a mis à ma disposition une île entière pour les tests : l’île “robots” dans la francogrid !
Interface web d’administration complète de SIM opensim par Gil.
C’est donc grâce à lui que je peux tester et modifier à mon aise les développements en relançant via mon téléphone mobile l’île en cas de problème. Entre nous, le système d’administration de Gil a de mon point de vue un grand avenir, avec la propagation du système opensim et d’hypergrid. Et la francogrid est un espace de prototypage génial, tranquille et truffé de talents.
MERCI GIL !
Troisième axe, le débogage.
Je me suis aperçu que le système avait de nombreuses “sautes”. Plus précisément, le robot détecte correctement les avatars, la personne physique, les met en présence avec le système, puis d’un seul coup la personne physique disparait. Puis revient, etc.
J’ai dupliqué la base de donnée, changé les scripts et recodé le robot afin d’être certain que celui que j’ai posé dans la nouvelle île de prototypage ne subissait pas d’interférences de l’ancien. Non.
Après de nombreux tests, il en découle une bonne et une mauvaise nouvelle. La bonne nouvelle c’est que mon code est intègre et fonctionne correctement. La mauvaise, c’est que les capteurs ultrasons du robot tangible sont efficaces pour détecter une présence mais pas pour la vérifier en permanence.
En effet, les ultrasons rebondissent bien sur les murs mais pas tellement sur la chair, les pull-overs, etc. Donc le robot tangible détecte, perd et retrouve la présence d’un humain face au robot de manière très peu fiable. Comme la passerelle de communication est maintenue tant qu’un avatar et un humain sont considérés comme face à face, elle saute…
Je suis donc en ce moment même en train de réfléchir aux mesures à prendre.
- soit je rajoute un capteur tiers par exemple sur une chaise, qui envoie des messages aux robot (par ex une led infrarouge)
- soit je change le principe et au lieu de tester en permanence la distance ultrason je génère un signal d’alerte ponctuel de la présence ou de l’abscence d’humain
- soit… ?
De toute façon, cela ne change rien à ce qui reste à faire :
- ajouter une deuxième caméra au dispositif afin de filmer le robot tangible vu de dessus, et câbler cette caméra sur un tapis virtuel, en plus de la caméra numéro 1 déjà active. Cela n’est pas très jouissif car ces problèmes techniques ont déjà été résolus pour la caméra numéro 1.
- régler la matérialisation de ce tapis écran au bon endroit au bon moment, comme cela a été fait pour l’écran de la caméra numéro un.
Problèmes réglés :
- Apparition d’une sphère bleue lors de la détection conjointe de la présence avatar/humain et lancement d’un écran virtuel avec passerelle vidéo live : ok.
- Apparition d’une poseball marquée “assied-toi” à ce moment là : ok
- Matérialisation d’un pad de jeu vidéo en 3D lorsque l’avatar s’assied sur la poseball et contrôle du robot tangible depuis le monde virtuel : ok
- Ajout du mode télécommande au robot tangible et gestion des changements de mode : ok.
- Détection de chute côté robot tangible et remise sur pied : ok.
Pas mal d’avancées depuis la mise en place de la passerelle vidéo. Dans les pistes à explorer j’évoquais la coopération d’un avatar et d’une personne au travers le guidage du robot tangible vers une cible. Pour cela j’ai en effet tenté une piste de fainéant consistant à reprendre les mêmes commandes et caractères échangés dans le processus, pour piloter le robot dans un nouveau mode “esclave” où il est télécommandé.
Le principe est qu’une fois la jonction établie par détection de la co-présence humain tangible/avatar on lance la passerelle vidéo interpersonnelle puis on matérialise une boule avec la mention “assieds toi”.
En s’asseyant sur cette boule deux choses vont se passer :
- le sol de la “zone de contact” deviendra un écran vidéo en direct avec une vue de dessus du robot.
- un pad virtuel 3D apparaît et permet à l’avatar de piloter le robot en cliquant sur des fleches directionnelles.
Je me suis concentré sur cette partie. Cela fonctionne.Mais que se passera-t-il si le robot venait à tomber en déplaçant ? L’avatar aurait bien du mal à le relever… J’ai donc ajouté un capteur de chute maison et créé une routine pour régler ce problème.
Puis j’ai relié le pad 3D au robot. Voici une courte vidéo de démonstration des premiers essais.
Mais la vraie difficulté c’est la transition entre les modes de fonctionnement. J’ai finalement arrêté de ruser avec la version précédente et revu tout le système par l’ajout d’une colonne “mode” dans la base de donnée. J’ai donc recodé en conséquence le programme de la carte arduino, les pages php qui interrogent la base de donnée, et le script python qui transmet les informations dans les deux sens avec le robot tangible. Puis j’ai recodé différemment les objets virtuels. Hélas, lors des essais j’ai crashé les îles virtuelles de la bibliothèque du metavers, et deux bacs à sables 3D sur la Francogrid. Merci à @taovacano et @metopen qui m’ont aidé pour relancer les îles. Mais cela m’inquiète beaucoup.
J’ai également tenté de refaire une beauté à REMI avec des légos. La contrainte est qu’il ne faut surtout pas obturer le champ des radars ultrasons qui ratissent l’espace avec un angle de 15 degrés. Donc le nez ne pourra pas être très long :-)
Un blindage de protection a été ajouté afin de prévenir les dégats des chutes avants en mode “esclave” (mode télécommande depuis le monde virtuel). Le système consiste dans une éponge végétale presque sèche enveloppée dans de la cellophane et plaquée sur le montage, comme un coussin. Le tout est enfermé dans un boitier fabriqué avec une boîte de tabac à rouler. Un élastique assure la fixation, des trous permettant la sortie de l’antenne du récepteur APC220, l’alimentation électrique de la carte et le branchement-débranchement sur l’ordinateur.
Prochaine étape, la combinaison des passerelles vidéo avec le mode esclave, et surtout la gestion de la sortie de ce mode : il faut proprement faire disparaitre les objets 3D qui ne sont plus dans le contexte. Ensuite, nous pourrons regarder de plus près le pilotage des objets tangibles par le robot. Pour le moment le seul test a été fait avec l’extinction/allumage de ma TV par REMI. Mais ça marche.
Ici la sphère bleue se matérialisant lors d’une “jonction”.
Juste quelques mots pour présenter cette courte vidéo de premier prototypage de la mise en relation automatique par REMI, via ses zones de contact.
Le principe : REMI lève le bras droit quant il y a un humain face à lui. REMI lève le bras gauche quand il y a un avatar face à lui. Ceci indique (pour humains et avatars) la présence d’une personne avec laquelle entrer en contact. Si un humain s’approche alors de REMI ou si un avatar entre dans la zone de contact, REMI prend une position de “jonction” et déclenche une passerelle vidéo.
Ici la passerelle vidéo expérimentale a été montée vite fait samedi matin. J’utilise un service de streaming vidéo live sur webcam ou smartphone (Ustream) , qui propose une pop up vidéo presque plein écran. J’ai récupéré l’url de cette fenêtre, ce qui me donne accès au direct s’il y en a un en cours. Puis j’ai appliqué cette url comme texture sur un écran virtuel, et étiré le résultat pour masquer la publicité. Enfin, j’ai intégré cet écran virtuel dans un objet qui le matérialise à la volée lors d’une jonction humain/avatar détectée dans le monde virtuel. Je n’ai pas eu le temps d’affiner, et comme j’ai eu des problèmes avec le lancement automatique de la lecture, j’ai ajouté une texture “cliquez-moi” faite en traitement de texte. Lors du clic la lecture se lance. Ca me rappelle les bons vieux mashups (et même SLashups) avec mon ami @loichay :-)
Lorsque la jonction est rompue par la sortie d’un des protagonistes (physiquement ou virtuellement), l’écran virtuel s’autodétruit.
J’ai également commencé à explorer une suite possible.
La personne visible et audible en vidéo devrait aider l’avatar à piloter un robot tangible. L’avatar verrait le sol de la zone de contact se transformer pour lui donner une vue partielle de dessus, sur le robot en question (en direct, via une autre caméra).
Grâce à un pad virtuel en 3D il devrait amener le robot vers une cible visible uniquement de la personne physique. L’idée est d’amener ces deux personnes à partager une expérience de coopération appelant leur attention (ouïe, vue, etc) indépendamment d’attributs soi-disants “réels” ou “virtuels”. L’idée est de construire une expérience d’attention commune interactive, précise, et synchrone.
Il sera intéressant de questionner les participants après l’expérience pour voir avec quels mots ils décriront ce simple jeu (“le robot “réel” ? “L’avatar du robot” ? “Tu parles d’un tel, mais c’est un avatar ? ” , “La cible tu la vois de quel côté ? “, etc …). Ceci mettra en évidence la pauvreté de la dualité réel/virtuel et nos difficultés pour qualifier une expérience mixte, même simple et facile à vivre.
Première idée de variante : le robot guidé depuis opensim serait un autre robot.
J’ai fait un essai en commençant des tests de pilotage de mon Isobot par l’émetteur infrarouge maison de REMI, lui-même recevant des ordres depuis opensim (monde virtuel 3D). J’aime beaucoup mon Isobot. Il est grand comme ma main , mais trop fragile. Voici a quoi il ressemble :
Cela m’a conduit à réfléchir à l’intégration de modes différents dans le programme de l’arduino, histoire d’avoir un mode pour l’indication de présence par les deux facettes de REMI (tangible, virtuelle) et un mode de pilotage-télécommande robotique via opensim. Il y a du boulot…
Deuxième variante : avec le bioloid REMI.
Au final, cela semble réalisable avec l’Isobot (en reprenant d’anciens travaux), mais j’ai envie de profiter au maximum de REMI…
Si il doit marcher debout, il peut tomber. je lui ai donc ajouté un petit détecteur de choc (tilt sensor) afin qu’il puisse se relever automatiquement. Le lancement de commandes infrarouges sera conservé pour allumer un écran plasma câblé sur opensim (tests effectués sur la TV). La connectique de REMI et son code sont modifiés en conséquence.
Concernant le pilotage de REMI depuis le monde virtuel l’intuition du fainéant c’est d’utiliser le même nombre et les mêmes commandes que celles que je gère déjà mais en effectuant un changement de mode.
Dans un premier mode le programme marche en pilotage/indication de présence, dans l’autre on aurait une sorte de télécommande avec fléches et pad 3D matérialisés dans le monde virtuel, la vidéo avec la personne physique sur le torse de REMI 3D, et une vidéo de dessus de REMI en train de se déplacer dans l’espace physique plaquée sur le sol de la zone de contact côté avatar.
Il y en a pour pas mal d’heures, d’autant que je n’ai pas le temps de revoir le code et que chaque augmentation de complexité augmente le délai de réaction et abaisse la fiabilité. J’ai l’impression d’avancer mais de bâcler de plus en plus. Il va bientôt falloir faire un point d’étape pour nettoyer le code, mais JE N’AI PAS LE TEMPS :-( Et puis il faut que je suive mes idées pendant qu’elles fusent, quitte à les abandonner pour en avoir d’autres.
J’ai installé une zone de prototypage sur Francogrid , et réalisé un mannequin me permettant d’effectuer des tests de réactivité du système côté tangible et 3D de l’espace.
Ces tests sont cruciaux afin de pouvoir déterminer l’agencement des éléments.
Par exemple, si je veux provoquer un face à face vidéo entre un avatar et une personne dans une pièce, et que les deux font face à un même robot “réel” et “virtuel”, cela veut-il dire que les deux dimensions du robot sont représentées dos à dos ? Vous me suivez ? :-)
Voici une courte vidéo de démonstration du système.
(Ndlr :Ma langue fourche, au début, quand je dis “dans la partie virtuelle”. En fait je fais deux fois la démonstration avec le geste tangible, puis ensuite avec mon avatar.)
J’ai depuis complété la chaîne des événements en ajoutant une sphère bleue brillante qui entoure l’avatar et le robot si la jonction physique/virtuelle est déclenchée.
J’ai également ajouté un émetteur infrarouge maison sur la tête de REMI afin d’effectuer le plus rapidement possible les tests de pilotage d’objets dans la pièce physique.
Feuille de route :
- import 3D direct des pièces du robot au format CAO (échec pour le moment)
- Mise en place d’une passerelle vidéo avatar/sujet au moment de la jonction (j’aimerai avoir le web on a prim…à vérifier).
- Modification du circuit avec l’intégration de l’émetteur infrarouge et tests.
- Habillage de l’espace mixte de test (et notamment avec crédits et remerciements pour les parrains et marraines de REMI).
Bon. Puisque nous sommes maintenant capables de faire communiquer les capteurs tangibles ou virtuels d’un objet (le robot) ayant des parties dans les dimensions réelles ou virtuelles d’un espace, il s’agit de s’attaquer à la question de la représentation du robot dans le monde virtuel.
Pour cela la francophonie a la chance de disposer d’une grille de serveurs de monde virtuel en 3D utilisant l’excellent solution opensimulator. J’ai nommé la Francogrid.
J’ai donc :
créé un avatar nommé remi robot sur francogrid.org
et surtout, je me documente énormément car il va falloir faire bouger des éléments 3D en lien avec les capteurs de mouvement des personnes physiques et des avatars.
Pour cela, j’ai d’abord relié des objets virtuels aux capteurs ultrasons fixés sur le robot “tangible”. En fonction de la distance d’un obstacle, la couleur d’un objet change. Ca marche.
Ensuite, grâce à l’excellent guide en français de scripting en LSL de Bestmomo Lagan (linden script langage) je suis en train de regarder comment effectuer des rotations à partir d’un mannequin très simplifié (buste et bras) du robot. L’objectif est de commencer à regarder comment les deux parties (physique et 3D) du robot bougent quand un avatar ou une personne physique passe à proximité.
Pour le moment le principe est le suivant :
un objet va ouvrir une page web en php affichant la base de donnée des états du robot
ce résultat est chuchoté à des objets 3D situés à proximité
ces objets changent de couleur ou effectuent des rotations
En parallèle, j’ai fouiné sur le web. La communauté des utilisateurs de robots bioloid est puissante, et il existe déjà des modèles 3D de chaque élément du robot ! Merci à John Hylands de l’Ontario. Le top du top serait de pouvoir importer ces éléments 3D dans opensim, puis de tenter un réassemblage d’un robot virtuel. Dans l’idéal, la maîtrise des paramètres de liens entre parties et de rotations de ces parties ouvre la voie à un modèle de robot capable de bouger avec ses articulations. Un peu comme une statue scriptée.
Evidemment, je n’ai pas du tout le niveau, mais je commence à effectuer des rotations à la demande sur le bras de mon petit mannequin, et grâce à @metopen, de la francogrid, j’ai accès à un espace virtuel permettant l’import de “mesh” c’est à dire de 3D externe. Via sketchup j’ai pu exporter les parties du robot au format collada (.dae). Et donc les tests vont pouvoir commencer.
Concernant REMI, il a une nouvelle tête en fabrication maison. Les matériaux utilisés sont un paquet de cigarettes (idéal pour une arduino), et un paquet de bouts filtres + du scotch isolant noir. Je suis assez content du résultat, de l’accessibilité de la connectique et de la souplesse.
Pilotage du robot via internet OK (tests réalisés via page web mobile)
Et maintenant une étape critique de franchie :
Premier test de pilotage du robot via objets dans un monde virtuel : OK
Bon, évidemment je n’en suis qu’aux balbutiements. Mais je pense que je suis sur la bonne voie. Afin d’obtenir ces premiers résultats j’ai appris il y a 8 jours, durant le WE, les bases d’un langage de programmation appelé Python. Celui-ci a de nombreuses qualités. Notamment de pouvoir tourner sans fin sur un ordinateur, de s’apprendre vite si comme moi on a juste besoin de rudiments, et de disposer d’une armada de bibliothèques permettant de communiquer via le port série, ou avec le web, etc.
En gros, et pour simplifier le système en cours de développement pour la preuve du concept du projet REMI.
Des objets dans le monde virtuel Francogrid (solution Opensim) sont codées en LSL (Linden Script Langage, utilisé aussi pour Second Life). Ils appellent des pages web en langage php.
Les pages web en php mettent à jour une minuscule base de donnée contenant des états du robot (états aussi bien dans la dimension physique que dans l’autre).
Un script python situé sur un ordinateur interroge le web et regarde les états en stock.
Suivants ces états le script python envoie des messages sous forme de chaînes de caractères à la carte arduino fixée sur le robot.
Cet envoi se fait via un module de modélisme sans fil APC220. Le robot peut être situé jusqu’à 1 km de la bécane connectée (gnark gnark).
La carte arduino reçoit les messages, les transforme aux spécifications du controlleur propriétaire du robot (le CM5) et les lui envoie.
Le CM5 envoie les commandes aux “actuateurs” (servo-moteurs intelligents pour simplifier) ou “muscles” du robot.
Maintenant, cet essai est très frustre. Je suis sur une mise en place évidemment bi-directionnelle, ce qui a nécessité l’ajout de capteurs externes au robot permettant de “remonter” les états du monde physique dans la base de donnée sur le web, et de gérer un début de va-et-vient.
Pour cela, le plus simple (notamment pour éviter des répétition débiles de gestes genre “humain à proximité je leve le bras droit”, “humain à proximité je lève le bras droit’) est de me baser sur des déclenchements basés sur les CHANGEMENTS d’état. Désolé pour les puristes qui archivent proprement des historiques de flux. Cela me permet de visualiser le délai de réaction aux deux bouts, d’enregistrer très peu, et de transmettre très peu.
Donc REMI commence à avoir une allure bizarre. Je lui ai rajouté des capteurs ultrasons sur la figure, et j’ai testé d’abord trois mouvements différents en fonction de la distance vis à vis du robot physique. Ca marche.
Puis j’ai testé l’envoi des changements d’état de l’espace physique depuis les capteurs du robot vers l’ordinateur relié à internet. Ca marche.
Puis maintenant je suis sur l’envoi de ces changements d’états à la base de donnée web, via Python. Puis il va y avoir l’interrogation de cette base de donnée par les objets virtuels. Notamment le futur robot “virtuel”.
Evidemment il va falloir mélanger tout. Par exemple, le robot physique irait beaucoup plus vite en bougeant quand un objet est détecté dans le monde physique. Mais ce n’est pas de jeu, car c’est un robot en réalité mixte. Il doit donc envoyer sur le web ses capteurs des deux côtés, puis agir dans les deux dimensions. Pour l’instant le délai de latence est de l’ordre de deux secondes ce qui me semble tout à fait tolérable pour le cas d’usage prévu.
En gros (peut-être est-ce une énormité pour les experts ?), c’est le script python situé sur l’ordinateur qui lit/envoie les mises à jour au web/requête les états/envoie au robot tangible via l’arduino. En boucle. Côté monde virtuel, ce seront les objets 3D qui vont écouter la partie “3D”/envoyer les mises à jour à la base de donnée web/requêter les états/mettre à jour l’espace 3D. En boucle. Le coeur est donc classiquement la base de donnée des états. Laquelle pourrait d’ailleurs comprendre donc des états modifiés par des pages web mobiles, des tablettes…
Vous aurez également remarqué les étranges cornes sur la tête de REMI. Le syndrome Goldorak ? Non. Un futur support pour l’envoi de commandes sans fils à des écrans et des objets tangibles.
Après avoir trouvé un moyen de contrôler le robot avec une méthode maison permettant de lui ajouter des capteurs, on remonte tranquillement vers le contrôle distant avec une solution permettant de contrôler REMI, non pas avec une télécommande mais via un ordinateur (ici au clavier).
L’objectif : utiliser un ordinateur (voire un téléphone mobile) comme passerelle avec le monde virtuel pour piloter le robot réel. Ici une courte vidéo montrant la suite de mes investigations : l’ajout d’un système haute fréquence permet de parler à distance avec la carte programmable arduino qui pilote le robot.
Une avancée décisive, que je suis en train de prolonger en apprenant les bases du langage de programmation python, qui semble bien plus intéressant pour combiner interrogation du net et envoi de commandes…
L’idée consiste à prendre le contrôle du robot en communiquant avec lui en me “faisant passer” pour l’ordinateur, avec une carte électronique programmable arduino.
Cette tactique a réussi. A ma connaissance c’est la moins coûteuse pour ajouter des capteurs à un robot bioloid et en prendre un contrôle simple, sans connaissances poussées. Et puis c’est moi qui l’ai fait, alors je suis content :-)
Mon matériel consiste dans une carte électronique programmable arduino, outil incontournable du bidouilleur (envron 25 euros), et dans une mini-jack audio (environ 2 euros).
Mon montage basique
On soude les trois broches de la jack sur trois fils, que l’on raccorde aux broches 2, 3 et ground (négatif) de l’arduino. La bibliothèque permettant de communiquer au protocole série via arduino permet d’échanger à la même vitesse qu’un PC avec le robot, soit 57600 bauds. Avec le PC il faut mettre le robot en mode “program” à l’aide des boutons de son boitier, puis un écran et une invite de commande apparaissent. On peut ensuite lancer des animations, des poses, et même interroger les moteurs dynamixels avec le clavier. Ici la carte arduino va remplacer le clavier et communiquer à notre place avec le contrôleur du robot.
Je dois dire que cela n’a pas été aussi simple durant les trois premières soirées d’essai. Impossible de faire réagir le robot. J’ai essayé d’envoyer en format Byte, Hex, en ascii, lettre par lettre, etc. Rien.
Et puis j’ai découvert, après avoir essayé les trois bibliothèques arduino de communication série, que la dernière offrait une option permettant d’inverser les états “haut” et “bas” des broches d’échange avec les objets qui ont cette inversion particulière dans leur manière de “parler” via le port série. Il s’agit du paramètre additionnel “true” dans la bibliothèque newsoftserial. Cette bibliothèque nous permet de communiquer en protocole serial via n’importe quelles broches. Ici la 2 reçoit (rx) et la 3 transmet (tx).
Là, aucun problème :) Voici une capture d’un code arduino jouant l’animation 10 du programme de démonstration fourni par le fabricant du robot.
Et la vidéo correspondante :
Moralité, il est possible non seulement d’échanger avec le reste du monde grâce à l’arduino, mais aussi d’interroger le système du robot. Et comme il est possible de relier l’arduino au web et au monde virtuel… On avance :-)
Voici une vue de Rémi équipé de son système arduino (sur le torse).
Saperlipopette : émotions fortes et première vidéo
L’écran de la mort : un seul moteur trouvé (au lieu de 18) !
Après quelques heures passées sans succès sur la voie de la fourmi, j’ai remarqué que le robot avait tendance à tomber en arrière lors d’une marche rapide. Une lecture du manuel, indique qu’il est possible de remettre les moteurs aux paramètres d’usine avec une procédure de RESET, via le terminal de contrôle du robot.
Comme un bon bucheron stupide, j’ai consciencieusement fait RESET moteur 1, moteur 2… jusqu’à 18. Et puis là, je me suis trouvé grosjean comme devant :-)
D’un seul coup le cerveau du robot (le CM5) n’a capté qu’un seul moteur au lieu de 18. En gros, il s’est retrouvé sans corps. Hum hum. Grosse émotion. J’ai cherché et appelé à l’aide quelques cadors de la robotique via twitter, et une relecture du manuel m’a indiqué qu’un reset affectait l’identifiant 1 au moteur et à tous les moteurs connectés en même temps. Haaaaa ! Donc tous les moteurs ont l’identifiant 1 ! Il est donc possible de leur réaffecter un par un leur identifiant (et le baudrate, et des tas de trucs), en débranchant tout et en les branchant l’un après l’autre sur le contrôleur, lui-même branché sur le terminal. OK. Cela m’a pris deux heures trente mais du coup je suis familier des commandes de base avec un moteur via le terminal.
Cette séquence émotion m’a permis de revenir à la case départ, en perdant pas mal de temps et avec une grosse frayeur. Tu parles d’une victoire. Mais au final, REMI remarche.
D’ailleurs, voici une première vidéo de démo avec les scripts fournis sur étagère par le fabricant, afin que vous puissiez voir REMI marcher.
Une bonne partie du temps libre de la semaine a été consacrée à une recherche et une lecture intensive de la documentation de très nombreux travaux et bricolages de roboticiens amateurs ou universitaires ayant pris le contrôle d’un humanoide bioloid.
Après la lecture de plus de 200 pages de documentation, trois voies sont possibles pour pouvoir commander le robot de l’extérieur en le câblant sur des messages ou capteurs tiers.
- La voie du lion consiste à prendre carrément le contrôle de tous les servo-moteurs dynamixels en utilisant des solutions mixtes hardware-software capables de remplacer le contrôleur du fabricant ou son firmware, voire les deux. Dans cette catégorie on a aussi bien des solutions pour flasher le bootloader du contrôleur CM5 (celui du fabricant), son remplacement par une carte arbotix, voir un pc sous linux miniature (Gumstix), avec des librairies de codes en C, C++ ou java, et même des systèmes de capture de pose en python. Ceci n’est pas ce que je souhaite. Je souhaite juste pouvoir lancer des séquences programmées avec les logiciels Robotis. Je n’ai donc théoriquement pas besoin de prendre le contrôle du “bus dynamixel” en half duplex à 1 mb/s, mais seulement de “parler” au CM5.
- La voie du singe consiste à ruser pour piloter un montage envoyant des ordres au robot via son système de télécommande. Le robot peut prendre des ordres en infrarouge ou en zigbee. Malheureusement l’utilisation du zigbee signifie l’achat d’un kit zig100 (59 euros) +un adaptateur zigbe (zg2serial) à 17 euros. De plus cet achat ne servirait que pour le robot. Concernant l’infrarouge, le modèle compréhensive kit ne peut pas être piloté par la télécommande en infrarouge RC100 que je possède, mais seulement par une télécommande assemblée à l’aide d’un capteur asX1 et d’un CM5. Evidemment, j’ai fait ce montage et tenté de capturer les codes infrarouges avec une carte arduino et un récepteur infrarouge. Mais (comme les forums me l’ont confirmé), cela ne marche pas. Le protocole infrarouge n’est pas un des protocoles standards classiques reconnu par la librairie de Ken Shiriff (RC5,RC6, Sony).
- La voie de la fourmi consisterait à copier la manière dont l’ordinateur communique avec le contrôleur CM5 à l’aide d’une carte arduino (avec laquelle je sais échanger avec le web et le reste du monde). Pour cela en théorie il me faudrait une jonction hardware et pouvoir parler avec le CM5 comme le fait l’ordinateur. Or j’ai exploré un mode intéressant de paramétrage du robot fourni par Robotis : le “robot terminal”. Ceci me permet de programmer les positions, enchainements de pose, mais aussi DE LES JOUER en mode “programme” avec une commande du type “P”, puis “Play P 7” (pour joue l’animation 7).
En épluchant plusieurs sources d’information j’ai pu avoir un schéma des connexions de la mini-jack qui relie le RS232 de l’ordinateur au bioloid, et également des spécifications du protocole série de conversation entre ordinateur et bioloid. Cela semble une voie facile à explorer. J’ai donc acheté une mini-jack audio que laquelle j’ai soudé trois fils (RX,TX,Ground) que j’ai relié à une carte arduino. L’idée est de tenter d’envoyer avec la carte arduino des instructions identiques à celle du PC quand il entre en mode programme via le terminal avec le CM5. D’après ce que je sais l’échange se fait en UART à 56700 Bauds 8 bits parité none avec 1 bit de stop. L’ordinateur envoie le caractère “v” puis un retour chariot. Le CM5 envoie un affichage, puis il faut envoyer “P” pour passer en mode programme. A ce stade, théoriquement, il suffirait d’envoyer “play p” suivi du numéro de l’animation programmée et chargée dans le robot pour la lancer.
Je vais donc tenter la voie de la fourmi. Si cela marche, je peux en théorie cabler de nombreux capteurs sur l’arduino et piloter le robot. Egalement, pour une communication sans fil, il me suffira d’acquérir un kit zigbee pour arduino beaucoup moins couteux et mutualisable avec d’autres projets. Comme j’ai le matériel pour interroger le web avec arduino, ceci me permettrait d’établir la passerelle avec le monde virtuel.
