Use time difference instead of period for cmd_dt

[efernandez]

This makes the limiters more robust under RT issue, since we compute the actual time difference instead of using period. Therefore, this relax the RT constraints.

Tested on gazebo.
Testing on a robot still pending.

[bmagyar]

Seems to be ok. Let me know how the testing on the robot goes. (Maybe even show it before/after)

[adolfo-rt]

What is the RT issue?.

Consider that if the system clock jumps discretely during controller operation unexpected things will happen. cmd_dt could be very large or even negative.

[efernandez]

@adolfo-rt If that's the case, we shouldn't use the period also for the odometry computations (now we use the time difference for computing the twist if dt > 0.0001 because there's a division), right?
@bmagyar has remembered me that using the period for the odometry computations didn't give good results.

[adolfo-rt]

@adolfo-rt If that's the case, we shouldn't use the period also for the odometry computations (now we use the time difference for computing the twist if dt > 0.0001 because there's a division), right?

If odometry uses time differences, then it is also subject to the same issues when the clock changes discretely.

I still don't know what is the RT issue. Is there significant jitter in period values?.