Clear obstacles resulting from skewed LaserScan data

asked 2012-06-11 06:25:05 -0600

Random-I-Am
45 ●4 ●6 ●10

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)

answered 2012-06-11 09:26:30 -0600

lindzey
1775 ●18 ●31 ●42

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.

edit flag offensive delete link

Comments

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.

weiin ( 2012-06-11 14:53:19 -0600 )edit

Link to similar question posted by @weiin - http://answers.ros.org/question/34271/how-to-solve-delay-in-tf-broadcast-by/

lindzey ( 2012-06-11 21:27:25 -0600 )edit

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!

Random-I-Am ( 2012-06-11 23:50:12 -0600 )edit

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!

Random-I-Am ( 2012-06-13 04:47:56 -0600 )edit

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

weiin ( 2012-06-14 16:50:07 -0600 )edit

also, putting the imu back into the system would cause the skew to return after "fixing" with timestamp increment.....

weiin ( 2012-06-14 16:53:29 -0600 )edit

add a comment