Messages de Carlton

Hello

Je ne suis pas super fan des offsets négatifs : ca peut se mettre à tourner plein couple si l'esp32 n'est pas alimenté, ou si le câble de commande a un faux contact. Je vais gérer le sens de rotation avec un pin de l'aasd.

L'avantage avec le MCP, c'est qu'on passe en 12b sur un signal 5V, donc plus de précision (même s'il a une marge d'erreur qui lui est propre) sur une amplitude de signal plus grande. La lecture coté AASD n'en sera que meilleure : on va utiliser la plage 0-5V sur 4096 de précision pour 3Nm vs 0-3V sur 255 de précision pour 6Nm (-3..3).

Je suis en train de regarder les paramètres de l'aasd pour régler

une commande mixte couple/vitesse sélectionnable avec une PIN,

une commande en analogique,

une pin pour l'Enable du driver,

une pin pour récupérer les alarmes de l'aasd.

On n'est pas très loin de ce que fait Thanos. Je n'ai pas envie d'activer l'autodétections de fin de course auto de l'aasd contrairement à ce qu'il fait...

Vincent

Salut Jempy ,

Nous avons une recrue qui a fait son inscription RFRO hier, il s'agit de Kay (vegamissyl sur les serveurs) qui avait tourné sur Valence et Spa en Open.

Est ce que vous avez vu son inscription passée ?

A très vite,

Vincent

Hello,

l'aasd peut etre configuré pour donner 100% a la tension que tu souhaites : 3.3, 5, 10v...

Je trouve le MCP suffisant pour nos premiers tests, ca vaut pas un adc haut de gamme, mais ca sera suffisant pour le poc

Vincent

il y a un bug, mais c'est le mien

tu peux utiliser la version 6 sur le 4.12

Le bug que j'ai fait dans l'implémentation du BissC est que je ne décrémente pas les compteurs d'erreur : en cas de mauvaise connexion entre le vesc et le bissc, le vesc impose de compter les erreurs pour arrêter le moteur si la position est inconnue depuis trop longtemps. J'incrémente bien le nombre d'erreur, mais j'ai oublié de le décrémenter quand il n'y à plus d'erreur, il faut reseter le vesc... Ca ne m'était jamais arrivé avant le test des vesc 6.

J'ai poussé un correctif dimanche que Benjamin (le père des vescs), il l'a déjà intégré dans la version courante pour la futur release.

Si tu as des soucis de communication je pourrai te la passer, mais c'est pas bon signe, ca veut dire que ta communication ne sera pas top

J'ai pas mal codé sur Openffboard, je suis repassé sur le moteur FFB pour être plus proche de la norme, travaillé sur les filtres pour avoir le maximum de détail, implémenter les profils, le monitoring des effets en temps réel, les stats des effets, le fine tune du moteur ffb sur la page FFB, le fine tune des encodeurs sur la page axis, la mise en systray avec les menus rapides, le bissC. j'en oublie surement :-D

D'ailleurs le firmware doit être pas mal : Yannick vient de voir que la marque Cammus nous à fait confiance en reprenant le firmware opensource dans toute leur gamme de volant, le firmware contient les headers OpenFFBOard. Nous en sommes certain pour le C5 que Yannick a eu entre les mains, ils ont apportées 2 ou 3 modifs à l'électronique coté filtre emi, mais le client de 2021 de Yannick permet de se connecter et de configurer le ffb... Ca signifie que nous avons un bon moteur

Ils ont pris une vieille version de 2021 avant tous les ajouts de Yannick etmes optimisations. Surement le temps pour eux de concevoir les produits finis et de les produire.

En tout cas ca rassure dans le travail fourni par toute l'équipe

Hello,

j'ai codé la gestion des profils dans openFFBoard pour partager le volant avec mes filles aussi.

Je touche relativement peut à la puissance globale, je le laisse au max.

Je baisse par contre le slider des "effets FFB" en dessous. Il réduit l'ensemble des effets sauf le endstop. Ca me permet d'avoir une butée franche que je ne mets pas non plus à bloc, sur le mige je suis à 25Nm pas besoin de ca dans les bras des enfants...

En effet tu ne tireras pas 11A en continue. Sur le mige 15015 en 36v (350rpm), je consomme moins de 2A/h.

Coté réglage, j'ai callé le vesc à 15A.

En test, je suis monté à 30A, l'électronique suit parfaitement et le moteur aussi, il ne sature pas. Mais là attention on parle de plus de 54Nm d'après les specs du moteur, l'axe du moteur était bloqué par un axe et le bouton d'arrêt à quelques cm... Tests aux limites du vesc avec les shunts modifiés pendant 15min... le vesc a eu chaud bien avant le moteur

hello,

c'est ca pour le schéma

j'ai finis de dessiner la carte d'OPV, elle revient à 18e assemblé chez JCLPCB... Ils annoncent des délais de 3 semaines, du coup je suis en train de faire un système vachement plus simple et efficace et moins cher !

Une carte ESP32 (j'en ai dans les tiroirs) mais n'importe quel carte arduino fera le boulot, un ads1115, 2 résistances et un mofset de lit chauffant d'imprimante 3D, ca revient à 15e... et c'est dispo partout.

L'esp32 lit la tension du bloc d'alimentation avec l'ads, et active de mofset des lits chauffant quand la tension est au dessus de la valeur de référence. Je ferais une carte plus tard avec ces éléments intégrés... J'ai codé le firmware hier, je teste ce soir si tout va bien.

C'est le principe de la carte que tu as achetés.

Un point de vigilance sur le courant à travers la diode que tu as dessiné DSI30 16A, parce que elle, elle à chaud ! Avec une Vf de 1.4v a 15A, elle a 21W à dissiper, il va falloir l'aider avec un radiateur.

Tu me feras un feedback de la solution quand tu auras testé, en tout cas, si tu as besoin, n'hésites pas à me mentionner, je passe régulièrement en ce moment avec le boulot sur la pédale FFB.

J'ai jamais eu de soucis de masse, le vesc n'as pas le connecteur USB entièrement cablé, il lui manque le VCC sur l'usb, je pense que c'est pour éviter le problème. Ca veut dire que tu ne peux communiquer avec lui qu'avec l'alimentation activée.

Ensuite pas de soucis de parasite non plus entre le vesc et le reste, le bus can ne partage pas de masse, tout est en différentiel de potentielle entre le CANL et le CANH.

A ta dispo

Bonsoir,

Tu peux me tutoyer, j'en fais de même, ou alors je passe sur le vouvoiement

le design de la 4.12 date en effet, mais les composants sont fiables et le fait de lire le courant pas des shunts low side est plus précis.

le design de la 6 est plus récent, mais ce sont les mêmes CPU donc finalement pas tant de différence dans les fonctionnalité. Que ce soit le vesc6 mk6 ou le flipsky 6.7, les deux ont le bug...

Les "vraies" différences sont 3 shunts vs 2 (mais ca bug...), un DRV réglagle par SPI (mais c'est pas codé dans le firmware), plus de voltage et plus de courant (mais nous on les réduits ), plus de rpm.

Finalement, le vesc 6 n'apporte rien en tant que tel pour nous. pour les vélo, skate, trottinette, je ne répondrai pas la même chose.

Le firmware 6 marche sur le vesc 6 et le vesc 4.12, c'est le même firmware pour les deux hardwares, tu as donc le bissC dans les deux cas. C'est d'ailleurs ma config.

j'avais exclu Odrive a cause des encodeurs, et j'ai trouvé que j'avais du cogging dans le volant, justement à cause de la boucle à faible vitesse.

Alors oui ces upgrades sont importants :

• la finesse des effets ffbs : le bissC te permets des positions très précises, et comme on le lit à 1khz, en 1ms, même quand tu tournes le volant lentement, sur un ABZ2500 tu va lire 1 cran d'encodeur, puis des 0, puis 1 cran d'encodeur... et pourtant la vitesse est constante, mais la précision ne le renvoie pas, donc on est obligé de mettre des filtres qui moyennent sur une "longue" période les vitesses. Et comme les effets damper/friction dépendent de la vitesse, et bien on les dégrade, ils deviennent moins précis, plus flou. Tu n'as pas ca avec les bissc, parce qu'en 1 ms tu lis suffisant de crans, meme à faible vitesse, pour avoir un signal correct, sans avoir besoin de le trifouiller.
• Le bruit : si le driver fonctionne à une vitesse audible, et bien tu entends les harmoniques dans le moteur... Ca siffle, chante... En dessous de 18kh il faut passer son chemin

Le vesc a sa boucle de controle de FOC à 20khz et qui peut monter à 30khz dans certain cas, et les mofset commutent aussi à cette vitesse, tu n'entends pas de sifflement Et il recoit les ordres d'Openffboard à 1khz, la fréquence du moteur FFB.

Je ne fais plus de dev sur OpenFFBoard pour le moment parce qu'on en a plus besoin : on a tout ce dont on peut avoir besoin : un moteur FFB qui implémente la norme, tous est reconfigurables en terme de gain, de filtre numériques, de monitoring

Salut MikeTheBike71

pour t'aider à comprendre la jungle des versions :

Les modifications que j'ai apporté au firmware d'origine sont de 3 natures :

• Le rajout d'une commande CAN pour récupérer la position de l'encodeur : intégré au firmware standard depuis la 5
• La prise en charge des bissC : intégré au firmware standard depuis la 6 (qui est sortie)
• La prise en charge de shunts avec des valeurs spécifiques : intégré en standard pour le Vesc4.12 et les shunt de 0.005mohm et pas pour les Vesc6 mais...

Pour le moment je recommande le minivesc 4.12 de Flypsky, il y a un bug avec les minivesc 6...

Pour faire simple, quand il y a 3 shunts sur un vesc, le gouverneur par en vrille dans le cadre de notre application de volant FFB : dès qu'il a fini de gérer les 3 phases d'un pole et qu'on passe sur le pole suivant, il coupe le couple! J'ai pas encore réussi a corriger le problème dans l'algo du FOC du vesc.

Ca marche au top avec un vesc 4.12, je suis a un paquet d'heure de simu sur des courses jusqu'à 3h, ca roule

Le firmware d'origine de Vedder marche très bien avec les minivesc4.12 de Flipsky, et tu n'as pas besoin de firmware spécifique.

La modification des shunts permet de gagner en précision de feeling : le vesc est prévu pour gérer 150A, comme nous avons besoin que de 30A max, le fait de réduire sa plage de fonctionnement, permet de gagner en précision.

Pour le coté overload, il s'agit principalement d'arriver à gérer le BEMF : les skateurs ont des moteurs qui tournent très vite avec beaucoup de pôles, et surtout, leurs poids en descente fait accélérer le skate plus vite que ce que le moteur peut faire quand il est alimenté par la batterie. Leur moteur génère une BEMF qui va au dela des 60v que peut gérer le VESC : il crame.

Nous sommes loin de ces valeurs avec les moteurs Mige10010 ou 15015, donc pas d'inquiétude de cramer un vesc ou de le mettre en sécu (c'est un paramètre que tu peux modifier, je mets les vesc en sécu à 58v).

On a quand même un "petit soucis" de BEMF, je m'explique : si on tourne vite le volant, on va générer une tension qui va partir dans le vesc (le moteur se transforme en dynamo), pas de soucis le vesc gère, mais cette tension va ensuite remonter à la batterie... Si c'est une batterie, aucun problème elle se recharge... Par contre si c'est une alimentation, là elle peut ne pas aimer... Son job c'est de fournir du 36v par exemple, pas de recevoir du 38v en sens opposé.

Il n'y a pas de carte toute faite, mais j'en ai dessiné une et il y en a d'autre qui en ont fait aussi. Je suis en train de faire le ménage dans le discord pour en sortir une officiel, facilement commandable et qui marchera pour toutes les valeurs l'alimentation : 24v, 36v et 48v. Pour le moment je suis encore avec mes batterie, mais je vais passer sur une alimentation.

Je tourne depuis 2 ans en 36v à 10A moteurs sur mon mige15015, ca fait environ 15Nm de couple et 350rpm : le moteur ne chauffe pas, il est froid et tout fonctionne bien.

Pour une installation from scratch Vesc BissC, il faut coté électronique une stm32Disco, un TJA1051 et un MAX490

Vesc interface manual

OpenFFBoard is a universal force feedback interface for DIY simulation devices - manoukianv/OpenFFBoard

github.com

Vesc BISSC encoder on HWSPI

OpenFFBoard is a universal force feedback interface for DIY simulation devices - manoukianv/OpenFFBoard

github.com

Pour ceux qui ont des simucubes 1, OpenFFBOard est maintenant compatible IONI, donc c'est assez facile de passer dessus pour avoir un moteur FFB à jour...

n'hésitez pas si je peux aider

Salut Jempy,

nous sommes partant a minima avec Jean, mais je pense que Tom suivra

Nom de l'équipe : Spin&Boxing

Nom du pilote 1: Tyrelever

N° de pilote : 85

Nom du pilote 2 : Carlton

N° de pilote : 19

au plaisir de rouler avec vous

Je connais très bien le firmware Hoan, je l'ai aidé à passer son code d'arduino au stm32 et sur la couche HID.

C'est sur son projet que j'ai joué avec l'AASD en série et en modbus et que j'ai testé les limites du driver

Salut Stef Bord,

Merci pour ton retour, ca marche je pars la dessus

Salut,

Je voulais accéder au VREF de l'ADC pour lui donner une autre tension de Ref que le 5V : du 3.3v en espérant gagné un cran de gain.

J'ai une loadcell de class 3 de 3kg en 2mV/V sous 12V stabilisé avec un gain de 64, buffer, mais je n'ai pas activé le filtre. Je ne crois pas aux filtres des fpga embarqués, j'ai probablement tort, dit moi.

J'ai mesuré la déviation du signal numérique reçu après avoir fait un décalage de 8bits à droite pour n'avoir que 16b de lecture. Le loadcell posé sur la table, je n'ai pas de variation de la valeur reçue.

Le biquad je l'ai rajouté parce qu'on en avait parlé, aucune autre raison. Je l'ai calé à 4khz avec une freq de coupure à 1khz pour viré tout ce qui est au dessus de la freq du FFB.

Pourquoi 4khz, bein parce que ca me paraissait bien, aucune raison scientifique ou technique, j'avais envie de lire vite pour filtrer le signal et le passer à un autre process que je voulais à 1khz, sans avoir trop de bruit

Je suis partisan du fail-fast pour les projets collaboratifs, ca permet de sortir des pièces à frapper (comme on dit dans la marine) et ca évite le standby. Mais dans l'approche fail-fast il faut un processus d'amélioration continue : je suis à votre écoute

Hello,

pour le décodage des encodeurs ABZ sur esp32, la lib que j'utilise marche avec des interruptions.

J'ai également mis en place 2 timers (sur les 4 de dispo) pour déclencher des traitements à 4khz (acquisition de data loadcell, etc.) et 1khz pour le calcul de FFB et les rapports HID.

J'ai externalisé la communication avec le PC sur le core 1 de l'esp32 pour regrouper ensemble les échanges hardwares bloquants.

Ca nous permet d'avoir des traitements aux fréquences que l'on souhaite et d'être tranquille pour l'acquisition et le FFB sans risque de blocage de thread sur la couche de comm. Je pourrais en rajouter d'autres pour le PID mais j'ai pour idée de le déléguer au max au contrôleur moteur. Si ce n'est pas faisable, je rajouterai une boucle de traitement qui va bien à 10, 20 ou 30khz en fonction de ce qu'on veut faire.

La carte ADS en 5V marche : elle s'alimente en 5V, mais le level-signal est compatible 3.3V.

le seul truc, c'est que nous n'avons pas accès au VREF c'est le 5V :-/ donc il va falloir un peut charger le loadcell en alim et prendre un 2mV/V pour être dans une plage d'utilisation confortable. Sur mon proto j'ai une lecture stabilisée de 10mNewton, c'est pas trop mal. J'ai quand même rajouté un filtre numérique passe bas pas trop aggressif (un biquad).

Comme la fréquence d'acquisition est maitrisée, le filtre passe vraiment bien. Pour tester les limites, j'ai monté la freq d'acquisition à 30khz avec le filtre, ca passe encore large de chez large.

J'ai pour idée de mettre le code à plat ce soir après l'openACC et de vous le partager dans l'état

pasted-from-clipboard.pngpasted-from-clipboard.png

L'intérieur de l'active pedal : c'est bien un moteur brushless avec une petite resistance de freinage

Avec deux shunt de mesure de courant sur les phase, donc globalement, je dois tout pouvoir coder dans un vesc...

ok, tout compris

coté écart avec ce que j'ai : la position que je renvoie est celle en mm de l'avance de la loadcell, pas la lecture en ° de la pédale, je n'avais pas prévu de mettre de capteur dessus j'ai fait comme simucube :-D

Pour le PID, il sera probablement proportionnel à la force à la distance à parcourir donc un double PID. Ca permettra d'avoir le couple nécessaire sur un tout petit mouvement de qq ° avec beaucoup de force d'écart (cas de la fin de course), et les grands débattement en ° avec un faible écart de pression.

Le point qui me questionne et sur lequel je bogue terme d'algo est "- on déduit le couple demandé par la courbe"

La courbe est "position/force de pression" avec en entrée "la force de pression".

Je n'arrive pas à déduire le couple de la position, j'ai besoin d'aide sur cette formule, ou alors il faut changer la courbe, mais je n'en ai pas trouvé (couple/force de pression, n'est pas viable)

Pour prendre un exemple :

• 1Nm de couple résistant
• 5Nm de couple max
• une courbe qui dit 200N pour 50mm et 300N pour 60mm (linéaire)

Nous sommes à 50mm avec 200N et j'appuie pour monter à 250Nm => j'applique quel couple ?

J'appliquerais bien le couple max (5Nm) et ensuite je réduis "progressivement" le couple en me rapprochant de 55mm. Il faut transformer le progressivement en équation, le PID peut nous aider

C'est ce que fait un driver de stepper Tu lui dis "va en position 55m", il applique le couple max pour l'atteindre et ensuite il a un PID sur le courant pour rester à cette position C'est le fonctionnement du tmc et son moteur de mouvement 6PointRamping...

Un moteur FFB de volant lui une relation "position/couple" : le jeu envoie une commande de couple par rapport à la position (en fonction de la physique qu'ils ont codé dans le simulateur : pneus/suspensions/gforce/etc.). C'est décrit dans le paragraphe 4.1 des specs du FFB : https://www.usb.org/sites/default/…nts/pid1_01.pdf

Ce qui s'applique au moteur FFB de volant (commande de couple), ne s'applique peut être pas au fonctionnement de la pédale

J'ai reçu hier soir mon sfu1610 de 200mm, ca fait une course de vis d'environ 150mm.

Je me suis rendu compte d'un truc avec, c'est que si on pousse sur la noix, ca ne fait pas tourner l'axe. C'est un défaut de ma vis à bille ou ca fait pareil sur celle que vous avez eu entre vos mains ?

En algo ca donne :

• Si couple < inertie mécanique : pas de mouvement
• Sinon : rotation
  • Mesurer la position
  • Si position est < position souhaitée maintenir le couple
    • sinon baisser le couple pour arrêter le mouvement

Je ne comprends pas l'intérêt de contrôler en couple si c'est pour asservir sur la position... Vous pouvez m'aider.

teddyman a écrit :

vous avez regardé sur les forums US ou internationaux, je suis tombé sur un short ou on voit une pédale DIY en impression 3D fonctionnelle, certains semblent bien avancé, après est-ce réaliste autre question mais y'a peut etre des infos à trouver pour écarter des interrogations que vous pouvez avoir ??

Salut, oui j'ai étudié la solution, ses choix techniques et son code (il est sur github).

Je trouve son approche intéressante et je suis parti de certain de ses concepts pour mon proto. Il est radicalement différent de que nous évoquons ici, il utilise un stepper commandé en position, et ici on évoque l'utilisation d'un moteur commandé en couple.

Le soft de base que j'ai initié permettra de tester les deux, on pourra ainsi comparer les approches et le rendu vs prix.

RacingMat a écrit :

bon, j'avance sur la prise de connaissance du driver AASD15 :
je partais sur une communication RS232 ou 485... mais la prise CN1 n'est pas montée sur mon driver

pasted-from-clipboard.png

me voilà à la recherche d'une solution pour sortir de l'arduino un signal -10V/+10V...

il me semble qu'on avait déjà abordé le sujet à propos des volants mais je ne retrouve pas l'info.

Et le dieu des mots clefs n'est pas avec moi ce soir, je ne trouve rien avec les moteurs de recherche.

Help ?! un shield, un montage avec un ampli OP ?

merci

Afficher plus

Tu as ca : https://fr.aliexpress.com/item/1005004402191795.html

Arduino-DAC-Expansion-Module-diy-kit-PWM-to-0-5V-0-10V-Voltage-Converter-for-NANO.jpg

j'avais testé à l'époque de commander un AASD15 en série et en rs485 et j'ai un souvenir de perf pas folle... De mémoire, il montait pas super haut en bps (dans les 30kbps) et la communication requiert un truc comme 7/8 octets sur 11bits, ca faisait une commande un poil en dessous de 500hz. et ca c'est sans lire l'état du driver, en récupérant la position et/ou des data, ca descendait à 200hz.