5 ms·

Guys I work at a company that uses Quaternions for rotations of physical objects. PTUs we call them (Pan Tilt Units). I am telling you Quaternions have HUGE is

Guys I work at a company that uses Quaternions for rotations of physical objects. PTUs we call them (Pan Tilt Units). I am telling you Quaternions have HUGE issues. These issues become much more apparent when you deal with physical objects. Here's the thing Quaternions don't exist in reality. It represents an orientation of rotation but it completely masks the path took to achieve that orientation. For every gimbal in reality there is an actual YawPitchRoll (YPR) that was executed to achieve that orientation. AS soon as you convert that real YPR into a Quaternion you lose the YPR that was needed to achieve that orienation. So let's say I need to have one gimbal imitate the position of another gimbal. I take the YPR given to me by gimbal "A" convert the YPR to a Quat, send that Quat over the wire to Gimbal "B" and convert that Quat back to YPR to feed to the gimbal so it can rotate itself to imitate the orientation of gimbal A. The quat is a higher entropy form of information. Now when converting back to YPR there are MULTIPLE YPRs that yield the same orientation. You can derive a YPR that is out of bounds of the physical gimbal. Literally you can get a YPR that tells your gimbal to Yaw 190 and pitch all the way back past 90 to 170 degrees and roll 180 degrees until it's right side up. This YPR is identical to a yaw of 10, a pitch of 20 and 0 roll. Quaternions hide the original YPR, you lose information so when you receive a Quaternion it's hard to translate it into a physical realization of the orientation. The company I work for doesn't realize this. They used Quaternions from day one and we have all kinds of headaches like this when we try to extract the YPR and use these orientations in the real world. Actually I should say only I have these headaches. A lot of people haven't figured out this problem yet. The only time you should use Quats are if you need to transform an orientation or you're dealing with virtual objects that have no rotational limits. Everybody thinks quats are magic and better. They are not. They have huge downsides. Huge.

dakr 5y ago
This real hardware handles quaternions just fine: https://en.wikipedia.org/wiki/Stratospheric_Observatory_for_Infrared_Astronomy https://en.wikipedia.org/wiki/Stratospheric_Observatory_for_...
- neonological 5y ago
  I'm sure it does, I'll give you the benefit of the doubt even though the article makes no mention of Quaternions. My point is, using Quaternions for physical devices is using a hammer on a screw. Huge mistake, but it can be done by people who don't know any better. I'm guessing you worked on this and bought in to the whole Quaternion BS? I'm in the defense industry as well and guess what? Basically most people don't know any better.
phkahler 5y ago
>> For every gimbal in reality there is an actual YawPitchRoll (YPR) that was executed to achieve that orientation. AS soon as you convert that real YPR into a Quaternion you lose the YPR that was needed to achieve that orienation. I would say you obscure it. You can certainly calculate it from the 4 quaternion parameters. SolveSpace (Free CAD software) can be used to design assemblies and mechanisms from a set of parts with constraints. You can certainly build a gimbal with it by constraining the pieces. If you do it correctly, it will be possible to re-orient the final 3DoF part and the constraint solver will solve for the angles (assuming you built it that way). Internally we treat all object orientations as quaternions, so this would just be using the algebraic constraint solver to find the angles. In practice there will be closed form solutions - with problems at gimbal lock.
- neonological 5y ago
  >I would say you obscure it. You can certainly calculate it from the 4 quaternion parameters. No it is an actual information loss. There are multiple valid YPR solutions like my example illustrated. There is NO way to determine which YPR out of the multiple possibilities was the original solution. Something like solve space can only determine the original YPR with additional assumptions or the original YPR still referenced in memory.
  - phkahler 5y ago
    Nope. The only thing you need to specify is the order the YPR angles are applied (that more a convention than an assumption). In SolveSpace the assembly constraints would effectively encode the order of application. A quick Google search even turns up a Wikipedia entry on this problem: https://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles https://en.wikipedia.org/wiki/Conversion_between_quaternions... If you really need this problem solve I might know someone willing to do paid consulting on it.
    - neonological 5y ago
      No, no, no. Wrong again. Please study basic trigonometry and read your own sources. Your own link proves you wrong. The formula for conversion from quat to ypr involves arctan and arcsin. These functions yield multiple answers. Additionally your own Wikipedia link explicitly states the existence of multiple answers, and that traditionally atan and asin in programming languages yield only one answer. I quote: "Note, however, that the arctan and arcsin functions implemented in computer languages only produce results between −π/2 and π/2, and for three rotations between −π/2 and π/2 one does not obtain all possible orientations. To generate all the orientations one needs to replace the arctan functions in computer code by atan2" Either way you misunderstand the math behind quaternions and you lack a basic grasp of trigonometry. Assuming you read your own Wikipedia link, what I said is categorically true.
edflsafoiewq 5y ago
Interesting to read about experience with a physical gimble, thanks. In this case the "problems" of Euler angles are actually an accurate model of the problem space.
- neonological 5y ago
  You can design a hardware ptu that when given a quat it figures out its own ypr to arrive at that orientation. That would make quats feasible for hardware. However, how the Ypr was picked by the hardware must be explicitly encoded as an assumption that must be part of every conversion from quat to ypr that happens downstream.
xaedes 5y ago
If you have actual, possibly motorized, physical rotation axes to keep track of, then of course you need to keep track of the actual angles of each separate rotation, somewhere. Compressing it all into one orientation may work for some use cases, but generally one should not expect that. Similarily one wouldn't try to represent all of the axes of a KuKa arm robot with just one orientation. You need info about the individual axes when you want to control it. Your company can still use quaternions to represent the rotations of each axis, tho. Might help in convincing them going forward, as they don't have to let go of them (they are good fellas actually).
- neonological 5y ago
  >Your company can still use quaternions to represent the rotations of each axis I don't understand this can you elaborate? My company does indeed use motorized pan tilt units.
  - xaedes 5y ago
    I meant when you want to compute the final orientation (lets ignore position): Each axis results in some orientation change which can be expressed as a quaternion. The final orientation can then be computed by combining the quaternions into one quaternion. This is very similar to the computation of forward kinematics (https://en.wikipedia.org/wiki/Forward_kinematics https://en.wikipedia.org/wiki/Forward_kinematics) for robots, which just have additional translations for the transformations. As said before you still want to retain the actual angles somewhere. Depending on your physical configuration one of the Euler angle variants (Tait–Bryan angles is another term to search for) could perfectly describe your case and you could just use these to store the angles. Euler angles can also be converted to quaternion. But you can't recover the original used angles from the quaternion alone because of the 2pi wrapping of angles. For others still wondering why quaternion or orientation alone won't suffice, here is a different example: Imagine an axis which can rotate more than only one revolution, i.e. can have angles like 4 pi, for example motorized volume knobs. An orientation alone can't represent that as it wraps the angles to 2pi. User manually turns the knob to two full revolutions (4pi) and then increases the value by remote control, which results in motorized knob to rotate. Should the knob turn back to nearly zero revolutions (rotate back 4pi) plus the increase? No, it should rotate to 4pi+increase. By the way, when you have internally stored the "multi revolution" angle and have a sensor reading in range [0..2pi[ you can recover an multi revolution angle equivalent to the sensor reading with wrapToPiSeq( angle in radians before, sensor reading). # to equivalent angle in [0,2pi[ range def wrapTo2Pi(rad): return rad % (2*pi) # to equivalent angle in ]-pi,pi] range def wrapToPi(rad): return wrapTo2Pi(rad + pi) - pi # angle difference between rad0 and rad1, in range ]-pi,pi] def angleDiff(rad0, rad1): r0 = wrapToPi(rad0) r1 = wrapToPi(rad1) return wrapToPi(r1-r0) # rad1 to equivalent angle so the jump from rad0won't be greater than |PI| def wrapToPiSeq(rad0, rad1): r0 = wrapToPi(rad0) r1 = wrapToPi(rad1) diff = wrapToPi(r1-r0) return rad0+diff

dakr 5y ago

This real hardware handles quaternions just fine: https://en.wikipedia.org/wiki/Stratospheric_Observatory_for_Infrared_Astronomy https://en.wikipedia.org/wiki/Stratospheric_Observatory_for_...

neonological 5y ago
I'm sure it does, I'll give you the benefit of the doubt even though the article makes no mention of Quaternions. My point is, using Quaternions for physical devices is using a hammer on a screw. Huge mistake, but it can be done by people who don't know any better. I'm guessing you worked on this and bought in to the whole Quaternion BS? I'm in the defense industry as well and guess what? Basically most people don't know any better.

phkahler 5y ago

>> For every gimbal in reality there is an actual YawPitchRoll (YPR) that was executed to achieve that orientation. AS soon as you convert that real YPR into a Quaternion you lose the YPR that was needed to achieve that orienation. I would say you obscure it. You can certainly calculate it from the 4 quaternion parameters. SolveSpace (Free CAD software) can be used to design assemblies and mechanisms from a set of parts with constraints. You can certainly build a gimbal with it by constraining the pieces. If you do it correctly, it will be possible to re-orient the final 3DoF part and the constraint solver will solve for the angles (assuming you built it that way). Internally we treat all object orientations as quaternions, so this would just be using the algebraic constraint solver to find the angles. In practice there will be closed form solutions - with problems at gimbal lock.

neonological 5y ago
>I would say you obscure it. You can certainly calculate it from the 4 quaternion parameters. No it is an actual information loss. There are multiple valid YPR solutions like my example illustrated. There is NO way to determine which YPR out of the multiple possibilities was the original solution. Something like solve space can only determine the original YPR with additional assumptions or the original YPR still referenced in memory.
- phkahler 5y ago
  Nope. The only thing you need to specify is the order the YPR angles are applied (that more a convention than an assumption). In SolveSpace the assembly constraints would effectively encode the order of application. A quick Google search even turns up a Wikipedia entry on this problem: https://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles https://en.wikipedia.org/wiki/Conversion_between_quaternions... If you really need this problem solve I might know someone willing to do paid consulting on it.
  - neonological 5y ago
    No, no, no. Wrong again. Please study basic trigonometry and read your own sources. Your own link proves you wrong. The formula for conversion from quat to ypr involves arctan and arcsin. These functions yield multiple answers. Additionally your own Wikipedia link explicitly states the existence of multiple answers, and that traditionally atan and asin in programming languages yield only one answer. I quote: "Note, however, that the arctan and arcsin functions implemented in computer languages only produce results between −π/2 and π/2, and for three rotations between −π/2 and π/2 one does not obtain all possible orientations. To generate all the orientations one needs to replace the arctan functions in computer code by atan2" Either way you misunderstand the math behind quaternions and you lack a basic grasp of trigonometry. Assuming you read your own Wikipedia link, what I said is categorically true.

edflsafoiewq 5y ago

Interesting to read about experience with a physical gimble, thanks. In this case the "problems" of Euler angles are actually an accurate model of the problem space.

neonological 5y ago
You can design a hardware ptu that when given a quat it figures out its own ypr to arrive at that orientation. That would make quats feasible for hardware. However, how the Ypr was picked by the hardware must be explicitly encoded as an assumption that must be part of every conversion from quat to ypr that happens downstream.

xaedes 5y ago

If you have actual, possibly motorized, physical rotation axes to keep track of, then of course you need to keep track of the actual angles of each separate rotation, somewhere. Compressing it all into one orientation may work for some use cases, but generally one should not expect that. Similarily one wouldn't try to represent all of the axes of a KuKa arm robot with just one orientation. You need info about the individual axes when you want to control it. Your company can still use quaternions to represent the rotations of each axis, tho. Might help in convincing them going forward, as they don't have to let go of them (they are good fellas actually).

neonological 5y ago
>Your company can still use quaternions to represent the rotations of each axis I don't understand this can you elaborate? My company does indeed use motorized pan tilt units.
- xaedes 5y ago
  I meant when you want to compute the final orientation (lets ignore position): Each axis results in some orientation change which can be expressed as a quaternion. The final orientation can then be computed by combining the quaternions into one quaternion. This is very similar to the computation of forward kinematics (https://en.wikipedia.org/wiki/Forward_kinematics https://en.wikipedia.org/wiki/Forward_kinematics) for robots, which just have additional translations for the transformations. As said before you still want to retain the actual angles somewhere. Depending on your physical configuration one of the Euler angle variants (Tait–Bryan angles is another term to search for) could perfectly describe your case and you could just use these to store the angles. Euler angles can also be converted to quaternion. But you can't recover the original used angles from the quaternion alone because of the 2pi wrapping of angles. For others still wondering why quaternion or orientation alone won't suffice, here is a different example: Imagine an axis which can rotate more than only one revolution, i.e. can have angles like 4 pi, for example motorized volume knobs. An orientation alone can't represent that as it wraps the angles to 2pi. User manually turns the knob to two full revolutions (4pi) and then increases the value by remote control, which results in motorized knob to rotate. Should the knob turn back to nearly zero revolutions (rotate back 4pi) plus the increase? No, it should rotate to 4pi+increase. By the way, when you have internally stored the "multi revolution" angle and have a sensor reading in range [0..2pi[ you can recover an multi revolution angle equivalent to the sensor reading with wrapToPiSeq( angle in radians before, sensor reading). # to equivalent angle in [0,2pi[ range def wrapTo2Pi(rad): return rad % (2*pi) # to equivalent angle in ]-pi,pi] range def wrapToPi(rad): return wrapTo2Pi(rad + pi) - pi # angle difference between rad0 and rad1, in range ]-pi,pi] def angleDiff(rad0, rad1): r0 = wrapToPi(rad0) r1 = wrapToPi(rad1) return wrapToPi(r1-r0) # rad1 to equivalent angle so the jump from rad0won't be greater than |PI| def wrapToPiSeq(rad0, rad1): r0 = wrapToPi(rad0) r1 = wrapToPi(rad1) diff = wrapToPi(r1-r0) return rad0+diff