ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Based on what you have said, I would not use move_base for this task. The robot movement will be ugly, and it will be constantly starting and stopping as the goal changes its position.

If it were me, I'd create a custom ros node "motion controller". It's job is to receive a goal distance and angle, then publish Twist messages to the /cmd_vel topic to move the robot closer to the (constantly changing) goal. The Twist velocity value should change smoothly (both up and down), and should be a function of the distance to the goal (or obstacle.)

A basic controller like this one will have no ability to navigate around an obstacle (that's a MUCH harder problem), but the robot can smoothly stop and wait for an obstacle to move out of the way. Detecting whether there is sufficient free space for the robot to move forward safely (collision detect) is also required for a controller like this one.

Based on what you have said, I would not use move_base for this task. The robot movement will be ugly, and it will be constantly starting and stopping as the goal changes its position.

If it were me, I'd create a custom ros node "motion controller". It's job is to receive a goal distance and angle, then publish Twist messages to the /cmd_vel topic to move the robot closer to the (constantly (always changing) goal. The Twist velocity value should change smoothly (both up and down), and should be a function of the distance to the goal (or obstacle.)

A basic controller like this one will have no ability to navigate around an obstacle (that's a MUCH harder problem), but the robot can smoothly stop and wait for an obstacle to move out of the way. Detecting whether there is sufficient free space for the robot to move forward safely (collision detect) is also required for a controller like this one.