G4st0n, bras robotisé

pilpoil a écrit:c'est un peu comme si on perdait quelqu'un de la famille (toutes proportions gardées)

Pour moi mes animaux de compagnie font intégralement partie de la famille. A tel point que ma femme qui est instit pouvait avoir une mutation sur Mayotte, pour y être déjà passé çà m'avait bien plu et on avait décidé de tenter l'aventure. Pas de soucis pour les chats mais les compagnies aérienne ne voulaient pas nous prendre le lapin nain alors on a laissé tomber l'affaire. Et on ne regrette rien.

Bon va pour un sujet sur l'arduino, c'est le genre de truc s'il prend qui risque de faire boule de neige.

Cool pour l'arduino mais je veux tout savoir, par quoi on commence, ce qu'il faut acheter etc.
Je casserais ma tirelire, je suis sur qu'il y a des chose a faire avec ça

Oserais-je répondre ... il y a tout à faire.
La mécanique c'est bien.
L'électronique c'est bien.
L'informatique c'est bien.

Mais quand tu associe les trois et que tu te mets à faire de la mécatronique alors là...

J'ai démonté la base tournante de R0G3R mon ancien bras. Il ne servira plus donc autant profiter du travail déjà fait. Il n'y aura pas trop de modifications à faire pour l'adapterà G4st0n.

L'asservissement par potentiomètre fonctionne bien mais présente trop de désagréments: mise en place compliquée sur le robot, usure des pistes à l'usage, etc.
Donc je travaille maintenant sur un asservissement par capteur optoélectroniques. Là aussi des plus et des moins:
- après essais le moteur n'est pas stable en vitesse, çà oscille entre 1415 et 1425 tr/mn.
- il met une seconde à se stabiliser et autant à s’arrêter.
- le potentiomètre renvoyant une tension comprise entre 0 et 5v on savait de suite la position du bras, ce n'est pas le cas avec le capteur, j'ai retourné le pbm dans tous les sens et je vais être obligé de programmer une POM qui s'effectuera au démarrage du bidule.

J'ai simulé une prise d'origine par capteur opto sur la maquette d'essai, le reste va se passer avec le clavier :

Bonsoir meles,
C'est sur que ce serait l'idéal, mais c'est un petit challenge que je me suis donné, j'ai de beaux petits moteurs cc démultipliés avec système opto, c'est surtout l'envie de les utiliser et de leur faire faire ce que je veux. Et puis aussi l'envie de faire un truc qui sort de l'ordinaire.
Je garde la solution des moteurs pap comme roue de secours si tout çà ne fonctionne pas comme je le voudrais au final,  
Mais pas des petits, des nema23 avec un torque d'au moins 18kg, je compte faire des segments d'au moins 25cm de long et il va falloir de la force pour les bouger et les maintenir.

Meles, l'ennui avec cette solution c'est que le signal qui sort d'un pas à pas entrainé par un autre moteur, c'est qu'il délivre un signal dont l'amplitude dépend de la vitesse de rotation et ici cette vitesse de rotation sera faible donc difficulté d'exploiter ces signaux. C'est tout l'intérêt des codeurs optiques. Niveau résolution en plus il n'y a pas photo car des codeurs optiques donnant des milliers de pulses par tour existent si besoin est.
Stan

Astucieux l'idée d'un encodeur à partir d'un pap, j'essaierai pour jouer. En plus il offre le schéma de remise en forme des signaux, pas besoin de le concevoir, c'est good.
J'ai déjà fais des essais en remplaçant le potar par un encodeur rotatif chinois à 1€. Pas terrible, pas limité en rotation mais des rebonds en pagaille car ces encodeurs sont mécaniques, bien pour du petit bricolage mais pas pour quelque chose de précis, j'avais déjà pu constater la chose quand j'ai construis le VFO de mon récepteur. Mais dans les trois cas (potar, encodeur rotatif, pap) çà complique la construction du bras car il faut les relier à l'axe, c'est pour cela que je fais des essais en utilisant le codeur intégré au moteur.
En ce moment je travaille sur une routine pour mesurer le nombre de ticks pour un tour en sortie d'axe démultiplié, pas simple il faut prendre ne compte l'inertie du moteur au démarrage et à l’arrêt car c'est comme çà que fonctionnera le bras au final.

bonjour,
après avoir remarqué la même chose que toi a propos des rebonds sur les encodeurs rotatifs chine-toc, j' ai développé un programme pour un petit pic 8 broches .Si tu es intéressé, un petit mp
Antoine

Je te remercie Antoine mais je ne maîtrise pas les PIC. J'avais voulu m'y mettre, je me suis acheté un jour un Pickit3, j'avais commencé les cours de BigOnOff et au même moment j'ai découvert l'arduino, le pickit depuis  dans un tiroir. On ne peut pas être partout.
Par contre si tu peux m'expliquer les grandes lignes de ton programme je pourrais peut-être l'implémenter sur arduino.

Si tu arrives a t' y retrouver ....

https://dl.dropboxusercontent.com/u/67800804/rotary%20enc%20debounce%201.JPG
https://dl.dropboxusercontent.com/u/67800804/rotary%20enc%20debounce%202.JPG

une autre piste: récupération roues codeuse d' une ancienne souris de pc
http://www.members.shaw.ca/swstuff/mouse.html

cela fonctionne d' enfer, pas de rebonds (le circuit intégré de la souris ne sert a rien

Bonsoir, merci pour tes liens Antoine, je comprends en gros les deux organigrammes même s'il y a des petits trucs spécifiques qu'il faudra adapter. Celui de la modif de souris est génial, çà faisait pas mal de temps que je louchais sur ces mécanismes mais c'est tellement petit... et puis finalement en l'adaptant sur un potentiomètre piraté c'est une super idée.
Prochain achat à la déchetterie.

POM codée:

Antoine, peux-tu me dire avec quel soft tu fais tes organigrammes ?  j'utilise le crayon et la gomme pour les miens et je finis par avoir un travail tout pourri à force de modifs

bonsoir,

il s' agit de SPLAN
(mettre abacom splan dans gogol)

++
Antoine

Merci, je vais voir çà.

Dernière avancée de G4ST0N, l'asservissement en position par coupleur opto. Le potentiomètre ne me convenait pas, usure dans le temps, limitation en rotation, limitation en précision du fait de la qualité du potentiomètre et surtout complications dans la construction du bras. Les petits moteurs Namiki disposant d'un coupleur opto çà aurait été dommage de s'en priver.
Un vrai combat de rue ce bout de code, çà fait plusieurs jours que je me cassais les dents dessus, pas pour le programme en lui-même mais les registres qui ne répondaient plus normalement.
Voilà une partie de code simple qui fonctionne bien pour faire tourner un moteur continu dans les deux sens et l'arreter quand on veut:

Code:

// -------------------------------------------------- Attributions pins
#define pinA      9                  // pin moteur (PWM)
#define pinB      11                 // pin moteur (PWM)
// -------------------------------------------------- Moteurs
#define moteurD    PORTB=B00000010       // pinA=HIGH, pinB=LOW   moteur tourne sens horaire
#define moteurG    PORTB=B00001000       // pintA=LOW, pinB=HIGH  moteur tourne sans anti-horaire
//#define moteurStop PORTB=B00001010   // pinA et pinB normalement à HIGH  
//#define moteurStop PORTB=B00000000   // pinA et pinB normalement à LOW  
//#define moteurStop PORTB|=B00001010  // pinA et pinB normalement à LOW  
#define moteurStop PORTB=11111111        // PORTB à HIGH  
//#define moteurStop digitalWrite(pinA,LOW);digitalWrite(pinB,LOW) // moteur stoppe net

Comme on le voit il y a plusieurs façons de stopper le moteur qui sont toutes fonctionnelles, 3 en jouant sur les registres et une en C arduino.
Le pbm c'est que dans le programme final qui est beaucoup plus long et plus complexe les moteurStop par registres ne fonctionnaient plus du tout, le moteur continuait à tourner. Obligé pour çà d'employer la méthode moins élégante en C arduino, plus lente à l'éxécution.

Pour faire une POM lente comme on le voit dans la vidéo dessous j'utilise un PWM à 10%. Après m'être bien creusé la tête je me suis rendu compte que c'était çà qui foutait la m....
Une fois le renard découvert j'ai résolu en remettant mon PWM à 255 juste avant d'appeler le moteurStop par registre qui cette fois fonctionnait normalement.
Des fois c'est tordu...  

Code:

#define moteurD_lent analogWrite(pinA,lent);analogWrite(pinB,0) // #define lent 10
#define moteurG_lent analogWrite(pinA,0);analogWrite(pinB,lent)

Pour driver le moteur j'ai commencé par utiliser un pont en H fait maison à partir de transistors de récup puis je suis passé ensuite sur des L298 plus compacts, faut vivre avec son temps. Dans le datashett du L298 il est indiqué qu'avec 00 ou 11 sur les entrées le moteur stoppe avec maintien. C'est de la fumisterie, il n'y a aucun maintien, essais à l'appui dans les deux cas aucune tension sur les sorties donc moteur libre. J'ai été obligé de coder une routine de maintien, si on veut faire bouger l'axe en position stop le moteur rattrape pour compenser, et çà marche super bien, impossible de le bouger à la main.

Dans la vidéo qui suit je commence par faire une POM, puis j'appelle depuis l'interface série des angles de 180,240,270,330,50,80,260, (arbitrairement, on pourrait choisir d'autres valeurs) pour finir par une autre POM. Ça tourne volontairement dans le sens anti-horaire pour des facilités futures de construction du bras. Je n'avais pas de datashett du moteur, alors pour en arriver là il a d'abord fallu faire un petit programme pour trouver le nombre de ticks par tour en sortie de démultiplication, ceci fait j'ai pu travailler sur le code final.
Là c'est des petits moteurs pour bricoler mais ce programme pourrait aussi bien servir pour asservir de gros moteurs de toutes puissance, tant qu'on le commanderait avec des drivers appropriés.
La prochaine étape va être d'appeler les prises d'angle à partir d'un autre arduino par liaison I²C.



Si je vous dit que je m'éclate avec ce truc vous me croirez

Je pense que si t avais commencer par la il y en a beaucoup qui n’aurai pas commander d’arduino  


« Si je vous dit que je m'éclate avec ce truc vous me croirez «  bien sur que oui

Mais continu tu me fait rêver aussi (va vraiment falloir que je débloque du temps)

BOB

Ah non faut surtout pas prendre peur et continuer avec l'arduino, il y a beaucoup de trucs bien plus simples et passionnants à faire. Ne pas prendre exemple sur ce qui vient de m'arriver, c'est un peu un cas extrême, quand on joue avec les champs de bits on n'est déjà plus un débutant et c'est toujours un peu expo si on ne sait pas vraiment ce qu'on fait.

J'aurais très bien pu coder l'asservissement du moteur en langage arduino "simple" et n'aurais pas eu de problème. C'est d'ailleurs ce que j'ai fais pour commencer et puis une fois le programme fonctionnel j'ai optimisé en jouant sur les registres pour remplacer des instructions arduino trop lentes et gagner en vitesse.

Ceci dit l'avantage de l'arduino par rapport à l'electronique ou l'usinage c'est que ce n'est que des lignes de code. Quand çà ne marche plus on n'a pas bousillé de composants, de fraise ou de brut, y'a qu'à chercher l'erreur et modifier le programme.

La petite oscillation au stop qu'on peut constater sur la vidéo à disparue quand j'ai purgé le code de toutes les routines que j'avais rajouté pour debbugger. Çà créait des ralentissements.

bob47 a écrit:

Je pense que si t avais commencer par la il y en a beaucoup qui n’aurai pas commander d’arduino  


« Si je vous dit que je m'éclate avec ce truc vous me croirez «  bien sur que oui

Mais continu tu me fait rêver aussi (va vraiment falloir que je débloque du temps)

BOB

C'est justement ce que j'étais en train de me dire

Le programme est au point, je me suis lancé dans la réalisation des circuits imprimés. Je n'ai pas de double-face dans mes stocks alors j'ai utilisé quelques straps. La carte porte les trois atmégas esclaves pour les 3 moteurs, 1 bouton de POM, toutes les connections avec le bras. L'alim se fait directement en +12v.

Salut

Joli circuit
Est pour la gravure? la CNC?

BOB