Under what circumstances will actionlib not mark a MoveBaseGoal as successful?

asked 2016-08-02 00:07:00 -0500

M@t gravatar image

updated 2016-10-26 15:20:49 -0500

I'm using a SimpleActionClient) to issue MoveBaseGoals to an instance of /move_base in a flat outdoor environment. If I have the "xy_tolerance" parameter for base_local_planner set to ~0.35m or larger then everything works well without any problems. However, If I reduce the tolerance to 0.25m in an effort to improve navigational accuracy, actionlib stops recognising that it has successfully reached the goal - even if it is repeatably within this tolerance in both the X,Y and Z axis (not that there is a vertical tolerance from what I understand). See below for an example bag file

In this case, the state of the goal remains stuck on '1' (labelled as ACTIVE) and will remain that way indefinitely until I manually cancel it.

So my question is: since all I have changed to cause this behaviour is "xy_tolerance", are there any hidden conditions that must be fulfilled for actionlib to move the state from 1 (ACTIVE) to 3 (SUCCEEDED) other than getting the robot within this distance of the goal point? Or am I likely just hitting the limit on how accurate ROS can be in an outdoor environment? The GPS I'm using is accurate to 20mm, as is the global fused data (verified experimentally).

I'm aware that there are a few other questions that address this issue. However, for the most part they seem to experience this problem regardless, whereas I only see it if I lower "xy_tolerance". So I believe the causes may be different.

Any help or advice is appreciated.

UPDATE 1: I must have been using a slightly older version of move_base and actionlib because I recently updated all my ROS packages and now the goal detection is significantly worse, to the point where it almost never correctly detects if it's reached the goal point, even if it's well within tolerance.

UPDATE 2: As suggested by @David Lu I increased the yaw to Pi (3.14) and conducted a test run. While the larger yaw tolerance significantly increased the rate of goals being successfully recognised, there were still several instances where the robot was within both the X,Y and yaw tolerances and yet it still didn't correctly recognise reaching the goal. I'll upload the bag file shortly.

I've looked through the source code for the internal goal check (goal_functions.cpp) and I noticed that the function checks the last pose in the global path (which is just an array of poses) against the current global position, whereas I'm using the original goal sent to the robot vs the current global position. So is it possible that the global path could have been re-calculated and ended up with a goal pose in a different place to the original?

UPDATE 3: As per @David Lu's suggestion (thanks for the help again!) I checked the end of the global path and the current goal:

  • /move_base/current_goal
  • /move_base/TrajectoryPlannerROS/global_plan

Both almost perfectly match the goal I originally ... (more)

edit retag flag offensive close merge delete

Comments

gvdhoorn gravatar imagegvdhoorn ( 2016-08-05 10:39:49 -0500 )edit

I watched the bag and have no solid answers. Initial thought: what happens if you increase the yaw_tolerance to Pi? https://github.com/ros-planning/navig...

David Lu gravatar imageDavid Lu ( 2016-08-06 13:50:21 -0500 )edit

I'll give it a shot and post the results as soon as I can. Thing is though, the robot never gets to the "rotateToGoal" part. So I think the error is in detecting that it's reached the correct X,Y,Z position.

M@t gravatar imageM@t ( 2016-08-07 17:16:29 -0500 )edit

Is there an appreciable difference between the end of the global path and the pose you sent?

David Lu gravatar imageDavid Lu ( 2016-08-21 17:36:44 -0500 )edit

That's exactly what I'm wondering, because the path is essentially an array of poses, and the path is periodically re-plotted so it may well change. I've gotten sidetracked with a different problem, but I fully intend to compare the original goal to the end of the path/current position ASAP.

M@t gravatar imageM@t ( 2016-08-21 17:56:12 -0500 )edit

Nope, almost no difference whatsoever. Doesn't matter if it's the end of the global pose or the pose in the /move_base/current_goal topic. They all match the goal I send.

M@t gravatar imageM@t ( 2016-08-21 23:50:46 -0500 )edit

Hello @M@t , did you find a solution to your problem ?

Kiwa21 gravatar imageKiwa21 ( 2016-09-19 12:18:28 -0500 )edit

No I haven't sorry, I've been distracted by other aspects of my project/health issues so I simply haven't had the time to look into it further. I'll keep chipping away at it as and when I can though.

M@t gravatar imageM@t ( 2016-09-20 15:54:18 -0500 )edit