Performances d'une carte Arduino

[invite1847dfac]

Bonjour à tous,

Je suis un étudiant en ingénierie, et je travaille actuellement sur un projet de motorisation électrique.

Calculs et dimensionnements faits, je vais alimenter deux moteurs à courant continu en PWM via des ponts en H.

Le contrôle en vitesse des roues ne protège pas le convertisseur de l'overshoot de courant, ce qui m'amène à mettre en place une solution de régulation de courant en cascade dans la boucle de vitesse, pour ce qui est du contrôle.

Les questions arrivent maintenant, pour des raisons de temps (très court) et de budget (plus que limité), la meilleure solution de support semble être Arduino.

Si on fait le décompte des choses à gérer, on a:

1) une commande de commutation commune aux deux drivers que je souhaite fixer à 20kHz, produite par l'Arduino (pas par la PWM usuelle qui ne dépasse pas les 500 Hz)

2)Deux boucles PI(D) pour contrôler le courant, à une fréquence de 10kHZ (temps bien inférieur à la constante électrique des moteurs...). La boucle de courant consiste à lire les valeurs des capteurs de courant, à mettre à jour les variables du PI(D) en tenant compte de la consigne, à calculer la nouvelle valeur de rapport cyclique et à l'insérer dans la commande de commutation.

3)Deux boucles PID pour contrôler la vitesse, à une fréquence entre 100H 1kHz. Il s'agit également de lire la valeur du capteur de vitesse (effet Hall), de réaliser la calcul de la fréquence à partir des relevés temporels, et de recalculer la consigne en conséquence.

Sachant que pour une boucle PID l'allure (en gros) du script est:
u(n)=Kp*e(n-1) + Ki*Se(n-1) + Kd*de(n-1)
e(n-1)=e(n)
e(n)=Ucons - u(n)
Se(n)=Se(n) + dT*e(n)

de(n)=( e(n) - e(n-1) )/ dT

Question: est ce qu'une carte Arduino Mega avec un processeur ATmega 1280 à 16 MHz est capable de tenir tout ça seule? a priori la fréquence est largement suffisante, mais on ne peut pas tolérer de retards du à des calculs trop longs sur le contrôle du courant ou sur la stabilité de la PWM pour des raisons de sécurité.

Je pense que ça revient à déterminer le temps que met Arduino pour faire une addition, une division, une assignation... mais je n'en ai aucune idée... Si je dédouble les cartes, je me pose la question du temps de communication entre ces dernières...?

Donc voila, je n'ai pas ces ordres de grandeurs en tête, et c'est la première fois que je m'attaque à ça, j'espère ma question est claire, et merci d'avance aux électroniciens qui prendront le temps de répondre!
-----

[invitee05a3fcc]

Bonjour kwakou et bienvenue sur FUTURA

Le contrôle en vitesse des roues ne protège pas le convertisseur de l'overshoot de courant,

Tu peux détailler ?
Tu peux donner le schéma de ton pont "H" et des drivers ?

est ce qu'une carte Arduino Mega avec un processeur ATmega 1280 à 16 MHz est capable de tenir tout ça seule?

Je pense que quasiment n'importe quel µC est capable de faire ça (si le courant max est géré en analogique !)

pas par la PWM usuelle qui ne dépasse pas les 500 Hz

Tu es sûr de cette affirmation ????

[invite1847dfac]

Bonjour DAUDET, merci de ta réponse,

il me semble qu'au démarrage du moteur, l'asservissement en vitesse le fait forcer un peu, ce qui se traduit par un pic d'intensité... j'ai donc peur que ce pic endommage les MOSFET du convertisseur... pour éviter ça, il m'a semblé (internet m'a dit) qu'une bonne solution serait de réaliser un asservissement du courant pour ne plus voir ce pic..

Au niveau du convertisseur, j'ai besoin qu'il soit réversible en tension pour contrôler le moteur dans les deux sens, et dans l'éventualité de la mise en place d'un freinage récupératif à l'avenir, il faut qu'il soit réversible en courant également... j'ai donc opté pour un hacheur quatre quadrants constitué de MOSFETs et de diodes en têtes bêches.... j'ai appelé ça pont en H donc mon post, désolé
Vu les prix ( on dépasse facilement les 50 euros l'unité sur les sites d'électroniques), je pensais limite le réaliser moi même, majorer la puissance dissipée et acheter un dissipateur thermique.
Pour le driver, c'est simplement pour m'assurer que les MOSFET fonctionnent par paire et de manière synchrone... je t'avoue que je ne me suis pas encore penché à fond là dessus, je voulais d'abord valider l'architecture du système de contrôle.. :/
Quelque chose de vraiment simple donc, quatre paires MOSFET/diode en tête bêche contrôlés en commutation par le driver..

Au niveau de la PWM qui ne dépasse pas les 500 Hz, je voulais juste dire que la commande analogWrite propose par défaut des fréquences assez faibles (500 Hz, et 1kHz sur les broches 5 et 6 je crois...), mais qu'il me semble qu'il est quand même possible de générer des signaux de fréquence plus élevée avec l'Arduino..

"Je pense que quasiment n'importe quel µC est capable de faire ça (si le courant max est géré en analogique !)"

Si on enlève les calculs du courant, je pense effectivement que la carte s'en sortira bien... le seul problème est que ça oblige à concevoir la régulation en analogique et à faire un système hybride... Ce qui en soit n'est pas un drame! Il y d'une part la raison temps/budget, mais je ne trouve pas ça très élégant de faire un PID numérique pour la vitesse, un PI analogique pour l'intensité, et derrière de revenir sur du numérique pour adapter le rapport cyclique sur la commutation :/
Il est peut être possible de dédoubler les cartes, afin d'en avoir une qui génère un signal propre et l'autre qui fait les calculs de contrôle, mais la solution la plus simple et la plus rapide reste encore de tout mettre sur une seule carte. Encore faut il être sur que le calcul du PI à 10kHz ne perturbe pas la génération de la commande de commutation... d'où ma question!

N'hésite pas à me reprendre si des choses te semblent bizarre dans mes explications, ce n'est pas vraiment mon domaine

Merci d'avance!

[antek]

il me semble qu'au démarrage du moteur, l'asservissement en vitesse le fait forcer un peu, ce qui se traduit par un pic d'intensité... j'ai donc peur que ce pic endommage les MOSFET du convertisseur... pour éviter ça, il m'a semblé (internet m'a dit) qu'une bonne solution serait de réaliser un asservissement du courant pour ne plus voir ce pic..

Le problème peut se résoudre en soft, mais ne sera valable que pour un seul moteur et une seule charge.
Il faudra pouvoir changer les paramètres en changeant de moteur ou de charge.
Cela consiste à appliquer une loi pour le calcul de la vitesse commandée, fonction de "vitesse actuelle moins vitesse de consigne".
Sinon, mesurer et tenir compte du courant demande quelques instructions assembleur.

[A voir en vidéo sur Futura]

[invite1847dfac]

Salut Antek, merci pour ta réponse

"Le problème peut se résoudre en soft, mais ne sera valable que pour un seul moteur et une seule charge.
Il faudra pouvoir changer les paramètres en changeant de moteur ou de charge."

Je ne suis pas sur de te suivre, il me semblait qu'en soft j'aurais la possibilité d'adapter mon montage, contrairement à un montage en Hard/analogique ou par contre il faudrait changer la valeur des composants... de toute façon, changer de moteur n'est pas prévu

"Cela consiste à appliquer une loi pour le calcul de la vitesse commandée, fonction de "vitesse actuelle moins vitesse de consigne".
Sinon, mesurer et tenir compte du courant demande quelques instructions assembleur. "

Oui, je suis d'accord avec toi, la synthèse du correcteur ne devrait pas poser de problème... mais je ne comprends pas ce que tu veux dire, je veux relever le courant de sortie du hacheur (de l'ordre de la dizaine d'ampères) avec un capteur de courant qui renvoie l'info à ma carte, où interviennent les instructions assembleur ici?

Merci d'avance!

[antek]

Je ne suis pas sur de te suivre, il me semblait qu'en soft j'aurais la possibilité d'adapter mon montage, contrairement à un montage en Hard/analogique ou par contre il faudrait changer la valeur des composants... de toute façon, changer de moteur n'est pas prévu

Cela veut dire que si ton système doit fonctionner avec n'importe quelle charge, l'utilisateur doit pouvoir entrer les paramètre de la charge.
Ce sera par exemple difficile à réaliser si la charge varie en continu.

[antek]

Oui, je suis d'accord avec toi, la synthèse du correcteur ne devrait pas poser de problème... mais je ne comprends pas ce que tu veux dire, je veux relever le courant de sortie du hacheur (de l'ordre de la dizaine d'ampères) avec un capteur de courant qui renvoie l'info à ma carte, où interviennent les instructions assembleur ici?

Tu avais l'air d'être préoccupé par la capacité du µC à gérer autant d'informations.
Acquérire une valeur et lui appliquer un traitement simple ne prend que le temps de quelques instructions (pas instructions C, instructions assembleur),
c'est à dire quelques µs.

[invite1847dfac]

Salut Antek,

Tu avais l'air d'être préoccupé par la capacité du µC à gérer autant d'informations.
Acquérire une valeur et lui appliquer un traitement simple ne prend que le temps de quelques instructions (pas instructions C, instructions assembleur),
c'est à dire quelques µs.

Je comprends mieux. Donc avec des instructions assembleur, je peux réduire le temps de calcul de ces traitements simples à quelques microsecondes, ce qui semble compatible avec les 20kHz=50µs!

Aurais tu une idée du temps de calcul nécessaire si je passe passe par les fonctions de base d'Arduino sans écrire en assembleur?

D'autre part, je n'ai pas réussi à trouver de documentation sur ces questions (ce qui m'a amené à vous embêter sur ce forum!), aurais tu une référence pour moi?

Dans tous les cas, merci beaucoup pour tes réponses!

[antek]

Je ne connais rien à arduimachin.
Par contre le µC de ces cartes peut se programmer en C ou en assembleur.

Par exemple, une addition avec résultat sur 16 bits prend dans les 6 instructions.
Le temps que cela prend est fonction de la durée d'un cycle instruction.
En C après compilation tu peux accéder au programme en assembleur ou langage machine et connaitre ainsi le temps d'exécution exacte.

[invite3c199cf9]

2)Deux boucles PI(D) pour contrôler le courant, à une fréquence de 10kHZ (temps bien inférieur à la constante électrique des moteurs...). La boucle de courant consiste à lire les valeurs des capteurs de courant, à mettre à jour les variables du PI(D) en tenant compte de la consigne, à calculer la nouvelle valeur de rapport cyclique et à l'insérer dans la commande de commutation.

A mon avis, il est risqué de gérer les surintensités par soft, et il est plus sûr de confier cette fonction à un circuit spécialisé comme le L297 (et d'autres). De plus, il te permettra de contrôler le sens, les demi-pas, etc..

[invitee05a3fcc]

j'ai donc peur que ce pic endommage les MOSFET du convertisseur... pour éviter ça, il m'a semblé (internet m'a dit) qu'une bonne solution serait de réaliser un asservissement du courant pour ne plus voir ce pic..

Le µC calcule le PWM qu'il faut pour commander le moteur.
Le driver (regarde le L297 comme exemple) commande les NMOS et peut te donner une info courant
Tu compares cette info avec la valeur max admissible et tu coupes , en anticipant, le pulse PWM
Faire ça par soft, c'est tisser la corde pour se pendre.

On ne sait toujours pas si ton moteur consomme 69A sous 400V .....
PS : pour des moteurs pour véhicule mobile, on préfère utiliser des BrushLess

[antek]

A mon avis, il est risqué de gérer les surintensités par soft, et il est plus sûr de confier cette fonction à un circuit spécialisé comme le L297 (et d'autres). De plus, il te permettra de contrôler le sens, les demi-pas, etc..

Dans l'absolu oui.
Mais pas dans le cas où on limite le courant par la limitation de l'accélération demandée au moteur.
Une sécurité hors soft étant toujours nécessaire.

Il est à noter que la question initiale concernait la limitation de courant moteur bloqué.

[bobflux]

La fréquence du PID d'un régulateur de courant soft est à considérer en fonction de l'inductance de la charge. Le moteur ayant normalement une inductance conséquente, le courant dedans ne varie pas rapidement, donc une fréquence de PID de 20 kHz n'est pas forcément nécessaire. Il faut étudier la question.

Maintenant, réguler le courant finement n'est pas forcément utile, voire nuisible. Si le robot rencontre un obstacle (par exemple il doit escalader une bordure de trottoir) alors il y aura une forte demande de couple pendant un moment. Par contre, si le robot cale contre un mur, le PID qui contrôle la vitesse finira par envoyer le PWM au max.

On peut mettre une sécurité par enveloppe : par exemple autoriser 10A pendant 1 seconde, mais seulement 3A en moyenne.

D'autres algos sont envisageables : par exemple, si la vitesse obtenue s'éloigne brusquement de la consigne, c'est qu'on a calé sur un obstacle. Il peut être utile de réduire la consigne pour ne pas avoir une accélération fulgurante juste après l'obstacle.

Concernant la protection des MOSFETs, une mesure de courant en soft protègera très bien le moteur, mais la seule chose qui protégera les MOSFETs d'un coup de tournevis malencontreux entre les fils du moteur (un bon vieux court-circuit) est un comparateur rapide suivi d'une bascule D ou RS qui va couper les MOSFETs le plus rapidement possible (genre, moins de 1 µs).

Pour ton pont en H, si tu as moins de 24V, tu peux utiliser des drivers style ADP3120 et des MOSFETs discrets.

[invite1847dfac]

Le moteur consomme du 13A en régime nominal, pour une tension de 24V.

Je vais plancher un peu sur vos conseil, et probablement implanter une partie analogique.

merci beaucoup pour votre expérience, vos références de composants, et vos astuces.

Je vous tiens au courant dès que j'ai une solution concrète à montrer

à bientôt!