Is the calculated stopping distance too conservative?

[PaulVerhoeckx]

The stopping distance in the end phase d_end_phase (here) contains a component which accounts for the distance traveled during the possible delay due to having a sampling time.

However I wonder if it isn't too conservative, currently it is:

target_x_vel * 2 * dt

Whereas I think the average delay is 0.5*dt, which would result in the following component:

target_x_vel * 0.5 * dt

[cesar-lopez-mar]

You are correct, however in practice this amount of compensation worked well. The need of compensation comes not only by the discrete sampling delay but also because of delays (and possible phase lag) in the robot's velocity controllers. Perhaps we should separate the compensation of both sources of delays.

[PaulVerhoeckx]

If this added compensation is robot specific (which I assume) it should at least be configurable but maybe we should even rethink the open-loop end phase of the velocity profile.

[cesar-lopez-mar]

I agree we should make this reconfigurable. As of the open loop concept, we have had already discussions about it and there is more pros to use open-loop. It is easier to tune and with closed loop you need to implement an additional controller with P-I-D component parameters, which makes tuning more difficult. Moreover, close to the end the velocities are very low, where friction plays an important role, and closed loop controllers tend to show undesired behavior. With open loop on the other hand the behavior is quite predictable.

[PaulVerhoeckx]

I agree that controlling the forward velocity would introduce new configuration parameters, and that these should be kept to a minimum. However, I also wonder whether the open-loop solution with 1 parameter (delta t, as we discussed above) can model the braking distance very well for all target_x_vel's. Because, as you said, different frictions play at different velocities.

Have you tested the accuracy of the current brake distance implementation with different target_x_vel's on a robot?

[cesar-lopez-mar]

Maybe @MCFurry can share his experience with breaking to a stop with the tractor.

We do have another parameter, which is the abs_minimum_x_vel. So in case the decceleration started too early, the robot keeps this speed until target is reached. I tested that with the palletizer robot and sometimes you could see it moving slow at the end for a second, which for our case was good enough.