Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Already moving robot does not stop if planner can not make a plan immediately #750

Closed
sunilsulania opened this issue Jun 26, 2018 · 3 comments

Comments

@sunilsulania
Copy link
Contributor

I have a robot running in a physical loop path with move_base running only in one of its straight segments. So i switch (Give goal to actionserver) to move_base while robot is moving.
In a condition when MoveBase::makePlan return false immediately after switching(giving goal to actionserver) velocities are not updated to zero causing robot to not stop.
makePlan returns false because there is an obstacle covering goal. And as an effect of this, robot goes crashing into obstacle.

I think I got the reason for it :

bool gotPlan = n.ok() && makePlan(temp_goal, *planner_plan_);

if(gotPlan){
.
.
.}
else if(state_==PLANNING)
{
.
.
    if(runPlanner_ && (ros::Time::now() > attempt_end || planning_retries_ > uint32_t(max_planning_retries_)))
    {
        .
        publishZeroVelocity();
        .
    }
.
.}

(ros::Time::now() > attempt_end || planning_retries_ > uint32_t(max_planning_retries_)) This term is false and robot does not stop

@sunilsulania sunilsulania changed the title Already moving robot does not stop if base_local_planner can not make a plan Already moving robot does not stop if planner can not make a plan immediately Jun 26, 2018
@mikeferguson
Copy link
Contributor

I think I might have seen this before and was blaming the simulation. Could you open a PR?

@mikeferguson
Copy link
Contributor

Ok -- I think this is different from what I've seen -- but I think you're right -- I don't see anywhere in the executeCb() where we set velocities to zero. That should probably be done right before we change state to planning.

@DLu
Copy link
Member

DLu commented Jun 18, 2019

Closed via #751

@DLu DLu closed this as completed Jun 18, 2019
GodCed added a commit to GodCed/navigation that referenced this issue Jan 8, 2020
* clear area in layer for melodic

* Added publishZeroVelocity() before starting planner (ros-planning#751)

Edit for Issue ros-planning#750

* Changed logic for when to resize layered costmap in static layer (ros-planning#792)

* Changed logic for when to resize layered costmap in static layer

-Now the master layered costmap should no longer get resized when
isSizeLocked returns true

* Fixing format for if loop

* Provide different negative values for unknown and out-of-map costs (ros-planning#833)

* Add force_updating and affected_maps parameters to tailor clear costmaps recovey (ros-planning#838)

behavior

* Costmap_2d plugin universal parameters and pre-hydro warnings (ros-planning#738)

* Comment and description clarification

* Renamed resetOldParameters to loadOldParameters

* Upscaled pre-hydro parameter info message to warning and added costmap-name

* Warn user when static_map or map_type is set but not used while plugins are used

* Added function that copies parent parameters inside each layer (makes it possible to set a global inflation_radius)

* use parameter magic

* Fixes ros-planning#782 (ros-planning#892)

* Drop Parameter Magic (ros-planning#893)

* Fix typo in amcl_laser model header (ros-planning#918)

* Cherry pick ros-planning#914 (ros-planning#919)

* update changelogs

* 1.16.3

Co-authored-by: Steven Macenski <stevenmacenski@gmail.com>
Co-authored-by: SUNIL SULANIA <sunilsulania9192@gmail.com>
Co-authored-by: David V. Lu!! <davidvlu@gmail.com>
Co-authored-by: Jorge Santos Simón <jsantossimon@gmail.com>
Co-authored-by: Martin Ganeff <martinganeff@gmail.com>
Co-authored-by: Hadi Tabatabaee <hadi.tab@gmail.com>
Co-authored-by: Michael Ferguson <mfergs7@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants