Added Minimum Translational Velocity Limit

[AlperenKosem]

Most planners have no minimum translational velocity limit and, People who want to add min limit solve this problem in low level controller. "min_vel_x" parameter is added to rqt_reconfiguration and configuration file.

[AlperenKosem]

for instance :

• Allow setting of minimal velocity #10

[corot]

nice addition; I guest it can be useful on some robots with picky controllers

can you move the new param together with the other velocities (e.g. after max_vel_x), as on .cfg?
Also, there're a bunch of spurious line breaks and a configuration file out of scope

[AlperenKosem]

thanks @corot !

Purious line breaks and a configuration file are deleted, and location of min_vel_x parameter was edited.

[AlperenKosem]

@corot Could you review again?

[corot]

Suggested change

	0.00, 0.00, 100)
	0.0, 0.0, 100)

[corot]

same order everywhere

Suggested change

	void TebLocalPlannerROS::saturateVelocity(double& vx, double& vy, double& omega, double max_vel_x, double max_vel_y, double max_vel_theta, double max_vel_x_backwards, double min_vel_x) const
	void TebLocalPlannerROS::saturateVelocity(double& vx, double& vy, double& omega, double max_vel_x, double min_vel_x, double max_vel_y, double max_vel_theta, double max_vel_x_backwards) const

[corot]

Works only when use_proportional_saturation is false (see my comment below)

[corot]

I'm not sure about this; ratio_x will get a value > 1, but that will be discarded here if using proportional saturation (which is the preferred option, and so we will move below min_vel_x

[AlperenKosem]

I didn't think proportional saturation side. Therefore i thought that there is no problem but you are right. If proportional saturation contains min velocity feature all twist components must speed up. Increased speed can causes unstability. Maybe this section can hard coded as below otherwise i have no solution for proportional saturation for min speed feature.
(I wrote pseudocode for explaining. When moved backwards, vx < min_vel_vx does not valid.)

if (cfg_.robot.use_proportional_saturation)
{
    double ratio = std::min(std::min(ratio_x, ratio_y), ratio_omega);
    vx *= ratio;
    if (vx < min_vel_x)
        vx = min_vel_x
    vy *= ratio;
    omega *= ratio;
}

[corot]

Yes, for sure; but I wonder if that may trigger other problems... 🤔
@croesmann , @RainerKuemmerle , would u mind to take a look at this solution and confirm it doesn't break the intended behavior of proportional saturation?

[corot]

But this will fail with negative x velocities, right?

[RainerKuemmerle]

I think with a min velocity that requires other components to speed up for keeping the curvature is problematic, i.e. proportional scaling. There are in general cases where, for example, vy would violate max_vel_y. In particular on an omni directional drive for which it is perfectly fine to have (0, vy, 0) as a target command.
For a differential drive, the min vel param should affect the wheels if the motivation is that below some velocity command, the wheels are not moving. In this case, it might make more sense to reason on the min rotational velocity on the individual wheels directly to minimize the error in the curvature to follow by the robot.

[corot]

Good point; I also read the old @croesmann's answer to the same issue and he agrees that a minimum velocity doesn't play well with TEB architecture.
If nothing against, I'll close this PR by now.
@AlperenKosem, as suggested, the min wheels velocity makes more sense at controller level.
But thanks a lot for the contribution; please don't feel discouraged to do more in the future!

[AlperenKosem]

Firstly i constrained velocity at controller level side but in this case, robot could not able to follow the trajectory because wheel velocities did not match the velocities which generated by planner. Therefore i added to min. vel. constraint to planner side. But i understand possible problems, thanks for reviews.