fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-10-03 12:38:54 +08:00
Code Issues Packages Projects Releases Wiki Activity

Move PX4 Guide source into /docs (#24490)

Browse Source 
* Add vitepress tree

* Update existing workflows so they dont trigger on changes in the docs path

* Add nojekyll, package.json, LICENCE etc

* Add crowdin docs upload/download scripts

* Add docs flaw checker workflows

* Used docs prefix for docs workflows

* Crowdin obvious fixes

* ci: docs move to self hosted runner

runs on a beefy server for faster builds

Signed-off-by: Ramon Roche <mrpollo@gmail.com>

* ci: don't run build action for docs or ci changes

Signed-off-by: Ramon Roche <mrpollo@gmail.com>

* ci: update runners

Signed-off-by: Ramon Roche <mrpollo@gmail.com>

* Add docs/en

* Add docs assets and scripts

* Fix up editlinks to point to PX4 sources

* Download just the translations that are supported

* Add translation sources for zh, uk, ko

* Update latest tranlsation and uorb graphs

* update vitepress to latest

---------

Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Ramon Roche <mrpollo@gmail.com>
This commit is contained in:
Hamish Willee
2025-03-13 16:08:27 +11:00
committed by GitHub
co-authored by Ramon Roche
parent 8e6d2ebe4a
commit 88d623bedb
5176 changed files with 558771 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en/tutorials/linux_sbus.md
+63
View File
@@ -0,0 +1,63 @@
# Connecting an RC Receiver to a PX4 Linux-based Autopilot
This topic shows how to setup a PX4 Linux-based autopilot to connect and use a [supported RC receiver](../getting_started/rc_transmitter_receiver.md) on any serial port.
For RC types other than S.Bus, you can just connect the receiver directly to the serial ports, or to USB via a USB to TTY serial cable (e.g. like PL2302 USB to Serial TTL converter).
::: info
For an S.Bus receiver (or encoder - e.g. from Futaba, RadioLink, etc.) you will usually need to connect the receiver and device via a [signal inverter circuit](#signal_inverter_circuit), but otherwise the setup is the same.
:::
Then [Start the PX4 RC Driver](#start_driver) on the device, as shown below.
<a id="start_driver"></a>
## Starting the Driver
To start the RC driver on a particular UART (e.g. in this case `/dev/ttyS2`):
```sh
rc_input start -d /dev/ttyS2
```
For other driver usage information see: [rc_input](../modules/modules_driver.md#rc-input).
<a id="signal_inverter_circuit"></a>
## Signal Inverter Circuit (S.Bus only)
S.Bus is an _inverted_ UART communication signal.
While some serial ports/flight controllers can read an inverted UART signal, most require a signal inverter circuit between the receiver and serial port to un-invert the signal.
:::tip
This circuit is also required to read S.Bus remote control signals through the serial port or USB-to-TTY serial converter.
:::
This section shows how to create an appropriate circuit.
### Required Components
- 1x NPN transistor (e.g. NPN S9014 TO92)
- 1x 10K resistor
- 1x 1K resistor
::: info
Any type/model of transistor can be used because the current drain is very low.
:::
### Circuit Diagram/Connections
Connect the components as described below (and shown in the circuit diagram):
- S.Bus signal &rarr; 1K resistor &rarr; NPN transistor base
- NPN transistor emit &rarr; GND
- 3.3VCC &rarr; 10K resistor &rarr; NPN transistor collection &rarr; USB-to-TTY rxd
- 5.0VCC &rarr; S.Bus VCC
- GND &rarr; S.Bus GND
![Signal inverter circuit diagram](../../assets/sbus/driver_sbus_signal_inverter_circuit_diagram.png)
The image below shows the connections on a breadboard.
![Signal inverter breadboard](../../assets/sbus/driver_sbus_signal_inverter_breadboard.png)
docs/en/tutorials/motion-capture.md
+51
View File
@@ -0,0 +1,51 @@
# Flying with Motion Capture (VICON, NOKOV, Optitrack)
:::warning
**WORK IN PROGRESS**
This topic shares significant overlap with [External Position Estimation (ROS)](../ros/external_position_estimation.md).
:::
Indoor motion capture systems like VICON, NOKOV and Optitrack can be used to provide position and attitude data for vehicle state estimation, orto serve as ground-truth for analysis.
The motion capture data can be used to update PX4's local position estimate relative to the local origin. Heading (yaw) from the motion capture system can also be optionally integrated by the attitude estimator.
Pose (position and orientation) data from the motion capture system is sent to the autopilot over MAVLink, using the [ATT_POS_MOCAP](https://mavlink.io/en/messages/common.html#ATT_POS_MOCAP) message. See the section below on coordinate frames for data representation conventions. The [mavros](../ros/mavros_installation.md) ROS-Mavlink interface has a default plugin to send this message. They can also be sent using pure C/C++ code and direct use of the MAVLink library.
## Computing Architecture
It is **highly recommended** that you send motion capture data via an **onboard** computer (e.g Raspberry Pi, ODroid, etc.) for reliable communications. The onboard computer can be connected to the motion capture computer through WiFi, which offers reliable, high-bandwidth connection.
Most standard telemetry links like 3DR/SiK radios are **not** suitable for high-bandwidth motion capture applications.
## Coordinate Frames
This section shows how to setup the system with the proper reference frames. There are various representations but we will use two of them: ENU and NED.
- ENU is a ground-fixed frame where **X** axis points East, **Y** points North and **Z** up. The robot/vehicle body frame is **X** towards the front, **Z** up and **Y** towards the left.
- NED has **X** towards North, **Y** East and **Z** down. The robot/vehicle body frame has **X** towards the front, **Z** down and **Y** accordingly.
Frames are shown in the image below. NED on the left, ENU on the right:
![Reference frames](../../assets/lpe/ref_frames.png)
With the external heading estimation, however, magnetic North is ignored and faked with a vector corresponding to world _x_ axis (which can be placed freely at mocap calibration); yaw angle will be given respect to local _x_.
:::warning
When creating the rigid body in the motion capture software, remember to first align the robot with the world **X** axis otherwise yaw estimation will have an initial offset.
:::
## Estimator Choice
EKF2 is recommended for GPS-enabled systems (LPE is deprecated, and hence no longer supported or maintained).
The Q-Estimator is recommended if you don't have GPS, as it works without a magnetometer or barometer.
See [Switching State Estimators](../advanced/switching_state_estimators.md) for more information.
### EKF2
The ROS topic for motion cap `mocap_pose_estimate` for mocap systems and `vision_pose_estimate` for vision.
Check [mavros_extras](http://wiki.ros.org/mavros_extras) for further info.
## Testing
## Troubleshooting