Error while building map in slam_gmapping.

[kishorekumar29]

I have recorded the rosbag data by simulating the robot in gazebo. I played back the logged bag file and tried to build the map using slam_gmapping node and i ended up in error below

[ WARN] [1453398305.145461344]: Laser has to be mounted planar! Z-coordinate has to be 1 or -1, but gave: -0.03982

After few iterations, i was able to build the map by modifying laser scanner joint origin in my URDF file from

origin xyz="0 -0.040 0.2" rpy="-1.5708 -1.5708 0" to origin xyz="0 -1 0.2" rpy="1.5708 -1.5708 0" but my robot model become weird as below (laser scanner is away from the robot).

How to get around the issue without relocating the laser scanner Below is my original robot model also fine my URDF file here https://www.dropbox.com/s/af99gstvnv1e3s0/jmbot1.1.urdf?dl=0

[codebot]

The link to the URDF file doesn't work for me; I think that link only works if you are logged in to your dropbox account. If you're in the Dropbox web interface and you right-click a filename, one of the options will be "Share..." and it will generate a link to allow public access to the file.

In general, this error from slam_gmapping is saying that (at least, according to its understanding of the URDF) the laser is not perfectly parallel to the ground. I'll have a look at your URDF file once I can see it.

[kishorekumar29]

I have changed the link please check it.

[kishorekumar29]

How to ensure that the laser scanner is parallel to the ground. Since laser scanner is added later to the assembly, how to fix it to the base_plate. How should be the above URDF edited to achieve it.

[codebot]

In the <joint name="hokuyo_joint" type="fixed"> tag, try changing this:

<origin xyz="0 -0.04 0.2" rpy="1.5708 -1.5708 0>

to this:

<origin xyz="0 -0.04 0.2" rpy="0 0 0"/>

to ensure that the coordinate system of the laser is "Z-up". This may require some coordinate-swaps of your xyz attribute, but the orientation of the laser is the more important thing for the error reported by slam_gmapping.

[kishorekumar29]

Yeah, i think the laser coordinates system is not Z-up as the result of above origin values results as below. The orientation of the laser is incorrect. How to swap coordinates of the laser or is there any other way to get around this?

[codebot]

Hmm, I'm not quite sure what's going on, since I can't reproduce your situation without the STL files referenced from the URDF. I would suggest posting the URDF+STL files somewhere where it's easy to get them (ideally a github repo), and then posting this to ROS Answers, where there are many more people watching.

[gerkey]

If I understand correctly, this configuration had the wrong position for the laser, but successfully created a map:

 <origin xyz="0 -1 0.2" rpy="1.5708 -1.5708 0"/>

If so, then you've got the right orientation by the wrong position. Adjust the xyz values (but not the rpy values) to get the laser back on the robot. I would try xyz="0 -0.04 0.2" first.

[kishorekumar29]

@codebot I have posted the STL files of the links along with the urdf over here https://www.dropbox.com/sh/sb03bz7hopntwqh/AAD2oWLLRmZAgTS91YJ_PfzOa?dl=0. I have posted issue in ROS forum.

[kishorekumar29]

@gerkey, Yeah i am able to create map successfully with y value as "-1", but when i try to build map after bringing back laser to robot by y value "-0.04" the error occurs.

[kishorekumar29]

Does this error got anything to do with slam_gmapping node?

[kishorekumar29]

@codebot were you able to rebuild the model and locate the issue, please let me know in case of additional detail requirement.

[kishorekumar29]

Modifying the the URDF to right hand coordinate system fixed the issue.

[codebot]

Just for completeness, in case anyone else finds this ticket later: what did you do to fix your problem? How did you change your coordinate system? I would be interested in knowing how we can detect the problem you were seeing, and generate a warning message on the console with a suggestion of how to fix it. On Feb 4, 2016 6:41 AM, "kishorekumar29" notifications@github.com wrote:

Modifying the the URDF to right hand coordinate system fixed the issue.

— Reply to this email directly or view it on GitHub https://github.com/osrf/rosbook/issues/6#issuecomment-179784201.

[kishorekumar29]

I zeroed on the issue by altering the joint values of my laser sensor, when i iterated my Z values the laser moved in sideways but it is intended to move up and down. Since my robot model was exported from solidworks i re-exported my model through solidworks2urdf after correcting my coordinates in solidworks, which fixed the issue. If we build the URDF from scratch the coordinate issue is will be in rare case.