Mixed Reality DesignRSSarchive

Quoi de neuf pour REMI ?

Cela fait longtemps que je n’ai pas donné de nouvelles de REMI.

image

Ma valise pour FOSSA 2012.

J’ai eu la chance d’être invité par l’INRIA à des rencontres internationales d’experts du logiciel libre, FOSSA 2012 où j’ai présenté le projet en catégorie artistique devant un parterre de personnalités et d’équipes de recherches. Cela a été une expérience particulièrement stressante et enrichissante pour un autodidacte pur comme moi. J’en ai profité pour présenter OPENSIM et la Francogrid, et pour faire la rencontre de  roboticiens des équipes de l’INRIA sur Grenoble spécialistes de ROS, un langage libre robotique très important. Je remercie beaucoup les organisateurs pour l’invitation. Beaucoup.

Ci-dessous la première partie de ma présentation, qui débouche sur un gros plan sur celle de REMI.

fOSSa2012- hugobiwan_zolnir open simulator and remi robot from fOSSa - Free Open Source Software Academia Conference

Mais ensuite, j’avoue avoir été très pris par d’autres projets, et aussi un autre robot que l’on m’a prêté (un nao !), jusqu’à ce que je croise une marraine de REMI, Karine Sabatier directrice de la Cantine Numérique Rennaise, qui m’a demandé de ses nouvelles.

En rentrant, j’ai immédiatement confectionné un carton de transport protégeant le robot, et j’ai repris les travaux sur la mise au point du mode “rage” qui sera activé en fin de scénario du projet.

Le mode “rage” ne pourra être déclenché que quand avatar et humain auront collaboré pour emmener le robot à un endroit entouré d’obstacles cibles. A ce moment l’avatar pourra déclencher la colère de REMi depuis le monde virtuel.

image

Remi à l’entrainement avec ses sparring partners :-)

Le principe est simple : une fois le mode “rage” déclenché, REMI se frappe la poitrine façon King-Kong puis pivote en cherchant une cible à portée. S’il y en a une, il la détruit. Sinon, il pivote pour en trouver une autre. Une fois toutes les cibles autour de lui détruites, je déclencherai un bonus dans les parties réelles et virtuelles de l’expérience. Pour l’instant, il revient en mode de détection de co-présence réelle-virtuelle.

Concernant le code, pas de problème particulier : j’ai paramétré des mouvements et des délais d’exécution, mis au point un nouveau script arduino et “paralysé” la liaison avec le monde virtuel le temps de la “rage” de REMI. Mais par contre, REMI est vraiment trop bardé de fils.

image

REMI en réparation à l’atelier du labfab de Rennes.

Et là, mon bricolage trouve ses limites : faux contacts et débranchements sont beaucoup, beaucoup trop courants. Il va donc falloir au final remonter la totalité des connexions de la carte arduino en les soudant sur un bouclier (un “shield” dans le jargon). On ne peut plus se permettre de perdre le radar ultrason, les signaux envoyés au contrôleur du robot ou les échanges permanents avec le monde virtuel. Surtout maintenant que le code et le montage fonctionnent :-)

J’attaque donc une étape de robustesse indispensable pour continuer. Heureusement, REMI est sur le portfolio du fablab de Rennes, le Labfab, ce qui me permet de disposer de petit matériel, notamment de plaques de prototypages à souder connectables sur arduino. Je pense faire cela dans les jours qui viennent.

image


Protoshield arduino

REMI m’a chargé d’embrasser de sa part tous ses parrains et marraines et de leur dire qu’il est toujours bien en vie, qu’ils pense à eux et qu’il ne prend pas la poussière ! J’en profite pour les remercier tous et toutes et leur souhaiter une excellente année, durant laquelle ils devraient voir REMI (qui a maintenant exactement un an) à l’oeuvre sur le scénario global.

@hugobiwan

link

Implémentation d’un mode “rage” pour REMI


From REMI - Robot Enabled for Mixed Interaction

REMI peut désormais tenir correctement debout en marche avant, arrière, et en rotation, détecter humain et avatars, et se déplacer avec deux passerelles vidéo actives.

Maintenant, que se passe-t-il une fois qu’avatar et personne physique collaborent pour déplacer REMI ?

Voici un premier système que j’essaie de mettre au point :

- REMI doit être emmené par ses deux pilotes sur une cible située hors du champ de caméra (la coopération et le guidage sont donc obligatoires). La cible est une marque au sol entourée de boîtes (genre boîtes de conserve), dans la partie physique de l’espace.

- REMI déclenche alors l’apparition d’un “mot mystère”.

- Le “mot mystère” doit être donné par la personne physique à l’avatar (oralement, par exemple, pour commencer, on verra après d’autres méthodes).

- Une fois le mot mystère tapé par l’avatar, REMI passe en mode RAGE.

- En mode RAGE REMI ne répond plus : il détruit. Il passe en mode combattant et détruit si possible acrobatiquement la construction de boîtes de conserves autour de lui. Dans le monde virtuel, le pad de pilotage de REMI disparait, et j’ai une idée de bonus que je ne dévoile pas encore.


From REMI - Robot Enabled for Mixed Interaction

Donc, pour mettre en place cela :

- il faut implémenter le mode RAGE (on a le mode de détection et le mode de pilotage actifs pour le moment).

- il faut inventer quelque chose pour dévoiler le mot mystère quand REMI atteint la cible

- Il faut déclencher la suite d’actions en mode RAGE mais aussi la réinitialisation dans la foulée, pour pouvoir remettre REMI au démarrage du scénario.

Pour le moment :

- j’ai modifié le script python pour détecter un passage en mode “rage” et prendre le contrôle de REMi avec une fonction spéciale qui court-circuite tout tant que REMI n’a pas tabassé son environnement.

- Des mouvements de combats sont inclus dans le script arduino de contrôle de REMI.

- un nouveau script a été créé dans un objet qui n’existe que pendant la phase de pilotage à distance de REMI, dans le monde virtuel. Cet objet “attend” le mot mystère pour mettre à jour la table des états de REMI sur internet avec le mode “rage” .

- j’ai fabriqué un petit panneau automatique avec une détection de présence pour faire des tests. Quand REMI s’en rapproche, il dévoile le mot mystère. Inconvénient, REMI risque de le détruire en mode “rage”…

Les tests commencent.

@hugobiwan

link

Hokkaïdo, Londres, Paris, Nancy : merci.


From REMI - Robot Enabled for Mixed Interaction

Bon, ce n’est pas parce que je n’ai pas publié de billets ici ces dernières semaines que j’ai chômé sur REMI.

Je vais envoyer rapidement une vidéo de démonstration actualisée avec les progrès du robot. Mais ce billet est rédigé suite à plusieurs messages qui m’ont fait plaisir, dans la foulée d’un don de mon ami Coulaut Menges en juillet, décisif pour améliorer REMI en lui intégrant l’équilibre (gyroscope) et l’énergie (batterie et chargeur lipo).

Avant tout, merci à toi, Coulaut !

Depuis j’ai été recontacté par Michael Vallance, d’Hokkaido, qui développe un environnement de pilotage de robot en monde virtuel entre étudiants situés au Japon et au Royaume Uni (notamment au Lego innovation Center). Michael et ses étudiants ont développé un centre de contrôle sur Opensim pour déplacer un robot NXT de chez lego. Nous avons échangé de petites recettes, et il utilise également maintenant le streaming web via Ustream et Bambuser avec un ipod embarqué sur le robot. Ca marche !

Merci à Hokkaido de s’intéresser à REMI ! Voici le blog de Michael.

Ensuite, fin août, coup de fil de la Cité des sciences et de l’industrie à La Villette sur Paris. David, animateur du carrefour numérique, invite REMI pour 4 jours pour la fête de la science 2012, en fournissant écrans plasma, connexion internet, billet de train… GENIAL ! Hélas, ce sera partie remise, malgré le soutien de toute l’équipe de la bibliothèque du metavers prête à épauler : ces dates sont bloquées pour des impératifs familiaux. D’ailleurs mes excuses ont été très bien acceptées. Mais ça fait plaisir et cela motive !

Pour info, David lance un Fablab là bas, comme il l’explique ci-dessous :

Merci à la Cité des sciences de s’intéresser à REMI  !

Enfin, il y a quelques semaines, un certain Xevel2 m’envoie un message via youtube pour me proposer spontanément des pièces de robot :

Salut,

Plutôt cool ton projet !
Il se trouve que j’ai accumulé pas mal de bricoles robotiques qui dorment actuellement dans des tiroirs faute de temps pour en faire quelque chose.
Y a-t-il une liste de trucs dont tu aurai vraiment besoin ? J’ai un peu de tout, dont une grande partie ne me manqueront pas, et j’aimerai bien les voir mis à profits dans un robot intéressant ^^’

++
Xevel

Et bien c’est Xevel qui est “plutôt cool”. Suite au remontage complet de REMI resserré, recodé et reboulonné, je me suis trouvé avec deux câbles trop courts, entre les bras et le dos. Et ces câbles s’achètent par gros paquets à 40 euros…


From REMI - Robot Enabled for Mixed Interaction


Cette photo c’est l’enveloppe que j’ai reçue ce week-end avec les câbles en question offerts par Xevel2, Nancy,  champion à l’Eurobot Moscou avec la team XD (catégorie créativité) , excusez du peu !

Merci à Nancy de s’intéresser à REMI !

Jetez ici un oeil au beau bébé de Xevel , XACHIKOMA:

Tout cela réchauffe le coeur. Chers parrains et marraines de REMI, continuez à le suivre !

Mon objectif est de candidater sur Laval Virtual Revolution 2013 afin de vous faire tester une installation digne de ce nom :-)

@hugobiwan

link

J’avais évoqué l’intérêt d’explorer la voie du singe, à savoir l’utilisation d’instructions réservées à la télécommande du nouveau REMI afin de pouvoir non plus lancer des mouvements, mais plutôt lancer des programmes utilisant la puissance du controleur propriétaire CM510 de chez Robotis. C’est chose faite, notamment grâce aux conseils de @aristofor.
La petite morale de ce nouveau développement est qu’il faut surtout bien se documenter amont. On découvre des tas de choses intéressantes. Pour ce qui est de la voie du singe :
- le protocole de communication est documenté sur internet (bas de page).- une exploration de l’aide du logiciel RoboTask fait découvrir l’existence d’un mode de test de la télécommande ! Une fenêtre windows apparait avec une télécommande miniature cliquable qui fait réagir le robot.
Conclusions :
- il est possible de “forger” des paquets au protocole infrarouge avec arduino.- MIEUX : il est possible d’envoyer ces instructions via protocole serie à 56700 b/s et la mini-jack, puisque le mode test de la télécommande sous robotask passe par là !- Pas la peine de se casser la tête avec la fréquence infrarouge de la télécommande, si on arrive à envoyer des paquets corrects VIA LA CONNECTIQUE DE MON PREMIER HACK (la voie de la fourmi). A partir de ce moment là, si le robot réagit, on peut utiliser le programme propriétaire de ROBOTIS pour gérer en permanence le gyroscope, se relever en cas de chute, etc.
Voici un exemple de code de base sous arduino 0.22 utilisant la librairie newsoftserial et une mini-jack branchée sur les broches 4, 5 et 6 (utilisée en négatif). Ladite mini-jack est branchée directement sur le CM510 du robot. Ce code fonctionne avec un bioloid premium de type A utilisant les fichier de démo de base.
#include <NewSoftSerial.h>
NewSoftSerial remi(4, 5,true); //le paramètre additionnel “true” est très important.
//ici on ajoute les variables pour échanger avec le CM510int prefixe1;int prefixe2;int data_l;int data__l;int data_h;int data__h;//tableau de stockage du paquetint octets[6];//variablesint a;int b;
void setup(){
//on ameliore la connectique : pin6 en négatif pourl’envoi des infos en serial.pinMode(6, OUTPUT);digitalWrite(6, LOW);
  remi.begin(57600);  Serial.begin(9600);
}
void loop(){
//preuve du concept qui envoie le robot en marche avant avec le prog par defaut de//robotis pour le bioloid premium. Ici on envoie la valeur hexadecimale 0001 qui//correspond à la touche “U” - voir systeme ici : //http://support.robotis.com/en/product/auxdevice/communicatio/rc100_manual.htm
a=0x01; b=0x00;
stockeenvoie(a,b);
}
//fonction d’envoi des paquets. Le controleur CM510 doit être en mode play avec des //réactions programmées pour la télécommande. Toute valeur peut être calculée ainsi : //pour envoyer 128, conversion en hexadecimal//(ici par ex  : //http://sebastienguillon.com/test/javascript/convertisseur.html)//donne 80. Sur 4 octets cela //donne 0080. Soit a=80 et b=00. 
void stockeenvoie(int a, int b){//formatage des compléments  data__l=a;data__l^=0xFF;  data__h=b;data__h^=0xFF;octets[0]=0xFF;octets[1]=0x55;octets[2]=a;octets[3]=data__l;octets[4]=b;octets[5]=data__h;//boucle d’envoi du packetint i;for (i = 0; i <= 5; i = i + 1) { //envoi au cm510 int valhex=(octets[i]); remi.print(valhex,BYTE); //Serial.print(valhex,BYTE); //Serial.print(“-“);}  //Serial.println();  //delay(1000);}
CQFD. Désormais le gyroscope et le contrôle dynamique de l’équilibre sont appliqués lors du pilotage de REMI depuis le monde virtuel :-D
@hugobiwan

J’avais évoqué l’intérêt d’explorer la voie du singe, à savoir l’utilisation d’instructions réservées à la télécommande du nouveau REMI afin de pouvoir non plus lancer des mouvements, mais plutôt lancer des programmes utilisant la puissance du controleur propriétaire CM510 de chez Robotis. C’est chose faite, notamment grâce aux conseils de @aristofor.

La petite morale de ce nouveau développement est qu’il faut surtout bien se documenter amont. On découvre des tas de choses intéressantes. Pour ce qui est de la voie du singe :

- le protocole de communication est documenté sur internet (bas de page).
- une exploration de l’aide du logiciel RoboTask fait découvrir l’existence d’un mode de test de la télécommande ! Une fenêtre windows apparait avec une télécommande miniature cliquable qui fait réagir le robot.

Conclusions :

- il est possible de “forger” des paquets au protocole infrarouge avec arduino.
- MIEUX : il est possible d’envoyer ces instructions via protocole serie à 56700 b/s et la mini-jack, puisque le mode test de la télécommande sous robotask passe par là !
- Pas la peine de se casser la tête avec la fréquence infrarouge de la télécommande, si on arrive à envoyer des paquets corrects VIA LA CONNECTIQUE DE MON PREMIER HACK (la voie de la fourmi). A partir de ce moment là, si le robot réagit, on peut utiliser le programme propriétaire de ROBOTIS pour gérer en permanence le gyroscope, se relever en cas de chute, etc.

Voici un exemple de code de base sous arduino 0.22 utilisant la librairie newsoftserial et une mini-jack branchée sur les broches 4, 5 et 6 (utilisée en négatif). Ladite mini-jack est branchée directement sur le CM510 du robot. Ce code fonctionne avec un bioloid premium de type A utilisant les fichier de démo de base.

#include <NewSoftSerial.h>

NewSoftSerial remi(4, 5,true); //le paramètre additionnel “true” est très important.

//ici on ajoute les variables pour échanger avec le CM510

int prefixe1;
int prefixe2;
int data_l;
int data__l;
int data_h;
int data__h;

//tableau de stockage du paquet
int octets[6];

//variables
int a;
int b;

void setup(){

//on ameliore la connectique : pin6 en négatif pourl’envoi des infos en serial.
pinMode(6, OUTPUT);
digitalWrite(6, LOW);

  remi.begin(57600);
  Serial.begin(9600);

}

void loop(){

//preuve du concept qui envoie le robot en marche avant avec le prog par defaut de
//robotis pour le bioloid premium. Ici on envoie la valeur hexadecimale 0001 qui
//correspond à la touche “U” - voir systeme ici :
//http://support.robotis.com/en/product/auxdevice/communicatio/rc100_manual.htm

a=0x01;
b=0x00;

stockeenvoie(a,b);

}

//fonction d’envoi des paquets. Le controleur CM510 doit être en mode play avec des //réactions programmées pour la télécommande. Toute valeur peut être calculée ainsi : //pour envoyer 128, conversion en hexadecimal
//(ici par ex  : //http://sebastienguillon.com/test/javascript/convertisseur.html)
//donne 80. Sur 4 octets cela //donne 0080. Soit a=80 et b=00.

void stockeenvoie(int a, int b){

//formatage des compléments 
data__l=a;
data__l^=0xFF; 

data__h=b;
data__h^=0xFF;

octets[0]=0xFF;
octets[1]=0x55;
octets[2]=a;
octets[3]=data__l;
octets[4]=b;
octets[5]=data__h;

//boucle d’envoi du packet

int i;
for (i = 0; i <= 5; i = i + 1) {
 //envoi au cm510
 int valhex=(octets[i]);
 remi.print(valhex,BYTE);
 //Serial.print(valhex,BYTE);
 //Serial.print(“-“);

}
  //Serial.println();
  //delay(1000);
}

CQFD. Désormais le gyroscope et le contrôle dynamique de l’équilibre sont appliqués lors du pilotage de REMI depuis le monde virtuel :-D

@hugobiwan

link

REMI a complètement été modifié grâce au soutien de Coulaut Menges, de la bibliothèque francophone, et de nouveaux donateurs. Il est désormais muni d’un nouveau contrôlleur, d’un gyroscope, de capteurs infrarouges et d’une alimentation lithium-polymère.

Ses performances sont sans commune mesure : puissance, vitesse, et surtout, un équilibre géré dynamiquement qui permet désormais un contrôle depuis le monde virtuel avec la caméra en  “First Person View”. Remi peut embarquer arduino à l’arrière et iphone à l’avant sans chuter !

Etapes suivantes : le hacking du robot via arduino et mini-jack en envoyant les commandes dans le mode d’éxécution du programme propriétaire. L’objectif est de pouvoir profiter des fonctionnalités de gestion dynamique de l’équilibre avec le gyroscope. Hier, j’ai réussi l’envoi de paquets émulant la télécommande pour la première fois avec l’arduino :-) La gestion des pinces est déjà opérationnelle. Une autre vidéo va donc suivre…

Ensuite, nous complèterons le build dans la francogrid afin de préparer un espace de partage avec les avatars présents sur zone.

link

REMI a fait son show au Carrefour des possibles !

Remi project : Robot enabled for Mixed Interaction from Huggy

Le Carrefour des possibles est un événement organisé par la FING dans la plupart des régions de France et qui vise à soutenir et développer l’innovation en faisant découvrir à chaque fois 10 projets lors d’une soirée spéciale organisée une fois par an.

En Bretagne, sur une trentaine de projets candidats, dix sont retenus puis sont présentés par les porteurs devant environ 400 acteurs de l’innovation, chacun en 6 minute chrono. Les porteurs de projets s’installent ensuite pour la soirée dans un espace de rencontre où ils tissent contacts et partenariats. Certains demandent de la visibilité, d’autre des investisseurs, des partenaires…

From REMI lauréat du carrefour des possibles 2012

J’ai eu le culot de candidater pour le projet REMI au mois de juin, et j’ai soutenu l’oral du projet devant les jury de Lorient, Brest et Rennes via la salle de visio-conférence du pôle Images et Réseaux. Suite à l’annonce de la sélection du projet REMI (malgré une présentation très bricolée faute de temps), le jury m’a demandé de garder le secret, la soirée de présentation des projets étant prévue le 11 juillet lors du forum des usages de Brest. Pour être franc, j’avais déjà remporté deux carrefours des possibles à titre professionnel avec la ville de Rennes, mais oser montrer un bricolage de garage personnel comme REMI m’a demandé beaucoup plus de courage. Evidemment le trac fut sans commune mesure.

From REMI lauréat du carrefour des possibles 2012

Heureusement, beaucoup d’amis étaient présents, parmi lesquels de nombreux parrains et marraines de REMI qui m’ont encouragé dès mon passage sur scène.

Je les remercie tous, et je remercie surtout Coulaut Menges, mon compagnon de la bibliothèque francophone, qui a effectué un don important pour le projet, ainsi que les nouveaux donateurs comme Claude Virlogeux, de la Fonderie.

From REMI lauréat du carrefour des possibles 2012

Alors que la connexion du Quartz à Brest ne pouvait laisser mon robot échanger avec son avatar, Yann Dieulangard, de la MEITO, est resté à mes côtés en transformant son smartphone en hotspot, ce qui m’a permis de lui démontrer la passerelle mixte et même le flux vidéo live. Ce fut un honneur pour moi que de pouvoir partager un projet personnel et de figurer à l’affiche avec les autres initiatives, toutes passionnantes et remarquables. J’ai eu la surprise de voir que plusieurs amis avaient été présélectionnés !! Karine Sabatier pour son magazine de photographie amateur, Baptiste Gautier (du labfab de Rennes) pour Smart TB, etc. Dès que les vidéos seront disponibles, je les pointerai depuis ce blog.

Un grand merci aussi aux twittos qui ont bien voulu photographier et relayer la présentation, et qui m’ont autorisé à reprendre leurs clichés : @epm79, @bymaddyness, @guyaum !

@hugobiwan

link

Pilotage d’objets tangibles

Une vidéo tremblotante mais qui montre que le projet avance bien.

  • REMI détecte humains et avatars
  • REMI les met en présence via passerelle vidéo
  • REMI a sa dimension “physique” pilotée depuis le monde virtuel

Et maintenant :

  • REMI peut piloter des objets tangibles.

Ici une petite démonstration de l’extinction et du rallumage de ma TV depuis le monde virtuel. Nous l’avons prise trop vite et avec mon téléphone, mais cela démontre que l’on peut combiner les interactions entre objets virtuels et réels, et même de façon ludique (REMI effectue une séquence pour “viser” la TV avec son bras avant de l’éteindre). J’aurai aussi pu matérialiser en même temps une TV dans le monde virtuel et plaquer une page web avec une chaîne en direct dessus… Et milles autres exemples.

@hugobiwan

link

Un petit essai d’explication du projet en vidéo.

link

Ca marche :-)

Bon, de bonnes nouvelles pour REMI.

From REMI - Robot Enabled for Mixed Interaction

Après 3 week-end passés sur la stabilisation de la marche avant, j’ai enfin un résultat valide. Cela a nécessité de nombreux essais extrèmement terre à terre dans le bricolage physique du robot, de sérieuses modifications, et quelques réglages logiciels.

Au final REMI arrive à se balader piloté depuis le monde virtuel sans trop chuter. En cas de chute, il se relève tout seul. Cela a pris du temps,  mais il aurait été impossible d’éviter le ridicule en cumulant les chutes tous les trois pas !

L’autre amélioration concerne les premiers tests avec l’ajout d’un deuxième flux vidéo pris en vue de dessus du robot, et qui permet à l’avatar de visualiser à la fois son interlocuteur physiquement présent sur la partie tangible de l’installation, et la zone de déplacement du Robot.

Pilotage du robot depuis le monde virtuel avec passerelle d’échange vidéo+vue de dessus.  From REMI - Robot Enabled for Mixed Interaction

Lors de la jonction déclenchée par REMI entre avatar et personne physiquement présente, une sphère bleue apparait, ainsi que deux textures d’écran. Pour prendre les images des deux flux vidéo, j’utilise la caméra de mon ordinateur et un iphone posé dans un abat-jour de plafond. L’avatar dispose alors d’une sorte de pad de jeu vidéo en 3D lui permet de déplacer le robot qu’il voit de dessus. Il doit suivre les conseils de la personne physique pour le déplacer, car la cible que le robot doit atteindre se trouve hors du champ de caméra. La collaboration est obligatoire.

Ca marche :-)

Les problèmes qui restent à régler sont les suivants :

- le lag. Les flux vidéo ont quelques secondes de retard. Or il est utile que l’avatar reçoive en temps réel les instructions de l’interlocuteur physiquement présent. Je pense donc rendre muet le flux vidéo et utiliser le chat vocal d’un avatar caméra montrant la partie virtuelle, avec le microphone de l’ordinateur qui filme la partie réelle (vous me suivez ? ;-).

- Le son. Si je rend muet le flux vidéo numéro un, il faut aussi rendre muet le flux numéro deux qui prend la zone de déplacement du robot de dessus, et utiliser le “chat vocal” du monde virtuel. Or dans les paramètres du service de stream que j’utilise avec l’iphone (Bambuser) on ne peut couper le son. Il faut trouver une solution.

- Les positionnement optimaux des éléments. Avatar caméra dans le monde virtuel, face à face avatar-humain, délimitation visuelle de la zone de déambulation du robot, tout cela détermine des placements précis et à tester afin d’avoir la plus grande compréhension pour les participants. Il faut donc rapidement tester les options, sachant que les choix seront rapides, car les figures imposées du cas d’usage imposent les bases.

- Une fois le problème de son résolu, il faut passer à la phase de test avec des avatars utilisant la francogrid, et munis d’un logiciel affichant les “textures web” (web on a prim). Ceci est une condition sine qua non pour profiter de la co-présence via les passerelles vidéo.

- Enfin, pour la fin de l’expérience, j’ai prévu un mode 3 pour REMI. Le mode 1 est le mode de détection de présence et d’action dans ses dimensions réelle et virtuelle. Le mode 2 est le mode de prise de contrôle du robot tangible par l’avatar. Le mode 3 sera déclenché quand REMi sera prés de sa cible. Il pourrait l’attaquer (genre arts martiaux), et montrer une animation bonus en récompense. Le mode est prévu dans la base de donnée et le code est compatible, mais pas je ne l’ai pas encore implémenté.

Je cherche donc des testeurs pour l’état actuel des développements. Sachant que je dois présenter le projet à une pré-sélection d’un concours d’innovation (oui, c’est nouveau:-) et donc réaliser une vidéo ou une présentation de démo rapidement. J’envisage de remonter toute l’installation au Labfab de Rennes et d’inviter des avatars testeurs. Si vous êtes intéressés  contactez moi : hugobiwan.zolnir_at_gmail.com.

link

Cornegidouille !

Le nouveau montage de REMI.

Crénom de nom,  par les cornes du casque de barbe rouge, je rame avec REMI !

Depuis une semaine je cherche le moyen d’éviter les chutes du robot lorsqu’il se déplace dans le monde tangible, téléguidé via internet par un avatar. Cette petite vidéo vous donnera un aperçu des difficultés…

Ce long week-end de Pentecôte a été mis à profit pour essayer de nombreuses solutions. Au final il semble que le mieux (avec un bioloid comprehensive kit, et non un bioloid premium disposant à la fois d’un gyro et d’un programme de correction de marche avec un contrôleur CM510 ou CM700) est d’abaisser le centre de gravité du robot.

J’ai essayé tout ce que j’ai pu. Déplacer la carte arduino, la pile de 9 volt, lester le robot…Je me suis aperçu que la carte arduino logeait dans le périmètre intérieur du boîtier du contrôleur du robot. J’ai essayé avec la carte dedans, le contrôleur du robot déporté, etc. Pas d’amélioration notable. 

Essai avec CM5 et batterie en vertical pour abaisser le centre de gravité.

Essai avec l’arduino dans le boîtier d’origine.

Essai avec l’alimentation de l’arduino très bas à l’avant.

Un des essais avec l’arduino dans le boîtier du CM5.

Au final, j’ai entamé les grandes manoeuvres, inspiré par cette vidéo :

La semaine dernière j’avais donc fabriqué des supports de talon. Ils apportent une petite stabilisation mais insuffisante au delà de deux à trois pas.

Stabilisateurs maison aux talons.

Pour imiter la solution de la vidéo, il faut passer un point de non retour. En effet pour positionner la batterie (jaune) du robot entre ses moteurs de hanche, il faut trancher dans pas moins de 3 pièces d’origine, en bousillant le système d’accroche entre le torse et le bas du corps… Ensuite il faut trouver sa propre manière de remonter un robot qui marche.

Première phase de découpage.

La première fois j’ai effectué une opération “légère” permettant de loger la batterie à plat contre l’arrière et plus bas. Cela ne marche pas. J’ai donc fait chauffer la dremel et découpé sans pitié afin d’imiter une position de batterie très basse avec une insertion maximale vers l’avant.

Préparation de l’intervention lourde.

Une fois les pièces découpées je me suis aperçu qu’il fallait remonter le buste de presque deux cm afin de bien positionner le bloc batterie. Ce qui augmente la taille du robot (mais il est très léger en haut). J’ai bidouillé un système mixte vissage-élastiques afin de remonter un REMI légèrement agrandi mais disposant d’un centre de gravité beaucoup plus bas.

Après l’intervention lourde. Essai avec l’arduino derrière la tête.

Les tests ont montré que cela augmente LEGEREMENT la stabilité… Après 6 heures de bidouille et d’essais, c’est un résultat moyen (boudiou !). J’ai donc ensuite essayé en mettant la pile de 9 V alimentant l’arduino dans le boîtier du  contrôleur du robot, en mettant la pile devant, puis derrière, puis l’arduino derrière…

Je ne suis pas du genre à désespérer, mais pour le moment, le robot peut exécuter toutes les routines d’essais en équilibre stable, sauf la marche avant !!!

Il semble qu’il manque un petit chouïa de déport du centre de gravité vers l’arrière. Je vais donc essayer deux solutions avant la reprise du travail :

- Modifier l’offset (calibrage) de la position de base du robot pour tenter de compenser.
- Tenter une accroche de lest arrière, éventuellement même suspendu derrière la tête.

A suivre !

@hugobiwan

link