Your own simulator

A simulator that speaks MAVLink is a vehicle as soon as its messages reach UXDuck. Nothing needs installing beside it.

Where to send

Open Home › Connect a real vehicle › Your own simulator. It shows this computer's addresses and the UDP port UXDuck listens on (15010, or the next free one up to 15019). Send the simulator's MAVLink there.

ArduPilot SITL

sim_vehicle.py -v ArduCopter --out=udp:192.168.1.20:15010

Use the address shown under Your own simulator. On the same computer, 127.0.0.1 works.

PX4 SITL

PX4 sends to UDP port 14550 on its own computer. Route it on with mavlink-router:

mavlink-routerd -e 192.168.1.20:15010 127.0.0.1:14550

MAVProxy

mavproxy.py --master=tcp:127.0.0.1:5760 --out=udp:192.168.1.20:15010

Your fork's parameters and messages

A SITL built from your own ArduPilot fork reports the commit it was built from, as hardware does, so the fork's parameter descriptions and MAVLink messages apply to it by themselves. Add them once from the checkout that built it:

uxduck params definitions generate path/to/ardupilot --vehicle Copter
uxduck mavlink dialects generate path/to/ardupilot

The vehicle's setup shows the commit beside the firmware version. See Parameters for choosing them per vehicle.

Let UXDuck start your own build

UXDuck can also start and stop a simulator built from your own ArduPilot checkout, as it does its downloaded ones. Build it with UXDuck once for each commit:

uxduck sim build path/to/ardupilot

It builds the checked-out commit in a copy of its own (your files and build/ folder are left alone; changes not committed are left out), adds UXDuck's local-only network patch so the simulator can't be reached from other computers, and checks that it can't. Use --vehicle plane (or rover, submarine, airship) for another vehicle; macOS and Linux only. Then choose the path it prints under New simulation › Advanced › Your own build, or run uxduck sim start --binary <path>.

The patch has a version for current ArduPilot and for 4.5. For another release, uxduck sim build --allow-network builds it without one: while it runs, other computers on your network can connect to it, send it RC input and receive its state.

Use an existing executable

You can also use a compatible ArduPilot SITL executable you have already downloaded or compiled, without rebuilding it with UXDuck. In New simulation › Advanced › Your own build, enter its absolute path and choose the vehicle it runs. Frame for this build accepts its frame name, including frames from your fork. If the binary does not include a frame table, UXDuck uses that selected vehicle and frame. Keep any supplied vehicleinfo.json and defaults/ files beside the executable so its own defaults can be loaded.

A build without local-only support needs Allow network access for this build checked before it can start. Other computers on your network may connect to it, send RC input and receive its state. This choice resets when you change the executable or reopen the form; restarting the same simulation keeps it. Builds with local-only support still use it when this option is checked.

From the command line:

uxduck sim start --vehicle multicopter --binary /absolute/path/to/arducopter --frame X --allow-network

Omit --allow-network for a build with local-only support. The same explicit allowNetwork option is available to MCP clients for sim_start and snapshot_start; requests still use UXDuck's configuration permissions and approvals.

Connect to it instead

SITL started with --no-mavproxy listens on TCP port 5760. Choose Connect to it instead, pick TCP client and give the simulator's address and 5760.

Simulated, not real

UXDuck marks the vehicle simulated when it says so itself: ArduPilot SITL and PX4 SITL have SIM_ parameters. Its flights count as simulated in the Logbook. To change it, open the vehicle's page and use Simulated.