Thank Wim and brian for pointing out the problems. Here are some updates:

Wim's analysis is totally right, 
(1) for rotation, the odometry is 1 second delayed than the laser data; this
behavior is traced back and the subroutine for gyro reading is found the
cause for it. We wrongly used the function flush() under pyserial. After
changed to flushImport(), the gyro readings now update fast enough.
(2) for forward motion, the odometry drift is caused by wrong coefficients
in forward kinematics matrix,which has also been corrected.

With the above corrections, we tested the navigation in our office again.
The result shows the navigation is almost fine, except two points:
(1) the robot rotates suddenly during the movement, which appears too
frequently. Please refer to the following youtube link:
http://www.youtube.com/watch?v=MXvEcovi3f8

(2) Observed from rviz window, there is an accumulative deviation between
the laser scan points and the map. Please also refer to the youtube link:
http://www.youtube.com/watch?v=roAMPNqg0k4

For point (1), we are guessing that it might be due to the robot self
load/high CG position, and the motors are not powerfull enough to drive the
robot when quite small ratation speed is issued by the planner. When the
angular difference is accumulated to certain extent, the PID controllers
within the motor controller will boost the driving current and thus the
sudden rotation (we have a setting for min_in_place_rotational_vel: 0.5, but
seems not optimal).

For point (2), we have no idea about it. Is the AMCL supposed to correct the
robot position?

Your further suggestions are greatly welcome.

xiaojun




-- 
View this message in context: http://ros-users.122217.n3.nabble.com/Navigation-Stack-the-robot-rotates-most-of-the-time-after-receiving-a-goal-tp1471418p1528873.html
Sent from the ROS-Users mailing list archive at Nabble.com.