Hi Marcel, Thank you for bringing this up.
I don’t think having soft real-time enforced by default is necessarily a bug, but I agree that it’d be best to have it default to false. I pushed some changes related to this and changed all vehicle demos to use the real time timer embedded in ChVehicle (and not take care of this themselves). The modification also makes it so that a correct RTF value is reported whether soft real time is enforced or not. As for your last point, I would argue that this goes beyond the scope of what Chrono::Vehicle is designed for. Real time was not and is not a goal in itself for this code. Adding this additional logic would complicate the code unnecessarily and could conflict with cases where the vehicle is embedded in a larger simulation (like is the case with many Chrono applications) in which case it is not the vehicle that dictates time stepping. I believe such a feature is best left to user code, if their particular application could benefit from the ability to catch up to real time later in the simulation. Note that, in typical applications for Chrono::Vehicle, that is unlikely to be possible (either the vehicle can be simulated in or below real time or it cannot). Thanks, Radu From: [email protected] <[email protected]> On Behalf Of Marcel Offermans Sent: Tuesday, June 28, 2022 3:12 PM To: ProjectChrono <[email protected]> Subject: [chrono] Soft real-time timer behavior... 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/4c6ceced-9d81-41a4-a061-722dd43aaba6n%40googlegroups.com<https://groups.google.com/d/msgid/projectchrono/4c6ceced-9d81-41a4-a061-722dd43aaba6n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/PH0PR06MB82375175164C7D62CB0B089BA7BA9%40PH0PR06MB8237.namprd06.prod.outlook.com.
