Aller au contenu


Leon

Inscrit(e) (le) 19 juil. 2009
Déconnecté Dernière activité août 08 2018 06:09
****-

#96251 Quelle machines d'usinage recommandez vous?

Posté par Leon - 10 juin 2018 - 06:33

Salut.

 

A mon avis, il n'y a pas de réponse absolue. Il existe plein de machines différentes pour plein d'usages différents.

Je ne m'y connais pas forcément bien, mais il est évident que ça dépend d'au moins 3 ou 4 critères:

* type de matériau à travailler/usiner (acier, aluminium, bois, résine, etc...)

* taille de la pièce et de la zone de travail

* précision attendue

* vitesse d'usinage

 

Il est évident qu'on pourra utiliser une machine beaucoup plus simple pour découper de petites pièces en bois/résine que pour usiner de grandes pièces en acier.

 

Donc il ne faut surtout pas laisser croire aux utilisateurs de ce forum qu'ils obtiendront une réponse absolue.

 

Et puis un truc important : une fraiseuse ou un tour ne sont pas obligatoirement "à commande numérique"!

 

Leon.




#95375 Boston Dynamics

Posté par Leon - 12 mai 2018 - 03:48

:blink:

Oh, putain, Atlas!!!

C'est un truc de malade!!!

 

La difficulté de l'exercice, l'avance qu'ils ont sur tous les autres... Je n'ai jamais rien vu de tel.

 

C'est dommage qu'on ne voit pas les transitions marche-course, c'est normalement ce qu'il y a de plus intéressant. Ils ont peut-être des choses à cacher.

 

Skynet est en marche.

 

Leon.




#90161 Atlas Next Gen - Boston Dynamics

Posté par Leon - 17 novembre 2017 - 07:22

Ils veulent pas laisser d'indice sur leurs actionneurs! J'ai l'impression qu'ils ont masqué le bruit des moteurs avec un autre son de moteur => bruit synchro avec les chocs des pieds, bruit de moteur décalé (voir à la fin quand il lève les bras).. ou alors des actionneurs élastiques ?.. ou je suis parano.. :)

Depuis très longtemps, Boston Dynamics utilise des vérins hydrauliques sur leurs gros robots (dont les différentes générations d'Atlas, Big Dog). Ils ne s'en sont jamais caché!

 

Il y a bien évidemment un accumulateur de pression hydraulique, qui sert de réserve d'énergie à très court terme, permettant de délivrer une puissance instantanée monstrueuse. C'est ça qui permet l'explosivité des mouvements que l'on voit, avec des actionneurs de petite taille.

Car la pression de travail doit être vraiment élevée. 50 ou 100 bars?

Les bruits bizarres sont clairement liés à ce système hydraulique. Et surtout, le fait que ça soit un groupe hydraulique explique très bien que le bruit n'est pas synchrone : après des mouvements, le groupe hydraulique doit tourner à fond pour recharger les accus hydrauliques, même si le robot reste statique.

 

Les premiers robots de ce type (les premiers Big Dog) étaient équipés d'un groupe hydraulique à moteur thermique. Voir vidéo ci-dessous.

 

Ici, sur Atlas, c'est clairement un générateur hydraulique alimenté en électrique, avec des batteries.

Les premières générations de bipède de Boston Dynamics (Petman et Atlas), celles qu'on voyait évoluer en intérieur exclusivement, avaient un générateur hydraulique externe, et des tuyaux externe qui descendaient du plafond pour alimenter le robot.

 

Pour finir, on retrouve enfin des figures (salto) qu'on n'avait pas vues depuis longtemps. C'était il y a 30 ans au MIT. (à l'époque, j'avais 10 ans et ça me passionnait déjà, je vous laisse deviner mon âge).  Ces gens là ont défriché de nouvelles voies dans la robotique... Puis ils ont fondé... Boston Dynamics!

 

Je vous conseille vraiment de regarder TOUTES les vidéos de la chaine Youtube Boston Dynamics.

 

Leon.




#90130 Atlas Next Gen - Boston Dynamics

Posté par Leon - 17 novembre 2017 - 07:24

Nouvelle vidéo d'Atlas Next-Gen, le robot humanoide de Boston Dynamics.

Atlas est quasi prêt à participer à un concours de gymnastique!

 

Ils sont sur "la bonne voie" (ou la mauvaise, selon le point de vue) c'est certain.

Ca fait penser aux robots sauteurs du MIT d'il y a 30 ans (déjà, je suis vieux).

 

Skynet est en marche...

 

Leon.




#89278 WALK-E, Crowdfunding sur Ulule, Soutenez nous !!!

Posté par Leon - 25 octobre 2017 - 11:21

Oui, mais comment as-tu souder les éléments que tu nous a montrés et quel est l'avantage de les souder ?

L'avantage de les souder est indéniable.

Des "support à pile", avec de simples contacts, ça provoque des chutes de tension, le contact n'est pas parfait, ça vieillit mal, ça prend de la place. Sur des gros blocs batterie, ça devient ingérable.

Par contre, ces éléments Li-Ion supportent effectivement très mal les soudures au fer à souder classique. C'est risqué de les souder (risque de départ de feu / explosion), et ça endommage potentiellement les éléments.

J'ai moi même endommagé involontairement des accus(NiMh à l'époque) alors que je ne savais pas que la chaleur intense pouvait endommager des accus. L'endommagement ne se voyait pas, mais au bout de quelques cycles de charge/décharge, j'avais des éléments morts.

 

Le matériel pour souder les accus d'un pack batterie, c'est très spécifique : soudure par points, avec courant bien réglé. Ca limite beaucoup l'échauffement de l'accu.

 

Pour faire des montages de Li-Ion en amateur, je recommande d'acheter des accus ou assemblages d'accus fourni avec languettes de connexion déjà soudées aux accus. Dans ce cas, on s'affranchit de tous ces problèmes, vu qu'on ne soude que les languettes, avec peu d'échauffement de l'accu en lui même (grosse dissipation thermique par la languette elle même).

C'est ce qu'a visiblement utilisé Yougo pour Walk-E, voir vidéo n°2, et c'est très bien.

Voir l'option "solder tags" sur le site où Yougo a acheté ses accus.

https://eu.nkon.nl/p...7v-2900mah.html

 

Leon.




#88450 Projet de bipède - marche dynamique

Posté par Leon - 07 octobre 2017 - 02:21

Je me rend compte que je n'avais jamais décrit l'algorithme utilisé pour la marche dynamique sur ce BOB5 simulé.

Je vais donc décrire ça avec des mots simples, et si j'ai le temps, je donnerais des précisions sur la foultitude de petits détails nécessaires pour faire fonctionner ça en vrai. Là, ça n'est qu'une ébauche.

 

C'est de l'automatique bourrine

Pour bien comprendre comment ça fonctionne, je vous conseille d'avoir des bases en automatique. C'est uniquement des asservissements bien bourrins. Il y a plusieurs asservissements imbriqués.

Tout est calculé en temps réel, en dynamique. Le robot réagit à ses capteurs (exclusivement des gyros).

Il détermine en temps réelle s'il doit lever/poser une jambe, et laquelle. Il n'y a rien qui est fait pour alterner périodiquement les pas droite-gauche, ce sont des mouvement reflex exclusivement, qui mis ensemble font qu'il marche. C'est ma façon de penser, de travailler.

Pour que ces asservissements fonctionnent, je suis contraint de marcher genoux pliés, pour pouvoir à tout instant bouger le pied en 3D par rapport au bassin. Si les jambes étaient tendues, ça serait "contraint". Ca simplifie les asservissements.

 

Le robot connait en permanence

 * orientation du tronc en roulis et tangage (2 gyroscopes)

 * la hauteur du bassin par rapport à un sol plat. La hauteur est déterminée par l'extension vers le bas de la jambe la plus basse

 

Cinématique inverse:

c'est une partie bas niveau qui me permet de déduire les angles des servos en fonction de la position relative entre pied et bassin que je souhaite obtenir.

Tous les mouvements sont déterminés à partir de coordonnées 3D.

Pour faire des mouvements fluides, on décompose en temps réel la position 3D de chaque pied selon une vitesse de déplacement maxi (atteignable par les actionneurs), avant l'algo de cinématique inverse.

 

Orientation du pied:

Les pieds sont toujours orientés pour être parallèles au sol en toute circonstances, même si le tronc penche en avant ou en arrière

 

Principe général de la marche:

Chaque jambe est asservie avec un automate global à états. Chaque jambe peut avoir 4 états : jambe posée, jambe levée, jambe en train d'être posée, jambe qu'on commence à lever. Dans chacun des 4 états, le comportement de la jambe est très différent.

Cet automate d'état le bipède considère, et fait en sorte qu'il ait obligatoirement 1 ou 2 jambes posées. 0 jambes posées n'est pas prévu, si ça arrive (saut), ça fait n'importe quoi.

Par exemple, cet automate à états impose qu'une jambe soit posée avant de lever la 2ieme.

 

Jambe(s) posée(s):

La ou les jambes posées vont essayer de maintenir le tronc droit, vertical. C'est le principe de l'asservissement d'un pendule inversé. La baguette que l'on tient verticale en équilibre sur le doigt. A chaque instant, j'estime l'orientation 2D du tronc (roulis/tangage), et la vitesse angulaire du tronc; Et j'applique un asservissement PID. La commande, c'est la position 2D du/des pieds posés au sol par rapport au tronc. Bref, je déplace les pieds en dessous du tronc pour maitriser la chute du pendule inversé.

Ce premier pendule inversé, c'est le tronc lui même, et son point d'appui (celui que je bouge, dont je fais varier la position), c'est le bassin, le point à l'entrejambe (oui, son derrière). Donc je déplace en 2D le bassin par rapport au sol pour garder le tronc droit.

 

Pour que l'asservissement soit efficace, dynamique et prédictif, je modélise le comportement global du robot posé au sol, en considérant un 2ieme pendule inversé. Ce 2ieme pendule inversé c'est le robot complet (pas juste le tronc), et son appui bas, c'est un point fictif d'appui au sol; c'est un point au sol à l'intérieur du polygone d'appui au sol du robot. Le point d'appui au sol peut être situé entre les 2 pieds si les 2 sont posés, et il est situé le long du pied posé si 1 seul pied est posé.

L'algorithme a donc une certaine liberté pour déterminer la position de l'appui bas du pendule inversé (qui est un point d'appui fictif), ce qui va aider le robot à se stabiliser (gérer le déséquilibre et la vitesse de déséquilibre), et à l'orienter : accélérer vers telle direction 2D.

 

J'essaye aussi de maintenir la hauteur du tronc constante par rapport au sol. Si je ne peux pas, si un pas trop grand, une jambe trop tendue me fait perdre de la hauteur, alors je m'adapte. J'essaye de stabiliser cette hauteur, de réhausser tout doucement le tronc, doucement pour ne surtout pas décoller les 2 pieds en même temps. C'est ce qu'on voit sur la vidéo quand le robot se rattrape après un grand écart.

 

Jambe levée:

La jambe est levée à une hauteur fixe par rapport au sol, assez faible pour pouvoir faire des mouvements rapides.

Le seul objectif est de faire aller le pieds à la nouvelle position d'appui le plus vite possible.

La position cible d'appui du pied en l'air est mise à jour en temps réel. La position cible n'est donc pas la même entre le moment où on a levé le pied et le moment où on pose le pied.

La position cible est déterminée comme un asservissement à partir de 3 choses:

* équilibre actuel du robot : position du centre de gravité par rapport au pied posé

* de la vitesse de déplacement du centre de gravité par rapport au sol (permet d'anticiper)

* de la volonté d'accélérer ou décélérer dans telle direction 2D

On cherche à garantir le meilleur équilibre possible.

Si la position cible n'est pas atteignable (grand écart, jambe croisée), on fait au mieux, et on pose rapidement le pieds une fois qu'on a fait le maximum.

Il y a aussi une logique pour ne pas croiser les jambes, pour ne pas se faire d'auto-croche patte.

 

Transitions:

Les transitions levé/posé sont réalisées en évitant de déséquilibrer le robot, donc à peu près en essayant d'avoir une vitesse 2D du pied par rapport au sol qui soit nulle.

Quand lever le pied? Dans 2 cas:

cas n°1 quand on est en déséquilibre. Globalement, le déséquilibre, c'est le fait que la projection 2D du centre de gravité au sol sort du polygone d'appui du robot au sol. Dans le calcul de l'équilibre, j'intègre également 2 choses supplémentaires:

* la vitesse 2D du centre de gravité du robot par rapport au sol

* la volonté d'accélérer/décélérer dans telle direction 2D

Cas n°2 : quand les 2 pieds sont posés, et que l'asservissement "pied posé" impose une position du pied qui devient pas catholique : pied trop rentré, jambe trop tendue. C'est ce que l'on voit sur la vidéo quand le robot se rattrappe après le grand écart.

 

Balancement droite-gauche:

Il existe également une logique qui tend (surtout à basse vitesse) à rapprocher la position 2D du centre de gravité vers le pied qui va servir le plus probablement d'appui (rester au sol) lors du prochain lever de pied (anticipation du déséquilibre). On le voit au tout début de la vidéo. C'est hyper utile pour la stabilité à basse vitesse.

 

Mathématiques

Tout cela nécessite beaucoup de calculs 2D/3D et asservissements, qui m'ont fait assez mal à la tête! :blink:

 

Leon.




#87253 Que faites-vous de vos robots ?

Posté par Leon - 01 septembre 2017 - 05:27

Je me permet de revenir au sujet initial, que je n'avais pas vu.

J'ai une question en tête depuis trop longtemps, il faut que je  vous la pose : que faites-vous de vos robot quand ils sont terminés ?

Si vous les avez fait pour vous initier, les démontez-vous quand vous avez réussi ce que vous vouliez et avant de passer à autre chose ?

Je vais décrire ma façon de faire.

 

Tout d'abord, ce qui me passionne, ça n'est pas de posséder des robots, mais de les concevoir, les construire, les programmer. Comme vous tous, j'y passe un temps énorme. Donc une fois que j'ai fini de bosser dessus, je m'amuse un peu avec, et je les range assez rapidement pour passer au projet suivant.

Un peu dans l'esprit du Monster Garage : "Leon n'a pas de temps à perdre avec les robots qui buggent, il y a de la soudure dans l'air et du code à pisser, le prochain projet de Leon est déjà sur les rails".

...désolé, mais j'adore cette émission.

En fait, j'ai toujours plein de projets futurs en tête. J'ai énormément d'idées, de sujets sur lesquels j'aimerais bosser.

J'ai toujours passé un temps énorme à réfléchir à des projets hypothétiques, à me creuser la cervelle pour imaginer comment je ferais tel truc.

Alors j'essaye vraiment de finir un projet avant de passer au suivant; mais ça n'est pas facile, car le projet suivant pousse en général très fort dans ma tête pour passer devant le projet en cours.

 

J'ai fait un petit nombre de "robots". Plus ou moins réussis.

Mon premier vrai robot, BOB2,je l'ai démonté, j'ai bazardé une grosse partie, alors qu'il fonctionnait. Je ne sais pas vraiment pourquoi j'ai fait ça, et je l'ai longtemps regretté. J'aurais bien aimé le revoir fonctionner, c'était vraiment un projet sympa pour l'époque, ça représente mes débuts en robotique.

 

Donc depuis ça, j'essaye de conserver mes robots bien rangés et opérationnels. Quitte à démonter quelques pièces facilement remontables, et les réutiliser sur un autre projet.

Une roue, une batterie, un microcontrôleur (stocker précieusement le code).

Le remontage doit être facile et "rapide" : 1 à 2h grand maximum pour le rendre de nouveau opérationnel.

 

Pourquoi les conserver? Parce que c'est hyper gratifiant de ressortir un projet sympa plusieurs années après. Je l'ai fait avec tous mes projets qui sont arrivés à un stade "opérationnel".

Se remémorer de comment on travaillait à l'époque, retrouver le comportement du robot, ses bugs, ça fait remonter plein de souvenirs intéressants, ça donne aussi des pistes de réflexions auxquelles on ne pensait plus depuis des années.

 

Attention, je ne conserve évidemment pas les (nombreux) projets mort-nés, ce qui ne fonctionneront jamais, qui n'ont aucun avenir, les essais infructueux. Si un projet n'a absolument aucun avenir, et ne pourra jamais être repris dans le futur, autant tout démonter et ré-utiliser le matériel. Ces essais ratés sont intéressant car ils permettent d'apprendre. Mais il ne sert à rien de les conserver.

 

Aimeriez-vous leur donner une "vie" après cette réalisation ?

Aimeriez-vous construire un robot pour faire des tournois sans règle trop stricte ou compliquée ?

Qu'est-ce que tu appelles "leur donner une vie"?

Pour les tournois, ça ne m'intéresse pas plus que ça. J'ai déjà participé 2 fois dans ma jeunesse à la coupe de France de robotique. C'était très sympa, je ne regrette pas de l'avoir fait... mais ça ne m'attire plus. Je préfère faire des projets à mon rythme, pour me faire plaisir, sans contrainte.

Par contre, je suis plus partant pour l'organisation de rencontres, de démonstrations, de présentation du travail de chacun. Des séances de partage, et d'amusement, rien de plus.

 

Leon.




#86918 Vidéos Bipèdes

Posté par Leon - 23 août 2017 - 06:09

Franchement, l'utilité d'un tel "Mecha" par rapport à des engins de chantier classiques, il faudra m'expliquer. Tu penses réellement qu'un tel robot est capable d'exercer la même force, avec la même dextérité, qu'une excavatrice, dans le cas d'immeubles effondrés?

Pareil pour la manutention?

 

Ca n'est pas parce qu'on a tous vu des films / manga où ce genre de robots savaient faire des choses hallucinantes, que c'est réaliste! 

 

Si tu t'y connais un peu en mécanique, tu comprendras que la mise en oeuvre d'un tel Mecha est super complexe et pas réaliste. Une grosse excavatrice, ça a un centre de gravité très bas, et une grosse base bien large pour s'appuyer de manière stable au sol, et pouvoir exercer des forces énormes sur son outil. Je vois mal comment un gros Mecha, avec sa morphologie de bipède, pourrait être plus avantageux.

 

Pour info : nous sommes en l'an 2000, et les voitures ne volent toujours pas, alors qu'on voit des voitures voler dans les films de SF depuis plus de 50 ans.

Bref, il ne faut pas confondre la (science) fiction avec la réalité.

 

Leon.




#86683 Multitâches avec arduino

Posté par Leon - 13 août 2017 - 05:51

Salut Path.

 

Oui, comprendre les contraintes du multitâche temps réel, c'est important.

Mais il n'y a pas 1 seule méthode pour y arriver.

 

Attention, je ne connais rien en Arduino, mais voici quelques éléments supplémentaires. C'est issu de mes expériences diverses.

 

* OK globalement pour ton affirmation sur les fonctions "bloquantes"

 

* Tu dis que les capacités en interruption d'un arduino Mega sont limitées. C'est issu de ton expérience? Si c'est le cas, il faut bien voir qu'un Atméga, c'est un microcontrôleur 8 bits très peu performant, et largement dépassé techniquement. Pour le même prix, on peut trouver des microcontrôleurs 32 bits avec plusieurs dizaines de ko de RAM, et tournant à ~100MHz. J'utilise principalement les ARM Cortex M3 / M4. Pour les suites de développement simples, équivalente à Arduino, j'utilise MBED : https://developer.mbed.org/

Un tel microcontrôleur 32 bits est infiniment plus performant qu'un Atméga Asthmatique, et il est beaucoup plus riche en périphériques, bus haut débit interne, DMA, gestion des interruptions, souplesse de configuration des broches.

 

* multiplier les microcontrôleurs similaires, c'est rarement nécessaire, et c'est une source d'emmerdes incroyable. OK pour faire cohabiter un R-Pi et un Arduino, l'un pour des fonctions "haut niveau" (serveur web, streaming vidéo, traitement d'image, algo de cartographie), et l'autre pour les aspects "temps réel / bas niveau". Mais faire cohabiter 2 arduinos, c'est rarement judicieux, car on peut très souvent trouver une solution "logicielle" si c'est un simple problème de cohabitation de tâches de priorité différentes. La seule application légitime que je vois pour utiliser plusieurs microcontrôleurs équivalents, c'est pour "multiplexer" des fils, comme on dit dans l'électronique automobile : quand des capteurs/actionneurs sont nombreux et éloignés géographiquement, on a parfois intérêt à faire transiter une liaison "série" plutôt que des dizaines de fils.

 

* On peut faire du "multi-tâches temps réel" de plusieurs manières différentes

    - avec un OS temps réel coopératif (je n'ai plus en mémoire, il faut que je retrouve)

    - avec un OS temps réel préemptif (type RTOS)

    - avec un simple séquenceur fait maison : une boucle principale, qui appelle successivement, et à intervalles réguliers, mais à des périodes différentes et/ou en fonctions d'événements, les différentes "tâches". C'est comme l'OS coopératif, mais en beaucoup plus simple

    - avec des interruptions, en plus du séquenceur. Interrputions déclenchées sur timer ou sur événement externe (IO, périphérique)

 

* perso, j'ai testé les 3 dernières solutions, et ce que j'en retiens:

    - Attention avec les OS temps réel préemptifs. C'est pratique, ça simplifie la vie, surtout pour coder des systèmes très complexes, mais... Si on veut faire des tâches très rapides et précises à la milliseconde près ou moins, c'est complexe. Le basculement de tâches bouffe énormément de performances, et ça devient inapproprié avec des tâches très récurrentes (moins de 1ms).

    - Au final, un tel OS n'est pas forcément indispensable pour nos applications simples.

    - Perso, tous mes derniers développements sont un mixte de : séquenceur fait maison + interruptions.

 

* Interruptions (=INT). Plusieurs choses à dire:

    - Contrairement à ce que tu dis, il est tout à fait possible d'écouter les autres sources d'interruption pendant une interruption. A ma connaissance tous les processeurs ne réagissent pas de la même façon quand une INT est en cours et qu'une autre INT arrive. Soit il faut désactiver temporairement les INT pendant une INT puis les réactiver après. Soit ça n'est pas nécessaire, et les autres IRQ sont mises en attente. Mais dans certains cas, avant de sortir de l'INT, il est possible de vérifier, par soft, qu'aucun autre événement à traiter n'est arriver.

    - La règle qui consiste à imposer de rester un temps le plus court possible pendant l'INT, et à ne surtout pas appeler de fonctions bloquantes, est une règle simpliste. Elle est valable dans la majorité des cas... Mais on peut s'en affranchir! Pour un développement en cours, je gère énormément de choses "temps réel" avec des INT, car j'ai besoin de temps de réactions hyper rapide, et j'ai besoin d'interrompre immédiatement (à quelques microsecondes près) les tâches moins prioritaire, et je dois faire beaucoup de choses dans ces INT. Et j'appelle des fonctions "légèrement bloquantes" (= qui durent des centaines de microsecondes) dans les INT! Au final, j'arrive dans le pire des cas à 20% du temps passé en INT. C'est énorme, mais ça marche! Il faut bien comprendre les contraintes, le principe. Et bien évidemment tester pour comprendre comment ça se comporte. L'analyseur logique est l'outil indispensable pour débugger ça!

 

Leon.




#85996 Mes robots web sécurisés avec accès publique !

Posté par Leon - 19 juillet 2017 - 09:18

Le quartier de la défense, je connais, j'y ai travaillé quelques années.

Mais j'avoue que je n'ai jamais songé à y habiter, ça n'est pas pour moi.

 

En tout cas, tu as un bel appartement de geek avec cet écran géant et ce robot! 

 

Leon.




#85414 WALK-E, Crowdfunding sur Ulule, Soutenez nous !!!

Posté par Leon - 04 juillet 2017 - 06:13

Une petite question vous utilisez quoi comme simulateur ?

Je ne sais pas à qui s'adresse cette question... A tout le monde?

 

De mon côté, pour mon bipède BOB5, j'utilisais Anykode Marilou. Voir les sujets suivants:

http://www.robot-maker.com/forum/topic/9118-anykode-marilou-simulateur-robotique/

http://www.robot-maker.com/forum/topic/9109-projet-de-bipede-marche-dynamique/

 

 

Attention : si tu veux discuter du sujet, il faut le faire ailleurs. Ici, on est sur le sujet qui parle de Walk-e.

 

Leon.




#85316 WALK-E, Crowdfunding sur Ulule, Soutenez nous !!!

Posté par Leon - 01 juillet 2017 - 07:32

Salut à tous,

 

Je n'intervient que rarement sur ce forum, mais là, ça me semble nécessaire.

Tout le monde a l'air très enthousiaste autour de ce projet, et je ne vois que des retours positifs, c'est très bien, mais... je vais devoir faire mon rabat-joie, désolé (c'est souvent mon rôle). Je suis assez surpris que personne ne l'ait déjà fait.

 

Est-ce que vous avez conscience de la complexité d'un tel projet? C'est monstrueux.

Même si vous maitrisez la réalisation de pièces 3D, même si vous maitrisez la théorie des réseaux de neurone, même si vous savez utiliser des arduino et des capteurs de poids... passer à la réalisation d'un robot comme Cassie, c'est carrément autre chose, c'est d'un autre niveau.

C'est d'une difficulté que vous n'imaginez peut-être pas encore. A votre avis, combien de centaines d'homme-jour Cassie a nécessité en bureau d'étude?

 

Vous prenez exemple sur Cassie, qui est un magnifique robot. Mais avez-vous conscience que Cassie coute beaucoup plus de 3000€? Je parle bien sans compter les "couts d'étude". Cassie utilise beaucoup de métal usiné, de carbone. Faire la même chose avec de l'impression 3D, je n'y crois pas beaucoup.

Combien de versions de prototypes et combien d'années ont été nécessaire pour arriver à un résultat abouti pour Cassie?

 

Est-ce que vous partez de zéro? Ou alors est-ce que vous partez d'un concept "open-source" déjà dispo? Si oui, lequel? Je n'en connais pas et ça m'intéresse si ça existe.

 

Est-ce que vous avez déjà des expériences passées? Je veux dire de robots qui nécessitent une bonne dynamique, une structure rigide, des asservissements intelligents et temps réels?

Combien d'heures par semaines comptez-vous consacrer sur le projet? D'un point de vue planning, combien d'années de travail vous visez? Rester groupés et motivés pendant plusieurs années autour d'un projet commun, ça n'est pas facile.

Combien de versions de prototypes complets estimez vous nécessaire pour arriver à un résultat abouti? 3 versions? 4? 5?

Et en terme de budget total?

 

Il y a 3 ans, j'avais comme projet, de réaliser un bipède à marche dynamique. Je l'avais étudié en simulation, puis j'avais commencé à le construire en vrai.

http://www.robot-maker.com/forum/topic/9109-projet-de-bipede-marche-dynamique/?p=60671

http://www.robot-maker.com/forum/topic/9816-bob5-bipede-1m20/

Mais j'ai abandonné pour plusieurs raisons. Rien que la partie simulation m'avait pris pas mal de temps, mais j'étais tout seul.

N'hésitez pas à commencer par simuler votre robot pour déverminer vos algorithmes. On peut même simuler les imperfections des capteurs / actionneurs / électronique pour tester la robustesse des algos (temps de retard, jitter, imprécision, bruit, etc...).

 

Bon courage dans tous les cas. Je suivrais vos avancées avec intérêt.

Si vous avez d'aide sur les items suivants, n'hésitez pas à me solliciter par message privé (je consulte rarement le forum):

* électronique temps réel

* asservissements (classiques, complexes, mais pas réseau de neurone)

 

Leon.




#82802 Pablo odysseus, robot artist Land Art

Posté par Leon - 01 mai 2017 - 06:25

Sinon, tu as déjà réussi un dessin complet? Je ne vois aucune photo d'ensemble d'un dessin complet, et ça serait vraiment chouette.

Si nécessaire avec une vue aérienne depuis un drone. Il y a forcément des volontaires équipés de drone dans ton coin, si tu n'en n'as pas un toi même!

Voire carrément une vidéo aérienne...

 

 

Côté navigateur, petit changement de stratégie. Du fait des imprécisions liées au système satellite, on fait appel à l'odomètre lorsque la distance à parcourir est inférieure à 1 mètre (à ajuster par essais) , au récepteur GNSS sinon, au compas dans tous les cas. En mode DEBUG ça ce passe bien (c'est un mode où je simule en live les données des capteurs par des informations que je maitrise avec des curseurs), à voir sur le terrain ce que ça donne.

Par rapport à ça, la meilleure stratégie reste la "fusion de données". N'utiliser qu'un seul jeu de données "position / orientation", qui est élaboré à partir de la fusion des données GNSS et odomètres.

Dans le principe : l'odomètre renseigne la partie "haute fréquence" du signal, et le GNSS la partie "basse fréquence".

 

Une méthode simple pour faire cette fusion de données :

1) tu mets à jour en temps réel la position avec l'odomètre. C'est précis sur les petits déplacements, et la précision de mesure est très bonne (quelques cm).

2) Mais en plus, tu recales lentement la position par rapport au satellite. Le lentement est super important. Par exemple, si tu as un signal GNSS toutes les secondes, tu ne recales (par exemple) que de 5% de l'écart entre la position estimée et la position GNSS chaque seconde. Ca fait que ça converge en ~20sec. la vitesse de recalage sera bien évidemment à affiner avec des tests sur le terrain.

 

Si ton robot fait des pauses ou roule à basse vitesse, pour éviter les "sauts" de l'estimation de position (à cause de la dérive GNSS), tu peux aussi choisir la vitesse de recalage en fonction de la vitesse réelle du robot: à l'arrêt, tu ne te recales pas du tout, et à haute vitesse tu te recales rapidement. Du coup, tu te recales de X% tous les mètres (non plus toutes les secondes).

 

Leon.




#80808 Bras robotique sur drone

Posté par Leon - 22 mars 2017 - 07:39

@AsKman, est-ce que tu as bien conscience que:

 

* vu que ton drone bouge tout le temps (même s'il bouge légèrement), tu devras ajuster en temps réel la position 3D du bras. Rien d'impossible, bien évidemment, mais c'est plus complexe que juste déterminer une fois pour toutes

 

* les mouvements du bras vont sans doute perturber le drone. Beaucoup plus qu'une nacelle avec appareil photo par exemple, vu que le centre de gravité d'une nacelle varie très peu. Du coup, tu auras 2 asservissements temps réel qui vont potentiellement se perturber mutuellement (asservissement du drone et asservissement du bras). C'est pas simple à gérer, et il est facile de faire des asservissements "auto oscillants" dans ces conditions. Il y a des méthodes pour éviter ça, et notamment mettre des dynamiques (temps de réponse) très différents entre les 2, ou alors mettre un bras très léger par rapport au reste du drone.

 

* la vidéo que tu donne en exemple nous montre un cas d'école assez simple : bras fixe par rapport au sol. Il suffit d'avoir une position de 2D de l'objet à saisir, la profondeur est constante, l'objet est toujours à la même "altitude" par rapport au bras. Dans le cas du drone, la profondeur pourra varier, donc il faudra estimer en temps réel la position de l'objet par rapport au drone en 3D, c'est plus complexe. Je ne sais pas comment tu comptes faire ça. De la stéréovision avec 2 caméras?

 

Bref, ça n'est pas si simple.

C'est sans doute faisable, mais pas simple.

Je suivrais avec intérêt tes avancées. N'hésites pas si tu as besoin de conseil.

 

Leon.




#80397 Vidéos Bipèdes

Posté par Leon - 16 mars 2017 - 06:46

Allez directement à 5'35". Mais je n'aime pas trop le nouveau look qu'il veut donner à son bipède.
 

J'avoue que je suis impressionné par ce qu'il réussit à faire en amateur. Même si le résultat est pas terrible (énormément de jeu mécanique dans les jambes), la démarche est très intéressante. C'est assez pragmatique, plein d'idées intéressantes, et ça marchotte. Faire des robots bipède de cette taille, c'est un défi énorme, et il l'a relevé!

 

Donc perso, même si je ne suis pas fan de l'aspect "Cosplay", j'aime bien ce qu'il fait.

 

Je me suis aussi demandé comment faisait cet homme pour avoir autant de temps libre pour sa passion.

J'ai rapidement compris : avec le buzz qu'il fait, il gagne 600$ par vidéo avec Patreon. A 7 vidéos le mois dernier, il a gagné 4200$ !!! Moins les impots certainement. Ca fait une belle somme d'argent. Et c'est sans compter les pubs Youtube (20 000 vues en moyenne par vidéo). Ca couvre certainement une grande partie de ses frais (électronique, imprimante 3D et consommables, etc...), et ça doit aussi lui permettre de vivre.

https://www.patreon.com/XRobots

 

Payé pour s'amuser, c'est un bon concept. J'avoue que je suis jaloux.

Mais bon, je principe de Patreon me dérange quand même beaucoup : la rémunération dépend plus du buzz que de la qualité et l'utilité du travail.

 

Leon.