DIY - quel type d'asservissement pour développer un bon FFB (débat)

Ah ok, on en avait deja parler sur l'ancien forum

Comment ça on a perdu la trace où Léo m'insulte parce que j'ai copié son travail ?

Il n'en n'était pas sorti grandi de celle-là...

Etienne a écrit :

Mais à l'occasion j'ouvrirai un topic pour parler de ça (ou un gentil administrateur fera le déplacement), parce que là on a bien a pourri le topic de Carlton avec un truc qui a rien à voir.

hop, le ménage est fait : si besoin tu peux même renommer le topic

C'est intéressant ce topic. Moi pour essayer d'ouvrir un peu je déteste devoir rajouter des effets côté matériel. Je pense que plein de simu calculent mal leurs effets ou alors c'est pas trop mal calculé côté pneus mais derrière c'est mal géré dans les liaisons les bras de suspension la crémaillère... C'est là où on doit avoir de la friction et c'est la géométrie de suspension qui doit amener de la stabilité (essentiellement la chasse mais aussi le pincement et le carrossage)... Bref si c'était bien fait. Ça devrait être plus smooth côté avec ou sans les mains dessus et sans effet supplémentaire.

bonjour messieurs, dame

Je suis passé en mode silence depuis 4/5 mois, parce que j'ai arrêté de coder et je me suis pris pour un pilote, mauvais je l'accorde

Petit focus sur le vesc 4.2 et la version PWM que tu avais testé Etienne, il y avait un bug dans la détection de l'inductance et du linkage, qui faisait que le gouverneur prenait la main sur le capteur de position : bilan au lieu d'utiliser le capteur de position de position, il la corrigeait avec une position théorique, d'ou l'apparition d'un cogging. la règle des 5C

Un pwm 32b c'est bien pour commander un générateur de courant, mais j'ai comme un doute sur la capacité des systèmes à transmettre / recevoir ce signal de manière qualitative entre deux carte. je l'ai vu en écrivant le décodeur coté vesc, soit tu fais une sale lecture adc (beurkkkk), soit tu fais une lecture de longueur de cycle, mais il faut avoir une clock sacrément bien calé pour avoir de la précision : 16khz * 2* 2^32 ca fait beaucoup... sans compter que quand tu n'as plus de signal, tu ne sais pas détecter de 0 parce que tu n'as plus de tick sur un signal de synchro. On arrive à faire des choses, mais je ne trouve pas ca propre : passage au CAN.

je me replonge donc le code avec pour but d'améliorer dans un premier temps le moteur ffb avec des technos que j'ai sous la main. En l'occurence celui d'openFFBBoard : contrôle par courant en regardant de plus près ce qui se passe avec les filtres. Les filtres numériques sont grisant et les développeurs vont vite dans la mise en place, mais comme en audio, quand on commence à rajouter des filtres, sur des filtres, avec des booster de gain qui rentrent dans des filtres, il reste quoi à la fin ? Et bien comme tu dis Etienne : du caca

Alors pour commencer, je ne crois que ce que je vois et on n'améliore que ce que l'on mesure, donc je commence à la base, j'ai rajouté un monitoring de FFB qui permet de mesurer ce que l'on a comme effet et leur volume max, parce que s'il n'y a pas d'effet conditionnel et bien la donne est plus simple, c'est au jeu de se débrouiller avec ce qu'il recoit comme info (la position). Et bien les choses évolues : je commence à voir du damper, du spring...

Je prends donc les sujets dans l'ordre, il faut une lecture de position et de vitesse de précision et quite à y etre, autant prendre l'accélération par les cornes. Si le capteur est borgne, aucune chance que l'effet soit roi et HiFi. Et comme je suis une bille en math, bein j'ai codé un truc visuel... Il est maintenant pour moi in-envisageable d'avoir un moteur FFB sans réglage fin de l'encodeur, on peut mettre autant de filtre de construction/reconstruction, limiteur de gain et autre booster, si le signal est pourri, il est pourri et comme les effets sont calculés à partir de ce signal : FAIL.

J'ai modifié une version du firmware pour y coder les settings qui vont bien dans la partie de capture de position et de calcule de la vitesse/accel. Un pas de geant dans le ressenti du volant, je sens immédiatement les variations de damper en jeu, les survirages, et je peux compter les zones rouges et blanches des vibreurs dans les mains... Parce que franchement, caller la réponse d'un système FFB pour que ca marche avec encodeur 2500cpr, ca n'a juste aucun, mais aucun sens.

Pour mettre en lumière ce que tu cries haut et fort depuis longtemps Etienne, (attention anglophile, vos oreilles vont saigner)

Dans un second temps, j'ai prévu de regarder le temps de réponse en couple dans un système fermé. La linéarité de la reproduction du couple permettra de maximiser le ressenti. Je vais tester le loadcell en mode balance, avec un arbre sur l'axe pour mesurer deux choses. Premièrement la linéarité de réponse sur une commande "full torque" ca devrait permettre de mesurer aussi les latences et les effets des pi(d) des algos de foc. Puis dans un second temps des mesures 0-10%, 0-20%, etc. et voir si je peux sortir une map prédictive de réponse de couple pour booster les signaux si les systèmes de production physiques sont trop mou. Si ca marche, je l'intégrerait au firmware à la mode LUT.

Voilà ou j'en suis dans mes réflexions et développement, et au plaisir d'être lu et challengé pour progresser