Closed JanJericevic closed 7 months ago
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.
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
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.
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.
Tested on:
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
:move_base/status
andmove_base/result
topicThe same occurs when sending the target goal using
2D Nav Goal
or using aactionlib
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