Pure localization in 3D case

[gwc88]

Hi,

The "pure localization" works properly in 2D cases, however, when I tried to localization the robot in 3D environment, I encountered the following error:

_# terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check_ [cartographer_node-2] process has died [pid 30846, exit code -6, cmd

I don't know where i am wrong or the 3D pure localization is not completely implemented.

I believe I correctly generated the Map and obtained the "pbstream" file as shown below

[damonkohler]

Pure-localization for 3D is not yet fully implemented. It seems we don't have an issue tracking that, so we'll leave this open as a placeholder for it.

[cschuet]

Towards 3D localization: Add trajectory trimming support to 3d

[gladxu]

The message is caused by unhandled exception of thread pool; you can catch this exception to avoid the program be terminated; but the root cause remains to be investgated; maybe it will be helpful;

--- a/cartographer/common/thread_pool.cc +++ b/cartographer/common/thread_pool.cc @@ -73,7 +73,12 @@ void ThreadPool::DoWork() { } } CHECK(work_item);

• try { work_item();
• } catch(std::out_of_range & e) {
• LOG(ERROR)<<e.what()<<FILE<<LINE;
• }

• } }

[SirVer]

@gladxu That is a bad idea. It fights the symptom (stuff threw exceptions), but not the cause (it should never get an out of range error).

[gladxu]

@SirVer That just avoid the program be terminated by OS;the error information will be logged;and the root cause needed to be find out; It is a bad idea that leave the exception alone, cause the error information provided by OS is too little;you have to do some work to find out where the exception come from;

[SirVer]

I disagree - not terminating the program when an unexpected condition occurred is wrong, since it is very dangerous. So letting the exception crash is better than catching.

Having more detailed information what happened would be nice, I fully agree there :). Unfortunately the exception does not carry a stack trace of the callsite.

[ojura]

I had great experience using Mozilla's rr reversible debugger for debugging hard-to-reproduce errors.

[gladxu]

here is the root cause of the exception cartographer/mapping_3d/scan_matching/rotational_scan_matcher.cc RotationalScanMatcher::RotationalScanMatcher( const std::vector<std::pair<Eigen::VectorXf, float>>& histograms_atangles) : histogram( Eigen::VectorXf::Zero(histograms_at_angles.at(0).first.size())) { //!!access vector.at(0) without vector size check;

[cschuet]

Thanks a lot for tracking this down. Seems like PR https://github.com/googlecartographer/cartographer/pull/501 introduced this code. So assigning bug to @wohe.

[wohe]

The implementation of pure localization in 3D had not been finished, so it was not surprising it did not work yet. I sent a PR that fixes the issue you ran into and one remaining issue related to IMU data. I think 3D localization should be supported now. Please let me know if you still have issues.

[gwc88]

Wooo, great! The 3D localization is working now. But the map was still updating during the pure localization, is there any way to disable the continuous map updating?

Thx!

[gaschler]

In pure localization, trajectory 0 is a static map and is not changed. Can you please specify what you mean by "continuous map updating", i.e. expected behavior and observed behavior? Thanks.

[cschuet]

When you see updates in rviz those are submaps belonging to trajetory 1, i.e. the fixed length trajectory build from sensor data from the localizing agent. This can't be turned off as we localize by both finding matches between scans from the agent against submaps from trajectory 0, i.e. the frozen map, as also the other way around.