ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
OK, I finally took some time to check this out. After playing around a bit I was able to get a robot, in an empty environment in simulation, to achieve very, very, high velocities. I'm not sure that the navigation stack is an awesome way to control an outdoor robot at high speeds, but I can at least give an explanation of why you were likely having trouble:
The local planner doesn't consume the entire global path for planning, instead it is given a region of the path that fits inside of a local window that based on the size of the local costmap. By default, the local costmap is centered at the robot and sized at 6m x 6m. This means that the goal point for the local planner is never going to be more about 3 meters away from the robot. As such, the cost function will actually limit the speeds the robot chooses to be slower because its planning to a point that is only a couple of meters away. Furthermore, as you increase the maximum velocity for the local planner, you're also increasing the size of the steps between simulated velocities. For example, 10 steps between 0 and 1 m/s would give 0.1 m/s increments, but 10 steps between 0 and 10 m/s would give 1.0m/s increments. As such, you could end up with slower velocities chosen for the 10 m/s max than the 1 m/s max because its at a coarser resolution. One solution here would bet to increase vx_samples, but this has performance implications as the planner will simulate a lot more trajectories.
I ended up changing my local map size to something absurdly large, it should be noted that this will also have some performance implications, and ran the local planner again with a high velocity limit. Lo and behold, the robot achieved its max velocity. To hit max velocity even faster, I upped the acceleration limits a bit, reduced the pdist_scale parameter to zero to allow the robot to just pursue its goal point, and switched to Trajectory Rollout from DWA since it consideres accelerations over the entire sim_time for the velocities it commands as opposed to DWA which just considers acceleration over the first simulation step.
I'm not sure this will make for the most reliable or robust planner for your application, but at least it explains what was happenning and I hope it helps.