Nav2d operator only turns left
klek17 opened this issue · comments
I have configured the nav2d operator to subscribe to cmd_vel. However when it encounters an obstacle, it always turns left no matter what. In RobotOperator.cpp evaluateAction() function always returns 0.5 when an obstacle is detected. Not sure how to fix this problem as the robot turns left even if the obstacle is on the left while the right is empty.
You mean the operator pubishes to cmd_vel, right? Have you checked the visualization of the Operator's costmap? E.g. whether there is free space where you expect it to be?
Hi, I also encountered the same problem: when the robot can adjust its heading by turning right or left, it sometimes selects the direction that needs a larger rotation. As shown below for an example. There are many such cases in my testing.
I think it may be caused by the randomness when creating the part of the reference trajectory (magenta path) that is very close to the robot. For example, it may be the first or second cell in the reference trajectory that causes the wired rotation of the robot, while the whole reference trajectory seems to be correct. Do you have any idea how to solve it?
Update: have verified that it is caused by the reference trajectory. The reference trajectory seems to be started behind the robot, rather than in the front. So there are many cases the robot will need unnecessary turning around and then go to the target. See the following for an illustration.
Both examples actually look fine to me. In the first scenario, the robot prefers to keep it's current rotation instead of making a full stop and start rotating to the other direction. This is working as intended, because we don't want to change the direction too abruptly. In the second example the new target lies behind the robot, so it needs to turn, doesn't it?
If you feel the robot is clinging too closely to the planned path, there is an (as I just found out apparently undocumented) parameter called "command_target_distance" for the navigator. It controls how away from the robot the next target for the RobotOperator is taken from the planned trajectory. So increasing it can also increase the smoothness of the trajectory, but might also decrease the performance in narrow environments.
Thank you for the detailed reply and I understand your consideration.
I am actually more concerned about the amount of rotation because I am evaluating the quality of the map built by SLAM. It seems that more roration will introduce more errors in the scan matching procedure. So regarding my concern, in Case-2, the robot should turn left to rotate less than pi, rather than turning right. I also agree with you on practical considerations.