Using the laser_slam_worker without odometry estimate

[lucaixia1992]

Hi, I have read the paper for several times in details, and also tried the 2 demos, it works very well. But may I ask SegMatch works well with Velodyne VLP16?

I just started to try to use SegMatch with VLP 16 only. Meanwhile, there is such a problem when I used SegMatch with our own rosbag : I0510 11:48:23.906718 3671 segmapper.cpp:122] publishing local maps [ INFO] [1525924103.907656700, 1523701063.778971112]: Stereo is NOT SUPPORTED [ INFO] [1525924103.907807419, 1523701063.778971112]: OpenGl version: 3 (GLSL 1.3). [ WARN] [1525924106.240226918, 1523701063.984035853]: [SegMapper] Timeout while waiting between world and velodyne. I0510 11:48:26.371474 3671 segmapper.cpp:122] publishing local maps95075
I0510 11:48:26.371620 3671 segmapper.cpp:122] publishing local maps [ WARN] [1525924106.441460653, 1523701064.185756267]: [SegMapper] Timeout while waiting between world and velodyne. [ WARN] [1525924106.644311873, 1523701064.388192654]: [SegMapper] Timeout while waiting between world and velodyne. I0510 11:48:26.704529 3671 segmapper.cpp:122] publishing local maps [ WARN] [1525924106.846493187, 1523701064.589803107]: [SegMapper] Timeout while waiting between world and velodyne. If someone came across the same issue, could you tell us the steps to use SegMatch with our VLP 16 online and the reason about the above problem.Thanks.

[rdube]

@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!

[lucaixia1992]

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.

[rdube]

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

[lucaixia1992]

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.

[rdube]

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

[lucaixia1992]

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

[rdube]

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!

[lucaixia1992]

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.

[xuanxiaobing]

@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.

[lucaixia1992]

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

[xuanxiaobing]

@lucaixia1992 xuanxiaobing@pudutech.com thanks!

[lucaixia1992]

OK

[rdube]

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

[lucaixia1992]

@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.

[rdube]

@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!

[lucaixia1992]

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.

[rdube]

@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?

[rdube]

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.

[lucaixia1992]

@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

[rdube]

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

[JoeQueenneu]

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?

[lucaixia1992]

Hi@JoeQueenneu I am glad to share my email 18946031431@163.com.

[chennuo0125-HIT]

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

[chennuo0125-HIT]

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

[narutojxl]

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!