gmapping and inversion Hokuyo don't work

Hello,

I'm trying to use the hokuyo on my robot, from upside down. (inverted position)

On Rviz all frames are correct and I see the the laser points perfect (rotated), but gmapping is ignoring the fact of my transformation: <node pkg="tf" type="static_transform_publisher" name="base_link_to_base_laser_link" args="0.058 0 0.125 0.0 0.0 3.1416 /base_link /base_laser_link 100" />

and the mapping is not coherent with what hokuyo senses. As i like show on next images, can someone help-me? (I can't implement slam this way)

( I have tried with <param name="inverted_laser" value="false" />, with <param name="inverted_laser" value="true" /> and without parameter and is the same) I'm using electric version, after images you can see my launch files.

<launch>
<node pkg="hokuyo_node" type="hokuyo_node" name="laser_scan">
<param name="port" value="/dev/ttyACM0"/>
<remap from="scan" to="base_scan" />
</node>
<node name="filbotic" pkg="filbotic" type="filbotic_driver" output="screen" >
<param name="port_name" value="/dev/ttyUSB0" />
</node>
<node pkg="tf" type="static_transform_publisher" name="base_footprint_to_base_link" args="0 0 0 0 0 0  /base_footprint /base_link 100" />
</launch>    

<launch>
<node pkg="gmapping" type="slam_gmapping" name="gmapping" output="screen">
<remap from="scan" to="base_scan" />
<param name="inverted_laser" value="false" />
<param name="maxUrange" value="30.0" />
<param name="particles" value="30" />
<param name="delta" value="0.01" />
<param name="xmin" value="-15.0" />
<param name="xmax" value="15.0" />
<param name="ymin" value="-15.0" />
<param name="ymax" value="15.0" />
<param name="angularUpdate" value="0.5" />
<param name="linearUpdate" value="1.0" />
<param name="map_update_interval" value="1.0" />
<param name="resampleThreshold" value="0.3" />
<param name="llsamplerange" value ="0.05" />
<param name="llsamplestep" value ="0.05" />
<param name="lasamplerange" value ="0.05" />
<param name="lasamplestep" value ="0.05" />
</node>
</launch>

edit retag close merge delete

I ran into this back in Diamondback--Since I had the same problem and hokuyo_node does NOT support an inverted parameter like the SICK node does, I cheated and wrote a quick and dirty node that flipped my scans. I could have sworn someone updated gmapping to support transforms in electric though...
( 2012-01-13 08:18:00 -0500 )edit

Sort by » oldest newest most voted

Could you provide a bag-file of a short drive around? (1-2 minutes or so)

Gmapping has indeed support for transforms, but i think they missed some essential parts. To solve your problem i suggest the following:

This is only one part of the solution! Look at the linked patch file from the edit!
Change line 340 of src/slam_gmapping.cpp:
from:
gsp_laser_angle_increment_ = scan.angle_increment;
to:
gsp_laser_angle_increment_ = angle_min > angle_max ? -fabs(scan.angle_increment) : fabs(scan.angle_increment); 
• Compile gmapping and test again.

If i am right, that should do the trick. It would still be nice if you could create a bag file, so that we have an actual usecase for testing a patch.

Regards, Ben

EDIT (20.01.2012): Sadly the changes above are incomplete and make the result even worse. Based on the new bag-file and two bag files i had from other robots i have now written a patch, that should hopefully work for every constellation of CW, CCW and/or inverted scanners. I have uploaded the patch here. If i get some positive feedback, i will also submit the patch to the bug rebort from arebgun.

more

So what's the final patch in this whole saga? And does it work for all possible permutations and combinations? Thank you for taking the trouble :) PS - Why hasn't it been incorporated into the gmapping source code by now?

( 2014-07-16 12:55:17 -0500 )edit

Thanks for the help. I will try that.

Meanwhile I let here one bag file. http://feupload.fe.up.pt/get/D3nlU7sdnvaOAzz

Regards, Filipe Santos

more

Thanks for the bag! In fact using my approach with your bag made it look much worse. It is not only mirrored but totally messed up. I will try if i find a solution to that...
( 2012-01-20 01:11:29 -0500 )edit
You really have to use the whole patch that I have attached for this to work.
( 2012-01-20 01:12:42 -0500 )edit
@arebgun: Have a look at our commens and answers to the other question. Your patch breaks a lot of other stuff for people with laserscanners that are rotating clockwise and as far as i can see you still did not supply a bag. Im in the middle of creating a patch that may cover all cases. Regards, Ben
( 2012-01-20 01:42:03 -0500 )edit
@Ben_S: I am not saying it does not, at the time I was only trying to get my setup working. Bag fell through the cracks, will try to post it today.
( 2012-01-20 02:31:11 -0500 )edit
I created a new patch: (http://users.informatik.haw-hamburg.de/~aba879/ros/gmapping_inverted_laser_new.patch). For the bag files i had available it seems to work fine. @Filipe Santos: Your odometry seems very poor. Combined with the fast movements the map still gets messed up.
( 2012-01-20 02:56:36 -0500 )edit
@Ben_S: I've uploaded a bag file from our robot here: http://dl.dropbox.com/u/48930510/wubble2_mapping.bag, use this command to run gmapping: rosrun gmapping slam_gmapping scan:=base_scan/scan _odom_frame:=odom_combined. With that said, I tested your patch and the map looks fine.
( 2012-01-20 05:03:53 -0500 )edit
You can also try hector_slam, results look like this: http://img818.imageshack.us/img818/8723/hectorslamportologfile.png . Let me know if you want to try it, I can provide a launch file in that case.
( 2012-01-20 05:06:05 -0500 )edit
@Stefan Kohlbrecher: hector_slam works great too, thanks!
( 2012-01-20 05:31:36 -0500 )edit