DIY - RFR Active Pedal : électronique

Oui c'est pour ma nouvelle carte

Les MCU qui ont un DAC :

- SamD21(Arduino Zero, QY Py, etc) : DAC 10 bits.

- Teensy LC ou 3.2 : DAC 12 bits, mais encore faut-il en trouver

- Sam3X (Arduino Due) : DAC 12 bits

Ensuite le signal sera entre 0 et 3.3v, pour balayer +/- 10 V, il faut donc le balancer dans un montage à base d'ampli ops, en recréant une alim +/- 10 V à partir d'un 5V (il faut un booster de tension + un booster inverseur). ça se fait mais c'est pas trivial...

Il y a une carte de Thanos qui fait ça aussi il me semble, s'il te reste un rein à vendre

Déjà t'as ça pour générer un +/- 9V : https://fr.aliexpress.com/item/4000714453558.html

ensuite reste plus qu'à faire un montage ampli op soustracteur + gain

Convertisseur-de-tension-DD1718PA-ADC-radiateur-LCD-broche-soud-e-3V-18V-5V-6-V.jpg

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.

Oui j'avais regardé aussi, et de mémoire c'était pas fou. Ce port est plus prévu pour configurer le drive depuis un PC que pour faire de la commande en temps réel. Bon si la position est récupérée autrement, 500 Hz c'est suffisant pour un FFB.

A voir si par l'entrée analogique, il y a moyen de régler un gain dans les paramètres.

Je viens de regarder la doc du AASD, en fait tu peux régler le gain et l'offset pour l'entrée analogique :

Pn189 - Analog torque instruction gain : 1-300 %/V

Pn190 - Analog torque instruction offset : -1500~1500 0 mv

Donc logiquement en réglant un gain de 66%/V et un offset de -1500 mV tu peux piloter le bousin entre 0 et 3 V

Les impulsions en quadrature de l'encodeur sont dispos sur CN2, donc tu peux les récupérer et les décoder directement sur la carte de commande, comme je faisais pour le RFR Wheel.

Tout dépend de ce que tu comptes utiliser comme MCU, mais 125KHz ça commence à faire beaucoup pour faire ça en soft (t'oublie tout de suite les AVR 16 bits). Il ne faut pas perdre de pulses. Cette librairie utilise les interruptions. Donc même si ça passe probablement sur un ESP32, ne pas oublier qu'il faut gérer des interruptions pour l'USB aussi (et éventuellement du wifi etc). Autant utiliser le décodage de quadrature HW disponible sur le Due ou Teensy 4.0. Et comme de toute façon on va faire un paquet de tours, le signal d'index n'est pas forcément nécessaire. Il faudra de toute façon des capteurs de fin de course.

N'importe quel MCU qui a de l'USB natif utilise les interruptions pour sa gestion, c'est parfaitement normal, il ne faut pas avoir peur

Je ne vois pas ce que tu comptes faire avec un PID. Mais de toute façon même si tu le mets sur une interruption, ça ne posera pas de problèmes. Il y a des priorités sur les interruptions sur la plupart des MCU modernes.

Que tu prennes un T4 ou un Due, je ne vois pas trop ce que ça change pour la gestion de la Load Cell.

Les 2 gèrent des encodeurs en HW, mais comme d'habitude le support logiciel côté Teensy est beaucoup plus sérieux et consistant.

Le Due je me demande pourquoi ils le produisent encore, il est hyper cher et ils n'ont jamais assuré le suivi du noyau sérieusement. J'avais il y a plusieurs années signalé des bugs dans le noyau, ils n'ont jamais été pris en compte ni corrigé.... C'est dommage car le Sam3X présente des caractéristiques intéressantes, notamment ses 2 DACS, qui vont te manquer sur le T4 si tu veux piloter le drive en analogique.

Ben si tu envoie une consigne de couple au Drive, c'est lui qui gère l'asservissement en courant. Côté FFB c'est pas du PID même si une combinaison d'effet ressort+damper+inertie ressemble de loin à un PID...

Le DUE fonctionne aussi en 3.3V, et l'ADS1256 (si c'est ce que tu as), fonctionne de toute façon en 3.3V niveau signaux SPI. Evite les levels shifters au maximum, surtout sur des signaux SPI qui peuvent monter avec une horloge à 2 MHz. Les levels shifters c'est pour les loosers qui utilisent des Arduino UNO et qui veulent l'interfacer avec n'importe quel capteur qui fonctionnera en 3.3V dans 99% des cas...

Le DUE n'est pas 10x moins bien, c'est sur que le T4 est un monstre, et il carbure sévère, et en plus il est moins cher. Mais pas de DACs pour lui.

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