Map not being built using gmapping with depthimage_to_laserscan

Question

Hello,

I am using Zed Camera, to build map of the surrounding. I am trying to build the map using depthimage_to_laserscan with slam_gmapping, however the laser scan data is not being published. Attached is my tf_frames, rqt_graph image, and the launch file I am using. It shows /scan for the laser scan in RVIZ. However, no points are being published, and there is no map being published.

I am not sure where the error is, any suggestion would be appreciated.

Ros: Kinetic, Ubuntu: 16.04

Since I am not allowed to upload images, I am attaching in the link below: https://www.dropbox.com/sh/uh2okf7h2s13ks8/AADfr8BV8Jart_CDIMIbkd0xa?dl=0

Thanks

---

Originally posted by hdbot on ROS Answers with karma: 36 on 2017-04-22

Post score: 0

---

Original comments

Comment by ahendrix on 2017-04-22:
Looks like there's no input to the depthimage_to_laserscan node.

Comment by hdbot on 2017-04-23:
How would I fix that? Any suggestions? Also it says that there is no map received.

Comment by mohsen1989m on 2017-04-23:
You are not publishing what depthimage_to_laserscan needs to subscribe. check the package documentation. you need a image (sensor_msgs/Image) and camera_info (sensor_msgs/CameraInfo). It seems that the Image is of a special type, so it needs a depth image as sensor_msgs/Image...

Comment by hdbot on 2017-04-23:
Yes you are right @mohsen1989m, the issue was of special topic, I managed to fix the issue of the laser scan output, but I still have error of no map received. I have updated the dropbox with new launch file, and the rviz output screenshot.

Comment by Humpelstilzchen on 2017-04-24:
For starters you can remove the remap from scan to /zed/scan. Next you have a static transform for odom. This does not sound right.

Comment by hdbot on 2017-04-26:
Yea I took the static transform off, but that causes issue such that tf has two trees. For some reason it seems that laser scan match is not being triggered. Not sure why though...

Comment by Humpelstilzchen on 2017-04-27:
Two tf trees: Looks like your odometry is not working. The odom->base_frame transform needs to be published by you.

Comment by hdbot on 2017-04-27:
The laser scan matcher node is supposed to do that, even if I publish that transform the map doesn't get built. I have added the laser scan matcher node in the file for reference.

Comment by mohsen1989m on 2017-04-28:
Gmapping relays on odometry, if you don't have odomery data I recommend you to try hector slam. To my experience it works much better and faster than gmapping

Comment by hdbot on 2017-05-01:
Yes I am aware that gmapping is dependent on odometry, hence using Laser Scan Matcher as it generates fake odometry that is used to match the scans. However, the laser scan matcher is using indigo version, and I am using Kinetic, so it is not working. I want to avoid using hector slam if possible.

Comment by Humpelstilzchen on 2017-05-01:
How about rtabmap (or real odometry?)

Comment by hdbot on 2017-05-01:
I tried using rtabmap, but even in that I would not be able to generate map. I followed the tutorial http://wiki.ros.org/rtabmap_ros/Tutorials/HandHeldMapping for Zed Camera, but same issue no map is being generated.

Answer 1

Ok, installed laser_scan_matcher and tested your launch file in my setup with a xtion, so I removed both tfs and the zed_wrapper_node/zed_tf.launch from the launch file. In my comment above I did not see the zed-group (indentation!), so the remaps in depthimage_to_laserscan have to stay, for you they probably have to look like this:

    <remap from="image" to="/zed/depth/image_rect_color"/>
<remap from="scan" to="/scan"/>

Additionally I had to remove the output_frame_id of depthimage_to_laserscan param as base_frame does not exist in my setup. After these changes gmapping went nuts and painted some kind of modern art while jumping around. It either is not supposed to work with my 3d camera or needs heavy tuning, however the launch file basically works.

Update: I should have disabled all my other nodes while testing this (my 'normal' odometry node was the cause of the jumping): Both laser_scan_matcher and gmapping defaults to "base_link" as their frame of reference. As far as I can tell you have no "base_link" in your setup. So you need to set the "base_frame" parameter to "base_frame" for both nodes.

---

Originally posted by Humpelstilzchen with karma: 1504 on 2017-05-01

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by hdbot on 2017-05-02:
I tried your path, when I follow it I get this error: [ WARN] [1493735681.711479943]: Failed to compute laser pose, aborting initialization ("base_link" passed to lookupTransform argument target_frame does not exist. ) Any idea why? I have updated the dropbox with the files containing changes.

Comment by Humpelstilzchen on 2017-05-02:
Obviously one of the nodes is still using base_link instead of base_frame. Please post updated launch file

Comment by hdbot on 2017-05-02:
I have updated the dropbox, as I mentioned in the previous comment. The updated launch file for gmapping, and the file for laser scan matcher is there.

Comment by Humpelstilzchen on 2017-05-03:
The launch file in the drop box does not contain the param "base_frame" for either gmapping or laser_scan_matcher

Comment by hdbot on 2017-05-03:
Sorry the file I uploaded was not the correct file. I have refreshed the dropbox with all recent errors that I receive. Still same issue no map is being built. I just had question, are you also using kinetic?

Comment by Humpelstilzchen on 2017-05-03:
I don't think this is specific to kinetic or any other recent version. You are still missing the param "base_frame" on gmapping.

Comment by hdbot on 2017-05-03:
What do you mean? should I add this : param name ="base_frame" value =:base_frame" in gmapping section of the launch file as well?

Comment by Humpelstilzchen on 2017-05-03:
Yes, of course. Else the base_frame param of gmapping defaults to base_link, which you do not have in your setup.

Comment by hdbot on 2017-05-03:
I did that, and I got same issue, it won't build map. I was thinking maybe the tf is cauzing issue, for example: the laser scan matcher node uses tf, while the camera node uses tf2, could that cause trouble? I have added the tf file for the camera and the node file used for the launch in dropbox.

Comment by Humpelstilzchen on 2017-05-03:
do you get smething with rostopic echo /scan

Comment by hdbot on 2017-05-03:
Yea I get tons of values, I have added the picture in dropbox. Honestly, I am not sure what it is producing, but seems like it is scanning.

Comment by Humpelstilzchen on 2017-05-04:
ok topic /scan works, so zed setup is ok, as is node configuration in launch file. What is exactly the error you have now?

Comment by hdbot on 2017-05-04:
The most recent error that I have is that "no map received" and " For frame [/base_frame]: No transform to fixed frame [map]. TF error: [Could not find a connection between 'map' and 'base_frame' because they are not part of the same tree.Tf has two or more unconnected trees.]".

Comment by hdbot on 2017-05-04:
Still have split TF trees, one with map -> odom, and base_frame->camera

Comment by Humpelstilzchen on 2017-05-04:
Can you post updated tf tree?

Comment by hdbot on 2017-05-04:
https://www.dropbox.com/s/0f8eljk7nr1nwyk/frames.pdf?dl=0 Here is the updated tf tree

Comment by Humpelstilzchen on 2017-05-04:
laser_scan_matcher does not publish odom->base_frame transform for some reason. Do you see any other error? (post full log)

Comment by hdbot on 2017-05-04:
Nope, that's the only error I am getting. I don't know why laser_scan_matcher is not working...

Comment by Humpelstilzchen on 2017-05-04:
How about updated node graph?

Comment by hdbot on 2017-05-04:
https://www.dropbox.com/s/lr1rrq7sgnmqec6/Zed%20Topic?dl=0 .. here is the entire publishing from the terminal

Comment by hdbot on 2017-05-04:
https://www.dropbox.com/s/fm0v4au8kv4qk25/rqt.png?dl=0 .. update rqt

Comment by Humpelstilzchen on 2017-05-04:
There you can see the problem, the topic depthimage_to_laserscan publishes "/zed/scan". Gmapping and laser_scan_matcher both subscribe to "/scan". The remap "/zed/scan"->"scan" should have fixed that. I wonder why it does not work. Try to play with that one.

Comment by Humpelstilzchen on 2017-05-04:
Checked the launch file, your remap is wrong, see my answer for correct remap.

Comment by hdbot on 2017-05-05:
Yes you were right, that fixed the error. I can finally build map. Thank you for all your help!`