TUM frequent loss of tracking, operation interruption, segmentation fault.

[zs1013]

Hello, I am running code on Ubuntu 20.04 and am confident that the versions of DBoW and g2o are correct. However, I frequently experience tracking loss while running several TUM sequences, such as in the "freiburg3_cabinet" sequence.

[2024-10-16 22:24:45.111] [I] config file loaded: ./example/tum_rgbd/TUM_RGBD_mono_3.yaml

---

Structure PLP-SLAM:
Copyright (C) 2022, Department Augmented Vision, DFKI, Germany.
All rights reserved.

This is free software,
and you are welcome to redistribute it under certain conditions.
See the LICENSE file.

Camera Configuration:

• name: TUM RGBD monocular 03
• setup: Monocular
• fps: 30
• cols: 640
• rows: 480
• color: RGB
• model: Perspective
  • fx: 535.4
  • fy: 539.2
  • cx: 320.1
  • cy: 247.6
  • k1: 0
  • k2: 0
  • p1: 0
  • p2: 0
  • k3: 0
  • min x: 0
  • max x: 640
  • min y: 0
  • max y: 480

ORB Configuration:

• number of keypoints: 1000
• scale factor: 1.2
• number of levels: 8
• initial fast threshold: 20
• minimum fast threshold: 7

Other Configuration:
PangolinViewer:

• camera_line_width: 3
• camera_size: 0.08
• graph_line_width: 1
• keyframe_line_width: 1
• keyframe_size: 0.05
• point_size: 2
• viewpoint_f: 400
• viewpoint_x: 0
• viewpoint_y: -0.9
• viewpoint_z: -1.9

[2024-10-16 22:24:45.118] [I] loading ORB vocabulary: ./orb_vocab/orb_vocab.dbow2
[2024-10-16 22:24:45.354] [I] >system< connect other module with PlanarMapping module
[2024-10-16 22:24:45.355] [I] >tracking< link planar_mapper to tracker
[2024-10-16 22:24:45.355] [I] startup SLAM system
[2024-10-16 22:24:45.356] [I] start global optimization module
[2024-10-16 22:24:45.356] [I] start mapping module
[2024-10-16 22:24:46.010] [I] initialization succeeded with H
[2024-10-16 22:24:46.014] [I] -- Initializer[Mono] -- trying to initialize plane
[2024-10-16 22:24:46.015] [I] new map created with 55 points: frame 12 - frame 14
[2024-10-16 22:24:46.015] [I] new map created with 3 lines: frame 12 - frame 14
[2024-10-16 22:24:46.057] [I] tracking lost within 5 sec after initialization
[2024-10-16 22:24:46.084] [I] resetting system
[2024-10-16 22:24:46.086] [I] reset mapping module
[2024-10-16 22:24:46.091] [I] reset global optimization module
[2024-10-16 22:24:46.094] [I] clear BoW database
[2024-10-16 22:24:46.094] [I] clear map database
[2024-10-16 22:24:49.829] [I] initialization succeeded with F
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 6) >= this->size() (which is 0)
*** Aborted at 1729088689 (unix time) try "date -d @1729088689" if you are using GNU date ***
PC: @ 0x7f949fcd900b gsignal
*** SIGABRT (@0x3e80008c9bd) received by PID 575933 (TID 0x7f947e299700) from PID 575933; stack trace: ***
@ 0x7f94a0099420 (unknown)
@ 0x7f949fcd900b gsignal
@ 0x7f949fcb8859 abort
@ 0x7f949ff418d1 (unknown)
@ 0x7f949ff4d37c (unknown)
@ 0x7f949ff4d3e7 std::terminate()
@ 0x7f949ff4d699 __cxa_throw
@ 0x7f949ff44369 (unknown)
@ 0x7f94a1770977 PLPSLAM::optimize::global_bundle_adjuster::optimize()
@ 0x7f94a16fabe9 PLPSLAM::module::initializer::create_map_for_monocular()
@ 0x7f94a16fc28b PLPSLAM::module::initializer::initialize()
@ 0x7f94a15fc830 PLPSLAM::tracking_module::initialize()
@ 0x7f94a15fefc5 PLPSLAM::tracking_module::track()
@ 0x7f94a15ffb85 PLPSLAM::tracking_module::track_monocular_image()
@ 0x7f94a15ef498 PLPSLAM::system::feed_monocular_frame()
@ 0x56238d557151 _ZZ13mono_trackingRKSt10shared_ptrIN7PLPSLAM6configEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESC_jbbbSC_ENKUlvE_clEv
@ 0x7f949ff79df4 (unknown)
@ 0x7f94a008d609 start_thread
@ 0x7f949fdb5353 clone
@ 0x0 (unknown)
已放弃 (核心已转储)

[PeterFWS]

hi,

have you de-activated BUILD_WITH_MARCH NATIVE (in ccmake .)?

this should solve the "operation interruption, segmentation fault" problem, which starts from @ 0x7f94a1770977 PLPSLAM::optimize::global_bundle_adjuster::optimize().

Best,

[zs1013]

hi,

have you de-activated BUILD_WITH_MARCH NATIVE (in ccmake .)?

this should solve the "已放弃 (核心已转储)" problem, which starts from @ 0x7f94a1770977 PLPSLAM::optimize::global_bundle_adjuster::optimize().

Best,

The BUILD_WITH_MARCH NATIVE has been disabled, and this situation does not occur every time, so I believe it may be an issue with my processor's performance.
Additionally, I have encountered a problem with the map viewer where the generated trajectory is inverted, causing it to flip upside down. Have you resolved this issue?

[PeterFWS]

Hi,

the issue of inverted trajectory is unfortunately not solved.

Best,

[zs1013]

Hi,

the issue of inverted trajectory is unfortunately not solved.

Best,

I modified the code related to writing the ofs file stream in the trajectory_io.cc file to flip the output trajectory file along the z-axis, allowing it to align with the ground truth during evo evaluation. This is sufficient for me.
I believe that by modifying the code regarding the Pangolin display camera and landmark rendering in the viewer.cc file, I should be able to resolve the flipping issue in the map viewer, but I have not tried it yet.
Thank you.

[PeterFWS]

Hi,

great suggestion! if you have tried successfully to modify Pangolin, please let me know.

Cheers,

[zs1013]

Hi,

great suggestion! if you have tried successfully to modify Pangolin, please let me know.

Cheers,

How should I evaluate the real-time performance of different modes (point, point-line, point-line-surface) in this project? Is there an implementation in the code that calculates the processing time for each frame?

[PeterFWS]

Hi,

in the tracking module you could see code like:

const auto start = std::chrono::system_clock::now();
const auto end = std::chrono::system_clock::now();
elapsed_ms_ = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();

This is used to measure the processing time of the code in-between the start and end.

Best,

[zs1013]

Hi,

in the tracking module you could see code like:

const auto start = std::chrono::system_clock::now();
const auto end = std::chrono::system_clock::now();
elapsed_ms_ = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();

This is used to measure the processing time of the code in-between the start and end.

Best,

Thank you very much!！！！

[zs1013]

Hi,

in the tracking module you could see code like:

const auto start = std::chrono::system_clock::now();
const auto end = std::chrono::system_clock::now();
elapsed_ms_ = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();

This is used to measure the processing time of the code in-between the start and end.

Best,

I apologize for bothering you again. When I ran the fre1_floor dataset using the point-slam component of your project, I obtained a trajectory result (mean RPE=1.529) that differs significantly from the trajectory result (mean RPE=0.02) I achieved using the official ORB-SLAM2 on the same dataset. Could you please let me know if your work is based on ORB-SLAM2? Alternatively, do you have any suggestions? I'm uncertain whether the issue lies with my computer or the environment.

[PeterFWS]

Hi,

the code was based on OpenVSLAM (similar to ORB-SLAM2) as mentioned in the README.

Well, if the trajectory differs that much, maybe the inverted trajectory issue was not properly solved by "flipping the output trajectory file along the z-axis". The SLAM system runs without this issue on my old desk PC as shown in the video I posted in the repository, therefore unfortunately I have no clue what changed in the new Ubuntu system or the new libs.

Best,