Poor accuracy versus Ceres in VSLAM #398
Comments
|
It's hard to say much here without knowing a lot more about what you're doing (what do you mean when you say graph-based VSLAM, what factors are included, what initialization, etc). It would also be useful to know what optimization parameters are being used with Ceres, or if Ceres is selecting any of those automatically, which it's choosing (which optimizer, which linear solver, inner iterations, etc). It looks like you've tried the DYNAMIC lambda parameter, which is one thing that can improve convergence in more nonlinear problems like bundle adjustment. One other thing that would be useful to know is whether the SymForce optimizer converges eventually, and how many iterations it takes, if you increase the iteration limit. |
The graph-based VSLAM framwork is VINS-MONO, feature-based frontend, factor-graph backend optimized with Gauss–Newton originally, and it optimizes camera poses, velocity, IMU bias, inverse-depth of landmark points.
Here is the Ceres parameter that works well in VINS: Symforce doesn't have DOGLEG, so I replace ceres::DOGLEG with LM in symforce like this: I also tried the default sparse decomposition:
DYNAMIC lambda parameter doesn't work----with it VINS runs even worse. Thus static lambda is used as the 2nd image above.
As for whether the SymForce optimizer converges eventually, it's showed in the fourth image above----seldom converges, usually disconverges and ends up with hitting iteration limit(50 times iterations). |
|
Again I'm not sure how much we're going to be able to debug this over GitHub issues, so this may be a dead end, but a couple more thoughts:
Is Ceres using inner iterations? It might help to have the Ceres solver output, e.g.
I'm not too shocked by this, but I'll note that DYNAMIC is basically what Ceres does by default in their LM implementation, while STATIC is not
What I was asking is, if you set the SymForce iteration limit much higher, what happens? It's much more useful to know what SymForce would do with an unlimited number of iterations (does it converge in 60? 100? 1000? or get stuck?) (does optimizing to convergence give the same solution as Ceres?) than knowing that it often takes more than 50. It is often also useful to see the full verbose optimization trace (by setting the |
I didn't set the option 'use_inner_iterations', and since its default value is false, I guess inner iterations is OFF in my cases.
Log of this test is also being record into the file above. It's interesting that when Ceres runs well, it doesn't converge either(mostly in 4 times iterations, end because iteration time out). And more interesting is, Ceres doesn't run well everytimes(see Ceres_LM_dense_cholesky1~3, which means exactly the same parameter but different results) Here are some other discoveries: |
|
That's actually pretty helpful, thanks Optimization traces like this are exactly those that should be improved by dynamic lambda: Traces like this one are a little weird, but I think may be resolved by using a smaller min lambda - the gain ratio is consistently high (>>1), which is a bit weird but arguably good (the optimizer is making much more progress than it expects based on the current linearization). This maybe suggests the optimizer is making good progress even though the problem is highly nonlinear. Anyway, I'd try decreasing the min lambda. The combination of 1) the fact that you mentioned this used to use GN, and presumably worked ok there and 2) lots of traces like that second one, where lambda monotonically decreases to a very small value also make me think your initial lambda should maybe be much smaller than 1, e.g. 1e-8, which would also make SymForce converge faster. This may also be a reason why you saw dynamic lambda doing worse, because one thing it doesn't do is decrease lambda as quickly. Your points 2 and 4 indicate that the problem is extremely ill-conditioned, and the hessian is either singular or has a very high condition number. 3 might make sense given this - the dense cholesky solver SymForce uses is Eigen's LDLT, which has pivoting, which may make it more stable in the face of the hessian being extremely ill-conditioned. When you say this is VINS-MONO, is it the default implementation https://github.com/HKUST-Aerial-Robotics/VINS-Mono, does it have modifications, is it another implementation, etc? Partly I'm wondering whether your initializations are already very good, and the optimizations you're doing here are making things much worse than just the initialization, and what it would look like if the optimization just did nothing |
|
Here's my further test result, all the test is runing on the euroc MH_05_difficult dataset, using Symforce with DYNAMIC lambda parameter. To facilitate your understanding, I make a table: And here's some new conclusion:
Both Ceres and Symforce use the same initilization result, I didn't modify the initiation part of VINS-MONO. |
|
If you need , I can provide modified VINS-mono |
|
To be honest, it's unlikely that I'm going to have time to look into this soon. Assuming you're talking about a fork of VINS-Mono, running the way they describe in their README for EuRoC on MH_05_difficult with nothing else involved, yeah it seems like a link to the code should be enough to reproduce, that would be helpful if I or someone else has time to look at some point |
|
Leave your email or any other contact information plz, or you can contact me by [[email protected]]，then I could send you the code. |
|
It's going to be much easier if you make a fork of VINS-Mono, and link to your fork here. If for some reason you don't want your code to be publicly accessible, you can create a private repo and invite my GitHub account. |
|
https://github.com/wxliu1/VINS-Mono-NotedByLWX |
|
@empty-spacebar Hi, I am also using SymForce to handle optimization problems, and I have encountered an issue where the optimization iteration time in C++ is too long, approximately 7ms per iteration. May I ask how long each iteration takes in the SymForce implementation you modified for VINS? Do you have any relevant data that you can share? |
Comparison between different hardware or different problem makes no sense, while comparison between solver makes sense. When solving BAL problem, symforce literally does a better job than Ceres. |
Hi,
I replaced Ceres with Symforce in a graph-based VSLAM backend, result in a bad accuracy.
Here are the details:
Screenshots
Environment
Additional context
The text was updated successfully, but these errors were encountered: