Should SITL pymavlink commands be so DAMN SLOW?

General
, , , ,
1

So right now, I am sending DO_REPOSITION commands to my ArduPlane Zephyr Fixed Wing model in SITL.

They get accepted, but only after a 1s, sometimes even 2-5s.

As you can imagine, this is not ideal!

I need the execution/process to start almost immediately!

So how can someone reduce the latency, and improve the speed of sending/command-acceptance?

Maybe 10Hz is the ideal here, but if there’s a possibility for higher speeds, I won’t mind.

Furthermore, the REQUEST_DATA_STREAM makes me choose how quickly can I get

output data such as GLOBAL_POISITION_INT, and so on,

so can a similar thing be achieved with sending commands?

I am using SITL, so technically, it should be even faster in simulations, right?

Thank you for any help or suggestions!

@khancyr Hopefully you’ll overlook me tagging you (yet again :sweat_smile:)

2

probably just you computer that is slow doing simulation with gazebo.
mavlink input are handled at more than 50hz, so that is instant. But the latest mavlink packet won. So if you send a lot of data, the latest will be executed and override previous command.

You need to look up what is the bottleneck of your simulation, most probably command are executed in time but your sim time is slow. So look at the logs to get an answer.

1 Like
3

Do you know if you’re simulating in realtime?

4

@bobzwik Could you clarify this? What do you mean by realtime?

From my narrow understanding, SITL is just an abstraction of reality. So realtime simulation is not possible, right? Or did I completely miss your question? :sweat_smile:

Thank you for the question.

5

@khancyr Then do you think that me sending REQUEST_DATA_STREAM commands every second to the ardupilot might be the issue?

Does the REQUEST_DATA_STREAM command continuously take priority over my DO_REPOSITION commands?

Btw, since I already mentioned it, is there a way to recall REQUEST_DATA_STREAM right after the stream gets reset back to default Hz rate?

Thank you for giving me the clues and hints!

6

There is no reset to default… You may have a gsc resetting the streamrate. By default if you launch SITL with sim_vehicle.py, you run mavproxy that set the streamrate for you. You need to disable streamrate control from mavproxy (on launch --streamrate -1), I don’t remember on the prompt.

Then the stream rate got no relationship with how the inputs are handle. Stream rate are just to get message output from ArduPilot. You can still send inputs at 400hz on copter even without setting a single stream rate

About realtime. Simulator can run in realtime. That mean that 1 s of simulated time is 1s in reality.
Most probably in your case, 1s of reality isn’t 1s of sim time. Thus the lag you mentioned

7

I meant, if you knew if 1 second of your simulated time is equal to 1 second in real time. If your computer is not powerful enough, it might take longer to simulate 1 second. Which could explain why the drone reacts slowly to commands.