DIY - développement d'une carte DIY équivalente à Simucube+ioni

Carlton a écrit :

J'avais essayé le framework MC-SDK de STM et je n'ai pas du tout été convaincu dans notre usage de volant à FFB.

La pauvreté de l'algo faisait que le moteur était très bruité, la fréquence de controle du PWM trop basse.

C'était il y a un poil plus de 2 ans, les choses ont peut etre évoluées.

J'ai passé un peu de temps à regarder, je trouve le code très lisible. L'algo est un algo FOC tout ce qu'il y a de plus classique, je doute que ce soit lui qui amène le bruit. Tout est réglable, y compris la fréquence PWM. Dans les docs et sur d'autres forums j'ai vu passer des captures qui étaient très propres.

Je serai fixé quand j'aurai testé.

Carlton a écrit :

As tu regardé la GSVESC sur github ?

Non, celui là je ne l'avais pas vu.

Malheureusement je suis incapable de faire de la revue de PCB de ce niveau.

Bon, je suis faible, j'ai mis la carte ESC dans mon panier...

EDIT: et retirée, car d'après ce que j'ai pu lire le design est très mauvais et elle surchauffe très vite.

Si j'ai le temps ce WE je regarderai le code de SimpleFoc, mais étant donné qu'il ne supportait même pas le mode 6PWM initialement je doute que ce soit très sophistiqué.

Des montages volant FFB avec moteur de hoverboard et cartes VESC, IMH08 et b-g431b-esc1, avec des avis mitigés sur cette dernière.

EDIT: et je vois que notre ami Etienne est passé par là

si tu fais des recherches sur des projets de volant FFB diy, il y a des chances pour que je sois passé par là car mon fw pour Leonardo est (ou à été) souvent utilisé. Et des fois je pose ma crotte pour rappeler que je suis toujours là et que je surveille

Je suis tombé dessus en cherchant des retours d'expérience sur la carte ESC.

Je viens de jeter un coup d'œil au code de VESC, et c'est effectivement imbitable, il n'y a quasi aucun commentaire dans le code et je n'ai pas trouvé trace de document quant au fonctionnement du contrôleur moteur.

Quant à SimpleFoC, il est comme son nom l'indique très simpliste.

Je reste donc pour l'instant sur le code de ST et celui de TI.

Tout est au meme au même endrois dans la classe *_foc_*

Et pour le coup le code du foc est assez simple : il lit les shunts, calcules les angles à partir des positions, en déduit les valeurs vectorielles et déclenche les modif des PWM.

Je joue depuis une semaine et c'est vraiement génial. Je vais poster dans l'autre page les premiers résultats des tests classiques.

Le principe est toujours le même, pour tous les algos FOC. Ce qui fait qu'un contrôleur est meilleur qu'un autre se joue dans quelques détails, et là pour le coup tout est noyé.

Il n'y a quasi aucun commentaire sur le pourquoi du comment, des littérales sans justification, du volatile en veux tu en voilà. La fonction mcpwm_foc_adc_int_handler() fait la bagatelle de 700 lignes. Et il n'y a aucune abstraction matérielle, tout est étroitement lié au hardware ST. Bref, tous les métriques sur la qualité d'un code sont au plus bas.

Ce n'est pas une critique, mais une constatation, Benjamin Vedder a fait ça sur son temps libre, on ne va pas non plus lui demander de passer des heures à tout documenter.

Mais pour quelqu'un qui veut contribuer au projet rien ne lui est simplifié.

Je suis d'accord sur l'analyse du code, je ne laisserai pas passer ca au taf, mais là, je n'y suis pas :-D

J'ai réussi à m'y mettre après un moment, mais c'est vrai que ce n'est pas simple.

Coté hardware je trouve que le travail est important : la version 4 a été stabilisée en 3 ans avec 12 versions. Puis la version 6, sortie il y a 3 ans, a été pensée pour avoir une mesure de courant sur les 3 phases. Les premières versions étaient à mesures directes, elles ont maintenant évolué vers une version avec filtre hardware.

Quoi qu'il en soit, il s'agit d'un stm32 avec un DRV, le framework de MCSDK de STM doit pouvoir être utilisé : le mapping de pin sera le principal travail.

Il n'est pas évident de trouver des métriques concernant les différents driver du marché quand on n'a pas le matériel à disposition.

Mais concernant la carte Ioni, Tero a posté un billet sur le blog GD il y a quelques années concernant la bande passante de la boucle de contrôle de couple (courant).

On y apprend que le firmware a été optimisé pour exécuter la boucle en moins de 25µs, pour permettre la mise à jour du prochain cycle PWM sans délai (à 20 kHz). Ce qui permet d'augmenter la bande passante de contrôle, par rapport à un système trop lent qui prendrait plus de 25µs (mais moins que 50).

Sur VESC, et la plupart des drivers, on est aussi à une itération par cycle PWM.

Si je voulais partir sur un circuit de chez TI c'est entre autre parce que leur boucle est optimisée pour s'exécuter en moins de 0.5µs (auxquels il faut rajouter 0.5µs pour la mesure du courant), grâce aux modules d'accélération hardware spécifiques des derniers C2000. Une boucle aussi rapide permet (quand les capteurs de courant sont sur les phases) de réaliser deux mesures et contrôle par cycle PWM (aux flèches vertes ET bleues sur le graphique de GD), augmentant encore la bande passante.

Malheureusement, la seule carte d'éval me permettant de l'implémenter est limitée à 10A, ce qui est peut-être un peu juste (ou pas).

Pour donner un ordre de grandeur sur le vesc :

• PWM de sortie à 25khz, sur un timer de 16bit
• durée de traitement de l'algo du FOC : 0,0281ms en rotation, 0.0201ms à l'arrêt

Ce temps d'algo inclu tous les traitements, de la mise à dispo des samples par DMA, à l'enregistrement des valeurs dans les 3 registres PWM :

• L'algo du FOC à proprement parlé (angle/Iq/Id/Vd/Vq) et l'ensemble des PID appliqués
• Les contrôles sur les valeurs limites de courant
• la gestion des cas particulier : openloop, amélioration sur l'observer, mise à dispo des stats (calculs des moyennes, etc.)
• les calcules de freq des registres des 3 PWMs

Cela veut dire qu'à 25kHz tu as un retard d'un cycle PWM.

Je ne comprends pas pourquoi tu as une durée différente à l'arrêt et en rotation.

EDIT: tu es sûr que ce qui touche aux stats et à l'observer n'est pas fait après la mise à jour des registres PWM ?

Quelle raison y a t-il à le faire avant ?

Je viens de voir ça dans le code:

/*
 *    Run the FOC loop once every N ADC ISR requests. This way the pwm frequency is
 *    detached from the FOC calculation, which because it takes ~25usec it can't work
 *    at >40khz. To set a 100kHz pwm FOC_CONTROL_LOOP_FREQ_DIVIDER can be set at 3
 *    so it skips 2 ISR calls and execute the control loop in the 3rd call.
 */

https://github.com/vedderb/bldc/blob/master/conf_general.h

Déçu je suis...

Il est impératif de descendre sous les 25µs si l'on veut maximiser la bande passante de la boucle de courant (à 20 kHz).

Et partir sur 40kHz avec 25µs de temps de boucle c'est effectivement reconnaitre un retard d'un cycle PWM, du coup j'ai dit une bêtise hier, VESC a, par design, du retard.

Peut-être qu'avec les accélérateurs mathématiques de la série G4 on peut gagner quelques µs.

En tout cas on est vraiment loin de la solution de TI qui par rapport à VESC doit avoir une bande passante quasi 5 fois plus importante.

Oui je suis certain que c'est inclu dans le temps que je t'ai donné : à chaque échantillon, l'algo FOC mets 0,0281ms à tout calculer, avant d'attendre le prochain échantillon.

Ces échantillons sont faits pendant la phase V0 du VSM.

A 25khz, ca fait 0,7s de temps traitement sur une 1s glissante, et comme c'est fait en V0, je ne comprends pas le cycle de retard PWM que tu évoques. J'avais cru comprendre qu'il y avait de la marge de CPU dispo du coup. En toute modestie, j'apprends l'électronique sur le tas, il me manque pas mal de notions encore !

J'avoue ne pas etre très à l'aise avec les timer... Mais je crois comprendre que c'est le TIMER du PWM (TIM1) qui déclenche le timer de l'ADC (TIM2) qui fait les lectures en milieu de cycle V0 et qui enchaine avec les copies DMA.

Est ce que cela veut dire que la chaine d'acquisition est gérée par des timers (donc 0% de CPU) que 70% du TPU est consommé par le FOC et que les 30% qui reste sont pour les thread chibios annexe (CAN, encoder, etc) ?

Je ne sais pas pourquoi il l'a fait comme ca, j'ai pour hypothèse qu'il a essayé de faire tous les calculs en V0 pour être certain d'avoir des échantillons le moins bruités possible de par la commutation (quoi qu'en état avec des shunts à la masse, ca évite parasite de commutation), et surtout s'assurer de prendre en compte tous les cas de gestion pour envoyer les ordres de commutations les plus définitif. Ca reste de l'hypothèse...

EDIT :

/*

* Run the FOC loop once every N ADC ISR requests. This way the pwm frequency is

* detached from the FOC calculation, which because it takes ~25usec it can't work

* at >40khz. To set a 100kHz pwm FOC_CONTROL_LOOP_FREQ_DIVIDER can be set at 3

* so it skips 2 ISR calls and execute the control loop in the 3rd call.

*/

Ca ressemble à ce que j'ai vu :

PWM (TIM1) -> ADC (TIM2)

avec TIM1 à 40khz * 25usec de traitement post échantillonage, ca passe juste juste dans la seconde

Par conte avec TIM1 à 100khz, ca voudrait dire 2,5s de traitement : stackoverflow

Pour avoir du TIM1 à 100khz, il ne faudrait garder qu'un cycle sur 3 -> 33khz d'échantillonage et ainsi rester sous la seconde de traitement.

Il me semble que le vesc est au dela de la maximisation de la boucle de commande que tu évoques à 20khz. A 25khz, ca marche bien. J'ai testé à 30khz, ca passe aussi sur le vesc 4.

[La flemme de faire un dessin]

Pour être actualisés au prochain cycle PWM, les registres PWM doivent être mis à jour avant la fin de la période PWM (traits en pointillé).

La mesure ADC étant synchronisée sur le milieu de la période (pour mesurer avec le moins de bruit de commutation au bas de l'onduleur), il faut donc que la boucle dure moins d'une demi-période (A/D conversion + SW routines), soit 25µs pour FPWM=20 kHz. Si tu débordes, les nouvelles valeurs seront prise en compte au cycle N+2 (troisième période sur le graph), ce qui est le cas sur VESC, contrairement à tous les framework mis à disposition par les différents fabricants de CI depuis quelques années.

Ah oui, c'est vachement plus clair comme ca

Je regarde si c'est comme ca dans le code

Je viens de regarder plus en détail le schéma de l'ESC b-g431b-esc1. Il n'y a aucun filtrage de la tension des shunts, juste un réseau de résistances de polarisation. Du coup, je me demande si ça vaut vraiment le coup de la tester. Et il va aussi falloir, tout comme pour le VESC, changer les résistances de shunt prévues pour 40A.

Je viens de voir que Trinamic propose une carte intégrant leur circuit FOC TMC4671 + leur gate driver TMC6100 avec MOSFET et capteur de courant en ligne (AD8418).

Autrement dit, cette carte s'occupe de tout le contrôle moteur. Ne reste qu'à lui adjoindre une carte qui s'occupe de l'USB (entre 5 et 10€).

La carte coûte 55€ HT et mesure 5 cm x 3.8 cm.

Elle est limitée à 10A, mais avec un 'petit' Mige ça peut suffire pour de nombreuse personnes.

On ne pourra pas non plus lui intégrer tous les filtrages imaginables, mais encore une fois ça peut suffire.

C'est à ce jour la meilleure solution, sur le papier, en terme de coût, d'encombrement et de temps de dev .

C'est ce circuit TMC4671 qui est utilisé sur la carte développée par Yannick, l'auteur d'OpenFFBoard, mais je crois qu'il ne l'a pas encore finalisé.

EDIT: juste dommage que la carte d'interface SPI coûte aussi cher (100€). Inutile pour utiliser la carte, mais pratique pour le développement.

EDIT2: il faut aussi rajouter le circuit pour piloter la résistance de freinage (qq euros).