The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
As far as I understood this (my colleague and me 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: 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.
| | 2 | link formatting fix |
As far as I understood this (my colleague and me 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: 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.
| | 3 | next try (preview working everytime..) |
As far as I understood this (my colleague and I did link: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.
| | 4 | falling back to html.. |
As far as I understood this (my colleague and I did link: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.
| | 5 | long comment |
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.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
