# Revision history [back]

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.

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.

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

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.

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

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.

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

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.