What is SITL, and why should a pilot care?

The short version

SITL stands for Software In The Loop. The flight-controller firmware — actual Betaflight, actual iNAV, actual ArduPilot, compiled from the same source that runs on your aircraft — is built to run as a program on your PC instead of on an STM32.

It still thinks it is a flight controller. It still runs its PID loop, its filters, its arming checks, its failsafe, its GPS Rescue logic. The only difference is where its senses come from: instead of a real gyro on a real frame, a simulator sends it gyro, accelerometer, barometer and GPS data, and receives back the four motor commands. The simulator then works out what an aircraft would do with those motor commands, and sends back the resulting sensor readings. A thousand times a second.

That closed loop — firmware → motor commands → physics → sensors → firmware — is the "loop" in the name. The software is in it.

What it is not

It is not a flight simulator. Liftoff, Velocidrone and DRL are excellent at teaching your thumbs, and they contain a flight model with something like a flight controller inside it, written by the game's developers. That is a game engine's approximation of Betaflight.

SITL is the opposite arrangement. There is no approximation of the firmware, because it is the firmware. If Betaflight has a bug, SITL has that bug. If your PID change makes the aircraft oscillate, it oscillates for exactly the reason it would in the field.

It is also not HIL. In Hardware In The Loop, the firmware runs on the real flight controller board, and the simulator feeds it fake sensor data over a wire. HIL tests the actual hardware — the real timings, the real DMA, the real board. SITL tests the actual logic, on a PC, with no hardware at all. SITL is easier to set up and faster to iterate; HIL is closer to the truth. Most people should start with SITL.

Why a pilot — not a developer — should care

The usual objection is fair: "I don't write firmware. Why would I run it on a PC?"

Because almost everything that goes wrong with a multirotor is a control-loop problem, and the control loop is exactly what SITL reproduces. Consider what you can do in a simulator that you cannot reasonably do in a field:

• Drive the aircraft into instability on purpose. Wind D up until it oscillates. Wind P up until it wobbles. You have now seen the failure modes, in the gyro trace, and you will recognise them instantly the next time they appear on a real log. Doing this deliberately on a 5 kg airframe is an expensive way to learn the same thing.
• Test a failsafe. Actually cutting the RC link on a live aircraft to see what happens is a legitimate test that most people never perform, because the downside is a fly-away. In SITL, you can perform it forty times before lunch.
• Fly the tune before you commit to it. Change one PID, fly the same manoeuvre, compare the logs. No battery cycles, no travel, no wind, no daylight limit.
• Learn a new firmware safely. Moving from Betaflight to iNAV or ArduPilot means learning an entirely different mode system, arming philosophy and failsafe behaviour. Making those mistakes with a real aircraft in the air is how expensive lessons happen.
• Rehearse a mission. Waypoints, RTL, geofence breaches, altitude limits — all of it executes identically in SITL, and none of it can hit a tree.

The people this pays off hardest for are the ones flying heavy. When a crash costs €50 you can afford to learn empirically. When it costs €3,000, or when the airframe is doing a job for somebody, you want to have already been wrong somewhere cheap.

What a SITL setup actually consists of

Three pieces, always:

1. A SITL build of the firmware. make TARGET=SITL in Betaflight, SITL target in iNAV, sim_vehicle.py in ArduPilot. It runs as an ordinary process on your machine.
2. A simulator to close the loop — something that owns a physics model and speaks the firmware's simulation protocol. It sends state, receives motor commands.
3. A transport between them. In practice, UDP and TCP sockets on localhost. Betaflight SITL, for instance, receives an 18-field flight-dynamics packet from the simulator on one UDP port and emits four motor PWM values on another, with RC channels arriving separately and MSP carried over TCP.

The awkward truth is that the reference SITL setups are built by firmware developers, for firmware developers. They usually mean a Linux box, a compiler toolchain, a Gazebo installation, and a physics model that is a generic quad rather than your quad. That is an entirely reasonable place for the ecosystem to be, and it is also why most pilots never touch it.

Where the fidelity actually matters

A SITL setup is only as good as the physics on the other side of the socket. If the simulator models a motor as "thrust is proportional to throttle," then your tune in the simulator is a tune for an aircraft that does not exist.

The things that determine whether a simulated tune transfers to the field:

• Loop rate. The FC runs its loop at up to 8 kHz. A physics step at 60 Hz cannot represent what that loop is reacting to. This is why 1000 Hz physics is the floor, not a bragging point.
• A real motor model. Motors have inertia, resistance, iron losses, and a torque curve; ESCs have deadband, timing and current limits; batteries sag under load. An aircraft that cannot sag its voltage cannot teach you anything about a heavy airframe at full throttle.
• Real mass properties. Inertia tensor, centre of gravity, arm length. This is most of why a 5 kg platform behaves nothing like a 250 g racer, and it is the first thing generic models get wrong.
• Aerodynamic drag. Which is exactly what your PID controller is fighting in forward flight.

Get those right and the loop the firmware experiences is close enough to the real one that the tune transfers. Get them wrong and you have a very convincing way to be confidently mistaken.