EUROBOT 2016 - Les Karibous

[Nadar]

Salut à tous !

Je me lance aussi pour cette année. Alors comme depuis 3 ans déjà, nos robots seront réalisés en maximum à l'imprimante 3D ( challenge personnel ). Petite nouveauté cette année par contre, nous allons essayé de présenter deux PR. Pourquoi deux PR ? Afin de ne développer qu'une seule structure de robot et de pouvoir la dupliquer par la suite si les tests sont positifs.

Pour le moment, le robot ressemble à ça en 3D :

*old link*

Parmi les petites nouveautés de cette année :

Coté mécanique :

• On reste sur des moteurs pas à pas avec réducteur épicycloidal, mais on intègre la roue autour du réducteur pour gagner de la place ( voir documentation associée )
• On test la fabrication de nos pneus en PU ( voir documentation associée )
• On va tester ( si j'ai le temps ) le polissage mécanique des pièces imprimées en 3D en utilisant un tambour à polir.

Coté détection :

• On utilise un tourelle rotative comme l'année dernière sauf que cette année, la rotation sera complete et se fera par un moteur monté sur un potentiomètre sans limite. ( voir documentation associée )

Coté électronique :

• On reste sur le pilotage des moteurs par des DRV8834 mais on simplifie l'interfacage
• On utilise des teensy 2.0 relié en I2C à la place des arduino micro de l'année dernière. Du coup, nouvelle carte électronique à développer.

Voila les amis !

 

[TDS-Team]

2 petit robot c est pas con cet année, c ete notre premier choix stratégique ...

Quel est la référence de moteurs pas a pas que tu utilise ?

 

[TDS-Team]

Autant pour moi j ai vu la ref apres, par contre l axe a l arriere, doit plus t embeter qu autre chose

 

[louloute30]

Salut Adrien,

Je vais apporter quelques précisions pour tes PAP qui pourraient, me semble-t-il te servir. Ayant pratiqué les PAP depuis quelques années, je vais te donner quelques unes des remarques que j'ai pu en tiré:
Un couple de 2Nm par moteur est tout à fait parfait pour un GR (donc un PR aussi), en deça, c'est limite, et au delà, ça me semble inutile, autant rajouter du poids sur le robot ou augmenter l'adhérence des roues pour accroître la poussée.

A mon avis, la démultiplication de tes nema 17 me semblent bien: C'est évident, tu perdra un peu en vitesse, mais ça ne te limitera pas en poids sur le robot.
Mon PR blanc était équipé de 2 nema 17 sans réducteur, les axes directement collés aux roues. La vitesse max atteinte en 1/4 de pas était de 0.3 - 0.4m/s (900µs entre chaque impulsion), au delà, les moteurs lâchent. Je pense que dans ton cas, il faudra régler ton driver en 1/2 pas voir en pas entier.
Je rajouterai que ce qui a permis des "vitesses pareilles" tout en gardant une puissance correcte, ce sont la qualité des drivers, à ne pas négliger ! Suivant leur qualité, tu peux vite passer d'une puissance motrice du simple au double. Je te conseillerai les M335, mais vu la place dans un PR, les TB6600 peuvent faire l'affaire (te les conseille pour les avoir testé moi-même). Dans tous les cas éviter toutes les cartes bleues CNC triples axes qui offrent un gain de place au détriment de la qualité de traitement de l'info et de la puissance obtenue dans les moteurs.

Dans tous les cas, PR ou GR avec des moteurs PAP sans codeurs incrémentaux ne te permettront pas (jamais !!!) d'envisager des stratégies après 3 mètres parcourus, sauf à se recaler sur chaque bordure en X et Y ce qui en pratique est très rarement faisable, et le tout, en espérant qu'aucune coquille (de coquillage) l'en empêche.
Les codeurs m'ont sauvés bien des fois, et c'est même devenu plaisant de rajouter des "tâches à faire" en fonction de l'emplacement désormais connu du robot.

Si j'aurai un seul conseil à te donner, c'est de privilégier les codeurs plutôt que des réducteurs, et minimiser le poids du robot de manière à créer un robot capable de se sauver de toute situation d'embouteillage... Mais si tu peux mettre codeurs + PAP + réducteurs alors, tu devrais avoir le PR étant le mieux conçu avec une telle motorisation. Sinon, je rajouterai que dans tous les cas, un robot avec PAP, si ta batterie n'est pas très bien chargée, autant ne pas le mettre sur le terrain (l'ayant vécu)...

Enfin, dans ton prog si tu as des codeurs, ne pas créer une boucle du genre:
for (nbPas=0;nbPas<Distance_A_Parcourir_En_Impl;nbpas++){
ImplRGauche();
ImplRDroite();
delaymicros (XXX);
}
qui obligerait tant à la roue gauche qu'à la roue droite d'attendre autant de temps entre les impl.

Il faut laisser au µcontrolleur la possibilité d'indépendance du temps entre les impulsions des deux moteurs de telle manière à faire varier le temps (et donc le nombre d'impulsion) entre chaque impulsion lancée sur le moteur de la roue droite indépendamment du temps entre chaque impl lancée sur la roue gauche.
Ainsi tu rattrapes sur toute la distance restant à parcourir le ou les "pas" manquant ou qui a fait défaut entre la roue G et droite.
Aussi, grâce à un moteur de gestion d'impl pareil, ça te permettra de faire faire à ton robot des rayons de courbures de ton choix. C'est la dernière modif que j'ai réalisé, et je m'en régale depuis.

Il y a 2 ans, je n'avais pas eu le tps de coder ça, c'est pour ça que le PR faisait "une dance", en rattrapant le pas manquant ou perdu sur la roue gauche en stoppant les impl lancées sur la roue droite. Au final, il circulait en canard.

En espérant avoir été assez clair

A bientôt, et au plaisir de les voir circuler.

PS: Si tu veux tester tes robots, j'aurai une table à Ham, j'y serai tous les vendredis.
PS2: Est-ce possible que tu m'imprimes les cônes, en contre parti, je pourrai te les régler (prix que tu fixeras) ou te donner des capteurs indus par ex.

 

[Nadar]

Autant pour moi j ai vu la ref apres, par contre l axe a l arriere, doit plus t embeter qu autre chose

Hello ! Effectivement ^^ C'est pourquoi je les ai tous simplement coupé ^^

 

[Nadar]

Oula : groooosssssee réponse de louloute !

Alors c'est partit !

Un couple de 2Nm par moteur est tout à fait parfait pour un GR (donc un PR aussi), en deça, c'est limite, et au delà, ça me semble inutile, autant rajouter du poids sur le robot ou augmenter l'adhérence des roues pour accroître la poussée.
(...)les axes directement collés aux roues. La vitesse max atteinte en 1/4 de pas était de 0.3 - 0.4m/s (900µs entre chaque impulsion), au delà, les moteurs lâchent. Je pense que dans ton cas, il faudra régler ton driver en 1/2 pas voir en pas entier.

En fait , j'ai utilisé et expérimenté cette technique l'année dernière et j'en suis plutôt bien content ( tant en terme de vitesse que de répétabilité ). En effet, je pilote en Pas entier dans mon cas afin de gagner en vitesse. Faudrait que je fasses des calcul et des tests mais avec mes nouvelles roues, j'ai x1,3 ma vitesse max par rapport à l'année dernière en théorie.

Dans tous les cas, PR ou GR avec des moteurs PAP sans codeurs incrémentaux ne te permettront pas (jamais !!!) d'envisager des stratégies après 3 mètres parcourus, sauf à se recaler sur chaque bordure en X et Y ce qui en pratique est très rarement faisable, et le tout, en espérant qu'aucune coquille (de coquillage) l'en empêche.
Les codeurs m'ont sauvés bien des fois, et c'est même devenu plaisant de rajouter des "tâches à faire" en fonction de l'emplacement désormais connu du robot.

On a des switch de recalage bordure (on les utilisait régulièrement en match l'année dernière et ça a donné de super résultats ) et on aura un gyroscope 1 axe pour la déviation ( essayé l'année d'avant avec beaucoup de succès mais pas eu le temps de l'implémenter l'année dernière ). Du coup, comme l'année dernier tout s'est bien passé, je me passe de codeurs ( questions de temps de dev ) mais j'ai un montage sous le coude pour les intégrer si jamais je vois que dans les semaines qui arrivent je suis charrette ...

Si j'aurai un seul conseil à te donner, c'est de privilégier les codeurs plutôt que des réducteurs, et minimiser le poids du robot de manière à créer un robot capable de se sauver de toute situation d'embouteillage... Mais si tu peux mettre codeurs + PAP + réducteurs alors, tu devrais avoir le PR étant le mieux conçu avec une telle motorisation. Sinon, je rajouterai que dans tous les cas, un robot avec PAP, si ta batterie n'est pas très bien chargée, autant ne pas le mettre sur le terrain (l'ayant vécu)...

Coté charge de batterie tu as eu des problèmes ? De notre coté, on tourne en NiMh 9,6V et notre robot sans actionneur consomme 0,5A ... Pas eu de soucis l'année dernière et j'avais mis une alerte visuel et sonore sur le robot quand la batterie était déchargé à 60% pour éviter tous problèmes ...

Enfin, dans ton prog si tu as des codeurs, ne pas créer une boucle du genre:
for (nbPas=0;nbPas<Distance_A_Parcourir_En_Impl;nbpas++){
ImplRGauche();
(...)à parcourir le ou les "pas" manquant ou qui a fait défaut entre la roue G et droite.
Aussi, grâce à un moteur de gestion d'impl pareil, ça te permettra de faire faire à ton robot des rayons de courbures de ton choix. C'est la dernière modif que j'ai réalisé, et je m'en régale depuis.

Alors c'était pas clair dans le post, mais on a un uC qui ne s'occupe que du déplacement du robot, ce qui nous permet une plus grande flexibilité dans la commande de celui-ci. J'avoue aussi que j'ai pas tout compris de ce que tu as essayé de m'expliquer Coté prog, j'étais partit pour coder moi même ma librairie puis on a testé la lib AccelStepper et MultiStepper, et j'ai été bluffé par le résultat ! Depuis j'utilise cette lib que j'ai un peu modifié/allégé.

Il y a 2 ans, je n'avais pas eu le tps de coder ça, c'est pour ça que le PR faisait "une dance", en rattrapant le pas manquant ou perdu sur la roue gauche en stoppant les impl lancées sur la roue droite. Au final, il circulait en canard.
En espérant avoir été assez clair
A bientôt, et au plaisir de les voir circuler.

Merci ! Au plaisir de vous revoir aussi !

PS: Si tu veux tester tes robots, j'aurai une table à Ham, j'y serai tous les vendredis.
PS2: Est-ce possible que tu m'imprimes les cônes, en contre parti, je pourrai te les régler (prix que tu fixeras) ou te donner des capteurs indus par ex.

Ha bas petit changement , cette année au FabLab on a pu se fabriquer une table complete pour nos tests Mais merci pour la proposition Faudra se faire un match ensemble par contre ^^
Coté des cônes, bien sur je peux en imprimer On peut en parler en MP si tu veux.

 

[louloute30]

Coucou,

Pour nous, c'était batterie de 12V 2Ah au plomb.

En fait, la boucle que j'ai tenté d'expliqué n'est utile que si tu as des codeurs, donc vu que tu fais des recalages bordures...
Content de voir que tu as une table aussi. C'est plus qu'utile pour la coupe !

Je t'envoie un petit MP pour la suite
A plus !

 

[syoctax]

On reste sur des moteurs pas à pas avec réducteur épicycloidal, mais on intègre la roue autour du réducteur pour gagner de la place ( voir documentation associée )

Mettre des roulements autour du réducteur Pas con!

J'ai bien le format et le contenu de vos documentations aussi.

 

[lapoutre]

Mettre des roulements autour du réducteur Pas con!

J'ai bien le format et le contenu de vos documentations aussi.

Super les documentations!

Pour les roulements autour des reducteurs c'est un bonne idée sur le papier et j'ai bien envie de voir en pratique comment ca passe.

Vincent

 

[Nadar]

Pour nous, c'était batterie de 12V 2Ah au plomb.

Ha ha ha ! Oui c'est vrai ! Comment oublier

En fait, la boucle que j'ai tenté d'expliqué n'est utile que si tu as des codeurs, donc vu que tu fais des recalages bordures...

Ok en relisant c'est plus clair

Content de voir que tu as une table aussi. C'est plus qu'utile pour la coupe !

Ca nous tellement manqué l'année dernière que l'on refait plus la même erreure

Je t'envoie un petit MP pour la suite

Vu ! Je te répond demain !

J'ai bien le format et le contenu de vos documentations aussi.

Super les documentations!

Merci !

Mettre des roulements autour du réducteur Pas con!

Pour les roulements autour des reducteurs c'est un bonne idée sur le papier et j'ai bien envie de voir en pratique comment ca passe.

Alors sur le papier c'est effectivement une bonne idée et en pratique ... Ben ça fonctionne très bien aussi pour le moment ! Je viens de finir le moulage de mon second pneu et je suis en train d'imprimer mon support supérieur pour mes cartes. Du coup demain je ferais des petits tests de déplacement. (vidéo et posts pour vous montrer) Aujourd'hui ça ressemble à ça :

Le pneu droit c'est celui avec nouveau mélange qui a super bien fonctionné. Le gauche par contre c'est mon premier essai et il a un peu morflé

A + !

 

[Nadar]

Hello !

Bon, c'est la galère pour avancer sur mes projets en ce début d'année ! Pas moyen de trouver du temps ... Je vous ai quand même fait des petites photos du robot :

*old link*

Les cartes électroniques sont fonctionnelles pour le moment. J'ai pas encore testé les servomoteurs et la communication Esclave --> Maitre ( la communication Maitre --> Esclave fonctionne par contre ). J'ai pu implémenter mon code de l'année dernière et le robot navigue correctement pour le moment. Je suis en train de faire du ménage dans mon code et de synthétiser mes fonctions.

Ca m'a d'ailleurs fait marrer de reprendre le code que j'ai écrit à la coupe ( et que je n'ai pas ressortit depuis ). Je me suis donc rendu compte que à 5h du matin, le code écrit dans les stands est loin d'être optimisé et que j'ai fait toute la coupe en utilisant le sous-programme de stratégie "homologation" .

Un petite frayeur sur les cartes : mon logiciel a routé une piste en trop je sais pas pourquoi ... J'ai eu peur que ce soit foutu, mais ça s'est arrangé plutôt bien finalement. J'ai juste plus l'utilité de ma diode en entrée d'alimentation. Je corrige ça dans la version suivante et je fais une documentation

J'ai aussi testé les Teensy 2.0 cette année en remplacement des arduino micro et ... Que c'est magique ! Le programme démarre direct ( alors que coté arduino, faut attendre de 10 à 15 sec parfois pour le boot ), c'est rapide à charger, les bibliothèques sont bien écrites, la taille est juste parfaite, et on a plus d'E/S pour les même microcontroleur ( un Atmel 32u4 dans les deux cas ). Vraiment super content de mon choix pour le moment ! Et c'est moins onéreux !

Du coup cette année je programme encore avec l'IDE Arduino pour gagner du temps et reprendre mes anciens programmes. Mais l'année prochaine , je pense passer sur du C direct.

Petit tips par contre : j'avais commandé des teensy officiels et des copies chinoises pour voir la différence. J'ai testé les deux et les copies sont vraiment de la m&@# ! Impossible de charger un programme, Watchdog qui se déclenche pour un oui ou un non, le bootloader qui a pas l'air d'être le même, j'ai même réussi à en faire "fumer" un sous 5V, c'est vous dire ...

Moralité : si vous voulez tester ce super contrôleur, allez directement l'acheter chez les revendeurs agréés !

A + les amis !