Hi @DanielPiker and @Michael_Pryor, I was having a conversation with @RIL about quaternions and their use in transformations and he mentioned that you might be able to comment on a problem I am having. Based on extensive search and learning from the conversations you all had, I think the quaternions identified in GH are unit values, and they tend to flip similar to the Euler angles do. I understand that in robotics, when we are defining a tool path between two planes with a SLIRP etc, the flip is unlikely, but when we are doing the opposite, say, teaching the robot a path or getting readings from an accelerometer/gyro combo chip, the unstable coordinate system is an issue. I’m trying to understand how best I can receive quaternion values from a device in physical world (new chips support this) and once I import to a tool like Falcon or Pufferfish, convert to a plane to display orientation of the geometry (think bunny demo from adafruit). I tried various different options but haven’t been successful. I appreciate any insights you can give to help with the physical world handshake issues some of us have and haven’t found a good solution.
This sounds very similar
Indeed, i have seen many problems posed, but no solutions. Especially when you don’t have a set path in mind and are receiving data to orient instead of path to orient to.
The first I heard of quaternions was from @Michael_Pryor:
If you can detect such a flip you can negate the measured quaternion q and use -q instead. That results in the same rotation, just “the other way around”.
I’m guessing your device won’t tell you which way it rotated around. So you’ll need some sort of reference quaternion (maybe the previous pose in the path?) say r. Then you can measure the angle between r and q and between r and -q, and use whatever gives you the smaller angle.
To measure quaternion distances (aka the angle) you can use:
Quaternion q; Quaternion r; var qd = q.Inverse * r; var angle = 2 * Math.Atan2(qd.Vector.Length, qd.A);
Did it work out @gy2106 ?
Not quite, I think the easiest way is to set a quaternion from the accelerometer, then track the initial and final plane, which gives you orientation change. Not as intuitive as Euler but works. I still see jumps on incoming data as the chips I use stream the data at a different rate, need to experiment with rates to see which one prevents the data flow. The problem being the general reader flows in more that 4 data points, giving a line from after the one I need to read. Is there a way to limit the incoming data to 4 at a time? That might solve the problem.