Nous sommes le Sam 21 Avr 2018, 08:50


Encodeur optique

Endosquelette en titane ou plaque en epoxy, roue en plastique ou piston pneumatique... Comment faire fonctionner tout cela !
  • Auteur
  • Message
Hors ligne
Avatar de l’utilisateur

Jep31

Bricoleur confirmé

  • Messages: 37
  • Inscription: Dim 14 Oct 2012, 17:53
  • Localisation: Toulouse

Encodeur optique

Message non luVen 2 Nov 2012, 18:46

Bonjour,

Je réalise un projet de robot mobile. Je ne présente pas mon robot ici, il est très simple et voici une vidéo qui montre le début du projet:



Pour le moment il est commander manuellement mais l'objectif est de l'équiper de capteurs pour m'en servir de plateforme de développement pour des déplacements autonomes.
Le dispositif le plus important dans mon robot sera les roues codeuses. Elles seront indépendantes des roues motrices pour éviter les erreurs dues au patinage des ces roues motrices. Cependant j'ai du mal à trouver un bon produit pas trop chers et fiables. C'est le dispositif le plus importants de mon robot donc je veux quelque chose de fiable et c'est aussi la plus grosse dépense donc je voudrais être sur de mon choix.

Je voudrais acheter des codeurs avec axe intégré pour éviter au maximum le bricolage approximatif. J'ai trouvé deux modèles chez US digital pas trop cher par rapport à la concurrence. Et je profite d'être au Canada jusqu'à Févier pour éviter les taxes car on ne peut pas les acheter en Europe.

Donc j'ai trouver deux modèles d'encodeurs équivalent j'ai Us digital:
Encodeur H5 US Digital ref H5-900-NE-S (CPR 900, No Index, Single-ended)
Encodeur S5 US Digital ref S5-900-236-NE-S-B (CPR 900, No Index, Single-ended, Ball Bearing)

Quand pensez vous ? Est ce un bon produit adapté ? A t'il un bon rapport qualité pirx ?
Que pensez vous des options ?

C'est la première fois que j'achète des encodeurs donc je suis novice et j'ai pas mal peur de me planter surtout vu la somme que ça représente.

Merci pour vos conseils,

Jep31
Hors ligne
Avatar de l’utilisateur

leon

Roboticien confirmé

  • Messages: 634
  • Inscription: Dim 19 Juil 2009, 07:57

Re: Encodeur optique

Message non luSam 3 Nov 2012, 12:17

Ca dépend de ce que tu veux faire. Avec des encodeurs "déportés", il ne faut pas envisager de faire un PID bourrin. Pourquoi? Parce que le terme dérivé fonctionnera mal. Un PID gentil, pas trop agressif, oui, fonctionnera bien. Pour pour un asservissement "gentil" ou même juste un positionnement 2D du robot, tu n'as pas forcément besoin d'une résolution de malade.

90€ l'encodeur, c'est encore beaucoup trop cher à mon avis. Il existe plein de solution plus économiques. A toi de bien déterminer ton besoin en performances, à savoir :
* le nombre de pas par tour de roue (ça dépends des algos que tu fais tourner derrière)
* la vitesse maximal de tes roues, donc la fréquence maxi des "tops" que l'encodeur doit supporter.

Regarde mon BOB3 où j'ai réalisé des encodeurs à partir de souris à boulle, donc pour 3 francs 6 sous. La résolution est peut-être insuffisante pour toi, mais ça te montre ce qu'on peut faire en bidouillant un peu. C'est vraiment très fiable.
http://ze.bot.free.fr/codeur/capteurs.html

On peut aussi trouver des encodeurs de récup plus performants, notamment dans les imprimantes et photocopieurs "pro" (pas les gadgets à 100€).

Exemple de produit "low cost" chez Lextronic:
http://www.lextronic.fr/P23527-encodeur ... 19-mm.html

Si tu as des questions...

Leon.
BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + FoxBoard Linux http://ze.bot.free.fr/
Hors ligne
Avatar de l’utilisateur

Jep31

Bricoleur confirmé

  • Messages: 37
  • Inscription: Dim 14 Oct 2012, 17:53
  • Localisation: Toulouse

Re: Encodeur optique

Message non luSam 3 Nov 2012, 15:45

Salut,


Merci pour t'as réponse. J'avoue que ce que je recherche c'est plus un solution clé en main même si c'est beaucoup plus cher. De plus je voudrais une précision de 500 CPR au minimum. A US Digital 500 CPR et 900 CPR c'est le même prix donc j'ai choisi 900. C'est pas en euro aussi le prix ;-) (73 € l'unité)

Par exemple l'encodeur de Pololu est bien clé en main mais avec seulement 48 CPR. C'est vrai que je me pose la question sur une résolution de 500 CPR, si ce n'est pas sur-dimensionner le matériel mais 48 c'est vraiment faible. J'aimerais programmer du suivi de trajectoire avec une odométrie très précise. On peut voir la vitesse de mon robot sur la vidéo et calculer facilement la fréquence des tops dont j'ai besoin. Je vais faire ça pour vérifier.

Que veut tu dires par un PID bourrin ne fonctionnera pas ? A la coupe de France de robotique tout le monde utilise ce système et cela fonctionne très bien pour certain.
Hors ligne
Avatar de l’utilisateur

leon

Roboticien confirmé

  • Messages: 634
  • Inscription: Dim 19 Juil 2009, 07:57

Re: Encodeur optique

Message non luSam 3 Nov 2012, 18:08

Jep31 a écrit:Salut,


Merci pour t'as réponse. J'avoue que ce que je recherche c'est plus un solution clé en main même si c'est beaucoup plus cher. De plus je voudrais une précision de 500 CPR au minimum. A US Digital 500 CPR et 900 CPR c'est le même prix donc j'ai choisi 900. C'est pas en euro aussi le prix ;-) (73 € l'unité)

Par exemple l'encodeur de Pololu est bien clé en main mais avec seulement 48 CPR. C'est vrai que je me pose la question sur une résolution de 500 CPR, si ce n'est pas sur-dimensionner le matériel mais 48 c'est vraiment faible. J'aimerais programmer du suivi de trajectoire avec une odométrie très précise.
Comment as-tu déterminé qu'il te fallait 500 tops? Ca donne combien de mm/micromètre en déplacement à la roue?

Il faut savoir que les encodeurs avec plein de tops n'ont qu'une seule raison d'être. L'objectif est de faire des asservissements PID très précis et rapides. Dans ce cas, pour calculer la vitesse (terme dérivé du PID) de manière précise, il faut un grand nombre de "tops", pour en voir suffisamment à chaque pas de calcul, même à faible vitesse.

Mais si ton besoin est uniquement de bien te repérer, alors tu n'as pas besoin (je pense) d'une si grande résolution (au 10ieme de mm). Dans ce cas, la contrainte la plus forte est sur l'estimation d'orientation du robot, qui doit être de l'ordre du degré si mes souvenirs sont bons sur BOB3. Toujours sur BOB3, je n'utilise pas de PID, mais seulement 2 asservissements PI (donc sans le D). Il y a un asservissement pour l'avancement, et un asservissement pour l'orientation. Certains appellent ça asservissement polaire. Dans ce cas, comme je n'ai pas de terme dérivé, je n'ai pas besoin d'une résolution très fine, et je me contente de peu. Un asservissement de type PI est moins performant, moins péchu, moins précis. Le suivi de trajectoire est peu précis sur BOB3. Mais le positionnement, lui, est très précis! Bob3 sait exactement où il est, même s'il a du mal à rouler bien droit. Ca correspond bien à mon besoin : je voulais un robot intelligent et simple, mais pas forcément performant.

Et la résolution peut être aussi améliorée par l'électronique. Sur BOB3, j'utilise un composant (HCTL2032) pour interpréter les tops des 2 codeurs, et il "multiplie par 4" la résolution. Chaque front (montant ou descendant) de chacun des 2 capteur lui sert à incrémenter/décrémenter son compteur. Regarde le datasheet.

A la coupe de France de robotique tout le monde utilise ce système et cela fonctionne très bien pour certain.
Ah, voici un argument trop souvent utilisé, dans le monde amateur comme dans le monde professionnel, et que je n'aime pas du tout (désolé). Ca n'est pas parce que le voisin a choisi une solution qu'elle est bonne pour toi!
Il faut avant tout poser ton problème (ton cahier des charges), explorer les différentes solutions, etc... Recopier n'est pas toujours la meilleure solution.

Donc si tu n'a pas prévu de faire d'asservissement de type PID sur chacune des 2 roues, il ne servira à rien d'avoir un encodeur avec autant de tops.

Un dernier truc: des encodeurs séparés, ça n'est pas forcément indispensable. Si tu maitrises bien la puissance, que tu la limite, pour être certain de ne pas déraper, alors ça ne posera pas de problème. Mais dans ce cas, il faut utiliser des roues les plus fines possibles, et les moins déformables possibles. Maintenant, vu les roues que tu as choisies, on peut comprendre que tu veuilles mettre des codeurs séparés.

Leon.
BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + FoxBoard Linux http://ze.bot.free.fr/
Hors ligne
Avatar de l’utilisateur

Jep31

Bricoleur confirmé

  • Messages: 37
  • Inscription: Dim 14 Oct 2012, 17:53
  • Localisation: Toulouse

Re: Encodeur optique

Message non luDim 4 Nov 2012, 03:13

Tout d'abord merci pour ta réponse très constructive

Comment as-tu déterminé qu'il te fallait 500 tops? Ça donne combien de mm/micromètre en déplacement à la roue?


En fait c'est surtout ce que j'utilisais au club robotique de mon école. J'ai calculé la résolution avec une roue de 2.5 cm de rayon (Je n'ai pas encore choisi la roue que j'allais utiliser). Ça donne environ du 0.03 cm ce qui est effectivement beaucoup. Mais en fait, dans le commerce on passe très rapidement au 500 par tour et c'est souvent le même prix que pour du 360. Donc je me disais autant prendre le maximum, plus y a d'impulsions plus on rit :D
Pensez vous que trop d'impulsions par tour puissent me gêner ?
Je compte effectuer ma commande de bas niveau(réception données codeurs et commande des moteur) avec l'Arduino Uno que je possède. Il ne devrait gérer que le bas niveau, j'espère connecter un Raspberry Pi (ou équivalent) pour le haut niveau.

Avec 360 CPR ça donne du 0.04cm ce qui me semble toujours acceptable même pour faire un PID bien bourrin comme tu dis.

Il faut savoir que les encodeurs avec plein de tops n'ont qu'une seule raison d'être. L'objectif est de faire des asservissements PID très précis et rapides.


Je compte me servir de ce robot pour tester surtout différents types de commandes assez précises donc je pense que je ferrais effectivement de mon mieux pour avoir un PID très précis et rapide.


Mais si ton besoin est uniquement de bien te repérer, alors tu n'as pas besoin (je pense) d'une si grande résolution (au 10ieme de mm). Dans ce cas, la contrainte la plus forte est sur l'estimation d'orientation du robot, qui doit être de l'ordre du degré si mes souvenirs sont bons sur BOB3. Toujours sur BOB3, je n'utilise pas de PID, mais seulement 2 asservissements PI (donc sans le D). Il y a un asservissement pour l'avancement, et un asservissement pour l'orientation. Certains appellent ça asservissement polaire. Dans ce cas, comme je n'ai pas de terme dérivé, je n'ai pas besoin d'une résolution très fine, et je me contente de peu. Un asservissement de type PI est moins performant, moins péchu, moins précis. Le suivi de trajectoire est peu précis sur BOB3. Mais le positionnement, lui, est très précis! Bob3 sait exactement où il est, même s'il a du mal à rouler bien droit. Ca correspond bien à mon besoin : je voulais un robot intelligent et simple, mais pas forcément performant.


Oui tu n'as pas tord, en aucun cas la résolution des codeurs ne joue sur le calcul de la pose du robot. En effet la résolution n'est pas l'erreur commise donc l'erreur du a une faible résolution reste la même et ne s'accumule pas. J'avais pas fait ce raisonnement tout bête avant :red:

Et la résolution peut être aussi améliorée par l'électronique. Sur BOB3, j'utilise un composant (HCTL2032) pour interpréter les tops des 2 codeurs, et il "multiplie par 4" la résolution. Chaque front (montant ou descendant) de chacun des 2 capteur lui sert à incrémenter/décrémenter son compteur. Regarde le datasheet.


Oui je sais que l'on peut utiliser tous les fronts pour doubler la résolution. Cependant c'est valable même quand le produit est spécifié deux voies en quadrature ?


Ah, voici un argument trop souvent utilisé, dans le monde amateur comme dans le monde professionnel, et que je n'aime pas du tout (désolé). Ca n'est pas parce que le voisin a choisi une solution qu'elle est bonne pour toi!
Il faut avant tout poser ton problème (ton cahier des charges), explorer les différentes solutions, etc... Recopier n'est pas toujours la meilleure solution.


Tu as absolument raison ! Honte à moi lol.
Je disais cela parce que mon robot devrait être assez proche de ceux qui sont font là bas et que j'ai vu des résultats assez impressionnant mais oui tu as raison ça ne veut rien dire.

Un dernier truc: des encodeurs séparés, ça n'est pas forcément indispensable. Si tu maitrises bien la puissance, que tu la limite, pour être certain de ne pas déraper, alors ça ne posera pas de problème. Mais dans ce cas, il faut utiliser des roues les plus fines possibles, et les moins déformables possibles. Maintenant, vu les roues que tu as choisies, on peut comprendre que tu veuilles mettre des codeurs séparés.


Oui je me dis que j'aurais pu commencer par des encodeurs intégrés aux capteurs, ça aurait été moins chers et je pourrais déjà faire mumuse avec. ^_^

Sinon je viens de tomber sur un nouveau produit(ou pas): 48€ l'unité !
NEMICON 360
NEMICON 500
NEMICON 1024

Encore une fois de 360 à 1024 c'est le même prix. Les 1024 sont juste deux fois plus long, ce qui pourrait me gêner.
Que pensez vous de ce modèle. J'ai vu une fréquence de 50KHz, ca fait 50 000 pulsation seconde pouvant être traitées c'est ça ? Parce que d'après mes calculs de nombres d'impulsions par seconde avec une vitesse entre 1m/s et 2m/s de mon robot 50KHz parait faible mais je loupe peut être un truc (voir tout)
Hors ligne
Avatar de l’utilisateur

leon

Roboticien confirmé

  • Messages: 634
  • Inscription: Dim 19 Juil 2009, 07:57

Re: Encodeur optique

Message non luDim 4 Nov 2012, 08:22

Oui tu n'as pas tord
[...]
Pensez vous que trop d'impulsions par tour puissent me gêner ?
[...]
pour faire un PID bien bourrin comme tu dis.
[...]
Que pensez vous de ce modèle.

Il faudra se décider entre le vouvoiement et le tutoiement! ;)
Personnellement, je pense que c'est tutoiement obligatoire sur les forums!

J'ai vu une fréquence de 50KHz, ca fait 50 000 pulsation seconde pouvant être traitées c'est ça ? Parce que d'après mes calculs de nombres d'impulsions par seconde avec une vitesse entre 1m/s et 2m/s de mon robot 50KHz parait faible mais je loupe peut être un truc (voir tout)
50kHz, avec un codeur de 500 tops, ça permet de détecter jusqu'à une vitesse de rotation de 100 tours par seconde, soit 6000 tours/min.
Avec des roues de 2.5cm de rayon, donc 16cm de circonférence, ça te permet d'aller jusqu'à 16m/s!!! 56km/h! Tu n'ira jamais à une telle vitesse avec ton robot, je te l'assure!

Et la résolution peut être aussi améliorée par l'électronique. Sur BOB3, j'utilise un composant (HCTL2032) pour interpréter les tops des 2 codeurs, et il "multiplie par 4" la résolution. Chaque front (montant ou descendant) de chacun des 2 capteur lui sert à incrémenter/décrémenter son compteur. Regarde le datasheet.


Oui je sais que l'on peut utiliser tous les fronts pour doubler la résolution. Cependant c'est valable même quand le produit est spécifié deux voies en quadrature ?
Comme je te le disais, avec des codeurs en quadrature, ça ne double pas seulement la résolution, ça la multiplie par 4: chaque front de chacune des 2 voies peut être utilisé. Je réitère mon conseil: regarde le datasheet du HCTL2032.
Par contre, je n'ai jamais codé ça sur un microcontrôleur. Je ne sais pas si c'est simple à faire ou non.

Leon.
BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + FoxBoard Linux http://ze.bot.free.fr/
Hors ligne
Avatar de l’utilisateur

Esprit

Membre asso caliban

  • Messages: 1641
  • Inscription: Jeu 11 Fév 2010, 11:14
  • Localisation: Ottignies

Re: Encodeur optique

Message non luDim 4 Nov 2012, 08:47

Je ne me suis pas manifesté, mais je lis attentivement les conseils de Léon. Toujours aussi intéressant, précis et clair !

Loué soit Léon ! :D
Simon, membre fondateur de l'Association Caliban Belgique,
.·° Mon blog : Le Chipoteur de Brols .·°·. L' Association Caliban Belgique °·.
"L'impossible, nous ne l'atteignons pas, mais il nous sert de lanterne." (René Char)
Hors ligne
Avatar de l’utilisateur

JBot

Roboticien en herbe

  • Messages: 164
  • Inscription: Sam 29 Mai 2010, 10:07
  • Localisation: Paris

Re: Encodeur optique

Message non luDim 4 Nov 2012, 13:08

leon a écrit:Comme je te le disais, avec des codeurs en quadrature, ça ne double pas seulement la résolution, ça la multiplie par 4: chaque front de chacune des 2 voies peut être utilisé. Je réitère mon conseil: regarde le datasheet du HCTL2032.
Par contre, je n'ai jamais codé ça sur un microcontrôleur. Je ne sais pas si c'est simple à faire ou non.

Leon.


Bien sur que c'est très simple à coder sur un microcontroleur. Mon robot 2011 ne possédait qu'une arduinoMEGA et décodait les 2 encodeurs en prenant en compte tous les front (montant et descendant) afin d'améliorer la précision.

http://www.instructables.com/id/Positio ... urce-code/
Fondateur de l'équipe S.M.A.R.T. (autonomouS Multi Application Robot Team) : http://smartrobotics.org/blog/
Malédiction du Créatif :
Plus vous avez d’idées et moins vous arrivez à les structurer.
Hors ligne
Avatar de l’utilisateur

leon

Roboticien confirmé

  • Messages: 634
  • Inscription: Dim 19 Juil 2009, 07:57

Re: Encodeur optique

Message non luDim 4 Nov 2012, 16:56

Effectivement, merci JBot!

Des interruptions déclenchées par un quelconque changement d'état sur une des 4 entrées des codeurs des 2 roues. Effectivement, en voyant le code, ça parait simple et logique.

Est-ce que tu as déterminé jusqu'où tu pouvais aller en fréquence de codeurs, du point de vue "logiciel", avant que les interruptions ne viennent perturber le programme?

Par exemple, si on va jusqu'à 50kHz (cf caractéristique des encodeurs de JEP31), avec 2 codeurs, et 4 interruption par période, on arrive à 50k x 4 x 2 = 400 000 interruptions par seconde. Ca doit commencer à faire beaucoup, peut-être même trop!

Leon.
BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + FoxBoard Linux http://ze.bot.free.fr/
Hors ligne
Avatar de l’utilisateur

Jep31

Bricoleur confirmé

  • Messages: 37
  • Inscription: Dim 14 Oct 2012, 17:53
  • Localisation: Toulouse

Re: Encodeur optique

Message non luDim 4 Nov 2012, 18:04

Il faudra se décider entre le vouvoiement et le tutoiement!
Personnellement, je pense que c'est tutoiement obligatoire sur les forums!


Le vous c'est pour s'adresser à l'ensemble des membres du forum, un vous pluriel ;)

50kHz, avec un codeur de 500 tops, ça permet de détecter jusqu'à une vitesse de rotation de 100 tours par seconde, soit 6000 tours/min. Avec des roues de 2.5cm de rayon, donc 16cm de circonférence, ça te permet d'aller jusqu'à 16m/s!!! 56km/h! Tu n'ira jamais à une telle vitesse avec ton robot, je te l'assure!


Ca confirme la datasheet avec 6000 tours/min j'ai donc bien fait une bourde de calcul. Si je me reprend correctement je ne devrais jamais dépasser 10 kHz même avec une roue de 3,5cm de rayon et 1024 impulsions et 2m/s(vitesse que mon robot n'atteindra jamais, il est plus proche des 1m/s. Je pense que l'Arduino devrait pouvoir gérer ça. Pas forcement besoin d'exploiter tous les fronts avec 1024 impulsions et même avec 500 j'en doute mais je pourrais tenter et comparer les résultats, c'est ça l'important. Normalement l'Arduino ne devrait pas gérer autre chose que l'odométrie et le contrôle moteur.
Arduino Uno: 6 analog inputs, a 16 MHz ceramic resonator

Je ne sais pas analyser ce chiffre, j'imagine que ça dépend du nombre d'opération élémentaires qu'effectue le programme. J'ai pas vraiment d'ordre de grandeur.

Après faut voir l'intérêt d'avoir tant d'impulsion:
Avec roue de 3,5cm de rayon:
résolution 360CPR = 2*Pi*3,5 / 360 = 0,610 mm
résolution 500CPR = 2*Pi*3,5 / 500 = 0,439 mm
résolution 1024CPR = 2*Pi*3,5 / 1024 = 0,21 mm
résolution 500CPR en utilisant chaque front = 2*Pi*3,5 / (4*500) = 0,109 mm

Je suis incapable de voir l'impact réel de ces valeurs sur un PID...
En fait la valeur la plus impactée par cette résolution serait l'erreur d'orientation comme l'a dit Leon:
Avec un écart entre le roue codeuse de 30 cm sur mon robot.
erreur max orientation 360 = 0,06*2/30 = 0,004 Rad = 0,2°
avec 500 = 0,0029 Rad = 0,167°
(J'espère ne pas encore avoir dans les calculs)

Ces différences me semblent quand même ridicule. Bon après 360 ou 1024 c'est le même prix. Seul la dimension du codeur change entre 500 et 1024. En effet le 500 est très petit, pratique ça prend pas de place mais un axe de 7mm pour le montage, ça me parait pas bien pratique.
Je me réfère aux encodeur NEMICON qui sont pour l'instant les moins chers avec un axe intégré.
Hors ligne

lordcuty

Membre asso caliban

  • Messages: 68
  • Inscription: Lun 4 Avr 2011, 20:12

Re: Encodeur optique

Message non luMer 7 Nov 2012, 14:03

bonjour à tous,

pour continuer les propos de jbot, dont je suis un fervent admirateur,
je dispose des codeurs résolution 1024CPR de vicatronnic, ce qui fait après calculs 4048 pas par tour, et là je pense que comme tu peux le voir sur la photo de mon barnabique, tu es plus limité par la mécanique, le codeur doit toucher le sol, être parallèle à la roue motrice, et le rester, dans les virages ne pas déraper.... bref tout un tas de contraintes que tu auras qui diminuerons la qualité de ton asservissement.
malheureusement ton arduino uno ne va pas suffire, car tu ne disposes que de deux interruptions matérielles, or
avec deux fois deux Chanels, il faudrait quatre interruptions matérielles comme sur une arduno méga.
à moins d'utiliser un circuit spécial comme celui de Léon.

Lordcuty
Fichiers joints
DSC01443_2.JPG
Hors ligne
Avatar de l’utilisateur

Jep31

Bricoleur confirmé

  • Messages: 37
  • Inscription: Dim 14 Oct 2012, 17:53
  • Localisation: Toulouse

Re: Encodeur optique

Message non luMer 7 Nov 2012, 17:29

lordcuty a écrit:pour continuer les propos de jbot, dont je suis un fervent admirateur,
je dispose des codeurs résolution 1024CPR de vicatronnic, ce qui fait après calculs 4048 pas par tour, et là je pense que comme tu peux le voir sur la photo de mon barnabique, tu es plus limité par la mécanique, le codeur doit toucher le sol, être parallèle à la roue motrice, et le rester, dans les virages ne pas déraper.... bref tout un tas de contraintes que tu auras qui diminuerons la qualité de ton asservissement.


Ah tu as les codeur de vicatronnic ! ::-D: Peux tu déjà me donner un retour sur leur qualité ?
Si il y a un défaut que tu aurais constaté.
L'axe tourne bien et sans jeu ? La dimension est elle propice a un bon montage ?
Le 1024 me parait de la bonne taille alors que j'ai peur que les autres soit trop petit et surtout la longueur de l'axe. 7mm c'est court !
Oui je sais que le coté mécanique est très délicat et c'est ce qui me fait peur car je ne dispose pas de moyen important et le bricolage n'est pas vraiment mon secteur de prédilection. Par contre le jour où j'ai une imprimante 3D de qualité à mes cotés ça va déménager !

lordcuty a écrit:malheureusement ton arduino uno ne va pas suffire, car tu ne disposes que de deux interruptions matérielles, or
avec deux fois deux Chanels, il faudrait quatre interruptions matérielles comme sur une arduino méga.
à moins d'utiliser un circuit spécial comme celui de Léon.
Lordcuty


Arghhh oui j'avais oublié ce détail. C'est vrai que pour le club robotique de mon école on avait justement choisi l'Arduino Mega pour cette raison. Mmmh va falloir que je réfléchisse ou que j'investisse, voir les deux...
Hors ligne

lordcuty

Membre asso caliban

  • Messages: 68
  • Inscription: Lun 4 Avr 2011, 20:12

Re: Encodeur optique

Message non luMer 7 Nov 2012, 22:05

je les ai pas mal utilisé, (ils sont montés) mais je n'ai pas eu de problème l'axe est relativement long et fixable facilement, (tant que tu ne regardes pas trop près mes perçages....), cela dit, je n'ai pas eu le temps de faire vraiment tourner, je venais de finir mon algo pid quand je suis rentrés en prépa....
sinon pour les capteurs, regarde les lidars de neato xv11, j'en avais eu un pour 80€
mais je sais que jbot et asstondb en utilises aussi sans problèmes non plus. après il faut aussi te faire des belles roues, j'avais pour ma part commandé les miennes chez easyrobotics...

quand aux arduinos, regarde sur ebay, tu en as qui marchent très bien pour 20$, des megas... c'est pas parcequ'ils n'ont pas le logo qu'ils ne marchent pas....
Hors ligne
Avatar de l’utilisateur

Jep31

Bricoleur confirmé

  • Messages: 37
  • Inscription: Dim 14 Oct 2012, 17:53
  • Localisation: Toulouse

Re: Encodeur optique

Message non luJeu 8 Nov 2012, 02:14

Oki je vois.
Je pense commander les 2 encodeurs 1024CPR de NEMICON sur Vicatronic.
Je ne connais juste pas le câblage à la sortie. Ils disent: "Raccordement par câble de 478 mm de long équipé d'un connecteur STOCKO 7 points référence MKH 5136-1-0-600" mais je ne vois pas à quoi cela correspond exactement. Penses tu que je peux brancher ça directement sur un Arduino ou il me faut commander quelque chose pour la connexion ? Je voudrais éviter les coups de ciseaux dans le câble par contre.

Merci pour votre aide à tous
Hors ligne
Avatar de l’utilisateur

leon

Roboticien confirmé

  • Messages: 634
  • Inscription: Dim 19 Juil 2009, 07:57

Re: Encodeur optique

Message non luSam 10 Nov 2012, 08:16

Tiens, je n'avais pas encore vu ton robot Barnabique, lordcuty.
Tu n'as pas de post où tu le présentes? C'est dommage.
Du coup, j'ai une question à propos du Lidar Neato : où est-ce qu'on achète ce genre de produit? Je parle bien juste du Lidar, pas du robot entier qui est facturé plus de 300€.
Et puis est-ce que tu as commencé à jouer avec? Je suppose que l'Arduino est bien insuffisante pour exploiter la quantité de donnée qu'envoie le Lidar. Du coup, est-ce que tu mets un PC ou une carte plus puissante derrière?

Leon.
BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + FoxBoard Linux http://ze.bot.free.fr/
Suivante

Retourner vers Mécanique

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité

cron