VIO vs SLAM

[shervinkoushan]

Hi,

Just checking if I have understood this correctly:

• By setting max_slam to 0 in the config file, this will be considered a VIO method.
• Setting it to anything else, this will be considered a SLAM method.

[goldbattle]

The "SLAM features" are still a temporal map (meaning they will be marginalized after they have been lost). Generally we still call this a VIO / odometry method or a "hybrid" which can leverage short tracked features. Generally, a system would be consider a SLAM system if it performs loop-closure and thus can reduce drift by revisiting a previously seen location (this is not what OpenVINS is). Hope this helps.

[shervinkoushan]

I see, thanks for taking the time to answer.

I have two further questions:

1. Based on the results in your paper, as well as my preliminary tests on the EuRoC dataset, it seems like the system performs better with the SLAM features. Is there any reason to not include them, other than the increased computational load?
2. Your roadmap has listed the inclusion of loop-closures as a possible improvement. Is this something you have looked further into?

[goldbattle]

You can read the original MSCKF 2.0 or Mingyang Li's optimization comparison paper for some insights if you are interested. In general it is the complexity, but it can also affect consistency if not handled properly.

I can't comment on the roadmap timeline, that page just has some ideas etc. You can checkout the ov_secondary if you are on 18.04 as an example for loosely-coupled secondary graph. If you want to run a large BA refinement afterwards, checkout the ov_maplab.

[shervinkoushan]

Thank you for pointing me in the right direction.

I will look more into these resources.

Best regards