Wrong accumulated_range_data_.origin in local_trajectory_builder.cc??

[JoyTam]

It's about the code! I don't know if this is wrong but it's confusing me a lot? Much appreciated if anyone can help me out!

Well the question is about a piece of code in function AddRangeDate in local_trajectory_builder_2d.cc . It tries to convert RangeData from tracking frame to local frame and put them into the "accumulated_range_data_" :

if (range >= options_.min_range()) {

  if (range <= options_.max_range()) {

    accumulated_range_data_.returns.push_back(hit_in_local);

  } else {

    accumulated_range_data_.misses.push_back(

        origin_in_local +

        options_.missing_data_ray_length() / range * delta);

  }

}

well now "hit in local " and "misses in local" are pushed back into returns and misses of RandeData separately.
However, the origin of the RangeDate is set as follow:

accumulated_range_data_.origin = range_data_poses.back().translation();

Shouldn't its origin be set as "origin in local " as well?
Here it takes the origin of tracking frame as the origin of RangeData origin. But the PointClouds are not necessarily collected from tracking frame. For example, I set the "track frame" as "base_link", and PointClouds are collected from camera frame. There can be an offset bewteen these two and may not just in z direction, which would make no difference in case of 2d then......

I don't know if i make myself understood here. Anyway, look forward to some reply here.
Thanks!

[gaschler]

Is this the same as #947?

[JoyTam]

@gaschler It's not.
It's about PointCloud data collected exactly from one camera.
I think there may exist a error about how the origin of the PointCloud are calculated. In the code, the origin are set as the origin of tracking frame. But actually, the origin should be the camera frame origin.

[gaschler]

@JoyTam Thanks for reporting.
I get the point that the origin is already incorrect for one lidar.
However, when we fix #947 for multiple lidars, this bug will also be fixed.

[JoyTam]

@gaschler Do you mean that the next release will fix this? Because i did't find the fix in the newest commit yet.

[gaschler]

There is no estimated time.
As a work around, you can configure your urdf and lua with options.tracking_frame that the tracking frame coincides with origin of the lidar (unless have an imu, in which case the tracking frame must be at the same position as the imu).

[JoyTam]

@gaschler Thank you for your patience!