I am setting up Nav2 for a tracked rover with 2 DC motors.
I am configuring the Nav2 controller’s max_vel_x and max_vel_theta parameters.
My plan is to simply map the velocity range to the PWM range (e.g., max_vel $\rightarrow$ PWM 255) inside my motor driver node.
My Questions:
Is this simple linear mapping usually enough for Nav2 to perform well?
Or is it strictly necessary to implement PID control (Closed-loop) with encoders to guarantee that the actual wheel speed matches the requested cmd_vel?
Are there other factors I should consider, such as the PWM dead zone (minimum PWM required to start moving)?
I want to know if I can get reliable navigation without complex low-level control loops. Thanks!
I would recommend that before adding navigation, you just make those adjustments of speed correspondence using keyboard teleop. Because essentially when you set those values in navigation, ar the same as the ones you use in teleop. That way you can adjust the speed control node of the rover so that when you say lets say 1.0 meters per second linear X speed it does that .
Obviously, navigation will cope with adjustments but these preflight adjustments can help a lot.
I followed your recommendation and calibrated the open-loop control using teleop. I adjusted the PWM mapping so that:
Linear X: A command of 1.0 m/s results in an actual speed of 1.0 m/s.
Angular Z: A command of 1.0 rad/s results in exactly ‘1.59 full rotations in 10 seconds’.
However, I am facing a problem with low-speed control. I noticed that the motor output required to initiate the movement from a standstill is higher than the output required to maintain the movement once the robot is already rolling.
Because of this, if I send a low velocity command, the robot often fails to start moving. But if I increase the minimum PWM to fix this, the robot moves too fast once it starts going.
My Questions:
What is the standard term for this specific behavior in robotics?
Is it strictly necessary to implement PID control (Closed-loop) with encoders to solve this?
If I want to stick to a simpler open-loop approach, what is the best way to handle this? (e.g., Is there a common technique to compensate for the initial resistance?)
I want to find a reliable solution that isn’t overly complex.
You indicated the solution: you need to implement a closed loop with the encoders. That is mandatory.
Open loop never works in reality because reality is plenty of side effects that you cannot model. A closed loop allows the robot to be sensing all the time what. is actually the current situation and the n modify the control accordingly.