Yaw pitch roll demonstration
I made this to show how to calculate yaw, pitch and roll from a physics sensor’s Euler angles. It also demonstrates various properties of the tilt and compass outputs (which act exactly like individual tilt and compass sensors). The motorized gimbal system is set up as yaw, pitch, roll itself. Press a button to rotate the part of the same color.
Conclusions you can draw from this:
• Tilt X is not the same as roll. Instead of going all the way to 180°, it reverses course at 90°. It’s also smaller than it should be if pitch is not zero.
• Tilt Z is actually pitch.
• Compass Z is actually yaw. It fails once |pitch| exceeds about 88.2°, outputting -0.
What’s harder to tell is loss of precision. Tilt values are less precise near up/down. Compass values are less precise near north/south. You lose half of your significant digits at the extremes. The worst-case jump is by 1.2 arc minutes. Not super bad, but a far cry from the 0.00032 arc minutes a number channel can represent.
My own conversion is numerically stable. If it had double-precision input, output precision would be commensurate with that. Gimbal lock inherently makes yaw and roll unpredictable individually. Crucially, I made sure their combination still corresponds to the full orientation very precisely. Garbage in, garbage out is the limiting factor.
The physics sensor mostly outputs good Euler angles (matching single precision) in practice. Its flaws are usually masked by its internal double precision. That said, its flaws are plentiful. It is not numerically stable. It is susceptible to its own gimbal lock, which can be brought out persistently by static axis-aligned grids such as the oil platform. Some extremely rare orientations erroneously change two outputs by ±π (a corruption of the already nonsensical btMatrix3x3::getEulerYPR). Some extremely rare orientations cause NaN (because Bullet’s orthonormalization can produce matrix values of ±1.0000000000000002—atrocious, I know). Do not put absolute faith in it.
The physics sensor can be made more reliable by installing it in a different orientation. Gimbal lock occurs when sensor x aligns with world z. In the default orientation, that corresponds to a vehicle facing east or west (at any pitch, zero roll). It may be better to place the sensor such that its x axis points up or down, and adjust your interpretation accordingly. Then gimbal lock occurs at a pitch of ±90° which is usually much rarer. I didn’t do it here because this demonstration uses tilt and compass values which only work as intended in the default orientation.
Most sensor outputs are suspect if the vehicle’s matrix isn’t orthonormal. That can occur at spawn. A static vehicle remains in that state forever! This really brings out numerical stability issues. Only something like my old matrix box can mitigate that, carefully mixing and matching multiple sensors to bring out the ones in their more stable domain.
