what is --dt in gtp.py? and is it sync with command rate that send to the simulator?

[uscodorbay]

Hi guys,
there is question for me how we can control the rate of the command in accurate way. in the gtp.py sample there is an argument '--dt' but it is not the exact time uses for updating the path!
based on the calculation time for solving optimization problem it's more than 300ms. then what means by --dt ?!! and how we can figure out the simulation time and sync it by wall clock?!

[ericcristofalo]

The dt (delta time) here represents the time-step used in the trajectory planning optimization problem. It is not synced with the command rate for the simulator.

For the GTP planner, the trajectory is discretized into n steps (self.n_steps) where each step is assumed to occur dt seconds after the previous step. This dt is then a parameter to tune the trajectory horizon, resulting in longer or shorter trajectories. The resulting planned trajectories are then passed as inputs to the moveOnSplineAsync() command which controls the drone along a dynamically feasible version of our trajectory. This operation is updated essentially as fast as we can run the GTP optimization.

Does this answer your question? And can you elaborate what you mean by simulation time and why you want to sync it by the wall clock?

[uscodorbay]

Thank you @ericcristofalo , I already checked all this functions. by the way thanks again for your good explanation. exactly in your explanation in above commend you wrote where each step is assumed to occur dt seconds after the previous step. assumed to occur dt second
this is exactly my question that how long it takes to happen in simulator?!

how I can sync my upper hand controller's command rate with what is happening in the simulator. I have to do short path planing along with the long path planing(way-points) based on my machine vision target. for doing this I need to make commands in a constant rate (for instance, 15 Hz)

[madratman]

all control APIs (moveBy*()) have a duration parameter for which the control command is applied. see https://microsoft.github.io/AirSim-NeurIPS2019-Drone-Racing/api.html#airsimneurips.client.MultirotorClient.moveByRollPitchYawZAsync for example

you can also append a .join() to make a blocking call moveByRollPitchYawZAsync(...).join()

[uscodorbay]

Thank you @madratman for your response. if I use the control APIs (movBy*()) i'm going to lose the benefit of long path planing! I mean, I don't want to make controller for Long path planing. I aim in an existence course Long Path Planer (Like, what happens with way-points and moveOnSpline*() ) and my controller just do the fine tuning of movement as a short path planner.
so if I use the movBy*() APIs, I'll lose the moveOnSpline*() and I have to make the long path planner based on movBy*() APIs! and I don't have any imagination about how it must be! the imagination of calculating all pitch, roll, .... command signals(with for example 30Hz, command rate) to travel from Start point to End point make me disappoint