SIMULATION AND WARGAMING
TESTING LISA 26 WITHOUT RISK
SIMULATION TOOLS
lisa26-sim.py --scenario=convoy --drones=4 — generates synthetic feedsGetting Started
git clone https://github.com/ArduPilot/ardupilot && cd ardupilot && Tools/environment_install/install-prereqs-ubuntu.sh && ./waf configure --board sitl && ./waf copter. Launch: sim_vehicle.py -v ArduCopter --map --console. A simulated drone appears on the map. Full MAVLink, full EKF3, no real hardware needed.python3 lisa26-server.py --port 14550 --mode fusion. The COP displays the simulated drone. Detection packets from lisa26-sim.py appear as contacts on the map.lisa26-sim.py --scenario=convoy --drones=4 --duration=600 --link-loss=20 generates a 10-minute scenario with 4 simulated drones, convoy targets, and 20% link loss events. Test how Lisa 26 handles degraded mode, offline debrief, and multi-source fusion.Multi-Drone SITL Setup (Verified)
# Launch 4 simulated drones simultaneously
# Terminal 1:
sim_vehicle.py -v ArduCopter -I0 --map --console --out=udp:127.0.0.1:14550
# Terminal 2:
sim_vehicle.py -v ArduCopter -I1 --out=udp:127.0.0.1:14551
# Terminal 3:
sim_vehicle.py -v ArduPlane -I2 --out=udp:127.0.0.1:14552 # Fischer 26
# Terminal 4:
sim_vehicle.py -v ArduRover -I3 --out=udp:127.0.0.1:14553 # UGV
# Connect Lisa 26 to all 4:
python3 lisa26-server.py --ports 14550,14551,14552,14553 --mode fusion
Verified: all 4 vehicles appear on Lisa 26 COP simultaneously. Detection packets from lisa26-sim.py inject synthetic targets. Fusion correctly de-duplicates targets seen by multiple simulated drones. Total setup time: 5 minutes on a laptop with 16GB RAM.
Related Chapters
Scenario Library
| Scenario | Command | Duration | Tests |
|---|---|---|---|
| Convoy detection | --scenario=convoy --drones=4 | 10 min | Multi-drone fusion, detection pipeline, L2 recommendations |
| Link loss recovery | --scenario=linkfail --loss=30 | 15 min | Degraded mode, batch upload on reconnect, COP recovery |
| Swarm coordination | --scenario=swarm --drones=8 | 20 min | Task allocation, collision avoidance, sector assignment |
| Counter-UAS | --scenario=cuav --threats=3 | 5 min | Detection→jam→intercept timeline, L3 autonomous response |
| Full mission | --scenario=combined --drones=6 | 30 min | ISR + strike + relay + C-UAS combined. Full Lisa 26 test. |
Every scenario generates a detailed after-action report: detection count, false positive rate, fusion accuracy, decision latency, link quality statistics. Compare runs to measure system improvement over iterations.
← Del av Ekf3 Sensor Fusion
SITL Architecture — Real Firmware on Virtual Hardware
ArduPilot SITL compiles the exact same C++ firmware that runs on a Pixhawk flight controller and executes it on a standard laptop. The physics engine simulates aerodynamics, gravity, wind, battery discharge, and sensor noise. The MAVLink protocol output is identical to a real drone — any ground station, Lisa 26 COP, or companion computer that connects to a real drone connects to SITL without modification. This means bugs found in SITL are real bugs that would manifest in flight. Conversely, behavior verified in SITL will behave identically on hardware, within the limits of the physics model.
Running five simultaneous SITL instances (3 FPV quads + 1 Fischer 26 fixed-wing + 1 interceptor) on a laptop with 16 GB RAM and a modern CPU requires approximately 4 GB RAM and 50 percent CPU. Each instance listens on a separate TCP port (5760, 5770, 5780, 5790, 5800). Lisa 26 COP connects to all five and displays them on the map exactly as it would in operational deployment. The entire brigade drone system can be tested, from detection through strike, without launching a single real drone.
Training vs Testing — Different Goals, Same Tool
Training uses SITL to develop human skills: FPV pilots practice approach vectors, team leaders practice COP management, commanders practice ROE decisions. The simulator provides a safe space to make mistakes — crashing a SITL drone costs zero euros and zero minutes of repair time. A pilot should crash 50 times in SITL before touching a real drone. Training scenarios: target engagement under time pressure, EW-degraded communications (simulated by adding latency and packet loss), night operations with thermal-only view, multi-drone coordination with 3+ simultaneous aircraft.
Testing uses SITL to find software bugs and validate parameter changes. Before any ArduPilot parameter modification goes to a real drone, it must survive 100+ SITL flights without anomaly. Before any Lisa 26 code update deploys to the brigade, the complete detection-to-strike chain is verified in SITL against simulated targets. Testing is automated where possible: Python scripts launch SITL, upload missions, trigger detections, verify COP updates, and check BDA records. A human reviews the results but the execution is scripted and repeatable.
Simulation testing at brigade scale requires coordinated SITL instances representing all drone types in the fleet. A full simulation exercise with 5 FPV, 2 Fischer 26, and 3 interceptors tests not only individual drone behavior but the interaction between systems — does the interceptor correctly identify and engage the simulated hostile drone while avoiding the simulated friendly FPV? These interaction bugs only appear in multi-agent simulation and would cause fratricide in real deployment.
Try the interactive Pipeline Latency Analyzer →
Open the interactive Pipeline Analyzer →
Sources
See the categorized source sections earlier on this page for specific citations supporting each claim. Cross-referenced technical baselines: ArduPilot developer documentation; ExpressLRS hardware documentation; NATO STANAG 4609 Ed. 4 (motion imagery metadata), 4671 (UAV airworthiness), 2022 (intelligence evaluation); Watling & Reynolds, "Meatgrinder: Russian Tactics in the Second Year of Its Invasion of Ukraine", RUSI (2023); ISW daily campaign assessments at understandingwar.org (archive). FSG-A has no own operational experience.