Ready for prime time?

[colinxs]

First off: thank you for all your hard work! I'm so very excited to see more robotics work being done in Julia!

I've been working on a GTSAM-based SLAM module in C++ to enable accurate real-time state estimates for a multi-agent autonomous vehicle research project. I also recently came across Julia, fell in love, and switched all my Python development to Julia.

So, I'm curious if RoME/IncrementalInference is fast and bug-free enough to replace our C++ GTSAM component. As a rough estimate, I would be adding roughly 15-100 factors a second and require state estimates at that same rate.

So, is RoME/IncrementalInference ready for prime time?

[dehann]

Hi, thanks for the interest. Yes, we have been using Caesar/RoME/IncrementalInference for a while now. The main inference algorithm multimodal-iSAM is the direct decedent of iSAM2 used by GTSAM, although we are targeting a different set of use cases at this time -- i.e. graphs that can be solved slower but that vastly more complicated than individual Gaussian assumptions. We want to implement the parametric iSAM2 equivalent solver here (already 85% there in the code already, Bayes tree etc.) but it hasn't made it to the top of the list just yet unfortunately. There are has been more interest in this lately, so we should just get it done.

The path we are following regarding the computation time to rather to separate real-time requirements by using dead-reckoning from the last local fixed-lag solution. It is not always necessary to solve the factor graph multiple times a second -- although we are constantly working on improving speed and there are still a great many things we can / will do. When we finalize the parametric only version (i.e. Gaussians only), that would likely be comparable to GTSAM-like behavior

To gauge, the largest batch solve we have done to date is 10000 variables with 1700 bimodal (uncertain data association factors) which solved in around 3 hours on a beefy machine. This was a much older version of the code, without incremental updates, or tiered priority and fixed-lag operation, i.e. many performance tricks. To be clear though, that is a fully functional solution to a system that has 2^1700 theoretical modes -- a staggering search space.

I would say you should think about solving around 50 variables in a truely non-Gaussian manner, and let your odometry / dead-reckoning resolve the real-time requirements against the latest available factor graph solution. By non-Gaussian we mean / are targeting the physical measurements from sensor physics -- think raw correlator outputs in from front-end analog/digital sensor processing.

The Caesar.jl packages are under constant development and improvement (3 years and counting), so many updates to come over the long term. We are pretty far behind on documentation and have been working hard on that the last 2 months or so, so the code can do much more than the docs show at this time. We are actively busy with algorithmic research and expect a change in underlying algorithms are on the horizon too.

If you have any specific ideas / suggestions / requests please log them here or at Caesar.jl. We are certainly open to discuss.

[dehann]

Oh, and on Julia -- yes, we are pretty excited about JuliaRobotics. Keep in touch and let us know your interests. There are around five or six of us in the JuliaRobotics space at this point, but sure the number will slowly grow over time. I have also moved to Julia from various other common robotics/algorithmic/C.S. languages, and been very happy with it. If you missed the move to Julia 1.0 over the last 6 months, the larger community of 2000 odd packages are just emerging from the upgrade cycle now, and its a pretty big deal to have Julia 1.0 out, so it is a great time to start using it more.