UM-ARM-Lab / pytorch_kinematics

Robot kinematics implemented in pytorch

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Incompatibility of rotation transformations in version <= 0.4.0 and >= 0.4.1

jangerritha opened this issue · comments

We used the github version 0.4.0 for months, to train a neuro-robotic application by using the FK functionality of the pytorch_kinematics package.

While the package is very useful for our training setup and we are very thankful to have it, the versions >= 0.4.1 lead to severe issues in our application. We noticed it when installing version 0.5.4 via pypi source.

The training of our neural models runs but the error does not minimize.

I located the matrix_to_quaternion(matrix) function to be the reason for the problem.

Changing the function back to it's 0.4.0 implementation makes it possible to run our system with the 0.5.4 version of your package. (I cloned the 0.5.4 github version and exchanged the new implementation of the function with the 0.4.0 implementation, then installed with pip install -e .)

For testing, I calculated forward kinematics on 10 randomly chosen joint states of our dataset and received strange results:

(Poses have the form: [pos. x, pos. y, pos. z, rot. x, rot. y, rot. z, rot. w])

Version 0.4.0 output

pytorch_0 4 0

Version 0.5.4 output

pytorch_0 5 6

For the first joint state, the sign of the rotation float values flipped, while for the other 9 joint states, the output of the pytorch_kinematics package equals for version 0.4.0 and 0.5.4.

I assume these sign-flips in the rotations to appear for a small subset of joint states in our dataset. Still, they create noise and prevent our training from success. I wanted to ask if you can explain a bit about the background of the changes to the matrix_to_quaternion(matrix) function . We are able to work with your software, but still, we have to patch this function which creates additional effort.

Thanks for noticing this difference - I believe there were changes to the implementation to improve its accuracy near some edge cases. This is not technically wrong because the negative of a quaternion represents the same rotation.

Losses on quaternions is a bit tricky since they are not actually in R^4 so Euclidean distance is not suitable. You should consider distances proposed here instead: https://math.stackexchange.com/questions/90081/quaternion-distance