terminate called after throwing an instance of 'std::out_of_range' what(): map::at

[BUG423]

When running the MSCEqF example with the Euroc dataset using the provided script, the process aborts with the following error:

error message

terminate called after throwing an instance of 'std::out_of_range'
what(): map::at
run.sh: line 8: 1422290 Aborted

Steps to Reproduce:

Navigate to the MSCEqF build directory.
Define dataset sequence, dataset location, and example location.
Run the MSCEqF example with the Euroc dataset using the provided script.

Expected Behavior:

The MSCEqF example should execute successfully without errors.

Actual Behavior:

The process aborts unexpectedly, displaying an 'out_of_range' error related to a 'map::at' operation in the script.

[AlessandroFornasier]

Hi!

Could you please let me know the structure of /root/ws/src/MSCEqF/dataset/euroc ?

[aforechi]

Hi Alessandro,

I am facing the same issue but with the first two EuRoC sequences only: euroc-mh-01-easy, euroc-mh-02-easy. I hope you can help me resolve this.

Here's what happens: the program exits with the same error message when I try to run it with these sequences but not the other ones. They follow the same directory structure except that these two sequences tests break when reaching timestamps that are exactly the same for imu0 and cam0. The exception occurs at the following two timestamps for sequences 01 and 02, respectively: 1403636580.313555456 and 1403636859.201666560.

Additionally, the out_of_range exception is thrown at updater.cpp line 104.

Congratulations on your excellent work on this project!

Thank you for your assistance.

[AlessandroFornasier]

Hi,

Is this happening at the beginning of the sequences? Could you please check if this happens with both zero velocity update active and zero velocity update inactive?

The issue seems to be related to the fact that there is no associated clone for the camera measurement. I suspect this might happen only in one or the other scenario and might be related to an erroneous cleaning of the buffer after initialization.

[aforechi]

Hi,

Yes, this issue is occurring at the beginning of the sequences. I checked with both zero velocity update active and inactive. When zero velocity update is disabled, the issue no longer occurs.

Thanks

[AlessandroFornasier]

I see, I guess this is actually the case:

The issue seems to be related to the fact that there is no associated clone for the camera measurement. I suspect this might happen only in one or the other scenario and might be related to an erroneous cleaning of the buffer after initialization.

I will soon push a fix.