Experimental Results on market sequence of OpenLORIS dataset

[HJMGARMIN]

I have run Dynamic-VINS on my own platform and evaluated it using openloris-scene-tools.
I compared our results with the results in the paper, and I found the result of market1-3 is not same as the paper. As shown below


The last line in the first figure is our result, the second figure is the results in orignal paper. As you can see, our result and VINS(both pinhole and fisheye) on market1-3 are inconsistent at the same position. However, the results in your paper is consistent. Can I achieve the effect in the paper by adjusting the parameters in *.yaml files?
The parameters we currently use that may be related to this are configured as follows：

#RGBD camera Ideal Range
depth_min_dist: 0.3
depth_max_dist: 3

frontend_freq: 30 # It should be raised in VO mode(without IMU).
keyframe_parallax: 10.0 # keyframe selection threshold (pixel); if system fails frequently, please try to reduce the "keyframe_parallax"  
num_grid_rows: 7
num_grid_cols: 8

#unsynchronization parameters
estimate_td: 1    ##########                  # online estimate time offset between camera and imu
td: 0.000                           # initial value of time offset. unit: s. readed image clock + td = real image clock (IMU clock)
#feature traker paprameters
max_cnt: 130           # max feature number in feature tracking. It is suggested to be raised in VO mode.
min_dist: 30            # min distance between two features
freq: 10                # frequence (Hz) of publish tracking result. At least 10Hz for good estimation. If set 0, the frequence will be same as raw image
F_threshold: 1.0        # ransac threshold (pixel)
show_track: 1           # publish tracking image as topic
equalize: 1             # if image is too dark or light, trun on equalize to find enough features
fisheye: 0              # if using fisheye, trun on it. A circle mask will be loaded to remove edge noisy points

#optimization parameters
max_solver_time: 0.04  # max solver itration time (ms), to guarantee real time
max_num_iterations: 8   # max solver itrations, to guarantee real time

#imu parameters       The more accurate parameters you provide, the better performance
acc_n: 0.1          # accelerometer measurement noise standard deviation. 
gyr_n: 0.01         # gyroscope measurement noise standard deviation.   
acc_w: 0.0002         # accelerometer bias random work noise standard deviation.  #0.02
gyr_w: 2.0e-5       # gyroscope bias random work noise standard deviation.     #4.0e-5

g_norm: 9.805       # gravity magnitude

#rolling shutter parameters
# rolling_shutter: 0                      # 0: global shutter camera, 1: rolling shutter camera
# rolling_shutter_tr: 0               # unit: s. rolling shutter read out time per frame (from data sheet)
rolling_shutter: 1                      # 0: global shutter camera, 1: rolling shutter camera
rolling_shutter_tr: 0.033               # unit: s. rolling shutter read out time per frame (from data sheet)

[jianhengLiu]

Hi!
I run another time of the exp using the default config in openloris_vio.yaml, and output a similar result in the paper as follow:

As my experience, the discontinuity always comes with the failure of feature tracking, you could debug it by turning on the visualization (show_track: 1).

[HJMGARMIN]

Thanks for your reply. I run another time using the default configuration. I found that it is "loop_closure: 1" causes the discontinuity. However, I do not know why.
If I disable loop_closure, I cannot always get the estimation poses results in the *.txt file. I usually get nothing in vins_result_no_loop.txt.
When I enable loop_closure, I can get estimation poses in vins_result_no_loop.txt or vins_result_loop.txt. But I do not which file contains the poses every time before I open the file. The save path and related congiuration are as follows:
output_path: "/home/ubuntu-slam/dvins/src/Dynamic-VINS/output" #loop closure parameters loop_closure: 0 # start loop closure fast_relocalization: 0 # useful in real-time and large project load_previous_pose_graph: 0 # load and reuse previous pose graph; load from 'pose_graph_save_path' pose_graph_save_path: "/home/ubuntu-slam/dvins/src/Dynamic-VINS/output/pose_graph" # save and load path
or
output_path: "/home/ubuntu-slam/dvins/src/Dynamic-VINS/output" #loop closure parameters loop_closure: 1 # start loop closure fast_relocalization: 0 # useful in real-time and large project load_previous_pose_graph: 0 # load and reuse previous pose graph; load from 'pose_graph_save_path' pose_graph_save_path: "/home/ubuntu-slam/dvins/src/Dynamic-VINS/output/pose_graph" # save and load path

[jianhengLiu]

Sorry that this repo focuses on odometry(estimator), the pose graph part is not in a well maintained state.
For your problem, that is because the estimator part doesn't have the function to save poses result, you could add-on it by imitating the function in pose_graph.

[HJMGARMIN]

Thank you. I will try your suggestions.

[HJMGARMIN]

I found the reason of saving nothing and fixed it! When I disable the pose_graph_nodelet, the problem does not occurs.
Because, the authors of VINS-Mono use a same string "VINS_RESULT_PATH" in both pose_graph_node and vins_estimator_node. When the loop_close is enabled, the two node will conflict during saving poses to *.csv. Just modify "VINS_RESULT_PATH" into different string in any node will slove the problem.