Messages de Etienne

pas terrible les bulles sur l'écran

Plus sérieusement, ça claque bien le carbone là quand même.

Reste plus effectivement que les poignées, et peut être mettre des capuchons en alu anodisé pour avoir un résultat de fou.

Justement grâce à l'IMU. Et si ce n'était plus utilisé il n'y aurait pas besoin de compensation de mouvement sur les simus dynamiques...

Tortue G a écrit :

Ca paraît pourtant tellement simple à mettre en place, un ou deux points (ou plus...) fixés au cockpit et sur lesquels un casque VR à tracking par caméra se base (plutôt que sur tout l'environnement...), et on aurait un tracking parfait exempt de mouvements parasites...

En fait c'est plus compliqué, parce que le tracking des casques ne se fait pas qu'avec les caméras (qu'elle soient sur le casque ou externes). Des accéléromètres / gyroscopes / magnétomètres (IMU) sont aussi utilisés car ils ont beaucoup moins de latence que les caméras.

Les caméras servent surtout pour les translations, que ces capteurs ne peuvent pas mesurer, et pour compenser les dérives des capteurs de l'IMU. Donc à moins ne plus utiliser ces capteurs (avec potentiellement une latence plus importante), impossible de ne pas être perturbé par les mouvement engendrés par le simu. Je ne sais pas où en est la performance des caméras (en terme de latence) dans les casques récents, mais je doute qu'elles atteignent les 1000 Hz qu'on peut avoir avec une IMU.

ok ca se tient, avec internet en 4G pour pas qu'il y ait une coupure de net au mauvais moment

Xoss a écrit :

J'ai annulé mon abonnement cellulaire sur un coup de tête, histoire de me retrouver avec moi-même un peu, et cela fait désormais 7 ans que je n'ai plus de smartphone, et JAMAIS je ne reviendrai en arrière, une des meilleures décisions que j'ai pris de ma vie.

D'ailleurs, je n'ai même plus de ligne fixe non plus, la paix, et quand je veux vraiment être tranquille, j'éteins l'ordi aussi.

Du coup t'es plus joignable par téléphone du tout ? Et si tu as un accident domestique ou un arrêt cardiaque, pas moyen d'appeler les urgences ?

magicfr a écrit :

Ouais et meme ca, il y en a qui avaient essayer les meme systems ( ok moins bien ) avant et ils avaient echouer car arriver trop tot et mauvais marketing. Et Apple est revenu avec des systems tres proches mais plus rafiné.
Quand le film sur Apple est sortit j'ai aussi regardé des documentaires sur l'histoire d'Apple... j'amais deja pas trop Apple mais apres ca, encore moins

Je ne savais pas, je vais regarder Bon je respecte quand même toujours un minimum Apple parce j'ai commencé l'informatique sur un Apple 2. Et ils fabriquent leur propres CPU. Et Android ça me gonfle et ça rame mais bon je veux pas être enfermé donc je continue avec.

Oui quand tu utilises des vieux MCU obsolètes et que tu as des signaux en quadrature à une fréquence élevée par rapport à celle du MCU. Autant il y a 10 ans ça pouvait avoir du sens, autant aujourd'hui je ne pense pas. Tous les MCU modernes tournent à plus de 48 MHz, et la plupart ont des décodeurs de quadrature hardware intégrés. Et le prix de tes IC c'est le prix d'un SamD21 ou d'un ESP32, donc vraiment je ne vois pas l'intérêt. Désolé d'être moqueur, mais pour moi c'est pareil que les tutos que tu trouves sur le net pour te faire des boites à boutons, où les mecs rajoutent des résistances de pull up et des condensateurs pour les boutons, ce qui est totalement inutile puisque t'as des pull up en interne de tous les MCU et que tu peux faire le debounce en soft. Pourquoi faire simple et pas cher quand on peut faire compliqué et cher.

lolof1 a écrit :

Quand des constructeurs généralistes suivront Apple sur cet Apple Vision on en verras partout à des prix bas de gamme au haut de gamme comme on le vois en 2023. Avec :

Désolé mais sur ce coup là Apple n'est pas du tout le premier, ni sur la VR, ni sur l'AR. Leur casque va sans doute être de qualité, mais il arrivent quand même assez tard sur le marché. Autant je suis d'accord que sur l'IPod et sur l'IPhone ils ont vraiment laissé tout le monde sur place en terme d'innovation, autant là je ne pense pas que ça soit le cas. C'est quoi le truc nouveau, l'écran qui montre tes yeux ? A part ça le reste a déjà été implémenté il me semble. Et puis un casque qu'on ne pourra probablement pas utiliser sur PC, ça va fortement limiter son utilisation. La majorité du marché de la VR grand public aujourd'hui, c'est quand même le jeux vidéo sur PC il me semble, et on ne peut pas dire qu'Apple ait une grosse PDM sur ce secteur.

Carlton a écrit :

Je voulais accéder au VREF de l'ADC pour lui donner une autre tension de Ref que le 5V : du 3.3v en espérant gagné un cran de gain.

J'ai une loadcell de class 3 de 3kg en 2mV/V sous 12V stabilisé avec un gain de 64, buffer, mais je n'ai pas activé le filtre. Je ne crois pas aux filtres des fpga embarqués, j'ai probablement tort, dit moi.

J'ai mesuré la déviation du signal numérique reçu après avoir fait un décalage de 8bits à droite pour n'avoir que 16b de lecture. Le loadcell posé sur la table, je n'ai pas de variation de la valeur reçue.

Le biquad je l'ai rajouté parce qu'on en avait parlé, aucune autre raison. Je l'ai calé à 4khz avec une freq de coupure à 1khz pour viré tout ce qui est au dessus de la freq du FFB.

Pourquoi 4khz, bein parce que ca me paraissait bien, aucune raison scientifique ou technique, j'avais envie de lire vite pour filtrer le signal et le passer à un autre process que je voulais à 1khz, sans avoir trop de bruit

Je suis partisan du fail-fast pour les projets collaboratifs, ca permet de sortir des pièces à frapper (comme on dit dans la marine) et ca évite le standby. Mais dans l'approche fail-fast il faut un processus d'amélioration continue : je suis à votre écoute

Afficher plus

Sur l'ADS1256 la vref fournie est x2, donc il faudrait que tu prennes une ref externe de 1.2V par ex pour avoir 2.4V en interne. Mais de toute façon en utilisant une ref externe, si elle n'est pas utilisée pour alimenter la load cell, on n'est pas en mesure radiométrique, donc je ne suis pas convaincu que ça présente un intéret. Si la load cell est alimentée avec le 5V de l'USB, ça va récupérer le bruit qui en provient. Et même en utilisant une ref de 5 ou 12V (avec un booster) pour alimenter la load cell, on aura pas forcément la même dérive en température.

Ensuite ta load cell alimentée en 12V, ben tu triche déjà . Mais bon admettons qu'on refasse un 12V avec un booster bien filtré. Quand tu la charges à 1.5 Kg tu arrives à 32768 sur tes 16 bits ? Non bruité ?

Les filtres ce n'est pas une religion, il n'y a pas à y croire ou pas, c'est des maths... Les ADC ne sont pas des FPGA (Field Programmable Gate Array). Et les meilleurs filtres que tu puisses faire en terme de conservation de la forme du signal ce sont les FIR. Les biquad sont des IIR, c'est plus efficace en terme de calcul et d'espace mémoire nécessaire mais ça présente des inconvénients. Les filtres intégrés dans la plupart des ADC sont des FIR (souvent des moyennes en fait, qui sont un type particulier de FIR).

Je ne connais pas le terme Fail-Fast.... moi j'essaie plutôt le Suceed-Fast mais bon c'est rare d'y arriver

RacingMat a écrit :

Et si c'est trop coûteux en terme de gestion des interruptions, on pourrait utiliser un circuit dédié avec un quadrature clock converter suivi d'un compteur ?

Oui t'as qu'a faire ça, et rajoute des levels shifters on sait jamais

Aucun rapport avec les niveaux logique, ces 2V en dessous des 5v c'est pour les entrées analogiques, avec le buffer activé. buffer désactivé on peut aller jusqu'à AVDD + 0.1

Tu fais bien de citer Paul, il sait de quoi il parle. Il a d'ailleurs énormément contribué à l'environnement Arduino, et pour concevoir les Teensy (notamment les 4.x), il faut toucher sa bille en électronique.

Je ne comprend pas pourquoi tu veux avoir accès au VREF de 5V (j'imagine que tu parles du VREF interne, provenant d'une référence de tension de précision externe de 2.5V et multiplié par 2 en interne).

Je ne comprend pas pourquoi tu lit l'ADS à 4 KHz alors qu'il peut faire lui même le filtrage à 1000 Hz, avec un filtre FIR de meilleure qualité qu'un Biquad. D'ailleurs, à quelle fréquence a tu réglé ton biquad ?

Perso j'ai fait des essais avec l'ADS1256 (avec la même carte que toi et avec une plus évoluée), et même avec une load cell à 2mV/V, qui théoriquement va sortir 10mV max si alimenté en 5V, avec un gain de 64 et 1000 SPS je suis loin d'avoir 16 bits de précision. Quand je parle de précision je ne parle pas de la précision théorique, mais bien celle que j'ai en pratique et qui est sérieusement entachée de bruit. Sur cette carte la mesure n'est pas radiométrique car la tension qui alimente la load cell n'est pas celle qui est utilisée pour la référence de tension (sauf si tu alimente la load cell avec le 2.5V, mais dans ce cas on tombe à 15 bits max théoriques).

Dans la doc, à 1000 SPS, buffer et gain de 64, la résolution sans bruit est déjà donnée à 15.6 bits. Et ça c'est "en laboratoire"...

J'arrive à 16 bits de précision en baissant drastiquement les SPS, mais à 1000 SPS je suis loin de les avoir (la load cell utilisée pour le test a un câble blindé, 2mV/V, et 120 Kg max)

Comment tu mesures le bruit/la précision de ta mesure ?

Ben si tu envoie une consigne de couple au Drive, c'est lui qui gère l'asservissement en courant. Côté FFB c'est pas du PID même si une combinaison d'effet ressort+damper+inertie ressemble de loin à un PID...

Le DUE fonctionne aussi en 3.3V, et l'ADS1256 (si c'est ce que tu as), fonctionne de toute façon en 3.3V niveau signaux SPI. Evite les levels shifters au maximum, surtout sur des signaux SPI qui peuvent monter avec une horloge à 2 MHz. Les levels shifters c'est pour les loosers qui utilisent des Arduino UNO et qui veulent l'interfacer avec n'importe quel capteur qui fonctionnera en 3.3V dans 99% des cas...

Le DUE n'est pas 10x moins bien, c'est sur que le T4 est un monstre, et il carbure sévère, et en plus il est moins cher. Mais pas de DACs pour lui.

N'importe quel MCU qui a de l'USB natif utilise les interruptions pour sa gestion, c'est parfaitement normal, il ne faut pas avoir peur

Je ne vois pas ce que tu comptes faire avec un PID. Mais de toute façon même si tu le mets sur une interruption, ça ne posera pas de problèmes. Il y a des priorités sur les interruptions sur la plupart des MCU modernes.

Que tu prennes un T4 ou un Due, je ne vois pas trop ce que ça change pour la gestion de la Load Cell.

Les 2 gèrent des encodeurs en HW, mais comme d'habitude le support logiciel côté Teensy est beaucoup plus sérieux et consistant.

Le Due je me demande pourquoi ils le produisent encore, il est hyper cher et ils n'ont jamais assuré le suivi du noyau sérieusement. J'avais il y a plusieurs années signalé des bugs dans le noyau, ils n'ont jamais été pris en compte ni corrigé.... C'est dommage car le Sam3X présente des caractéristiques intéressantes, notamment ses 2 DACS, qui vont te manquer sur le T4 si tu veux piloter le drive en analogique.

Tout dépend de ce que tu comptes utiliser comme MCU, mais 125KHz ça commence à faire beaucoup pour faire ça en soft (t'oublie tout de suite les AVR 16 bits). Il ne faut pas perdre de pulses. Cette librairie utilise les interruptions. Donc même si ça passe probablement sur un ESP32, ne pas oublier qu'il faut gérer des interruptions pour l'USB aussi (et éventuellement du wifi etc). Autant utiliser le décodage de quadrature HW disponible sur le Due ou Teensy 4.0. Et comme de toute façon on va faire un paquet de tours, le signal d'index n'est pas forcément nécessaire. Il faudra de toute façon des capteurs de fin de course.

Oui, mais j'ai édité mon message, en le nuançant. ça rejoint ce que tu dis, si il n'y avait pas de friction, on pourrait se passer de load cell. Or il y en a beaucoup (en tout cas beaucoup plus que sur un DD), donc elle sert peut être comme info pour l'algo pour aider à la compenser plus facilement.

Ce n'est qu'une intuition mais je pense qu'il ne faut pas faire rentrer la mesure de la load cell dans le calcul du couple à envoyer au moteur pour le moment. A mon avis ça va être difficile à stabiliser.

Pour moi il faut juste implémenter un effet ressort (couple = (pos-pos_min)*K). En tout cas dans un premier temps (avec un petit damper pour éviter les oscillations).

Exactement les mêmes effets que pour le FFB de volant, et déjà voir ce que ça donne dans un premier temps avant de rajouter dans la boucle la load cell.

Peut être que la load cell est utile, notamment pour aider à vaincre la friction statique, en tout ça c'est la seule explication que j'ai trouvé pour le moment, parce que sinon je ne vois pas son intérêt, il suffirait de déduire la force depuis la position pour envoyer ça au PC.

Tu peux mettre les phases dans l'ordre que tu veux, il n'y a aucun risque. La seule chose c'est le sens de rotation. Dès que tu permute 2 phases, ça change le sens de rotation.

Les impulsions en quadrature de l'encodeur sont dispos sur CN2, donc tu peux les récupérer et les décoder directement sur la carte de commande, comme je faisais pour le RFR Wheel.

Je viens de regarder la doc du AASD, en fait tu peux régler le gain et l'offset pour l'entrée analogique :

Pn189 - Analog torque instruction gain : 1-300 %/V

Pn190 - Analog torque instruction offset : -1500~1500 0 mv

Donc logiquement en réglant un gain de 66%/V et un offset de -1500 mV tu peux piloter le bousin entre 0 et 3 V

Oui j'avais regardé aussi, et de mémoire c'était pas fou. Ce port est plus prévu pour configurer le drive depuis un PC que pour faire de la commande en temps réel. Bon si la position est récupérée autrement, 500 Hz c'est suffisant pour un FFB.

A voir si par l'entrée analogique, il y a moyen de régler un gain dans les paramètres.