Consider Slerp instead of Squad for rotation interpolation

[jrutgeer]

I am using the gz-gui camera tracking plugin to adapt the simulation viewpoint throughout the simulation.

I noticed that motion is sometimes 'shaky' due to the rotation interpolation, e.g. :

$ gz service -s /gui/move_to/pose --reqtype gz.msgs.GUICamera --reptype gz.msgs.Boolean --timeout 500 --req 'pose: {position:{x: 27.2, y:-1.7215,z:2.2255}, orientation:{x:-0.1466788, y:0.0344671, z:0.9623708, w:0.2261413}}'
$ gz service -s /gui/move_to/pose --reqtype gz.msgs.GUICamera --reptype gz.msgs.Boolean --timeout 500 --req 'pose: {position:{x:24.081968307495117,y:1.0910710096359253,z:1.194319486618042},orientation:{x:0.10836052149534225,y:-0.0045970650389790535,z:-0.99320769309997559,w:-0.042135711759328842}}'

squad.mp4

Changing this single line:

gz-math/src/RotationSpline.cc

Line 95 in 6460f7c

return Quaterniond::Squad(_t, p, a, b, q, _useShortestPath);

to use Slerp instead of Squad solves the issue:

  return Quaterniond::Slerp(_t, p, q, _useShortestPath);

slerp.mp4

Is it an option to change this to slerp instead of squad?
Why was squad chosen (I don't find references through 'git blame', seems it was squad from the first commit?)

It seems this is a good reference wrt rotation interpolation:

https://splines.readthedocs.io/en/latest/rotation/index.html

[jrutgeer]

According to following SE answer, an alternative could be to keep the squad algorithm, but to choose better A and B 'helper quaternions' for that algorithm:

https://math.stackexchange.com/a/2654414

[scpeters]

I have added the help wanted label to this issue; we will be happy to review pull requests with a proposed change. For example, we could add an overload to RotationSpline::Interpolate with a parameter to specify whether Slerp or Squad should be used.

[sdhar04]

@scpeters I noticed that the points and orientations given in this issue are too close to each other, and it feels like the 'shaky' movement is due to the radius of the interpolation sphere being too small. Should I add a condition to use Slerp if the final and initial points' and orientations' differences fall within a threshold and Squad if they don't?

[scpeters]

that sounds reasonable; go for it!

[sdhar04]

that sounds reasonable; go for it!

I played around with the values a little and noted that the ‘shaky’ movement stayed even if the points were far apart. So I focused on the difference between the starting and final orientations and made changes in the code accordingly.