Messages de Etienne

J'ai rippé sur mon clavier, qui a une latence pas trop mauvaise

mimaximax a écrit :

Mais du coup Etienne, si la latence est aussi peu élevée avec l'ensemble (non-intégré) VSD+STM+MMos, je ne comprends plus pourquoi on a totalement délaissé ce système... pas possible de faire des trucs genre reconstruction filter dessus ?

Parce que la VSD n'est plus fabriquée, parce que les évolutions sur le FW de la SimuCube ont permis de passer à des encodeurs SinCos et Absolus, qui ne seront jamais gérés par MMos, et parce que la plupart des gens n'ont pas envie de bricoler et préfèrent se laisser bercer par les sirènes du Marketing. En programmant un nouveau FW pour Disco ou même SImuCube, il y a moyen de faire plein de choses super

A propos de l'effet de la latence sur les effets liés à la vitesse, c'est très simple. Pour un jeu qui génère un effet de friction lui même au lieu de laisser faire le FW, le principe est le suivant (exemple pour le damping):

- le jeu mesure la différence de position entre 2 trames et en déduit la vitesse

- il envoie une commande de couple dans le sens opposé à la vitesse, proportionnelle à cette vitesse

- le volant réagit avec x ms de retard (c'est là que la latence intervient), il ralentit

- le jeu récupère une nouvelle mesure et en déduit la nouvelle vitesse (la latence intervient ici aussi) et diminue la commande de couple. S'il met trop de temps à récupérer cette info, le volant va trop ralentir, voir partir dans le sens inverse. Si le gain sur l'effet est trop élevé, c'est aussi ce qui va se passer.

Donc si la latence est trop élevée, le gain maximum de cet effet va être limité, et il y aura un effet de grain, voir des oscillations parasites si le taux de rafraîchissement du FFB est trop faible. Par exemple, il fut un temps ou iRacing rafraichissait le FFB à 60 Hz (16 ms de latence donc) et générait l'effet de friction en interne. Je ne sais pas où ça en est aujourd'hui, mais rajouter 20 ms à ces 16 ms c'est loin d'être négligeable !

Pour les effets de friction gérés au niveau du FW, le principe est le même, et plus le taux de rafraîchissement de calcul du FFB est faible, plus on va avoir le même genre de problème. Et une latence élevée, même s'il elle peut venir de plusieurs choses, peut aussi provenir d'un FW qui ne rafraichit pas le FFB assez souvent en interne.

Pour la perception directe des effets par rapport à ce qui se passe dans le jeu ou le temps que va mettre le jeu à percevoir que vous avez bougé le volant, je suis d'accord que 20 ms c'est pas forcément un gros problème. Mais par rapport au prix d'un DD et aux performance des autres volants (notamment les plus anciens !), là je trouve que pour Fanatec c'est plutôt embarrassant.

Je ne sais pas pourquoi Mika parle de friction, comme je l'ai dit elle est quasi inexistante sur les DD, et extrêmement faible au regard du couple des moteurs des DD.

Le RFR Wheel de M3RS2 a la latence la plus basse à mon avis parce qu'il utilise MMos et que son couple max est énorme (malgré la réduction, qui n'est pas très élevée).

Sur les DD la friction est négligeable. C'est sur les volants à réduction qu'on va en trouver, et normalement elle va être à peu près identique sur toute une production. Ce n'est pas la friction qui peut expliquer les différences de latence.

ilfreddo76 , je ne parle pas de percevoir directement cette latence (que certains perçoivent), mais de l'influence sur la qualité des effets de friction/inertie et d'éventuelles oscillations dans certains jeux

Stef Bord , la friction et l'inertie peuvent un peu jouer sur la latence parce plus ils sont élevés plus le changement de position va mettre du temps à survenir.

J'ai déjà expliqué plusieurs fois pourquoi 20 ms ça peut être vraiment problématique (dans certains jeux), il faut que je recommence ???

Il y a même des jeux comme Dirt qui ne proposent pas les mêmes menus de réglages de FFB suivant le volant qu'ils voient. Du grand n'importe quoi.

Sur le 1er, on touche le fond là, quand la bagnole tourne à gauche le simu prend du yaw sur la droite !

Bah t'as juste la meilleure latence mesurée jusqu'à présent, un truc de fou ! (presque étrange, ou alors c'est MMos qui fait ça car le STM reçoit directement les impulsions de l'encodeur et envoie les commandes par PWM, ce qui est probablement le mieux en terme de rapidité).

C'est clair que 15 N.m ça commence à faire, faut les tenir ! Comme je l'ai dit plein de fois, plus de couple ça sert surtout pour avoir des butées bien dures, pour simuler correctement les directions de certaines vieilles bagnoles ou de Karts.

On avait déjà fait les calculs pour l'inertie, la roue a beaucoup plus d'influence que l'inertie du moteur, donc au final c'est l'inertie de la roue et le couple max du moteur qui vont déterminer la mesure d'accélération. Pour moi ça ne sert pas à grand chose de la comparer entre les différents setup, et ce n'est pas non plus à mon sens une donnée pertinente sur la qualité du rendu du FFB (sauf si le couple est vraiment faible, là je parle de DD).

Kolwezi , pour le calcul du couple max sur ton moteur :

C_max = K_trms * (32.2 / R₂₀)

Donc pour toi ça fait C_max = 15.28 N.m

magicfr, Oui je t'avais renvoyé les modifs. Je peux te les renvoyer si besoin, d'après mes souvenirs et ce que j'ai relu sur le topic de feu rfr, j'avais enlevé les effets desktop et rajouté un damping pour les DD qui ont peu de friction.

Si j'écris les équations avec A = dV/dt accélération, J : Inertie, C couple, Cm couple moteur, Cf couple de friction :

J x A = Cm-Cf

Donc pour le test 1 tu vas mesurer A = Cf/J et pour le test 2 Cm-Cf = 0 d'où Cf = Cm. On en déduit J = Cf/A. C'est bien ça que tu veux faire ?

ça pourrait marcher, en admettant qu'on connaisse le gain entre force constante max et couple max afin de connaître Cm.

Même si le soft ne sert pas que sur les DD, la friction sur un DD est quasi inexistante, donc risque d'être difficile à mesurer. En plus on va être perturbé par le cogging (qui peut être intéressant à mesurer aussi cela dit).

Pour le test 2, il faudra peut être en faire plusieurs à des vitesses différentes, car Cf peut être composé d'une friction statique et d'une friction dynamique (non linéraire à priori). Peut être aussi mesurer le couple min pour faire bouger le volant afin de déterminer cette friction statique. Mais bon je pense que le cogging va compliquer tout ça.

Stef Bord a écrit :

Oui 900° avec les butées sur 900° également, encodeur 2500CPR Etienne ...

Ok donc effectivement je pense que le bruit de mesure de la vitesse vient des 2500 PPR, ce qui revient à 10000 CPR (ou l'inverse, je ne sais jamais). 10000 positions par tours ça veut dire qu'à 900° tu ne perds pas de précision par rapport à l'encodeur (900° pour 2^16 valeurs, ça fait 26214 positions encodables par tour, soit 2.6 x plus que ce que ton encodeur peut produire).

Très bon résultat à mon sens. A mon avis le bruit sur la mesure de la vitesse est à mettre sur le compte de la précision de l'encodeur. Tu as quoi comme encodeur ? Tu as réglé 900° comme débattement je suppose ?

Il faut que le "Max Lock" mis dans WheelTest soit effectivement le réglage de débattement utilisé, sinon les vitesses et accélérations mesurées ne sont pas à l'échelle (mais je viens de voir que tu l'as précisé).

Quand on vous dit que c'est plug and play, rien à faire tu branches et ça marche

L'autre après des années d'adultère avec la domotique, il vient de démonter son simu sur un coup de sang, et il se moque

Pour éviter de dire des bêtises, il faudrait que je me (re)plonge dans le code de magicfr qui a écrit RFRWheelTest pour être sûr de comment sont mesurés les différents résultats.

J'avais d'ailleurs fait des modifications à ce programme pour l'adapter aux problématiques des DD. Je suis en train de regarder tout ça et de tester sur mon volant à base de Leonardo.

21 ms de latence c'est énorme, ça pose réellement problème, notamment pour les jeux qui implémentent les effets de friction eux même à l'aide de l'effet force constante au lieu d'utiliser l'effet Direct Input qui est implémenté directement sur la carte de contrôle, voire au niveau du drive comme c'est le cas pour les Ioni ou SimuCube.

Les chiffres c'est important, encore faut-il mettre les volants dans les mêmes conditions. Il faut que l'angle de butée à butée soit le plus faible possible pour ne pas être dépendant de la résolution de l'encodeur (surtout quand on ne la connait pas...)

Le test sur le DD1 montrent une fréquence de rafraîchissement de 1000 Hz, donc 20 ms c'est vraiment étrange. Pour moi du damping ne peut pas expliquer cette latence.

Je crois qu'il comparait à Apple pour leur politique de vouloir enfermer les gens dans leur marque, en allant jusqu'au câble de recharge. Mais j'ai l'impression que malheureusement GD est sur la même voie.

oui c'est vrai qu'il y a aussi ça à prendre en compte.