robot starts rotating in place occasionally once it reaches the goal
Hi all,
I have a mobile base which is navigating around a room (already have a map of the room). I am using rotary encoders for odometry and I am feeding phidgets 3/3/3 IMU data along with rotary encoders data to the robotposeekf. I am using amcl for localization and move_base for planning. Everything seems to be working fine but now and then, once the robot reaches the goal, it starts rotating in place continuously and does not come to halt. I am a little surprised because the local planner is not sending any velocities, rostopic echo /cmd_vel
does not show anything whereas rostopic echo /odom
obviously shows the robot pose and twist. One of the common causes of such a behavior is a very low yaw_goal_tolerance
but I increased it to 0.15 and having same problem.
baselocalplanner_params.yaml
TrajectoryPlannerROS:
#Set the acceleration limits of the robot
acc_lim_th: 2.5
acc_lim_x: 2.0
acc_lim_y: 0
#Set the velocity limits of the robot
max_vel_x: 0.5
min_vel_x: 0.1
max_rotational_vel: 1.0
min_in_place_rotational_vel: 0.8
#The velocity the robot will command when trying to escape from a stuck situation
escape_vel: -0.1
#For this example, we'll use a holonomic robot
holonomic_robot: false
#Set the tolerance on achieving a goal
xy_goal_tolerance: 0.15
yaw_goal_tolerance: 0.15
latch_xy_goal_tolerance: false
#We'll configure how long and with what granularity we'll forward simulate trajectories
sim_time: 1.5
sim_granularity: 0.025
angular_sim_granularity: 0.025
vx_samples: 3
vtheta_samples: 20
controller_frequency: 10.0
#Parameters for scoring trajectories
goal_distance_bias: 0.8
path_distance_bias: 1.0
gdist_scale: 0.8
pdist_scale: 1.0
occdist_scale: 0.01
heading_lookahead: 0.325
#We'll use the Dynamic Window Approach to control instead of Trajectory Rollout for this example
dwa: false
#How far the robot must travel before oscillation flags are reset
oscillation_reset_dist: 0.05
#Eat up the plan as the robot moves along it
prune_plan: false
# Global Frame id
global_frame_id: odom_combined
Here is the link to the video which will show clearly the problem I am having (just see the last 2 mins of the video where the robot keeps on rotating in place): https://www.youtube.com/watch?v=YBUowSEEAFs
Ok..Here is the update from the comments and answer: @yohtm and @Procopio. Indeed the robot reaches the goal and prints "goal reached" and cmd_vel stops publishing any velocities and after that, the robot starts rotating. Here is the image which hopefully will give you a better idea:
Also, in the above image when "Goal Reached Yipeee..." is typed, cmd_vel publishes 0 velocity twice and then the publisher stops:
This looks really weird and I feel the motor controller is behaving in a strange manner.
Please let me know if you need more information from me. Does anyone have any idea what is causing such a behavior and how to solve this? Any help will be appreciated.
Thanks.
Naman Kumar
Asked by Naman on 2015-05-19 10:35:06 UTC
Answers
The fact that the /cmd_vel topic is empty makes me believe that the problem is more on the side of your motor controller than on the path planning or localization side. It might be skipping messages (not applying the /cmd_vel message to the motors) or there might be a hardware problem with the motor communication.
[Update]
To follow up on your update, the bug is definitely on the motor side (move_base behaves as planned, sending 0 velocity messages when the last goal is reached). The problem probably lies in the node subscribed to /cmd_vel that sends (serial?) commands to the motor controller. You could check that node and try to understand exactly what it does when it receives a message on /cmd_vel. It might be ignoring messages with certain conditions or it might simply be a bug.
If everything seems ok, then the bug might be in the communication with the controller or in the actual hardware controller.
Asked by yohtm on 2015-05-20 11:19:43 UTC
Comments
That might be the problem but if there is a hardware problem with the motor communication, why does it happen occasionally and not always?
Asked by Naman on 2015-05-20 12:23:24 UTC
A lot of bugs happen only occasionally because of certain events that might or might not occur at the same time. You could try logging the cmd_vel and the commands sent to the motor controller and compare them to see if all messages are applied.
Asked by yohtm on 2015-05-20 12:41:57 UTC
I have to agree with @yohtm. The absence of /cmd_vel is likely due to move_base reaching the goal (can you verify if this message appears in the terminal? it should be something like "goal reached").
Asked by Procópio on 2015-05-21 01:33:24 UTC
I would suggest you directly publish /cmd_vel messages to your robot, with different values and see if you can replicate the behavior without the rest of the setup in place.
Asked by Procópio on 2015-05-21 01:34:23 UTC
Many motor controller implementations have a "watchdog" timeout implemented. Basically, as soon as no command is send on /cmd_vel for X seconds, the watchdog automatically sends zero twist messages, in order to prevent your behaviour.
Asked by daenny on 2015-05-21 02:23:52 UTC
@yohtm and @Procopio.. I think that might be the issue and I have verified that this happens once the robot reaches the goal..I have updated the original question, please have a look. Thanks.
Asked by Naman on 2015-05-21 09:12:07 UTC
Comments
when you say " rostopic echo /cmd_vel does not show anything" , you mean the /cmd_vel topic is all 0s or it does not exist at all?? EDIT: ok, I just saw the video and understand the problem now.
Asked by Procópio on 2015-05-21 01:22:57 UTC