Hi,
I realised that my Gazebo simulation is using a stepsize = 0.001 sec where my NEST setup uses timestep = 0.1 sec.
I cannot quite understand what consequences, if any, that this would have?
Can somebody chip in with some insight on whether I should change either to make them match and in that case which, or if I can simply ignore this and allow Gazebo to take 100 timesteps for each NEST iteration, or whether there is a third option that I don’t know of?
Cheers and thanks in advance
Hi Jakob,
I an not sure if you are discussing about the NRP timestep (also called CLE = Closed Loop Engine timestep), or the bare Gazebo and Nest internal timesteps.
The latter are rather unrelevant to NRP users. WHat is generally set in NRP is the NRP timestep (I think in the BIBI file) which is by default 20ms. In this frame of 20ms, Gazebo and Nest are let to run freely with their own timesteps and then they are paused to synchronize with our NRP transfer functions.
So my guessed answer here would be to just ignore these internal timesteps if they are no particular problem to you.
Axel
Hi Axel and thanks for your reply,
My concern is mainly regarding impulses and for how long a certain force is in effect.
Say NEST evaluates every 0.1 sec to yield a force to be applied in Gazebo. Then I assume that this NEST output force should be considered static for the next 100 iterations of Gazebo’s physics engine, right? This means that I have to consider how to use this force in Gazebo, whether the same value should be applied for 100 Gazebo iterations or treated in a different way.
Furthermore I have to decide on a sample rate for discretizing a transfer function in my Gazebo plugin. My fastest time constant is 0.0326 sec so neither the CLE nor the NEST timestep are sufficient in an ideal world.
If I understand it correctly I guess the easiest is to discretize with 0.001s for the Gazebo plugin and apply NEST output as input to my transfer function until I get a new value from NEST?
Cheers
Hi Jakob,
Your Gazebo plugin will run with whatever timestep, but will indeed get updates from Nest only every 20ms (default CLE timestep), because your transfer functions will run only with that cycle time.
You can change the default timestep and try to set it faster, but the CLE overhead and Nest execution time will most probably slow down your whole simulation, making it not real time anymore (if it was). Though, if you care about control accuracy and not about real time, this might help you, because you will have smaller grained Nest updates in your Gazebo plugin.
Another option could be to user asynchronous transfer functions, but I am not sure it would greatly help in this case, because Nest execution will still be the bottleneck.
Best,
Axel
Gazebo works with seconds but NEST time unit is millisecond (ms), so timestep = 0.1 actually means 0.1 * 10^-3s = 0.0001s => NEST grid is 10 times “finer” than Gazebo’s.