Code to reproduce

R = np.array([[-0.26588199,  0.0721791,  -0.96129961],
                      [ 0.01772801,  0.99739046,  0.06998566],
                      [ 0.96384256,  0.001566,   -0.26646775]])
R = SO3.from_matrix(R, True)
q = R.to_quaternion()
print(np.isclose(la.norm(q), 1))

prints False

I recently found two occurrences of this error, both in torch/so3.py:

Traceback (most recent call last): File "", line 1, in File "/home/ubuntu/.local/lib/python3.6/site-packages/liegroups/torch/se3.py", line 80, in exp rot_jac = cls.RotationType.left_jacobian(phi) File "/home/ubuntu/.local/lib/python3.6/site-packages/liegroups/torch/so3.py", line 187, in left_jacobian #large_angle_mask = 1 - small_angle_mask # element-wise not File "/home/ubuntu/anaconda3/envs/pytorch_p36/lib/python3.6/site-packages/torch/tensor.py", line 362, in rsub return _C._VariableFunctions.rsub(self, other) RuntimeError: Subtraction, the - operator, with a bool tensor is not supported. If you are trying to invert a mask, use the ~ or logical_not() operator instead.

I could verify locally that it is just a matter of doing what is suggested and it works fine. P.S.: My pytorch version is 1.3

When I use liegroups in a loss function, it reports error as follows: Can't call numpy() on Variable that requires grad. Use var.detach().numpy() instead.

Here is the code:

    print('rotation_ab_pred size = {} type = {}'.format(rotation_ab_pred.size(), rotation_ab_pred.type()))
    rvec_ab_pred = SO2.from_matrix(rotation_ab_pred)

And the result:

rotation_ab_pred size = torch.Size([32, 2, 2]) type = torch.cuda.FloatTensor

I do not know whether you have considered this, but in monocular VO with bundle adjustment it may be interesting to include the scale directly in the similarity transformation (see http://roboticsproceedings.org/rss06/p10.pdf, page 6) and optimize over it rather than separately.

Modification to base classes for compatibility with python 2.7. On some systems, may require installing future (easy with pip).

For explanation of changes, see https://python-future.org/compatible_idioms.html, specifically the "Metaclasses" section.

This assertion fails.

import numpy as np
from liegroups import SO3
s = SO3.from_rpy(np.pi, 0, np.pi/2)
es = SO3.exp(s.log())
assert np.allclose(s.mat, es.mat)

Hello,

In the so3.log function

https://github.com/utiasSTARS/liegroups/blob/fe1d376b7d33809dec78724b456f01833507c305/liegroups/numpy/so3.py#L205

There's a division by np.sin(angle) but there isn't a check to see if angle is +np.pi or -np.pi. I understand that due to numerical precision, np.sin(np.pi) != 0.0 but I'm wondering if there needs to be some extra care taken here.

See

https://en.wikipedia.org/wiki/Axis–angle_representation#Log_map_from_SO(3)to%7F'%22%60UNIQ--postMath-0000000D-QINU%60%22'%7F(3)

When using the liegroups lib I run into the following SyntaxWarning when using the so3.py file

liegroups/numpy/so3.py:83: SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif ordering is 'wxyz':

I've changed the literal with two equal signs for this file to prevent the warning. I will look through some of the other files to see if I can find any more needing to be changed.

Implemented the SE(2) group jacobian (and inverse) in numpy and torch. These did not seem to be covered in Barfoot and so the reference for the solution implemented in this PR is a Lie theory described in https://arxiv.org/pdf/1812.01537.pdf. Specifically, I ported the left jacobian implementation from the C++ code here: https://github.com/artivis/manif/blob/6f2c1cd3e050a2a232cc5f6c4fb0d33b74f08701/include/manif/impl/se2/SE2Tangent_base.h The paper does not provide a closed form solution for the inverse left jacobian, so I used MATLAB's symbolic toolbox to arrive at one - for both the general and small angle cases. This has all been unit tested in the same style as SE(3) cases. Incidentally, when testing this on GPU (torch version), I ran into a few problems with the SO2/base interfaces. This PR thus includes a few fixes along those lines.

The class methods in so3 creates new matrices (eye etc.) without taking the device selection taking into account. This patch should fix this by setting the right device directly while creating new matrices.