DIY - [OpenFFBoard + VESC + BISSC] Connection en CANBus, command de couple numérique : feedback et code source...

Bonsoir,

comme vous le savez probablement, je me suis créé un premier setup il y a de cela une grosse année avec MMOS et un contrôleur de moteur VESC pour mon mige 15015

Ce setup, qui m'est revenu à 400€, vient de subir un petit lifting

Au menu :

-> passage sur OpenFFBoard pour avoir une fréquence de calcul du FFB plus rapide et surtout OpenSource pour y contribuer

-> mise en place d'une commande numérique de "couple/position encodeur" entre le VESC et la discovery (STM32)

-> gestion de l'encodeur par le vesc.

Bilan : ca n'a absolument rien à voir par rapport à la première version en PWM+DIR : le volant est plus souple et tout me semble plus détaillé :

• Les effets de faibles amplitudes sont "clairs" et se sentent bien dans les mains,: à vitesse réduites, je ressens très précisément les bosses et les trous de la route sans exagération, sans à-coups, vraiment très doux, je pense que cela vient de la précision de la commande numérique qui envoie une consigne de couple extrêmement précise
• Les effets de dynamiques de voitures sont instantanés : je sens la voiture qui commence à perdre de l'adhérence, à ce moment les détails du sols redeviennent clairs et à la reprise de grip, le couple est franc sans pic.
• Les crashs, coups de raquette et autre sont violent, mais ne font pas mal et c'est pas un grand coup de couple comme avant, mais quelques choses de plus précis, la descente est douce et je devine se qui se passe... C'est pas du ON/OFF

Autrement dit, j'ai perdu tout mes repères

Une petite video pendant laquelle j'ai essayé de faire un peu de tout :

• de l'herbe et gravier à faible vitesse pour que vous voyez le détail de la commande de couple avec une très, très faible amplitude.
• De grands virage avec perte/reprise d'adhérence
• de petits virages avec un "laissé coulé" (c'est ce qui m'a le plus surpris... on peut décrire la route avec les yeux fermés)

La courbe rouge, c'est la commande de couple reçu par le vesc, vous avez la valeur en numérique en dessous.

Si vous tendez l'oreille, vous entendrez le jeu, le son est pris par le micro de mon casque audio, vous m'entendrez aussi souffler, et le bruit de mon pédalier... quand au volant : aucun bruit.

Choses promises, chose dues ! le code source :

• le firmware du vesc et le client pour le configurer sont disponibles ici : https://github.com/manoukianv/ves…FBoard/releases
  • Le code source que j'ai fait pour l'encodeur a été intégré dans la version standard du vesc (du code de moins à maintenir
• le firmware d'OpenFFBoard a été soumis au créateur du projet, ma contribution est disponible ici : https://github.com/manoukianv/OpenFFBoard dans la branche vesccan
• le client de configuration est disponible ici : https://github.com/manoukianv/OpenFFBoard-configurator également dans la branche VescCan

de la doc viendra par la suite si certain veulent tester

Vincent

Pour info j'utilise un vesc 4.12 ou un minivesc 4.2 sur lesquelles j'ai fait l'adaptation suivante :

1. suppression du filtre RC sur les entrées du port du capteur de position pour l'encodeur ABI de 2500cpr
2. remplacement des deux shunts de 0.001ohm par des 0.005 pour passer les vescs d'une plage -160A/+160A à -32A/+32A, ce qui améliore la précision par 5 du systhème de contrôle de courant !

A venir : prendre du plaisir avec le volant, essayer de gérer des encodeurs BISS-c de mige dans le vesc.

Je vais faire des petits tutos videos, et écrire un guide de mise en place.

Oui il y a une mesure du VBUS, c'est assez facile d'écrire une application pour commuter un mofset sur une résistance de freinage : il faut compter une petite heure de boulot

Pour ce qui est des cartes a 3 shunts, je rejoins ton avis : ca doit être encore mieux ! Mais là, à deux shunts callés pour avoir une plage de +/-30A max, c'est déjà génial.

J'ai regardé la carte FOCCer 2, elle a l'air carrément top, et j'en profiterai bien pour changer les shunts directement pour caller la lecture à 30A.

Après le truc excellentissime, serait d'avoir une mesure sur 2 gains, un pour les courant <5A et un pour le 30A comme sur les IONI, il y a assez d'entrée analogique sur le VESC pour le faire... Je ne m'y connais pas assez en électonique analogique pour faire un tel étage, mais je peux le coder dans le vesc. Pour infos la lecture des ADCs est callée à la vitesse du FOC, 25khz par défaut et je le pousse à 30khz dans nos cas.

Je vais changer les shunts de ma carte clone vesc6 pour voir si je peux en faire quelque chose...

Par contre, je ne te rejoins pas sur ta dernière phrase, j'ai partagé un firmware de vesc il y a un an pour se faire une carte moteur DIY en PWM+DIR qui est utilisé par des simracer sous MMOS, Hoan et OpenFFBOard

Rentrer dans le code du vesc, il m'a fallu 1 an de hobbyst, j'y ai passé des heures au carrés...

Je l'utilise dans d'autre application que le simracing.

Pour la lecture de l'ADC, ce n'est pas une lecture séquentielle dans le code, mais "pseudo parallèle" par le CPU avec mise à dispo des infos par DMA. Concrètement vue la vitesse du timer pour l'ADC on est large, il fait toutes les mesures d'un coup et les échantillons sont frais à chaque calcul de FOC. Les calculs du foc sont quand à eux callés sur la freq du PWM de pilotage des mofsets, dans mon cas à 30khz.

Actuellement, sur le 4.12, le vesc lit d'un coup les entrées suivantes : 2 shunts, la BEMF des 3 phases, la tension d'entrée (VBUS/VIN), 2 ADC "externes" (EXT & EXT2 sur le connecteur accessoire), la temperature du moteur, la temperature a coté des mofset et pour finir la Vref Intermédiaire du STM32

Nous avons donc à notre dispo des ADC de dispo pour mesurer une 3eme phase par exemple ou pour rajouter un second étage de mesure de shunt sur un autre niveau de gain.

Pour être certain que nous parlions de la même chose : sur le vesc4 et le vesc6, tous les channels des 2 ADCs sont lus en même temps :-D

C'est pour cela d'ailleurs que la lecture est callé sur la clock PWM, ca permet de mesurer de manière synchro avec les mofset commuté pour éviter le bruit sur les changement d'état.

Oui on parle bien de la même chose du coup

j'ai une STM32F407 sur la discovery et le vesc, de mémoire les ADC peuvent tourner à 40Mhz, donc à 30khz.

Je me souviens avoir fait les calculs des timings, et c'était bon.

Mizoo a écrit :

Tu saurais mesurer la durée de la boucle de régulation de courant ?

Entre la fin de la mesure de l'ADC et la mise à jour du PWM.

Alors là, j'ai mal à la tête je viens de passer 1heure dans le code, et je ne comprends pas tout ce qui est fait au niveau des timer.

Bon dans notre cas, c'est le Timer2 qui sert à caller le rythme des ADC, et ils sont callés à 42Mhz (oui ils sont overclocker), mais je ne sais plus combien de temps de clock il faut pour lire les 3 ADCs et les copier en RAM. Je pense que c'est de l'ordre de 20 cycles au moins, donc 2Mhz de capture.

Et j'ai dit une bêtise : le calcul du FOC est fait à cette vitesse des ADC des que le DMA a copié les données, c'est le PWM des mofset qui est callé à 30khz

L'init de l'ADC, du DMA et du déclenchement du calcul sont callé ici :

https://github.com/vedderb/bldc/b…cpwm_foc.c#L529

Donc pour répondre à ta question sur les mesures de timings entre les deux. Par contre le FOC calcul beaucoup plus vite et souvent que la période des PWM, un ratio qui doit être de l'ordre de 2.1Mhz de FOC (hypothèse) pour 30khz de commande de pwm.

Une dernière chose, les mesures de courant à travers les coils que je t'ai partagées sont sur un timer qui a une fréquences encore différentes des autres, je pense que ca n'aide pas à la lecture d'un signal stable. C'est pour limiter le volumes de samples...

Je pense que c'est pour ca que le résultat au feeling est meilleur que ce que l'analyseur donne.

Salut,

Ca commence à dépasser mes connaissances, mais j'ai pris mon courage a deux mains en rouvrant le datasheet du stm32f405.

Dans la partie ADC, ce que je comprends, c'est qu'il faut 15clk d'ADC à 42Mhz, ca fait 0,5µs par capture.

Mais il me semble qu'il y a 10 captures en séries plus le temps du DMA.

je vais essayer de mettre des traces dans le code, ce sera plus simple qu'avec le datasheet