I noticed that simulation time has an error that tend to creep up. For a default simulation with a 50ms time step this tend not to be a big problem. But at much lower time step (ie. 0.2ms) this can begin to cause problems.
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.
Simulation Time Error Creep
Re: Simulation Time Error Creep
Hello,
perfectly agree. The simulation time step was initially not supposed to be smaller than 5ms, but this constraint was loosen.
We have now switched to a uint64 for keeping track of time. Will be available in next release.
Thanks for the suggestion.
Cheers
perfectly agree. The simulation time step was initially not supposed to be smaller than 5ms, but this constraint was loosen.
We have now switched to a uint64 for keeping track of time. Will be available in next release.
Thanks for the suggestion.
Cheers
-
- Posts: 45
- Joined: 25 Sep 2015, 19:10
Re: Simulation Time Error Creep
You guys are awesome, respond and get things done so fast!