laser_scan_matcher with YDLidar
Hello fellow ROS users,
I'm trying to use the laser_scan_matcher together with a YDLidar X4. While the matcher works well on the demo bag, there seems to be some delay when using it with scans recorded from the robot. Whenever the turning or moving direction changes, the matched frame seems to always be somewhat behind the actual robot pose (see rviz image with some decay on the laser scan)
When the robot is moving at constant speed, the matching works as expected. Does anyone know how to fix this issue?
The attached bag file can be tested with
rosrun laser_scan_matcher laser_scan_matcher_node _fixed_frame:=odom _base_frame:=laser_frame
Best regards Mark
It is behind. Doesn't just seem like it. The entire laser scan has to be loaded by the driver prior to being published. The robot is turning while that is happening so by the time the end of the current scan is loaded, the robot is in a different orientation than it was when the scan started. Then the driver publishes the scan that shows where the robot was at the start of the previous scan. Of course the effect is strongest at the beginning points of the scan and lowest at the end points.
So you think that the whole scan itself is kind of skewed? My lidar has a rotation frequency of about 7Hz. Now it kind of makes sense that the robot is at a different position when a scan rotation ends than when it was started.
Does this problem also occur with 'regular' Sick/Hokuyo Lidars but is simply less present because of their higher scanning speed? I could try to increase the scanning speed at my YDLidar somehow. But the proper solution would be to have an IMU which measures the robot movement during a scan and compensates for the resulting distances, right?
I don't see this as a problem. It's just a fact of life. Is it causing some issue you can't tolerate? If it ain't broke....
It causes some problems when performing SLAM (e.g. with gmapping), since new walls "apper" on the map when turning direction quickly changes. Mostly the map is fixed some moments later, but this is not always the case. I got some "dewarping" code based on odometry history from this thread where others also had similar problems, maybe that will help.
At least I'm better aware of the problem now!