Optimize SITL to run faster?

SITL is generally super slow to run. I’m not talking about compiling the firmware. This is about running SITL after everything has already been compiled and ran once. Running multiple instances is near impossible on a single computer. Are there some flags I can try for a “lightweight” SITL? What are some factors that will contribute the most to execution speed, besides hardware?

Hello,
What do you mean by slow, it is design to run like a real device ? And compiling on a decent computer on linux should’nt take more that 2min.

You can run multiple instance by using the I parameter and --use-dir to put the log and flash in another directory.

Otherwise you can always speed up the simulation with SIM_SPEEDUP parameter . Becarefull, if you are launching SITL with sim_vehicule.py, then mavproxy will be launch by default and the radio and GCS failsafe will trigger if the speed is greater that 10.

2 Likes

Hi,

Wow, 10 instances running with ArduPilot SITL on the same computer?

Are these containerized somehow or do you use the -I flag?

By slow I mean eating lots of resources – arduplane seems to be around 18% of my CPU, and mavproxy 16% on average without the vehicle flying. This becomes worse if I fly. And then starting another instance slows everything down further more as processes compete for resources. Only 1 CPU on this machine. 2GB RAM.

MAVProxy is optional, and a known CPU eater. You can simply not launch more MAVProxy instances if you don’t need them. (You only have to open the port from SITL once to actually launch the sim).

On my machine I’m seeing Plane SITL (running a quadplane) consume 4% CPU simulating at real time. If I launch a normal plane simulation using JSBsim for physics I see SITL consume 7% CPU, and JSBsim eats another 8%. (These are all linux numbers so that’s on a core, not the entire machines workload).

Are you running SITL on windows or linux?

Linux

I tried disabling mavproxy, which helps but I need to open two ports so I’m not sure how to do it without mavproxy. By default there’s only 5760 that’s open I think? I removed all the unnecessary modules from mavproxy too (down to default-modules=link,output,param)

You can connect mavproxy manually, then disconnect/kill it. mavproxy.py --master tcp:127.0.0.1:5760 then just kill it again. If some GCS (or MAVLink speaking thing) won’t be connected to it though I’m not sure what it’s doing for you?

I mean that I’d like to start SITL and have two ports ready & open to it, so I can connect to it from two clients.

So since I don’t know how to do it without mavproxy, I have to use mavproxy such as

mavproxy.py --master 127.0.0.1:5760 --out 127.0.0.0:8888 --out 127.0.0.1:9999

You may be able to use cmavnode, mavlink-router or mavlink-hub instead.

lightweight alternatives to mavproxy? :slight_smile:

SITL open 3 tcp ports : 5760, 5762, 5763

And yes it was just using -I parameter

Disabling mavproxy speeds things up by a lot. The dronekit calls I’m making on the other ports (e.g. 5762) appear to be much much faster and reliable. I used to be able to make calls that would take easily a few seconds and sometimes just hang, but now everything gets through within a second or less.

How is mavproxy slowing things down? The SITL seems to be much less responsive when a mavproxy is connected to it and client connections go through mavproxy.

Is there a way to configure these SITL ports (5760 etc.) ? E.g. if I want UDP instead of TCP. Or if I want other ports?

MAVProxy does some very tight loops/sleeps in places which just reschedules the task, even though there is not any work for it yet. It’s also worth noting that unless a certain flag is used (and possibly even then I think there may be issues) MAVProxy will see some commands that you are forwarding which trigger internal states in it (ie uploading/modifying missions through the port forwarding tends to result in MAVProxy attempting to upload/download the missions as well, and generates a large amount of ACK/NACK traffic as it gets out of sync).

1 Like

Hi, I have a question which is connected to this. What is the maximum SIM_SPEEDUP value? I want to record a long distance simulation mostly because I think it would be cool but I don’t want to record a video file which is over 9000 GB so I wanted the simulation to run kind of quickly, in like 15 minutes or less.

So far the maximum I’ve managed is 3E+38 but if I measure the time it takes to travel 100 meters or 1km it’s around the same real time as when it was waaay lower. Is there some sort of cap to how high you can put it? When starting the simulation it caps at 100, I’ve been changing this from the parameter list. Thanks.

Hello,

Is there any answer to this ?
I’m in the same case but can’t find any way to bypass this cap :frowning:

Thanks in advance,
F

I have setup multi-drone-simulation in Gazebo with SITL. I have PC with intel xeon , 32Gb ram. So hardware was not an issue.

So, what i did is, I changed some parameters in SITL as follow;

LOG_BITMASK - 156126.0 (old value- 176126.0)
LOG_FILE_BUFSIZE - 100 (old value- 200)
SCHED_LOOP_RATE - 200 (old value- 400)

this worked for me

I have used this instruction to setup drone simulation
github:GitHub - monemati/multiuav-gazebo-simulation: Tutorial for Multi-UAV (Quadcopters) simulation in Gazebo and Ardupilot.