Concordia University
Research Assistant, Winter 2022 semester
Real-time IMU visualisation in C++ and OpenGL, 99% system accuracy, cross-platform
Wrote a cross-platform C++ application that read roll, pitch, yaw, quaternion, acceleration, and angular velocity from an IMU sensor, then visualised the orientation live using quaternion-based rotations in OpenGL.
The problem
A research group needed to visualise IMU (inertial measurement unit) sensor data in real time on multiple platforms. The existing pipeline was slow, and the visualisation lagged the sensor rate.
Rotation using Euler angles introduces gimbal lock at certain orientations, which visibly breaks the model when the axes align. Quaternions avoid that entirely but the math is less intuitive.
Why it was hard
Sensor rate is not a variable you control. The frame budget is fixed by the hardware, and the visualisation has to live inside it or drop frames. That constraint disqualifies most optimisation strategies before you start.
Cross-platform C++ that reads from a hardware sensor has to survive three operating-system quirks in the same code path (device enumeration, floating-point mode, thread affinity). Debugging is triple the surface area.
Quaternion rotations produce the correct result but the math is not what most contributors expect. Documenting the invariants so someone else could extend the visualisation later mattered more than shipping the last 3% of features.
The approach
Built a cross-platform C++ application to process and visualise the sensor stream in real time. Implemented 3D visualisation with OpenGL using quaternion-based rotations, which sidestep the gimbal-lock trap that Euler angles fall into.
Profiled the hot path and optimised the collection and analysis algorithms so the visualisation stayed at frame rate as the sensor sample rate went up.
The outcome
System accuracy improved to 99% by tightening the collection and analysis algorithms.
Processing time reduced. Overall system responsiveness improved.
The application ran identically on the platforms the research group needed.
You have this problem if
- Your user-facing latency budget is fixed by hardware or by physics, not by your team's velocity
- The system runs correctly on the primary target platform but degrades or fails on the others you promised
- A math-heavy path in the code (rotation, projection, filtering) is a black box that only one person understands
- Adding features has started to cost performance, and nobody has profiled the actual hot path in a while
What I take from this
Frame-rate systems have a hard ceiling. You cannot cheat the math. Optimisation is not about writing faster code, it's about doing less work per frame. That mental model transfers directly to every latency-sensitive system I've touched since: real-time inference, streaming APIs, live agent loops, live-updating UIs.
How this shows up in my work today
The same discipline sits under every LLM-integrated app I build today. Token throughput is not a variable you control. Model latency is not a variable you control. The frame budget of a live agent loop is fixed by the model provider, and the product has to live inside it or feel broken. Same lens: profile the hot path, do less work per turn, cache what does not change.