Danse contemporaine - School of moon

français
Tags: #<Tag:0x00007f5cebf94ee0>

#41

Pour les moteurs “broken” je le savais mais abs_y est vraiment très important dans toutes les choré, et le “cramage” a eu pour effet de forcer la ligne data à la masse, ce qui a rendu tous les moteurs du torse muets (avec une grosse peur :slight_smile: )
Pour le sens des moteurs, c’est moi qui suis pas bon, dès le départ, j’ai imposé des offsets à zeros, et j’ai posé comme règle que le “zéro” correspondait à zero effort sur l’axe (par exemple, les bras le long du corps)
Ensuite, dans les chevilles de la version beta, j’ai mis les moteurs à l’envers, mais je peux plus les sortir :wink:

Sinon, pour le câblage, j’ai direct enlevé les “hubs” dynamixel pour les remplacer par du fil soudé et thermogainé (ça fait des grosses pieuvres de fils). J’ai déjà eu des faux contacts avec.

Pour le WIFI AC, c’est top pour 1 robot. Pour plusieurs robots en simultané, il semble que j’ai encore des vérifications à faire.

Pour les batteries, je les fais passer dans les trous de devant les cuisses. Dans la version 1.0, les trous sont plus étroits… Ca passe plus


Poppy humanoid powered by battery
#42

Le problème c’est qu’il y a des zones du corps où tu peux faire plus de 180°C dans un sens. Si tu mets le zero comme ça tu vas te retrouver avec pas assez de range d’un côté et trop de l’autre, l’exemple typique étant les bras, en particulier shoulder_y.

C’est quelle reference de batterie que tu utilises ?


#43

La voici :


#44

Une autre vidéo avec un autre robot un peu plus grand : le HRP-2 dans l’équipe Gepetto du LAAS.


#45

Nous voici de retour en résidence pour deux semaines dont une à Toulouse et une à Düsseldorf.
Ce sont les dernières résidences artistiques et de validation de faisabilité avant le mois de Novembre qui sera consacré à la mise au propre et à la mise en place le l’architecture de gestion du spectacle complet.
Pour cela, j’ai été rejoint par trois personnes dont Franck, rencontré au Fablab Artilect de Toulouse, qui va s’occuper de gérer les robots Bioloid, Cypria, stagiaire en animation graphique qui va nous aider à l’animation des robots.et Aurélien qui va participer à la tournée du spectacle avec moi, il est notamment sur le spectacle “Robots” de Bianca Li.

Sur Poppy, nous préparons de nouveaux mouvements dont des mouvements propres au spectacle, une relevée complète (oui debout) et de nouvelles figures où le robot sera porté par les enfants. Une technique interessante à exploiter est la possibilité de figer le robot à n’importe quel moment “block” ce qui permet des trucs de fous comme faire tenir Poppy en équilibre sur la main du danseur.

Pour les Bioloid, les logiciels fournis par Robotis sont décidément extrèmement instables et impraticables pour un spectacle. Nous avons décidé de tout migrer sous Pypot (Freedom!!) en accrochant une Raspberry Pi au dos. (d’où la question du Hub USB Wifi)

Nous allons aussi commencer à passer à l’affinage des mouvements avec du lissage (pour éviter les accouts), de l’anticipation (pour donner le l’ampleur), et du retard (pour donner de la souplesse). Je réfléchi à comment vraiment integrer tout ça dans FIRE.

Il y a aussi un affinage dans la mise en scène avec la définition de tableaux. Le résultat est que la masse de travail est assez conséquente (d’où l’arrivée de nouvelles personnes).

Petite anecdote, j’utilisais Pickle (natif dans Python) pour sauver des fichiers. Il faut savoir que ce format n’est pas stable puisqu’une fois importés dans Git Hub, ils ne sont plus lisibles. Pour les récupérer, les ouvrir dans Notepad++ et les convertir en UNIX. (vous pouvez imaginer que j’ai transpiré à très grosses gouttes)
Donc FINI pickle, je vais passer au CSV pour pouvoir éditer les choré sous Excel.

Nous allons aussi passer l’architecture globale sous Open Sound Control dit OSC pour être compatible avec d’autres outils de spectacle.


#46

Je pense que c’est un problème d’ASCII et de Windows (you can have a look here for details). Using a binary representation should also solved your problem. Yet, for what you are trying to do a csv file probably makes more sense. You would thus be able to “work” on your data without having to re-create all your Python classes.

With @Theo, we are starting to think that we should have a brainstorming on defining a representation for movement which is also compatible with “classical” animation techniques such as the work described by @EtienneB:

We will probably create a topic on this specific question.


#47

C’est très bien d’ouvrir le sujet d’un soft d’animation. J’ai eu la commande de plein d’evolutions sur fire dont je detaillerai la liste, mais ca permet vraiment d’obtenir une gestuelle bluffante. Il faut encore que je sois a l’aise avec avant de décrire tout ça. Ce sont des effets minimalistes mais très riches.

Autre nouvelle : nous avons la marche a quatres pattes de poppy!. Je vais écrire un petit article car ca donne des outils pour la construction de poses qui jouent a l’équilibre/déséquilibre.
On va donc avoir besoin maintenant de gérer la navigation sur le plateau via une manette de xbox.

Le vendredi a été une restitution de résidence a CIRCA a Auch où il y a eu une série de tables rondes autour de l’art et de l’industrie en présence de l’État (region et senateurs) il y a un gros engouement et une volonté de travailler dans l’explosion des barrières. J’ai fait une demo sur la scène ouverte de l’ecole circa qui s’est déroulée sans accros. :slight_smile: je commence a avoir une bonne confiance en mr Poppy et a éviter l’effet demo (checklist, process…)
Bon, poppy a un succès fou auprès des enfants, Nao va être jaloux.


#48

News von Dusseldorf Ja !
Cette semaine est une résidence à la maison de la danse de Dusseldorf. Une occasion de faire le point sur le spectacle, son déroulé et ce qu’il manque vis à vis des robots.
C’est aussi l’occasion de tester Poppy sur la durée. En effet, la semaine dernière, Poppy a commencé à faire des “décrochages” comme un moteur qui devient subitement très lent ou très rapide, un moteur qui est figé alors que j’ai demandé à le mettre mou.
J’ai à nouveau ces problèmes.
Un moyen de s’en débarrasser est de tuer le serveur ZMQ sur Poppy et de le redémarrer (ce n’est donc pas un problème des moteurs)
Au retour de résidence, ce sera mon projet numéro un, de fiabiliser la transmission en la déchargeant un peu.

Nous avons aussi créé une nouvelle animation qui consiste à tourner sur soi-même en étant à genou (pour par exemple se mettre face public)


#49

Il est aussi possible que certain fils soit usés et génère du bruit sur le bus. Ça pourrais expliquer ces ralentissements sur le réseaux… Le soucis c’est que c’est très compliqué a identifier, ça dépend souvent de la position des fils.


#50

Prise de tête avec Poppy…

Il m’est arrivé quelquechose aujourd’hui :
Le moteur abs_x a décidé de se mettre en configuration de sortie d’usine (57k, delais 250µs…) comme ça. J’ai eu peur de l’avoir perdu mais en fait non.

Pour les perturbations sur le bus, c’est en effet très gênant mais je ne comprends pas encore ce qu’il se passe…


#51

Ca y est ! j’ai enfin cramé mon premier moteur pour causes de surcharge (et non à cause d’un bête court-circuit). C’est tout de même mon premier moteur depuis 10 mois que j’ai Poppy, et je pense qu’il en voit de toutes les couleurs.
Bon, malheureusement, le moteur qui a flanché est un MX-64 de la cuisse. Ce fut lors d’une marche rampée au milieu des enfants courant dans tous les sens en faisant des pas classiques. Je pense que je lui ai demandé d’aller trop vite.

Ensuite, une nouvelle séquence du spectacle est en cours d’écriture : un duo de porté entre un danseur (Gaëtan Brun Picard) et Poppy. L’écriture d’une chorégraphie avec un robot est vraiment très intéressante mais bien sûr difficile puisque les mouvements pré-programmés sont ici très limités. Il y a une interaction entre le pilote du robot et le danseur qui est très intense.


#52

Les MX64 sont pourtant plus durs à casser que les 28, c’est étonnant que tu commences par ceux là ^^


#53

Je pense que justement, s’ils sont plus forts, c’est qu’ils supportent des couples plus forts, et qu’on ose plus…


#54

La résidence à Düsseldorf est terminée. Nous avons pu faire une démonstration en public avec Poppy avec un moteur en moins (vive l’orienté objet !!) et l’autre robot. Les enfants ont aussi pu faire une belle performance (difficile pour les danseurs puisque tout devait être traduit en temps réel en Allemand)
Le résultat c’est que l’on jouera en mai trois dates à Düsseldorf :slight_smile:
Le fil conducteur global du spectacle commence aussi à converger à la vue des différents rendus faits.
Ce mois de novembre est dédié à la mise au propre de tout ça :

  • correction des bugs
  • contrôle des fils
  • déplacement de la génération de trajectoires dans l’ODROID pour éviter les accoups dus à la connexion WIFI
  • lissage naturel des mouvements
  • Fignolage des chorégraphies

Il va y avoir aussi l’arrivée de Mommy, c’est à dire un deuxième Poppy (on a décidé de l’appeler Mommy pour simplifier). Il va falloir écrire une chorégraphie à deux robots…

La prochaine résidence va être le 30 novembre au Cuvier à Bordeaux !! Retour aux sources pour Poppy. Est-ce que quelqu’un de l’équipe y sera ? @Comacina, on pourra se rencontrer à ce moment.
Avant d’aller au Ballet National de Marseille pour la résidence finale avant représentation fin janvier…


#55

Bien sûr, on passera te voir!


#57

Un concentré d’impression 3D !! :smile:


#58

Depuis la dernière résidence à Dusseldorf fin octobre, il s’est passé beaucoup de choses.
Tout d’abord, le mois de novembre était consacré à la fiabilisation de Poppy, à tout point de vue.
En effet, lors de la résidence à Dusseldorf, le robot était très aléatoire, certains moteurs se bloquaient ou bien repassaient en configuration d’usine de manière aléatoire. Le seul moyen de retrouver une situation convenable était de relancer le programme Python.
Il y avait aussi des centrages à corriger, le robot se bloquant tout seul quand il avait les bras tendus. Et enfin, les connexions electriques étaient victimes de faux contacts.
Il fallait aussi finir le montage et l’installation du deuxième robot Poppy (dit “Mommy”)
Le logiciel FIRE de synchronisation était aussi à étoffer pour réfléchir à une interface de contrôle pendant le spectacle, différente de l’interface de conception des choregraphies. Voir comment interfacer aussi le logiciel avec une manette de XBOX.
Nous avons aussi désormais 4 robots Nao disponibles. L’objectif était d’avoir écrit des bouts de chorégraphies lors du spectacle (notamment des rondes).
Un autre objectif était de continuer la conception du robot Bioloid interfacé avec Pypot via une Raspberry Pi.

Après un mois de travail et une semaine de résidence au Cuvier de Bordeaux avec l’assistance de l’INRIA ;-), on est à peu près dans les temps pour deux semaines de résidence au Ballet National de Marseille !!

Voici quelques obstacles rencontrés, interessants pour améliorer Poppy ou d’autres projets liés :

  • Concernant le figeage des moteurs intempestifs ou encore la remise en configuration d’usine, la cause est un moteur, en l’occurence sur mon Poppy le moteur ‘abs_z’ qui rayonnait des signaux aux autres moteurs et brouillait tout le Poppy. Si je débranchais l’USB2AX et le rebranchais, tout allait mieux pour quelques instants. J’ai changé le moteur et maintenant tout va mieux. J’ai aussi décidé par la même occasion de passer le bus en 500Kbps au lieu de 1MHz (ce passage n’a pas résolu mon problème). J’ai décidé de rester sur cette vitesse. Au passage, il serait pratique de régler cette vitesse via le fichier .json sans avoir à modifier les valeurs par défaut de Pypot (pour info, la vitesse de 500Kbps n’est pas possible pour les petits XL-320)
    Pour observer tout ceci, j’ai patché un bout de code que m’a passé @Matthieu et @Pierre qui est super :
    [bout de code]
    Il permet de savoir en temps réel si des moteurs sont débranchés. (time out)
  • Je confirme que le passage à la norme WIFI AC sur la fréquence 5GHz est très bénéfique. Par contre, la plupart des dongles wifi AC ne sont pas directement compatible avec Linux. Il s’ensuit une lutte acharnée contre Linux à compiler le module 8812au… Voici un lien qui permet de compiler un driver WIFI AC sous ODROID XU4. Il n’y a pas de règles générales sur ce process, il faut être patient.
  • Comme @Nicolas me le faisait remarquer, mettre des batteries Li-Po en parallèle pour alimenter le robot n’est pas optimal. En effet, j’ai deux batteries, une dans chaque cuisse de 2200mAh. Si les batteries ne sont pas equilibrées, celle qui est la moins chargée est celle qui va se décharger en premier. Il faut donc faire attention à ce qu’elles soient gérées par couple. Je vais réfléchir à une solution plus perenne.
  • Pour les robots Nao, des chorégraphies ont été écrites par Cypria Donato, animatrice en dessin animé. Le process est assez interessant puisque le chorégraphe a donné une sequence à interpréter au robot. Mais comme le robot a certaines contraintes mécaniques et d’équilibre, la séquence est légèrement modifiée. Ceci implique que la chorégraphie faite par les humains va être modifiée pour se caler au robot. Le pilotage global des Nao va se caler lors de la résidence à Marseille.
  • Pour le Bioloid, au déut, il s’agissait de reprendre la forme humanoïde du kit bioloid pour la mettre sur scène. Mais comme le bluetooth n’était pas fiable, nous avons décidé de mettre une raspberry pi dans le dos pour le piloter via WIFI (802.11n ici). C’est une véritable conception produit qui est donc en cours. Le corps est maintenant fini mais c’est la raspberry pi qui ne semble pas assez puissante pour contrôler tous ces moteurs via pypot. C’est Franck Jubin qui travaille sur ce sujet. Il viendra sur ce forum pour exposer les problèmes rencontrés.
  • Les fichiers de chorégraphies utilisés par FIRE sont désormais des fichiers CSV, finis les fichiers pickle. Cela rassure énormément et évite de perdre des fichiers pour de simples problèmes de compatibilité UNIX/Windows.
  • Le spectacle va être une succession de scènes avec plusieurs robots qui vont être pilotés en partie via FIRE. Pour rendre la gestion des robots plus simple et plus sûre, j’ai décidé de modifier légèrement la structure de FIRE afin que chaque bloc, chaque choregraphie puisse être activable/desactivables via une machine à états finis. Les transitions entre ces états pouvant être activées par ces même blocs. Chaque bloc FIRE peut être hérité d’une classe QWidget de Qt4. Cela permet de disposer d’une interface graphique. Pour la machine à états finis, il s’agit d’une mosaïque de boutons représentant chaque état et s’allumant quand l’état est actif. Il y a quelques conflits avec l’utilisation de pygame pour gérer le son ou la manette de XBOX.
    J’ai notamment ajouté à chaque bloc une entrée “activate” qui permet de rendre le bloc actif (les sorties sont évaluées) et une sortie “finished” qui permet de savoir quand c’est fini.
    Ca permet notamment d’avoir de gros boutons et d’éviter de chercher les boutons avec la souris. Pour info, il existe une application qui s’appelle “Dimmer” qui permet d’avoir un écran très peu lumineux, idéal pour la scène.
    On peut avoir un bouton d’arret d’urgence.
  • Un autre bloc “SoundPlayer” a été créé afin de jouer un son quand l’entrée “play” passe à 1. Très utile pour faire une alerte sur la température des moteurs des robots.
  • après diffusion du logiciel FIRE en interne, je me suis rendu compte que ce n’était pas facile à installer. Notamment à cause de Python et de la Leap Motion puis de pygame. Pour l’installation de Python sous Windows, je conseille de plus en plus l’installation de la disztribution python(x,y), comme ça tout est déjà fait.
  • Sur l’ancienne version de FIRE, je commandais chaque moteur via WIFI toutes les 20ms. Quand le WIFI a du lag, le robot se met à avoir du lag et les trajectoires étaient moches. Désormais, je contrôle le robot par “poses”. C’est à dire que je vais donner son comportement pendant quelques secondes. C’est l’ODROID qui va contrôler les moteurs plus finement. J’envoi donc des messages sous forme de chaines de caractère :
  • M : le moteur est mode safe_compliant (c’est à dire éteint sauf s’il sort des limites angulaires)
  • P : le moteur est commandé à la position courante mesurée. Cela donne un effet amorti
  • S20.31 : le moteur est commandé à la position 20.31deg avec une vitesse d’arrivée nulle (polynome cubique)
  • L-50.63 : le moteur est commandé à la position -50.63 avec une vitesse d’arrivée tangente au mouvement global (on lisse la trajectoire en contraignant la courbure) polynome cubique ici aussi.
  • K : le moteur est commandé à la position mésurée lors du premier envoi de la commande ‘K’ (mode statue)
    On peut imaginer d’autres types d’interpolations polynomiales
    Un serveur zmq est créé sur le robot pour comprendre ces commandes et les envoyer à pypot sur les servos.
    Le résultat est à la fois un lissage très joli des mouvements de Poppy mais aussi une réduction de la complexité de FIRE (le calcul étant déporté sur le robot)

Le reste arrive à Marseille !!


#59

Il y a beaucoup d’information extrêmement utile sur ton poste, merci @Thot.


#60

C’est une Raspberry Pi 2? C’est ce l’équipe a testé et utilise pour les robots Poppy (la prochaine version de Poppy Humanoid devrait être avec une Rpi 2), et il ne nous semblait pas qu’il y avait des problèmes pour contrôler tous les moteurs?


#61

Pour rebondir sur la question de la RPI2 je pense que le soucis viens plutôt du bus, 1 USB2AX pour 20 moteur avec les synchro de base pypot ça peut provoqué quelques latences. L’utilisation de Pixl pourrais résoudre ces problèmes, sinon tester avec 2 réseaux USB2AX (comme sur poppy humanoid).