> In this case use the one closest to the actual current angles. For cases when all angles are possible for an axis, use the current angle as target (i.e. motor

> In this case use the one closest to the actual current angles. For cases when all angles are possible for an axis, use the current angle as target (i.e. motor doesn't change). When you then have an target angle use `wrapToPiSeq` to get an equivalent angle close the current actual angle as input for the motor controller. Yeah that's how I solved this issue. But still if we avoided quaternions we wouldn't have this problem all together, which is my point. Specifically what's going on is that we're sending quaternion values over the network and the person on the receiving end needs YPR so we're basically like wtf, there's no transformations being performed on the quat, the source of info is a YPR and the output is needed is the same exact YPR so we're only converting to a company wide Quat Protobuf type to send over the wire. I submitted a request to make a new protobuf type that included YPR but I was met with huge company resistance from other engineers saying that a YPR was redundant to a Quat (It's not). >In computer animation and robotics, inverse kinematics is the mathematical process of calculating the variable joint parameters needed to place the end of a kinematic chain, such as a robot manipulator or animation character's skeleton, in a given position and orientation relative to the start of the chain. Interesting, but yeah the application in my company is just a single gimbal so there's no chain of "joints" here. I don't think this would apply to our my specific case. >https://www.astro.rug.nl/software/kapteyn/_downloads/fa29752e4cd69adcfa2fc03b1c020f4e/attitude.pdf https://www.astro.rug.nl/software/kapteyn/_downloads/fa29752... Thanks for all your input. I'll take a look at the link above, it looks interesting.