Comments (10)
can you suggest a good reference for SE(3) / SO(3) / SU(2) derivatives as needed for manifold optimization?
While SE(3) / SO(3) etc. are pretty much covered by standard textbooks, I'm not aware of a good reference when it comes to the concept I call "internal generators". This concept arises by the fact that we represent SO(3) internally as SU(2).
I do have some vague plans to
- add all relevant Jacobians of Sophus Lie groups to the c++ library (including matrix representations as well as quaternion ones)
- derive all Jacobians and other interesting functions (e.g exp/log) using sympy and include such symbolic proofs inside of Sophus.
When I find some time...
from sophus.
Should this maybe be the following,...
👍 the formula makes sense, but it's hard to believe such an error is overlooked by unit tests (!?).
Ah, good point about the unit tests. There is in fact a unit test, and it passes as is, and fails with my suggestion. Thinking about it again, my comment is wrong, since we are multiplying by a generator, and not by another SE3 element. The generators (as 4x4 matrices) all have 0 in their last row, which means that the translation of this
is in fact irrelevant and should not be added, which should translate over to the quaternion representation in the same way, I guess.
from sophus.
P.S.: regarding this issue here, looking at your report, equation (10.19), it makes sense that the translation does not appear in the Jacobian of Sohpus' code either.
from sophus.
Is there really something fundamental going on here?
@NikolausDemmel, you are right. There is not. I merged some changes which make this hopefully much cleaner: SO(2), SO(3), SE(2) and SE(3) have now a number of Jacobians implemented:
Dx_exp_x
with is Dx exp(x)
.
Dx_exp_x_at_0
with is Dx exp(x)
at x=0
,
Dx_exp_x_matrix_at_0
with is Dx exp(x).matrix()
at x=0
, and
Dx_this_mul_exp_x_at_0
with is Dx (this * exp(x))
at x=0.
Here, Dx_exp_x_matrix_at_0
is equivalent to the infinitesimal generator of the matrix Lie group.
And Dx_exp_x_at_0
is what I called "internal generator" before, but I don't believe this term is canonical hence I will avoid it from now on. Finally Dx_this_mul_exp_x_at_0
is the Jacobian which is needed by Ceres and hence replaces internalMultiplyByGenerator
.
All such derivatives are derived from sympy, see py/
directory - which is covered by unit tests.
In addition all derivatives have c++ unit test coverage by comparing the Jacobians with numerical Jacobians using finite differences.
from sophus.
Hence, I believe PR #133 addresses this issue. Please reopen if this is not the case.
from sophus.
Should this maybe be the following,...
👍 the formula makes sense, but it's hard to believe such an error is overlooked by unit tests (!?).
can you suggest a good reference for SE(3) / SO(3) / SU(2) derivatives as needed for manifold optimization?
Sections 7 to 10 of these notes I collected over the years might hopefully be a good starting point... (feedback is welcome!)
from sophus.
can you suggest a good reference for SE(3) / SO(3) / SU(2) derivatives as needed for manifold optimization?
Sections 7 to 10 of these notes I collected over the years might hopefully be a good starting point... (feedback is welcome!)
@jlblancoc: I'm aware of your tech report, and it has been very useful to me many times, thank your very much!
However, for me it leaves some questions open, in particular when trying to understand the implementation here.
Your report discusses the optimization related Jacobians with respect to a matrix representation, not the quaternion one. Also, you follow the convention for current state estimate x
and update in local parameterization u
of x boxplus u = exp(u) * x
, whereas Sophus implements x boxplus u = x * exp(u)
. Finally, it seems that Sophus uses a more general rule for computing the Jacobian of the boxplus update, something like d (x * exp(u)) / d u_i = vec(x * generator_i)
, where generator_i
is the i
'th generator of the lie algebra. I'm not sure of that holds in general? Do you know a reference for the latter rule?
P.S.: I have some minor comments on this part of your report. In what form would you prefer the feedback? Via email?
from sophus.
Hi @NikolausDemmel ,
P.S.: I have some minor comments on this part of your report. In what form would you prefer the feedback? Via email?
Until now people contacted via email, but I have just published the whole thing on a GH repo so it's easier to discuss and propose changes to anyone. Feel free of opening issue tickets there to post your comments on the report.
you follow the convention for current state estimate x and update in local parameterization u of x boxplus u = exp(u) * x, whereas Sophus implements x boxplus u = x * exp(u).
AFAIK, both are valid choices. I can't remember from the top of my head if one has more advantages than the other in computational terms.
Your report discusses the optimization related Jacobians with respect to a matrix representation, not the quaternion one.
I tend to like the matrix version since it led to really "clean" (and linear) Jacobians. Probably we can obtain the Jacobians wrt quaternions by applying the chain rule. That conversion Jacobian would be a nice addition to the report, since it will allow any of the other formulas to work for quaternions too.
something like d (x * exp(u)) / d u_i = vec(x * generator_i), where generator_i is the i'th generator of the lie algebra. I'm not sure of that holds in general? Do you know a reference for the latter rule?
I was not familiar with that rule, but writing it in matrix form, looks valid in general to me.
from sophus.
you follow the convention for current state estimate x and update in local parameterization u of x boxplus u = exp(u) * x, whereas Sophus implements x boxplus u = x * exp(u).
AFAIK, both are valid choices. I can't remember from the top of my head if one has more advantages than the other in computational terms.
This is also my understanding. I have came across both variants many times and there does not seem to be a clear advantage of either approach in general.
I tend to like the matrix version since it led to really "clean" (and linear) Jacobians. Probably we can obtain the Jacobians wrt quaternions by applying the chain rule. That conversion Jacobian would be a nice addition to the report, since it will allow any of the other formulas to work for quaternions too.
Yes that would be useful. In general there is of course also the problem that there are different conventions for quaternions (see Joan Sola's techreport for a detailed discussion).
While SE(3) / SO(3) etc. are pretty much covered by standard textbooks, I'm not aware of a good reference when it comes to the concept I call "internal generators". This concept arises by the fact that we represent SO(3) internally as SU(2).d
Is there really something fundamental going on here? It is simply a matter of representing rotations in different and equivalent ways. And its fine to mix and match, as long as you are consistent. E.g. for manifold optimization, what Jacobians you need depends on whether you differentiate down to the quaternion representation, or stop at the direction cosine matrix, and at the same time whether you apply the update directly to the quaternion, or whether you update an intermediate direction cosine matrix and then convert the result to a quaternion.
I do have some vague plans to
Would be nice to have :-D
from sophus.
Thanks @strasdat
from sophus.
Related Issues (20)
- SO3 setIdentity() HOT 1
- Syntax Error with VS2019 in several headers HOT 2
- QuaternionProduct in So3.hpp missing SOPHUS_FUNC HOT 1
- SOPHUS_FMT_ARG causes compilization error when SOPHUS_USE_BASIC_LOGGING=ON HOT 3
- leftJacobian implementation cannot echo the formula in given PDF HOT 2
- test_so3, test_se3, test_velocities fail on PowePC HOT 5
- Broken link on landing page README.rst HOT 4
- Compilation Error on Raspberry Pi 4 Buster HOT 2
- Looks like 22.10 and 22.04.1 tags got removed? HOT 3
- How to creating a Sophus::SE3f variable from a Eigen::Matrixf variable? HOT 4
- install erorr issue HOT 1
- Wrong compiler standard in CMakeLists.txt HOT 2
- Documentation link is broken HOT 3
- SOPHUS_USE_BASIC_LOGGING=ON compilation error HOT 1
- rotationMatrix() and angles give different results HOT 4
- FMT warning when not found HOT 1
- CUDA::cublas but the target was not found HOT 1
- Sophus ensure failed in function ..... HOT 2
- Error on building ORB-Slam3 on Debian-12 x86-64 HOT 1
- Sophus ensure calls `abort()` HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sophus.