DIY - RFR Active Pedal : programmation firmware

Hello,

j'ai fait un premier test rapide avec un esp32-S3, c'est une bonne base de travail très facile d'accès

pasted-from-clipboard.png

Le côté sympa, c'est que la carte à deux connecteurs USB :

• un connecteur qui simule un gamepad natif (HID device)
• un adaptateur USB/série qui permet la programmation, mais qui peut aussi permettre la communication entre le logiciel sous windows à écrire (pour capter les effets et la config) et le firmware

Les premiers tests m'ont permis de voir que la couche USB est calée pour envoyer les rapports hid à 1khz.

Le double usb permet de développer un protocole de communication série beaucoup plus simple que des rapports HID.

J'ai mis le code ici : https://github.com/manoukianv/FFBPedal

J'ai rajouté un language de communication par port série avec des exemples :

Les commandes sont INFO ou ABS, elles peuvent avoir des paramètres comme ABS qui prends : l'état 1/0 de l'abs et la durée de l'effet. Le séparateur des paramètres est le ":" C'est pour tester...

Lorsque le firmware a traité la commande, il renvoie soit un R (RESPONSE) soit un E (ERROR) avec des infos qui vont bien en fonction de la commande. vous avez une capture de demo en dessous.

Avec cette base, ce sera très simple de rajouter les commandes dont on a besoin.

pasted-from-clipboard.png

J'ai commencé à réfléchir sur l'ABS et sur les effets damper et friction et j'ai des questions :

*) ABS : le but va être de faire varier la position de la pédale à un ensemble de vitesse/position qui sont réglables par l'utilisateur, ca c'est pas compliqué.

Par contre, le fait que la pédale bouge va faire varier la pression lue de la pédale : quand elle va reculer, la pression va baisser et inversement en avançant... donc à pression constante sur la pédale, le signal du loadcell va varié générant une réponse sinusoïdale au jeu, je ne sais pas si naturellement nous allons compenser ces variations. Est ce que ca se produit vraiment comme ca dans une vraie voiture? est ce que vous voyez une formule mathématique pour que je puisse déterminer (de manière anticipée) cette réponse sinusoïdale pour "traiter le signal" ?

*) damper/friction : ces effets dans un moteur FFB sont là pour générer une force proportionnelle à la vitesse (pour le damper) ou une force constante dès que ca bouge, nous ne sommes pas dans le cas d'un moteur FFB standard Ce que j'ai fait pour le moment, c'est de calculer la forceDamper et la forceFriction, et je les retires à la force lue du loadcell. Ca me permet d'équilibrer les forces et ensuite j'applique la courbe de réponse force/position programmé (min force=min position, max force = max position). Vous en pensez quoi ? Une autres alternative serait de ne pas jouer avec les forces, mais de jouer avec les vitesses du moteur (fonctionnement des ffb avec des moteurs brushed). D'un point de vu mécanique, le côté force est plus proche de la réalité, mais je ne sais pas si c'est le meilleur scenario. J'ai lu beaucoup de chose sur la théorie des dampers, mais je suis preneur de vos avis

Carlton je ne peut pas te dire sur une vrai voiture, mais des quelques télémétries que j'ai vu de personnes utilisant les simucube, ce n'est pas compensé.

Moradness - ABS on the Simucube ActivePedals

Watch Moradness's clip titled "ABS on the Simucube ActivePedals"

clips.twitch.tv

Alors ca c'est une excellente nouvelle ! Ca sera beaucoup plus simple à coder

Tu as raison, on voit bien les oscillation du ffb sur la courbe de frein

J'ai joué un peu hier soir avec l'esp32 et l'arduino.

Finalement je n'utilise qu'un seul port USB, celui marqué USB sur la photo.

J'active sur ce port USB "2 fonctions" : le HID pour renvoyé les données au jeu ET le port série pour discuter avec l'interface sur le PC.

Le deuxième port me sert uniquement à débugger et à programmer l'esp32.

J'ai également commencé à faire un peu de répartition de charge entre les cores et mettre en place les timers.

Je suis en phase d'expérimentation.

Bon changement d'avis, j'ai tout passé en HID, même pour la communication.

Je mets en place des features, ce sera plus performant et plus proche de la norme des périf HID.

Salut,

J'ai regardé ton schéma et il y a quelques écarts avec ce que j'ai pour le moment :

le driver pour un moteur pas à pas (nema) se commande en step/dir

Je verrais plus tard pour mettre un encodeur sur le nema, si j'en mets un ce sera plutôt un capteur absolu type as5048 en SPI.

pasted-from-clipboard.png

Le petit progrès de la journée : mise en place de la communication entre l'esp32 et le TMC5160

pasted-from-clipboard.png