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.
