Property use_now_instead_of_sim_time has no effect

[dmronga]

Hi,

I am using mars under Rock (Ubuntu16.04, Rock branch master, Mars branch master). It seems that the property use_now_instead_of_sim_time does not have any effect.

My use case is the following: I have multiple Rock components attached to a Mars simulation and some of them are using the transformer. When I reset the simulation (through the GUI or via the control_action input port), the timestamps of the Mars sensor readings are reset to the time when the simulation was started. This makes the transformer start dropping transforms because of old data. When I change use_now_instead_of_sim_time to true, the same problem occurs, the timestamps still seem to show the Mars time instead of the current wall time.

I already checked:

• The property is read and applied here: https://github.com/rock-simulation/simulation-orogen-mars/blob/a6ea2a4b4c41d838f6c1c6fa21c22d65b3fa3c97/tasks/Task.cpp#L462
• The current timestamp seems to come from here: https://github.com/rock-simulation/mars/blob/71a60f2c5b09cd8451986b8df9fce6b8f708615d/sim/src/core/Simulator.cpp#L1330

However, the value of cfgUseNow.bValue is always false, even if I set use_now_instead_of_sim_time to true. Any ideas how to solve this?

Best, Dennis

[malter]

Hey, I just fixed the getTime function and the cfgUseNow property handling. Without the property the simulation will return the real time of the last simulation reset + the processed simulated time. With the use_now... time option set, it should always return the current real time.

[planthaber]

Then, that option HAS to make sure, that realtime_calc is enabled.

[malter]

Why and where?

[planthaber]

The simulation in general may run faster or slower than realtime. So using Time::now is misleading, as in 1s simulation time may be e.g. 0.1s or 2s in real time. this will definately lead to different results in the higher level. realtime_calc at least makes sure, simulation time is not faster than the system time.

This is why the system time is normally not used by the simulation.

Also the higher processing levels should use the timestamp of data aquisition and not the current time, as transmission times may vary between the receival of samples.

As Time::now should normally only be used by sensor drivers, not higher level tasks. using the simulation time is normally not an issue. This might also be the reason why use_now_instead_of_sim_time does not work.

Afaik the transformer also works on the timestamps, not Time::now.

I think the better option would be to restart also the transformer, or create a mars option not to reset the simulation time when resetting.

[malter]

I have no Idea how the "high" level deals with data which is in the future. ;-) If the simulation should run in real time but is computational to slow some control task also can't deal with that setup. To my knowledge the simulation should always run (and manage to run) in real time for usage with ROCK. Concerning Time::now, for me the simulation is simulating the sensor drivers and it should be okay to it.

[planthaber]

"high" level means all except the drivers. If those components are all using timestamps instead of Time::now() (system time), there is no issue with different simulation speeds at all.

That was more a general remark, because the availability of that option could confuse devs and make them to rely on system time and not timestamps. So i think it is a bad idea to have that option at all. Also because it makes the user think, it solved the issue but actually it is not. The simulation still can become slower than the system time.

The simulation does not have to run in a similar speed to actual time, even with rock. But only if the components are consistently using the timestamps and not the system time.

I'd rather change the reset to optionally start from system time

[malter]

OK, then we may remove the option. By the way I did a fix that the simulation time is reset to Time::now() and then incrementing the time with the simulated time. This should also solve the reset issue. If it does, we can remove the Time::now().