Bonjour, je suis entrain de développer/chercher un robot permettant de tester des algorithmes, principalement bio-inspirés sur l’apprentissage de la marche et du programme locomoteur générale. Poppy me semble tout désigné pour répondre à cette problématique, tant du point de vue de l’aboutissement technique, que par la philosophie de développement, l’aspect open-source et la communauté associé.
Malgré cela et comme avec les autres robots du marché, j’ai certaines problématiques d’ingénierie auxquelles ils ne répondent pas. Ce qui m’amène à envisager de redevelopper un robot, mais avant d’avancer dans cette direction, j’aurais voulu vous poser quelques questions, afin de limiter les efforts vains et surtout inutiles. Et pourquoi pas apporter ma pierre à l’édifice Poppy en ajoutant ces fonctionnalité plutot qu’en redeveloppant de A à Z un hardware.
Voici les questions auxquelles le projet Poppy ne semble pas répondre, vous avez surement du y réfléchir et choisi de ne pas intégrer ces aspects là et j’aurais aimé savoir pourquoi :
Avez-vous une approche de la “compliance”? Ce que j’appelle personnellement la “robotique flexible”, nécessaire selon moi pour s’éloigner de la marche “saccadé”. Avec entre autre le fait d’avoir une chaine de commande mécanique réversible ainsi qu’une approche “molle” de l’asservissement électronique.
Dans le même ordre d’idée, une des autres limitations pour moi de cette classe de robots et que ses actionneurs (les dynamixels) ne permettent pas un controle en couple/effort mais seulement en position, ce qui est grandement contraignant pour une approche bio-inspiré. La compliance face à l’environnement étant extrinsèque, elle dépend totalement de la vitesse de la boucle de retroaction, ce qui est rarement satisfaisant, alors qu’une approche intrinsèque permettrait d’ouvrir de nouvelles possibilités. Ma deuxième question est donc la suivante : Avez-vous une approche lié a cette problématique de commande en effort?
Au delà des aspects scientifiques, une motivation initiale et principale du projet était de créer une base robotique libre pour éviter que des chercheurs soient obligés de perdre du temps en développement à réinventer un robot entier alors que ce qui les intéressent n’est qu’une sous-partie.
Poppy Humanoid est là pour qu’on puisse l’utiliser librement et modifier juste la partie du corps qui motive un axe de recherche. Donc effectivement, c’est totalement dans l’esprit du projet de créer des versions dérivées répondant à des besoins très spécifiques.
Oui c’est un aspect très important pour nous aussi. C’est d’ailleurs l’unique raison de l’utilisation des moteurs Robotis qui permettent de “contrôler” (à un certain degré), la compliance du robot. Dans les faits, on peut limiter le torque max et passer les moteur en mode passif.
Pour le moment, la motorisation est le seul aspect compliant du robot. Pour aller plus loin, on pourrait imaginer utiliser l’impression 3D de pièces méca avec des materiaux flexibles:
C’est vrai mais il existe une légende urbaine ( @Steve ) comme quoi ce serait quand même possible de faire du contrôle en couple avec des Dynamixel MX64. Mais je ne l’ai pas vu de mes yeux…
Oui nous avons prévu, dans l’équipe Flowers, d’axer nos efforts de développement sur la réalisation d’actuateurs robotique contrôlables en force et open source ;). Cependant c’est un projet qui va prendre les 2 prochaines années…
J’avais cru comprendre, et des initiatives de ce genre mérite d’être connues ! Le problème de changer d’actuateur et qu’ils sont au coeur du design et je ne vois pas trop comment faire un fork du projet en changeant les actuateurs mais en gardant le reste des pièces.
Cette légende m’interesse au plus au point, c’est un des rares défauts que je leurs trouvais aux dynamixel.
C’est une très bonne initiative, un système de servo-moteur opensource manque cruellement, j’ai vu des initiatives tels que OpenServo, mais qui m’ont l’air d’être à l’arret.
Enfaite, dans mes recherches sur des actionneurs avec un comportement bio-inspiré, je me suis rendu compte que même un actionneur controlé en effort est assez éloigné du modèle biologique du muscle humain. En effet, certaines personnes considère les muscles comme des “ressorts à raideurs variable” donc plus que simplement controlé en couple… Mais déjà des actionneurs controlables en effort serait un grand pas en avant et ouvrirais de nouvelles porte en terme de controle/algorithmie.
C’est sûr mais pour un certain nombre de cas, il n’est peut être pas nécessaire de changer tous les moteurs. Par exemple, si on s’intéresse au grasping dans un contexte de robotique humanoïde, même si on veut des moteurs un peu spécifiques, un chercheur peut se focaliser que sur la modification de la morphologie de Poppy Humanoid au niveau des mains. L’intérêt de Poppy Humanoid pour la recherche est de pouvoir être adapté/hacké rapidement (voir salement) pour certaines experiences.
Pour ceux qui veulent utiliser des systèmes de motorisation totalement nouveaux et sur le corps entier, il y est peut être effectivement plus rapide de tout refaire. C’est le cas pour Roboy par exemple.
C’est exact. Le fait qu’on contrôle en rotation plutôt qu’avec des actuateurs linéaires antagonistes change pas mal la donne aussi.
Dans notre projet, il n’est pas forcement question de faire du bio-inspiré parce qu’on on ne sait pas vraiment de quelle fonctionnalité il faut s’inspirer. Il s’agit plus de fournir une brique de base et le fait qu’elle soit ouverte permet d’explorer ces questions et de tester facilement differentes alternatives de contrôle ou de hardware (ressort vs pas ressort par ex).
Plusieurs labos, comme par exemple celui de Manfred Hild en Allemagne (https://www.ki.informatik.hu-berlin.de/mitarb-en/manfred-hild ), ont reprogrammé le firmware des dynamixels et arrivent à un résultat qui en pratique permet le contrôle en force. Vous pouvez le contacter de ma part, il pourra certainement vous en dire plus.
Juste pour dire, il suffit de prendre un moteur et de tester, vous en avez, c’est 5 min… http://support.robotis.com/en/product/dynamixel/mx_series/mx-64.htm#Actuator_Address_46
C’est plutôt du contôle en courant.
J’ai ajouté les registres dans pypot, branch "test_torque_control’.
Il faut faire un set_torque_mode() ensuite c’est goal_torque et pour la mesure de courant c’est present_current.
C’est pas miraculeux non plus. Niveau précision je sais pas ce que ça vaut mais en tout cas ça a l’air vaguement cohérent.
Il y a toujours un blocage au changement de sens, on a quelques idées pour tenter de régler ça, bientôt dans le firmware open source.
Quel firmware? Je sais pas, le dernier?
Moi aussi j’avais testé il y a quelques années et ça marchait pas non plus.
Je sais pas à partir de quelle version ils ont ajouté ça.
Il faut qu’il y ait le circuit de mesure de courant donc si l’élec a pas changé ça devrait aller avec une mise à jour.