320 réponses à ce sujet

[Mike118]

Je change de sujet pour poser une petite question :
Quel sera le diamètre des roues ?
C'est pour définir le diamètre des roues codeuses.

Selon mes réflexions personnelles sur ce sujet :
- Les roues codeuses devraient être fixées sur l'arbre de la roue car c'est l'axe le plus lent sur le rapport de réduction (jeu d'engrenages)
- La roue codeuse doit avoir le diamètre le plus grand possible car plus sa circonférence est grande, plus la résolution des marquages sera efficace.
contrainte :
Les roues devront être le moins large possible afin de réduire les effets de patinage lors des virages qui seraient néfastes sur les mesures d'odométrie.

Mes hésitations :
je me demande si il est préférable d'utiliser une roue codeuse "normale" (opaque et transparent) avec une fourche en U :
http://www.hobbyelectro.fr/shop/optoelectronique/446-capteur-infrarouge-reflectif-rpr220.html
ou si, en collant une rondelle de papier alu sur le transparent (réflectif ou non-réflectif), il ne serait pas plus simple d'utiliser ce genre de composant :
http://www.hobbyelectro.fr/shop/optoelectronique/163-capteur-infrarouge-reflectif-rpr220.html

Pour ce qui est du codage imprimé sur la roue, je pense que le mieux (plus simple à mettre en place et moins de composants nécessaires) serait d'utiliser un codage séquentiel sur deux largeurs :
blanc-étroit / noir-étroit / blanc-large / noir-large.
Ceci permet de déduire avec un seul capteur le sens et la vitesse de rotation.

Hum... Le diamètre des roues ... Cela dépend de la vitesse qu'on veut pour le robot et du moteur choisis ...
Ensuite pour être le plus précis possible il faut soit mettre le disque au niveau de l'arbre moteur : il fait plus de tour pour un plus petit déplacement donc on peu entre autre se permettre de mettre un disque avec moins d'alternance, soit les mettre sur des roues folles de faible diamètre ( permet de prendre en compte un éventuel glissement ) le mieux étant de mettre ces roues folles suivant le même axe que les roues directrices.

Pour le reste je suis d'accord.

Ensuite qu'est ce qui est le mieux entre les Vide/opaque et les noirs/ blanc je ne sais pas... Je ne sais pas non plus lequel sera le moins cher ... à voir !

Enfin, concernant la dernière proposition je ne suis pas convaincu par l'argument " permet d'utiliser un seul capteur" ... Car si tu as deux ligne sur ta roues codeuse il te faut deux capteurs pour lire indépendamment leur état !


Moi de mon côté puisqu'il faut bien commencer quelque part je décide de commencer par la partie alimentation...

donc je vais faire un cahier des charges complet de cette partie. Tout personne voulant travailler sur cette partie ou donner des idées est bien entendu la bienvenue =).
Je vais faire une estimation du coût etc ...

Bonjour a tous.

Bon je suis en train de faire des recherches pour la cartes de puissance pour les moteurs:
j’hésite entre 2 drivers, le L293D et le L298N.

*L293D: supporte 1A
*L298N: supporte 2A

J'aimerais avoir votre avis pour essayer de faire des schémas et peut être aussi avoir vos versions.
Je ne peut pas faire les C.I. mais bon je pense qu'il y a un R-Maker qui va pouvoir nous faire cela /> .

Moi j'opte pour le L298 =)
on tape dans les 2A et on a une bonne plage d'entrée en tension.
( En plus j'utilise beaucoup ce composant et j'ai deux trois astuces qui vont avec ^^)

On peut l'avoir aussi bien en version traversant que cms. Il est d'ailleur plus pratique en version CMS ( sauf si on fait l'astuce du pliage de patte )
et il prend moins de place. De plus en version CMS on peut facilement en souder un autre par dessus pour monter à 4A et tenir 6A en pointe...


Concernant les cartes électronique je peux en faire rapidement en traversant pour des test ( mais pas en CMS j'en ai pas actuellement sous la main )

[R1D1]

(...)

Enfin, concernant la dernière proposition je ne suis pas convaincu par l'argument " permet d'utiliser un seul capteur" ... Car si tu as deux ligne sur ta roues codeuse il te faut deux capteurs pour lire indépendamment leur état !

(...)

Par deux largeurs, j'ai compris non pas qu'il y avait deux lignes mais des barres sur une ligne de largeur différente. Un motif comme :

__||||_____||||||||||

[thermo_nono]

oui, c'est bien ça.
voici un exemple, mais quand j'aurai fait mes premiers essais, j'en redessinerai une avec une meilleure résolution.
https://sites.google...ux largeurs.pdf

[Mike118]

oui, c'est bien ça.
voici un exemple, mais quand j'aurai fait mes premiers essais, j'en redessinerai une avec une meilleure résolution.
https://sites.google...ux largeurs.pdf

oulà ah oui en effet je ne l'avais pas vu comme ça !
Mais une telle disposition est problématique ... Comment savoir à quelle vitesse on tourne si les barres ne sont pas de la même taille ?
En tout cas à moins de me donner plus de détail sur l'algo de traitement qui va avec cette roue là je ne trouve pas que cela soit une très bonne idée ...

[thermo_nono]

oulà ah oui en effet je ne l'avais pas vu comme ça !
Mais une telle disposition est problématique ... Comment savoir à quelle vitesse on tourne si les barres ne sont pas de la même taille ?
En tout cas à moins de me donner plus de détail sur l'algo de traitement qui va avec cette roue là je ne trouve pas que cela soit une très bonne idée ...

en ce qui concerne l'algo, j'avais pensé à un truc dans ce genre :

Pour connaître le sens de rotation, il suffit de mémoriser la séquence, puis de l'analyser :
il y a 4 bandes remarquables
- étroite transparente (ET)
- étroite opaque (EO)
- large transparente (LT)
- large opaque (LO)
la séquence en avant correspondrait à la séquence :
ET-EO-LT-LO
alors qu'une séquence correspondant à :
LO-LT-EO-ET
indiquerait que la roue recule.

Ensuite, en ce qui concerne la vitesse, dans le cas de l'exemple que j'ai dessiné, on sait (et le µC le saura aussi) qu'une bande large représente 30° et qu'une bande étroite représente 15°. Ainsi, dés que le µC aura mesuré (et identifié) une bande étroite et une bande large, il sera en mesure d'en déduire l'angle parcouru qui est proportionnel à la distance parcourue.. si on établi le rapport entre la distance parcourue et le temps écoulé, on déduit la vitesse.

Je n'ai pas encore fait l’algorithme, et pour tout dire, je n'ai même pas encore commandé les composants pour faire les essais.

edit : c'est une méthode grandement inspirée par celle décrite dans "dropbox\Le robot de robot-makers\Electronique\Roues codeuses maison\nouvelle approche.odt"

[Leon]

Ensuite, en ce qui concerne la vitesse, dans le cas de l'exemple que j'ai dessiné, on sait (et le µC le saura aussi) qu'une bande large représente 30° et qu'une bande étroite représente 15°. Ainsi, dés que le µC aura mesuré (et identifié) une bande étroite et une bande large, il sera en mesure d'en déduire l'angle parcouru qui est proportionnel à la distance parcourue.. si on établi le rapport entre la distance parcourue et le temps écoulé, on déduit la vitesse.

Je pense que ça ne peut pas marcher ton truc. Imagine que tu es en train d'accélérer (ou de décélérer) fortement. Voir carrément si tu changes de sens. Ton chronogramme donnera des signaux longs (en temps), mais tu ne sauras pas s'ils sont long du fait de la lenteur de la roue (vitesse faible, proche de zero), ou du fait que tu es sur un dessin "grand trait" de ta roue. Notamment au changement de sens, ça ne pourra pas fonctionner, tu vas (je pense) louper des tops. Tu ne pourras pas savoir précisément à quel moment le sens de rotation s'est inversé. Et louper ne serait-ce qu'un seul top, c'est perdre l'orientation du robot (écart de déplacement droite/gauche).
La solution des codeurs en quadrature fonctionne très bien, je ne vois pas pourquoi chercher à faire autrement.

J'avais étudié les capteurs suivants lors de la conception de mon BOB3.

Capteur réflectif:
* CNY70: pas assez précis: la transition sombre - clair est beaucoup trop large (plus de 1mm).
* hamamatsu P5587 est précis et rapide, mais nécessite un placement hyper précis du capteur par rapport à la roue codeuse

Capteur transmissif:
* KRA011: pas mal du tout, mais nécessite une roue codeuse parfaitement propre.

Au final, j'ai tout simplement utilisé des capteurs de souris à boule, qui sont très robustes, peu sensibles aux perturbations/erreurs d'alignement, et fiables. Par contre, ils sont limités en fréquence maxi, mais ça ne me gêne pas.
http://ze.bot.free.fr/codeur/capteurs.html

Les capteurs sont directement sur l'axe. Donc la résolution est ~1/2mm. Cela empêche de faire des asservissements de type PID rapides. Je n'utilise que des PI sur ce robot. Un PID rapide impose (en général) de mettre un codeur avec une bien meilleur résolution, voire carrément un codeur placé en amont du réducteur (côté moteur). En effet, une résolution fine est nécessaire pour calculer fréquemment la vitesse, utilisée dans le terme dérivé du PID. Il faut voir suffisamment de "tops codeur" à chaque pas de calcul, pour calculer une vitesse, donc il faut une résolution fine.

D'ailleurs, vous pouvez copier autant que vous voulez mon BOB3. Sans capteurs ultrasons (avec des capteur moins chers), sans chargeur intégré, et avec une carte mère moins chère, il est possible que ça tienne votre budget.

Leon.

[Mike118]

Ca ne peut pas marcher ton truc. Imagine que tu es en train d'accélérer (ou de décélérer) fortement. Voir carrément si tu changes de sens. Ton chronogramme donnera des signaux longs, mais tu ne sauras pas s'ils sont long du fait de la lenteur de la roue, ou du fait que tu es sur un dessin "grand trait" de ta roue.
La solution des codeurs en quadrature fonctionne très bien, je ne vois pas pourquoi chercher à faire autrement.

J'avais étudié les capteurs suivants lors de la conception de mon BOB3.

Capteur réflectif:
* CNY70: pas assez précis: la transition sombre - clair est beaucoup trop large (plus de 1mm).
* hamamatsu P5587 est précis et rapide, mais nécessite un placement hyper précis du capteur par rapport à la roue codeuse

Capteur transmissif:
* KRA011: pas mal du tout, mais nécessite une roue codeuse parfaitement propre.

Au final, j'ai tout simplement utilisé des capteurs de souris à boule, qui sont très robustes, peu sensibles aux perturbations/erreurs d'alignement, et fiables. Par contre, ils sont limités en fréquence maxi, mais ça ne me gêne pas.
http://ze.bot.free.fr/codeur/capteurs.html

Les capteurs sont directement sur l'axe. Donc la résolution est ~1/2mm. Cela empêche de faire des asservissements de type PID rapides. Je n'utilise que des PI sur ce robot. Un PID rapide impose (en général) de mettre un codeur avec une bien meilleur résolution, voire carrément un codeur placé en amont du réducteur (côté moteur). En effet, une résolution fine est nécessaire pour calculer fréquemment la vitesse, utilisée dans le terme dérivé du PID. Il faut voir suffisamment de "tops codeur" à chaque pas de calcul, donc il faut une résolution fine.

D'ailleurs, vous pouvez copier autant que vous voulez mon BOB3. Sans capteurs ultrasons (avec des capteur moins chers), sans chargeur intégré, et avec une carte mère moins chère, il est possible que ça tienne votre budget.

Leon.

Merci pour cette intervention léon =) tu confirmes parfaitement ce que je pensais ! =) En plus tu donne deux références que je ne connaissais pas ainsi que les avantages et inconvénient de ces capteurs ! Donc cela nous aide beaucoup !
De plus je vais regarder de nouveau ton bob3 =).

à bientôt !

[thermo_nono]

En effet, lors des accélérations, décélérations et changement de sens, ça peux poser problème.
Je pensais néanmoins que :
- le sens de rotation est déjà connu du µC puisque c'est lui qui envoie le signal.
- la différence entre les largeurs de bande allant du simple au double je pensais que ça ne poserait pas de problème à moins que le robot n'accélère énormément.

cela dit, tu as tout à fait raison et je remarque que tu connais le sujet (alors que je n'ai jamais travaillé sur ce type d'élément). Je vais donc m'en remettre à tes conseils et revenir à la méthode des codeurs en quadrature.

[sky99]

En voyant le sujet, je me dis que ça risque d'être difficile d'atteindre la barre des 100€ avec tout ce que vous avez prévu.
Je propose deux idées :

-Soit on l'augmente dans un premier temps, par exemple 150-200€;
-Soit on ne s'occupe pas de ça pour l'instant, en gardant à l'esprit de pas non plus prendre des composants trop chers tout le temps;

L'idée étant que c'est difficile de résoudre des solutions techniques sans plein de domaines différents, tout en ayant une contrainte
d'optimisation financière à l'esprit. Donc peut être qu'une stratégie serait de partir un peu plus large, pour arriver à une base,
un prototype en version 1.0, fonctionnel, plus cher que l'objectif, mais complet, et par la suite quand on aurait atteint l'objectif
fonctionnel, de réfléchir à une optimisation sur les coûts, en cherchant des équivalents moins chers, etc.

De même réussir à faire le robot pourra nous donner une idée du prix minimal possible à atteindre, car j'imagine bien que si on fait
un robot pour 150€, on peut peut être imaginer de baisser son coût d'un tiers, mais probablement pas de baisser le coût de 75% sans
avoir une usine dédiée.

Qu'en pensez vous?

[Mike118]

En voyant le sujet, je me dis que ça risque d'être difficile d'atteindre la barre des 100€ avec tout ce que vous avez prévu.
Je propose deux idées :

-Soit on l'augmente dans un premier temps, par exemple 150-200€;
-Soit on ne s'occupe pas de ça pour l'instant, en gardant à l'esprit de pas non plus prendre des composants trop chers tout le temps;

L'idée étant que c'est difficile de résoudre des solutions techniques sans plein de domaines différents, tout en ayant une contrainte
d'optimisation financière à l'esprit. Donc peut être qu'une stratégie serait de partir un peu plus large, pour arriver à une base,
un prototype en version 1.0, fonctionnel, plus cher que l'objectif, mais complet, et par la suite quand on aurait atteint l'objectif
fonctionnel, de réfléchir à une optimisation sur les coûts, en cherchant des équivalents moins chers, etc.

De même réussir à faire le robot pourra nous donner une idée du prix minimal possible à atteindre, car j'imagine bien que si on fait
un robot pour 150€, on peut peut être imaginer de baisser son coût d'un tiers, mais probablement pas de baisser le coût de 75% sans
avoir une usine dédiée.

Qu'en pensez vous?

Je suis d'accord sur le fait qu'on ne peut pas réaliser le prototype au même prix que celui auquel on veut le développer au final ! C'est évident ! Il me semble même l'avoir dit plusieurs fois dans la discussion. Cependant pour moi l'objectif est quand même de rester sous la barre des 100 euros pour le produit fini . Pas pour le proto ! Donc une fois qu'on aura le proto 100% fonctionnel il faudra encore trouver le moyen de réduire les coût pour qu'il passe sous la barre des 100 euros quitte à réduire certaines spec...

Cependant ce que je pense faisable pour 100 euros :

Le bloc batterie
Le raspberrie pi
Les moteurs
La carte d'asservissement moteur + roue codeuse
Un capteur de distance
le chassis. ( roue comprise )

moi je reconnais que là je ne suis pas à fond sur le projet : c'est la dernière ligne droite pour la coupe de france de robotique. Je travaille à fond sur les robots x) Il y a encore des détailles à régler x) Tout la méca est réglée mais il reste encore de l'élec et de la prog x) et il ne reste qu'une semaine

[Mike118]

Je suis d'accord sur le fait qu'on ne peut pas réaliser le prototype au même prix que celui auquel on veut le développer au final ! C'est évident ! Il me semble même l'avoir dit plusieurs fois dans la discussion. Cependant pour moi l'objectif est quand même de rester sous la barre des 100 euros pour le produit fini . Pas pour le proto ! Donc une fois qu'on aura le proto 100% fonctionnel il faudra encore trouver le moyen de réduire les coût pour qu'il passe sous la barre des 100 euros quitte à réduire certaines spec...

Cependant ce que je pense faisable pour 100 euros :

Le bloc batterie
Le raspberrie pi
Les moteurs
La carte d'asservissement moteur + roue codeuse
Un capteur de distance
le chassis. ( roue comprise )

moi je reconnais que là je ne suis pas à fond sur le projet : c'est la dernière ligne droite pour la coupe de france de robotique. Je travaille à fond sur les robots x) Il y a encore des détailles à régler x) Tout la méca est réglée mais il reste encore de l'élec et de la prog x) et il ne reste qu'une semaine />

Bon me voilà de retour sur le forum ! La coupe de France étant finie je peux enfin me mettre d'avantage sur ce projet ! ( Pour ceux que ça intéresse j'ai finie 77ème sur plus de 200 équipes inscrites. Mes deux robots ont été homologués malgré le fait que le robot principale ne fut malheureusement pas fini complètement ... )

Bref tout ça pour dire que là je me met à créer un module batterie répondant aux critères que j'ai énoncé tout au long des discussions... Donc si vous pensez à autre chose à ajouter sur ce module dites le moi.

ensuite je ne sais pas qui en est où qui compte faire quoi mais en tout cas pour moi ce projet n'est pas mort et je compte réellement le réaliser =)

à bientôt donc !

[Gyro49]

Bonsoir,

Personnellement je me détache du sujet, en effet c'était le risque annoncé il y a quelques mois. Même si le sujet regroupe un sentiment positif par tous nous avons, tous des idées bien précise du rendu final.

Même si l'objectif de ma construction est identique à la votre, j'ai pris un autre axe de recherche.

Je vais associer une RP a un ATMEGA328P (arduino lowcost)

Les moteurs seront des pas-à-pas de 12v avec 200 pas, donc roue codeuse par le fonctionnement des pas.

Re-donc batterie 12v

Rp 35 euros
Atmega 9 euros
moteurs 35 euros
capteur 15 euros
roues 5 euros
batterie 20 euros (http://www.atlantique-composants.fr/eGold/Tools/Modules/modListProduct.php?_pstrSubPrj=STORE&pintHeadingID=1&pstrMenusID=1_3_2)
chassis gratuit -> vieux calendrier

il manque la petite électronique

Maintenant mon projet devra pouvoir évoluer en intérieur avec des obstacles et accepter les tapis de 1 cm d'épaisseur

Je vous souhaite bon courage à tous

Gyro49

[Mike118]

Par curiosité je veux bien voir les liens pointant vers les différents composants que tu comptes utiliser ! en particulier les capteurs, roues et moteurs!
Ensuite concernant la batterie je suggère quand même d'avantage une batterie de type lipo ... Plus légère, plus de capacité et moins cher sur hobby king ...

Perso mes deux robots pour la coupe de france sont en moteur pas à pas avec des lipo ... Et je reconnais qu'une base sur le même principe serait bien plus rapide à faire pour moi ^^ Surtout que j'ai réussis à avoir de belle trajectoire bien droite sans roues codeuses ^^ ( Sauf quand le robot d'en face me percute ... mais ça c'est autre chose x) )

[Melmet]

Mise a jour dans la Dropbox:

schéma de la carte de puissance et gestion des GPIOs.

La carte électronique peut être modifier.
Dites moi ce que vous en pensez.

[Gyro49]

Pour mes composants

Rp 35 euros c'est du classique
Atmega 9 euros Snootlab ou HobbyTronic
moteurs 35 euros HobbyTronic
capteur 15 euros hc-SR04
roues 5 euros http://www.robotshop.com/eu/pair-roues-tamiya.html
batterie 20 euros (http://www.atlantique-composants.fr/eGold/Tools/Modules/modListProduct.php?_pstrSubPrj=STORE&pintHeadingID=1&pstrMenusID=1_3_2)
chassis gratuit -> vieux calendrier

il manque la petite électronique

Gyro49

[Mike118]

Mise a jour dans la Dropbox:

schéma de la carte de puissance et gestion des GPIOs.

La carte électronique peut être modifier.
Dites moi ce que vous en pensez.

Je vais tout de suite y jeter un oeil

EDIT : Tu ouvre tes fichiers avec quoi ? Et quel fichier ? j'ai pas réussi à l'ouvrir ...

Pour mes composants

Rp 35 euros c'est du classique
Atmega 9 euros Snootlab ou HobbyTronic
moteurs 35 euros HobbyTronic
capteur 15 euros hc-SR04
roues 5 euros http://www.robotshop.com/eu/pair-roues-tamiya.html
batterie 20 euros (http://www.atlantique-composants.fr/eGold/Tools/Modules/modListProduct.php?_pstrSubPrj=STORE&pintHeadingID=1&pstrMenusID=1_3_2)
chassis gratuit -> vieux calendrier

il manque la petite électronique

Gyro49

Les moteurs sont très intéressants =)
Pour les capteurs j'utilise les même =) ainsi que des shrap =)
Pour les roues par contre là je suis sceptique j'ai à peu près les même et je pense que tu va être déçu ...

Pour le reste rien à redire />

Le seul truc c'est que si on en a pour 30 euros de moteurs et 30 euros de raspberry pi ... pour rester sous les 100 eurs il reste 40 euros pour le reste ... Mais au moins on a pas besoin de trop forcer sur l'asservissement même si le driver de moteur pas à pas sera un peu plus cher ...

[Melmet]

Bon concernant la carte puissance et gestion GPIOs, j'ai penser a des petites modifs qui peuvent servirent.
je laisse le circuit V1.0 ( ) et je posterais les modifs apres discutions avec Mike.

[Mike118]

Bon concernant la carte puissance et gestion GPIOs, j'ai penser a des petites modifs qui peuvent servirent.
je laisse le circuit V1.0 ( />) et je posterais les modifs apres discutions avec Mike.

Comme le laisse supposé mon précédent message, je n'ai pas réussis à lire tes fichier ! =/ Quel fichier ouvres tu ? et avec quel logiciel ?

De mon côté je prépare une carte d'alimentation, mais je n'ai pas encore choisis le composants principal ... J'en ai juste sélectionné quelques un pour le moment !

En fait à vouloir faire " modulaire" je cherche un régulateur 5V avec un bon rendement qui fait aussi bien step up que step down histoire de pouvoir aussi bien utiliser une batterie 1S que 6S ( et tout les intermédiaires ^^ ) .

Comme ça du coup on pourra mettre la batterie que l'on veut

[Melmet]

Désoler, j'avais pas vue ton message.
C'est sous kicad.
si ça marche pas, je prend des Screenshots et je publie.

[Melmet]

Bon voila, j'aimerai bien savoir : si quelqu'un fait quelque chose sur le projet.

Y a pas mal de personnes inscrites sur la dropbox et je ne voie pas de commentaires ou de schémas ou de CI.
Je sais bien que vous pouvez avoir autre choses a faire, mais commentez au moins les plans qui ont été mis sur la dropbox. (pour ceux qui y participent vraiment)

Moi perso: j'ai fait les schémas de la carte de puissance et gestions des GPIOs sous KICAD! (important car s'il manque une bibliotheque, dites le moi)

Mais j'aimerais bien savoir si quelqu'un a quelque chose a partager.

J'aimerais avoir votre avis et aussi donner mon avis sur votre et mon travail />

Mise a jour dans la Dropbox faite.