Take the following simple ball drop where I am tracking z-position in a graph with a simulation time step of 0.2ms. After an arbitrary amount of time I check the time step between data points:
We have t2 = 14.8418083, and t1 = 14.8416080, resulting in a dt=0.0002003. Therefore we have a t_error = 0.0000003 (3*10^-7). For a time step of 0.2ms, we have 5000 steps per second. Therefore:
We have a time drift of 0.00015s per 1s.
We have a time drift of 0.15s per 100s, or in other words a 0.15% time drift error due to time step error.
If we had the same t_error for a 50ms time step:
We have a time drift of 0.000006 (6*10^-6) per 1s.
We have a time drift of 0.0006 per 100s, or in other words 0.0006% time drift error due to time step error.
Clearly this is a much bigger problem at lower time steps. This can cause problems when interfacing V-REP with an external application (ie. external control) that is assuming a fixed time step as time can drift!
I am guessing this error is due to the limited precision of float point numbers used to store the time (t_error on order of 10^-7, seems to point to single precision). I think this could be rectified if current simulation time was calculated in another way as a function of the current simulation iteration. Either way just my suspicion, and suggesting!
In other words, store the current simulation iteration as a 64bit unsigned integer, then calculate the current simulation time by multiplying the current simulation iteration by the simulation step size. Just a suggestion, but it would remove the steadily accumulating time error.