Hi all, I was just looking into the behavior of the timer that is used in most of the demos that ship with Chrono (ChRealtimeStepTimer) and there are a few things I would like to discuss:
The first is something I would consider a bug, and this is that by default, ChVehicle embeds and enables a ChRealtimeStepTimer that, every time its Advance() is invoked, will wait for at least a single "step size" in real-time to have passed. I would argue that by default this embedded timer should at least be disabled (if it needs to be present in ChVehicle at all, one could argue it has not place there at all). My proposal would be to initialize m_realtime_force to false in all constructors. The demos all use their own ChRealtimeStepTimer that, after invoking Synchronize() and Advance() on all modules, will wait for "step size" to have passed anyway. The second is more of a design question. ChRealtimeStepTimer will currently, every time you invoke Spin(double step_size), wait for at least step_size seconds to pass. That means that if the simulation is running slower than step_size for any single step, it will fall behind and never recover. I think it would be better to at least have the simulation try to catch up. Of course, if the simulation is structurally way too slow to run in real-time, that won't help at all, but in cases where occasionally it is a bit slow, it can still catch up and will arguably run "better" in real-time than when it can't catch up at all. Of course it is possible to simply implement a different "MyRealtimeStepTimer" and I'm currently playing around with one. Is this of interest to anyone here? Greetings, Marcel -- You received this message because you are subscribed to the Google Groups "ProjectChrono" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/4c6ceced-9d81-41a4-a061-722dd43aaba6n%40googlegroups.com.
