Clear obstacles resulting from skewed LaserScan data

Question

I recently stumbled upon a strange behavior my robot is showing while rotating. Now, when it rotates I am capable of observing two strange things (visualized using rviz).

• LaserData is always displayed slightly delayed. Meaning, the RobotFootprint is refreshed quick (almost real-time) while the LaserData is not.
• When the rotation of the robot stops the rotation of the visualized RobotFootprint is stopping as well. Unfortunately this is not the case with the LaserData. LaserData will continue to follow the rotation for at least a few frames and then suddenly jump back matching the end pose.

While on first sight this might just seem to be some kind of visualization problem it really affects path planning. For a better understanding assume the robot stands in front of an opened door and rotates to the left. The laser scans representing the right side of the door frame keep moving to the left. In the end they are right in the middle of the door yielding obstacles preventing my robot to plan any path through that door.

The only issue that came to my mind that could lead to such a behavior is the following:

• Some problem with publishing frequencies

Any suggestion is appreciated. I will update my question as soon as someone comes up with any idea and post additional information.

(Our Kinect PointCloud is fine. No delay, no jumps in between two frames)

---

Originally posted by Random-I-Am on ROS Answers with karma: 45 on 2012-06-11

Post score: 1

Answer 1

Do you only see this while rotating, or do you see the same thing (though it'd be more subtle) whenever the robot is moving? Since the data from the Kinect is fine, I'm assuming that your state estimate is OK, but might there be an error in the Hokuoy's timestamps? I think that having them be stamped slightly in the future could cause the behavior you're seeing.

---

Originally posted by lindzey with karma: 1780 on 2012-06-11

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by weiin on 2012-06-11:
I've had the same problem and have tried changing the hokuyo's timestamps (both forward and backward in time). It helped, but only minimally. Interestingly, once I put in an imu (through robot_pose_ekf) things got better.

Comment by lindzey on 2012-06-11:
Link to similar question posted by @weiin - http://answers.ros.org/question/34271/how-to-solve-delay-in-tf-broadcast-by/

Comment by Random-I-Am on 2012-06-11:
This is a general problem but espacially painful while rotating. The most problematic result of this is when the LaserData are creating obstacles while rotating, since those might not be removed because the robot now looks to e.g. the opposite direction. I'll look into the timestamp issue!

Comment by Random-I-Am on 2012-06-13:
What I ended up doing was to write a LaserFilter plugin which increased the timestamp of the LaserData frames by 200ms. This resolves all the issues I described above!

Comment by weiin on 2012-06-14:
Did you notice any difference in turning left and turning right? When I changed the timestamp forward in time, turning one direction would be ok, but turning the other would cause a greater skew. Conversely, timestamp backward in time would cause the skew to be greater in the other direction

Comment by weiin on 2012-06-14:
also, putting the imu back into the system would cause the skew to return after "fixing" with timestamp increment.....