DIY - logiciel FlyPT Mover Hexapod Interface (de 1 à 6 DOF)

    LeboisVR a écrit :

    Matt_Stealth je ne vois pas où régler précisément la résolution :/

    Le park est à -49mm comme habitude... C'est étrange... Mon code fonctionne nickel en 15 bits. J'ai des entiers longs partout et pourtant ça plante....

    Peut être qu'on ne parle pas de la même chose mais regarde sur le screen ci dessous concernant l'output bits :



    Pour le Park, si tu mets -49mm dans Mover sur les 4 actuateurs, est ce que tu as le même Park Position déclaré dans ton code ?
    Je demande car j'ai déjà rencontré ce "bug" avec la carte Thanos, si le Park de la carte et de Mover ne correspondent pas....problème :B

    Je veux qu'au lieu d'envoyer les datas de 0 à 1023, il envoie de 0 à 923 par exemple.

    Il y a la fonction scale qui fait un peu ça, mais elle modifie le min et le max en même temps... (De 100 à 923 par exemple).... Ceci dit je peux peut-être m'en sortir avec, en indiquant sur l'arduino que le min du vérin est 100 par exemple...

    En tout cas, c'est vraiment un logiciel génial !

    Wanegain a écrit :

    This is a great news !! But ideally it would be necessary to be able to visualize the curve of the reference as well as the curve of the potentiometers. In my Arduino sketch I put a function that allows you to retrieve all this information through the serial port.

    In my case I am not using linear actuators but DC motors with crank (rotation).


    Back to french because it can be interesting for everybody :

    Si vous faites un système de licence payante, j'aimerai pouvoir intégrer une licence lorsqu'une personne me commande un kit complet (je ne prends aucune commission sur les licences). J'avais demandé cette possibilité pour Simtools mais ça ne les arrangeait pas... Parce que dans mes kits, la seule chose qui manque c'est une licence pour un logiciel (avec les plugins) et c'est pas toujours simple d'expliquer qu'il faut acheter une licence sur un site, puis prendre un abonnement sur un autre site pour avoir accès aux plugins... Et puis j'ai l'impression qu'il y a une réelle valeur ajoutée au logiciel Mover par rapport à Simtools, où on peut aller beaucoup plus loin dans les réglages du simulateur !

    Il est possible de comparer dans le graphique, la position demandé at la position courante.

    J'ai pas d'image encore sur la nouvelle version, mais voici dans la premiere version du logiciel (2:30):

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Tu peu voire en rouge la vélocité envoyée vers le simulateur,

    en noire la position prétendue (resulta des informations q'on reçois du jeux)

    et en gris la position réelle des vérins du simulateur.

    La nouvelle version de Mover contient tous ça et fonctionne avec plusieurs maps de bits et la string defini par l'utilisateur pour envoyer et recevoir information.

    LeboisVR a écrit :

    FlyPT Est-ce qu'il est possible de mapper les valeurs de sorties vers l'arduino ?

    J'envoie les données en 15 bit à mon arduino (de 0 à 32767).

    Ensuite je les convertis de 0 à 67800. (mes vérins ont une résolution de 0 à 67800).

    J'aimerai que FlyPt envoie directement des données allant de 0 à 67800.

    Ça éviterait à l'arduino d'avoir à faire la conversion. Au passage, lorsque je passe de 15 à 16 bits, mon programme bug, le vérin ne s'arrête plus de bouger, pourtant mon programme sur l'arduino est sensé géré le 16 bits aussi bien que le reste... Si quelqu'un a une piste...

    Pour envoyer valeurs de 0 à 67800, tu as besoin d'utiliser 17 bits (0 à 131071). 16 bits arrive juste à 65535.

    Mais lá tu envoie 3 bytes. C'est peut être plus rapide de mapper les valeurs dans Arduino que utiliser 1 byte de plus pour chaque moteur.

    Mover n'a pas moyen de savoir à quoi correspond le 0 a 67800. C'est 100mm? 50mm? 100º?

    Alors quand tu defines que le vérin utilise 17 bits et à un range de 250 mm (500 mm parcours total), tu indique que -250 correspond à -250 mm et 131071 à +250 mm.

    Le vérin au milieu, la position zero, aura la valeur 65535.

    C'est la qui entre le "scale", mais pas pour ton problème.

    Tu peu changer le scale pour ajuster les valeurs.

    Avec un scale de 0.035, il est possible d'avoir un valeur maximum de 67829, mais alors, comme on utilise 17 bits, le milieu sera toujours les 65535, et le minimum sera 63241 au lieu de 0.

    Le scale est utilisé pour faire un match des distance réelles avec les distances présentés dans Mover.

    Alors, la conclusion, c'est que du doit faire le map dans l'Arduino.

    Et, dans mon opinion, du devrais passer au ESP32, beaucoup plus rapide, avec deux "threads".

    OK, est-ce que je dois modifier quelque chose dans le code Arduino pour que Mover reçoive les informations du ou des potentiomètres ?

    FlyPT a écrit :

    Alors quand tu defines que le vérin utilise 17 bits et à un range de 250 mm (500 mm parcours total), tu indique que -250 correspond à -250 mm et 131071 à +250 mm.

    Le vérin au milieu, la position zero, aura la valeur 65535.

    Petite erreur dans l'explication je pense.

    Il faut comprendre 0 = -250mm et 131071 = +250mm

    La position milieu de l'actuateur est 65535.

    J'en ai acheté un alimenté pour ne pas avoir de soucis et bein c'était quand même la merde, le mieux reste une carte sur le pci de la cm au moins pas de soucis de compatibilité ou d'alimentation de port

    salut,

    j'ai du mal a comprendre ces courbes:

    En noir: la courbe des informations du jeu , il s'agit de la position dans l'espace de position de la voiture donc du simulateur ? c'est ça ?

    en gris, c'est le mouvement du simulateur , qui devrait être parfaitement sur la noir ? puisqu'il doit suivre la courbe de télémétrie du jeu?

    la rouge je comprend pas , la vélocité du simulateur , c'est a dire ?

    Le souci vient probablement du manque de puissance.

    La solution est souvent de prendre un hub avec une alimentation secteur.

    L'imagination est plus importante que le savoir (Albert Einstein)

    Questions à FlyPT :

    1) Serait-il possible d'ajouter une option pour charger automatiquement un fichier au démarrage du logiciel ?

    2) Serait-il aussi possible d'ajouter une option pour que l'interface se connecte automatiquement au chargement de ce fichier ?

    3) Même question pour les interfaces des jeux

    Sinon à tous, comment vous régler le heave ? J'aimerai surtout pouvoir ressentir les g verticaux, mais si j'augmente trop le gain, le simu oscille énormément juste en suivant les irrégularités du revêtement...

    Riton39 a écrit :

    salut,

    j'ai du mal a comprendre ces courbes:

    En noir: la courbe des informations du jeu , il s'agit de la position dans l'espace de position de la voiture donc du simulateur ? c'est ça ?

    en gris, c'est le mouvement du simulateur , qui devrait être parfaitement sur la noir ? puisqu'il doit suivre la courbe de télémétrie du jeu?

    la rouge je comprend pas , la vélocité du simulateur , c'est a dire ?

    Noir: La position demandé au vérin pour produire une "pose" dans le simulateur.

    Gris: La vrai position du vérin. Il est impossible de suivre le noir.

    En rouge: La vélocité demande au moteur pour aller à la position noire. Les échelles ne sont pas comparables avec la position.

    Le soft analise le noir et le gris et calcule la vélocité demande au moteur. Plus grande la diference entre noir et gris, plus grande la vélocité.

    Alors, le soft est bidirectionnel, il envoie information au hardware et reçois information aussi.