Nouvelles:

Bienvenue au Forum de discussion Électro-Bidouilleur! Inscrivez-vous pour participer aux discussions!: 
https://forum.bidouilleur.ca/index.php?action=signup Les demandes d'inscription sont révisées quotidiennement.

Menu principal

BLDC controller without MCU - and BLDC controller hybrid

Démarré par sylvainmahe, Mai 18, 2023, 07:05:34 PM

« précédent - suivant »

sylvainmahe

Bonjour à  vous, la liste des composants nécessaires pour la totalité du contrôleur de moteur (avec mosfet 60V 55A), soit 27,85€ de composants chez E44 en France :


sylvainmahe


sylvainmahe



sylvainmahe

J'ai commencé à préparer la logique pour intégrer quelques fonctions :
- Frein
- Suivi de consigne RPM
- Changement de sens de rotation


sylvainmahe

Le tachymètre sera un LM2907 réglé pour donner 100mV pour 1000 RPM.


loulou31

Bonjour,

Avec 10k 1uF le signal de sortie du capteur de vitesse va être beaucoup trop atténue? La fréquence de coupure va être de l'ordre de 15Hz!


Jean-Louis

sylvainmahe

#22
Bonjour Jean-Louis,

C'est le signal retourné par le LM2907, soit une tension que je pense choisir égale à 100mV pour 1000 RPM. La sortie "TACHOMETER" de mon décodeur rentre dans le LM2907 et il en sort une tension.

Autre point, mon moteur qui est un MN2204 effectue 42 commutations par tour, donc au final pour ce moteur à la sortie du LM2907 je pense choisir 100mV si ma sortie logique oscille à 700Hz, soit 1000 RPM du moteur : (1000×42)÷60

Autre point, je souhaite que ce montage fonctionne avec beaucoup de moteurs disponibles, il en existe des 2200kV (c'est le cas du MN2204), des 300kV, etc... soit des tours par volts donc des RPM max complètement différents.

Le MN2204 avec 12.6V sans charge tourne à environ 27000 RPM, mais il en existe bien d'autres.

Autre point, ce lissage du rattrapage de consigne je pense le faire variable.

Autre point, imaginez que vous êtes à 1% de la consigne utilisateur, ou à 50%, quel lissage faut-il ? Sachant qu'il est dépendant :
Du type de moteur
De sa charge
De la tension d'utilisation
De l'application
De l'effet souhaité
Etc...

Autre point, ce dernier schéma est de principe, je n'ai encore rien calculé. C'est à la louche mais ça répond bien dans le simulateur par rapport à ce que j'imagine pour l'instant.

sylvainmahe

#23
Bonjour à vous tous, je donne suite au projet mais avec deux déclinaisons :
- un circuit sans MCU simple mais fonctionnel, c'est la version présentée.
- un circuit avec MCU pour une gestion du moteur plus élaborée.

J'ai donc poursuivi ces derniers temps en remplaçant tout ce qui n'est pas nécessaire par un MCU, ces derniers jours je travaille sur la partie freinage et inversion du sens de rotation rapidement.

Actuellement je fais des essais de robustesse du code C++ pour l'arrêt et redémarrage d'un Tiger Motor MN2204 avec hélice 6 pouces. Ce n'est pas la meilleure hélice pour ça car elle a une certaine inertie, mais l'arrêt et le redémarrage s'effectuent en 750 ms.

Pour l'instant c'est suffisant sur un avion, mais trop lent pour un quadricoptère, donc je vais travailler mon algorithme pour améliorer ça. Tout est question de non décrochage du moteur dans cette phase critique.

En 750 ms c'est robuste, ça fonctionne à tous les coups.


sylvainmahe

#24
Bonjour, j'ai obtenu des meilleurs résultats :
- lors du freinage pendant 100 ms le moteur vibrait encore en rotation jusqu'au moment de la procédure de redémarrage avec commutation forcée des phases.

La procédure actuelle est la suivante :
1 - freinage.
2 - commutation forcée des phases depuis le dernier endroit connu.
3 - activation du bemf et commutation via les interruptions.
4 - attente à gaz ralenti 100 ms (j'ai vu que ça fiabilisait énormément la procédure).
5 - courbe de rattrapage consigne utilisateur depuis ralenti moteur jusqu'à consigne.
6 - suivi de consigne en boucle.

J'effectuais le freinage en appliquant 40% de la tension d'alimentation au départ de la courbe pour finir à 5% soit le ralenti moteur à la fin de ces 100 ms. En inversant cette logique c'est-à-dire commencer le freinage avec 5% de la tension et finir à l'issue des 100 ms à 40%, le moteur n'a presque plus de vibrations visibles sur l'axe de rotation. Ce qui permet d'engager la procédure forcée de commutation des phases donc de démarrage de façon fiable.

Actuellement après essais qui se poursuivent :
le moteur à vide :
change de sens à tous les coups en 400 ms :
- freinage 100 ms.
- commutation forcée 100 ms.
- attente ralenti moteur 100 ms.
- rattrapage consigne 100 ms.

En faisant un essai de 200 ms (50 ms × 4), c'est très rapide mais il arrive que le moteur décroche.

Il faut s'imaginer au plus critique un moteur qui tourne à 28980 rpm sens horaire et on lui demande de tourner à 28980 rpm sens anti-horaire le tout en 400 ms. 200 ms étant compliqué, ça ne m'étonne pas trop.

Mais je poursuis mes essais afin de voir là où je peux diminuer la durée de la procédure, tout est question de déphasage, d'inertie du rotor, de puissance, de courbes, etc...

Ces réglages sont accessibles dans mon code source via les variables SETUP, j'ai l'habitude de mettre ces variables en fin de déclaration de la totalité des variables afin de permettre aux gens de personnaliser le fonctionnement des algorithmes :

const unsigned int SETUP_TIME_BRAKE = 100;
const unsigned int SETUP_TIME_FORCE_ROTATION = 100;
const unsigned int SETUP_TIME_WAIT = 100;
const unsigned int SETUP_TIME_CATCH_UP = 100;
const unsigned int SETUP_DELAY_FORCE_ROTATION_MIN = 100;
const unsigned int SETUP_DELAY_FORCE_ROTATION_MAX = 1;
const float SETUP_SPEED_BRAKE = 40;
const float SETUP_SPEED_STARTUP = 30;
const float SETUP_SPEED_MIN = 5;
const float SETUP_SPEED_MAX = 100;
const float SETUP_GAIN_SLOWER_MIN = 0;
const float SETUP_GAIN_SLOWER_MAX = 0;
const float SETUP_GAIN_FASTER_MIN = 0;
const float SETUP_GAIN_FASTER_MAX = 0;

sylvainmahe

Ok, j'ai compris à l'aide d'une vidéo de Texas Instruments là où ma séquence a un problème, il faut aligner le rotor deux fois avant de forcer la commutation des phases car sinon le rotor peut être aligné mais inversé, je n'y avait pas pensé.





sylvainmahe

Les résultats sont bons avec ce double alignement :
Sans hélice le moteur change de sens de rotation pour 28980 rpm en seulement 310 ms à tous les coups.

C'est une autre histoire avec l'hélice, j'essaye de voir comment optimiser les paramètres en charge.

sylvainmahe

#27
Bonjour, j'ai gagné beaucoup de stabilité à basse vitesse et lors du changement de sens de rotation du rotor en baissant la valeur des 3 résistances du neutre virtuel de 30k à 10k, et en rajoutant au bout une résistance de 10k tout de même afin de faire le pont diviseur 1÷2 et le bon filtre RC.



Ensuite après de nombreux tests pendant deux semaines avec les interruptions du BEMF avec MCU, je me suis aperçu que rien ne vaut les performances des portes logiques HC pour gérer la commutation des phases du moteur sans interruptions. En plus ça permettra d'être compatible sans faire davantage de recherche avec des vitesses de moteur même supérieures à 28000 rpm, sachant que le MN2204 que j'ai actuellement est très petit déjà avec un bon KV donc très rapide.

Donc le contrôleur de moteur que je développe sera hybride, l'asservissement BEMF vers la commutation des phases sera directe sans MCU pour les performances supérieures, mais la partie freinage, démarrage, et PWM sera faite avec un MCU léger et pas cher.



Je vais peut-être faire une vidéo prochainement pour vous montrer l'inversion de sens de rotation avec MCU.

sylvainmahe

#28
Bonjour, aujourd'hui j'ai commencé à dessiner la carte prototype de ce principe hybride : portes logiques série HC pour la boucle de rétroaction et MCU pour la gestion.

L'idée est d'avoir pour cette boucle de rétroaction la vitesse la plus élevée et stable quel que soit le MCU utilisé. L'addition moyenne des durées de propagation du comparateur vers les portes logiques vers les pilotes de mosfet donne comme résultat 315ns soit plus de 3MHz.




En entrée le pilotage pourra être fait avec :
- Le protocole usart.
- Un pwm.
- Un potentiomètre et un interrupteur de coupure moteur.

J'ai placé trois ponts qui peuvent être fermés par brasure pour sélectionner ça. J'ai aussi pensé à détecter automatiquement ce qui rentre mais je préfère une sélection en dur finalement.

sylvainmahe

#29
La carte proto juste pour valider le concept hybride de contrôleur de moteur triphasé synchrone avec MCU pour la gestion et freinages/alignements/démarrages et portes logiques 74HC pour la boucle de rétroaction avec BEMF.