MiR movement execution is aborted if target goal is occupied

[JanJericevic]

Tested on:

• MiR100 robot
• software version 2.13.3.2

Hello! First of all I would like to thank you for the work done in this repository.

I have a problem when using mir_driver on the real robot.

When sending the robot to a target goal using the web interface, there is a timeout that starts if the target goal is occupied. If the target goal becomes unoccupied during the timeout period, the robot moves to the target goal. If the target goal remains occupied until the end of the timeout period an error is thrown.

When sending a target goal over move_base_simple/goal:

• if the target goal is not occupied, the movement is executed correctly
• if the target goal is occupied:
  • "Goal point is blocked" message is published to the move_base/status and move_base/result topic
  • There is no timeout period where the robot waits if the obstacle will move and the target goal will become unoccupied
  • There is no additional attempt to execute the movement / no additional commands issued
  • Movement is not executed

The same occurs when sending the target goal using 2D Nav Goal or using a actionlib client in a python script.

It was my understanding from this reply, that the mir_driver relays the goal to the planner running on the internal MiR computer.

If that is the case, why does it seem that the planner aborts movement execution if the target goal is occupied since that is not the behavior of the robot when sending the command over the web interface? Do i need to implement the "timeout + retry moving to the target goal behavior" in a separate node?

Any explanation or help regarding this topic is appreciated. I can provide further information about my setup and execution if needed.

Best regards

[mintar]

It's true that the mir_driver simply relays the goal to the move_base planner running on the internal MiR computer. The behavior that you're seeing is the behavior of move_base on the internal MiR PC.

I suspect that the MiR control software simply wraps a loop around the move_base action: If move_base aborts with "Goal point is blocked" error, wait a couple of seconds and run move_base again (up to 10 times). You could implement something similar.

[JanJericevic]

Thank you for the quick reply. I implemented the recommended solution.

A question before closing this issue - is it possible to control the desired/allowed velocities (lin and rot) for the planner over the ROS parameter server? I've tried changing the values of /move_base_node/MIRPlannerROS/max_vel_x, /move_base_node/MIRPlannerROS/max_allowed_vel_x, parameters but it does not seem to change the planner behavior. Changes made on the web interface are shown in these parameters, but changing the parameters over ROS does not change the values shown in the interface. The web interface only offers control over lin velocity and not rot, which also seems strange.

EDIT: these parameters are on the MiR internal roscore, not using the mir_driver

Thank you for your help

[mintar]

I don't think it's that easy.

In general, most ROS parameters are only read when the node starts, so changing them on the parameter server when the node is already running often doesn't accomplish anything.

One exception are dynamically reconfigurable parameters; you can change those via a GUI (rosrun rqt_reconfigure rqt_reconfigure) or via the command line:

rosrun dynamic_reconfigure dynparam set /node parameter_name value

There's also dynparam list and so on, see the wiki page.

However, this probably doesn't work easily via mir_driver; it's probably best to either use the MiR internal roscore directly or even log into the MiR PC and run the command from there. It also depends whether the MiR people implemented max_vel_x and max_allowed_vel_x as dynamic reconfigure parameters or not.

Alternatively, many things that can be done via the web interface can generally also be done via the REST API. There's an open issue (#74) about calling parts of the REST API instead of going via ROS. Perhaps you can dynamically set the velocities that way.

[JanJericevic]

Right. Was hoping some of them were reconfigurable but that doesn't seem to be the case. Too bad, since the interface / REST API planner settings only allow control over linear velocity and acceleration. A similar situation of limited control for light signalization. The way I got it working at the moment is by creating a few while loop missions with a single color, that I run based on which robot status I want to convey.

Thank you for your help, as far as I'm concerned this issue can be closed.