La très grande majorité des moteurs pas à pas ont des dimensions et des interfaces mécaniques standardisées : NEMA-XX.

 

Pour les axes des moteurs et autres engrenages, là aussi c'est "normalisé". Mais attention, il y a plusieurs "standards", et il est très facile de se faire piéger : système américain et système métrique.

Perso, j'essaye de rester sur le système métrique.

 

Sinon, pour tout ce qui se monte sur un axe (engrenage, roue), tu peux normalement élargir l'axe en utilisant les bons outils. Bons outils, pour moi, c'est un tour. Avec juste une perceuse, même perceuse à colonne, il est difficile de faire un trou parfaitement concentrique.

 

Leon.

Impossible de voir les images en grand chez moi. Imagehack plante...

C'est possible de nous décrire ce que tu as fait?

Leon.

Cool, encore un utilisateur de la FoxBoard!

Ton robot ressemble pas mal à celui de Yoann. Tu t'en es inspiré?
http://www.yoannsculo.fr/genesis/

Sinon, tu as prévu lui faire faire des trucs plus autonomes?

Leon.

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.

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.

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.

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.

Ne crois tu pas que si nous étions plus attentif a nos montages ils ressembleraient plus (sans le égaler bien sur) à des robots industriels. Enfin qu'il pourraient se situer à mi-chemin entre le jouet et la bête de concoures ?

Tu as tout à fait raison, et c'est normal.

Les concours de robotique (amateur ou non) sont le meilleur exemple de ce qu'on peut faire avec du bon matériel. Des robots capables de se déplacer de manière rapide et précise, ça nécessite autre chose que des moteurs de jouets!

En robotique amateur "intelligente", les capteurs sont sans doute la partie la plus importante si on veut faire un robot qui comprend son environnement. Des capteurs facilement bruités (ces fameux GP2Dxx) c'est chiant à exploiter, et ça rend la programmation plus complexe que des capteurs robustes.

Il faut juste savoir ce que l'on veut faire! Personnellement, quand je vois un gamin jouer avec un jouet radiocommandé (hélico, mini voiture, bateau), je me dit que ça serait top de pouvoir robotiser ça! Et je n'attend pas quelque chose de performant de cette "robotisation". Un robot peu performant, lent, mais bien asservi, et qui sait ce qu'il fait, c'est ça mon objectif! Tes objectifs sont peut-être différents. C'est bien dans cette philosophie que j'ai fait mes 2 robots:

Mon drone est basé sur une base d'hélico chinois bon marché (80€ prêt à voler), et ça me convient très bien. Il n'ira jamais à des vitesses super-soniques, ne fera jamais d'accrobaties aériennes. Il est capable de se déplacer tout seul, et c'est déjà une grande satisfaction!

Avec BOB3, j'ai une mécanique ultra basique, peu chère, peu performante. Les odomètres sont basiques, peu de tops. Pourtant, la reconstruction 2D de la position du robot fonctionne à merveille! Je peux faire plus de 20m sans problème en gardant une très bonne précision. Et c'est ça le plus important pour ce robot: savoir se repérer. Il ne vas pas vite, l'asservissement est basique (pas de PID).

Bref, pour résumer, il faut adapter ses solutions techiques à ses besoins. Pas besoin de dépenser des fortunes là où n'attend rien de son robot.

En résumé, vous me confirmez tous les deux que moi aussi je peux concerver mes moteurs (alimentés en 12V)

Oui, bien sur que tu peux les garder! Comme dit Luj, tu vas mettre un certain temps avant de les exploiter à fond. Et comme ils ont déjà les codeurs intégrés, c'est parfait! Regardes les vidéos de BOB3, qui ressemble fortement au tiens, avec pourtant des moteurs de moins bonne qualité!


Leon.

Je ne pense pas qu'il faille des moteurs performants pour faire un bon robot.

Sur mon BOB3, j'utilise un double bloc moteur Tamiya, avec réducteur. Un truc de jouet.
Ca coute entre 10 et 15€ l'ensemble! Chaque moteur, sans réducteur, doit couter quelque euros!
http://www.selectronic.fr/article.asp?article_ref_entier=11.8530-1

Les codeur optiques, sur BOB3, c'est de la récup avec des bouts de souris à boule, donc ça ne m'a rien couté! J'ai récupéré ça dans un stock de matériel informatique qui partait à la poubelle. Par contre, attention, ça nécessite de bidouiller pas mal: à la fois pour le montage du truc et pour l'électronique aussi! Pas forcément simple...

Pour le contrôleur moteur, ta carte "Arduino motor shield 2A" est très bien, inutile d'en changer.

En regardant la vidéo des déplacements que tu as posté, je ne vois vraiment pas de problème avec la motorisation de WIP.

Leon.

Mais alors, dans quel cas ces moteurs sont ils utilisés. Car quand je parle de moteurs à 100€, c'est mour certain modèles une entrée de gamme car nous en trouvons à 300, 350, et meme 400€.

Les moteurs "industriels" chers et ultra performants ont des qualités (en comparaison des autres moteurs) dont on se moque bien si on veut faire un simple robot qui déambule dans un appartement à vitesse raisonnable.
Durée de vie : ils ont une durée de vie très importante. Les mouvements incessants des robots industriels qui tournent en 2-8 ou 3-8, ça nécecssite des moteurs très robustes!
Rendement: le rendement de ces moteurs est ultra-optimisé. Très peu de frottements, résistance ohmique optimisée. Du coup, ils s'échauffent beaucoup moins (durabilité), consomment moins, ce qui est important sur des installations industrielles constituées de milliers de moteurs tourant très fréquement. De plus, ces frottements limités simplifient énormément l'asservissement, si on veut des asservissements ultra performants.
Absence de jeu: les réducteurs des moteurs amateur ont souvent du jeu mécanique. C'est parfois gênant pour l'asservissement. Les moto-réducteurs industriels, eux, sont là aussi archi optimisés, et peuvent bloquer très précisément une position donnée, sans jeu. Une méthode pour limiter le jeu dans un motoréducteur bon marché consiste à le gaver de graisse (graisse rose sur des pignons métaliques, et blanche sur du plastique).

Est tu certain que la précision des odomètres sera assurée de de la meme façon entre ces 2 moteurs?

L'odomètre, c'est à part du moteur. Tu peux mettre de très bon odomètres sur de très mauvais moteurs, et réciproquement. Encore une fois, les odomètre industriels de plusieurs centaines de tops par tour, monté sur le moteur électrique (en entrée du motoréducteur), donc donnant parfois des dizaines de milliers de tops par seconde (si, si), ça sert à une seule chose: faire des asservissements ultra-performants! Et les asservissements en robotique industrielle sont très impressionnants: ultra rapides et ultra précis. Capable de suivre une trajectoire à grande vitesse très précisément. Pour ce faire, on utilise des PID qui tournent à plusieurs centaines de fois par seconde. Dans ces conditions, pour renseigner la composante "dérivée", c'est à dire la vitesse du moteur, il faut pouvoir compter suffisament de tops entre 2 pas de calcul.
En amateur, si tu n'as pas besoin de performances monstrueuses, juste de te déplacer, tu peux faire un asservissements (PID ou autre) rafraichi plusieurs dizaines de fois par seconde. Et sur BOB3, je n'utilise même pas de composante dérivée, ce qui réduit encore le besoin de résolution. Sur BOB3, j'ai 40 tops par tour de roue, ce qui est peu. En gros, j'utilise un asservissement polaire en "PI" sans D: j'asservit l'orientation et l'avancement du robot séparément.

Pour finir, un codeur est un codeur. Son objectif est de ne perdre AUCUN top. C'est le cas pour mes odomètres à 2 balles, comme pour les odomètre pro. Les différences entre les 2: la durabilité, la résolution (40 tops chez moi, des centaines chez les pros) et surtout la fréquence maxi.

Clairement, nos robots ressemblent plus à des jouets de supermarché qu'à des robots industriels. Si un humain arrive à piloter un jouet radiocommandé, alors l'électronique du robot y arrivera très bien aussi!

Leon.

Pour la reconstruction 3D, je ne compte pas utiliser de librairie ou de soft déjà existant...
[...]
Mais, le but est de tout faire "a la main" (sinon c'est pas drôle ).

C'est la philosophie que j'applique également dans mes projets (voir ma signature).

Donc, grosso modo, l'idée est de se baser sur l'omographie entre deux images.

Omographie? Qu'est-ce que c'est? Mon dico ne connait pas, wikipedia non plus.
http://fr.wiktionary.org/wiki/homographie

A partir de là, faire une estimation de la profondeur devrait ne pas être trop compliqué et donc d'ensuite d'en extraire les volumes (on le fait dans les moteurs 3d, grâce à l'inversement de la perspective).

Pareil pour le terme "inversement de la perspective". Ca veut dire quoi?

Je connais l'angle entre les deux images, grace aux servos de la tourelle et/ou au capteur d'angles et/ou au gyroscope du portable, et je devrais avoir une estimation de la distance grâce a un capteur de distance.

Quel type de capteur d'angle, et qui mesure quoi?

Sinon, encore une fois, pourquoi ne pas utiliser d'odométrie pour savoir de combien ton robot s'est déplacé?

En tout cas, c'est un chouète projet. Tiens nous au courant.

Leon.

Sa camera servira à la reconnaissance et l'analyse du territoire (soft en cours de développement, basé sur la détection de lignes et de reconstruction 3d en temps-réel si c'est possible),

Tu peux nous en dire un peu plus, stp? Car ça doit intéresser beaucoup d'entre nous. Cartographier un environnement 3D avec une unique caméra, c'est quelque chose d'ambitieux.

Quels types d'algos comptes-tu utiliser? Tu as déjà défini ça? Est-ce que tu vas reprendre du code existant? Si oui, lequel? Ou alors tout coder toi même? Et dans ce cas, quel algo, quelle théorie utilises-tu derrière?

Autre question: tu n'as pas d'autre capteur dans ton robot? Pas d'odométrie, de gyro? Comment comptes-tu déterminer le placement de ton robot par rapport à son environnement? Par la caméra uniquement?

Enfin, comment comptes-tu utililiser le sonar attaché à la caméra? Les sonars ont un cone de détection assez large en général (30°), donc ça n'est pas facile.

Leon.

Physinain, tu as essayé d'activer et d'utiliser Telnet comme je te l'ais proposé, plutôt que du SSH? On t'a aussi proposé de communiquer avec ta Roboard par un port série RS232. Tu comptes tester ça prochainement?

Et puis tu dis avoir un ami qui s'y connait, et qui t'as conseillé cette carte à plus de 250€. Pourquoi ne pas lui demander de t'aider à avancer, au moins pour te débloquer?

L'avantage de la Roboard, c'est que tu pourras l'utiliser en tant que PC pour embarquer des applications sur le fauteuil. Avec un petit écran à pas cher. Donc à ne pas jetter tout de suite à mon avis.

Leon.

Dis, c'est quoi un "controleur d'environnement pour fauteuil roulant"?
D'habitude, le terme "controleur d'environnement", ça porte sur des trucs qui mesurent/contrôlent température/humidité... Donc là, je ne vois pas trop le rapport avec un fauteuil roulant.

Leon.

Pour le terme de "controleur d'environnement", ça aurait été bien d'expliquer sa signification dès le début, non?

Si tu n'y arrives pas à te connecter en SSH, pourquoi ne pas essayer en telnet. Normalement, c'est le truc le plus facile à faire fonctionner, non?

Leon.

Bravo pour ces résultats. Jbot et Maximus sont donc qualifié les 8iemes de finale!

Leon.

Beau travail!
Le robot fonctionne bien apparemment.
Il est sans doute promis à un bel avenir!

Bon courage pour la suite, et bonne chance pour la coupe!

Leon.

Si, c'est censé se faire en équipe mais bon, vu que j'ai envie de faire toutes les parties du robot je préfère le faire seul c'est plus intéressant au moins je connais tout le robot. Le problème en équipe c'est que tu vas te concentrer que sur certaines parties.

Tiens, je me reconnais bien là... C'est vrai que c'est idéal de tout faire, si on a le temps. Et puis, travailler à plusieurs, c'est très difficile. Je n'ai jamais réussi à travailler sérieusement à plusieurs dans mes projet amateurs.

Sinon, saches que l'automatique (boucles de régulations etc) est très important en robotique !

Je dirais même indispensable. L'automatique, les asservissement, les lois de commande, les observateurs, on en retrouve partout en robotique!

Leon.

J'arrive avec BEAUCOUP de retard sur le sujet, désolé, mais je ne fréquente plus trop les forums robotique en ce moment.

Je ne suis pas trop d'accord avec les affirmations de Skyhack.

Utiliser une souris à boule telle quelle, ça ne peut pas fonctionner. 2 souris à boule, c'est mieux, mais ce qui est encore mieux, c'est d'utiliser l'électronique et/ou la mécanique d'une souris à boule pour en faire des codeurs que tu peux monter sur tes roues de propulsions (ou sur des roues dédiées à l'odométrie).

Oui, les roues codeuses des souris à boule sont de TRES BONS CAPTEURS!
Voici en vrac les trucs qu'il faut savoir:
- Pour des codeurs, c'est facile à utiliser, et assez robuste, peu sensible au désalignement, contrairement à des codeurs plus précis.
- Ca n'est pas super performant : ça a une fréquence limite au delà de laquelle tu ne peux pas aller. Je ne pense pas, par exemple, que l'on puisse mettre la roue codeuse d'une souris à boule sur le moteur de propulsion en amont du réducteur. Mais monté côté roue, ça fonctionne très bien!
- une souris est bien censée renvoyer les déplacements x-y entre 2 lectures. Attention, il faut lire assez fréquemment, car sinon, le petit compteur de la souris arrive assez vite à saturation et alors tu perds des données.
- dans la logique de la souris, il y a un réglage à faire : dans la souris, et dans l'OS, il y a un facteur multiplicatif qui fait que la souris peut renvoyer des déplacements plus grands que la normale si elle va à vitesse élevée. C'est pour l'ergonomie, mais ça nous fait chier pour nos capteurs. Il faut désactiver cette fonction, à toi de trouver la doc nécessaire, sur les instructions qu'il faut renvoyer à la souris.
- la précision est bonne, voire très bonne. En fait, comme tout codeur, une roue de souris à boule ne perd aucun front si elle est utilisée dans la bonne plage de fonctionnement (bien réglée, utilisée à vitesse raisonnable).
- Contrairement à ce que dit Skyhack, une souris à boulle sait très bien dans quel sens ça tourne, et ne perd aucun front pour déterminer le sens d'avancement (contrairement à d'autre types de capteur rotatif). C'est en fait vrai pour n'importe quel codeur qui fonctionne avec des signaux en quadrature.

J'ai utilisé cette solution dans 2 robots différents:
- Sur BOB2 (pas de site complet), j'utilisais toute l'électronique de la souris, donc ça ressemble beaucoup à ce que tu veux faire, swolf. Voir le chapitre "elec" du site.
- sur BOB3, je n'ai utilisé que les fourches optiques et les roues codeuse, et toute l'électronique est faite "maison" avec un HCTL2032 pour exploiter les codeurs. Voir le chapitre capteurs du site.

Et si tu as des questions, n'hésites pas à me faire signe. Je ne garantis pas le délai de réponse cependant.

Leon.

Pour le bob2, celui où tu utilises toute l'électronique de la souris, t'as utilisé quoi comme type de code? tu as aussi compté les impulsions données par le CI? parce que je me dis que'en fait, ça ne sert à rie de le garder si il ne fait que compter les impulsions et déterminer le sens de rotation... Peut-être qu'il vaut mieux uniquement garder les codeurs...

En fait, BOB2 était réalisé (il n'existe plus) à partir des restes d'un vieux PC portable (486). Donc la souris était directement branchée sur le port PS/2, avec le driver souris intégré à l'OS (MS DOS). Donc ça n'a rien à voir avec l'arduino que tu utilises.

Sinon, oui, je te confirme que l'électronique de la souris ne fait "que" compter les impulsions, en prenant en compte le sens de rotation. J'avoue que je ne sais pas s'il est facile de faire la même chose avec un Arduino (compter des tops en prenant en compte le sens). A toi de fouiller sur le web. Sur BOB3, j'ai carrément un composant dédié pour faire ça: le HCTL2032.

Leon.

Il est peut-être plus facile de trouver des souris à boulle que ce genre de composants. Pour BOB3, j'avais acheté un lot de 5 souris à boules "microsoft" pour 5€ l'unité, si mes souvenirs sont bons. C'était il y a 5 ans. Aujourd'hui, je ne sais pas si on en trouve encore.

Leon.

Salut Levend,

Pour info, j'utilise DraftSight, c'est gratuit.

C'est gratuit gratuit? Parce que sur le lien que tu nous as donné, ils semblent dire que c'est gratuit 30 jours pour essai, pas plus. Donc si c'est ça, c'est loin d'être gratuit.

 

Leon.

Bon, ça devrait en théorie être un défi pour moi.

J'ai justement déjà commencé à assembler un robot scribe, à base de servomoteurs bidouillés (sans électronique) et de pièces Lynxmotion.
http://www.robot-maker.com/forum/topic/6622-robot-scribe/

Malheureusement, je me disperse beaucoup en ce moment, et ce projet est complètement à l'arrêt. J'ai d'autres idées en tête...

Leon.

Salut!

Comme je viens de finir mon robot scribe, j'ai repensé à ton défi!

Voici donc une vidéo qui montre le résultat.


Rappel : la description du robot scribe est ici:
http://www.robot-maker.com/forum/topic/8690-robot-scribe-version-2/

Leon.

Je n'ai pas compris: c'est quoi la liaison radio qu'il y aura entre l'arduino et le PC? Bluetooth? WiFi? As-tu testé le débit, pour voir s'il est faisable de transférer des images en temps réel? Parce que si tu as 1 image toutes les 5 secondes, ça ne va pas le faire.

L'arduino n'est clairement pas conçue pour manipuler de grandes quantités de données, ni pour faire des transferts rapide de données.

Mais bon, à vous d'estimer tout ça, et de tester, même sans caméra: tester un transfert de données vers le PC pour voir quel débit maxi peut être atteint. J'avoue que j'ai un peu peur du résultat.

Leon.