Moteur Direct Drive

[willoubu44 48]

Bonjour,

j'ai trouvé il y a quelque temps de cela un document sur le site concernant la solution direct drive. "Motorisation Direct Drive pour nos télescopes" par C.Cavadore
C'était fort intéressant et du coup je me suis mis à explorer les détails.

Je présume que le moteur est contrôlé par un signale SVPWM mais sur combien de bit ? Sur 8 bits cela ne donne que 254 niveaux possibles. Même sur un moteur avec 24 bobines, la résolution reste assez basse pour suivre le codeur.

On parle de codeur Sincos dans le document, Celui ci ne peut pas avoir déjà une erreur périodique ? Je pensais que seul les codeurs absolue était exploitable pour cette solution.

Voilà, si vous avez des liens ou explications intéressantes la dessus je suis preneur.

Merci

William

[Kepler 67 0]

"Sur 8 bits cela ne donne que 254 niveaux possibles"

256 pour être exact = [0-255]
L'avantage du direct drive, c'est qu'il n'y a pas d'erreur périodique (EP). L'EP est générée par des systèmes mécaniques de type roue + vis sans fin.

Sinon j'ai trouvé un lien sur le direct drive (? le même que le tien) : http://www.astrosurf.com/luxorion/Illustrations/moteur-direct-drive.pdf

Kepler 67

[Ce message a été modifié par Kepler 67 (Édité le 12-08-2016).]

[willoubu44 48]

Salut,

Oui c'est le document que j'ai lu.

En fait les états 0 et 255 ne sont pas utilisés.
Je connais bien les intérêts du direct drive, maintenant j'essais de comprendre quels types de signaux sont utilisés pour piloter les moteurs.

Faire tourner un moteur Brushless rapidement c'est très simple.
Le faire tourner très lentement (1 tour en 24h) ça semble un peu plus compliqué.

[higgins 104]

bonjour à tous, j'ai bossé sur des moteurs brushless industriels qui sont les mêmes que ceux des direct drive mais en plus gros. Il n'y a pas de problème à les faire tourner à 1 tour en 24h.
les codeurs utilisés dans ces moteurs sont des sin/cos a un peu plus de 1 millions de pas par tour!
avantages de ces moteurs: le variateur ou l'électronique associé, calcule en permanence la position ou doit être l'arbre du moteur, donc même avec un fort vent, la monture ne bouge pas d'un pouce et suis tranquillement l'objet.
pas de mécanique, donc pas d'ep à corriger!

inconvénient: pour ceux que j'ai utilisé, électronique imposante et nécessité de développer du programme pour un goto par exemple.

Je vais dans peu de temps récupérer un moteur et un contrôleur à mon boulot (matériel obsolète) en vue de bricoler un prototype de monture dont la capacité de charge sera énorme (moteur industriel oblige)
voilà, a +

[willoubu44 48]

Salut,

alors justement, ma question porte la dessus. Comment le faire tourner lentement ?
Avec un signale en SVPWM ou SPWM mais sur quel résolution et fréquence ?

J'ai bien compris que la roue codeuse était essentiel pour l'asservissement (vitesse de rotation et Goto) mais il faut pouvoir généré un mouvement de rotation qui soit en adéquation avec la résolution de la roue codeuse.

A 1 million de pas par tour, le mouvement est infime. D’où ma question sur la résolution du signal qui pilote le moteur.

A t'on affaire à un bobinage type par paire de phases inversée (AaBbCc...) ou plutôt (ABC....) ?

William

[willoubu44 48]

salut higgins,

as tu avancé sur ton essai de moteur bldc ?

De mon coté, je suis en carafe sur le PID.

J'ai fabriqué un moteur avec 16 poles.
je le pilote avec un arduino Due et un driver pour moteur BLDC (L6234).

Pour faire varier la vitesse je fais varier la fréquence de ma boucle qui applique les tensions (PWM à 20khz) en déphasage sur les trois phases.

j'ai 4096 valeurs possibles sur 3 phases pour réaliser les 360°.

J'arrive à un mouvement très lent genre un tour en 8h.

Comment fais tu varier la vitesse de tes moteurs en industrie ? est ce la même méthode.

Sinon à titre expérimental j'ai installé une roue codeuse sur l'axe qui fait 2400 tick par tour(je sais on es loin de la précision recherchée mais c'est à titre expérimental).

Et la je galère avec le PID. Faire varier la fréquence de cette boucle en fonction du nombre de tick effectué toutes les 100ms par exemple me fait gigoter le moteur dans tous les sens.
C'est pour cela que je me demande si je suis sur la bonne voie.

A+

William

[olivdeso 1 860]

pas compris la variation de fréquence : PWM ou PFM ?

Un article qui peut t'interesser:
http://www.berryjam.eu/2015/04/driving-bldc-gimbals-at-super-slow-speeds-with-arduino/

[Ce message a été modifié par olivdeso (Édité le 21-09-2016).]

[willoubu44 48]

salut

le pwm ne change pas il est fixé à 20khz.

Le lien que tu indiques est le point de départ que j'ai utilisé.. :-)

donc en effet pour faire varier la vitesse du moteur je modifie la fréquence de la boucle Delay (pfm)

Mon interrogation était la dessus. Est la bonne méthode pour faire varier la vitesse car en effet ça fonctionne mais pour le PID je galère.

william

[Ce message a été modifié par willoubu44 (Édité le 21-09-2016).]

[olivdeso 1 860]

c'est deux choses différentes

- soit tu commande en vitesse de rotation
- soit tu commande en position

je me demande si tu ne mélanges pas les 2

Donc évidement le PID n'est pas le même dans les 2 cas, la vitesse étant la dérivée de la position.

Inversement la position est l'intégrale de la vitesse.

Si tu commandes en position :

dans l'ordre

- tu défini un vecteur de position
- tu l'applique au PID
- le PID se charge de l'asservissement en position et effectuer automatiquement la rotation vers le bon point

Evidemment, outre le réglage du PID, tu peux jouer sur la vitesse max de déplacement ou le nombre max de pas.

Si tu commandes en vitesse, la consigne sera la vitesse et pas le vecteur de position (i.e. ta fréquence de pas à pas, pour passer d'un vecteur de position au suivant)

Dans ce cas ton PID sera

D = accélération
I = position
P = vitesse

avec chacun son coef à régler.

Le problème avec ce système, va être la précision du codeur. Si ça tourne super lentement et que tu as très peu de pas, ça ne va jamais marcher.

Il va falloir faire un asservissement en vitesse différent.
Un truc simple peu être une moyenne pondéré des vitesse des précédents pas de codeurs (une sorte de filtre passe bas).

Avec 2400 pas et 8h de rotation (il faudra viser 24h), ça fait un pas toutes les 12s. Donc évidement une correction possible toutes les 12s.

[willoubu44 48]

Salut,

Merci pour tes infos.

Pour l'instant je ne travaille que sur l'asservissement en vitesse et non en position.

La roue codeuse que j'utilise est à titre expérimental, je sais bien que je ne ferais pas grand chose de plus avec. D'ailleurs mon objectif était d'obtenir une vitesse moteur de 33.3 T/m.

J'ai enfin réussi hier à le faire fonctionner correctement. J'ai une vitesse constante sans trop d'oscillation autour de la consigne.

La prochaine étape est de faire le même System avec une roue codeuse absolue utilisant le protocole SSI.
Mon idée est de convertir le code binaire en une valeur décimal pour la mesure de vitesse.

J'y vais pas à pas pour mesurer mes limites avant d'investir dans une roue codeuse type BiSS-c en 26bits qui coute juste un bras et une jambe :-)

[Ce message a été modifié par willoubu44 (Édité le 22-09-2016).]

[olivdeso 1 860]

OK.

Pour moi il vaut mieux asservir en position.

C'est ce qui te servira au goto entre autre.

Puis tu ajoute une vitesse sidérale là dessus sur l'axe AD. i.e. tu va changer de position l'axe AD n fois par seconde au rythme de la vitesse sidérale.

[willoubu44 48]

Ok ! Compris.

Ta remarque m'avait justement orienté la dessus.

L’intérêt en plus est que je pourrais mettre tout ça dans dans une fonction à part, appelée par un timer qui serait plus précis que le le delay d'une fonction en boucle.

J'ai trouvé un codeur absolu 15 bits SSI sur Ebay aux US pour faire mes testes à 40 dollars. Bon y'en a pour autant en frais de port...

Je passerai à un mouvement tick toutes les 2.6 secondes :-)

William

[olivdeso 1 860]

au fait ton codeur actuel est purement numérique? par de possibilité de sortie analogique? car tu pourrais gagner en précision.

[willoubu44 48]

oui c'est un codeur en quadrature tout simple.

[willoubu44 48]

Salut,

L'asservissement en position fonctionne bien avec la roue codeuse.

Je peux fixer la vitesse max et le ralentissement quand on atteint la consigne se fait en fonction du coeff P. (Proportionnalité) Par contre il me faudra autre chose pour l'accélération.

J'ai reçu la roue codeuse absolue et j'attends le transceiver RS485 que j'ai commandé pour gérer le protocole SSI de la roue codeuse.

Pour réutiliser mon code actuel je compte faire une conversion Grey => Binaire => Décimal.

J'utilise une carte Arduino DUE à 84Mhz donc ça devrait pas trop impacter.
Si c'est le cas je peux toujours faire une interface complète avec une Arduino Micro et envoyer le résultat toujours en port Série sur l'Arduino DUE.

Après que la roue codeuse soit en 15 bits ou 26 bits, le code restera le même.

William

[willoubu44 48]

Salut à tous.

Depuis Novembre 2016 je n'ai pas relâché mes efforts malgré une maison entière à rénover. (On a gardé 4 murs en pierres...) mais ça cela a payé !

Voilà ou j'en suis.

Coté Electronique j'utilise une roue codeuse absolue sur 15 bits avec le protocole SSI. Ça fonctionne bien, j'ai un asservissement en position avec une consigne qui change via un timer en fonction de la résolution du codeur. (1 pas / 2.7 seconde pour la vitesse sidéral) Je sais la résolution est de l'ordre de 35" d'arc mais c'est pour tester. J’ai un autre timer qui vérifie la consigne et corrige la position 1500 fois par seconde. Je peux changer la consigne pour le Goto et tous autres mouvements.

Il faut que je fabrique une carte de puissance similaire à celle que j'utilise pour mes tests (L6234) mais pour driver un moteur plus gros (là je suis limité à 2.5 ampères). En fait il faut qu’une sortie à l’état bas soit reliée à la masse et non pas en l’air.
J'ai trouvé un moteur pour l'axe RA qui est pas mal, celui d'un lave-linge Direct Drive. 36 bobines, 48 pôles, mais vu la taille du file utilisé il faut du courant...
Si vous avez d'autre moteur à me recommander je suis preneur (de préférence des moteurs qu'un particulier puisse acheter :-)
J’ai presque terminé le driver Ascom. J’ai fait mes tests avec CDC et un arduino qui simule le déplacement du télescope et ça fonctionne impeccable. J’ai fait une petite interface qui renvoie quelques infos venant du télescope et j’ai inclue les fonctions de Goto, Tracking, Synchronisation, Home et retour Home. Il me reste le déplacement manuel à faire.

En fait toute l’intelligence de la monture est dans le driver, l’arduino ne gère que la lecture des roues codeuse et l’envoie du signal SPWM au moteur. Le driver lit la position des roues codeuses toutes les 500ms et envoie une consigne si besoin (Goto ou flèche de direction).
Voilà, en gros il me reste la carte de puissance, Structure de la monture et me procurer les roues codeuses en SSI qui vont bien.
Pour l’axe DEC, une roue 20 bits devrait faire l’affaire, 1 sec/arc de résolution.
Pour l’axe RA c’est une autre histoire… il me faut une RC de 24 bits minimum. Il faut que je trouve un fournisseur qui accepte de m’en vendre avec un prix pas trop délirant…

William

[Chris277 581]

Cool que tu ais poursuivi ce défis techno! bravo William!
Christophe

[willoubu44 48]

Merci Chris

C'est pas évident car peu de temps à y consacrer...

Si certain on des références de moteur à me donner je suis preneur.

[ngc_7000 125]

Je maitrise mal le sujet , mais un moteur de machine a laver , n'est pas une bonne base ?
http://moustachedor.free.fr/lg/problemes.htm

[Ce message a été modifié par ngc_7000 (Édité le 18-06-2017).]

[jmpg86 43]

Super Willoubu44 que tu persistes, c'est l'avenir pour les bricoleurs, le présent pour les pro, il ne peut pas y avoir de meilleur système d'entrainement, sauf pour la consommation qui reste conséquente.

[Laurent51 2 787]

Même pas... la consommation d'une moteur directdrive est bien inférieur a une motorisation du type moteur pas a pas par exemple... surtout quand la monture est en guidage. Le courant montera un peut en pointage, surtout si vous demander des accélérations tres fortes.

Laurent Bernasconi

[jmpg86 43]

Ah au temps pour moi, je croyais qu'elles consommaient largement plus d'un ampère sous 12V en guidage.

[Laurent51 2 787]

En faite, ca consomme simplement le courant qu'a besoin le moteur pour tenir la consigne. Donc, avec un télescope équilibré, il n'y a pas besoin de beaucoup de puissance. c'est seulement en phase de pointage que le courant va augmenter.

Laurent Bernasconi

[willoubu44 48]

Salut !

Alors oui en effet j'ai déjà fait l'acquisition d'un moteur de machine à laver qui est idéal pour l'axe AD. Il y a 36 bobines pour 48 aimants ! Le couple est parfait.

Selon moi le moteur direct drive consomme plus. Pour avoir du couple sachant qu'il n'y a pas de démultiplication, il faut du courant...
Je n'ai pas encore pu tester avec le moteur de machine à laver. Je rénove ma maison et c'est horriblement long !

Par contre j'ai terminé le driver Ascom ! Il manque deux ou trois options comme le Park ou l’arrêt d'urgence mais le Goto, Sync, et le Pad de contrôle sont opérationnels !

J'ai fait mes tests sur CDC avec un Arduino qui émule la monture et ça fonctionne.

Je cherche un plus petit moteur pour l'axe de déclinaison. Je ferai une monture de type fourche sur une table équatoriale.
Je pensais à un moteur de Vélo Electrique qui est aussi de typo "Out-runner" avec un bon couple.

Je posterai une petite image de l'interface de controle.

William

[willoubu44 48]

Bonjour,

J'étais un peu pressé avant d'envoyer mon message la dernière fois et donc je ne me suis pas trop étalé sur le sujet mais je voulais revenir sur le sujet du courant nécessaire pour ce type d'entrainement.

En fait il ne doit pas être négligé. Plus on a de courant et donc de couple, plus le suivi sera de qualité.

En fait il faut imaginer le fonctionnement comme celui des micros pas d'un moteur pas à pas. On maintien en équilibre la position d'un aiment entre le champ magnétique de deux bobines.

Sauf que pour atteindre une résolution suffisante on utilise un PWM (sur 12 bits pour ma part) sur chaque ensemble de bobines (couplés par trois). On transforme en gros un signal carré en une valeur analogique. les changements sur de cette valeur analogique étant infime, il faut que la position soit bien maintenu en fonction de cette valeur.

Donc si le couple n'est pas assez important, on risque de "sauter des pas".
Ou alors la moindre brise peut faire osciller le télescope.

En effet, il faut que le système soit extrêmement bien équilibré.
On préconise un petit déséquilibre sur les montures classique pour limiter les effets du jeu mécanique mais la il ne faut pas.

Le fonctionnement fait que la consommation de courant est toujours la même. Que l'on soit en vitesse sidérale ou en Goto.

Je pourrais limiter le courant en désactivant une phase qui n'est pas utilisée. En fait on a trois phases décalées de 120° mais seules deux sont réellement utilisées en même temps. Je garde la troisième alimentée par simplicité de fonctionnement.

J'espère que mon explication est compréhensible :-)

William