Navigation stack caps cmd_vel regardless of actual waypoint location
The navigation stack is set up using the guide provided by this page. The following parameters are used to set up the trajectory planner. The robot is set up using omnidirectional movement that translated the x and y coordinate into an angle and intensity.
However when a waypoint is set the the x_vel is the only value that is changed and only to a value of 0.1. Thus, the robot actually does move forward, but if the waypoint is not directly in front of the device and in the same orientation the device does not stop. Any possible way point yields the same results, regardless of its position in regards to the device.
My thought is that the planner is the part causing problems, but editing the base planner and dwa planner all yield the same results. Are there any deeper caveats to consider when setting up a robot navigation stack, especially in regards to omnidirectional movement? And where should I focus to debug?
These configurations files are the only files I have edited from the Navigation Stack Package: Costmap Common Parameters, Costmap Global Parameters, Costmap Local Parameters, Move_Base launch file, Base Local Planner Parameters
more info needed: real or simulation? NAV stack so LIDAR? Settings for obstacle avoidance/footprint/inflation radius? How do you convert CMD_VEL message to velocity commands to the HW? What is the HW? Show all config files.
Apologies for the delayed response. Kind of figured the question would remain unanswered so I appreciate your time. The application is for real world. I have not done any prior simulations as my desktop runs Windows.
Yes the device uses a LIDAR as the SLAM sensor, however without odometry as hector slam is used.
I have not configured any other parameters than those described in the setup guide. I thought the obstacle avoidance is handled by the local planner.
I'm unsure what is meant by "HW"? If you could clarify I would gladly provide more info. I have a motor command program using ROS that interprets the x and y linear messages as x and y coordinates and translates them into polar coordinates for intensity. Thus the motors move in the direction of an angle and intensity.
Configuration files for the navigation stack have been added to the edited ...(more)
What are you using for localization? I had that problem and it was because of issues between transforms and noisy odom data.
I should say the issue was the robot reaching the waypoint and not stopping. No issues with the velocities.
HW = hardware, in this case I meant the motor controller.
I have concerns about your config files, but I'm not certain it relates to your issue. Max velocity is 1m/s and update rate is 1/second, and transform tolerance is 2. So your robot could move 2 meters without an effective update to the twist command, but your inflation radius is only 0.1m and obstacle range is only 1m. It's conceivable that the planner just doesn't know what to do given the configuration. Why the slow update rate?
Do you have RVIZ running and can see the robot, obstacles, path, and inflation radius? If not, get that all set up because you'll learn a lot about what is happening with RVIZ.
Is use Hector for both mapping and localisation. ACML can be used but it is not advised to use different components.
Luckily I did describe the motor control. I use mecanum wheels so omnidirectional movement is possible, the motor program uses a polar coordinate as it translates to PWM signals easier.
The update rate of the LiDAR is 10HZ. However, with the SLAM algorithm overhead it is closer to 5Hz. I'm unsure about the transform tolerance, if I remember correctly using a lower value meant no cmd_vel message was published at all. A lower inflation radius is used as the device needs to move within an office space with doors and furniture and this allows it to move closer to the edges. I could adjust the obstacle range to detect further. The range of the LiDAR is 8m.
I have had some trouble getting X11 forwarding working on the ...(more)