[WIP] Scud Race vers PC

[njz3]

J'ai commencé la transformation d'un twin Scud Race arrivé d'un roadtrip en savoie (merci à Amano J pour son accueil et son aide !) que j'ai migré vers un racecab avec émulateur PC. L'idée est de conserver la structure, le panel avec volant et l'électronique de pilotage du moteur, et la partie sono avec son ampli.

Ecrans
Pour l'instant je souhaite garder les CRT, mais comme je galère trop à y connecter un PC avec le coup du 24kHz, je les ai remplacé par des LCD incurvés. J'ai trouvé des Philips 31,5pouces 325E1C qui font 71,2cm qui viennent épouser le bezel par l'extérieur une fois monté sur un pied.
C'est 100% réversible (aucun dégats sur le Bezel), mais pas intégré de manière très robuste pour les bourins (en même temps, un LCD sans glasse de protection ca reste bcp plus fragile qu'un CRT...).
Temps de retrait du CRT (en étant seul) : 30min.
Temps de mise en place du LCD : 5min.

Choix et mise en place du PC
J'ai opté pour l'achat de 2x HP 400 G1 au format SFF qui rentrent pile poil à la place du stack et surtout qui ont la place de mettre une carte graphique low profile type Nvidia 1050Ti LP qui occuperait 2x slots PCi.
Pour l'instant mes tests ont été fait avec une 1030 LP qui semble suffire pour avoir du 60fps dans la plupart des émulateurs et des jeux Teknoparrot.
Les caractéristiques PC sont:
- Intel i5-4570
- 8Go de RAM, 500Go HDD
- alim de 240W (non remplacable)
- carte graphique 1030LP
- Windows 10 x64
- carte son 4 canaux (CMI8738) avec équerre Low-Profile à 9€ sur les sites de marchands en ligne.

Le PC est placé proche de l'alim Model 3 d'origine qui reste en place pour alimenter l'Arduino (5V) et driveboard (5V&12V).
Les sorties son de la carte PC (jack 3,5mm) sont reliées directement aux connecteurs CN7 et CN8 allant anciennenement vers le stack. Le son est quadriphonique selon les jeux, stéréo sur supermodel ou Model 2.

Connexion du PC
Un arduino Mega2560 est placé à côté du PC et j'ai directement connecté les CNXX via des fils dupont sur le Mega2560.
Un ULN2003 est utilisé pour piloter les lampes.
Les infos sur mon soft de pilotage se trouve maintenant ici

Schémas électriques
Merci à hdangvu qui nous a donné un beau scan des diagrammes (schematics) du twin Scud en version UK :





Historique
- nov. 2019, les photos à réception :



Hier soir j'ai passé quelques heures à faire un état des lieux et du repérage. L'idée est d'avoir un maximum d'infos sur ce qui est bon et pas bon avant de tout démonter comme un sauvageon.

La borne n'a pas de stacks, les deux alimentations sont grillées et les bas de caisses ont quelques goujons arrachés et pas mal de rouille à certains endroits (heureusement peu visibles).
Les sides en plastique sont également abimés et les coques de siège sont fissurés.
Au niveau électronique, j'ai essayé une alim model 3 fonctionnelle que j'ai d'un Le Mans, et les driver boards de chaque side m'affichent toutes les deux un code Er 22 après rotation du volant à gauche et à droite. J'ai dans l'idée de creuser un peu avant d'éventuellement migrer vers une carte variateur (je bosse en parralèle sur le pilotage de moteur brushless par un arduino Due+driver FET).
Les écrans semblent fonctionnels.

Avant d'aller plus loin, je suis déjà confronté à un petit soucis mécanique sur un des sièges.
Le rail avec levier d'un des sièges est complètement arraché au niveau de la patte faisant office de blocage de la translation (là où il y a normalement un ressort).
J'ai dans un premier temps remplacé les rails du siège endommagé par d'autres qui conviennent aussi mais qui ne sont pas des originaux Sega.

- déc 2019: j'ai réparé les 2x alimentations model 3 en panne. Un simple refluage de certaines soudures à suffit à les faire refonctionner.
- jan 2020-mai 2020 (confinement): j'ai surtout travaillé sur du logiciel et l'interfacage avec vJoy sur PC (voir mon soft de pilotage). Il a fallu reprendre le code de vJoy pour corriger des bugs, écrire un feeder vJoy qui permette de recevoir les trames de FFB, et enfin traduire les effets de FFB vers des commandes qui permettent de piloter une driveboard Sega. Des essais avec la driveboard d'origine avec l'EPROM Scud Race n'ont pas été concluants sur la qualité de la commande en couple.
- juin 2020: j'ai fait ressoudé par un pro les rails de siège d'origine qui étaient cassé. L'état est impeccable et on jurerait qu'ils n'ont jamais été cassés. J'ai aussi récupéré des pièces faites en découpe laser pour fixer des volant en 70mm ou 50mm. Il y a des retouches à faire, ce sera pour une v2. Les bornes ont été démontées intégralement pour un gros nettoyage et un déménagement dans mon sous-sol.
- juillet 2020: un single a été remonté et j'ai pu continuer mes essais de pilotage. En passant sur une EPROM Sega Rally 2 il est possible d'avoir un bien meilleur contrôle en couple du volant. J'ai donc laissé à demeure l'EPROM de SR2.
- septembre 2020: achat de PC au format SFF pour les mettre physiquement à la place des stacks.

[njz3]

Petit follow-up

Bon en fait pour les alimentations, finalement elles ne sont pas grillées du tout.

En démontant complètement la carte d'une alim (retrait des dissipateurs), j'ai vu qu'un composant type transistor ne tenait pas bien en place... à priori la dilatation thermique a fait lâcher les soudures.






Et il y avait clairement besoin de refluer certains plot de soudure, dont ceux de ce composant.




Après remplacement de la graisse thermique, remise en place des refroidisseurs et remontage, le composant est bien en place :


L'alim s'allume correctement, et tout fonctionne !


Au final, j'avais trois alimentations model 3 en rade (2 scud et 1 lemans), et j'ai pu récupérer les trois en ressoudant le même composant + quelques soudures.

Seul soucis qu'il me reste, les alimentations restent éteintes quand il fait trop froid dans mon garage ;-)
Peut être un soucis de condo, mais la solution est facile il suffit de chauffer la pièce à plus de 5° !

Est-ce que quelqu'un aurait un schéma électrique complet d'un twin scud race ?

[njz3]

Concernant le rail de réglage de siège cassé. J'ai mesuré les dimensions suivantes :
- entraxe des vis M8 de fixation partie fixe (caisse) : 28cm
- entraxe des vis M8 de fixation partie mobile (siège) : 30cm

Je n'ai toujours pas trouvé de rail neuf, et le seul d'occasion que j'ai trouvé se trouve à 450km et le transport va plomber le prix.
Est-ce que vous pensez que ce type de composant peut convenir ?
Rail siège sport

Dans la même veine j'ai trouvé cela :
Rails siège

Pas sûre que cela soit compatible...

[njz3]

Enfin pour les volants.
A défaut de réparer les actuels en mauvais état, je me demande si l'un d'entre vous a déjà essayé de monter un volant sport classique.

Par exemple, j'ai trouvé celui-ci en aluminium qui contient en plus 4 boutons à câbler, mais qui a un diamètre un peu grand par rapport aux originaux :
Volants lowcost

Est-ce que cela peut ensuite se monter avec un 'hub' de réduction pour revenir à un diamètre compatible ?

[Iro]

Avec une platine d’adaptation home made çà se monte. Par contre la taille du volant sur les cabs SEGA correspond à des volants de karting. J'avais monté un MOMO pour voiture (320mm) et c'était trop grand à mon gout.
Surtout que sur le cab SEGA , le volant est plutôt vers le bas, le volant était trop pres des cuisses et trop bas.

[njz3]

Merci Iro pour ta remarque sur la place restante. C'est vrai aussi qu'avoir un grand volant va diminuer l'impression de couple pour le conducteur, mieux vaut rester dans une taille d'origine.

Je viens de mesurer : sur la lemans, le volant fait effectivement 270mm (11pouces), comme celui d'un kart.


Sur la scud race, par contre il font 300mm, donc ni 11 pouces, ni 13 pouces.


Alors, dans le même style en 300mm il y a celui-là :
https://fr.aliexpress.com/item/33052964263.html

[njz3]

Bon le temps passe et j'ai pu faire le remontage du siège avec un rail de remplacement que je viens de recevoir
L'idée était de mettre un rail standard de siège auto, qui en général ont un perçage d'entre-axe à 28cm de chaque côté.

Ceux que j'ai pris coutent une vingtaine d'euros frais de port inclus. Le transport les a un peu rayés, mais globalement ils sont fonctionnels.


La course est limitée : j'ai +/- 7cm de course au lieu de +7/-11cm sur les rails d'origines.
Pour les fixer, j'ai finalement opté pour l'utilisation des trous d'origines au lieu de repercer à 28cm. Cela m'a permis de pouvoir décaler la fixation au maximum et donc retrouver pratiquement le recul d'origine (pour les petits, il faudra pendre des coussins pour compenser !). Les fixations sont faites avec des boulons M8x16mm et M8x20mm. J'ai du ajouter des rondelles larges pour compenser une boursoufflure de soudure de qlq mm d'épaisseur au niveau de la poignée et pour bloquer l'extrémité. On verra à l'usage si cela tient !

Voilà la fixation sur la platine côté fauteuil (rappel : entreaxe de 30cm). A noter que la poignée va être inversée par rapport au rail d'origine car les nouveaux rails ont la poignée à gauche sur la base mobile.



Une fois remonté sur le siege avec la visserie, pas de soucis particulier hormis cette histoire d'épaisseur à compenser par des rondelles.


Les rails étant noirs, cela donne un bon rendu.



Pas de soucis particulier à l'usage. La manette s'active facilement et on arrive bien à glisser le siège.
Ca fait le job et ca me permet de pouvoir remonter l'ensemble et de continuer !

A noter que j'ai trouvé des clips plastiques très proches de ceux d'origine pour refixer les coques de siège et pour les mousses.

[njz3]

Au niveau de la gestion du volant pour mes futurs 'racecab', je vous expose mes idées.

J'ai d'abord essuyé quelques essais infructueux avec le programme d'Etienne sur Leonardo. Oui, tout le monde semble y arriver mais moi j'ai déjà eu énormément de mal rien qu'à télécharger le code et configurer le bidule ! Ensuite impossible de piloter mon variateur ... Et enfin difficile de pouvoir changer la linéarité ou les zones mortes du retour de position du volant, par exemple pour faciliter l'utilisation du volant dans des jeux comme MarioKart NGC/Wii qui demande une gestion spéciale de la linéarité du joystick.

Vu que je cherche une solution ouverte pour pouvoir modifier le code et en particulier gérer à la fois le retour par potentiomètre (moteur le mans) et codeur (moteur Scud), j'ai finalement jeté mon dévolu sur vJoy et son API d'émulation de manettes avec récupération des commandes de force-feedback.

C'est vraiment simple d'utilisation et rapide à prendre en main. Pour l'instant, je suis parti de l'exemple de Feeder en C# qui me permet de remonter les infos des potentiomètres des pédales et du volant et d'avoir le retour des informations de force-feedback (les 12 "effets" gérés en natif par Windows et les périph HID).

Dans mon idée, les informations de force feedback seront directement interprétées par le code PC qui génèrera les effets (machine à état) et émettra des commandes en couples de manière périodique et les enverra au variateur que l'on choisit, ce qui allège le code embarqué et le réduit au plus simple. Il existe des variateurs avec entrées PWM (comme ceux de Granite Device), mais également en RS232, CAN, USB, Ethernet/EtherCAT, ... Bref il y a le choix.
Les interfaces matérielles type IO seront faites avec des arduinos : Leonardo et Due. Pourquoi ceux-ci ? Parce-qu'ils gèrent en natif de la communication USB port série et qu'on peut donc attendre des débits de plusieurs MBits sans problème de CRC, de perte de trames, de mauvais cablage. Cela simplifie l'utilisation au niveau soft et n'ajoute pas tant de latence que cela.
 
Evidemment Windows et l'USB n'étant pas fait de base pour de la commande temps-réel, il ne faudra pas trop en demander au niveau réactivité du retour haptique. Je sais d'expérience que Windows est tout à fait capable de gérer des échanges périodiques à quelques millisecondes via les API multimedia (ex: claviers midi en USB) et donc peut facilement envoyer des ordres à plus de 50Hz à un périphérique tiers (on peut même descendre jusqu'à un temps de cycle de qlq ms). Par contre, il peut y avoir parfois du lag en fonction de la charge CPU.
C'est le point noir de ma solution, mais on verra en pratique le jour où ces limitations feront réellement obstables. Sur mon PC actuel (Ryzen 6 coeurs 12 threads), j'avoue n'avoir pas encore vu de limite CPU avec les émulateurs actuels que j'ai pu essayer.
Avec le couplage électromécanique de nos bornes Sega, il y a un filtrage mécanique naturel qui me fait dire qu'à partir de 100Hz, on aura de toute facon du mal à transcrire des effets haptiques.

Mon architecture hardware/logicielle sera donc la suivante :
1) une ou plusieurs cartes que j'appelerai "IOboard" sur base Leonardo ou Due : au moins une pour gérer les boutons et les potentiomètres, l'autre pour faire l'interface avec le variateur (cf mon autre sujet de travail). Ces cartes auront un code simplifié à l'extrême et enverront des trames "human readable" pour rafraichir périodiquement leurs données ou en recevoir. Pour l'instant je pars sur du 10ms de temps de rafraichissment (100Hz).
Le but est de pouvoir facilement concevoir ses propres IO board en fonction du besoin. Types de données : tout ou rien en bits pour les infos digitales (type bouton ou relais), sur 12bits ou plus selon qu'il s'agisse de codeur ou d'entrée analogique. Pour le variateur : à déterminer selon le matériel et sa couche de pilotage. Seul du filtrage anti-rebond (boutons), passe bas (analogique) ou anti glitch (codeur) sera intégré sur ces cartes.

2) une application feeder sur PC en C# qui :
a. fera la lecture de données de(s) IO Board(s) par USB et la mise en forme des signaux : gestion des zone-morte centrales, application de transformation de type linéarité/log/exp sur les valeurs analogiques, saturations et remise à échelle des signaux. (10ms)
b. enverra de manière périodique la mise à jour des données vers vJoy (feeder, 10ms)
c. recevra les commandes FFB de vJoy (dépend du logiciel/émulateur qui envoit des données à son rythme)
d. fera la gestion des effets FFB dans une tâche périodique quasi temps-réel (10ms), enverra les commandes de couple au variateur via un port de communication dédié.

3) l'interface joystick vJoy sera exposée aux émulateurs/jeux PC. Pour l'instant j'ai prévu de déclarer : un axe X (volant), un axe RY (accel) et un RZ (frein), 32 boutons pour se laisser de quoi faire.

Pour l'instant j'ai fait la preuve fonctionnelle pour 1), 2)a., 2)b., 2)c. et 3). Mais il me manque encore la partie 2.d).
En gros : j'arrive sans problème à jouer avec m2emulator, supermodel mais sans FFB car je n'ai pas encore la partie variateur...
C'est la suite du chantier !

Note : si 10ms (100Hz) ne suffit pas, alors on baissera la période. Dans mes essais, je descend sans problème à 4ms ou moins, mais c'est au détriment d'une charge CPU et de communication qui est peut être superflue pour ces pauvres arduinos.

[Amano J]

Pfiou ça c'est du WIP ! 👍
J'ai pas tout compris mais ça me plaît 😄

[SDF]

Salut, bon déjà, gg, super projet, ça promet et en plus t'a l'air de savoir de quoi tu parles.
Ce qui m'amène à mes questions:
- Tu parles de compatibilité avec les volants de lemans et de scudrace, 2 technologies différentes. Est ce qu'il faudra donc un type de variateur différents pour chaque système ou bien, tu penses que ca peux fonctionner avec un seul type de variateur pour ces 2 systèmes?
- Quel le prix d'un variateur compatible avec une lemans, PWM donc, il me semble? Et, t'as une ref? Parce que là, j'suis perdu face au nombre incalculable de variateurs.
- Il faudra garder les drive board et motor drive board?
- T'as besoin de béta testeur? Parce que moi aussi, j'ai essayé la solution du soft d'Etienne et je galère, ça marche que dans les emus model 2/3, rien sur les logiciels windows.
Merci.

[njz3]

Salut,
@Amano: ca avance pas vite, mais merci à toi de m'avoir donner accès au matos ;-)

@Nene2k10:
- compatibilité entre les deux moteurs : tu as raison il faudra deux bases variateurs différentes selon le moteur lemans ou scud si l'on se base sur une solution sur étagère. En réalité, c'est le même mode de pilotage pour les deux moteurs (sortie en tension PWM vers les phases) et uniquement le retour du signal de position angulaire du rotor qui est différent (l'un par potar, l'autre par codeur).
Malheureusement je ne connais pas de variateurs sur étagère qui savent gérer le retour analogique du lemans. D'où mon projet de faire mon propre variateur qui fonctionnera avec les deux moteurs en changeant juste le mode de traitement du signal d'entrée (logiciel+cablage). Ca vient, patience !

Au passage, après réflexions je pense savoir pourquoi la résistance est élevée sur les moteurs lemans (~90ohm) ou le scud (~12ohm). La raison est que ce sont des moteurs prévus pour fonctionner principalement en mode commande de couple et quasiment à l'arrêt (courant constant). Le bobinage est fait avec des fils à section très très faibles (donnant ces hautes valeurs de résistance de bobinage). La tension de force contre électromotrice doit être élevée en conséquence, mais comme on ne tourne pas vite, pas de soucis.
Ces moteurs sont prévus pour fournir un couple plus qu'acceptable (presque 3Nm sur la lemans en 48V), tout en consommant un faible courant afin de diminuer les échauffement par effet joule (Pthermique=R.I^2). De plus, pas besoin d'une sécurité sur le couple max, sur la sur-intensité courant ou sur-échauffement au niveau du variateur. En gros, même en cas de défaut sur le variateur (tension bloquée au max), pas de danger pour l'utilisateur, le moteur ou la machine. C'est bien la première fois que je vois des moteurs conçu comme cela. Bien joué Sega !
Sur le scud, on devine que pour faire baisser les coûts ils ont pris un moteur sur étagère qui lui consomme pas mal de courant (probablement 2 à 4A). Comme il doit pas mal chauffer il y a un gros ventilo...

- prix d'un variateur : bin ca dépend. Au minimum compte 160€ pour l'ODrive (version 2 moteurs) qui est le variateur du marché le moins cher que je connaisse. Ca reviendrait à 80€/moteur sans compter le câblage et les cartes d'IO supplémentaires pour faire passerelle. C'est pourquoi je regarde la solution alternative Arduino Due+DRV8302 qui reviendrait au même prix mais avec plus de flexibilité.

- drive-board/motor board d'origine : si le projet d'Aganyte d'avoir une carte passerelle générique converge, alors pas besoin de variateur ! Ca fait des économies ! Du coup y'aurait même juste qu'à remplacer la carte d'Etienne par la solution purement logicielle vJoy et du coup les coûts deviendraient ridicules...

- pas encore besoin de testeurs. Tu verrais mon bureau il est plein de fils partout ! Impossible de t'envoyer un tuto. Je peux uniquement te faire essayer la partie sans Force feedback avec un Leonardo si tu veux utiliser ton volant sans FFB dans quasiment tous les émulateurs/jeux. Mais bon dans ce cas je pense que tu peux déjà le faire avec le soft d'Etienne, non ?

[SDF]

Effectivement, ça fonctionne déjà nickel sans FFB.
Pour un driver, j'avais vu ca : driver

Vu les tensions/ampérages que tu m'annonces ça devrait être compatible, non?

[njz3]

Oui c'est compatible avec ce que l'on cherche !
Ca serait clairement une deuxième piste après la solution Due+DRV8302.
Le seul inconvénient de cette carte c'est que la mesure de courant ne se fait que via un seul 'shunt'. C'est à dire qu'on ne peut reconstruire le courant dans chaque phase moteur. Un peu moins facile d'un point de vue implémentation, mais cela reste en théorie utilisable. Autre soucis: je n'y connais encore rien en programmation chez STM !

Pour la solution avec le soft d'Etienne : est-ce que tu gères le retour codeur de la lemans via l'émulation codeur par un second arduino branché sur le potar ? Et les zones mortes des pédales, ça marche bien dans autre chose que m2emulator/supermodel ? Moi ca m'a trop posé de problème, d'où mon switch vers vJoy...

[Aganyte]

- drive-board/motor board d'origine : si le projet d'Aganyte d'avoir une carte passerelle générique converge, alors pas besoin de variateur ! Ca fait des économies ! Du coup y'aurait même juste qu'à remplacer la carte d'Etienne par la solution purement logicielle vJoy et du coup les coûts deviendraient ridicules...

J'attends les pcbs prototypes depuis plusieurs mois.....

[njz3]

C'est loin la Chine ...
Et entre le PC et ta futur PCB montée sur Arduino, tu utilises la solution d'Etienne ou plutôt celle de BigPanik à base de lecture d'octets en mémoire des emulateurs ?
Il faut que je mette mon code C# du feeder vJoy sur github pour que tu puisses regarder et me dire si les 12 effets remontés via Windows/vJoy seront transcodables vers ta carte.

[Aganyte]

Je pensais laisser libre court à l'utilisateur, une entrée pwm+dir et zou...