Latest › Build a Drone with a Bot: Software and Hardware Series

Simulate First: Set Up ArduPilot and PX4 SITL with a Bot as Your Guide

WalkthroughBy Bot Tutorials · Published Nov 2, 2026 · Facts last verified Nov 1, 2026

Next in this series: Tomorrow: Parts Before Purchase: Using a Bot to Check Drone Component Compatibility · The day after: Your First Bot-Written MAVLink Script: Reading Telemetry with pymavlink · Series hub

Part 1 of our drone series: use Grok Bot, ChatGPT or Claude to set up ArduPilot SITL or PX4 SITL, read the errors, and connect a ground station before any real flight.

Welcome to our daily series on building a drone with a bot as your assistant. Over the next ten days we'll alternate between software (flight scripts, simulators, telemetry, code review) and hardware (parts, power, wiring, matching components). It starts with the most important habit in the whole hobby: simulate first.

Bots are good at writing code fast. Flight code that's fast to write and wrong can crash a drone, so before a bot writes a single line for you, you need somewhere safe to run it. That place is SITL.

What SITL is, in plain words

SITL stands for Software In The Loop. ArduPilot's developer docs describe it as a way to run the autopilot's flight code on an ordinary computer, with a physics model standing in for the aircraft. The autopilot really runs: it arms, reads simulated sensors, follows missions and triggers failsafes. Only the aircraft is pretend.

There are two main open-source autopilots, and both have a simulator:

ArduPilot SITL. You start it with the sim_vehicle.py script from the ArduPilot source tree. It usually launches MAVProxy, a command-line ground station, alongside it.
PX4 SITL. PX4's docs cover simulation with Gazebo and other simulators, started from PX4's build system. The Gazebo page lists the supported vehicle models.

Which one should you pick? If you're not sure, ask the bot to compare them for your goal, then check its answer against both projects' docs. Very roughly, ArduPilot is common on camera multirotors, planes and rovers, and PX4 is common in research and in many commercial platforms. Both speak MAVLink, so most of what you learn carries over.

Step 1: ask for a plan, not a script

The worst prompt is "install ArduPilot SITL for me." The bot can't run commands on your computer, and it will guess at your setup. A better prompt gives it context and asks for a checklist:

I'm on Ubuntu 24.04 (or Windows 11 with WSL2, or macOS). I want to run ArduPilot SITL for a quadcopter and connect Mission Planner or QGroundControl. Give me a numbered checklist, link the official ArduPilot page for each step, and tell me what output means success at each step. Don't invent commands. If you aren't sure of one, say so.

That last sentence matters. It invites the bot to flag uncertainty instead of making something up. Then open the official SITL Simulator page and the Using SITL for ArduPilot Testing page, and compare the two lists line by line. If the bot's list is missing a step, or names a package the docs don't mention, follow the docs.

Step 2: start the simulator and read what it says

The ArduPilot docs show starting a copter simulation from the ArduCopter directory with a command along the lines of sim_vehicle.py -v ArduCopter --console --map. That opens a console window, a map, and a MAVProxy prompt. The first run compiles the code, so expect it to take a while.

When something fails, and on a first install something usually does, here's how to get useful help from a bot:

Copy the whole error, starting from the first red line, not just the last line.
Say what you ran, your OS, and what you expected.
Ask: "What are the two most likely causes, and what command shows which one it is?"

Asking for a diagnostic step instead of a fix keeps you in control. A bot that jumps to "just run sudo pip install on everything" is guessing. Push back, and ask which official page backs up its answer.

Step 3: connect a ground station

ArduPilot's testing page explains that MAVProxy forwards MAVLink to UDP port 14550 on your machine. You can see this with MAVProxy's output command, which lists the outputs. Mission Planner and QGroundControl both listen on 14550 by default, so if they run on the same computer they often connect on their own. On another computer, you add an output for that machine's IP address, as the docs describe.

Once connected, you should see the simulated drone on the map, a heartbeat, and a battery reading. That connection string, udpin:127.0.0.1:14550, is what our Python scripts will use later in this series.

Step 4: your first simulated flight

From the MAVProxy prompt, ArduPilot's docs walk through switching to GUIDED mode, arming, and taking off to a few meters. Do it a few times by hand before you script anything. Watch what the console prints when you:

try to arm before the simulated GPS has a fix (you'll see a pre-arm message, and that's a feature),
switch modes,
let the simulated battery run down, if you set it up to.

Each of those messages is something your own code will need to handle later. Paste them into the bot and ask, "What is this message telling me, and what would my script need to check before arming?" That builds your understanding, and it builds the checklist for the code review piece later in the series.

PX4 path in brief

If you went with PX4, the PX4 user guide's simulation section explains building PX4 SITL with Gazebo. The ground station flow is similar, and PX4's offboard and MAVSDK examples connect to the simulator on PX4's own documented ports, which we'll use when we write MAVSDK code. Use the same prompt pattern: ask the bot for a checklist linked to docs.px4.io, compare it with the guide, and paste full errors.

What the bot is good at here (and what it isn't)

Good at:

Explaining what each component does (SITL, MAVProxy, the GCS, MAVLink).
Reading long build errors and pointing out the likely cause.
Turning official docs into a checklist that fits your OS.
Explaining the meaning of console and pre-arm messages.

Not good at:

Knowing your machine's state. It can't see your Python version or path.
Keeping up with changes. Install steps change between releases, so trust the docs' current version.
Being honest about uncertainty unless you ask it to be.

A habit to start today

Make a plain text "flight notebook". Each time you run the simulator, write the date, the commands, what broke, and how you fixed it. Paste the notebook into the bot at the start of future sessions so it has context. When you reach real hardware later in this series, that notebook becomes your build log.

Next up in the series is hardware. The countdown strip on this page always shows the exact next title.

Safety and legal: read this before anything leaves the ground

This series is about hobby, camera and learning drones only. A bot is a helper, not an authority, and everything it says about flight has to be checked.

Simulate before you fly. Run every script and every parameter change in a simulator (ArduPilot SITL, or PX4 SITL with Gazebo) before it goes near a real aircraft. Bot-written code that has never run in simulation does not go on a vehicle.
Check bot advice against official sources. Compare every answer with the ArduPilot, PX4, MAVLink or Betaflight documentation and with the manufacturer's spec sheet for each part. If the bot and the docs disagree, the docs win.
Props off on the bench. Take the propellers off whenever the battery is connected for setup, motor tests or firmware work.
Keep failsafes and geofences on. Don't let a bot talk you into disabling radio, battery or GCS failsafes, or into getting around a geofence or airspace restriction.
Follow the FAA rules in the US. The FAA requires registration for drones of 250 grams (0.55 lb) or more, and for any drone flown under Part 107. Recreational flyers must pass the free TRUST test and carry proof of it. Registered drones need Remote ID, either built in, through a broadcast module, or by flying at an FAA-Recognized Identification Area. Commercial flights need a Part 107 certificate. Stay away from airports and controlled airspace unless you have authorization, keep the drone in sight, and don't fly over people.
Treat LiPo batteries with respect. Charge on a fireproof surface with a balance charger, never leave a charging pack unattended, and retire swollen or damaged packs following the manufacturer's instructions.
Never fly untested code near people. Test first flights in an open, legal area with nobody nearby.

Outside the US, check your national aviation authority's rules. They may be different.

FAQ

Do I need a real drone to start?

No. ArduPilot SITL and PX4 SITL run the real flight-control code on your computer, so you can learn and test scripts with no hardware at all.

Which port do I connect a ground station to?

ArduPilot's SITL docs show MAVProxy forwarding MAVLink to UDP 14550 on the same machine, which Mission Planner and QGroundControl listen on by default.

Can the bot install SITL for me?

A chat bot can explain each step and read your error messages, but you run the commands. Check every command against the official ArduPilot or PX4 setup page for your OS.

Sources

Video outline (coming)

Why simulation comes first
ArduPilot SITL vs PX4 SITL
Asking the bot for an install plan for your OS
Starting sim_vehicle.py and reading the console
Connecting a ground station on UDP 14550
Pasting errors back to the bot the right way
Your first simulated takeoff in GUIDED mode
Recap and what's next

The narrated video for this piece is in production; this outline is what it will cover.