I've been testing the MoveIt! replanning functionality with good results. I'm using Octomap and when I introduce an obstacle in the way of the path during execution, the new plan is correctly computed and the obstacle avoided. However, I noticed that this works only when the _move()_ method is called (In Rviz corresponds to clicking on the Plan&Execute button).
I would expect this functionality to work also when planning and execution are executed separately. At the current state if I attempt to plan (click on Rviz plan button) a path and then execute it (click on Rviz execute button), the re-planning will not be performed when the environment changes resulting in an ignored collision with the obstacle.
I think this is due to the fact that, in the _plan()_ method, the _can_replan_ attribute of the goal is set to false by default as shown here:
https://github.com/ros-planning/moveit/blob/kinetic-devel/moveit_ros/planning_interface/move_group_interface/src/move_group_interface.cpp#L807
Is there a specific reason for that?
If not, a solution could be to change it as shown here:
https://github.com/ros-planning/moveit/blob/kinetic-devel/moveit_ros/planning_interface/move_group_interface/src/move_group_interface.cpp#L846?
Hey there,
I believe the main idea is that if you explicitly plan beforehand (and probably inspected the trajectory),
then you usually don't want your arm to move without further affirmation if something changes (in some cases this is probably (just) a cable hanging from the arm..).
However, the ignored collision is definitely a problem.
The trajectory could/should probably be aborted by the move_group if it is configured to verify trajectories during execution.
can_replan in plan() will not work, because replanning only occurs during execution and the plan method does not execute anything.Hi,
I see that we agree on the point that ignored collision is a problem. I think that even if the plan has been inspected beforehand it would be good to have collision detection to prevent any kind of accident. This will allow to safely run the robot also in a non-controlled environment.
How would you propose to cope with this problem?
Regarding the addition:
I thought that the _plan()_ function was in charge of creating the goal trajectory. Then the trajectory is requested and executed through _execute()_ function. Hence, adding the parameter can_replan in there should be fine, since it will be subsequently used during execution. Isn't that the case?
Hi,
we have the same problem here. The planning is good but the moving arm ignores collisions.
Did you solve your problem? If yes it would be great to know how you did it! The can_replan function does'nt solve the problem :(
Thank you!
+1
Any progress on the re-planning topic?