Revision history [back]

Based on @DavidLu's answers I started the following trials:

1. I corrected to the footprint to match the robot as much as possible. It didn't improved very much.
2. I also found out that my robot was not rotating/moving properly, and I fixed it as well. It improved the localization and movement, but the problem was still there.
3. I did fiddle around with inflation radius, it improved the movement. However, the robot could still get stuck frequently, or as you saw in the first video link, it was moving slow.
4. Then I thought well, I am going to read the source code, which helped a lot. and thanks for good coding + comments. In dwa_local_planner page, the forward_point_distance is defined as an additional scoring point in front of the robot. I frankly didn't understand what it meant. However, in the source code, I found out that this value is being used as a cost value for robot alignment to the path. By setting it to zero, the trajectory will not be penalized if the robot is not aligned on the path. This is a very important factor for differential drive robots whose centre of rotation is not the in the middle of the robot. Apparently, a lot of valid trajectories were being dropped because of this. As soon as I set this to zero, the robot was able to perform much better. However, improvements could be done so I continued.
5. I found a very interesting debugging feature in the planner which helps in visualizing the simulated trajectory points. There is a publish_traj_pc private node handler parameter value which is false by default. I didn't know how to set it to true from the config files, so I enabled it in the source and recompiled. The only downside was that the trajectory centres was not on the robot (perhaps their base frame was base_footprint or base_link while I was using map as the reference frame).
6. Using the new visualization parameter, I played around with sim_time, trajectory scoring parameters, vx_samples, and vtheta_samples (note that vy_sample should be 0 or 1 cause the robot does not move in Y vector space). When the number of samples are high, there is higher chance to find solutions if the robot is in a tricky situation. However, increasing the samples requires extensive calculations and after a point move_base will thell you that desired control frequency cannot be achieved. By increasing sim_period the simulation takes longer, and may help in better solutions, but the downside is not achieving the desired control frequency

After a lot of trials, I can conclude that one set of parameters is not enough for a reliable navigation. I would recommend having a couple of settings for different environmental situations. And change the parameters using dynamic reconfigure when the robot gets stuck or fails to reach the goal.

Based on @DavidLu's answers I started the following trials:

1. I corrected to the footprint to match the robot as much as possible. It didn't improved very much.
2. I also found out that my robot was not rotating/moving properly, and I fixed it as well. It improved the localization and movement, but the problem was still there.
3. I did fiddle around with inflation radius, it improved the movement. However, the robot could still get stuck frequently, or as you saw in the first video link, it was moving slow.
4. Then I thought well, I am going to read the source code, which helped a lot. and thanks for good coding + comments. In dwa_local_planner page, the forward_point_distance is defined as an additional scoring point in front of the robot. I frankly didn't understand what it meant. However, in the source code, I found out that this value is being used as a cost value for robot alignment to the path. By setting it to zero, the trajectory will not be penalized if the robot is not aligned on the path. This is a very important factor for differential drive robots whose centre of rotation is not the in the middle of the robot. Apparently, a lot of valid trajectories were being dropped because of this. As soon as I set this to zero, the robot was able to perform much better. However, improvements could be done so I continued.
5. I found a very interesting debugging feature in the planner which helps in visualizing the simulated trajectory points. There is a publish_traj_pc private node handler parameter value which is false by default. I didn't know how to set it to true from the config files, so I enabled it in the source and recompiled. The only downside was that the trajectory centres was not on the robot (perhaps their base frame was base_footprint or base_link while I was using map as the reference frame).
6. Using the new visualization parameter, I played around with sim_time, trajectory scoring parameters, vx_samples, and vtheta_samples (note that vy_sample should be 0 or 1 cause the robot does not move in Y vector space). When the number of samples are high, there is higher chance to find solutions if the robot is in a tricky situation. However, increasing the samples requires extensive calculations and after a point move_base will thell you that desired control frequency cannot be achieved. By increasing sim_period the simulation takes longer, and may help in better solutions, but the downside is not achieving the desired control frequencyfrequency.

After a lot of trials, I can conclude that one set of parameters is not enough for a reliable navigation. I would recommend having a couple of settings for different environmental situations. And change the parameters using dynamic reconfigure when the robot gets stuck or fails to reach the goal.

Based on @DavidLu's answers I started the following trials:

1. I corrected to the footprint to match the robot as much as possible. It didn't improved very much.
2. I also found out that my robot was not rotating/moving properly, and I fixed it as well. It improved the localization and movement, but the problem was still there.
3. I did fiddle around with inflation radius, it improved the movement. However, the robot could still get stuck frequently, or as you saw in the first video link, it was moving slow.
4. Then I thought well, I am going to read the source code, which helped a lot. and thanks for good coding + comments. In dwa_local_planner page, the forward_point_distance is defined as an additional scoring point in front of the robot. I frankly didn't understand what it meant. However, in the source code, I found out that this value is being used as a cost value for robot alignment to the path. By setting it to zero, the trajectory will not be penalized if the robot is not aligned on the path. This is a very important factor for differential drive robots whose centre of rotation is not the in the middle of the robot. Apparently, a lot of valid trajectories were being dropped because of this. As soon as I set this to zero, the robot was able to perform much better. However, improvements could be done so I continued.
5. I found a very interesting debugging feature in the planner which helps in visualizing the simulated trajectory points. There is a publish_traj_pc private node handler parameter value which is false by default. I didn't know how to set it to true from the config files, so I enabled it in the source and recompiled. The only downside was that the trajectory centres was not on the robot (perhaps their base frame was base_footprint or base_link while I was using map as the reference frame).frame). However, if you select odom as the reference frame in the local costmap parameters, the trajectories will be on the robot.
6. Using the new visualization parameter, I played around with sim_time, trajectory scoring parameters, vx_samples, and vtheta_samples (note that vy_sample should be 0 or 1 cause the robot does not move in Y vector space). When the number of samples are high, there is higher chance to find solutions if the robot is in a tricky situation. However, increasing the samples requires extensive calculations and after a point move_base will thell you that desired control frequency cannot be achieved. By increasing sim_period the simulation takes longer, and may help in better solutions, but the downside is not achieving the desired control frequency.

I uploaded another video on youtube with the latest knowledge: Trial N, success

After a lot of trials, I can conclude that one set of parameters is not enough for a reliable navigation. I would recommend having a couple of settings for different environmental situations. And change the parameters using dynamic reconfigure when the robot gets stuck or fails to reach the goal.