fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-04-14 10:07:39 +08:00
Code Issues Packages Projects Releases Wiki Activity
PX4-Autopilot/docs/en/simulation/index.md
Ramon Roche 9adda29da2
docs(sim): add Try PX4 quick-start and pre-built packages reference (#26957) 
Adds documentation for the SITL containers and .deb packages introduced in #26495. The containers are now live on Docker Hub: [`px4io/px4-sitl:latest`](https://hub.docker.com/r/px4io/px4-sitl) and [`px4io/px4-sitl-gazebo:latest`](https://hub.docker.com/r/px4io/px4-sitl-gazebo).

The main addition is a [Try PX4 Simulation](https://docs.px4.io/main/en/dev_setup/try_px4) page that leads with a single `docker run` command and gets someone flying in under a minute. It lives in Getting Started, right after Recommended Hardware/Setup, so it's one of the first things new users see.

The existing `.deb` package reference has been moved from `packaging/px4_sitl_deb.md` to `simulation/px4_sitl.md` and expanded to cover both containers and `.deb` packages on one page. Sections are ordered by how people use them: what's available, install, configure, connect QGC/MAVSDK, connect ROS 2.

Other changes:
- README now has a "Try PX4" section with the docker one-liner above "Build from Source"
- Landing page (`index.md`) reworked to lead with "Try PX4" before "For Developers"
- Toolchain page (`dev_env.md`) gets a tip redirecting simulation-only users to pre-built packages
- `getting_started.md` and `SUMMARY.md` updated with links to the new pages
- Simulation index tip updated to mention containers alongside `.deb` packages

The SIH container image is published as `px4io/px4-sitl` (renamed from `px4io/px4-sitl-sih`) so the default lightweight option carries the simplest name. The Gazebo image remains `px4io/px4-sitl-gazebo`.

Also upgrades all GitHub Actions in the SITL workflow to Node.js 24 compatible versions (`actions/checkout@v6`, `actions/cache@v5`, `actions/upload-artifact@v7`, `actions/download-artifact@v8`, `docker/setup-buildx-action@v4`, `docker/build-push-action@v7`) to fix the Node.js 20 deprecation warning ahead of the June 2026 deadline.

---------

Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
2026-04-09 08:51:22 -07:00

390 lines
28 KiB
Markdown
Raw Blame History

# Simulation
Simulators allow PX4 flight code to control a computer modeled vehicle in a simulated "world".
You can interact with this vehicle just as you might with a real vehicle, using _QGroundControl_, an offboard API, or a radio controller/gamepad.
PX4 supports both _Software In the Loop (SITL)_ simulation, where the flight stack runs on computer (either the same computer or another computer on the same network) and _Hardware In the Loop (HITL)_ simulation using a simulation firmware on a real flight controller board.
Information about available simulators and how to set them up are provided in the next section.
The other sections provide general information about how the simulator works, and are not required to _use_ the simulators.
:::tip
Simulation is a quick, easy, and most importantly, _safe_ way to test changes to PX4 code before attempting to fly in the real world.
It is also a good way to start flying with PX4 when you haven't yet got a vehicle to experiment with.
:::
## Supported Simulators
The following simulators are supported by the PX4 core development team.
:::info
Gazebo Classic is being downgraded to [community supported](../simulation/community_supported_simulators.md) and is no longer recommended as the default simulation solution.
Use [Gazebo](../sim_gazebo_gz/index.md) (formerly Gazebo Ignition) for new projects.
If you have an older workflow that does not yet work in newer Gazebo, Gazebo Classic remains available but will not receive core team maintenance going forward.
See [PX4-Autopilot#23602](https://github.com/PX4/PX4-Autopilot/issues/23602) for the deprecation timeline and migration status.
:::
| Simulator | Description |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Gazebo](../sim_gazebo_gz/index.md) | Gazebo supersedes [Gazebo Classic](../sim_gazebo_classic/index.md), featuring more advanced rendering, physics and sensor models. It is the only version of Gazebo available from Ubuntu Linux 22.04<br><br>A powerful 3D simulation environment that is particularly suitable for testing object-avoidance and computer vision. It can also be used for [multi-vehicle simulation](../simulation/multi-vehicle-simulation.md) and is commonly used with [ROS](../simulation/ros_interface.md), a collection of tools for automating vehicle control. <br><br><strong>Supported Vehicles:</strong> Quad, VTOL (Standard, Tailsitter, Tiltroter), Plane, Rovers |
| [SIH](../sim_sih/index.md) | A lightweight, headless simulator that runs physics directly inside PX4 as a C++ module (no external dependencies). Headless by default for fastest iteration. Supports ROS 2 via uXRCE-DDS. Can also run on flight controller hardware (`SYS_HITL=2`).<br><br>**Supported Vehicles:** Quad, Hex, Plane, Tailsitter, Standard VTOL, Rover |
| [Gazebo Classic](../sim_gazebo_classic/index.md) | A powerful 3D simulation environment that is particularly suitable for testing object-avoidance and computer vision. It can also be used for [multi-vehicle simulation](../simulation/multi-vehicle-simulation.md) and is commonly used with [ROS](../simulation/ros_interface.md), a collection of tools for automating vehicle control.<br><br>**Supported Vehicles:** Quad ([Iris](../airframes/airframe_reference.md#copter_quadrotor_x_generic_quadcopter)), Hex (Typhoon H480), [Generic Standard VTOL (QuadPlane)](../airframes/airframe_reference.md#vtol_standard_vtol_generic_standard_vtol), Tailsitter, Plane, Rover, Submarine |
There are also a number of [Community Supported Simulators](../simulation/community_supported_simulators.md).
:::tip
To run PX4 SITL without setting up a build environment, [pre-built packages and containers](px4_sitl_prebuilt_packages.md) are available.
:::
### Simulator Comparison
| Feature | Gazebo | SIH |
| ------------------------- | ----------------------------------------- | ------------------------------------------------------------------- |
| **Default Mode** | GUI with 3D rendering | Headless (fastest iteration) |
| **3D Visualization** | Built-in (photorealistic) | Optional: QGC map or jMAVSim display-only |
| **Physics Engine** | External (gz-physics) | Internal (C++ module, uORB) |
| **External Dependencies** | Gazebo packages, rendering libs | None |
| **Vehicle Types** | Quad, VTOL, Plane, Rovers | Quad, Hex, Plane, Tailsitter, Std VTOL, Rover |
| **Multi-vehicle** | Yes (documented) | Yes ([multi-vehicle](../sim_sih/index.md#multi-vehicle-simulation)) |
| **Sensor Simulation** | Camera, LiDAR, depth, IMU, GPS, baro, mag | IMU, GPS, baro, mag, airspeed |
| **Custom Worlds/Models** | Yes (SDF, large model library) | No |
| **ROS 2 Integration** | Yes (uXRCE-DDS) | Yes (uXRCE-DDS) |
| **Extensibility** | Plugins, custom sensors, environments | Modify C++ source, tune SIH\_\* parameters |
| **Community/Ecosystem** | Large Gazebo community, model repos | PX4-internal |
| **Faster-than-Realtime** | Yes | Yes |
| **Runs on FC Hardware** | No | Yes (SYS_HITL=2) |
| **macOS Apple Silicon** | Unstable (known issues) | Works natively |
| **Lockstep** | Yes | Yes |
:::tip
For a detailed analysis of PX4 simulation user needs, priorities, and pain points, see the [PX4 Simulation Integration Survey Report](https://www.mcguirerobotics.com/px4_sim_research_report/) (K. McGuire, Dronecode Foundation, Dec 2025, 120 respondents).
:::
### Which Simulator Should I Use?
- **Full-featured simulation with 3D rendering, custom worlds, camera/lidar sensors, or rich sensor ecosystems:** Use [Gazebo](../sim_gazebo_gz/index.md). Largest ecosystem, custom models and plugins, photorealistic rendering, extensive sensor library, large community.
- **Fast headless iteration, controls research, zero-dependency setup, or macOS:** Use [SIH](../sim_sih/index.md). Runs entirely inside PX4 with no external dependencies, headless by default for maximum speed, physics parameters directly tunable via `SIH_*` params. Supports ROS 2 via uXRCE-DDS.
- **Hardware integration testing without propellers:** Use [SIH on flight controller hardware](../sim_sih/index.md#sih-on-flight-controller-hardware) (`SYS_HITL=2`).
:::info
SIH is headless by default. For optional 3D visualization, you can use [jMAVSim in display-only mode](../sim_sih/index.md#visualization-optional) or monitor the vehicle in QGroundControl's map view.
:::
## Simulator MAVLink API
Most external simulators communicate with PX4 using the Simulator MAVLink API.
This API defines a set of MAVLink messages that supply sensor data from the simulated world to PX4 and return motor and actuator values from the flight code that will be applied to the simulated vehicle.
The image below shows the message flow.
:::info
SIH does not use the MAVLink simulator API. It runs physics internally via uORB messages. Gazebo communicates with PX4 via gz_bridge (Gazebo transport), not MAVLink.
:::
![Simulator MAVLink API](../../assets/simulation/px4_simulator_messages.svg)
::: info
A SITL build of PX4 uses [SimulatorMavlink.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/simulation/simulator_mavlink/SimulatorMavlink.cpp) to handle these messages while a hardware build in HIL mode uses [mavlink_receiver.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp).
Sensor data from the simulator is written to PX4 uORB topics.
All motors / actuators are blocked, but internal software is fully operational.
:::
The messages are described below (see links for specific detail).
| Message | Direction | Description |
| --------------------------------------------------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [MAV_MODE:MAV_MODE_FLAG_HIL_ENABLED][mav_mode_flag_hil_enabled] | NA | Mode flag when using simulation. All motors/actuators are blocked, but internal software is fully operational. |
| [HIL_ACTUATOR_CONTROLS][hil_actuator_controls] | PX4 to Sim | PX4 control outputs (to motors, actuators). |
| [HIL_SENSOR][hil_sensor] | Sim to PX4 | Simulated IMU readings in SI units in NED body frame. |
| [HIL_GPS][hil_gps] | Sim to PX4 | The simulated GPS RAW sensor value. |
| [HIL_OPTICAL_FLOW][hil_optical_flow] | Sim to PX4 | Simulated optical flow from a flow sensor (e.g. PX4FLOW or optical mouse sensor) |
| [HIL_STATE_QUATERNION][hil_state_quaternion] | Sim to PX4 | Contains the actual "simulated" vehicle position, attitude, speed etc. This can be logged and compared to PX4's estimates for analysis and debugging (for example, checking how well an estimator works for noisy (simulated) sensor inputs). |
| [HIL_RC_INPUTS_RAW][hil_rc_inputs_raw] | Sim to PX4 | The RAW values of the RC channels received. |
<!-- links for table above -->
[mav_mode_flag_hil_enabled]: https://mavlink.io/en/messages/common.html#MAV_MODE_FLAG_HIL_ENABLED
[hil_actuator_controls]: https://mavlink.io/en/messages/common.html#HIL_ACTUATOR_CONTROLS
[hil_sensor]: https://mavlink.io/en/messages/common.html#HIL_SENSOR
[hil_gps]: https://mavlink.io/en/messages/common.html#HIL_GPS
[hil_optical_flow]: https://mavlink.io/en/messages/common.html#HIL_OPTICAL_FLOW
[hil_state_quaternion]: https://mavlink.io/en/messages/common.html#HIL_STATE_QUATERNION
[hil_rc_inputs_raw]: https://mavlink.io/en/messages/common.html#HIL_RC_INPUTS_RAW
<!-- above ^^^ links for table -->
PX4 directly uses the [Gazebo API](https://gazebosim.org/docs/) to interface with [Gazebo](../sim_gazebo_gz/index.md) and MAVlink is not required.
## Default PX4 MAVLink UDP Ports
By default, PX4 uses commonly established UDP ports for MAVLink communication with ground control stations (e.g. _QGroundControl_), Offboard APIs (e.g. MAVSDK, MAVROS) and simulator APIs (e.g. Gazebo).
These ports are:
- PX4's remote UDP Port **14550** is used for communication with ground control stations.
GCS are expected to listen for connections on this port.
_QGroundControl_ listens to this port by default.
- PX4's remote UDP Port **14540** is used for communication with offboard APIs.
Offboard APIs are expected to listen for connections on this port.
::: info
Multi-vehicle simulations use a separate remote port for each instance, allocated sequentially from `14540` to `14549`
(additional instances all use port `14549`).
:::
- The simulator's local TCP Port, **4560**, is used for communication with PX4.
The simulator listens to this port, and PX4 initiates a TCP connection to it.
::: info
The ports for the GCS, offboard APIs and simulator are specified by startup scripts.
See [System Startup](../concept/system_startup.md) to learn more.
:::
<!-- A useful discussion about UDP ports here: https://github.com/PX4/PX4-user_guide/issues/1035#issuecomment-777243106 -->
## SITL Simulation Environment
The diagram below shows a typical SITL simulation environment for any of the supported simulators that use MAVLink (i.e. most external simulators, but not Gazebo or SIH).
![PX4 SITL overview](../../assets/simulation/px4_sitl_overview.svg)
The different parts of the system connect via UDP, and can be run on either the same computer or another computer on the same network.
- PX4 uses a simulation-specific module to connect to the simulator's local TCP port 4560.
Simulators then exchange information with PX4 using the [Simulator MAVLink API](#simulator-mavlink-api) described above.
PX4 on SITL and the simulator can run on either the same computer or different computers on the same network.
::: info
Simulators can also use the _uxrce-dds bridge_ ([XRCE-DDS](../middleware/uxrce_dds.md)) to directly interact with PX4 (i.e. via [UORB topics](../middleware/uorb.md) rather than MAVLink).
This approach _may_ used by Gazebo Classic for [multi-vehicle simulation](../sim_gazebo_classic/multi_vehicle_simulation.md#build-and-test-xrce-dds).
:::
- PX4 uses the normal MAVLink module to connect to ground stations and external developer APIs like MAVSDK or ROS
- Ground stations listen to PX4's remote UDP port: `14550`
- External developer APIs listen to PX4's remote UDP port: `14540`.
For multi-vehicle simulations, PX4 sequentially allocates a separate remote port for each instance from `14540` to `14549` (additional instances all use port `14549`).
- PX4 defines a number of _local_ UDP ports (`14580`,`18570`), which are sometimes used when networking with PX4 running in a container or virtual machine.
These are not recommended for "general" use and may change in future.
- A serial connection may be used to connect [Joystick/Gamepad](../config/joystick.md) hardware via _QGroundControl_.
If you use the normal build system SITL `make` configuration targets (see next section) then both SITL and the Simulator will be launched on the same computer and the ports above will automatically be configured.
You can configure additional MAVLink UDP connections and otherwise modify the simulation environment in the build configuration and initialisation files.
### Starting/Building SITL Simulation
The build system makes it very easy to build and start PX4 on SITL, launch a simulator, and connect them.
The syntax (simplified) looks like this:
```sh
make px4_sitl simulator[_vehicle-model]
```
where `simulator` is `gz` (for Gazebo), `gazebo-classic`, `jmavsim` or some other simulator, and vehicle-model is a particular vehicle type supported by that simulator ([Gazebo](../sim_gazebo_gz/index.md) and [jMAVSim](../sim_jmavsim/index.md) only support multicopters at time of writing, while [Gazebo Classic](../sim_gazebo_classic/index.md) supports many different types).
A number of examples are shown below, and there are many more in the individual pages for each of the simulators:
```sh
# Start Gazebo with the x500 multicopter
make px4_sitl gz_x500
# Start Gazebo Classic with plane
make px4_sitl gazebo-classic_plane
# Start Gazebo Classic with iris and optical flow
make px4_sitl gazebo-classic_iris_opt_flow
# Start JMavSim with iris (default vehicle model)
make px4_sitl jmavsim
# Start PX4 with no simulator (i.e. to use your own "custom" simulator)
make px4_sitl none_iris
# SIH (headless, zero dependencies)
make px4_sitl_sih sihsim_quadx
make px4_sitl_sih sihsim_airplane
```
::: info
Use `px4_sitl_sih` instead of `px4_sitl` to avoid building Gazebo dependencies.
:::
The simulation can be further configured via environment variables:
- Any of the [PX4 parameters](../advanced_config/parameter_reference.md) can be overridden via `export PX4_PARAM_{name}={value}`.
For example changing the estimator: `export PX4_PARAM_EKF2_EN=0; export PX4_PARAM_ATT_EN=1`.
The syntax described here is simplified, and there are many other options that you can configure via _make_ - for example, to set that you wish to connect to an IDE or debugger.
For more information see: [Building the Code > PX4 Make Build Targets](../dev_setup/building_px4.md#px4-make-build-targets).
### Run Simulation Faster than Realtime {#simulation_speed}
SITL can be run faster or slower than real-time when using Gazebo, Gazebo Classic, jMAVSim, or SIH.
The speed factor is set using the environment variable `PX4_SIM_SPEED_FACTOR`.
::: info
PX4 SITL and the simulators are run in _lockstep_, which means that they are locked to run at the same speed, and therefore can react appropriately to sensor and actuator messages.
This is what makes it possible to run the simulation at different speeds, and also pause the simulation in order to step through code.
:::
For more information see:
- Gazebo: [Change Simulation Speed](../sim_gazebo_gz/index.md#change-simulation-speed)
- Gazebo Classic: [Change Simulation Speed](../sim_gazebo_classic/index.md#change-simulation-speed) and [Lockstep](../sim_gazebo_classic/index.md#lockstep)
- jMAVSim: [Change Simulation Speed](../sim_jmavsim/index.md#change-simulation-speed) and [Lockstep](../sim_jmavsim/index.md#lockstep)
- SIH: Supports `PX4_SIM_SPEED_FACTOR` for faster-than-realtime simulation.
### Startup Scripts
Scripts are used to control which parameter settings to use or which modules to start.
They are located in the [ROMFS/px4fmu_common/init.d-posix](https://github.com/PX4/PX4-Autopilot/tree/main/ROMFS/px4fmu_common/init.d-posix) directory, the `rcS` file is the main entry point.
See [System Startup](../concept/system_startup.md) for more information.
### Simulating Failsafes and Sensor/Hardware Failure
[Simulate Failsafes](../simulation/failsafes.md) explains how to trigger safety failsafes like GPS failure and battery drain.
## HITL Simulation Environment
With Hardware-in-the-Loop (HITL) simulation the normal PX4 firmware is run on real hardware.
The HITL Simulation Environment in documented in: [HITL Simulation](../simulation/hitl.md).
## Joystick/Gamepad Integration
_QGroundControl_ desktop versions can connect to a USB Joystick/Gamepad and send its movement commands and button presses to PX4 over MAVLink.
This works on both SITL and HITL simulations, and allows you to directly control the simulated vehicle.
If you don't have a joystick you can alternatively control the vehicle using QGroundControl's onscreen virtual thumbsticks.
For setup information see the _QGroundControl User Guide_:
- [Joystick Setup](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/setup_view/joystick.html)
- [Virtual Joystick](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/settings_view/virtual_joystick.html)
<!-- FYI Airsim info on this setting up remote controls: https://github.com/Microsoft/AirSim/blob/master/docs/remote_controls.md -->
## Camera Simulation
PX4 supports capture of both still images and video from within the [Gazebo Classic](../sim_gazebo_classic/index.md) simulated environment.
This can be enabled/set up as described in [Gazebo Glassic > Video Streaming](../sim_gazebo_classic/index.md#video-streaming).
The simulated camera is a gazebo classic plugin that implements the [MAVLink Camera Protocol](https://mavlink.io/en/services/camera.html) <!-- **PX4-Autopilot/Tools/simulation/gazebo-classic/sitl_gazebo-classic/src/gazebo_geotagged_images_plugin.cpp -->.
PX4 connects/integrates with this camera in _exactly the same way_ as it would with any other MAVLink camera:
1. [TRIG_INTERFACE](../advanced_config/parameter_reference.md#TRIG_INTERFACE) must be set to `3` to configure the camera trigger driver for use with a MAVLink camera
:::tip
In this mode the driver just sends a [CAMERA_TRIGGER](https://mavlink.io/en/messages/common.html#CAMERA_TRIGGER) message whenever an image capture is requested.
For more information see [Cameras Connected to Flight Controller Outputs](../camera/fc_connected_camera.md).
:::
1. PX4 must forward all camera commands between the GCS and the (simulator) MAVLink Camera.
You can do this by starting [MAVLink](../modules/modules_communication.md#mavlink) with the `-f` flag as shown, specifying the UDP ports for the new connection.
```sh
mavlink start -u 14558 -o 14530 -r 4000 -f -m camera
```
::: info
More than just the camera MAVLink messages will be forwarded, but the camera will ignore those that it doesn't consider relevant.
:::
The same approach can be used by other simulators to implement camera support.
## Running Simulation on a Remote Server
It is possible to run the simulator on one computer, and access it from another computer on the same network (or on another network with appropriate routing).
This might be useful, for example, if you want to test a drone application running on real companion computer hardware running against a simulated vehicle.
This does not work "out of the box" because PX4 does not route packets to external interfaces by default (in order to avoid spamming the network and different simulations interfering with each other).
Instead it routes traffic internally - to "localhost".
There are a number of ways to make the UDP packets available on external interfaces, as outlined below.
### Use MAVLink Router
The [mavlink-router](https://github.com/mavlink-router/mavlink-router) can be used to route packets from localhost to an external interface.
To route packets between SITL running on one computer (sending MAVLink traffic to localhost on UDP port 14550), and QGC running on another computer (e.g. at address `10.73.41.30`) you could:
- Start _mavlink-router_ with the following command:
```sh
mavlink-routerd -e 10.73.41.30:14550 127.0.0.1:14550
```
- Use a _mavlink-router_ conf file.
```ini
[UdpEndpoint QGC]
Mode = Normal
Address = 10.73.41.30
Port = 14550
[UdpEndpoint SIM]
Mode = Eavesdropping
Address = 127.0.0.1
Port = 14550
```
::: info
More information about _mavlink-router_ configuration can be found [here](https://github.com/mavlink-router/mavlink-router#running).
:::
### Enable UDP Broadcasting
The [mavlink module](../modules/modules_communication.md#mavlink_usage) routes to _localhost_ by default, but you can enable UDP broadcasting of heartbeats using its `-p` option.
Any remote computer on the network can then connect to the simulator by listening to the appropriate port (i.e. 14550 for _QGroundControl_).
::: info
UDP broadcasting provides a simple way to set up the connection when there is only one simulation running on the network.
Do not use this approach if there are multiple simulations running on the network (you might instead [publish to a specific address](#enable-streaming-to-specific-address)).
:::
This should be done in an appropriate configuration file where `mavlink start` is called.
For example: [/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink).
### Enable Streaming to Specific Address
The [mavlink module](../modules/modules_communication.md#mavlink_usage) routes to _localhost_ by default, but you can specify an external IP address to stream to using its `-t` option.
The specified remote computer can then connect to the simulator by listening to the appropriate port (i.e. 14550 for _QGroundControl_).
This should be done in various configuration files where `mavlink start` is called.
For example: [/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink).
### SSH Tunneling
SSH tunneling is a flexible option because the simulation computer and the system using it need not be on the same network.
::: info
You might similarly use VPN to provide a tunnel to an external interface (on the same network or another network).
:::
One way to create the tunnel is to use SSH tunneling options.
The tunnel itself can be created by running the following command on _localhost_, where `remote.local` is the name of a remote computer:
```sh
ssh -C -fR 14551:localhost:14551 remote.local
```
The UDP packets need to be translated to TCP packets so they can be routed over SSH.
The [netcat](https://en.wikipedia.org/wiki/Netcat) utility can be used on both sides of the tunnel - first to convert packets from UDP to TCP, and then back to UDP at the other end.
:::tip
QGC must be running before executing _netcat_.
:::
On the _QGroundControl_ computer, UDP packet translation may be implemented by running following commands:
```sh
mkfifo /tmp/tcp2udp
netcat -lvp 14551 < /tmp/tcp2udp | netcat -u localhost 14550 > /tmp/tcp2udp
```
On the simulator side of the SSH tunnel, the command is:
```sh
mkfifo /tmp/udp2tcp
netcat -lvup 14550 < /tmp/udp2tcp | netcat localhost 14551 > /tmp/udp2tcp
```
The port number `14550` is valid for connecting to QGroundControl or another GCS, but should be adjusted for other endpoints (e.g. developer APIs etc.).
The tunnel may in theory run indefinitely, but _netcat_ connections may need to be restarted if there is a problem.
The [QGC_remote_connect.bash](https://raw.githubusercontent.com/ThunderFly-aerospace/sitl_gazebo/autogyro-sitl/scripts/QGC_remote_connect.bash) script can be run on the QGC computer to automatically setup/run the above instructions.
The simulation must already be running on the remote server, and you must be able to SSH into that server.
Reference in New Issue View Git Blame Copy Permalink