Messages de Carlton

Parfait, c'est ce que j'ai fait

avec un stepper.

On pourra le remplacer plus tard avec une commande de couple des que j'aurai un BLDC de 57mm

ça y est, je crois que je commence à comprendre les différence de philosophie entre nos approches

Je comprends pkoi vous voulez commander en courant le moteur : l idée est que Le moteur apporte une résistance différence et que de cette résistance en découle un mouvement.

Je suis parti sur une autre philosophie : par défaut le système bloque la pédale à la position actuelle, plus on essaie de la faire bouger dans un sens ou l,autre, plus le moteur consomme de courant pour maintenir la position. Pour bouger, le moteur doit recevoir une variation de la charge, il calcul la futur position et déplace la pedale a la position en question...

Peut être que le résultat final sera le même. Pour votre version, j ai pas le matos pour le faire, et il faudra coder beaucoup de mécanique, en particulier la force de force absorber par la vis à bille lorsqu on appuie sur la noix jusqu'au début de rotation de la vis à bille, il va falloir la mesurer, la contrer.

Est ce que vous avez une idée de pourquoi ma philo marcherai pas ?

Merci pour cette base de travail

Je n'ai pas de cas "pédale non assemblée" parce que j'ai codé des endstops vituelle et que je connais la position de la pédale pour les déclencher.

Dans la page 2, un point m'interroge sur le profil constant :

• hypothèse : je suis au endstop du début avec 1kg sur la pédale pour avoir le point d'équilibre.
• action : j'alourdit à 1.1kg pendant 3s et je relâche pour revenir à 1kg
• constat : le moteur a avancé et se stabilise en fin de course sans bouger
• conclusion : que l'on appui 1kg sur la pédale en début ou en fin de course on a la même réaction, mais pas la même position.

C'est le comportement attendu d'un volant FFB : le jeu envoie une commande de couple, il mets le système en déséquilibre et l'humain est en réaction de ce déséquilibre. Par exemple, quelque soit la position du moteur :

• le moteur génère une force de 1kg, et moi humain je dois mettre 1kg de poids sur le moteur
• si j'oppose moins, je moteur ce met à tourner de part le couple supérieure qu'il exerce sur mes mains
• si j'oppose plus, je fais tourner avec mes mains le moteurs.

Pour moi le comportement est inverse dans le cas de la pédale. L'humain met le système en déséquilibre, et, le système doit simuler une réponse physique : simuler soit un ressort, un fluide mis en pression, un écrasement de matière.

Ce que je comprends de tous ces cas, c'est que nous sommes dans le domaine de la compression : course = fn(force)

fn est linéaire dans le cadre d'un ressort (jusqu'à un certain point), logarithmique dans le cadre de compression de matière, etc.

J'ai codé le comportement le plus simple pour le moment, celui du ressort : course=force/raideur

• avec 0kg de poids je suis au début | 1.5kg je suis au milieu de la course | 3kg je suis à la fin
• Quand j'ai 1kg de poids constant je suis à 33% de la course du ressort
• Si j'alourdis à 1.1kg et que je stabilise, j'avance de 3.3% de plus immédiatement, et j'arrête le mouvement au nouveau point d'équilibre
• Si je retire mon pied, je recule au fur et à mesure de la réduction de la force jusqu'à la position 0 (pas de poids).

C'est le comportement que j'ai compris dans la vidéo que j'ai partagé de la config de l'active pédale de simu, mais je me trompe peut être :

pasted-from-clipboard.png

1 - force en kg du loadcell

2 - position de la pédale

3 - valeur renvoyée au jeu (valeur HID)

Est ce que si tu faisais une feuille 3 avec une simulation de la compression d'un ressort, tu décrirais le même fonctionnement que ce que j'ai partagé juste au dessus ?

Le capteur de pression est lu 4000 fois par seconde, et la position de la pédale est mise à jour 1000 fois par seconde.

Je n'ai pas compris ta réponse sur le pourquoi mécaniquement parlant la commande en couple est meilleure, tu peux de donner plus de détail ?

Pour aller dans la direction que tu évoques, j'ai codé un petit programme qui fait varier la courant entre 0 et 4A proportionnellement à la force du load cell. Le rendu est très très moyen :

• Si je fais tourner le moteur à la main, comme si j'appuyai sur la pédale qui fait tourner le moteur, je n'ai aucune résistance, c'est normal j'ai pas de force en contre
• Si j'applique un courant proportionnel à la loadcell, ca merdouille aussi, au début ca tourne pas, ensuite ca tourne, sans s'arrêter et ca maintient pas la position...
• Donc en contrôle courant pur, ca fonctionne pas, il faudrait en fait avoir l'inverse, une force inverse proportionnelle à la pression. J'ai essayé et le resultat n'est pas concluant : je ne maitrise pas du tout la course de la pédale.

J'ai changé de phylo en commandant le vesc en position toujours en FOC, en utilisant le moteur PID de position. A régler c'est l'enfer, ca vibre dans tous les sens, le résultat en feeling est plus mauvais que ce que j'ai avec le stepper.

Je suis preneur d'un schéma de commande si vous avez une idée de la chose à coder précisément : autant j'ai aucun pb à coder un moteur FFB, un volant en controle de courant, la pédale avec un stepper... mais je n'arrive pas à voir la logique de l'algo de la pédale en controle de courant, ni coté esc, ni coté firmware...

Je vais voir ce que ca donne pour la fluidité, si c'est pas bon, je changerai, j'en suis la pour le moment :

Je n'avais pas vu vos messages au dessus, désolé

LeboisVR , tu as beaucoup plus étudié les pédales que moi, je me fie à ton expérience.

D'un point de vu mécanique, je n'arrive pas à comprendre en quoi la réponse de couple apporte le comportement attendu :'(

Sur la simucube, ils commandent bien en force=>position

Je pense que le cas d'usage de la pédale est différent de celui d'un volant.

Pour un volant FFB, on veut ressentir un couple dans les mains : un moteur brushless controlé par courant est la meilleur solution (le couple généré est linéaire au courant appliqué à la bobine). Le jeu ne demande pas au volant d'aller à une position, mais il envoie la valeur de couple à produire dans les mains du pilote. C'est pour ca que j'ai codé une interface entre OpenFFBoard et les VESCs, les vescs sont des contrôleurs dont le firmware est OpenSource et qui permettent de piloter le courant en utilisant l'algo du FOC. Il existe d'autre type de commande pour un driver brushless que le courant, il peut y avoir une commande en vitesse de rotation ou de position, mais en général, ce qui est codé, c'est une boucle PID qui fait varié le courant pour atteindre la vitesse ou la position de consigne.

Pour la pédale, le jeu ne nous envoie rien, on a déjà plus de liberté Ce que l'on cherche à avoir c'est un "mouvement" de pédale qui simule ce que l'on aurait eu dans la vie réelle. Je prends le cas simple de l'accel : le mouvement est celui de la compression d'un ressort : la force exercée sur le ressort provoque la compression de celui ci et la réduction de sa longueur. J'ai simplifié le problème en disant que plus j'appuie fort, plus la pédale doit reculer. Ca fonctionne en théorie à deux conditions : que la vitesse de déplacement soit élevée sinon on aura un feeling d'amortisseur (réduction du mouvement en fonction de la vitesse), et un couple de blocage suffisant pour que la fin de course simulée par le blocage du moteur bloque vraiment la pédale.

Je pense que c'est pareil pour le frein, sauf que l'on veut plus de possibilité de réglage pour simuler une position qui n'est pas linéaire à la pression. Ca permettra de simuler un fluide en compression dans un maitre cylindre, des plaques qui font une course avant de mordre le disque, etc...

Un moteur pas à pas à une conception justement faite pour restituer un déplacement. la conception est relativement proche de celle d'un moteur brushless : il n'a que 2 poles vs 3 sur un brushless. Ils sont désignés pour fournir un certain nombre de pas par tour, en général 200 (stepper de 1.8°). Les drivers de moteurs pas à pas, sont commandés en "pas" (step) et en direction (dir), ca permet de dire dans quel sens tourner et de combien de degré. Pour les commander il suffit "juste" d'envoyer le nombre d'impulsion qui va bien au driver pour lui dire de tourner du nombre de cran souhaité dans un sens ou dans un autre. On est très loin du principe de commande de couple d'un FOC. D'ou l'impossibilité de fabriquer un moteur FFB de pédale qui gère les deux modes à la fois.

Je ne suis pas certain d'être parti dans la bonne direction, mais c'est celui qui permet d'être économique

Je pense que simucube est parti la dessus aussi, mais sans ouvrir la bête pour voir combien de fil de commande rentre dans le moteur, je n'ai aucune certitude.

Par rapport au kit partagé, je n'aime pas du tout les drivers comme les DM556. Ils ont l'avantage d'être dans une boite fermée autonome, mais on ne peut pas les régler à souhait, ni savoir ou ils en sont : tu envoies le nombre de step que tu veux qu'il fasse et tu pries pour qu'il le fasse. Tu n'as aucun retour du système et souvent le signal généré est salle. Pour le reste, le nema23 de 3Nm, le rail et la vis à bille, j'y crois

La société Trinamic fabrique des puces drivers de moteurs pas à pas qui sont très qualitatives pour un rapport qualité prix imbattable. Tu en trouves sur les imprimantes 3D, les CNC, les robots médicaux, etc. et on n'a pas de sensation de "step" au mouvement.

Celui que j'ai choisi, le TMC5160, permet de monter assez haut en terme de courant, de pouvoir gérer un encodeur pour corriger la position réelle du moteur par rapport à l'attendu, de pouvoir aussi entièrement moduler la forme du courant généré pour optimiser le couple, et de le surveiller de près (temperature, court circuit, blocage du moteur, etc...)

Un TMC5160 vaut par contre deux fois plus cher d'un DM556.

Allez, assez de blabla, voila à j'en suis

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

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.

J ai 16 bits sans bruit a 4khz. je monte à 18 à 11kz en faisant une moyenne glissante sur 3 valeurs.

Le bruit est de l ordre de 0.0002g. Autant te dire que rien que le fait de prendre le loadcell dans la main. Ça bouge dans tous les sens en lecture brute.

Le cast : comme la lecture est sur un int qui passe de temps en temps à -0,001g (parce que mon offset de calibration etait pas top) il etait converti en 32764 parce qu il gardait le bit de signe dans le cast, donc on passait en valeur max.

comme j ai mis l'axe sur 16bit aussi sur kg, ça bouge vite

J ai une boucle de contrôle sur la qualité du signal, de l orchestration.

Pour le filtre j'en suis certain, l'ads a ce qu'il faut pour bufferiser le signal. Comme je moyenne 3 valeurs. je calme sérieusement le jeu au niveau du bruit. Ca serait dommage de se priver de la dynamique du signal.

Je rajouterai quoi qu'il arrive un filtre biquad dans la boucle d'acquisition, comme ca on aura la main paramétrer un low pass filter si on a un soucis.

Coté variation au début, c'est un bug, j'ai mal casté mon int de l'adc en valeur HID, du coup quand l'adc devient négatif (torsion inverse), le HID prends la valeur opposé, c'est ce que tu vois: c'est corrigé.

Pour la tension d'alim pour le moment j'utilise le 5v de l'USB. On peut utiliser une alim supplémentaire pour le loadcell 12v ou 10v, en. effet, au choix. Pour le moteur vaudra mieux du 36v. Par contre impossible de connaitre avec précision la vref de l'adc, elle n'est pas exposé. D'apres le schematic, c'est propre.

Le loadcell que j'utilise est hyper réactif, trop 3kg ca varie quand je souffle dessus ! :-D

Le voltage du load cell est le voltage d'alimentation du pont du loadcell : 5/15v

le loadcell sort ensuite une tension qui dépend de ses caractéristique : je prends toujours de 2mv/v, il sort donc 20mV en pleine charge quand il est alimenté en 10v.

C'est pour ca que le gain de l'ampli est super important, avec un gain de 64 on monte donc à 1,28v en entrée de convertisseur, c'est bien.

L'ads a un filtre intégré et un buffer, pas besoin de traiter le signal en amont

Voici un premier résultat d'intégration ESP32/ADS1256 loadcell 3kg - 2mv/v

pour le loadcell, un hx711 ou son copain de chez TI l'ads1232 ne sont pas suffisant.

Ils ont un débit de 80hz en 24bits, je suis parti sur un ads1256 (aliexpress) que j'ai acheté il y a quelques mois, sur le papier il tient 30kz en 24bits avec un gain de 64. Cela permet de lire propremement le loadcell alimenté en 10V et qui serait en 2mV/V.

Dans le code, j'ai prévu de le faire tourner à 3.5khz et j'ai callé la fréquence de calcul de la pédale et le HID à 1khz. Je fais donc une moyenne des 3 dernières valeurs de force pour calculer le FFB.

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.

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 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

Ca devrait le faire Etienne, mais je suis toujours partant pour une revue de code si tu as du temps.

Pour les autres du forum, je ne crache pas sur de l'aide, sinon, ca n'a pas de sens de faire de l'OpenSource...

J'utilise pour le moment "ESP32-S3-WROOM-1-N8R2(8M Flash/2SRAM)"

Je n'ai pas de soucis de mémoire pour le moment, je suis à 9%

je vais en remettre une couche

J'ai essayé de faire un calcul de couple moteur, alors j'ai cherché la puissance nécessaire à absorber. Je n'ai aucune idée si je suis dans le vrai :

à partir de ca : https://www.cours-et-exercices.com/2016/05/cours-…mission-de.html

Et que l’on part de l’hypothèse qu’il n’y a pas de perte

P = F * v (translation)

N. m/s

P =. T * r (rotation)

N.m rad/s

——————————————————————— Accélérateur———————————————————————————

Force ressort = 10N/mm * 40mm = 400N (pour un déplacement de 8cm avec un point d’accroche à 50%)

P(translation) = 400N * 0.04 / 0.2 = 80w (8cm de déplacement en 0,2s avec un point d’accroche à 50%)

P(translation) = P(rotation)

80w = 3Nm * r

r = 80/3 = 26 rad/s = 1500°/s = 4,16tr/s = 250tr/min

Donc a 250tr/min à 3Nm de résistance, on absorbe la puissance ?

Le nombre de tour en 0,2s

4,16tr/s * 0,2s = 0,832tr avec une 1610 => 0,83cm vs les 4cm attendus en comparaison du ressort, on a de la marge coté couple

——————————————————————— Frein ———————————————————————————

Force frein = 100kg * 2 * 9,80 = 2000N (pour un point d’accroche à 50%)

P(translation) = 2000N * 0.02 / 0.1 = 400w (4cm de déplacement en 0,1s avec un point d’accroche à 50%)

P(translation) = P(rotation)

400w = 3Nm * r

r = 400/3 = 133 rad/s = 7620°/s = 21,16tr/s = 1270tr/min

Le nombre de tour en 0,1s

21,16tr/s * 0,1s = 2,12tr avec une 1610 => 2,12cm vs les 2cm attendus en comparaison du ressort, on a de la marge coté couple

—————————————————

Avec un nema de 23 de 3Nm, j’ai l’impression que ca passe coté couple, sauf pour le frein qui aurait une course de pédale de 4,12cm avec un point d'accroche à 50%.

Si je ne me suis pas trompé, nous aurons une course plus courte sur le frein avec un 1605 et ca passe avec un 3Nm

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 mis le code ici : https://github.com/manoukianv/FFBPedal