74 réponses à ce sujet

[MrWhite]

Comment vas-tu usiner ton aluminium ?

Bravo pour tes robots, j'aime beaucoup tes dernières réalisations.

[Leon]

Comment vas-tu usiner ton aluminium ?

Je ne voudrais pas répondre à la place de skyhack, mais avec une perceuse (même pas à colonne), une scie à métaux, un mini-étaux, un marteau, quelques limes, on peut déjà faire pas mal de choses sur de l'alu ou même de l'acier. Si on est soigneux, on peut faire des choses propres et précises, même avec cet outillage minimum. Pas besoin d'outillage lourd pour de petites pièces.

L'homme aidé de quelques outils peut être aussi précis qu'une machine à commande numérique, s'il prend le temps de s'appliquer.

Leon.

[skyhack]

... tout à fait ça ...

Je suis quelqu'un qui n'a pas l'habitude de faire les choses à moitié.

Ainsi c'est une réalisation sur laquelle je vais faire beaucoup de test etc ... il faut qu'elle soit clean et solide.

Peu importe le temps que je prendrai (pas trop quand même ), de toute façon avec le peu de temps que j'ai je peut ainsi me permettre de faire les choses bien et efficacement.

skyhack.

[Leon]

Pour l'histoire de la programmation, ce qui est embêtant en fait c'est que je programme (comme beaucoup d'autre j'imagine) avec des tableaux de valeur correspondant aux différentes positions des servos, ainsi je peut faire des séquences etc etc , mais ce type de programme bouffe de l'espace mémoire et des variables à n'en plus finir, l'idéal serait en fait que ce soit l'environnement du robot qui dicte le comportement à prendre dans telle ou telle situation, que je ne soit plus obligé de savoir les valeurs intermédiaires dans un mouvement, en bref de l'auto-programmation des mouvements, et donc une adaptation à l'environnement.

En bref je travail surtout sur ça ... have to work

je joint un exemple de programme et encore ça n'est que la marche avant (oui c'est du basic mais on fait avec ce qu'on a ).

Pourquoi ne pas essayer de décomposer ton programme, de créer des fonctions basiques (lever, poser de jambe), et de faire des fonctions de plus haut niveau (avancer à telle vitesse dans telle direction, tourner de tant de degrés). Tu peux aussi commander par des fonctions de bas niveau la position de tes pattes en 3D (avec les matrices cinématiques inverses), et faire des fonctions de plus haut niveau qui donnent des consignes 3D (x, y, z) à chacune des pattes. Les ordres "haut niveau" peuvent être très simples, ne nécessiter que très peu de paramètres, et pourtant engendrer des actions complexes.

Exemple? Pour BOB3, j'ai une fonction de haut niveau qui prend simplement les coordonnées 2D du point à atteindre. Cette fonction calcule (à l'aide d'autres fonctions plus basiques) la trajectoire à atteindre en fonction des obstacles connus. Puis une fonction de gestion des actions (superviseur) prend le résultat de la trajectoire planifiée (une série de coordonnées 2D de points à atteindre), organise les déplacements du robot, à l'aide de fonctions bas niveau de lecture des capteurs, d'actualisation de la position 2D du robot, d'asservissement, de contrôle des moteurs.
Au final, le programme de BOB3, c'est 1500 lignes de code de C, réparties en une cinquantaine de fonctions.

La programmation séquentielle d'ordres pré-programés telle que tu la pratiques en ce moment, ça va un temps. Je pense qu'il faut rapidement passer à autre chose, si tu veux évoluer niveau programmation. Et le BASIC n'est pas un langage si limité que ça. On peut faire des choses intéressantes, et bien structurées avec. Je programme en C, à peu près du même niveau que le BASIC. Il ne faut pas que ce soit un prétexte pour ne pas faire. Mon ancien robot, BOB2, était programmé en "QuickBasic" sous MSDos (on s'est d'ailleurs beaucoup moqué de ça). Et pourtant, le programme fonctionnait bien, et j'ai réussi à faire des choses assez complexes avec. Comme pour BOB3, je réalisait des cartes 2D du terrain. Autour de 1000 lignes de code en QuickBasic.

Bref, ta programmation est quand même sacrément en décallage par rapport aux théories d'auto-apprentissage, de marche auto-adaptative dont tu nous parles. Si tu as peur de ne pas avoir assez de puissance de calcul (vitesse, mémoire) sur un petit microcontrôleur, tu peux très bien faire tourner ton programme sur un PC relié à ton robot (port série, bluetooth).

Je pense que même sans parler d'auto-apprentissage, d'auto-adaptativité à l'environnement, on peut faire des trucs sympa avec une programmation bien organisée, sur un quadrupède. Pour l'apprentissage, l'auto-adaptativité, est-ce que tu maitrises ces concepts, et la théorie qui va avec? Quel type d'apprentissage veux-tu implémenter?

Leon.

PS: ne prend pas la mouche, ce post a uniquement pour objectif de te booster, et non de te critiquer gratuitement.

[skyhack]

Salut Leon,

Tu sais je n'ai jamais beaucoup évolué dans la programmation, entre les cours, les exams et autre c'est difficile d'apprendre par soi même un langage de programmation, j'ai d'autre priorité malheureusement d'ordre disons "administrative", et la robotique est une passion que je doit bien souvent mettre de côté si je veux réussir dans mes études, car dans celle que j'effectue on ne parle pas beaucoup de mécanique, d'électronique, de condo, de transistor non non, pour l'instant ça n'est que le début, les bases ! toi tu a une profession dans l'électronique je pense ? moi loin de là, ça n'est que de la formation universitaire pour l'instant.

Alors toute mes théorie sur l'apprentissage et l'auto apprentissage ne sont et ne reste pour l'instant QUE des théories que j'énonce plutôt afin de donner des idées aux autres, je ne suis guère en mesure pour l'instant de les mettre en œuvre (du moins en partie).

Je réalise des robots qui bien souvent sont loin d'être facile à réaliser et à contrôler pour un débutant, mais c'est un moyen comme un autre de se donner des défis et de la motivation pour évoluer dans le domaines.

Ainsi j'en attend surtout de vous les pros pour en connaitre d'avantage sur la programmation et les algorithmes.

Attention je n'ai pas dit que j'étais défaitiste, je fait seulement des projets qui dépassent souvent mes propres connaissances, mais sa m'éclate et ça me fait avancer, quoi dire de plus.

Sinon j'aimerai bien me remettre à la programmation java (car j'avais déjà programmé en java mes robot lego grâce à un livre dédié), elle me permettrai de faire des classes et des sous classes, ainsi je pourrai peut-être faire ce que tu m'a dit sur les fonctions basique etc ...

A suivre ...

[Leon]

Salut Leon,

Toi tu a une profession dans l'électronique je pense ? moi loin de là, ça n'est que de la formation universitaire pour l'instant.

J'ai effectivement un poste d'ingénieur en électronique. Mais ce que je fais au boulot n'a rien à voir avec de la programmation. Je fais de la gestion de projet, j'élabore des spécifications à destinations de ceux qui codent. Je n'écris aucun programme dans mon boulot.

Alors heureusement qu'il y a mes loisirs robotiques pour me rappeler que je sais réaliser puis programmer par moi même des trucs qui fonctionnent réellement! C'est vrai, j'ai eu une bonne formation de base en électronique, qui m'aide beaucoup pour mes loisirs (pour mon boulot aussi). Mais mes cours me semblent de plus en plus loin: ça fait plus de 10 ans que je suis sorti de l'école.

Après, je pense qu'en autodidacte, on peut apprendre beaucoup, surtout dans des domaines comme l'informatique ou l'électronique, grâce aux nombreuses ressources que contient le Web pour ces sujets. Regarde: avant de bidouiller la carte mère FoxBoard qui équipe mon robot, je ne connaissais rien à Linux!

Bien sur, comme beaucoup de loisirs, ça prend du temps si on veut progresser. Donc c'est à gérer en fonction des priorités qu'on se fixe.

Leon.

[skyhack]

Je vais tenter d'expliquer succinctement mon ancienne théorie sur la marche adaptative (qui se révèle avoir un gros problème):

-En fait j'ai remarqué que le robot ne pouvais être stable que si la valeur des capteurs de pression de chaque patte était la même (en faite = à une moyenne sur les 4 pattes). Ainsi en calculant la valeur d'équilibre stable sur sol complétement plan et lisse, on peut savoir si le robot penche d'un côté ou de l'autre, pour l'instant rien de compliqué !
-Toute-fois le type de programmation que j'envisage (uniquement sur papier pour l'instant) c'est de fonctionner à l'inverse ! kesako ? En fait dans une réalisation pour trouver LA solution on a souvent en présence 2 cas strictement opposés : exemple, le servo du bassin de mon robot peut soit:
-être fixe sur le corps du robot et actionner via un " U " le restant de la patte.
-être fixe sur la patte et actionner en soit "le reste du corps".
Nous avons 2 cas opposés dont l'un est l'inverse de l'autre.

Et bien dans ma théorie c'est pareil, on fonctionne à l'inverse. Au lieu de comparer les valeurs des capteurs de pression sous chaque patte pour en déterminer (avec l'aide de simple moyenne) si le robot penche et donc de faire que le robot fasse contrepoids en se penchant à l'opposé d'une certaine façon, on va au contraire donner des ordres simplissîmes au robot du type "maintenant avance ta patte ", on ne dicte pas de combien il doit avancer sa patte, il ne faut aucunes valeur ! , et dans une partie spécifique du programme faire que la moyenne des capteur de pression soit toujours conservée ce qui implique que le robot va tâtonner pour se pencher d'une certaine manière pour qu'il y ai équilibre !

Je ne sais pas si je suis assez claire mais ce que je tente d'expliquer c'est que le programme ne contient aucun tableau de valeur (à part les fins de courses des servos et encore), on ne sais pas de combien il va se pencher, ni de quel angle ou que sais-je, le robot s'adapte !

Ainsi quand le robot muni de cette théorie fonctionne, on ne prévoit pas ses gestes et ses séquences de mouvement car c'est lui même qui les confectionne !, on sait qu'il va aller tout droit mais on ne prévois pas la séquence qu'il va utiliser !

C'est la programmation du type "début connu ", "objectif connu", "maintenant tu te débrouille pour y arriver !"

Cependant cette théorie a malgré tout un sérieux problème ! Lorsque le robot avance, il fait pression sur le sol, donc le robot va "penser" qu'il tombe du côté où la pression est la plus forte ! Ça n'est pas la théorie en soit qui est mise en cause, c'est qu'il faudrait que le programme ne tienne pas compte des rapides évolution de pression en même temps que le robot avance (du type si je pousse sur la patte n°3 alors ne tient pas compte de la pression sur la patte 3) !

C'est bête comme problème !

Si quelqu'un a une idée pour y remédier je suis partant car si cette théorie aboutie ,ce robot va vraiment marcher très naturellement !

[Leon]

Ton postulat de départ me semble bizarre, pour ne pas dire faux.

Où as-tu vu que les efforts devaient être équivalents entre les pattes pour que ton quadrupède soit stable? Pourquoi dis-tu ça?
Un quadrupède qui monte une côte devra mettre plus de force sur ses pattes de derrière, et quand il descend, il faut qu'il mette plus d'effort sur les pattes de devant. Même arrêté dans une côte montante ou descendante, c'est toujours valable. Et c'est contraire à ce que tu veux faire. Et un quadrupède peut très bien rester stable sur 3 pattes, voire 2 seulement! Sinon, les bipèdes n'existeraient pas.

En statique (=sans mouvement), la stabilité d'un engin (à roue, à pattes) est garantie si la projection verticale de son centre de gravité est comprise à l'intérieur de la projection verticale de l'enveloppe de ses appuis. Tu as suivi?
C'est donc très différent de ce que tu annonces. Un quadrupède peut très bien rester équilibré sur 2 pattes. C'est sur cette règle simple que fonctionnent tous les robots à pattes à marche 'quasi-statique'. Les robots à marche 'quasi statique' sont des robots qui sont toujours bien stable, en équilibre (ils peuvent arrêter leur mouvement à n'importe quel moment sans tomber), et dont les mouvements sont suffisamment lents pour ne pas les déséquilibrer.

Rien qu'avec cette règle simple, je pense que tu peux t'amuser à faire des choses sympa, en détectant avec tes capteurs à quel moment les pattes touchent le sol. Si tu vois que la projection du centre de gravité est proche de la limite de la projection de l'enveloppe des appuis (voir de l'enveloppe des appuis sans la patte que tu vas prochainement bouger), alors il faut décider de bouger une patte, en choisissant celle qui va le faire gagner en stabilité. C'est en général la patte dont la projection est la plus proche de la projection du centre de gravité.

Après, pour généraliser ça à une marche plus rapide (mais pas encore "dynamique"), il faut remplacer la notion de projection verticale (orientation de la gravité) par une projection selon l'accélération totale subie par le centre de gravité de ton engin. L'accéléraion totale comprend non seulement la gravité, mais aussi l'accélération du centre de gravité due à son mouvement: [g+a] en vecteurs.

Pour la marche dynamique (que tu dis étudier), c'est à dire qui ne recherche pas la stabilité permanante (si un humain s'arrête dans sa marche, 1 pied en l'air, il tombe), mais la performance, la théorie est beaucoup plus complexe.

Leon.

[skyhack]

Salut Leon,

C'est bien pour ça que je fait appelle à des forums pour en apprendre d'avantage de personne comme vous et d'autre qui sont peut-être spécialisé dans ce domaine.

En effet la même valeur de contact n'implique pas forcement la stabilité, mais alors ne peut on pas tirer quelque informations sur l'équilibre du robot rien qu'avec des capteurs de pression (avec des valeurs autre que contact, non-contact) ?

La technique du centre de gravité etc , n'est pas mauvaise (elle est plutôt logique) mais si j'utilise un accéléromètre 3 axes, cela suffira-t'il pour avoir les infos sur la stabilité du robot et sur la direction de chute (ce qui m'interresse d'avantage)?

Je suis un peu dans le flou de ce côté là ...

PS: sinon qu'en dit tu sur la façon avec laquelle je compte programmer ce robot ? (la démarche inverse).

[Leon]

Salut Leon,

C'est bien pour ça que je fait appelle à des forums pour en apprendre d'avantage de personne comme vous et d'autre qui sont peut-être spécialisé dans ce domaine.

En effet la même valeur de contact n'implique pas forcement la stabilité, mais alors ne peut on pas tirer quelque informations sur l'équilibre du robot rien qu'avec des capteurs de pression (avec des valeurs autre que contact, non-contact) ?

La technique du centre de gravité etc , n'est pas mauvaise (elle est plutôt logique) mais si j'utilise un accéléromètre 3 axes, cela suffira-t'il pour avoir les infos sur la stabilité du robot et sur la direction de chute (ce qui m'interresse d'avantage)?

Je suis un peu dans le flou de ce côté là ...

PS: sinon qu'en dit tu sur la façon avec laquelle je compte programmer ce robot ? (la démarche inverse).

La façon la plus simple de déterminer l'orientation du corps (et donc connaitre la verticale par rapport à ton corps), c'est effectivement d'utiliser un accéléromètre 2 axes (longitudinal et latéral).

Mais en théorie, à partir des capteurs d'effort de chaque patte, et de la position connue de tes pattes, tu peux également déduire tout ça aussi! Normalement, avec le savoir d'un niveau "terminale S" en physique (mécanique), tu dois savoir retrouver ça: équilibre des forces, équilibre des moments autour du centre de gravité selon les axes longitudinal et latéral. Je ne dis pas que c'est simple, mais c'est faisable.
Après, pour appliquer ça, il faut impérativement calculer en "temps réel" la position 3D de tes pattes par rapport au centre de gravité, à partir de l'angle connu de chaque articulation.

Si tout ça te parait trop compliqué, tu peux aussi appliquer un algorithme "empirique".

Pour le reste, je ne peux pas trop t'aider, n'ayant pas compris ta "démarche inverse", surtout si elle est basée sur un postulat de base faux.

Leon.

[skyhack]

Bonjours à tous,

Bon, suite des travaux:
-ais reçu mes nouveaux servos (13 kg c'est du costaud ).
-m'attelle à la construction d'un châssis pour le 2ème axe des servos. Déjà plusieurs version réalisées: une par pliage successif en une pièce en alu, fonctionne certes, mais pas facile à faire, une autre avec un profilé, marche toujours pas, trop fragile.

Je recherche ainsi un tube rectangulaire de 6 par 3 en alu, il suffit alors d'en découper des tranches puis de couper le dessus pour que le servo s'y loge, MAIS C INTROUVABLE ! Casto, brico, leroy merlin, que nenni personne ne connais, et vous, savez-vous ou pourrais-je trouver ce genre de tube ! (c'est la meilleur solution pour mes servos) ?

PS: au fait pour ce qui est de la démarche de programmation à l'envers, elle n'est pas basée sur un postula faux, ma pseudo-théorie sur l'équilibre l'est, mais celle là non !

Pour faire simple :
La programmation que je souhaite réaliser est la suivante : quand on programme un robot, il faut penser au début à " qu'est ce que je veux que le robot fasse ?" c'est le BUT, le vecteur directeur, la source de lumière, et le robot va essayer dans son programme de l'atteindre tout en appliquant les différentes consignes intermédiaires, jusque là tout est claire ?
Par exemple dans mon cas , que doit "penser le robot" ?
-1): "Je me penche du bon côté avec la bonne inclinaison que je calcul en fonction de ...., PUIS je lève et avance ma patte".
-2): "Je lève la patte et je l'avance tout en tâtonnant pour garder l'équilibre".

?? TIC TAC TIC TAC TIC TAC ...

et bien ma programmation vise le point n°2), pourquoi, parce qu'elle use beaucoup moins de calculs, pourquoi ? car le programmeur se contre-fou de savoir les valeurs retournées par les <> capteurs, de quel angle doit se pencher le robot etc ... le but premier du robot c'est bien d'avancer, non ?, alors on vise le but ET on s'adapte en conséquence, et non l'inverse, ce que nous faisons bien malgré nous tout le temps sans s'en rendre compte.

Ainsi le robot pour garder son équilibre va "tâtonner" tout en levant sa patte, il s'adapte !

Je pense que c'est claire maintenant, je n'ai pas dit que les calculs devenaient absent mais qu'ils ne prenaient maintenant qu'une place "secondaire" dans le programme, on vise puis on agi.

Ça n'est pas forcement une programmation simple, mais en tout cas cette fois-ci c'est le robot qui se programme lui-même et non nous qui avons à le comprendre.

skyhack.

[skyhack]

Voilà une bonne démonstration d'un robot qui s'adapte en fonction de son environnement, c'est ce sur quoi je planche en ce moment sur mon robot.

<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/_6U46ZRHB6g&hl=fr_FR&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/_6U46ZRHB6g&hl=fr_FR&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

[skyhack]

ZUT, bug

[Electron]

Salut Skyhack

le programmeur se contre-fou de savoir les valeurs retournées par les <> capteurs, de quel angle doit se pencher le robot etc ... le but premier du robot c'est bien d'avancer, non ?

Pour avancer, le robot n'a t'il pas besoin de savoir s'il y a un obstacle ou pas devant lui ? c'est donc que le programmeur a bien besoin de connaitre les valeurs retournées par les capteurs non ?

Je la trouve bien cette vidéo youtube Sky

[skyhack]

Attention, je ne parle ici que du programme pour la marche sur sol plat, ou non, c'est déjà assez compliqué pour le moment .

Pour les valeurs retournées par les capteurs, il ne s'agit que des capteurs qui permettent au robot de savoir si oui ou non il est stable, les capteur pour les obstacles ne font pas parti du lot.

De plus, je dit que c'est le programmeur qui ne tient pas à savoir les valeurs retournées exactement ..., comment dire, étant donné que c'est le robot qui tâtonne, c'est à lui de les prendre en compte ainsi que leur variation, le programme est rempli de comparaison en tout genre pour les traiter, pas pour en connaitre la vrai signification. Je veux au mieux me rapprocher d'une auto-programmation, ça n'est pas moi qui a besoin des valeurs précises, mais le robot lui même.

Dans la vidéos que j'ai posté, c'est le robot qui traite les données, pas le programmeur (il a mieux à faire), comme j'avais déjà dit " on sait que le robot va aller tout droit, mais on ne sait pas par quels moyens et de quelles manière car c'est lui qui décide en fonction de l'environnement.

à l'écrit c'est pas toujours facile d'expliquer des sujets comme celui-là

PS: à vrai dire le fait d'ignorer totalement les valeurs et une utopie, il faudra toujours ou presque mettre ses mains dans ces valeurs, mais comme le robot, j'ai un but, mais je ne peut pas dire précisément comment je vais m'y prendre, en tâtonnant justement, la boucle est bouclée .

skyhack.

[Electron]

Pour les valeurs retournées par les capteurs, il ne s'agit que des capteurs qui permettent au robot de savoir si oui ou non il est stable, les capteur pour les obstacles ne font pas parti du lot.

De plus, je dit que c'est le programmeur qui ne tient pas à savoir les valeurs retournées exactement ..., comment dire, étant donné que c'est le robot qui tâtonne, c'est à lui de les prendre en compte ainsi que leur variation, le programme est rempli de comparaison en tout genre pour les traiter, pas pour en connaitre la vrai signification. Je veux au mieux me rapprocher d'une auto-programmation, ça n'est pas moi qui a besoin des valeurs précises, mais le robot lui même.

Haaaa ok
Y a comprendre mieux moi cette fois

à vrai dire le fait d'ignorer totalement les valeurs et une utopie

C'est vrai comme dirait la mère denis
Et comme dirait les freres dupond : "Et je dirais même qu'ignorer les valeurs est une utopie"

[skyhack]

Je recherche ainsi un tube rectangulaire de 6 par 3 en alu, il suffit alors d'en découper des tranches puis de couper le dessus pour que le servo s'y loge, MAIS C INTROUVABLE ! Casto, brico, leroy merlin, que nenni personne ne connais, et vous, savez-vous ou pourrais-je trouver ce genre de tube ! (c'est la meilleur solution pour mes servos) ?

Quelqu'un aurait une info à ce niveau, je bloque ?

Pour en revenir à ma façon de programmer, les mouvements en séquences que je fait ne sont là que pour tester les types de marches basiques, marche droit, gauche, droite, arrière et-ce avec les conditions initiales idéales (sol plat, pas d'obstacle). Cependant je ne compte bien sur ne pas m'y prendre comme ça par la suite, ce ne sont que des tests , pour la démarche adaptative, là c'est un autre problème, mais pour l'instant ce ne sont que des projets et des brouillons rien de finalisé.


Tant que j'y suis les capteur type "FSR" fonctionnent ils correctement, apparemment il n'y a que la parti centrale qui est sensible d'où une petite modification à faire ?

Merci de vos réponses.

Skyhack.

[Electron]

cherche avec google à "profilés alu" pour voir ?

[skyhack]

Salut,

Il est vrai que les briques easy sont intéressantes.

Je peut toujours essayer de le contacter car j'ai déjà mes servos, espérons qu'il puisse s'adapter aux briques easy.

En tout cas merci quand même.