Aller au contenu


Contenu de Leon

Il y a 1000 élément(s) pour Leon (recherche limitée depuis 04-avril 13)



#96251 Quelle machines d'usinage recommandez vous?

Posté par Leon sur 10 juin 2018 - 06:33 dans Usinage

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 sur 12 mai 2018 - 03:48 dans News dans le domaine de la robotique

: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.




#91554 Projet RobEx pour passionné de robotique et de patrimoine - à l'abandon

Posté par Leon sur 13 janvier 2018 - 08:26 dans Bric-à-brac

Mais comme je l'ai dit, je préfère les robots ...

Mais un Drone, ça fait partie de la famille des robots!

 

Et puis autre chose : Si tu explores ces monuments abandonnés avec des robots, tu ne pourras pas t'imprégner dans le détail de l'atmosphère, de l'ambiance du lieu. Découvrir un lieu atypique dans ses moindres recoins, le vivre pour de vrai, c'est vraiment quelque chose. Ca laisse des souvenirs énormes.

Le faire à travers un écran, quelle que soit la qualité du matériel, je trouve ça carrément moins drôle.

 

Après, je comprends ton choix : c'est à mi-chemin de 2 de tes passions : robot et "patrimoine abandonné".

 

Leon.




#91544 Projet RobEx pour passionné de robotique et de patrimoine - à l'abandon

Posté par Leon sur 13 janvier 2018 - 03:09 dans Bric-à-brac

J'ai pensé au drone mais la réglementation est contraignante, à cela s'ajoute qu'il est difficile de piloter un drone sans le voir à l'intérieur de constructions et la prise de photos par un drone ce n'est pas ce qu'il y a de mieux et les photos tirées de vidéo je n'en suis pas fan non plus. (je sais je suis très négatif :D )

La réglementation des drones serait contraignante? En intérieur? En intérieur, tu fais ce que tu veux avec un drone!

Ou alors je n'ai pas compris ce que tu veux dire.

 

Pour l'exploration de bâtiments avec un drone, il existe des drones 100% entourés de protections (pare-chocs réalisés avec des tiges/tubes carbones) qui ne craignent pas les contacts avec les murs ou le sol ou le plafond.

Ce carénage (très ouvert) peut même prendre la forme d'une boule ou d'un cylindre, articulé autour du chassis du drone, pour rouler librement sur le sol ou sur les murs, et encore moins perturber le vol.

 

Pour la prise de vue depuis un drone, c'est parfaitement au point. Les nacelles stabilisatrices pour appareil photo fonctionnent très bien. J'ai déjà vu aussi des drones plutôt léger qui se posaient dans des endroits dangereux avant de prendre des photos depuis le sol.

 

Leon.




#90382 Drones + Intelligence Artificielle

Posté par Leon sur 27 novembre 2017 - 07:30 dans Drone, Robot volant, et autres machines volantes

Sympa... mais attention:

Dans les 2 vidéos, le terrain est équipé de capteurs type "motion capture". Vous savez, ces capteurs à quelques dizaines de milliers d'euros fait de caméras IR (très haute résolution) qui traquent des balises IR en 3D.

 

Donc les drones ne sont pas du tout autonomes!

Et ça fait toute la différence. Ici, ça n'est qu'une histoire d'algo, qui travaillent avec des capteurs parfaits. Bref, ça n'est pas utilisable dans la vraie vie!

 

Et puis ce genre de vidéos, ça fait entre 5 et 10 ans qu'on en voit.

 

Je suis beaucoup plus impressionné par les quelques drones capables d'évoluer de manière 100% autonome dans un environnement intérieur encombré.

http://techtv.mit.edu/videos/4149

 

Perso, ce genre de "performance" m'impressionne vraiment beaucoup moins que l'humanoide Atlas de Boston Dynamics, justement parce que ça n'est pas représentatif du monde réel.

 

Leon.




#90161 Atlas Next Gen - Boston Dynamics

Posté par Leon sur 17 novembre 2017 - 07:22 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

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 sur 17 novembre 2017 - 07:24 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

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 sur 25 octobre 2017 - 11:21 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

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.




#88616 Matériel pour la maintenance de robot sur site

Posté par Leon sur 11 octobre 2017 - 05:36 dans Bric-à-brac

Oh, mais il faudrait acheter carrément un semi remorque pour pouvoir déplacer la totalité de ton atelier. Ca serait beaucoup plus simple. :crazy:

 

Leon.




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

Posté par Leon sur 09 octobre 2017 - 05:41 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Oui on a effectivement des objectifs qui vous paraissent un peu con, mais bon ça nous force a nous bouger.

Ne croyez pas qu'on a balancer ça alors que l'on a pas commencer le code, ce n'est pas le cas,

si on dit ça c'est qu'on a des résultats pas trop horribles ;)

Du coup, pourquoi ne pas montrer ces résultats dans la vidéo?

 

Leon.




#88475 logiciel modélisation robot anykode

Posté par Leon sur 08 octobre 2017 - 12:24 dans Logiciels

Nooooooooooooooooooooooooooooooooooooooon !

Pas de variables globales ! Ça réduit la visibilité du code, ça créé des problèmes de masquage de variable (la variable n globale et la variable n locale), et si ton code inclue plusieurs fichiers, ça devient un enfer de maintenance pour peu que tu aies plusieurs variables globales avec le même nom. À moins d'être obligé de définir une variable comme globale (par exemple, en Arduino, le main() est caché et on n'a accès qu'aux fonctions loop et setup), il y a toujours une solution simple qui utilise la bonne portée des variables.

Pas vraiment d'accord avec ça.

OK, si tu fais des gros programmes bien complexes, si tu fais des trucs pro, les variables globales c'est mal.

Mais pour nos petites bidouilles, pour des petits programmes avec seulement quelques fonctions, ça passe très bien.

Et je vais même au delà: pour programmer des petits microcontrôleurs, c'est même préconisé, car ça accélère l'exécution dans certains cas.

Bref, ça n'est pas parce que des profs disent que c'est mal, que ça l'est forcément.

 

Leon.




#88464 logiciel modélisation robot anykode

Posté par Leon sur 08 octobre 2017 - 07:54 dans Logiciels

Salut Telson,

Il y a 2 solutions pour simplifier les appels à des fonctions qui utilisent de nombreux pointeurs vers actionneurs.

 

1) Déclarer tous les pointeurs vers actionneurs comme variables globales, donc globales/communes à toutes tes fonctions. Tu peux même déclarer des variables globales utilisables dans plusieurs fichiers source, si ton code source est réparti en plusieurs fichiers. En C/C++, ça se fait avec "extern".

Dans tous les cas, si tu fais ça, il faut séparer

 - la déclaration de tes pointeurs vers actionneurs :

ModaCPP::DeviceServoMotor    *s_genou_D;

Cette déclaration sera en dehors de toute fonction, dans le fichier header .h si tu en as un.

 - l'initialisation de ton pointeur

s_genou_D=pPHX->QueryDeviceServoMotor("phx0/Genou_D/a1/s_genou_D");

Cette initialisation sera par exemple dans le main().

 

2) Faire une structure dans ton code (struct) qui regroupe tous tes pointeurs vers les actionneurs. Structure déclarée une seule fois, dans le main() par exemple. Et pour passer cette structure comme argument à des fonctions, il faut alors utiliser un pointeur vers cette structure. C'est là qu'on utilise le fameux symbole "->" en C/C++ : pour désigner un membre (tes pointeurs d'actionneurs) d'une structure dont on connait le pointeur. pointeur_structure->membre_1

Les pointeurs vers structure, c'est ultra courant et ultra pratique en C/C++.

Voir ce cours très bien fait:

https://openclassroo...es-de-variables

 

Perso, pour BOB5, j'ai utilisé la première solution, que les codeur "haut niveau" qualifieront de crade, mais qui fonctionne très bien pour nos petits programmes, sans se prendre la tête.

Quand tu as un petit nombre connu à l'avance d'objets, ça se fait très bien avec des variables globales, pas besoin de s'embêter avec les allocations dynamiques et autres.

La 2ieme solution est jugée plus propre par les codeurs "haut niveau", et c'est bien de s'habituer à coder proprement.

 

Leon.




#88462 Projet de bipède - marche dynamique

Posté par Leon sur 08 octobre 2017 - 06:19 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Salut Telson,

Juste une précision : je ne prétends surtout pas que ma solution est universelle. C'est une vraie usine à gaz, et cette complexité n'est nécessaire que pour un bipède très élancé et dynamique (type Cassie).

En restant sur une logique séquentielle comme la tienne, tu peux très bien obtenir un début de marche dynamique, en partant d'un ZMP, et en rajoutant une sur-couche pour la gestion de l'équilibre, de la vitesse, des accélérations.

J'espère en tout cas que ces éléments pourront inspirer les nombreux créateurs de bipèdes. Il y a pas mal de clefs de compréhension des mécanismes de la marche dans ce que j'ai écrit hier.

 

Leon.




#88450 Projet de bipède - marche dynamique

Posté par Leon sur 07 octobre 2017 - 02:21 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

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.




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

Posté par Leon sur 07 octobre 2017 - 01:20 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Salut Léon,

 

Ce serait vraiment bien si tu pouvais échanger sur ce que tu avais déjà fait en simulation....Tu avais déjà fait du très beau travail sur Marilou....

Effectivement, malgré mon échec sur ce projet BOB5, je m'étais dit qu'il fallait le documenter publiquement sur le web.

Mais je n'ai jamais pris le temps!  :(

Le manque de motivation, la somme des autres projets de bidouille en cours... et puis le fait que plusieurs années après, ça n'est plus très frais dans ma mémoire.

 

J'essayerai de ressortir ça prochainement, mais sans garantie.

Mais en attendant, n'hésites pas à me poser des questions, sur le sujet lié au BOB5 simulé, pour ne pas polluer le sujet sur Walk-E.

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

 

EDIT : une première ébauche ici, en espérant que ça soit utile à l'équipe de Walk-E et aux autres passionnés de robots bipèdes.

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

 

Leon.




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

Posté par Leon sur 07 octobre 2017 - 09:37 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Une petite vidéo, je suis surpris qu'ils ne l'aient pas mise eux mêmes.

Le robot a bien été exposé à la Toulouse Robot Race.

Ils annoncent viser un robot qui marche dans 2 mois, ça n'est pas réaliste du tout.

 

Sinon, pour un pied à appui ponctuel (style échasse), c'est vraiment complexe car il faut contrer l'effet de vrillage autour d'un axe vertical.

Nous les humains gérons ça naturellement, mais pour un robot c'est complexe.

J'avais essayé ça dans mes simulations, et je m'étais rendu compte rapidement qu'un robot avec pied "linéaire" était beaucoup plus simple à gérer.

 

Du coup, vous avez commencé l'étape simulation? Les algos à base de neurones marchent bien? 

 

Leon.




#87253 Que faites-vous de vos robots ?

Posté par Leon sur 01 septembre 2017 - 05:27 dans Recyclage

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 sur 23 août 2017 - 06:09 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

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.




#86916 Vidéos Bipèdes

Posté par Leon sur 23 août 2017 - 05:45 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Pour l'autonomie des gros mecha de plusieurs centaines de kg, je vois un moyen assez simple de les rendre autonomes en énergie : un bon vieux moteur thermique. Ce moteur thermique peut entrainer un alternateur (groupe électrogène) et/ou une pompe hydraulique (groupe hydraulique) pour fournir la puissance à tout le robot.

 

A part ça, je ne vois vraiment pas l'intérêt de ce genre de réalisation, mais c'est un autre débat.

 

Leon.




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

Posté par Leon sur 22 août 2017 - 06:35 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Pour faire une marche non dynamique, donc ZMP quasi statique, il faut un robot solide avec des grands pieds, larges et longs, et un centre de gravité pas trop haut. Donc plutôt une allure de sumo.

Bref, tout le contraire de votre robot svelte avec un centre de gravité haut.

 

Donc j'y crois vraiment moyen...

Bon courage, je ne savais pas que vous visiez la Toulouse-Robot-Race. Ca me semble carrément ambitieux. Trop ambitieux, mais je pense que tu as compris que j'étais le rabat joie de service.

 

Leon.




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

Posté par Leon sur 22 août 2017 - 06:17 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Super, ça avance. Quand tu dis "on a fini le robot", j'espère que tu as bien conscience que tu as juste terminé la réalisation matérielle de la toute première version du robot. Il y aura forcément pas mal de choses à faire évoluer pour arriver à quelque chose d'utilisable.

 

Sinon, il lui manque les pieds, non?

 

Sinon, vous n'avez pas du tout touché à la partie simulation dynamique 3D? Notamment vous n'avez pas validé votre concept d'algorithme à réseau de neurone, ni le dimensionnement de votre mécanique?

 

Leon.




#86868 Projet RobEx pour passionné de robotique et de patrimoine - à l'abandon

Posté par Leon sur 20 août 2017 - 05:27 dans Bric-à-brac

Ca devient de plus en plus énigmatique ton histoire...

Mais j'attendrais que tu veuilles en dire plus. Tu nous mets l'eau à la bouche.

 

Leon.




#86866 Projet RobEx pour passionné de robotique et de patrimoine - à l'abandon

Posté par Leon sur 20 août 2017 - 12:22 dans Bric-à-brac

Ouf, on sait enfin à quoi sert cette débauche d'aluminium usiné!

 

Est-il possible de savoir de quel type de patrimoine tu parles? Tout et n'importe quoi? Des blockhaus? Des châteaux? Des usines désaffectées?

 

Le deuxième robot est un robot preneur de sons parce que ce patrimoine à aussi un côté audio important, c'est pour le moment une des deux grosses contraintes puisque je ne sais pas du tout le matériel nécessaire, la seconde contrainte : les escaliers.

Là, j'avoue que je vois pas de quoi tu parles pour la partie "prise de son". Quels types de sons veux-tu capter? On est d'accord pour dire qu'il n'y a en général aucun bruit à l'intérieur d'un bâtiment désaffecté? Ou alors est-ce que tu veux entendre le bruit de ton premier robot qui roule sur des feuilles, du verre cassé?

Et surtout pourquoi dédier un robot entier juste à cette prise de son? Le premier robot ne peut pas faire les 3 trucs en même temps? Les photos, la vidéo, la prise de son?

 

Leon.




#86683 Multitâches avec arduino

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

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.




#86054 Mon robot d'exploration - Explora 85 - à l'abandon

Posté par Leon sur 22 juillet 2017 - 07:10 dans Robots roulants, chars à chenilles et autres machines sur roues

Au fait, tu as pensé à fêter les 5 ans de ton projet?

 

J'admire ta persévérance. De mon côté, je n'ai jamais réussi à rester motivé/mobilisé sur un projet perso plus de 2 ans. Au delà, je ressent une grosse lassitude, et une envie de passer à autre chose.

 

Leon.