Stabilisation de signal

Dunatotatos · 26 juil. 2016, 18:28

Salut à tous,

J'aime bien cette section, alors je poste, je poste :D
Je code en ce moment pour OSVR (un casque de réalité virtuelle), et le signal de positionnement du casque est un peu bruité. Par contre, la rotation est stable. Du coup, je cherche un moyen de stabiliser le déplacement pour éviter les fréquents "sauts d'image" auxquels j'ai droit. L'un de vous a-t-il déjà travaillé là-dessus ? J'ai pensé à utiliser deux méthodes différentes :
* un phénomène d'inertie (le rafraîchissement se faisant à 60Hz, il n'y a pas grand risque de mal de mer si l'inertie n'est pas trop élevée)
* une transformée de Fourier discrète, et je vire les hautes fréquences (j'ai juste peur que ce soit un peu trop gourmand en temps de calcul).

L'un de vous a-t-il été confronté à un tel problème ? Quelle solution avez-vous implémentée ? Dans l'idéal, un module Python pour faire ça ?

Merci d'avance !
Duna

funkygoby · 26 juil. 2016, 19:04

Salut,
j'en sais rien :)

Mais pour avoir fait des transformées de fourier et gabor, tu devrais pas trop avoir de soucis de ce coté là. (cherche "FFT")

Comment se fait le positionnement? À quoi ressemble le signal? Je vois pas trop comment une fft pourrait aider...
Peut être en jouant sur la taille de la fenêtre temporelle? Ou en mettant un "gate" sur le niveau de ta fft (tu vires tout ce qui est en dessous d'une certaine amplitude, un débruiteur de fortune).

vohu · 26 juil. 2016, 21:09

pour le traitement d'image, il y a openCV avec un API pour python. Et en prime, déjà présent dans les dépots debian

27 juil. 2016, 10:08

Si je comprend bien c'est le capteur de position qui t'envoie une valeur qui n'est pas très stable même si le casque l'est.
L'idée de la transformé de fournier est une bonne solution je pense, surtout qu'il y a des algo rapide car simplifiant la formule de calcul («FFT» de Funkygoby).

Dunatotatos · 27 juil. 2016, 11:08

Quand je le souhaite, j'appelle une méthode update() qui met à jour les données sur l'état du casque. Puis je peux recevoir un quaternion qui correspond à la rotation du casque (celui-ci marche bien et est plutôt stable), et un vecteur de dimension 3 qui représente la position du casque dans l'espace (c'est celui-là qui n'est pas très stable), et comporte souvent des "sauts". La détection de la position se fait grâce à une caméra infrarouge qui filme des émetteurs placés dans le casque. J'ai vérifié qu'il n'y ait pas d'autre source d'infrarouge aux alentours, que la caméra soit bien calibrée, et que tous les émetteurs fonctionnent. Mais ce n'est pas assez.

Suite à l'obtention du vecteur de position, je fais la différence avec le vecteur précédent pour obtenir le déplacement à appliquer à ma scène pour la mettre à jour. L'opération mathématique n'est pas complexe, l'instabilité ne vient certainement pas d'ici.

Je pensais donc appliquer une transformée de Fourier discrète sur ce signal de position sur une fenêtre de temps assez courte pour éviter les sauts qui durent un ou deux update.

Désolé vohu, pas de traitement d'image...

Bon, je me penche sur la question et reviens donner des nouvelles.

EDIT : Exactement Mimoza

28 juil. 2016, 11:20

Salut,
quel type de bruit sur le signal , quelle gamme de fréquence ?
Quelle gamme de fréquence dans ta bande passante que tu veux exploiter ?
Sans plus d'infos, je vois plusieurs solutions:
- moyenne glissante sur X échantillons
- un filtre passe bas
- des rampes de façon à limiter la valeur sur la vitesse de déplacement à ce qui est physiquement possible

funkygoby · 30 juil. 2016, 20:28

Si je comprends bien après ton update() tu récupères ton 3-vecteur x à différents instants rapprochés. Tu calcules dx = x_n - x_(n-1) et tu obtiens parfois des écarts dûs à du bruit qui donnent des sauts d'écran.

Le bruit est il constant? Est ce que tu as tout les temps des sauts d'images? Ou est ce que c'est juste de temps en temps genre toute les ~1sec?
1 er cas comme dit piratebab
2ème cas, je calculerais dx ET ddx (l'accélération) = dx_n - dx_(n-1) ( = x_n - 2*x_(n-1) + x_(n-2) ). Si la position recupèrée part à l'ouest, tu devrais obtenir une accélération démesurée. À la fin si ddx > ddx_raisonnable, tu dégages le dernier x ( x_n = x_(n-1); ) et tu continues.

30 juil. 2016, 22:34

Perso, je prendrais plus de temps à chercher à corriger la source du problème plutôt que d'essayer de filtrer ses effets.

Peut-être est-ce un simple problème de synchro ou parasitage du signal (masse, boucle de masse, induction parasite, etc)
alimentation mal filtrée, cordon de liaison défectueux, faux contact, mise à la masse d'un connecteur oubliée, adaptation d'impédance entre capteurs et entrées de mesure.

Dunatotatos · 31 juil. 2016, 08:42

@funkygoby : Je rencontre le deuxième cas. Le bruit n'est pas constant. Je peux parfois utiliser le casque pendant quelques minutes sans problème, puis il se met à sauter tout à coup pendant plusieurs secondes.

La cause de ces sauts est connues. Les pilotes sont expérimentaux, et l'instabilité du signal fait partie des "known issues". Je participerais bien à l'élaboration de ces pilotes, mais j'ai moyennement le temps de me plonger dans ce problème. Du coup, je cherche une rustine temporaire, en attendant que les pilotes soient plus stables.

31 juil. 2016, 22:52

une rampe sur la vitesse me semble alors le plus simple

Dunatotatos · 13 sept. 2017, 15:03

Petit déterrage. J'ai mis les pilotes du casque à jour, et les secousses semblent avoir disparu. Le signal est bien plus stable !

14 sept. 2017, 14:13

Tu devrais quand même faire quelque chose de ton coté de façon à limiter les variations à ce qui est physiquement réaliste. Tu n'est pas à l'abri d'une perturbation sur ton signal.
C'est comme si sur une saisie utilisateur, tu ne vérifiais rien ...

Dunatotatos · 15 sept. 2017, 17:48

En effet. Mais il se trouve que j'ai même changé de technologie pour utiliser A-Frame (par Mozilla). Je me retire toute la pénibilité de la comaptibilité avec différents appareils. Le seul point négatif est l'usage obligatoire d'un navigateur.

Mais c'est vraiment cool !!

18 sept. 2017, 13:41

Quand je vois que de nombreux développeurs/entreprises développent tout from scratch, alors qu'il existe des solutions libres performantes.
Quel gachis de temps, d'énergie, et d'argent ..

18 sept. 2017, 15:44

Attention, tout refaire depuis le début n'est pas forcément mal. Sinon pourquoi avoir le choix entre 36 environnement de bureau.
Refaire depuis zéro permet de prendre des décisions autre que celle de la solution précédente, ça peux contenter d'autre utilisateur, rendre 10x plus intéressante la solution, etc.
Oui c'est une somme de travail phénoménal qui est refait, mais on y gagne la diversité et le choix qui est une qualité bien plus importante a mes yeux que l'optimisation des ressources.

19 sept. 2017, 09:10

certes l'idée est louable, mais souvent tu as au final un "truc" incomplet, pas complètement débogué, et qui tombe vite dans l'oubli.
alors que toute cette énergie pourrait étre utilisée a améliorer le logiciel existant.

19 sept. 2017, 13:27

Mais si fondamentalement le logiciel existant ne te convient pas ?
Il y a quand même des exemples où une réécriture a donné voir supplanter le logiciel de référence. Sinon pourquoi Linus aurait écrit un nouveau noyau alors que les BSD existaient déjà depuis un moment et était bien plus développés.

La diversité a du bon je trouve :
Gnome / KDE(Plasma) / Xfce / BlackBox / enlightenment/ …
VLC / MPlayer / Totem / …

19 sept. 2017, 13:39

C'est comme dans tout, c'est l'exes qui est néfaste. Un peu de diversité, un peu de réutilisation ..
Ce que je voulais dire, c'est que les entreprises non pas le réflexe d’aller voir du coté du logiciel libre ce qui existe. Leur premier reflexe est de dire "ce sera mieux si on le fait nous même".
et la tendance actuelle des décideurs serait "c'est mieux si on l'achéte à l'extérieur, et plus c'est cher, plus c'est de qualité", sans se poser la question du vrai besoin utilisateur, et de l'intégration dans l'existant ....

19 sept. 2017, 17:56

Ha là je ne peux être que d'accord … combien de fois je suis tombé sur un framwork «maison» qui au mieux n'était qu'une surcouche d'un classique ou au pire tout à la main …
Pour ce qui est d'acheter il n'y a qu'a regarder SAP qui est une usine a gaz souvent totalement inadapté aux SI et process métier de l'entreprise que l'on personnalise a coup de centaine de JH de consultant à 1000€/j. Certaine DSI s'achète ce truc comme le banlieusard qui veux s'acheter des Nike … il est prêt a mettre en péril son équilibre financier pour un truc qui lui fait mal au pied.

Ensuite c'est les utilisateur/développeurs qui doivent faire avec parce que «la décision vient d'en haut»

Stabilisation de signal Le sujet est résolu