Simracing DIY

Règles du forum
Cette section est dédié a vos projets, descriptions et demandes d'aide.
Merci de limiter le nombre de sujet par projets.
Lorsqu'un sujet deviens long vous pouvez éditer le premier message pour maintenir à jour le descriptif et garder en lisibilité
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1636
Enregistré le : 01 mars 2017, 20:46
Contact :

Simracing DIY

Messagepar Flax » 15 janv. 2022, 13:44

EDIT : j'ajoute une photo prise ce jour.

Il se trouve donc que je me suis mis à la simulation automobile sur PC. J'ai prévu d'en parler dans des articles détaillés sur mon blog, mais il faut que je trie le bazar d'information que sont actuellement les brouillons que j'ai commencé, et ça m'embête de ne pas avoir de trace écrite, donc je fais un post ici, que j'agrémenterai au fur et à mesure de mes avancées. Et ça va me permettre de faire un peu de pédagogie autour de ce domaine qui est ... intéressant, je trouve.

"Simracing" c'est quoi-t-'est-ce ? Il s'agit du terme usuel pour parler de simulation automobile sur ordinateur (ou console). C'est un domaine assez large, qui part du simple fait de jouer à des jeux de course "sérieux" (comprendre : un peu plus réalistes que Ridge Racer ou Mario Kart) à la simulation ultra-pointue avec cockpit complet, mais globalement dès qu'on a un volant à retour de force correct ça rentre dans cette catégorie. Le niveau d'implication dans la simulation va de pair avec le réalisme des jeux pratiqués, mais aussi avec la complexité du setup hardware. Je vous laisse chercher sur Google, mais les équipement de simulation peuvent monter dans des dingueries assez velues, avec des simulateurs qui valent 6 ou 7 chiffres en euros. Exemple : https://www.youtube.com/watch?v=UnmXrCl9FBQ

(J'ai entendu parler du projet d'un ancien membre du CA du Lab qui voulait faire un simulateur 360° :diable:). Moi je ne vais partir dans des trucs aussi compliqués, mon but c'est juste de jouer dans de bonnes conditions.

Je vais faire un petit tour d'horizon, pour donner du contexte, avant de parler de mes projets en particulier.

Quels jeux ?

Un peu de contexte donc. Moi je joue à des jeux de simulation de course de rallye, donc c'est la cible de ce projet. En particulier je pratique les licences suivantes:
  • Collin McRae DiRT et DiRT 2.0 de chez Codemasters : la référence historique franchisé du roi d'Ecosse de la cabriole :p Très réaliste (surtout le 2.0) et plutôt cool à jouer, quoique très difficile. Je joue principalement au premier opus car le 2.0 demande un PC assez costaud et ma carte graphique actuelle a un peu de mal à l'encaisser, et vu la pénurie de GPU actuelle je ne suis pas prêt de l'upgrader. C'est très orienté "rallye historique" avec beaucoup de caisses anciennes (Alpine A110, Escort MK1 et MK2, Mini période BMC / British Leyland, Lancia Fulvia ...). Les "suites" DiRT 2, 3 et 4 ne sont pas vraiment des simulations, beaucoup trop kikoo pour ça, et c'est pas mon truc.
  • WRC : la "licence officielle de la FIA", moins chiadé techniquement que DiRT (graphismes moins soignés, audio moins flatteur), mais à jour au niveau bagnoles, pilotes et circuits. C'est une franchise pseudo-annuelle, proche du principe de FIFA. La dernière version (WRC 10) a ajouté des rallyes historiques avec des caisses plus anciennes, ce qui le met en concurrence avec DiRT. Niveau réalisme c'est controversé, les bagnoles sont quasi-indestructibles et la physique est bizarre, par contre il parait que la simulation du comportement des pneus est inégalée. Moi je n'ai joué qu'au WRC 7, je l'ai trouvé cheap comparé à DiRT, je n'aime pas trop le feeling, mais bon, ça se laisse jouer.
  • Richard Burns Rally : un vieux tromblon de 2004, qui est tombé en abandonware, ou du moins qui n'a pas été claim par un éditeur quand des version custom ont commencé à apparaître sur le net. Il y a même un ancien développeur du studio d'origine qui a filé un coup de main pour le modder, ce qui fait qu'il est maintenant fortement pimpé. Niveau graphisme et son il accuse son age, par contre niveau réalisme c'est pas mal, c'était une référence à l'époque (contrairement aux jeux Colin McRae de l'époque qui étaient plutôt foireux niveau gameplay), difficile, limite sans pitié. La version la plus couramment utilisée est une compilation faite par des hongrois, avec un installateur automatique, plein de plugins pré-installés (amélioration du son, de la physique, meilleur support des contrôleurs récents...), pléthore de caisses et de circuits (100Go de contenu à télécharger), intégration avec leur site qui organise des compétitions en ligne ... C'est un peu casse-pieds à configurer, mais franchement ça vaut le coup de tester, et c'est gratuit donc pas cher.

Voilà, c'est ça les cibles de ce projet.

Par ailleurs j'ai aussi acheté Assetto Corsa et Forza Horizon 4 en promo au black Friday, mais ils ne m'ont pas convaincu de passer à la course sur piste. Je n'aime pas trop ça, en fait, et Forza Horizon est vraiment trop kikoo, c'est insupportable ...

Volant

Le premier accessoire pour entrer dans le monde merveilleux du simracing, c'est le volant à retour de force. Le marché actuel est assez restreint (je trouve) et se divise en plusieurs catégories en fonction de l'implémentation:
  • Les volants sans retour de force, que je ne traiterai pas, c'est du gadget et c'est hors-sujet ici.
  • Les volants retour de force "entrée-de-gamme" avec moteur à courant continu et transmission par engrenage ou courroie, typiquement Logitech G23, G25, G29, Thrustmaster T150 et T300. En particulier les Logitech et le T150 sont en moteur courant continu et engrenage, le T300 en moteur brushless et entraînement par courroie, ce qui est un peu plus qualitatif et robuste que Logitech, même si ce n'est pas non plus radicalement différent. Compter environ 300-400€ pour ce genre de volant.
  • les volants retour de force "haut-de-gamme" avec le volant branché en direct sur l'axe d'un moteur brushless, communément appelé "direct drive". La marque phare dans cette catégorie est Fanatec, et les prix commencent dans les 600€ et montent très vite à plus de 1000€. Le direct drive est très prisé par les fanatiques de la simulation, car il permet d'avoir un couple monstrueux sur le volant (moyennant un moteur et une alim qui le sont tout autant, on parle de 500W minimum) et un force feedback très réactif, en plus de ne pas avoir de friction dû à l'entrainement, donc résultat plus convaincant. Par contre ça coûte une blinde, il y a intérêt à avoir un support bien rigide pour le fixer, sinon c'est un coup à casser son bureau. Ou son bras, d'ailleurs, les accidents ne sont pas rares avec ces volants.

Je m'étais renseigné sur les projets de direct drive open-source, et je n'ai pas trouvé grand chose de probant. Il y a des solutions pas open (la marque Granite est souvent citée) pour se fabriquer son propre direct drive à base d'énormes brushless de 1000W+, qui me semblent surtout une occasion d'acheter des brushless "pas chers" sur Aliexpress, un peu du genre des servos qu'on a monté sur la Charly et Maurice (d'ailleurs, sur les pages produit des moteurs mis en exemple dans ces projets, les commentaires clients indiquent que le simracing est une usage ultra-majoritaire). J'ai également trouvé moult projets avec "open" dans le titre, qui sont autant open-source que mon *** ! Genre ya un vague plan mécanique donc c'est open-source, ou le logiciel est filé en freeware (après inscription obligatoire sur un forum !) donc c'est open-source, mais bien sûr. Au mieux on a de l'assemblage d'éléments propriétaires (souvent Granite, donc). Clairement, le concept d'open-source tel qu'on le connait est très brumeux et mal compris dans ce milieu, et souvent confondu avec "DIY".

Exemple :
http://opensimwheel.wikidot.com/
La plupart des composants sont propriétaires (cartes, servos ...), l'élément le plus important, le contrôlleur de FFB n'est pas open-source, c'est un allemand qui l'a bricolé dans un coin, et pour récupérer le binaire il faut avoir un compte sur le forum virtualracing. Comment dire ...
Ce contrôlleur est un truc qu'on retrouve souvent, qui s'appelle MMos.
https://granitedevices.com/wiki/MMos
https://forum.virtualracing.org/threads ... ler.92420/
Bon, voilà le genre de truc "open" qu'on trouve. Ca laisse à désirer.

En VRAI open-source je n'ai trouvé qu'un seul projet vraiment abouti : openFFB. C'est porté par un allemand, à base d'un ASIC Trinamic pour la régulation du moteur, et d'un STM32 pour la supervision et la com avec le PC, sur une carte custom et ça supporte moteurs DC, pas à pas et brushless. J'étais parti à modifier ce projet : le hardware est sous Eagle - beurk ! - donc je voulais le porter sous Kicad, et faire quelques modif, car le form-factor ne me plaît pas, ni l'ergonomie des connecteurs, et vu les difficultés pour obtenir des composants STM32 et Trinamic (et les boîtiers merdiques) je comptais aussi l'adapter pour les cartes d'évaluation plutôt que les composants en direct. Mais l'ampleur de la tâche m'a calmé, et le coût total aussi.

Dans un deuxième temps, j'ai découvert l'existence de la librairie SimpleFOC pour Arduino, et j'ai eu envie de tester, car elle supporte les moteurs pas à pas et a l'air relativement accessible. J'ai bricolé un driver de stepper "indus" pour commander les gate des MOS en direct. Je commençais à faire de la commande basique mais j'ai bêtement crâmé la carte, ce qui m'a mis un coup au moral.

Donc j'ai arrêté de m'emmerder et j'ai acheté un T300.

Note concernant le force feedback : j'en ai profité pour regarder un peu comment est géré le force feedback dans la norme USB, il y a une classe de device PID, qui prend des informations de mouvement qui ressemblent à de la CNC. Les device PID peuvent être commandés en direct, amis on peut aussi leur envoyer des "patterns" un peu complexes qu'ils gardent en mémoire volatile sur une session, et qui peuvent être appelés comme des sortes de presets / mémoires. Intéressant comme mode de fonctionnement. Bien entendu, comme tout device USB, le protocole est une tannée à gérer.

Et au passage, fun fact, dans la partie HID de la norme USB il y a une liste d'applications "standard" pour contrôleurs, disponibles en natif avec des configurations pré-existantes. Et dans ces nombreuses applications, il est prévu entre autres ... un contrôleur pour tapis volant :)

Pédalier

Concernant les pédales, il y a un peu de choix, même si ça reste limité comme pour les volants. En gros les pédaliers vendu avec les volants sont en général très basiques (celui du T300 ne fait pas exception : plastique cheap et seulement deux pédales) mais des alternatives existent, là aussi plus ou moins luxueuses et réalistes. A noter qu'il y a plusieurs façon de "modéliser" la résistance et le comportement des pédales. Pour reproduire la résistance physique, on peut utiliser un simple ressort, la méthode la plus cheap, convient bien pour l'accélérateur et l'embrayage, surtout que c'est ce qu'on a sur les voitures modernes. Pour plus de réalisme on peut aussi mettre un vérin, soit fermé, soit carrément avec un circuit hydraulique, ce qui est pas mal pour simuler la résistance d'un circuit de freinage et permettre de faire jouer le mémoire musculaire. Pour capter la position de la pédale, on a soit un capteur angulaire optique ou bêtement à base de potentiomètre, ce qui marche bien pour l'accélérateur et l'embrayage, mais pour les freins il vaut mieux mesure la force appliquée par le pied, et utiliser une jauge de contrainte (communément appelé "load cell" en simracing) ou carrément mesurer la pression de liquide si on a un circuit hydraulique. En gros : ressort c'est pas cher et simple, load cell c'est mieux mais plus cher, pression c'est roxxor et le système devient compliqué. Perso j'ai pris le pédalier Trustmaster (TM-LCM) avec load cell sur le frein, pour avoir une pédale d'embrayage et aussi parce que c'est quand-même mieux que le pédalier merdique qu'ils donnent avec le T300.

Je n'ai ni la place, ni l'envie d'avoir un rig ou un chassis dédié, donc je vais jouer avec ma chaise de bureau à roulettes, donc il faut maintenir le pédalier pour qu'il reste à peu près droit et qu'il ne se barre pas quand j'appuie sur les pédales. J'ai fait simple et ai juste acheté du tasseau en chêne chez castomerlin, avec un petit système de fixation à base d'écrou papillon en M6. Thrustmaster fournit bien entendu les dimensions et position des perçages disponibles sous le pédalier, il n'y a donc qu'à s'aligner dessus.

pedal_fixture_01_small.jpg
pedal_fixture_01_small.jpg (437.08 Kio) Vu 12438 fois


pedal_fixture_02_small.jpg
pedal_fixture_02_small.jpg (463.22 Kio) Vu 12438 fois


BIEN ! Partant de là, je pouvais déjà m'amuser :) Mais je me suis dit que, quand-même, je pouvais me fabriquer d'autres accessoires, et on en arrive ENFIN, après cette intro longue comme un jour sans chocolat, à mes projets.

Frein à main

Comme je joue à des jeux de rallye, le frein à main est un accessoire très utile (SKRRRRRRT !), car le mapper sur un bouton sur le volant n'est guère pratique à l'usage. C'est donc le premier accessoire que j'ai fabriqué. Il en existe dans le commerce, mais c'est soit du aliexpress cheap et venu de l'autre bout du monde, ce qui m'embête un peu, soit c'est trop cher, et puis c'est plus sympa de fabriquer soit-même. Pour simplifier j'ai décidé de partir sur un levier vertical, "comme dans les vraies", parce que c'est plus simple à fixer sur le bureau, et plus pratique à manipuler.

Pour la partie méca, je suis parti sur de la quincaillerie castomerlin, un "serre-joint de marqueterie" pour fixer sur le bureau, des plaques de fabrication de meuble, des équerres, et du profilé carré en alu pour le manche. Un interrupteur fin de course pour détecter la position, et pour la touche final : du grip de guidon de vélo de course pour faire une poignée :) Pour transmettre l'activation au jeu, j'ai utilisé une carte d'évaluation STM32 (évidemment) qui fait de l'USB, se déclare comme un device HID et envoie un appui de touche, et je mappe cette touche dans le jeu, et ça marche bien.

Boîte de vitesse

Le passage de vitesses aux palettes c'est très moderne, mais c'est quand-même plus marrant d'avoir un levier de vitesse. Donc je suis parti à faire un levier de boîte séquentiel, dans un premier temps parce que plus simple à fabriquer, mon objectif étant de faire un levier en H, pour correspondre aux vieilles merguez qu'on peut conduire dans ces simulation. Pour boîte séquentielle, j'étais parti à faire une étoile, "comme une vraie", mais j'ai calé sur la fabrication, un peu trop compliqué. Donc je me suis rabattu sur une architecture à base de double ressort. C'est "moins réaliste", mais ça fait le taf.

Comme pour le frein à main : castomerlin. J'ai fait un peut d'usinage pour la jonction entre le manche et la tige, et pour les guides en plastique pour la tige j'ai fait des alésage à la tête à aléser sur la PF. C'est pas parfait, mais ça fait le taf, à encore. Pour la partie électronique, même chose que sur le frein à main : interrupteurs fin de course que je branche sur la même carte, qui centralise et envoie les appuis de touche. Vu que les trames USB HID "report" peuvent contenir jusqu'à 6 appui de touche, j'ai dédié un byte par entrée (frein à main, vitesse supérieure, vitesse inférieure) comme ça je peux faire du N-key roll-over :p

Par rapport au frein à main, j'ai aussi tâché de modifier la façon dont la fermeture du fin de course se fait, de façon à ce que le levier de l'interrupteur soit "dans l'axe" de la pièce en mouvement, et pas à 90°, ce qui évite que l'interrupteur se fasse écraser en cas de "défaillance" ou de mauvais réglage des fins de course mécanique.

Mon premier prototype:

gear_seq_01_small.jpg
gear_seq_01_small.jpg (384.41 Kio) Vu 12438 fois


Le joint entre le levier et la tige horizontale avec les ressorts était vraiment merdique. Donc je l'ai modifié, j'ai fabriqué une petite pièce à base d'une chute de carré alu de la taille du dessus du levier, j'ai fait une gorge, et j'ai usiné un petit cube en plastique enfoncé à force dans cette pièce, puis j'ai percé et taraudé pour que ça se visse sur la tige horizontale:

gear_seq_02_small.jpg
gear_seq_02_small.jpg (414.29 Kio) Vu 12438 fois


Pour faire un pommeau, j'ai récupéré une vieille poignée dans le tiroir des poignées de machines, qui se visse sur du M10. Donc, j'ai pris un boulon en M10, je l'ai limé pour en faire une tête carrée, et je l'ai enfoncé à force dans le profilé alu :)

gear_seq_handle_01_small.jpg
gear_seq_handle_01_small.jpg (444.08 Kio) Vu 12438 fois


gear_seq_handle_02_small.jpg
gear_seq_handle_02_small.jpg (444.91 Kio) Vu 12438 fois


EDIT : Après ébavurage et chanfreinage des bords coupants, voici don à gauche le levier de vitesse, et à droite le levier de frein à main:

gearseq_handbreak_final_01_small.jpg
gearseq_handbreak_final_01_small.jpg (402.16 Kio) Vu 12406 fois


Pour le levier de boîte en H il faut que je clarifie mon archi mécanique, pour l'instant c'est trop brouillon.

Dash

Ensuite je me suis dit que tant que j'y étais ça serait pas mal d'avoir un petit écran pour visualiser des télémétries, la vitesse, régime moteur etc. Un tableau de bord déporté, quoi. Et que cet écran pourrait faire "hub" pour récupérer les entrées des accessoires.

J'ai quelques cartes Discovery STM32F746 avec écran tactile que je gardais "pour plus tard", c'est le bon moment pour jouer avec :) J'ai regardé s'il était compliqué de développer une interface graphique, me doutant que ST propose des solutions user-friendly pour aller avec leurs librairies et STM32CubeIDE. De fait, il se trouve qu'ils ont visiblement racheté la boîte qui développait TouchGFX, et maintenant c'est un outil qui s'interface (presque) de façon transparente avec STM32CubeIDE, et il est gratuit avec une licence relativement permissive (en tous cas suffisamment pour moi). Donc je suis parti là-dessus.

Note : comme pour les autres accessoires, on trouve des "dashboard" tout-faits dans le commerce, parfois les mêmes qu'on met dans les vraies voitures pour la vraie compétition peuvent être utilisés avec les jeux, mais c'est beaucoup trop cher pour ce que c'est, c'est full-propriétaire, et encore une fois : je préfère faire soi-même, c'est plus sympa.

Ici c'est le jeu qui envoie les infos à la carte. Pour beaucoup de simulations (pas uniquement de bagnole d'ailleurs) le jeu peut générer des télémétries qui sont émise sur un port UDP. L'idée est donc de récupérer ces télémétries et de les afficher sur un appareil, LEDs, afficheurs 7-segments, écran...

J'ai hésité à faire lire les trames UDP en direct par la carte, vu qu'elle dispose d'une interface Ethernet, mais j'ai peur de m'embarquer dans une histoire pas possible, et ça ferait deux câbles à connecter (un Ethernet et un USB). Or, j'aimerais bien simplifier et n'avoir qu'un seul câble, donc l'autre solution c'est d'avoir une communication "custom" entre le PC et la carte, et avoir un logiciel qui tourne en tâche de fond et fait le pont de l'UDP vers cette liaison custom. Le plus simple c'est de faire de l'UART via USB (VCOM), les cartes Discovery le font nativement sur leur port de debug, et à terme mon idée est de faire un device composite HID + VCOM sur un seul port USB, pour avoir un seul câble qui envoie les infos d'appui de touches de la carte au PC, et les infos de télémétrie du PC à la carte. Je pourrais aussi tout faire via l'UART, et faire générer des appuis de touche au logiciel-compagnon en réponse à des commandes UART de la carte (à tester).

Concernant le logiciel de conversion, pour commencer j'ai repris un code Python qui s'appelle pyGauge. Il est basique mais il fait le taf : extraction des données intéressantes dans les trames UDP pour les multiplexer dans des trames UART, qu'il suffit de décoder au niveau de la carte. Je l'ai bricolé pour le faire fonctionner avec Richard Burns Rally, il faut que je checke sur WRC7.

C'est bien pour commencer, mais ce soft a deux gros défauts:
1) Il est en Python 2.7 et je préfèrerais qu'il soit en Python 3, parce que je n'aime pas la dette technique. Ca se traduit principalement par le fait qu'il utilise asyncore, qui est deprecated en Python 3 et remplacé par asyncio, qui n'a pas du tout la même API,
2) Il consomme le port UDP ce qui fait que le port n'est pas disponible pour une autre appli qui tournerait en parallèle, par exemple pour logger les télémétries.
C'est un bon POC, mais pas utilisable de façon pérenne.

Par ailleurs j'aimerais bien utiliser un programme d'enregistrement comme DR2_logger et il se trouve que celui-ci est en Python3, utilise socket et du threading pour dépiler les trames, ce qui me semble un meilleur choix. En plus l'architecture est un peu plus "rationelle" je dirais, avec un découpage des sources qui a du sens. Je pense qu'une bonne solution est de modifier ce programme-ci, pour y ajouter la communication série vers la carte externe, et ajouter une interface graphique.

Pour l'interface graphique je pense utiliser wxPython, que j'ai déjà utilisé au taf donc je connais un petit peu.

Plus généralement, j'ai d'autres projets pour lesquels je vais avoir besoin d'une interface sur PC pour configurer et contrôler des cartes électroniques via de l'USB et/ou de l'UART, et j'ai bien envie de profiter de ce projet-ci pour faire une sorte de plate-forme que j'adapterai en fonction de l'application finale. Le faire en Python ne me semble pas si pire.

A noter qu'il existe déjà des logiciels "tout-faits" pour s'interfacer avec les télémétries en UDP et les transmettre à des accessoires via UART, USB, etc. Encore une fois : c'est propriétaire, moi je veux un truc que je peux modifier comme je veux. Juste pour référence, je pense à des trucs comme SimHub

Concernant le code embarqué, j'ai un peu joué avec TouchGFX, qui est une bonne usine à gaz, mais qui reste compréhensible, et relativement bien documenté. Ca a beau être du C++, j'arrive à m'y retrouver, c'est dire. Le développement de l'interface en elle-même se fait via un logiciel dédié TouchGFX Designer qui génère automatiquement le code embarqué, et créé même un projet pour CubeIDE qu'il n'y a plus qu'à ouvrir et compiler. Ca gère les images, la transparence, les polices de caractères ... C'est ultra-pratique, il y a même un simulateur pour voir comment ça se comporte. je recommande chaudement. Il y a des alternatives, mais pas aussi permissif au niveau de la licence.

Ça donne de jolies interfaces (moyennant mes talents limités en design visuel):

dash_interface_02.PNG
dash_interface_02.PNG (22.82 Kio) Vu 12438 fois


Et concernant la mécanique, il faut que je fabrique un petit support pour tenir l'écran droit. Pour le moment j'ai juste découpé un vieux calendrier, c'est du provisoire mais il faudra que je fasse quelque chose de joli et solide.

dash_support_01_small.jpg
dash_support_01_small.jpg (486.11 Kio) Vu 12438 fois


dash_support_02_small.jpg
dash_support_02_small.jpg (457.95 Kio) Vu 12438 fois


Voilà où j'en suis. C'était un peu long et confus, désolé. C'est ce sur quoi je bosse depuis quelques mois.

Le setup complet actuel :

full_setup_01_small.jpg
full_setup_01_small.jpg (392 Kio) Vu 12438 fois


Et le voici en action :p

https://youtu.be/3N7_Behzg6I
StephaneH
Electrolab::Membre
Messages : 2
Enregistré le : 08 sept. 2023, 19:17

Re: Simracing DIY

Messagepar StephaneH » 09 sept. 2023, 15:04

pas mal.
et une version soudee comme benjamin workshop ? je suis pret a souder. https://www.youtube.com/watch?v=KUSxRTp4nCM
Avatar de l’utilisateur
Eric
Electrolab::Référent
Messages : 481
Enregistré le : 09 mars 2017, 10:09
Localisation : Electrolab
Référent : Zone Élec

Re: Simracing DIY

Messagepar Eric » 12 sept. 2023, 16:17

Hello Flax,
Plutôt sympa comme projet. C'est un domaine que je connais pas (même pas de nom, c'est dire).
Par contre je suis tombé récemment et par hasard sur ce revendeur d'accessoires pour simracing.
https://simline.eu/en/

Pour un truc un peu sympa, il doit être possible de faire un siège/poste de pilotage qui bouge en 3D, comme les sièges d'une des attractions du Futuroscope, non ?
Ahhh, je me disais bien que d'autres avaient eu ce genre d'idée :
https://www.xsimulator.net/community/th ... axis.9249/
https://deltakinetic.com/motion-simulat ... -platform/
https://dofreality.com/

Mais sur ces sites, ce qu'ils vendent c'est des trucs d'appartement commandés par des moteurs électriques. C'est probablement lent et/ou avec une faible course.
Avec des vérins hydrauliques classiques de mini-pelleteuses à 160 barg de course conséquente (400-700 mm) pilotés par electrodistributeurs, ça doit être plus sympa comme sensations sur une plateforme 6DOF.
Pour que ça bouge vite, faut prévoir une pompe hydraulique qui débite pas mal (25-40 l/min), donc alim triphasée requise. Mais ça au Lab, il y a.
Les calculs de cinématique inverse sont pas trivaux.


Eric
... n'est jamais dans la démesure
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1636
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Simracing DIY

Messagepar Flax » 18 sept. 2023, 10:34

Alors on va se calmer tout de suite : vous, vous faites ce que vous voulez, mais moi j'ai pas la place :nono: Et pas le temps ni l'envie.
C'est sur ça donne envie ces setups "de luxe" mais bon, à un moment il faut prioriser :)

Retourner vers « Les Projets »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité