Closed marcomasa closed 3 years ago
Consider also a translational move to the side, not only the rotation. This feature is also discussed in my lectures. The resulting RPM values need to be scaled, such that the maximum possible RPM value is not exceeded by any motor. 1) Find out the max value rpm_max out of the 4 wheels 2) Calculate the ratio between abs(rpm_max) and RPMMAX (max. possible value) 3) if ratio > 1.0 then multiply the rpm values with this ratio
I tried this in the old evo_drives_control and it significantly improves the behaviour of the navigation stack.
@marcomasa Is it necessary to provide the maximum speed depending on the battery voltage? Or is it enough to provide the maximum speed as an launch file parameter?
A conservative approach is to take the maximum velocity, that the robot can drive at the lowest battery voltage level. If you take the maximum value, the controller has to handle windup effects. I think to linearly decrease the maximum velocity with the battery level would be the best (but complicated) approach. How much is the difference between the highest and the lowest battery voltage?
Implemented in current version
When driving with full speed in linear x direction, the robot is not able to also rotate at full speed, because the wheels can't go faster.
To maintain the input cmd_vel vector, the resulting wheel speeds have to be downsized. For this, the mecanum drive class needs access to the maximum rpm of an evo_mbed::Motor object.
--> Add this to the class