Parameters for Robosense 16-scans lidar

[kokeliang]

Hello. Thank you for your great work on loop closure. I'm trying to evaluate contour context with my own data colleted by robosense 16-scans lidar. The follwing parameters should be adjusted. Could you give me some tips that how to modify these parameters? Thanks again.

# Part of parameters for database and fixed query parameters
ContourDBConfig:
  nnk_: 50
  max_fine_opt_: 10
  # NOTE: which levels ([1, 2, 3, 4]) to generate Keys is hardcoded.
  q_levels_: [ 1, 2, 3 ]  #// the layers to query (Note the difference between `DIST_BIN_LAYERS`)
  ContourSimThresConfig: ## Thresholds for pairwise contour similarity:
    ta_cell_cnt: 6.0
    tp_cell_cnt: 0.2
    tp_eigval: 0.2
    ta_h_bar: 0.3  # Used for KITTI
#    ta_h_bar: 0.75  # Used for Mulran
    ta_rcom: 0.4
    tp_rcom: 0.25

  TreeBucketConfig:
    max_elapse_: 25.0  #// the max temporal delay before adding to the trees
    min_elapse_: 15.0  #// the min temporal delay to wait before adding to the trees

#####################################################
# Part of parameters for generated contours
ContourManagerConfig:
  # NOTE: which levels ([1, 2, 3, 4]) to generate Keys is hardcoded.
  lv_grads_: [ 1.5, 2, 2.5, 3, 3.5, 4 ]  # KITTI in paper
  #  lv_grads_: [1.0, 2.5, 4.0, 5.5, 7.0, 8.5]  # mulran in paper
  # {1.5, 2.5, 3.5, 4.5, 5.5, 6.5}; {1.5, 2.0, 3.0, 4.5, 6.0, 7.0};

  # TODO: reso other than 1.0
  #  reso_row_: 1.0
  #  reso_col_: 1.0
  n_row_: 150
  n_col_: 150

  lidar_height_: 2.0   # ground assumption
  blind_sq_: 9.0

  min_cont_key_cnt_: 9  # minimal the cell count to calculate a valid key around an anchor contour
  min_cont_cell_cnt_: 3  # the minimal cell cnt to consider creating a contour

correlation_thres: 0.64928  # sim score above this value will be plotted as positive

#####################################################
# variable query parameters
thres_lb_: # lower boundary
  i_ovlp_sum: 3
  i_ovlp_max_one: 3
  i_in_ang_rng: 3
  i_indiv_sim: 3
  i_orie_sim: 4
  correlation: 0.3
  area_perc: 0.03
  neg_est_dist: -5.01
thres_ub_: # upper boundary
  i_ovlp_sum: 6
  i_ovlp_max_one: 6
  i_in_ang_rng: 6
  i_indiv_sim: 6
  i_orie_sim: 6
  correlation: 0.75
  area_perc: 0.15
  neg_est_dist: -5.0

[lewisjiang]

Hi @kokeliang, thank you for trying out our code. The parameters mainly depend on what kind of environment you are testing and how you mount your sensor. I suggest you starting from the following parameters:

1. lidar_height_: the height of sensor above the assumed ground plane.
2. blind_sq_: the squared distance from the sensor that you want to exclude.
3. lv_grads_: the heights you want to slice your structures, and it really depends on how far the major structures are from your lidar and your lidar vertical fov.
4. ta_h_bar: the hard bar for CA simialrity, which also depends on structure distance and lidar vertical fov.

[kokeliang]

Hello @lewisjiang. Thank you for your suggestion. I have modified the parameters as you suggested. I'm running contour context with my own data.

If contour context firstly tried to detecte the loop closure of the current key frame by the function queryRangedKNN, then the current key frame without tramsformation into map coordinate system, was put into database via function addScan and pushAndBalance, in this case contour context could find the loop closure successfully, the yaw angle of the loop closure was right, but the position (x, y) was obviously wrong (not the relative position between two key frames or the position in map coordinate system).

I thought before the key frame was put into the database, it should convert its own coordinate system to the map coordinate system, then the position (x, y) in map coordinate system of loop closure would be right. But in this way, contour context could not find any loop closures. Do you know the reason about it? Thank you for your help.

 // std::unique_ptr<ContourDB> ptr_contour_db_;
 // std::unique_ptr<ContourManager> cmng_ptr_;
  cmng_ptr_.reset(new ContourManager(cm_config_, curr_id)); 
  cmng_ptr_->makeBEV<ms_lams::PointType>(out_ptr);
  // cmng_ptr_.makeContours();
  cmng_ptr_->makeContoursRecurs();
  // 2.2 add new
  ptr_contour_db_ -> addScan(cmng_ptr_, out_ptr -> header.stamp);
  // 2.3 balance
  ptr_contour_db_ -> pushAndBalance(curr_id, out_ptr -> header.stamp);

[lewisjiang]

@kokeliang According to your description, I'm not sure if the problem is caused by data adaptation, bugs or just a bad estimate produced by cont2. I suggest you trying out more one-on-one matching of scans (write tests following queryRangedKNN() function) without the database thing and save the intermediate files for visualization. Also, the operation of cont2 has nothing to do with map coordinate system, because it only estimates the relative transform.

[euncheolChoi]

@lewisjiang Hi. Thank you for your great work on loop closure. I'm also trying to run Contour Context, but i have a question about anchor.
I've read your paper on how to get an anchor which becomes a base of an CAC, but I didn't see anything about that, so I'm wondering how to get an anchor CA.
thanks in advance

[lewisjiang]

@euncheolChoi Hi, thank you for your interest. Some CAs are augmented with their vicinity information to become anchors (which carry CAC information), after all the CAs are generated for a scan. Please refer to the following function:

contour-context/include/cont2/contour_mng.h

Line 584 in 6f419e9

void makeContoursRecurs() {

[euncheolChoi]

@lewisjiang Thank you for your kind reply. It helped me a lot!

[xiaoxueshengyao]

I had tried to modify these parameters as you suggested, but still cannot get good result in underground parking. Is there any suggest to get good result? Thank you.

[lewisjiang]

@xiaoxueshengyao The current protogtype of Cont2 uses a naive projection (highest point projection) as a proof of concept. This can be problematic since the ceilings are low in indoor parking lots. I suggest you modifiy the slicing procedure so that the ceiling will not overshadow the lower strutures.