Posts by Etienne

    Cédric33 tu as testé ?

    Je pensais que ces vérins était réversibles. J'ai ici une vis à bille de pas 5mm et c'est réversible. Donc normalement avec le poids du simu les vérins devraient revenir en position basse.

    d'après mon expérience, la pédale bouge toujours un peu, donc un capteur de position voit la différence.

    En théorie oui, mais en pratique pour être précis sur une très faible course, il te faut une précision de mesure de malade (genre 24 bits réels), ce que tu n'aura jamais à moins d'avoir une électronique de la NASA (j'exagère peut être un peu, ces chiffres sortent d'un chapeau, mais c'est pour me faire comprendre).

    On en revient à la discussion qu'on a eu je sais plus où.

    On peut faire un accélérateur avec une LoadCell puisqu'avec un ressort l'effort est proportionnel à la compression donc au déplacement, et inversement tu peux capter la pression sur un frein avec un potar puisque le déplacement est lié à la force (ce que tu expliques dans ta vidéo).

    Mais en pratique, ça me semble beaucoup plus simple de faire un accélérateur (ou un embrayage) avec un capteur de position (potar ou hall), et un frein avec une Load Cell ou un capteur de pression dans un circuit hydraulique.

    Et j'ajouterai que je pense que la précision dont on a besoin sur l'accélérateur ou l'embrayage est moindre que sur le freinage, mais ça c'est une autre histoire.

    Bah pourquoi faire simple quand on peut faire compliqué ?

    J'ai vu aussi des pédaliers avec 2 maîtres cylindres sur le frein pour la répartition av/ar (alors qu'à ma connaissance qu'aucun jeu ne gère 2 inputs pour les freins av/ar).

    Mais bon, c'est joli (enfin il parait).

    J'ai eu quelques contretemps, mais j'ai mes protos de cartes fabriquées et je vais pouvoir m'y remettre cette semaine.

    Une des cartes que je vais proposer sera une évolution du shield de Pyroneous, elle pourra gérer 6 vérins et prendra en compte les fins de course pour la calibration.

    Mettez un fusible sur le circuit... sur une voiture, si trop de neige sur parebrise, le fusible saute, les moteurs sont protégés...

    Sauf qu'on ne connait pas le courant max (en tout cas je n'ai pas vu l'info), donc impossible de choisir le fusible.

    De toute façon ça ne résoudra rien, le moteur peu très bien accepter un courant pendant un moment mais chauffer quand même.


    En mesurant la résistance du bobinage tu pourra calculer le courant max à 24v, ce qui déterminera l'électronique nécessaire pour le piloter.

    En l'alimentant en 24 v, bloqué, le moteur ne va pas cramer instantanément. Il suffit de surveiller sa température pour voir si le bobinage est sous dimensionné.

    Je plussoie. Avec un Mige il ne faut pas de réduction (dans un sens ou l'autre soit tu perd la vitesse soit le couple).

    Je pense aussi qu'en mettant un peu de friction logicielle tu peux reproduire le ressenti de la courroie, ce réglage étant fait une fois pour toute (et non pas pour tous les jeux/bagnoles).

    Maintenant reste l'alimentation de tes moteurs de vibration. Je ne sais plus où on en était, je t'avais envoyé un convertisseur 5v -》 12v pour mettre derrière le récepteur à induction.


    Tu ne peux pas simplement dire "je ne veux pas débattre de tel aspect du projet (le côté déporté)", car c'est un aspect central qui conditionne tout le reste (du reste tu en es au stade de réflexion, donc ça coute rien).


    Maintenant si tu tiens absolument à rester sur ce principe de courroie, soit tu choisis un moteur qui présente un intérêt pour une réduction (vitesse élevée (par ex vitesse nominale de 3000 tr/mn à 220v), qui une fois réduite t'amène dans les 200 tr/mn à 48v), soit si tu veux un mige 30 Nm ça sera sans réduction.

    Il y a moyen de contourner la limite à 10000 de Dinput (d'ailleurs c'est +/- 10000, donc on est plutôt sur 15 bits), en utilisant l'offset plutôt que le gain.

    Le grain provient plutôt d'un encodeur dont la résolution est trop faible par rapport à la fréquence d'échantillonnage de la position. Une trop faible résolution sur la commande aura plutôt tendance à créer un effet de seuil ou des paliers.

    Avoir une résolution élevée sur la commande permet d'avoir un couple max élevé (pour les butées entre autre) sans sacrifier les micro détails

    Pour savoir si les gens perçoivent la différence, il faudrait faire des tests à l'aveugle (façon de parler :B)

    Etienne on sait le nombre de valeurs de commande FFB possibles sous SimuCube ?

    Entre les STM32, Les commandes de couple sont envoyées sur 16 bits par le bus rs485.

    Ensuite, en interne de l'Ioni, je ne sais pas quelle précision de pwm est utilisée mais même si c'est 16 bits, c'est probablement la résolution de l'ADC qui mesure le courant qui va limiter la résolution. Comme je n'ai pas vu d'ADC externe sur l'Ioni, je suppose qu'ils utilisent l'ADC interne des STM32, qui est sur 12 bits. Tout ça c'est pour la SC1. Pour la SC2 je ne connais pas l'architecture HW.

    C'est GD qui doit donner ces infos, mais à mon avis tout sera mieux sur SimuCube par rapport à Fanatec.


    Savoir que Fanatec était en 8 bits n'est pas du tout rassurant sur la qualité du reste du code/HW (c'est dans la continuité de ne pas parler de la résolution de leurs encodeurs qui ne doit pas être terrible). Ou alors c'est du marketing de merde (pléonasme) pour faire genre "vous avez vu on continue à améliorer notre produit, dormez gentils consommateurs, hein, quoi, quels problèmes de QR ?" :hihihi:

    Non tu confonds la résolution et la fréquence.

    Fanatec est passé de 8 bits à 16 bits, c'est à dire 256 à 65536 valeurs de commandes possibles pour le couple.

    Pour la fréquence de rafraîchissement, il y en a plusieurs :

    - Les 20 KHz de l'Ioni sont la fréquence à laquelle l'asservissement de courant est rafraîchit sur le STM32 de l'Ioni dédié à la commande de puissance.

    - et il y a la fréquence de rafraîchissement du calcul des effets FFB de l'autre STM32, qui est de 1000 ou 2000 Hz sur la SimuCube (je ne sais plus à combien elle est maintenant, il me semble qu'au départ c'était 2000 et il l'ont baissé à 1000).


    Je ne vois pas le rapport avec les 16 bits/44.1 KHz du standard CD pour le son(le son peut être encodé à plein de résolutions et fréquences différentes).

    Les éternelles questions qui reviennent :hihihi:

    Tu peux mesurer une force avec un ressort en mesurant l'allongement ou la compression.

    F = K . x

    C'est le principe des peses bagage manuels ou de certains anciens pese personnes.


    L'inverse est aussi possible, puisque

    x = F / K

    Donc, toujours avec un ressort, on peut mesurer l'allongement à partir de la mesure de la force appliquée au ressort.


    Mais bon, il faut reconnaître que c'est quand même plus logique d'utiliser une Ioad cell ou capteur de pression pour mesurer une force, et un capteur de position pour mesurer une position (potard, capteur hall, etc).


    Les load cell sont très sensibles aux parasites emi car les tensions a mesurer sont de l'ordre du millième de volts. D'ailleurs dans les Hx711 et consort, il y des filtres pour rejeter le 50 et 60 Hz, histoire de ne pas choper les ondes EM générés par les lignes 220v ( ou par votre corps qui les capte). A cause de ces raisons, Les 24 bits du Hx711 sont théoriques, et en pratique si on arrive à 14 bits c'est déjà pas mal.


    Les capteurs de pression hydrauliques sont plus faciles à mettre en œuvre au niveau électrique, pas contre le côté liquide genre huile et tout l'aspect étanchéité etc est délicat. Et puis le liquide de freinage étant incompressible, théoriquement l'aspect hydraulique ne va pas apporter quoi que ce soit niveau ressenti, à moins de mettre des durites qui se dilatent etc..


    Les capteurs à effet Hall (par ex AS5600) permettent de capter un angle et ont l'avantage de ne subir aucune usure. Par contre ça peut-être compliqué à mettre en place.


    Les potentiometres, s'ils sont fermés et de bonne qualité, peuvent tenir aussi longtemps que le reste, pour un cour modique (6€). Ça reste la solution la plus simple à mettre en œuvre.