gmapping and inverted (upside-down) laser

edit

Hello, I've been having the same sort of trouble as was originally posted - I've read this thread through but I'm new enough to ROS that I'm not sure what I ought to do. Here's my situation:

I'm using an inverted Hokuyo scanner at the center front of my robot, with ROS electric and an ASUS netbook. I've tried setting the transform to show gmapping that the laser is inverted by editing the transform from the laser to the base. I've tried changing yaw, pitch, and roll by 3.14 and by 180, I've tried changing them all separately and in combinations, all to no avail. I'm not sure from the patches listed here how to approach this - would someone be so kind as to give me a summary of guidelines?

Thanks,

Khiya

Patch 5250 works for me: I have an inverted SICK, set the 'inverted' parameter to true in sicktoolbox wrapper, my transform has 0 0 0 on roll/pitch/yaw.

File is here, Min angle is 1.5707, Max angle is -1.5707, increment is -0.01745

Did you publish an inverted tf for you laserscanner like suggested here: http://ros.org/wiki/gmapping#Parameters (note for ~inverted_laser)?

The patch you applied removed code that was explicitly added to handle upright laserscanners, that report the scans in an inverted order. Ticket: https://code.ros.org/trac/ros-pkg/ticket/4984

My guess would be a problem with your transform that does not reflect the correct (upside-down) position of your laserscanner. The sign of the angle_increment should only be used to check the scan-order (clockwise or ccw), but not to determine if the laser is inverted.

Update (18.11.2011): I think i have found the problem why our solution didnt work for you. In line 541 of https://code.ros.org/trac/ros-pkg/browser/stacks/slam_gmapping/tags/slam_gmapping-1.2.4/gmapping/src/slam_gmapping.cpp#L541">slam_gmapping.cpp the plain scan.angle_min is used. To get valid results with an upside-down scanner you should use the transformed angle_min from line 338. I am however not sure if this will break mapping for scanners which are not centered (angle_min == -angle_max) but are rotated along the z-axis (for example are looking to the left side of the robot).

Update (25.11.2011): I have uploaded a bag file and our gmapping launchfile here. These are the results: pre-patch and post-patch-5250

When you post your bag, I will try to implement my suggested solution from the last edit. Maybe we can get it to work under all circumstances.

As far as I understood this (my colleague and I did this patch), gmapping does not use the angle_increment to check whether the laser is inverted, but uses the transform information. The laser nodes send their data regardless of the laser placement, as this is done through tf. (And I cannot see an inverting option in hokuyu_node).

Wiki proove: link:http://ros.org/wiki/gmapping#Parameters Did you set your transform correct?

The angle_increment-check is for those laser nodes which send their scan data with an negative step increment, as this has to be reverted for the gmapping lib, which cannot handle a negative increment. At least that's what the slam_gmapping.cpp comment says.

So if you modified gmapping, and the behaviour changed, I doubt it will work everywhere else.

Your patch isn't working with our laser (which btw seems to be a CW one), it's like it was before our patch. As the laser message description (http://www.ros.org/doc/api/sensor_msgs/html/msg/LaserScan.html) says, its usual view is CCW, as the Z axis usally points upwards (http://ros.org/wiki/gmapping#Parameters says the same). The real laser direction is unimportant for that, but some lasers are CW, and the rod4-author didn't want to reverse the range data, so the range array is going from a positive min to a negative max, hence the negative inc, which results in from left to right, CW. Your message should be the exact opposite, you may test a echo for that.

I couldn't find the part where gmapping checks for the transform (IMO roll has to be like 3.14..) but you should check that. In 3 lines from 414 on it implies that variable as the flag to check for invertion, but I cannot see this variable being set in dependence of a tf condition. Maybe you can find the part, or we have to ask the authors.