Using the laser_slam_worker without odometry estimate about segmap HOT 25 OPEN

@lucaixia1992 thanks for your interest! Regarding your question I would suggest that you have a look at #69. Concerning the issue that could simply be that the topic names were not properly set.

See: https://github.com/ethz-asl/segmap/blob/master/segmapper/launch/kitti/kitti_loop_closure.yaml#L14
and: https://github.com/ethz-asl/segmap/blob/master/segmapper/launch/kitti/kitti_loop_closure.yaml#L15
and: https://github.com/ethz-asl/segmap/blob/master/segmapper/launch/kitti/kitti_loop_closure.yaml#L17

Hope that helps!

from segmap.

Hi, @rdube thank you for your reply and nice work.This is my yaml file:
LaserSlamWorker: {

use_odometry_information: true,

odom_frame: "world",
sensor_frame: "velodyne",

assembled_cloud_sub_topic: "/velodyne_data",
trajectory_pub_topic: "trajectory",

The velodyne_data is the topic name. I want to know whether you had used the IMU in the kitti dataset.
This is the TF tree when I tried the demo:

This is the TF tree with our own rosbag.

Is it reason of the lack of imu data in my data? I also want to know where to change this TF tree. Because I didn't find the urdf file in your package.
Hope to get your reply, thanks.

from segmap.

In your data, in which frame are the velodyne clouds being published? I only see the map and world frames. Yes it would help if you can run a state estimator based on odometry. It is possible to run without but that can result in low robustness

from segmap.

Hi, the velodyne clouds were published in the velodyne frame with my data. however, I did't see the velodyne frame in the TF tree.

from segmap.

And do you have any state estimator running for example based on imu and / or wheel odometry?

from segmap.

NO，there are only the velodyne points in my data.

from segmap.

Ok you can try setting use_odometry_information and use_odom_factors to false:
https://github.com/ethz-asl/segmap/blob/master/segmapper/launch/kitti/kitti_loop_closure.yaml#L12
https://github.com/ethz-asl/segmap/blob/master/segmapper/launch/kitti/kitti_loop_closure.yaml#L113

This is the configuration that we used in the LiDAR only experiment of our SLAM paper. See section V-D http://n.ethz.ch/~cesarc/files/IROS2017_rdube.pdf

Please keep in mind that this is not related to SegMap but to the LiDAR odometry estimation!

from segmap.

Thank you for your reply. This question is still there according to your suggestion. I think I need to take a good look at your program. Thanks.

from segmap.

@lucaixia1992 I use segmatch with rslidar-16, i solve this problem with remap the rostopic of rslidar-16's point_cloud to "/velodyne_points". there is not warning or error, but the segmatch seems not run at all.

from segmap.

@xuanxiaobing If you care about providing your email, I would like to consult with you on this issue. Thanks.

from segmap.

@lucaixia1992 [email protected] thanks!

from segmap.

OK

from segmap.

Note that you can also remap the topic here: https://github.com/ethz-asl/segmap/blob/master/segmapper/launch/kitti/kitti_loop_closure.yaml#L17

from segmap.

@rdube Thank you for your reply. I think the problem lies in the tf topic. There is no tf topic in my previous data. Now, after I added the tf topic to the data, the problem still exists. I don't know how to convert the relationship between sensor_frame and world only rely on velodyne data. Hope to get your answer.

from segmap.

@lucaixia1992 the issue probably lies here: https://github.com/ethz-asl/laser_slam/blob/master/laser_slam_ros/src/laser_slam_worker.cpp#L99 as the laser_slam_worker expects a transformation from the odom frame to the sensor frame. I believe that in your case this transform is not published.

You could try adding a ros static transform publisher (with eg. identity transformation) see 6.3 in http://wiki.ros.org/tf#static_transform_publisher and set the laser_slam parameters as described above. The laser_slam_worker code could be re-factored to handle that case properly if you feel like looking into this.

Hope that helps!

from segmap.

Hi @rdube Thank you for your reply. It's ok. The issue lies on tf topic. I publish the transformation calculated by ICP and then re-store it in the bag. In this way, I can run successfully with the previous configuration. However, the transformatiion I calculated still require further optimization because there are large errors in the results of the operations.

from segmap.

@lucaixia1992 not sure to understand why you would need to store the ICP transformations in the bag. How did you configure ICP? Are you using another scan registration method than the one provided in the laser_slam package?

from segmap.

Note that if your robot platform is moving quickly, relying on ICP only can result in wrong odometry estimation. This is because computing ICP can require up to a few seconds and the initial guesses can lead to incorrect solutions.

from segmap.

@rdube Thank you for your help. In the case of velodyne data only, using icp to get the tf conversion I need. I'm currently intensively reading your program and looking for other ways instead of using icp to implement it. Thanks

from segmap.

@lucaixia1992 we will present a poster at 10h30 today @ ICRA Localization 1 session (podR). Any chance that we can discuss this issue there?

from segmap.

hi @lucaixia1992 , I'm working on the odometry problem as you, since I only have laser to use. Can I have your email to communicate with you?

from segmap.

Hi@JoeQueenneu I am glad to share my email [email protected].

from segmap.

you just use one rslidar-16？ how to get transform between world frame and base_footprint(rslidar)? @xuanxiaobing

from segmap.

what about the performence of using 16-line laser radar? @xuanxiaobing @rdube

from segmap.

Hi @rdube, how you realized the fusion of wheel odom and imu to provide this odometry, similar question 168 ? Could you please give some reference project? Thanks for your help!

from segmap.