gmapping and inversion Hokuyo don't work

asked 2012-01-13 07:39:17 -0600

Filipe Santos

341 ●22 ●28 ●34 http://www.fbnsantos.com/

updated 2014-01-28 17:11:07 -0600

ngrennan
1 ●1 ●1

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.

image description

<launch>
  <node pkg="hokuyo_node" type="hokuyo_node" name="laser_scan">
    <param name="port" value="/dev/ttyACM0"/>
    <param name="frame_id" value="base_laser_link"/>
    <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_link_to_base_laser_link" args="0.058 0 0.125 0.0 0.0 3.1416 /base_link /base_laser_link 100" />
  <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 flag offensive close merge delete

Comments

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

JeffRousseau ( 2012-01-13 08:18:00 -0600 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2012-01-16 21:18:24 -0600

Ben_S

2500 ●14 ●29 ●53

updated 2012-01-20 04:17:00 -0600

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:

Check out the gmapping sources from here
Apply some parts of this proposed patch which has been discussed in this question:

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.

edit flag offensive delete link

Comments

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?

2ROS0 ( 2014-07-16 12:55:17 -0600 )edit

add a comment

answered 2012-01-19 22:18:39 -0600

Filipe Santos

341 ●22 ●28 ●34 http://www.fbnsantos.com/

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

edit flag offensive delete link

Comments

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

Ben_S ( 2012-01-20 01:11:29 -0600 )edit

You really have to use the whole patch that I have attached for this to work.

arebgun ( 2012-01-20 01:12:42 -0600 )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

Ben_S ( 2012-01-20 01:42:03 -0600 )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.

arebgun ( 2012-01-20 02:31:11 -0600 )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.

Ben_S ( 2012-01-20 02:56:36 -0600 )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.

arebgun ( 2012-01-20 05:03:53 -0600 )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.

Stefan Kohlbrecher ( 2012-01-20 05:06:05 -0600 )edit

@Stefan Kohlbrecher: hector_slam works great too, thanks!

arebgun ( 2012-01-20 05:31:36 -0600 )edit

add a comment

gmapping and inversion Hokuyo don't work

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

gmapping and inversion Hokuyo don't work edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

gmapping and inversion Hokuyo don't work