Revision history [back]

As the laser scanmatcher only matches the current scan with the preceding one, drift over time can't be avoided when using noisy sensor data (which always is the case in the real world). Depending on your needs you could use a SLAM system like gmapping and generate the needed odometry using laser scan matcher.

Alternatively (shameless plug ahead) you can have a look at hector_mapping. Here, scans are matched against the existing map without need for odometry information. For this reason, there is not drift when standing still.

As the laser scanmatcher only matches the current scan with the preceding one, drift over time can't be avoided when using noisy sensor data (which always is the case in the real world). Depending on your needs you could use a SLAM system like gmapping and generate the needed odometry using laser scan matcher.matcher. /edit: See this question/answers for details.

Alternatively (shameless plug ahead) you can have a look at hector_mapping. Here, scans are matched against the existing map without need for odometry information. For this reason, there is not drift when standing still.

As the laser scanmatcher only matches the current scan with the preceding one, drift over time can't be avoided when using noisy sensor data (which always is the case in the real world). Depending on your needs you could use a SLAM system like gmapping and generate the needed odometry using laser scan matcher. /edit: See this question/answers for details.

Alternatively (shameless plug ahead) you can have a look at hector_mapping. Here, there is no need for odometry information and scans are matched against the existing map without need for odometry information. map. For this reason, there is not drift when standing still.