Project Logs

Collapse

• Menuiserie et moteurs linéaires

  llo • 01/17/2019 at 09:40 • 0 comments

  J'ai eu la chance, de par mes occupations hors électronique de m'initier à la menuiserie, et je pense désormais pouvoir réaliser moi-même la plupart des pièces de mon robot, y compris les articulations :)

  J'ai réalisé aussi que je pourrais utiliser des moteurs linéaires, ce qui serait plus pratique, notamment parce que ce serait moins encombrant et plus proche du besoin "physiologique".

  En clair ? Ça va être moins galère que prévu !

• M&Ms : Matériaux et Muscles

  llo • 01/16/2018 at 12:48 • 0 comments

  Après m'être longuement cassé la tête à propos de l'utilisation du cuivre pour mon projet, j'en suis venue à remettre ce choix en question, essentiellement à cause du manque de souplesse de ce matériau dans la gamme de ses utilisations possibles et de la grande adaptabilité que je souhaite obtenir de ce projet de robotique : Je veux pouvoir utiliser le moins de matériaux différents possible et trouver (ou concevoir !) des moyeux en cuivre pour mes moteurs serait un véritable casse-tête. Or ma quête des moyeux parfaits a débouché sur un désert : aucun moyeu qui fasse exactement ce que je veux, au mieux, un s'en approchant mais évidemment pas aux dimensions espérées.

  Je vais devoir concevoir mes propres moyeux. Autant utiliser un matériau adapté et autant utiliser ce matériau pour la totalité du robot. Mon choix définitif n'est pas encore arrêté mais pour le prototypage, je vais tester le durciroc, notamment parce qu'il n'a pas de retrait au séchage, ce qui va considérablement simplifier les choses.

  J'avais un peu peur au départ, en switchant vers ce modèle (que j'avais déjà effleuré il y a quelques années avec l'utilisation de l'argile) de me retrouver avec une statue trop lourde pour être déplaçable, mais à priori à moins de faire sciemment des os et des articulations monstrueusement épaisses, ça devrait très bien aller.

  L'avantage vient également de la souplesse de cette pâte à modeler hyper solide après séchage, qui devrait énormément accélérer le développement des articulations. Il y a un verni applicable sur la structure qui permet de plus de la rendre parfaitement lisse et devrait permettre aux pièces de coulisser sans problème les unes sur les autres. Il restera à insérer des points de couture pour les tendons, ce qui m'amène au second sujet de ce log : les muscles.

  J'ai décidé, après réexamen de la place des moteurs et surtout de leur encombrement, de me défaire de l'idée de les attacher directement aux os, pour les inclure à l'intérieur de structures textiles tendues le long des os et qui permettront en plus un renforcement de l'action protectrice des tendons. Ça a l'air de rien comme ça mais ça ouvre une dimension supplémentaire pour stocker des moteurs et ça pourrait me permettre de passer de 3, 4 moteurs grand max par ensemble articulaire à plus d'une dizaine, avec une nouvelle finesse d'approche. C'est une grande porte vers l'agilité et la précision qui s'ouvre :) Rien qu'au niveau des mains, ça va tout changer.

• "Vous voulez quelque chose ? Faites le vous-même !"

  llo • 12/22/2017 at 20:28 • 0 comments

  La belle énergie du créateur du processeur que j'espère utiliser dans mon robot s'est éparpillé peu à peu ces derniers temps et étant donné que je ne souhaite pas revenir aux PICs, je vais devoir saisir le taureau par les cornes et faire par moi-même le reste du chemin qu'il reste à parcourir pour obtenir un robot totalement open-source et electropunk.

  Le défi majeur c'est le programmateur-débugueur post-installation du processeur, qui sera mon outil de travail pour les prochains mois si tout se passe comme je le souhaite. Tout le reste me parait faisable au prix d'efforts et de patience (trouver une puce (A3P060) et une carte d'accueil, installer le logiciel de Libero et installer YGREC8 dans son petit nid douillet). La partie programmateur est réellement ardue pour moi par contre, car c'est un domaine que je ne connais pas du tout, et il faudra repartir des bibliothèques en C développées par Whygee pour YGWM (moi et le C ....).

  Pour ma part, je ne souhaite pas m'encombrer d'une interface graphique et de boutons user-friendly, la ligne de commande fera mon bonheur. Je développerai probablement une poignée de scripts shell pour faire ce que je désire. Je ne souhaite pas non plus débuguer à distance via HTML ou le port ethernet : je vais rester sur le RPI. Je tenterai d'installer GHDL sur Raspbian (un dérivé de debian) et si ça ne donne rien, je me brancherai dessus depuis mon ordinateur principal pour lui transmettre rapidement les fichiers adéquats. L'important est surtout de pouvoir débuguer avec aisance : contrôler l'horloge, faire du pas à pas, boucler des séquences, récolter un maximum d'informations, en bref communiquer avec la puce depuis le bus GPIO du RPI.
  

  À l'heure actuelle, je suis un peu bloquée à la maison, c'est les vacances de noël et j'aurai un bébé dans les pattes jusqu'au 7 janvier. Je ne sais pas si j'aurai la latitude d'y travailler.

• évolution technologique

  llo • 11/12/2017 at 16:16 • 0 comments

  Dernier log datant de mi-septembre ? Ouch, il était temps d'en faire un nouveau.

  Depuis que j'ai cerné les technologies qui seraient utilisées pour le contrôle des moteurs, les choses ont bougé. Je dirai même que la terre a tremblé : d'un côté, les PICs ont montré un certain degré de résistance à la programmation qui m'a un peu refroidi et de l'autre, le processeur que je comptais utiliser pour la partie haut niveau (qui correspondrait à la partie bas niveau d'un ordinateur, soyons clairs) a décollé comme une fusée. Du coup, étant donné qu'une version plus menue est en production à l'heure où j'écris, il devient possible d'envisager une utilisation complète de FPGA : de petits FPGA avec une multitude d'outils énergétiques pour le bas niveau, et de plus gros FPGA, plus sommaires mais plus puissants pour la partie haute :) Merci Whygee :-* 
  

  Cela dit, j'ai quand même écrit ce fameux article sur les PICs, parce que mine de rien, attaquer cette partie avec un tuto, ça aide sérieusement à mettre le pied à l'étrier. Je finis la relecture et j'envoie :)

  Rappelons nous que la nécessité de l'utilisation d'une logique avancée pour le contrôle des moteurs est multiple : il y a évidemment la coordination entre les moteurs (c'est la première chose à laquelle on pense en tant que roboticien), il y a aussi l'utilisation, de plus en plus courante et précise d'outils de contrôle de type accéléromètres, pour réguler l'utilisation des moteurs et permettre au robot d'acquérir une certaine stabilité, par des mouvements plus fins.

  Il y a enfin dans mon cas un contrôle de l'énergie utilisée par les moteurs, afin de les forcer à respecter le contexte articulaire dans lequel ils sont intégrés. C'est une nécessité dans mon cas et pas dans d'autres car mon système articulaire ne prévoit de bornes mécaniques. Pas de triches, de fins de courses, tout est hyper flexible et hyper laxe. C'est un désavantage évident dans le cas d'un robot basique, avec quelques mouvements répétitifs. Ça devient une nécessité absolue dans le cas d'un robot capable d'exécuter des combinaisons complexes de mouvements variés. Dès qu'on aborde l'équilibre, les mouvements fins, le déplacement de poids, raisonner en termes d'axes coordonnés ne suffit plus pour que ça tienne la route, il faut maîtriser la puissance et contrebalancer les effets de plusieurs moteurs.

  Pour ça, il faut connaitre le mouvement produit, la consommation des moteurs et détecter les surconsommations employées pour forcer le moteur à tourner malgré une résistance au mouvement et garder en tête l'hyper flexibilité. Ou pour parler de façon plus précise : envoyer un courant et un voltage au moteur, connaitre l'accélération produite sur le membre, corriger éventuellement, et en fonction de l'efficacité de cette correction, continuer d'augmenter, et tout le temps de cette correction, comparer la consommation et stopper le mouvement quand la consommation dépasse un certain seuil, au risque de léser l'articulation, le moteur ou les deux.

• Première sous couche électronique : le contrôle automatique des moteurs

  llo • 09/14/2017 at 14:10 • 0 comments

  J'ai passé la journée d'hier à me creuser la tête pour faire le tri entre ce qui était du domaine du possible, de l'efficace et de l'élégant entre l'usage total du VHDL, celui de l'assembleur machine de Microchip et un mix des deux.

  Pourquoi ? Eh bien, déjà les puces PIC de Microchip disposent toutes d'un solide support de gestion de l'énergie, et c'est bien mon objectif de réussi à une gestion aussi intelligente et fine que possible de cette énergie, donc l'emploi de PIC pour le contrôle automatique des moteurs est très pertinent. Ensuite, vient la question de savoir où fixer la limite entre l'usage des PIC et l'usage d'un FPGA plus complexe et capable de gérer des actions bien plus sophistiquée. Bref, où s'arrête le contrôle inconscient et où commence le contrôle volontaire ? Étonnamment plus haut que je ne l'aurai cru au vu de ce que j'envisage pour la suite. On a beau se persuader qu'on est UNE seule personne, en réalité entre les automatismes de notre corps, ceux de notre cerveau et notre volonté, les frontières sont poreuses, floues même.

  Je pense utiliser les PICs pour le contrôle de l'énergie globale et locale et de la limite de charge et d'amplitude des moteurs qui en découle, mais il faudra aussi que j'envisage une passerelle entre ces PICs et les PICs permettant la gestion automatique des mouvements, ainsi qu'une entre ces derniers et la puce en FPGA qui gérera des mouvements purement conscients et élaborés, lesquels pourront surpasser partiellement cette gestion automatique.

  Tout un programme !
  

  Je compte commencer la programmation par la gestion de l'énergie, laquelle est le niveau de complexité le plus bas, en utilisant MPLABX couplé à un programmeur PicKit3. Un article sur le sujet est prévu pour bientôt, j'espère dans Hackable Magazine. J'achèterai ensuite un ICD 3, afin de bénéficier d'un débugage, lequel deviendra indispensable à mesure que la complexité ira croissante.

• Compartimentation

  llo • 09/13/2017 at 08:05 • 0 comments

  Comme ça me tue de rester inactive en attendant d'avoir de quoi finir la partie mécanique du robot (3 semaines, c'est une éternité quand on a pas été productif depuis 3 ans, croyez moi), j'ai décidé d'avancer le reste autant que possible. Je me suis couchée avec cette idée et ce matin, j'ai compris comment faire (merci cerveau) : je vais travailler à la compartimentation des fonctions moteurs du robot.

  Je sais déjà, de part mon expérience passée, qu'il ne faut surtout pas chercher à tout gérer dans un seul système : fonctions réflexes, motrices simples, motrices complexes. C'est voué à devenir un capharnaüm inefficace et grotesque. Il faut diviser pour mieux régner. Il y a encore beaucoup de choses que je ne peux pas faire tant que mon robot de tient pas debout et n'a pas des bras, des mains, des pieds ... Mais en revanche, je n'ai pas besoin de tout ça pour commencer à gérer deux choses : le tonus (c'est à dire le maintien d'une position fixe malgré les perturbations) et la gestion des limites motrices (c'est à dire la capacité à ne pas utiliser ses moteurs au delà de leur limite, à détecter ces limites et à s'empêcher de les dépasser). Les deux sont liées évidemment car au delà d'une certaine pression de l'environnement, le tonus ne peut être maintenu. C'est le principe d'un bras de fer, où l'un ou l'autre fini fatalement par céder, avant que ses muscles et ses articulations cèdent ;)

  Afin de commencer à bidouiller et à établir le fonctionnement et donc le programme logiciel de ces deux fonctions de base, il me faudra un servomoteur et une carte pour le contrôler. Je pense commencer directement en VHDL car même si ces fonctions sont simples, d'autres vont s'y ajouter avec le temps : gestion de l'équilibre, gestion des accélérations, gestion de l'énergie globale, puis enfin, quand tout ça sera opérationnel, gestion des mouvements automatiques (marche par exemple).

• Articulation finale

  llo • 09/12/2017 at 09:07 • 0 comments

  Grace à cet après-midi très productif passé à Leroy-Merlin, je sais exactement comme je vais créer les articulations pour qu'elles soient optimales, tant en taille qu'en forme et en poids. Je vais replier une feuille de cuivre, l'arrondir jusqu'à obtenir le creux puis la bosse qui permettront aux tubes de bouger l'un par rapport à l'autre et les relier avec des filaments judicieusement placés.

  J'ai d'abord trouvé une articulation sphérique avec une boule en acier, et elle était parfaite. Mais j'ai réalisé que c'était beaucoup trop évolué pour la simple fonction de coulissement à 360 degrés dont j'ai besoin. Trop lourd, trop complexe, trop délicat. J'ai donc continué à chercher et au rayon plomberie j'ai trouvé des rosaces coniques :

  Bien qu'elles ne soient pas la solution parfaite dont je rêve, elles m'ont remis sur la piste de la création d'articulations sur mesures, simplement en courbant une feuille de cuivre très fine et en la repliant pour l'épaissir et la renforcer, afin de créer les creux et les bosses des os de mes robots. Je vois maintenant où je vais. :)

  Hélas, je n'aurai probablement pas assez de fonds ce mois-ci pour acheter une feuille de cuivre (et les tubes en cuivre très fins qu'il me manque pour les doigts et les orteils). Je verrai à la fin du mois. Cela dit, j'ai tout de même pu finaliser sur le plan théorique la forme de mon robot, et bien mieux que lors de ma première tentative il y a plusieurs années, où j'étais restée coincée au niveau de l'articulation des épaules et des hanches. Le travail sur les avant-bras et les jambes m'aura permis de dépasser cette difficulté : je vais simplement utiliser 4 fils, et 2 moteurs et les combiner pour obtenir le mouvement désiré.

  Il ne reste donc plus la moindre zone d'ombre au niveau des articulations, tout est clair dans ma tête. Voici d'ailleurs le plan schématique du robot à ce jour : (on notera le pelvis, qui loin d'être optionnel va permettre de supporter les organes internes du robot : batteries, unité centrale ...). J'en ferai prochainement un plan plus détaillé, quand je devrais le concevoir (avec une feuille de cuivre également, ainsi que les omoplates et les cotes, non visibles, et le crâne bien sûr).

  Ça va être un travail d'orfèvre et le résultat sera encore plus magnifique que j'en avais rêvé :)

• Les charnières

  llo • 09/09/2017 at 10:50 • 0 comments

  Après mûres observations et réflexions, il est devenu évident qu'il faudrait utiliser uniquement des charnières 3D pour un maximum de mouvements, même au niveau des coudes et des genoux, si on veut permettre la rotation des mains et des pieds, c'est indispensable.

  Ces charnières permettront également la rotation des doigts, de la tête, des vertèbres et cervicales, des épaules et des jambes et possiblement l'articulation des yeux.

  Je vais aller chiner lundi à Leroy Merlin. C'est un magasin de bricolage géant. J'espère bien trouver mon bonheur étant donné l'incroyable diversité de pièces de serrurerie en laiton qu'on y trouve. Le catalogue en ligne m'a déjà donné quelques idées intéressantes. Il me faudra également une scie à métaux, pour scier les tubes et du fil 1,5 mm pour créer les points d'attache des fils sur les tubes.

  Si à terme je parviens à souder des charnières 3D sur les tubes, alors je pourrais passer à l'assemblage. Je validerai d'abord les bras et les jambes (il me faut encore une ou deux étapes de réflexion pour déterminer comment engendre la rotation de l'avant bras et du tibia de façon fiable), puis je pourrais soit rattacher les bras et les jambes aux épaules et aux hanches, soit réfléchir aux mains et aux pieds. La première option semble tout de même moins décourageante ;)

• Shopping

  llo • 09/07/2017 at 11:11 • 0 comments

  Cet après-midi, séance shopping au magasin de modélisme, pour récupérer des tubes de cuivre, des charnières, des moteurs, etc.

  Je pense imprimer à terme le circuit de commande des moteurs directement sur les tubes en cuivre, huhu, alors s'ils sont introuvables là bas, je prendrai mon mal en patience et chercherai ailleurs. Mais j'espère trouver le maximum de matos nécessaire dans ce magasin : les frais de port coûtent seulement un ticket de bus ;)

View all 9 project logs