Concordia University
Assistant de recherche, session hiver 2022
Visualisation IMU en temps réel en C++ et OpenGL, précision système de 99 %, multiplateforme
Écriture d'une application C++ multiplateforme qui lisait le tangage, le roulis, le lacet, le quaternion, l'accélération et la vitesse angulaire d'un capteur IMU, puis visualisait l'orientation en direct via des rotations basées sur les quaternions dans OpenGL.
Le problème
Un groupe de recherche voulait visualiser en temps réel des données d'IMU (unité de mesure inertielle) sur plusieurs plateformes. Le pipeline existant était lent, et la visualisation retardait par rapport à la cadence du capteur.
La rotation par angles d'Euler introduit le blocage de cardan à certaines orientations, ce qui casse visiblement le modèle quand les axes s'alignent. Les quaternions évitent ça complètement, mais les mathématiques sont moins intuitives.
Pourquoi c'était difficile
La cadence du capteur n'est pas une variable qu'on contrôle. Le budget par image est fixé par le matériel, et la visualisation doit vivre dedans ou perdre des images. Cette contrainte disqualifie la plupart des stratégies d'optimisation avant même de commencer.
Du C++ multiplateforme qui lit un capteur matériel doit survivre à trois caprices de système d'exploitation dans le même chemin de code (énumération des périphériques, mode virgule flottante, affinité de threads). Le débogage a trois fois la surface.
Les rotations par quaternions donnent le bon résultat mais les mathématiques ne sont pas ce à quoi la plupart des contributeurs s'attendent. Documenter les invariants pour qu'un autre puisse étendre la visualisation plus tard comptait plus que livrer les derniers 3 % de fonctionnalités.
L'approche
Construction d'une application C++ multiplateforme pour traiter et visualiser le flux du capteur en temps réel. Implémentation d'une visualisation 3D avec OpenGL utilisant des rotations basées sur les quaternions, qui évitent le piège du blocage de cardan des angles d'Euler.
Profilage du chemin critique et optimisation des algorithmes de collecte et d'analyse pour que la visualisation tienne la cadence quand le taux d'échantillonnage montait.
Le résultat
La précision du système est passée à 99 % en resserrant les algorithmes de collecte et d'analyse.
Le temps de traitement a diminué. La réactivité globale du système s'est améliorée.
L'application tournait de manière identique sur les plateformes dont le groupe de recherche avait besoin.
Vous avez ce problème si
- Votre budget de latence côté utilisateur est fixé par le matériel ou la physique, pas par la vélocité de votre équipe
- Le système tourne correctement sur la plateforme cible principale mais se dégrade ou casse sur les autres que vous avez promises
- Un chemin de code à forte densité mathématique (rotation, projection, filtrage) est une boîte noire qu'une seule personne comprend
- Ajouter des fonctionnalités a commencé à coûter en performance, et personne n'a profilé le vrai chemin critique depuis un moment
Ce que j'en retiens
Les systèmes en cadence d'image ont un plafond dur. On ne triche pas avec les mathématiques. L'optimisation n'est pas d'écrire du code plus rapide, c'est de faire moins de travail par image. Ce modèle mental se transfère directement à tout système sensible à la latence que j'ai touché depuis : inférence en temps réel, API en streaming, boucles d'agent en direct, interfaces qui se mettent à jour en direct.
Comment ça se voit dans mon travail aujourd'hui
La même discipline se retrouve sous chaque application intégrant un LLM que je construis aujourd'hui. Le débit de jetons n'est pas une variable qu'on contrôle. La latence du modèle n'est pas une variable qu'on contrôle. Le budget par image d'une boucle d'agent en direct est fixé par le fournisseur du modèle, et le produit doit vivre dedans ou paraître cassé. Même lentille : profiler le chemin critique, faire moins de travail par tour, mettre en cache ce qui ne change pas.