Gopro Brushless Gimbal / Nacelle stabilisée

[Bordaste]

Bonjour à tous!

je ressort ce topic car j'ai depuis quelque temps le projet de me fabriquer un guimbal pour ma Gopro, et éventuellement pour un Reflex.

Je ne pense pas qu'un modèle avec servomoteur soit un réel bonne idée.. On contrôle un servo en position angulaire, donc si le capteur est un gyro, on devra intégrer le signal pour pouvoir piloter le moteur. Et de se que j'en sais, intégrer si on veut un truc stable et sans dérive, c'est mal.

Un autre idée serait d'utiliser un accéléromètre pour avoir directement une position angulaire par rapport au sol. Mais dans ce cas, l'utilisation du stabilisateur au ski, par exemple, me semble compromise.

Je ne vois alors plus qu'une seul solution viable: gyro + brushless. Comme ça on mesure une vitesse angulaire, pour asservir une vitesse angulaire. En theorie, moins de traitement a faire du coup.

Je retiens donc ça pour l'instant.

Comment piloter le brushless?

il y a 2 possibilté:
_utiliser un driver, oui, mais lequel?

les driver de modelisme type:
http://fr.aliexpress.com/item/30A-Br...451318400_6151
Mais avec ça je ne vois absolument pas comment inverser le sens de rotation avec le µC..

Donc j'ai regardé ça:
http://www.ti.com/product/drv10963
Mais là c'est la datasheet que je ne comprend pas! selon eu, l'amplitude de sortie dépend du duty cycle de la pwm d'entré, or j'aurais plutôt vu un influence sur la fréquence, pour une amplitude fixe...

_Créer soit même les 3 phases avec le µC.
Grace a la datasheet du driver de ti, ( et mes anciens cours d'electrotech aussi ) je peut m'inspirer pour générer les 3 phases. Il y a un dessin a la page 8 de la datasheet. En résumé, générer 3 PWM pour simuler des signaux sinusoïdaux entre phases.
Autre problème, comment gérer l’arrêt? en effet les moteur ne seront pas en permanence en rotation, et je ne vois pas trop comment verrouiller la position du moteur lorsque l'axe n'est pas parfaitement aligné avec une paire de bobine..


Donc voila: je vois plusieurs pistes de réflexion, mais il y a plein de questions auquel je n'ai pas de reponse. Merci de m'apporter un peu d'aide!
-----

[jiherve]

Bonjour,
Je ne vois pas trop comment l'usage d'un brushless peut être un plus pour cette application sauf à imaginer que dans ton langage brushless = pas à pas.

Si c'est le cas alors les drivers du commerce ont tout ce qu'il faut pour assurer le changement de sens et maintenir un petit couple à l’arrêt.
Fais donc une recherche avec "stepping motor controler" et cela ira mieux.
JR

[Bordaste]

Je suis d'accord pour dire que en prime abord les steppers on l'air parfait! Contrôle simple, couple résistant en permanence..

Mais la plupart des personne qui parle de Gimbal DIY sur internet arrivent a la même conclusion: un moteur pas à pas ne convient pas vraiment pour cette application.
une vidéo en exemple: https://www.youtube.com/watch?v=0ALNKv2VYwE

Si tu connais un projet de Gimbal fonctionnant avec des steppers, avec des résultats satisfaisant, alors je suis aux anges!

Ce que j'entend par moteur brushless c'est un moteur triphasé synchrone. Ce genre de chose: http://rctimer.com/product-575.html
J'ai un peu de mal avec les dénomination des moteurs.. J'ai l'impression que tout n'est pas normés. Si je dis des conneries, arrêtez moi! ^^


Pour ce qui est des plus du brushless:
Facile a piloter en vitesse angulaire, car a priori l'axe suit le signal (synchro).
Pas d’intégration (au sens mathématique) a faire pour piloter le moteur en vitesse, contrairement au pas à pas, qui par définition sera piloté en position.
Plus rapide, ce qui permet une meilleur réactivité du stabilisateur.

Sinon pour ce qui est du capteur, je pensais a un MPU 6050.. Je ne sais pas vraiment ce qu'il vaut, mais j'ai déjà vu un gimbal fonctionner avec ce capteur. Il a quand même l'avantage d’intégrer un accelero (dont je pense pouvoir me servir de référence absolu), et surtout, de ne pas couter grand chose

Si quiconque a une expérience avec ce type de projet, ça serait sympa de partager les moteurs, capteurs, drivers, µC que vous avez utilisé!

[crokrodil]

De mon coté je travaille aussi sur un stabilisateur de ce genre.

Faute de temps à dédier à ce projet je ne suis pas très avancé pour le moment mais voila mes idées :

- Utilisation d'un DSP "optimisé" pour le contrôle de moteur (d'après Microchip) : dsPIC33EP512MU810 (choix personnel, vu le nombre d'I/O, le nombre de periph et la fréquence, je me dis qu'il pourra me permettre de répondre à tous mes développements ou presque), et j'ai aussi un STM32F3 (F3-Discovery board) qui pourra largement faire l'affaire (il a aussi un DSP, des timers 16 et 32 bits, PWM...)

- Utiliser un accéléro ou gyro en SPI (là aussi c'est un choix perso, de l'analogique ça peut très bien aller aussi). Je n'ai pas encore fait le choix entre gyro, accéléro ou mix des deux.

- Utilisation de moteurs DC commandés par PWM. j'ai pas la référence en tête mais ceux que j'ai sont des petits Maxxon, ça coute une blinde mais pour cet usage il faut des moteurs performants (et ils me servent sur un autre projet aussi).
Bin sur il existe d'autres moteurs avec certainement des caractéristiques similaires : Ils ont une très bonne dynamique, un bon couple, ils ont un rotor "ironless", c'est à dire sans structure ferromagnétique, donc pas de points d'arrêts gênants. Ils consomment rien, à vide ils commencent à tourner autour de 1,2V et 10 à 15 mA, et il commence à y avoir du couple à partir de 2,5 - 2,7V, du coup pour de l'embarqué avec une Li-Po de 3,7V c'est impec.

- Asservissement par encodeur magnétique (magnetic rotary encoder), Austria Microsystems a de très bons capteurs, avec plusieurs types d'interfaçages. Pour ma part je préfère la communication SPI mais là encore c'est un choix personnel, l'avantage c'est qu'il n'y a pas de contact, donc pas d'effort contrairement à un potentiomètre. Je pense qu'un capteur optique ou capacitif pourrait aussi répondre aux besoins.

Concernant les moteurs brushless, je ne sais pas ce que tu comptes utiliser mais ça ne me semble pas une bonne idée : en général ce sont des moteurs triphasés (en tout cas ceux de modelismes), donc plus complexe à commander. En plus de ça ils ont un noyau en fer, du coup l'arrêt du moteur se fait forcément sur un de ces pôles, ce qui peut entrainer une erreur de position, ce qui n'est pas négligeable. Et enfin, ce sont des moteurs faits pour de la vitesse (rotor de drone, voiture RC, entrainement du plateau de disque dur...) et n'ont pas une bonne dynamique pour de l'asservissement en position sur une faible course et avec des changements de sens de rotation successifs. Et mine de rien ça consomme...

J'espère avoir pu t'aider un peu sur les choix techno pour la partie asserv par contre je ne peux pas t'aider, j'ai encore rien modéliser ni même fait un bout de code...

[A voir en vidéo sur Futura]

[Bordaste]

Merci de ta réponse!

C'est vrai que je n'ai même pas parlé du type de µC que je comptais utiliser.. Je possède déjà un arduino, ce qui me permettras de faire les premier test. J'aime bien ton DSP pas trop chère, et pas mal de possibilité. (ps: le jeux de mots DSPic est tres bon ) 16 bits doit être un minimum.. A voir.

Je pense faire comme toi, tout en SPI ou I²C, ça reste plus simple..

Pour ce qui est des moteurs:
Je pense que tu as mis le doigt sur mon dilemme! Les moteur DC ont plein d'avantage, mais celons certain forum, les chinoiserie soit a prohibée. Pour ce qui est des autres c'est leur prix qui me pose problème.. A plus de 80€ par moteur, ça fait vite chère quand il en faut 3 ^^

Pour répondre à tes hésitation envers les brushless:
Je suis conscient de la complexité du triphasé.
C'est vrai que j'avais pas spécialement pensé a la différence de conso.. A voir
Je pense que leur faible précision sur des faible courses provient surtout de la façon de les commander.(plus de détails en dessous)
L’arrêt du moteur moteur sur un pole n'est peut être pas obligatoire, je m'explique:

imaginons une tension max=5V (je met n'importe quoi comme chiffre, c'est pour le principe.)
la commande utilisé dans la plus part des modèles réduit revient a appliquer cette tension max sur chacun pole dans l'ordre, puis cette tension en inverse sur chacun des pole dans le même ordre. On attire alors le ferromagnétique successivement sur chacun des pôles. C'est du moins ce que j'ai compris.
Maintenant si on imagine un système pouvant repartir cette tension max entre deux pôle, analogiquement (réellement, ou par PWM suffisamment rapide par rapport a la rotation) on a alors la possibilité de faire varié l'angle avec une précision a priori indépendante du moteur, simplement fonction de notre systèmes.

Si je suis autant buté sur les brushless, c'est avant tout car j'ai fait la constatation que tout les Gimbal pro sont motorisé par des Brushless.. Et que je ne suis pas encore tombé sur autre chose que des brushless parmi les Gimbal home made. Je me trompe peut être!

Je me rend compte de l'usine a gaz que je suis en train d'imaginer, mais j'ai vraiment peur de tomber sur des problèmes non solvable autrement, et je ne trouve pas de driver pour brushless utilisable dans ma situation ..

Tu soulève une autre question intéressante: Je pensais pas avoir besoins d'un autre capteur que le gyro pour régler mon asservissement.. J'imaginais surement faire ça directement en boucle fermé.

Voila, Merci de participer en tout cas!

[jiherve]

Bonsoir,
bon j'ai compris ton pb, en effet si tu veux un truc aussi reactif il faut passer par du brutal ,en fait cela revient effectivement à envoyer la bonne tension sur les 3 enroulements, ce qui se faisait avec les vieux synchro afficheurs. Il te faudra donc 3PWM indépendantes mais évidemment synchrones par moteur(3 phases) , le sens de rotation dépend du sens de rotation des phase.
ici bien mieux que je ne saurais l'écrire :http://www.instructables.com/id/Brus...-with-Arduino/
JR

[crokrodil]

C'est vrai que je n'ai même pas parlé du type de µC que je comptais utiliser.. Je possède déjà un arduino, ce qui me permettras de faire les premier test. J'aime bien ton DSP pas trop chère, et pas mal de possibilité. (ps: le jeux de mots DSPic est tres bon ) 16 bits doit être un minimum.. A voir.

L'arduino je suis pas trop fan (surtout le langage, trop haut-niveau pour certaines applications, c'est bien pour débuter mais il faut vite passer au C ou C++, avec la gestion des registres...) mais effectivement pour mettre en place un petit algo ça devrait être suffisant. L'avantage du DSP par rapport aux uC c'est l'architecture interne pour la rapidité de calcul. Je sais même pas si ce serait nécessaire pour un asserv comme celui là.
16 bits (et 32 bits pour le STM32) sont effectivement suffisant, il faut surtout une taille de RAM conséquente. Là encore c'est que par rapport à l'architecture interne, tu peux manipuler des variables 64 bits sur un uC 8 bits, c'est juste que tu vas consommer plus de RAM et plus de temps d'execution

Je pense faire comme toi, tout en SPI ou I²C, ça reste plus simple.

Oui en général le SPI ça marche bien, c'est rapide. l'I²C je trouve ça un peu plus chiant à mettre en oeuvre mais ça marche pas trop mal non plus. Dans les deux cas tu esquives la mise en forme du signal analogique.

Pour répondre à tes hésitation envers les brushless:
Je suis conscient de la complexité du triphasé.
C'est vrai que j'avais pas spécialement pensé a la différence de conso.. A voir
Je pense que leur faible précision sur des faible courses provient surtout de la façon de les commander.(plus de détails en dessous)
L’arrêt du moteur moteur sur un pole n'est peut être pas obligatoire, je m'explique:

imaginons une tension max=5V (je met n'importe quoi comme chiffre, c'est pour le principe.)
la commande utilisé dans la plus part des modèles réduit revient a appliquer cette tension max sur chacun pole dans l'ordre, puis cette tension en inverse sur chacun des pole dans le même ordre. On attire alors le ferromagnétique successivement sur chacun des pôles. C'est du moins ce que j'ai compris.
Maintenant si on imagine un système pouvant repartir cette tension max entre deux pôle, analogiquement (réellement, ou par PWM suffisamment rapide par rapport a la rotation) on a alors la possibilité de faire varié l'angle avec une précision a priori indépendante du moteur, simplement fonction de notre systèmes.

Je ne me suis pas penché sur les trucs existants donc certes un moteur brushless peut convenir, mais tu vas rencontrer plusieurs problèmes :
- ton moteur, contrairement à un moteur pas-à-pas bipolaire, possède 3 phases. Pour la commande analogique "entre deux pas" il va falloir connaitre en temps réel les deux phases entre lesquelles tu te trouves pour jouer sur tes deux modulations (PWM ou analogique), et dans le cas d'un changement de phase (rotation supérieure à l'angle entre tes deux phases précédentes) il faudra anticiper l'alimentation de la troisième phase et couper la première (en gros passer de ton angle P1-P2 à P2-P3, ou P3-P1 selon le sens de rotation, et cela de manière fluide).
Avec un moteur DC tu ne te poses pas la question, tu alimentes dans un sens ou dans l'autre, et la rotation se fait toute seule.

- point de vue conso, à vrai dire ça dépend des moteurs. Dans le meilleur des mondes, avec un moteur DC, si tu es en position et que ton maintien mécanique est correcte, tu coupes le jus : conso 0 (bon en pratique tu vas toujours devoir compenser un peu dans un sens et dans l'autre). Avec ton brushless tu seras toujours obligé de maintenir ta position si tu veux pas que le moteur se bloque sur un pole. en plus de ça, plus tu es proche d'un des pôles, plus il faut un courant important pour lutter contre l'attirance de ce pôle.

- un moteur brushless comme tu l'as dit c'est un peu galère à alimenter mais faisable, il te faut 3 push-pull (half-bridge) et 3 PWM. chez Texas Instruments et ST Microelectronics (pour ne citer qu'eux) tu devrais pouvoir trouver ce genre de driver. Pour le moteur DC il faut seulement 2 push-pull, 1 PWM et un bit de sens, ou 2 PWM (attention à la synchro).

Tu soulève une autre question intéressante: Je pensais pas avoir besoins d'un autre capteur que le gyro pour régler mon asservissement.. J'imaginais surement faire ça directement en boucle fermé.

En fait c'est surtout un complément et je pense que l'on peut s'en passer, mais c'est surtout dans le cas où tu veux faire une rotation de camera volontaire (genre panoramique) tu peux te servir de ça pour faire un mouvement fluide, gérer la vitesse, etc.

Je me rend compte de l'usine a gaz que je suis en train d'imaginer, mais j'ai vraiment peur de tomber sur des problèmes non solvable autrement, et je ne trouve pas de driver pour brushless utilisable dans ma situation

Problème non-solvable je ne pense pas, le seul gros problème que je vois c'est au point de vue dimensionnement méca : si ton moteur n'a pas assez de couple pour déplacer ton système l'asservissement n'y pourra rien, mais sinon il y a toujours moyen de faire un truc plus ou moins précis, avec des temps de réponse plus ou moins longs.

Après en ce qui concerne l'approche de modélisation pour la partie asservissement, je ne connais pas ton niveau en automatisme, mais il y a quelques trucs simples pour les réglages des correcteurs PID/PI/PD. Déjà connaitre l'avantage de chacun pour choisir le plus approprié. Ensuite pour les réglages des coefficients je fais en général la méthode d'essai/erreur en réponse à un échelon, réglage du Proportionnel jusqu'à oscillation/pseudo-oscillation, puis réglage de l'Intégrateur pour avoir un bon amortissement avec un dépassement négligeable et une compensation de l'erreur statique, et ensuite réglage du Dérivateur... jusqu'à avoir un système qui a un temps de réponse satisfaisant avec peu d'oscillations et une erreur statique négligeable voire inexistante je te laisse jeter un œil ici (les premieres pages trouvées par google parmis tant d'autre) http://www.ferdinandpiette.com/blog/...re-de-calculs/
https://fr.wikipedia.org/wiki/R%C3%A9gulateur_PID

Voila, Merci de participer en tout cas!

Mais de rien!

Crok'

[Bordaste]

L'arduino je suis pas trop fan (surtout le langage, trop haut-niveau pour certaines applications, c'est bien pour débuter mais il faut vite passer au C ou C++, avec la gestion des registres...) mais effectivement pour mettre en place un petit algo ça devrait être suffisant. L'avantage du DSP par rapport aux uC c'est l'architecture interne pour la rapidité de calcul. Je sais même pas si ce serait nécessaire pour un asserv comme celui là.
16 bits (et 32 bits pour le STM32) sont effectivement suffisant, il faut surtout une taille de RAM conséquente. Là encore c'est que par rapport à l'architecture interne, tu peux manipuler des variables 64 bits sur un uC 8 bits, c'est juste que tu vas consommer plus de RAM (plus d'instruction plutot nan? ^^) et plus de temps d’exécution

Oui pour le coup je suis bien d’accord, je me suis déjà arraché des cheveux pour ça.. Mais grâce à Jiherve je suis tombé la dessus: http://www.instructables.com/id/DIY-...uino/?ALLSTEPS
Comme quoi, pas impossible de tout faire la dessus.
L’idéal finalement je pense que c'est plus un FPGA qu'autre chose.. Vu le nombre de PWM synchrones a générer (9 quand même pour 3 axes...)
Mais je suis pas sur de vouloir faire du FPGA ^^

Sinon au tout début du topic je mettais ça: http://www.ti.com/lit/ds/symlink/drv10963.pdf histoire d'avoir un composant qui premache le travail.

lorsque j'ai vu la figure 2 (page 8) je me suis tout de suite dit que c’était ce qu'il me fallait. Mais en regardant la figure 3, je ne comprend plus rien... Selon la doc le rapport cyclique de la PWM d'entrée défini l'amplitude max de la moyenne de la séquence des PWM de sortie. Mais je ne vois pas en quoi cela permet de contrôler la vitesse du moteur Le couple peut être, mais la vitesse, je comprend pas.
Du coup je pense pas que ce compo puisse m'aider.. Je vais essayé d'en trouver des similaires.

Problème non-solvable je ne pense pas, le seul gros problème que je vois c'est au point de vue dimensionnement méca : si ton moteur n'a pas assez de couple pour déplacer ton système l'asservissement n'y pourra rien, mais sinon il y a toujours moyen de faire un truc plus ou moins précis, avec des temps de réponse plus ou moins longs.

Justement c'est ce que je voulais dire par non solvable c'es a dire arrivé a un point on je ne pourrais plus optimiser avec mon matériel. Pour que ce bricolage reste "rentable" j'ai pas 32 essais ^^

Après en ce qui concerne l'approche de modélisation pour la partie asservissement, je ne connais pas ton niveau en automatisme

J'ai un niveau sortie de DUT GEII, c'est a dire solide notion en aserv analogique, et un peu moins solide (mais ça va quand même ^^) en discret.

J'ai pris note du reste de tes explication

Au plaisir!

[jiherve]

Re
effectivement le composant TI n'est fait que pour controler en vitesse. Compte tenu du prix d'un µC de chez n'importe qui tu peux en utiliser plusieurs.
JR