Ici il faut déterminer le choix du type de moteur (servo, stepper, ...) et de son driver
selon les specs : couple, vitesse, etc...
Ici il faut déterminer le choix du type de moteur (servo, stepper, ...) et de son driver
selon les specs : couple, vitesse, etc...
Bon pour un proto, si on part sur un moteur peu puissant avec 3 N.m à basse vitesse et surtout 0,4 N.M à 1800trs
on aurait une force sur une vis à bille de pas 5mm, rendement 0,9 de = 0,4 N.m * 2 * 3.14 * 0,9 / 0.005m = 450 N = 45 kg
il faut que je refasse le calcul pour retrouver la force sous la pédale à partir de la force longitudinale (j'avais fait le calcul pour la force verticale).
Pour moi, le principe est une "pédale restituant un contre-effort sous un certain effort"
on a bien une vis à bille "réversible" qui transmet l'effort dans les 2 sens,
il faut donc un moteur contrôlé en couple.
J'ai beaucoup de mal à concevoir l'utilisation d'un stepper dans ce cas de figure...
J'ai un servo d'occas que je prévoyais pour mon tensionneur de harnais 2DOF en v2
il a une belle gueule de profil (de performance :B) puisqu'il ne perd pas de couple jusqu'à sa vitesse de rotation nominale
A : Intermittent Duty Zone
B : Continuous Duty Zone
edit : par rapport au stepper au-dessus, j'ai 6x plus de force à 3000rpm.
qu'en pensez-vous ?
Pour moi c'est une évidence qu'un stepper ne fera pas l'affaire. Entre le fait qu'il ne soit pas contrôlé en couple et le grain dont il est impossible de se défaire...
Après le 80st-m0425 risque d'être light mais au moins ça donnera une idée de est-ce que c'est viable.
C'est un 80ST-M02430
et il est à 2,39 N.m
avec une vis à bille de pas 5mm, rendement 0,9
► Force axiale vis à bille => 2,39 N.m * 2 * 3.14 * 0,9 / 0.005m = 2700 N = 270 kg axial
► F freinage sous le pied
Avec L = 2 x R et θ à 30°, on a la relation simplifiée suivante :
F freinage sous le pied= Cmoteur x 6,27 / pas
F freinage sous le pied = 2997N = 300 kg
ben, on est laaarge !!
(et avec 80st-m0425, ça donne 500 kg)
avec une vis à bille de 5mm, j'arrivais à dépasser la force du vérin avec un 80st-m04025 sur un seatmover longitudinal...
oh... t'as une photo du setup ?
quelqu'un pour vérifier le calcul SVP ? DIY - RFR Active Pedal : dimensionnement, calculs
ça c'était avec le stepper
RacingMat Une propal à partir de 172€ TTC livré gratuitement de Pologne jusqu'à moins de 200€ suivant si l'on prend le 400, le 600 ou le 750W avec le servo driver (amusant le 750w est moins cher que le 600W...)... A voir si le driver va bien pour notre application... Ce fait 100€ de moins sur la facture
400W couple nominal 1.27 Nm max 3,82 172€
600W couple nominal 1.91 Nm max 5.73 194€
La division du dessus 750 et 1Kw toujours autour des 200€ TTC et envoi compris.
750W couple nominal 2.4 Nm max 7.2 183€
1KW couple nominal 3.8Nm max 11.4 209€
super ! le modèle à 750W a le même couple que le 80ST
183€ ça le fait déjà beaucoup mieux et le vendeur est très bien noté >98%
par contre j'ai pas vu la provenance de Pologne (ce qui est super) : on voit ça où ?
Tu choisis le 750W avec le RS485 et la livraison apparait comme venant de Pologne RacingMat
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
peut-être faut-il se garder les 2 approches disponibles ? servo moteur VS stepper ?
J'aurai tendance naturellement à sélectionner un servomoteur car c'est naturellement pilotable en couple et donc plus simple à concevoir...
Mais je vois que tu es confiant sur l'approche stepper qui ont l'avantage d'être moins coûteux...
(je ne connais pas bien les nouvelles méthodes pour piloter les stepper en couple (Field-Oriented Control) ou aussi les Stepper Hybrid...)
Que penses-tu de ce combo : table + stepper + driver à 150€ ?
DIY - RFR Active Pedal : structure, pièces mécaniques
le driver peut faire le taff ?
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
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
tu peux contrôler en force ou en position, peu importe, vu que la formule du ressort lie justement les deux.
Le problème c'est qu'un stepper ne sera JAMAIS fluide...
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 :
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 :
Hello, je pense que ce n'est pas le comportement obtenu n'est le bon...
exemple 1 :
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 :
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 :
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
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 :
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 vais lire tout ça en détail mais le premier point 'pedale non assemblée' : il est prévu précisément pour ton cas de la vidéo où le moteur n'est pas solidaire de la pédale.
Le end stop virtuel modifie en effet la donne : il faut le désactiver pour le moment.
C'est important de valider les cas de test les plus simples avant de complexifier avec les ends stop. ☺️