mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-05-22 22:32:11 +08:00
New Crowdin translations - zh-CN (#25559)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
PX4 Build Bot
GitHub
@@ -157,6 +157,7 @@
|
||||
- [mRo (3DR) Pixhawk Wiring Quickstart](assembly/quick_start_pixhawk.md)
|
||||
- [Holybro Pixhawk Mini (FMUv3) - Discontinued](flight_controller/pixhawk_mini.md)
|
||||
- [Manufacturer-Supported Autopilots](flight_controller/autopilot_manufacturer_supported.md)
|
||||
- [Accton Godwit GA1](flight_controller/accton-godwit_ga1.md)
|
||||
- [AirMind MindPX](flight_controller/mindpx.md)
|
||||
- [AirMind MindRacer](flight_controller/mindracer.md)
|
||||
- [ARK Electronics ARKV6X](flight_controller/ark_v6x.md)
|
||||
@@ -283,6 +284,7 @@
|
||||
- [CubePilot Here+ (Discontined)](gps_compass/rtk_gps_hex_hereplus.md)
|
||||
- [INS (Inertial Navigation/GNSS)](sensor/inertial_navigation_systems.md)
|
||||
- [InertialLabs](sensor/inertiallabs.md)
|
||||
- [sbgECom](sensor/sbgecom.md)
|
||||
- [VectorNav](sensor/vectornav.md)
|
||||
- [光流](sensor/optical_flow.md)
|
||||
- [ARK 光流](dronecan/ark_flow.md)
|
||||
@@ -679,6 +681,8 @@
|
||||
- [RoverPositionSetpoint](msg_docs/RoverPositionSetpoint.md)
|
||||
- [RoverRateSetpoint](msg_docs/RoverRateSetpoint.md)
|
||||
- [RoverRateStatus](msg_docs/RoverRateStatus.md)
|
||||
- [RoverSpeedSetpoint](msg_docs/RoverSpeedSetpoint.md)
|
||||
- [RoverSpeedStatus](msg_docs/RoverSpeedStatus.md)
|
||||
- [RoverSteeringSetpoint](msg_docs/RoverSteeringSetpoint.md)
|
||||
- [RoverThrottleSetpoint](msg_docs/RoverThrottleSetpoint.md)
|
||||
- [RoverVelocitySetpoint](msg_docs/RoverVelocitySetpoint.md)
|
||||
@@ -739,6 +743,7 @@
|
||||
- [YawEstimatorStatus](msg_docs/YawEstimatorStatus.md)
|
||||
- [AirspeedValidatedV0](msg_docs/AirspeedValidatedV0.md)
|
||||
- [ArmingCheckReplyV0](msg_docs/ArmingCheckReplyV0.md)
|
||||
- [ArmingCheckRequestV0](msg_docs/ArmingCheckRequestV0.md)
|
||||
- [BatteryStatusV0](msg_docs/BatteryStatusV0.md)
|
||||
- [EventV0](msg_docs/EventV0.md)
|
||||
- [HomePositionV0](msg_docs/HomePositionV0.md)
|
||||
|
||||
@@ -628,7 +628,16 @@ div.frame_variant td, div.frame_variant th {
|
||||
### Free-Flyer
|
||||
|
||||
<div class="frame_common">
|
||||
<img src="../../assets/airframes/types/AirframeUnknown.svg"/>
|
||||
<img src="../../assets/airframes/types/FreeFlyer.svg"/>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>常规输出接法</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><ul><li><b>Motor1</b>: back left thruster, +x thrust</li><li><b>Motor2</b>: front left thruster, -x thrust</li><li><b>Motor3</b>: back right thruster, +x thrust</li><li><b>Motor4</b>: front right thruster, -x thrust</li><li><b>Motor5</b>: front left thruster, +y thrust</li><li><b>Motor6</b>: front right thruster, -y thrust</li><li><b>Motor7</b>: back left thruster, +y thrust</li><li><b>Motor8</b>: back right thruster, -y thrust</li></ul></td>
|
||||
</tr>
|
||||
</tbody></table>
|
||||
</div>
|
||||
|
||||
<div class="frame_variant">
|
||||
@@ -638,7 +647,7 @@ div.frame_variant td, div.frame_variant th {
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="spacecraft_free-flyer_kth-atmos">
|
||||
<td>KTH-ATMOS</td>
|
||||
<td><a href="https://atmos.discower.io">KTH-ATMOS</a></td>
|
||||
<td>Maintainer: DISCOWER<p><code>SYS_AUTOSTART</code> = 70000</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
||||
@@ -291,7 +291,7 @@ If you're using [DroneCAN ESC](../peripherals/esc_motors.md#dronecan) the contro
|
||||
### Flight Controller Power
|
||||
|
||||
Pixhawk FCs require a regulated power supply that can supply at around 5V/3A continuous (check your specific FC)!
|
||||
This is sufficient to power the controller itself and a few low-power peripherals, such as a GNSS module, RC transmitter, and low power telemetry radio, but not for motors, actuators, and other peripherals.
|
||||
This is sufficient to power the controller itself and a few low-power peripherals, such as a GNSS module, RC receiver, and low power telemetry radio, but not for motors, actuators, and other peripherals.
|
||||
|
||||
[Power modules](../power_module/index.md) are commonly used to "split off" this regulated power supply for the FC and also to provide measurements of the battery voltage and total current to the whole system — which PX4 can use to estimate power levels.
|
||||
The power module is connected to the FC power port, which is normally labeled `POWER` (or `POWER 1` or `POWER 2` for FCs that have redundant power supply).
|
||||
|
||||
@@ -13,9 +13,9 @@ The first executed file is the [init.d/rcS](https://github.com/PX4/PX4-Autopilot
|
||||
|
||||
根据 PX4 运行的操作系统将本文后续内容分成了如下各小节。
|
||||
|
||||
## Posix (Linux/MacOS)
|
||||
## POSIX (Linux/MacOS)
|
||||
|
||||
在 Posix 操作系统上，系统的 shell 将会作为脚本文件的解释器（例如， 在 Ubuntu 中 /bin/sh 与 Dash 建立了符号链接）。
|
||||
On POSIX, the system shell is used as script interpreter (e.g. /bin/sh, being symlinked to dash on Ubuntu).
|
||||
为了使 PX4 可以在 Posix 中正常运行，需要做到以下几点：
|
||||
|
||||
- PX4 的各个模块需要看起来像系统的单个可执行文件。
|
||||
@@ -59,7 +59,7 @@ cd <PX4-Autopilot>/build/px4_sitl_default/bin
|
||||
### Dynamic Modules
|
||||
|
||||
通常，所有模块都被编入一个 PX4 可执行程序。
|
||||
However, on Posix, there's the option of compiling a module into a separate file, which can be loaded into PX4 using the `dyn` command.
|
||||
However, on POSIX, there's the option of compiling a module into a separate file, which can be loaded into PX4 using the `dyn` command.
|
||||
|
||||
```sh
|
||||
dyn ./test.px4mod
|
||||
@@ -95,7 +95,7 @@ The whole boot can be replaced by creating a file `/etc/rc.txt` on the microSD c
|
||||
The best way to customize the system startup is to introduce a [new frame configuration](../dev_airframes/adding_a_new_frame.md).
|
||||
机架配置文件可以在固件中，也可以在SD卡上。
|
||||
|
||||
#### Dynamic customization
|
||||
#### Dynamic Customization
|
||||
|
||||
If you only need to "tweak" the existing configuration, such as starting one more application or setting the value of a few parameters, you can specify these by creating two files in the `/etc/` directory of the SD Card:
|
||||
|
||||
@@ -153,27 +153,36 @@ Calling an unknown command in system boot files may result in boot failure.
|
||||
mandatory_app start # Will abort boot if mandatory_app is unknown or fails
|
||||
```
|
||||
|
||||
#### Additional customization
|
||||
#### Additional Init-File Customization
|
||||
|
||||
In rare cases where the desired setup cannot be achieved through frame configuration or dynamic customization,
|
||||
you can add a script that will be contained in the binary.
|
||||
In rare cases where the desired setup cannot be achieved through frame configuration or dynamic customization, you can add a script that will be compiled into the binary for a particular `make` target build variant.
|
||||
|
||||
**Note**: In almost all cases, you should use a frame configuration. This method should only be used for
|
||||
edge-cases such as customizing `cannode` based boards.
|
||||
:::warning
|
||||
In almost all cases, you should use a frame configuration.
|
||||
This method should only be used for edge-cases such as customizing `cannode` based boards.
|
||||
:::
|
||||
|
||||
步骤如下：
|
||||
|
||||
- Add a new init script in `boards/<vendor>/<board>/init` that will run during board startup.
|
||||
例如：
|
||||
|
||||
- Add a new init script in `boards/<vendor>/<board>/init` that will run during board startup. 例如：
|
||||
```sh
|
||||
# File: boards/<vendor>/<board>/init/rc.additional
|
||||
param set-default <param> <value>
|
||||
```
|
||||
|
||||
- Add a new board variant in `boards/<vendor>/<board>/<variant>.px4board` that includes the additional script. 例如：
|
||||
- Add a new board variant in `boards/<vendor>/<board>/<variant>.px4board` that includes the additional script.
|
||||
例如：
|
||||
|
||||
```sh
|
||||
# File: boards/<vendor>/<board>/var.px4board
|
||||
CONFIG_BOARD_ADDITIONAL_INIT="rc.additional"
|
||||
```
|
||||
|
||||
- Compile the firmware with your new variant by appending the variant name to the compile target. 例如：
|
||||
- Compile the firmware with your new variant by appending the variant name to the compile target.
|
||||
例如：
|
||||
|
||||
```sh
|
||||
make <target>_var
|
||||
```
|
||||
|
||||
@@ -206,23 +206,13 @@ The relevant parameters shown below.
|
||||
|
||||
### Position Loss Failsafe Action
|
||||
|
||||
The failure action is controlled by [COM_POSCTL_NAVL](../advanced_config/parameter_reference.md#COM_POSCTL_NAVL), based on whether RC control is assumed to be available (and altitude information):
|
||||
|
||||
- `0`: Remote control available.
|
||||
Switch to _Altitude mode_ if a height estimate is available, otherwise _Stabilized mode_.
|
||||
- `1`: Remote control _not_ available.
|
||||
Switch to _Descend mode_ if a height estimate is available, otherwise enter flight termination.
|
||||
_Descend mode_ is a landing mode that does not require a position estimate.
|
||||
Multicopters will switch to [Altitude mode](../flight_modes_mc/altitude.md) if a height estimate is available, otherwise [Stabilized mode](../flight_modes_mc/manual_stabilized.md).
|
||||
|
||||
Fixed-wing planes, and VTOLs not configured to land in hover ([NAV_FORCE_VT](../advanced_config/parameter_reference.md#NAV_FORCE_VT)), have a parameter ([FW_GPSF_LT](../advanced_config/parameter_reference.md#FW_GPSF_LT)) that defines how long they will loiter (circle with a constant roll angle ([FW_GPSF_R](../advanced_config/parameter_reference.md#FW_GPSF_R)) at the current altitude) after losing position before attempting to land.
|
||||
If VTOLs have are configured to switch to hover for landing ([NAV_FORCE_VT](../advanced_config/parameter_reference.md#NAV_FORCE_VT)) then they will first transition and then descend.
|
||||
|
||||
The relevant parameters for all vehicles shown below.
|
||||
|
||||
| 参数 | 描述 |
|
||||
| -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| <a id="COM_POSCTL_NAVL"></a>[COM_POSCTL_NAVL](../advanced_config/parameter_reference.md#COM_POSCTL_NAVL) | Position control navigation loss response during mission. Values: `0` - assume use of RC, `1` - Assume no RC. |
|
||||
|
||||
Parameters that only affect Fixed-wing vehicles:
|
||||
|
||||
| 参数 | 描述 |
|
||||
|
||||
@@ -33,7 +33,7 @@ _QGroundControl for Windows_ is additionally required if you need to:
|
||||
Note that you can also use it to monitor a simulation, but you must manually [connect to the simulation running in WSL](#qgroundcontrol-on-windows).
|
||||
|
||||
:::info
|
||||
Connecting to an USB device from within WSL is not natively supported, however it can still be achieved by using the [USBIPD-WIN](https://learn.microsoft.com/en-us/windows/wsl/connect-usb) project. With this you can automatically upload firmware from the command line in WSL using the [`upload`](../dev_setup/building_px4.md#uploading-firmware-flashing-the-board) function.
|
||||
Connecting to an USB device from within WSL is not natively supported, however it can still be achieved by using the [USBIPD-WIN](https://learn.microsoft.com/en-us/windows/wsl/connect-usb) project. With this you can automatically upload firmware from the command line in WSL using the [`upload`](../dev_setup/building_px4.md#uploading-firmware-flashing-the-board) function.
|
||||
:::
|
||||
|
||||
:::info
|
||||
@@ -349,3 +349,9 @@ sudo add-apt-repository ppa:kisak/kisak-mesa
|
||||
sudo apt update
|
||||
sudo apt upgrade
|
||||
```
|
||||
|
||||
### QGroundControl not connecting to PX4 SITL
|
||||
|
||||
- The connection between PX4 SITL on WSL2 and QGroundControl on Windows requires [broadcasting](../simulation/index.md#enable-udp-broadcasting) or [streaming to a specific address](../simulation/index.md#enable-streaming-to-specific-address) to be enabled.
|
||||
Streaming to a specific address should be enabled by default, but is something to check if a connection can't be established.
|
||||
- Network traffic might be blocked by firewall or antivirus on you system.
|
||||
|
||||
@@ -0,0 +1,153 @@
|
||||
# Accton Godwit G-A1
|
||||
|
||||
:::warning
|
||||
PX4 does not manufacture this (or any) autopilot.
|
||||
Contact the [manufacturer](https://cubepilot.org/#/home) for hardware support or compliance issues.
|
||||
:::
|
||||
|
||||
The G-A1 is a state-of-the-art flight controller developed derived from the [Pixhawk Autopilot v6X Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-012%20Pixhawk%20Autopilot%20v6X%20Standard.pdf).
|
||||
|
||||
It includes an STM32H753 double-precision floating-point FMU processor and an STM32F103 IO coprocessor, multiple IMUs with 6-axis inertial sensors, two pressure/temperature sensors, and a geomagnetic sensor.
|
||||
It also has independent buses and power supplies, and is designed for safety and rich expansion capabilities.
|
||||
|
||||
With an integrated 10/100M Ethernet Physical Layer (PHY), the G-A1 can also communicate with a mission computer (airborne computer), high-end surveying and mapping cameras, and other UxV-mounted equipment for high-speed communications, meeting the needs of advanced UxV systems.
|
||||
|
||||
:::tip
|
||||
Visit [Accton-IoT Godwit](https://www.accton-iot.com/godwit/) for more information.
|
||||
:::
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
:::info
|
||||
This flight controller is [manufacturer supported](../flight_controller/autopilot_manufacturer_supported.md).
|
||||
:::
|
||||
|
||||
## 产品规格
|
||||
|
||||
### 处理器
|
||||
|
||||
- STM32H753IIK (Arm® Cortex®-M7 480MHz)
|
||||
- STM32F103 (Arm® Cortex®-M3, 72MHz)
|
||||
|
||||
### 传感器
|
||||
|
||||
- Bosch BMI088 (vibration isolated)
|
||||
- TDK InvenSense ICM-42688-P x 2 (one vibration isolated)
|
||||
- TDK Barometric Pressure and Temperature Sensor CP-20100 x 2 (one vibration isolated)
|
||||
- PNI RM3100 Geomagnetic Sensor (vibration isolated)
|
||||
|
||||
### 电源
|
||||
|
||||
- 4.6V to 5.7V
|
||||
|
||||
### External ports
|
||||
|
||||
- 2 CAN Buses (CAN1 and CAN2)
|
||||
- 3 TELEM Ports (TELEM1, TELEM2 and TELEM3)
|
||||
- 2 GPS Ports (GPS1 with safety switch, LED, buzzer, and GPS2)
|
||||
- 1 PPM IN
|
||||
- 1 SBUS OUT
|
||||
- 2 USB Ports (1 TYPE-C and 1 JST GH1.25)
|
||||
- 1 10/100Base-T Ethernet Port
|
||||
- 1 DSM/SBUS RC
|
||||
- 1 UART 4
|
||||
- 1 AD&IO Port
|
||||
- 2 Debug Ports (1 IO Debug and 1 FMU Debug)
|
||||
- 1 SPI6 Bus
|
||||
- 4 Power Inputs (Power 1, Power 2, Power C1 and Power C2)
|
||||
- 16 PWM Servo Outputs (A1-A8 from FMU and M1-M8 from IO)
|
||||
- Micro SD Socket (supports SD 4.1 & SDIO 4.0 in two databus modes: 1 bit (default) and 4 bits)
|
||||
|
||||
### Size and Dimensions
|
||||
|
||||
- 92.2 (L) x 51.2 (W) x 28.3 (H) mm
|
||||
- 77.6g (carrier board with IMU)
|
||||
|
||||
## 购买渠道
|
||||
|
||||
- [Accton-IoT Godwit](https://www.accton-iot.com/godwit/)
|
||||
- [sales@accton-iot.com](sales@accton-iot.com)
|
||||
|
||||
## 针脚定义
|
||||
|
||||
|
||||
|
||||
## UART Mapping
|
||||
|
||||
| Serial# | Protocol | Port | 备注 |
|
||||
| ------- | --------- | ------ | ---------- |
|
||||
| SERIAL1 | Telem1 | UART7 | /dev/ttyS6 |
|
||||
| SERIAL2 | Telem2 | UART5 | /dev/ttyS4 |
|
||||
| SERIAL3 | GPS1 | USART1 | /dev/ttyS0 |
|
||||
| SERIAL4 | GPS2 | UART8 | /dev/ttyS7 |
|
||||
| SERIAL5 | Telem3 | USART2 | /dev/ttyS1 |
|
||||
| SERIAL6 | UART4 | UART4 | /dev/ttyS3 |
|
||||
| SERIAL7 | FMU Debug | USART3 | |
|
||||
| SERIAL8 | OTG2 | USB | |
|
||||
|
||||
## Wiring Diagram
|
||||
|
||||
|
||||
|
||||
## PWM Output
|
||||
|
||||
PWM M1-M8 (IO Main PWM), A1-A8(FMU PWM).
|
||||
All these 16 support normal PWM output formats.
|
||||
FMU PWM A1-A6 can support DShot and B-Directional DShot.
|
||||
A1-A8(FMU PWM) are grouped as:
|
||||
|
||||
- Group 1: A1, A2, A3, A4
|
||||
- Group 2: A5, A6
|
||||
- Group 3: A7, A8
|
||||
|
||||
The motor and servo system should be connected to these ports according to the order outlined in the fuselage reference for your carrier.
|
||||
|
||||
|
||||
|
||||
## RC Input
|
||||
|
||||
For DSM/SBUS receivers, connect them to the DSM/SBUS interface which provides dedicated 3.3V and 5V power pins respectively, and check above "Pinout" for detailed pin definition.
|
||||
PPM receivers should be connected to the PPM interface. And other RC systems can be connected via other spare telemetry ports.
|
||||
|
||||
|
||||
|
||||
## GPS/Compass
|
||||
|
||||
The Godwit G-A1 has a built-in compass
|
||||
Due to potential interference, the autopilot is usually used with an external I2C compass as part of a GPS/Compass combination.
|
||||
|
||||
|
||||
|
||||
## Power Connection and Battery Monitor
|
||||
|
||||
This universal controller features a CAN PMU module that supports 3 to 14s lithium batteries.
|
||||
To ensure proper connection, attach the module's 6-pin connector to the flight control Power C1 and/or Power C2 interface.
|
||||
|
||||
This universal controller does not provide power to the servos.
|
||||
To power them, an external BEC must be connected to the positive and negative terminals of any A1–A8 or M1–M8 port.
|
||||
|
||||
|
||||
|
||||
## SD Card
|
||||
|
||||
The SD card is NOT included in the package, you need to prepare the SD card and insert it into the slot.
|
||||
|
||||
|
||||
|
||||
## 固件
|
||||
|
||||
The autopilot is compatible with PX4 firmware. And G-A1 can be detected by QGroundControl automatically. Users can also build it with target "accton-godwit_ga1"
|
||||
|
||||
To [build PX4](../dev_setup/building_px4.md) for this target, open up the terminal and enter:
|
||||
|
||||
```sh
|
||||
make accton-godwit_ga1
|
||||
```
|
||||
|
||||
## More Information and Support
|
||||
|
||||
- [Accton-IoT Godwit](https://www.accton-iot.com/godwit/)
|
||||
- [sales@accton-iot.com](sales@accton-iot.com)
|
||||
- [support@accton-iot.com](mailto:support@accton-iot.com)
|
||||
@@ -12,6 +12,7 @@ This category includes boards that are not fully compliant with the pixhawk stan
|
||||
|
||||
The boards in this category are:
|
||||
|
||||
- [Accton Godwit GA1](../flight_controller/accton-godwit_ga1.md)
|
||||
- [AirMind MindPX](../flight_controller/mindpx.md)
|
||||
- [AirMind MindRacer](../flight_controller/mindracer.md)
|
||||
- [ARK Electronics ARKV6X](../flight_controller/ark_v6x.md) (and [ARK Electronics Pixhawk Autopilot Bus Carrier](../flight_controller/ark_pab.md))
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Throw Launch (Multicopter)
|
||||
|
||||
<Badge type="tip" text="PX4 v1.15" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
:::warning
|
||||
Experimental
|
||||
|
||||
@@ -45,6 +45,41 @@ MicroStrain <command> [arguments...]
|
||||
status Driver status
|
||||
```
|
||||
|
||||
## eulernav_bahrs
|
||||
|
||||
Source: [drivers/ins/eulernav_bahrs](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/ins/eulernav_bahrs)
|
||||
|
||||
### 描述
|
||||
|
||||
Serial bus driver for the EULER-NAV Baro-Inertial AHRS.
|
||||
|
||||
### 示例
|
||||
|
||||
Attempt to start driver on a specified serial device.
|
||||
|
||||
```
|
||||
eulernav_bahrs start -d /dev/ttyS1
|
||||
```
|
||||
|
||||
Stop driver
|
||||
|
||||
```
|
||||
eulernav_bahrs stop
|
||||
```
|
||||
|
||||
### Usage {#eulernav_bahrs_usage}
|
||||
|
||||
```
|
||||
eulernav_bahrs <command> [arguments...]
|
||||
Commands:
|
||||
start Start driver
|
||||
-d <val> Serial device
|
||||
|
||||
status Print driver status
|
||||
|
||||
stop Stop driver
|
||||
```
|
||||
|
||||
## ilabs
|
||||
|
||||
Source: [drivers/ins/ilabs](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/ins/ilabs)
|
||||
|
||||
@@ -15,25 +15,25 @@ Request are published by `manual_control` and subscribed by the `commander` and
|
||||
# It allows mapping triggers from various external interfaces like RC channels or MAVLink to cause an action.
|
||||
# Request are published by `manual_control` and subscribed by the `commander` and `vtol_att_control` modules.
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp # [us] Time since system start
|
||||
|
||||
uint8 action # [@enum ACTION] Requested action
|
||||
uint8 ACTION_DISARM = 0 # Disarm vehicle
|
||||
uint8 ACTION_ARM = 1 # Arm vehicle
|
||||
uint8 ACTION_TOGGLE_ARMING = 2 # Toggle arming
|
||||
uint8 ACTION_UNKILL = 3 # Revert a kill action
|
||||
uint8 ACTION_KILL = 4 # Kill vehicle (instantly stop the motors)
|
||||
uint8 ACTION_SWITCH_MODE = 5 # Switch mode. The target mode is set in the `mode` field.
|
||||
uint8 ACTION_VTOL_TRANSITION_TO_MULTICOPTER = 6 # Transition to hover flight
|
||||
uint8 ACTION_VTOL_TRANSITION_TO_FIXEDWING = 7 # Transition to fast forward flight
|
||||
uint8 ACTION_TERMINATION = 8 # Irreversably output failsafe values on all outputs, trigger parachute
|
||||
uint8 action # [@enum ACTION] Requested action
|
||||
uint8 ACTION_DISARM = 0 # Disarm vehicle
|
||||
uint8 ACTION_ARM = 1 # Arm vehicle
|
||||
uint8 ACTION_TOGGLE_ARMING = 2 # Toggle arming
|
||||
uint8 ACTION_UNKILL = 3 # Revert a kill action
|
||||
uint8 ACTION_KILL = 4 # Kill vehicle (instantly stop the motors)
|
||||
uint8 ACTION_SWITCH_MODE = 5 # Switch mode. The target mode is set in the `mode` field.
|
||||
uint8 ACTION_VTOL_TRANSITION_TO_MULTICOPTER = 6 # Transition to hover flight
|
||||
uint8 ACTION_VTOL_TRANSITION_TO_FIXEDWING = 7 # Transition to fast forward flight
|
||||
uint8 ACTION_TERMINATION = 8 # Irreversibly output failsafe values on all outputs, trigger parachute
|
||||
|
||||
uint8 source # [@enum SOURCE] Request trigger type, such as a switch, button or gesture
|
||||
uint8 SOURCE_STICK_GESTURE = 0 # Triggered by holding the sticks in a certain position
|
||||
uint8 SOURCE_RC_SWITCH = 1 # Triggered by an RC switch moving into a certain position
|
||||
uint8 SOURCE_RC_BUTTON = 2 # Triggered by a momentary button on the RC being pressed or held
|
||||
uint8 SOURCE_RC_MODE_SLOT = 3 # Mode change through the RC mode selection mechanism
|
||||
uint8 source # [@enum SOURCE] Request trigger type, such as a switch, button or gesture
|
||||
uint8 SOURCE_STICK_GESTURE = 0 # Triggered by holding the sticks in a certain position
|
||||
uint8 SOURCE_RC_SWITCH = 1 # Triggered by an RC switch moving into a certain position
|
||||
uint8 SOURCE_RC_BUTTON = 2 # Triggered by a momentary button on the RC being pressed or held
|
||||
uint8 SOURCE_RC_MODE_SLOT = 3 # Mode change through the RC mode selection mechanism
|
||||
|
||||
uint8 mode # Requested mode. Only applies when `action` is `ACTION_SWITCH_MODE`. Values for this field are defined by the `vehicle_status_s::NAVIGATION_STATE_*` enumeration.
|
||||
uint8 mode # Requested mode. Only applies when `action` is `ACTION_SWITCH_MODE`. Values for this field are defined by the `vehicle_status_s::NAVIGATION_STATE_*` enumeration.
|
||||
|
||||
```
|
||||
|
||||
@@ -15,14 +15,14 @@ Published by the vehicle's allocation and consumed by the ESC protocol drivers e
|
||||
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Sampling timestamp of the data this control response is based on
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Sampling timestamp of the data this control response is based on
|
||||
|
||||
uint16 reversible_flags # Bitset indicating which motors are configured to be reversible
|
||||
uint16 reversible_flags # Bitset indicating which motors are configured to be reversible
|
||||
|
||||
uint8 ACTUATOR_FUNCTION_MOTOR1 = 101
|
||||
uint8 ACTUATOR_FUNCTION_MOTOR1 = 101 #
|
||||
|
||||
uint8 NUM_CONTROLS = 12
|
||||
float32[12] control # [@range -1, 1] Normalized thrust. where 1 means maximum positive thrust, -1 maximum negative (if not supported by the output, <0 maps to NaN). NaN maps to disarmed (stop the motors)
|
||||
uint8 NUM_CONTROLS = 12 #
|
||||
float32[12] control # [@range -1, 1] Normalized thrust. where 1 means maximum positive thrust, -1 maximum negative (if not supported by the output, <0 maps to NaN). NaN maps to disarmed (stop the motors)
|
||||
|
||||
```
|
||||
|
||||
@@ -15,10 +15,10 @@ Published by the vehicle's allocation and consumed by the actuator output driver
|
||||
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Sampling timestamp of the data this control response is based on
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Sampling timestamp of the data this control response is based on
|
||||
|
||||
uint8 NUM_CONTROLS = 8
|
||||
float32[8] control # [@range -1, 1] Normalized output. 1 means maximum positive position. -1 maximum negative position (if not supported by the output, <0 maps to NaN). NaN maps to disarmed.
|
||||
uint8 NUM_CONTROLS = 8 #
|
||||
float32[8] control # [@range -1, 1] Normalized output. 1 means maximum positive position. -1 maximum negative position (if not supported by the output, <0 maps to NaN). NaN maps to disarmed.
|
||||
|
||||
```
|
||||
|
||||
@@ -13,10 +13,10 @@ It is subscribed by the airspeed selector module, which validates the data from
|
||||
# This is published by airspeed sensor drivers, CAN airspeed sensors, simulators.
|
||||
# It is subscribed by the airspeed selector module, which validates the data from multiple sensors and passes on a single estimation to the EKF, controllers and telemetry providers.
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Timestamp of the raw data
|
||||
float32 indicated_airspeed_m_s # [m/s] Indicated airspeed
|
||||
float32 true_airspeed_m_s # [m/s] True airspeed
|
||||
float32 confidence # [@range 0,1] Confidence value for this sensor
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Timestamp of the raw data
|
||||
float32 indicated_airspeed_m_s # [m/s] Indicated airspeed
|
||||
float32 true_airspeed_m_s # [m/s] True airspeed
|
||||
float32 confidence # [@range 0,1] Confidence value for this sensor
|
||||
|
||||
```
|
||||
|
||||
@@ -21,39 +21,39 @@ The message is not used by internal/FMU components, as their mode requirements a
|
||||
# Note that the external component is identified by its registration_id, which is allocated to the component during registration (arming_check_id in RegisterExtComponentReply).
|
||||
# The message is not used by internal/FMU components, as their mode requirements are known at compile time.
|
||||
|
||||
uint32 MESSAGE_VERSION = 1
|
||||
uint32 MESSAGE_VERSION = 1
|
||||
|
||||
uint64 timestamp # [us] Time since system start.
|
||||
|
||||
uint8 request_id # Id of ArmingCheckRequest for which this is a response.
|
||||
uint8 registration_id # Id of external component emitting this response.
|
||||
uint8 request_id # Id of ArmingCheckRequest for which this is a response.
|
||||
uint8 registration_id # Id of external component emitting this response.
|
||||
|
||||
uint8 HEALTH_COMPONENT_INDEX_NONE = 0 # Index of health component for which this response applies.
|
||||
uint8 HEALTH_COMPONENT_INDEX_NONE = 0 # Index of health component for which this response applies.
|
||||
|
||||
uint8 health_component_index # [@enum HEALTH_COMPONENT_INDEX]
|
||||
bool health_component_is_present # Unused. Intended for use with health events interface (health_component_t in events.json).
|
||||
bool health_component_warning # Unused. Intended for use with health events interface (health_component_t in events.json).
|
||||
bool health_component_error # Unused. Intended for use with health events interface (health_component_t in events.json).
|
||||
uint8 health_component_index # [@enum HEALTH_COMPONENT_INDEX]
|
||||
bool health_component_is_present # Unused. Intended for use with health events interface (health_component_t in events.json).
|
||||
bool health_component_warning # Unused. Intended for use with health events interface (health_component_t in events.json).
|
||||
bool health_component_error # Unused. Intended for use with health events interface (health_component_t in events.json).
|
||||
|
||||
bool can_arm_and_run # True if the component can arm. For navigation mode components, true if the component can arm in the mode or switch to the mode when already armed.
|
||||
bool can_arm_and_run # True if the component can arm. For navigation mode components, true if the component can arm in the mode or switch to the mode when already armed.
|
||||
|
||||
uint8 num_events # Number of queued failure messages (Event) in the events field.
|
||||
uint8 num_events # Number of queued failure messages (Event) in the events field.
|
||||
|
||||
Event[5] events # Arming failure reasons (Queue of events to report to GCS).
|
||||
Event[5] events # Arming failure reasons (Queue of events to report to GCS).
|
||||
|
||||
# Mode requirements
|
||||
bool mode_req_angular_velocity # Requires angular velocity estimate (e.g. from gyroscope).
|
||||
bool mode_req_attitude # Requires an attitude estimate.
|
||||
bool mode_req_local_alt # Requires a local altitude estimate.
|
||||
bool mode_req_local_position # Requires a local position estimate.
|
||||
bool mode_req_local_position_relaxed # Requires a more relaxed global position estimate.
|
||||
bool mode_req_global_position # Requires a global position estimate.
|
||||
bool mode_req_global_position_relaxed # Requires a relaxed global position estimate.
|
||||
bool mode_req_mission # Requires an uploaded mission.
|
||||
bool mode_req_home_position # Requires a home position (such as RTL/Return mode).
|
||||
bool mode_req_prevent_arming # Prevent arming (such as in Land mode).
|
||||
bool mode_req_manual_control # Requires a manual controller
|
||||
bool mode_req_angular_velocity # Requires angular velocity estimate (e.g. from gyroscope).
|
||||
bool mode_req_attitude # Requires an attitude estimate.
|
||||
bool mode_req_local_alt # Requires a local altitude estimate.
|
||||
bool mode_req_local_position # Requires a local position estimate.
|
||||
bool mode_req_local_position_relaxed # Requires a more relaxed global position estimate.
|
||||
bool mode_req_global_position # Requires a global position estimate.
|
||||
bool mode_req_global_position_relaxed # Requires a relaxed global position estimate.
|
||||
bool mode_req_mission # Requires an uploaded mission.
|
||||
bool mode_req_home_position # Requires a home position (such as RTL/Return mode).
|
||||
bool mode_req_prevent_arming # Prevent arming (such as in Land mode).
|
||||
bool mode_req_manual_control # Requires a manual controller
|
||||
|
||||
uint8 ORB_QUEUE_LENGTH = 4 #
|
||||
uint8 ORB_QUEUE_LENGTH = 4
|
||||
|
||||
```
|
||||
|
||||
@@ -21,10 +21,12 @@ The reply will also include the registration_id for each external component, pro
|
||||
# The reply will include the published request_id, allowing correlation of all arming check information for a particular request.
|
||||
# The reply will also include the registration_id for each external component, provided to it during the registration process (RegisterExtComponentReply).
|
||||
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
uint32 MESSAGE_VERSION = 1
|
||||
|
||||
uint64 timestamp # [us] Time since system start.
|
||||
uint64 timestamp # [us] Time since system start.
|
||||
|
||||
uint8 request_id # Id of this request. Allows correlation with associated ArmingCheckReply messages.
|
||||
uint8 request_id # Id of this request. Allows correlation with associated ArmingCheckReply messages.
|
||||
|
||||
uint32 valid_registrations_mask # Bitmask of valid registration ID's (the bit is also cleared if flagged as unresponsive)
|
||||
|
||||
```
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
# ArmingCheckRequestV0 (UORB message)
|
||||
|
||||
Arming check request.
|
||||
|
||||
Broadcast message to request arming checks be reported by all registered components, such as external ROS 2 navigation modes.
|
||||
All registered components should respond with an ArmingCheckReply message that indicates their current mode requirements, and any arming failure information.
|
||||
The request is sent regularly, even while armed, so that the FMU always knows the current arming state for external modes, and can forward it to ground stations.
|
||||
|
||||
The reply will include the published request_id, allowing correlation of all arming check information for a particular request.
|
||||
The reply will also include the registration_id for each external component, provided to it during the registration process (RegisterExtComponentReply).
|
||||
|
||||
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/px4_msgs_old/msg/ArmingCheckRequestV0.msg)
|
||||
|
||||
```c
|
||||
# Arming check request.
|
||||
#
|
||||
# Broadcast message to request arming checks be reported by all registered components, such as external ROS 2 navigation modes.
|
||||
# All registered components should respond with an ArmingCheckReply message that indicates their current mode requirements, and any arming failure information.
|
||||
# The request is sent regularly, even while armed, so that the FMU always knows the current arming state for external modes, and can forward it to ground stations.
|
||||
#
|
||||
# The reply will include the published request_id, allowing correlation of all arming check information for a particular request.
|
||||
# The reply will also include the registration_id for each external component, provided to it during the registration process (RegisterExtComponentReply).
|
||||
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
|
||||
uint64 timestamp # [us] Time since system start.
|
||||
|
||||
uint8 request_id # Id of this request. Allows correlation with associated ArmingCheckReply messages.
|
||||
|
||||
```
|
||||
@@ -11,39 +11,39 @@ This is currently used only for logging cell status from MAVLink.
|
||||
#
|
||||
# This is currently used only for logging cell status from MAVLink.
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp # [us] Time since system start
|
||||
|
||||
uint16 status # [@enum STATUS_FLAG] Status bitmap
|
||||
uint16 STATUS_FLAG_UNKNOWN = 1 # State unknown or not reportable
|
||||
uint16 STATUS_FLAG_FAILED = 2 # Modem is unusable
|
||||
uint16 STATUS_FLAG_INITIALIZING = 4 # Modem is being initialized
|
||||
uint16 STATUS_FLAG_LOCKED = 8 # Modem is locked
|
||||
uint16 STATUS_FLAG_DISABLED = 16 # Modem is not enabled and is powered down
|
||||
uint16 STATUS_FLAG_DISABLING = 32 # Modem is currently transitioning to the STATUS_FLAG_DISABLED state
|
||||
uint16 STATUS_FLAG_ENABLING = 64 # Modem is currently transitioning to the STATUS_FLAG_ENABLED state
|
||||
uint16 STATUS_FLAG_ENABLED = 128 # Modem is enabled and powered on but not registered with a network provider and not available for data connections
|
||||
uint16 STATUS_FLAG_SEARCHING = 256 # Modem is searching for a network provider to register
|
||||
uint16 STATUS_FLAG_REGISTERED = 512 # Modem is registered with a network provider, and data connections and messaging may be available for use
|
||||
uint16 STATUS_FLAG_DISCONNECTING = 1024 # Modem is disconnecting and deactivating the last active packet data bearer. This state will not be entered if more than one packet data bearer is active and one of the active bearers is deactivated
|
||||
uint16 STATUS_FLAG_CONNECTING = 2048 # Modem is activating and connecting the first packet data bearer. Subsequent bearer activations when another bearer is already active do not cause this state to be entered
|
||||
uint16 STATUS_FLAG_CONNECTED = 4096 # One or more packet data bearers is active and connected
|
||||
uint16 status # [@enum STATUS_FLAG] Status bitmap
|
||||
uint16 STATUS_FLAG_UNKNOWN = 1 # State unknown or not reportable
|
||||
uint16 STATUS_FLAG_FAILED = 2 # Modem is unusable
|
||||
uint16 STATUS_FLAG_INITIALIZING = 4 # Modem is being initialized
|
||||
uint16 STATUS_FLAG_LOCKED = 8 # Modem is locked
|
||||
uint16 STATUS_FLAG_DISABLED = 16 # Modem is not enabled and is powered down
|
||||
uint16 STATUS_FLAG_DISABLING = 32 # Modem is currently transitioning to the STATUS_FLAG_DISABLED state
|
||||
uint16 STATUS_FLAG_ENABLING = 64 # Modem is currently transitioning to the STATUS_FLAG_ENABLED state
|
||||
uint16 STATUS_FLAG_ENABLED = 128 # Modem is enabled and powered on but not registered with a network provider and not available for data connections
|
||||
uint16 STATUS_FLAG_SEARCHING = 256 # Modem is searching for a network provider to register
|
||||
uint16 STATUS_FLAG_REGISTERED = 512 # Modem is registered with a network provider, and data connections and messaging may be available for use
|
||||
uint16 STATUS_FLAG_DISCONNECTING = 1024 # Modem is disconnecting and deactivating the last active packet data bearer. This state will not be entered if more than one packet data bearer is active and one of the active bearers is deactivated
|
||||
uint16 STATUS_FLAG_CONNECTING = 2048 # Modem is activating and connecting the first packet data bearer. Subsequent bearer activations when another bearer is already active do not cause this state to be entered
|
||||
uint16 STATUS_FLAG_CONNECTED = 4096 # One or more packet data bearers is active and connected
|
||||
|
||||
uint8 failure_reason # [@enum FAILURE_REASON] Failure reason
|
||||
uint8 FAILURE_REASON_NONE = 0 # No error
|
||||
uint8 FAILURE_REASON_UNKNOWN = 1 # Error state is unknown
|
||||
uint8 FAILURE_REASON_SIM_MISSING = 2 # SIM is required for the modem but missing
|
||||
uint8 FAILURE_REASON_SIM_ERROR = 3 # SIM is available, but not usable for connection
|
||||
uint8 failure_reason # [@enum FAILURE_REASON] Failure reason
|
||||
uint8 FAILURE_REASON_NONE = 0 # No error
|
||||
uint8 FAILURE_REASON_UNKNOWN = 1 # Error state is unknown
|
||||
uint8 FAILURE_REASON_SIM_MISSING = 2 # SIM is required for the modem but missing
|
||||
uint8 FAILURE_REASON_SIM_ERROR = 3 # SIM is available, but not usable for connection
|
||||
|
||||
uint8 type # [@enum CELLULAR_NETWORK_RADIO_TYPE] Cellular network radio type
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_NONE = 0 # None
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_GSM = 1 # GSM
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_CDMA = 2 # CDMA
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_WCDMA = 3 # WCDMA
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_LTE = 4 # LTE
|
||||
uint8 type # [@enum CELLULAR_NETWORK_RADIO_TYPE] Cellular network radio type
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_NONE = 0 # None
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_GSM = 1 # GSM
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_CDMA = 2 # CDMA
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_WCDMA = 3 # WCDMA
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_LTE = 4 # LTE
|
||||
|
||||
uint8 quality # [dBm] Cellular network RSSI/RSRP, absolute value
|
||||
uint16 mcc # [@invalid UINT16_MAX] Mobile country code
|
||||
uint16 mnc # [@invalid UINT16_MAX] Mobile network code
|
||||
uint16 lac # [@invalid 0] Location area code
|
||||
uint8 quality # [dBm] Cellular network RSSI/RSRP, absolute value
|
||||
uint16 mcc # [@invalid UINT16_MAX] Mobile country code
|
||||
uint16 mnc # [@invalid UINT16_MAX] Mobile network code
|
||||
uint16 lac # [@invalid 0] Location area code
|
||||
|
||||
```
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
# RoverSpeedSetpoint (UORB message)
|
||||
|
||||
Rover Speed Setpoint
|
||||
|
||||
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/RoverSpeedSetpoint.msg)
|
||||
|
||||
```c
|
||||
# Rover Speed Setpoint
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 speed_body_x # [m/s] [@range -inf (Backwards), inf (Forwards)] [@frame Body] Speed setpoint in body x direction
|
||||
float32 speed_body_y # [m/s] [@range -inf (Left), inf (Right)] [@frame Body] [@invalid NaN If not mecanum] Mecanum only: Speed setpoint in body y direction
|
||||
|
||||
```
|
||||
@@ -0,0 +1,18 @@
|
||||
# RoverSpeedStatus (UORB message)
|
||||
|
||||
Rover Velocity Status
|
||||
|
||||
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/RoverSpeedStatus.msg)
|
||||
|
||||
```c
|
||||
# Rover Velocity Status
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 measured_speed_body_x # [m/s] [@range -inf (Backwards), inf (Forwards)] [@frame Body] Measured speed in body x direction
|
||||
float32 adjusted_speed_body_x_setpoint # [m/s] [@range -inf (Backwards), inf (Forwards)] [@frame Body] Speed setpoint in body x direction that is being tracked (Applied slew rates)
|
||||
float32 pid_throttle_body_x_integral # [] [@range -1, 1] Integral of the PID for the closed loop controller of the speed in body x direction
|
||||
float32 measured_speed_body_y # [m/s] [@range -inf (Left), inf (Right)] [@frame Body] [@invalid NaN If not mecanum] Mecanum only: Measured speed in body y direction
|
||||
float32 adjusted_speed_body_y_setpoint # [m/s] [@range -inf (Left), inf (Right)] [@frame Body] [@invalid NaN If not mecanum] Mecanum only: Speed setpoint in body y direction that is being tracked (Applied slew rates)
|
||||
float32 pid_throttle_body_y_integral # [] [@range -1, 1] [@invalid NaN If not mecanum] Mecanum only: Integral of the PID for the closed loop controller of the speed in body y direction
|
||||
|
||||
```
|
||||
@@ -1,22 +1,26 @@
|
||||
# VehicleAirData (UORB message)
|
||||
|
||||
Vehicle air data
|
||||
|
||||
Data from the currently selected barometer (plus ambient temperature from the source specified in temperature_source).
|
||||
Includes calculated data such as barometric altitude and air density.
|
||||
|
||||
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleAirData.msg)
|
||||
|
||||
```c
|
||||
# Vehicle air data
|
||||
#
|
||||
# Data from the currently selected barometer (plus ambient temperature from the source specified in temperature_source).
|
||||
# Includes calculated data such as barometric altitude and air density.
|
||||
|
||||
uint64 timestamp # time since system start (microseconds)
|
||||
|
||||
uint64 timestamp_sample # the timestamp of the raw data (microseconds)
|
||||
|
||||
uint32 baro_device_id # unique device ID for the selected barometer
|
||||
|
||||
float32 baro_alt_meter # Altitude above MSL calculated from temperature compensated baro sensor data using an ISA corrected for sea level pressure SENS_BARO_QNH.
|
||||
float32 baro_pressure_pa # Absolute pressure in Pascals
|
||||
float32 ambient_temperature # Abient temperature in degrees Celsius
|
||||
uint8 temperature_source # Source of temperature data: 0: Default Temperature (15°C), 1: External Baro, 2: Airspeed
|
||||
|
||||
float32 rho # air density
|
||||
|
||||
uint8 calibration_count # Calibration changed counter. Monotonically increases whenever calibration changes.
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Timestamp of the raw data
|
||||
uint32 baro_device_id # Unique device ID for the selected barometer
|
||||
float32 baro_alt_meter # [m] [@frame MSL] Altitude above MSL calculated from temperature compensated baro sensor data using an ISA corrected for sea level pressure SENS_BARO_QNH
|
||||
float32 baro_pressure_pa # [Pa] Absolute pressure
|
||||
float32 ambient_temperature # [degC] Ambient temperature
|
||||
uint8 temperature_source # Source of temperature data: 0: Default Temperature (15°C), 1: External Baro, 2: Airspeed
|
||||
float32 rho # [kg/m^3] Air density
|
||||
uint8 calibration_count # Calibration changed counter. Monotonically increases whenever calibration changes.
|
||||
|
||||
```
|
||||
|
||||
@@ -229,10 +229,10 @@ Graphs showing how these are used [can be found here](../middleware/uorb_graph.m
|
||||
- [RoverPositionSetpoint](RoverPositionSetpoint.md) — Rover Position Setpoint
|
||||
- [RoverRateSetpoint](RoverRateSetpoint.md) — Rover Rate setpoint
|
||||
- [RoverRateStatus](RoverRateStatus.md) — Rover Rate Status
|
||||
- [RoverSpeedSetpoint](RoverSpeedSetpoint.md) — Rover Speed Setpoint
|
||||
- [RoverSpeedStatus](RoverSpeedStatus.md) — Rover Velocity Status
|
||||
- [RoverSteeringSetpoint](RoverSteeringSetpoint.md) — Rover Steering setpoint
|
||||
- [RoverThrottleSetpoint](RoverThrottleSetpoint.md) — Rover Throttle setpoint
|
||||
- [RoverVelocitySetpoint](RoverVelocitySetpoint.md) — Rover Velocity Setpoint
|
||||
- [RoverVelocityStatus](RoverVelocityStatus.md) — Rover Velocity Status
|
||||
- [Rpm](Rpm.md)
|
||||
- [RtlStatus](RtlStatus.md)
|
||||
- [RtlTimeEstimate](RtlTimeEstimate.md)
|
||||
@@ -281,7 +281,7 @@ Graphs showing how these are used [can be found here](../middleware/uorb_graph.m
|
||||
- [UlogStreamAck](UlogStreamAck.md) — Ack a previously sent ulog_stream message that had
|
||||
the NEED_ACK flag set
|
||||
- [VehicleAcceleration](VehicleAcceleration.md)
|
||||
- [VehicleAirData](VehicleAirData.md)
|
||||
- [VehicleAirData](VehicleAirData.md) — Vehicle air data
|
||||
- [VehicleAngularAccelerationSetpoint](VehicleAngularAccelerationSetpoint.md)
|
||||
- [VehicleConstraints](VehicleConstraints.md) — Local setpoint constraints in NED frame
|
||||
setting something to NaN means that no limit is provided
|
||||
@@ -301,6 +301,7 @@ Graphs showing how these are used [can be found here](../middleware/uorb_graph.m
|
||||
- [YawEstimatorStatus](YawEstimatorStatus.md)
|
||||
- [AirspeedValidatedV0](AirspeedValidatedV0.md)
|
||||
- [ArmingCheckReplyV0](ArmingCheckReplyV0.md)
|
||||
- [ArmingCheckRequestV0](ArmingCheckRequestV0.md) — Arming check request.
|
||||
- [BatteryStatusV0](BatteryStatusV0.md) — Battery status
|
||||
- [EventV0](EventV0.md) — this message is required here in the msg_old folder because other msg are depending on it
|
||||
Events interface
|
||||
|
||||
@@ -52,7 +52,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
|
||||
|
||||
### 传感器
|
||||
|
||||
- TBD
|
||||
- Add [sbgECom INS driver](../sensor/sbgecom.md) ([PX4-Autopilot#24137](https://github.com/PX4/PX4-Autopilot/pull/24137))
|
||||
|
||||
### 仿真
|
||||
|
||||
|
||||
+21
-21
@@ -1,45 +1,45 @@
|
||||
# ROS 2
|
||||
|
||||
[ROS 2](https://docs.ros.org/en/humble/#) is a powerful general purpose robotics library that can be used with the PX4 Autopilot to create powerful drone applications.
|
||||
ROS 2 是ROS (机器人操作系统)最新版本 ， 一个通用的机器人库，可以与 PX4 自驾仪一起创建强大的无人机应用。
|
||||
|
||||
:::warning
|
||||
Tip
|
||||
The PX4 development team highly recommend that you use/migrate to this version of ROS!
|
||||
小提示
|
||||
PX4开发团队强烈建议您使用/迁移到此版本的 ROS！
|
||||
|
||||
This is the newest version of [ROS](https://www.ros.org/) (Robot Operating System).
|
||||
It significantly improves on ROS "1", and in particular allows a much deeper and lower-latency integration with PX4.
|
||||
这是最新版本的 [ROS](https://www.ros.org/) (机器人操作系统)。
|
||||
它大大改进了外空军备竞赛“1”，尤其是允许与PX4更深、更低的延迟结合。
|
||||
:::
|
||||
|
||||
ROS得益于一个活跃的生态系统，在这个生态系统里，开发者会解决常见的机器人问题，他们也有权使用为Linux编写的其他软件库。
|
||||
It can be used, for example, for [computer vision](../computer_vision/index.md) solutions.
|
||||
例如，它可以用于[计算机视图](../computer_vision/index.md)解决方案。
|
||||
|
||||
ROS 2 enables a very deep integration with PX4, to the extent that you can create flight modes in ROS 2 that are indistinguisable from internal PX4 modes, and directly read from and write to internal uORB topics at high rate.
|
||||
It is recommended (in particular) for control and communication from a companion computer where low latency is important, when leveraging existing libraries from Linux, or when writing new high level flight modes.
|
||||
ROS 2能够非常深入地与 PX4 集成 只要你可以在交战规则2中创建无法与内部的 PX4 模式区分的飞行模式， 并以高费率直接读取内部uORB主题。
|
||||
建议（尤其是）从同伴计算机进行控制和通信，因为这种计算机的延迟率很低。 当利用来自Linux的现有库时，或在编写新的高层飞行模式时。
|
||||
|
||||
Communication between ROS 2 and PX4 uses middleware that implements the [XRCE-DDS protocol](../middleware/uxrce_dds.md).
|
||||
This middleware exposes PX4 [uORB messages](../msg_docs/index.md) as ROS 2 messages and types, effectively allowing direct access to PX4 from ROS 2 workflows and nodes.
|
||||
ROS 2 和 PX4 之间的通信使用中间件实现[XRCE-DDS] (../middleware/uxrce_dds.md)。
|
||||
这个中间件将以 ROS 2 消息和类型显示 PX4 [uORB 消息](../msg_docs/index.md)， 有效地允许从 ROS 2 工作流和节点直接访问 PX4。
|
||||
中间件使用 uORB 消息定义生成代码来序列化和反序列化来处理PX4 的收发消息。
|
||||
These same message definitions are used in ROS 2 applications to allow the messages to be interpreted.
|
||||
在ROS 2 应用中使用相同的消息定义可直接进行解析。
|
||||
|
||||
:::info
|
||||
ROS 2 can also connect with PX4 using [MAVROS](https://github.com/mavlink/mavros/tree/ros2/mavros) instead of XRCE-DDS.
|
||||
This option is supported by the MAVROS project (it is not documented here).
|
||||
ROS 2 也可以使用 [MAVROS](https://github.com/mavlink/mavros/tree/ros2/mavros而不是 XRCE-DDS连接到 PX4。
|
||||
这一备选办法得到了MAVROS项目的支持(此处没有记录)。
|
||||
:::
|
||||
|
||||
To use the [ROS 2](../ros2/user_guide.md) over XRCE-DDS effectively, you must (at time of writing) have a reasonable understanding of the PX4 internal architecture and conventions, which differ from those used by ROS.
|
||||
在XRCE-DDS上有效使用[ROS2](../ros2/user_guide.md)。 (撰写本文时)你必须对PX4内部结构和公约有合理的理解，这些结构和公约不同于交战规则所用的内部结构和公约。
|
||||
我们计划近期提供ROS 2 API 以对 PX4 的特性进行封装，并举例说明它们的用途。
|
||||
|
||||
## Topics
|
||||
|
||||
本节的主要主题是：
|
||||
|
||||
- [ROS 2 User Guide](../ros2/user_guide.md): A PX4-centric overview of ROS 2, covering installation, setup, and how to build ROS 2 applications that communicate with PX4.
|
||||
- [ROS 2 Offboard Control Example](../ros2/offboard_control.md): A C++ tutorial examples showing how to do position control in [offboard mode](../flight_modes/offboard.md) from a ROS 2 node.
|
||||
- [ROS 2 Multi Vehicle Simulation](../ros2/multi_vehicle.md): Instructions for connecting to multipole PX4 simulations via single ROS 2 agent.
|
||||
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md): A C++ library that simplies interacting with PX4 from ROS 2.
|
||||
Can be used to create and register flight modes wrtten using ROS2 and send position estimates from ROS2 applications such as a VIO system.
|
||||
- [ROS 2 Message Translation Node](../ros2/px4_ros2_msg_translation_node.md): A ROS 2 message translation node that enables communcation between PX4 and ROS 2 applications that were compiled with different sets of messages versions.
|
||||
- ROS 2 用户指南: PX4 视角下的 ROS 2，包括安装、设置和如何构建与 PX4 通信的 ROS 2 应用。
|
||||
- [ROS 2 离板控制示例](../ros2/offboard_control.md)：一个 C++ 教程示例显示如何在 [离板模式] (../flight_modes/offboard.md) 中使用 ROS 2 节点进行位置控制。
|
||||
- [ROS 2 多车辆模拟](../ros2/multi_vehicle.md)：通过单独的ROS2 代理商连接到多极PX4 模拟的说明。
|
||||
- [PX4 ROS2 接口库](../ros2/px4_ros2_interface_lib.md)：一个C++ 库，它与ROS2的 PX4 交互。
|
||||
可以使用 ROS 2 创建和注册飞行模式，并从 ROS2 应用程序如VIO 系统发送位置估计数。
|
||||
- [ROS 2 消息翻译节点](../ros2/px4_ros2_msg_translation_node.md)：一个 ROS 2 消息翻译节点，它允许在 PX4 和 ROS 2 应用程序之间共享，这些应用程序被编译成不同的消息版本。
|
||||
|
||||
## 更多信息
|
||||
|
||||
- [XRCE-DDS (PX4-ROS 2/DDS Bridge)](../middleware/uxrce_dds.md): PX4 middleware for connecting to ROS 2.
|
||||
- [XRCE-DDS (PX4-ROS 2/DDS Bridge)](../middleware/uxrce_dds.md): PX4 使用中间件链接到 ROS 2。
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
# Multi-Vehicle Simulation with ROS 2
|
||||
# 使用 ROS 2 进行多车辆仿真
|
||||
|
||||
[XRCE-DDS](../middleware/uxrce_dds.md) allows for multiple clients to be connected to the same agent over UDP.
|
||||
This is particular useful in simulation as only one agent needs to be started.
|
||||
[XRCE-DDS](../middleware/uxrce_dds.md) 支持多个客户端通过 UDP 协议连接到同一个代理。
|
||||
这在模拟中特别有用，因为只有一个代理需要启动。
|
||||
|
||||
## Setup and Requirements
|
||||
## 设置和要求
|
||||
|
||||
The only requirements are
|
||||
唯一的要求是
|
||||
|
||||
- To be able to run [multi-vehicle simulation](../simulation/multi-vehicle-simulation.md) without ROS 2 with the desired simulator ([Gazebo](../sim_gazebo_gz/multi_vehicle_simulation.md), [Gazebo Classic](../sim_gazebo_classic/multi_vehicle_simulation.md#multiple-vehicle-with-gazebo-classic), [FlightGear](../sim_flightgear/multi_vehicle.md) and [JMAVSim](../sim_jmavsim/multi_vehicle.md)).
|
||||
- To be able to use [ROS 2](../ros2/user_guide.md) in a single vehicle simulation.
|
||||
- 能够在不依赖 ROS 2 的情况下，使用所需的仿真器([Gazebo](../sim_gazebo_gz/multi_vehicle_simulation.md), [Gazebo Classic](../sim_gazebo_classic/multi_vehicle_simulation.md#multiple-vehicle-with-gazebo-classic), [FlightGear](../sim_flightgear/multi_vehicle.md) 和 [JMAVSim](../sim_jmavsim/multi_vehicle.md))运行多车辆仿真[multi-vehicle simulation](../simulation/multi-vehicle-simulation.md)。
|
||||
- 能够在单车辆仿真中使用ROS 2（机器人操作系统 2）
|
||||
|
||||
## Principle of Operation
|
||||
## 工作原理
|
||||
|
||||
In simulation each PX4 instance receives a unique `px4_instance` number starting from `0`.
|
||||
This value is used to assign a unique value to [UXRCE_DDS_KEY](../advanced_config/parameter_reference.md#UXRCE_DDS_KEY):
|
||||
在仿真中，每个 PX4 实例都会获得一个唯一的px4_instance编号，编号从0开始。
|
||||
该值用于为 [UXRCE_DDS_KEY](../advanced_config/parameter_reference.md#UXRCE_DDS_KEY)分配一个唯一值：
|
||||
|
||||
```sh
|
||||
param set UXRCE_DDS_KEY $((px4_instance+1))
|
||||
参数设置 UXRCE_DDS_KEY $(px4_instance+1))
|
||||
```
|
||||
|
||||
:::info
|
||||
By doing so, `UXRCE_DDS_KEY` will always coincide with [MAV_SYS_ID](../advanced_config/parameter_reference.md#MAV_SYS_ID).
|
||||
通过这种方式，UXRCE_DDS_KEY 将始终与 [MAV_SYS_ID] 保持一致（../advanced_config/parameter_reference.md#MAV_SYS_ID）
|
||||
:::
|
||||
|
||||
Moreover, when `px4_instance` is greater than zero, a unique ROS 2 [namespace prefix](../middleware/uxrce_dds.md#customizing-the-namespace) in the form `px4_$px4_instance` is added:
|
||||
此外，当 px4_instance 大于 0 时，会添加一个格式为 px4_$px4_instance 的唯一 ROS 2 命名空间前缀：
|
||||
|
||||
```sh
|
||||
uxrce_dds_ns="-n px4_$px4_instance"
|
||||
```
|
||||
|
||||
:::info
|
||||
The environment variable `PX4_UXRCE_DDS_NS`, if set, will override the namespace behavior described above.
|
||||
环境变量 PX4_UXRCE_DDS_NS 若已设置，将覆盖上文所述的命名空间行为。
|
||||
:::
|
||||
|
||||
The first instance (`px4_instance=0`) does not have an additional namespace in order to be consistent with the default behavior of the `xrce-dds` client on a real vehicle.
|
||||
This mismatch can be fixed by manually using `PX4_UXRCE_DDS_NS` on the first instance or by starting adding vehicles from index `1` instead of `0` (this is the default behavior adopted by [sitl_multiple_run.sh](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/simulation/gazebo-classic/sitl_multiple_run.sh) for Gazebo Classic).
|
||||
第一个实例（px4_instance=0）没有额外的命名空间，此举是为了与真实载具上 xrce-dds 客户端的默认行为保持一致。
|
||||
这种不匹配可以通过手动使用 `PX4_UXRCE_DDS_NS` 来修复，或者通过从索引 `1` 中添加车辆而不是 `0` (这是Gazebo Classic的 [sitl_multiple_run.sh](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/simulation/gazebo-classic/sitl_multiple_run.sh) 的默认行为)。
|
||||
|
||||
The default client configuration in simulation is summarized as follows:
|
||||
模拟中的默认客户端配置概述如下：
|
||||
|
||||
| `PX4_UXRCE_DDS_NS` | `px4_instance` | `UXRCE_DDS_KEY` | client namespace |
|
||||
| `PX4_UXRCE_DDS_NS` | `px4_instance` | `UXRCE_DDS_KEY` | 客户端命名空间 |
|
||||
| ------------------ | -------------- | ---------------- | --------------------- |
|
||||
| not provided | 0 | `px4_instance+1` | 无 |
|
||||
| provided | 0 | `px4_instance+1` | `PX4_UXRCE_DDS_NS` |
|
||||
| not provided | > 0 | `px4_instance+1` | `px4_${px4_instance}` |
|
||||
| provided | > 0 | `px4_instance+1` | `PX4_UXRCE_DDS_NS` |
|
||||
| 未提供 | 0 | `px4_instance+1` | 无 |
|
||||
| 已提供 | 0 | `px4_instance+1` | `PX4_UXRCE_DDS_NS` |
|
||||
| 未提供 | > 0 | `px4_instance+1` | `px4_${px4_instance}` |
|
||||
| 已提供 | > 0 | `px4_instance+1` | `PX4_UXRCE_DDS_NS` |
|
||||
|
||||
## Adjusting the `target_system` value
|
||||
## 调整 `target_system` 值
|
||||
|
||||
PX4 accepts [VehicleCommand](../msg_docs/VehicleCommand.md) messages only if their `target_system` field is zero (broadcast communication) or coincides with `MAV_SYS_ID`.
|
||||
In all other situations, the messages are ignored.
|
||||
Therefore, when ROS 2 nodes want to send `VehicleCommand` to PX4, they must ensure that the messages are filled with the appropriate `target_system` value.
|
||||
PX4 只在他们的 `target_system` 字段为 0 (路由通信) 或与 `MAV_SYS_ID` 一致时，才接受 [VehicleCommand](../msg_docs/VehicleCommand.md)。
|
||||
在所有其他情况下，信息都被忽视。
|
||||
因此，当 ROS 2 节点需向 PX4 发送 VehicleCommand（载具指令）消息时，必须确保消息中填写了合适的 target_system（目标系统）字段值。
|
||||
|
||||
For example, if you want to send a command to your third vehicle, which has `px4_instance=2`, you need to set `target_system=3` in all your `VehicleCommand` messages.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ROS 2 Offboard 控制示例
|
||||
|
||||
The following C++ example shows how to do position control in [offboard mode](../flight_modes/offboard.md) from a ROS 2 node.
|
||||
以下的 C++ 示例展示了如何在 [离板模式] (../flight_modes/offboard.md) 中从 ROS 2 节点进行位置控制。
|
||||
|
||||
示例将首先发送设置点、进入offboard模式、解锁、起飞至5米，并悬停等待。
|
||||
虽然简单，但它显示了如何使用offboard控制以及如何向无人机发送指令。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# PX4 ROS 2 Control Interface
|
||||
|
||||
<Badge type="tip" text="PX4 v1.15" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
:::warning
|
||||
Experimental
|
||||
@@ -104,26 +104,26 @@ The above concepts provide a number of advantages over traditional [offboard con
|
||||
|
||||
The following steps are required to get started:
|
||||
|
||||
1. Make sure you have a working [ROS 2 setup](../ros2/user_guide.md), with [`px4_msgs`](https://github.com/PX4/px4_msgs) in the ROS 2 workspace.
|
||||
1. 请确保您在 ROS 2 工作区中有 [ROS 2 设置](../ros2/user_guide.md) 与 [`px4_msgs`](https://github.com/PX4/px4_msgs]。
|
||||
|
||||
2. Clone the repository into the workspace:
|
||||
2. 将代码仓库克隆到工作空间中
|
||||
|
||||
```sh
|
||||
cd $ros_workspace/src
|
||||
git clone --recursive https://github.com/Auterion/px4-ros2-interface-lib
|
||||
```
|
||||
|
||||
::: info
|
||||
To ensure compatibility, use the latest _main_ branches for PX4, _px4_msgs_ and the library.
|
||||
See also [here](https://github.com/Auterion/px4-ros2-interface-lib#compatibility-with-px4).
|
||||
提示信息
|
||||
为确保兼容性，请使用 PX4、px4_msgs（PX4 消息包）及该库的最新 main 分支。
|
||||
另请参阅 [here]（https://github.com/Auterion/px4-ros2-interface-lib#compatibility-with-px4）
|
||||
|
||||
:::
|
||||
|
||||
3. Build the workspace:
|
||||
3. 构建工作空间:
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
colcon build
|
||||
colcon building
|
||||
source install/setup.bash
|
||||
```
|
||||
|
||||
|
||||
@@ -1,48 +1,48 @@
|
||||
# PX4 ROS 2 Interface Library
|
||||
# PX4 ROS 2 接口库
|
||||
|
||||
<Badge type="tip" text="PX4 v1.15" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
:::warning
|
||||
Experimental
|
||||
At the time of writing, parts of the PX4 ROS 2 Interface Library are experimental, and hence subject to change.
|
||||
在撰写本文时，PX4 ROS 2 接口库的部分内容仍处于试验阶段，因此可能会发生变动。
|
||||
:::
|
||||
|
||||
The [PX4 ROS 2 Interface Library](https://github.com/Auterion/px4-ros2-interface-lib) is a C++ library that simplifies controlling and interacting with PX4 from ROS 2.
|
||||
[PX4 ROS 2 接口库 ]（https://github.com/Auterion/px4-ros2-interface-lib）是一个 C++ 库，可简化从 ROS 2 对 PX4 进行控制和交互的操作。
|
||||
|
||||
The library provides two high-level interfaces for developers:
|
||||
该库为开发者提供了两个高级接口。
|
||||
|
||||
1. The [Control Interface](./px4_ros2_control_interface.md) allows developers to create and dynamically register modes written using ROS 2.
|
||||
It provides classes for sending different types of setpoints, ranging from high-level navigation tasks all the way down to direct actuator controls.
|
||||
2. The [Navigation Interface](./px4_ros2_navigation_interface.md) enables sending vehicle position estimates to PX4 from ROS 2 applications, such as a VIO system.
|
||||
1. [Control Interface](./px4_ros2_control_interface.md) 允许开发者创建并动态注册使用 ROS2 编写的模式。
|
||||
它为发送不同类型的设置点提供了课程，涵盖范围从高级导航任务一直到直接执行器控制。
|
||||
2. [导航界面](./px4_ros2_navigation_interface.md) 允许从ROS 2应用程序（如VIO系统）向PX4发送车辆位置估计数。
|
||||
|
||||
<!--
|
||||
## Overview
|
||||
-->
|
||||
|
||||
## Installation in a ROS 2 Workspace
|
||||
## 在 ROS 2 工作区中安装
|
||||
|
||||
To get started using the library within an existing ROS 2 workspace:
|
||||
要开始使用现有ROS2工作空间内的库：
|
||||
|
||||
1. Make sure you have a working [ROS 2 setup](../ros2/user_guide.md), with [`px4_msgs`](https://github.com/PX4/px4_msgs) in the ROS 2 workspace.
|
||||
1. 请确保您在 ROS 2 工作区中有 [ROS 2 设置](../ros2/user_guide.md) 与 [`px4_msgs`](https://github.com/PX4/px4_msgs]。
|
||||
|
||||
2. Clone the repository into the workspace:
|
||||
2. 将代码仓库克隆到工作空间中
|
||||
|
||||
```sh
|
||||
cd $ros_workspace/src
|
||||
git clone --recursive https://github.com/Auterion/px4-ros2-interface-lib
|
||||
```
|
||||
|
||||
::: info
|
||||
To ensure compatibility, use the latest _main_ branches for PX4, _px4_msgs_ and the library.
|
||||
See also [here](https://github.com/Auterion/px4-ros2-interface-lib#compatibility-with-px4).
|
||||
提示信息
|
||||
为确保兼容性，请使用 PX4、px4_msgs（PX4 消息包）及该库的最新 main 分支。
|
||||
另请参阅 [here]（https://github.com/Auterion/px4-ros2-interface-lib#compatibility-with-px4）
|
||||
|
||||
:::
|
||||
|
||||
3. Build the workspace:
|
||||
3. 构建工作空间:
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
colcon build
|
||||
colcon building
|
||||
source install/setup.bash
|
||||
```
|
||||
|
||||
@@ -50,9 +50,9 @@ To get started using the library within an existing ROS 2 workspace:
|
||||
## How to Use the Library
|
||||
-->
|
||||
|
||||
## CI: Integration Tests
|
||||
## ROS集成测试
|
||||
|
||||
When opening a pull request to PX4, CI runs the library integration tests.
|
||||
These test that mode registration, failsafes, and mode replacement, work as expected.
|
||||
向 PX4 提交拉取请求（pull request）时，持续集成（CI）会运行该库的集成测试
|
||||
这些测试用于验证模式注册、故障保护（failsafes）和模式替换功能是否按预期工作。
|
||||
|
||||
For more information see [PX4 ROS2 Interface Library Integration Testing](../test_and_ci/integration_testing_px4_ros2_interface.md).
|
||||
欲了解更多信息，请访问[PX4 ROS2 接口库集成测试](../test_and_ci/integration_testing_px4_ros2_interface.md)。
|
||||
|
||||
@@ -65,7 +65,7 @@ The translation node will print a warning if it encounters an unknown topic vers
|
||||
After making a modification in PX4 to the message definitions and/or translation node code, you will need to rerun the steps above from point 2 to update your ROS workspace accordingly.
|
||||
:::
|
||||
|
||||
### In ROS Applications
|
||||
### 在ROS 应用中
|
||||
|
||||
While developing a ROS 2 application that communicates with PX4, it is not necessary to know the specific version of a message being used.
|
||||
The message version can be added generically to a topic name like this:
|
||||
@@ -183,7 +183,7 @@ class MinimalPubSub(Node):
|
||||
On the PX4 side, the DDS client automatically adds the version suffix if a message definition contains the field `uint32 MESSAGE_VERSION = x`.
|
||||
|
||||
:::info
|
||||
Version 0 of a topic means that no `_v<version>` suffix should be added.
|
||||
主题版本0意味着不应添加`_v<version>`后缀。
|
||||
:::
|
||||
|
||||
## Development
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# PX4 ROS 2 Navigation Interface
|
||||
# PX4 ROS2 导航接口
|
||||
|
||||
<Badge type="tip" text="PX4 v1.15" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
:::warning
|
||||
Experimental
|
||||
At the time of writing, parts of the PX4 ROS 2 Interface Library are experimental, and hence subject to change.
|
||||
在撰写本文时，PX4 ROS 2 接口库的部分内容仍处于试验阶段，因此可能会发生变动。
|
||||
:::
|
||||
|
||||
The [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) navigation interface enables developers to send their position measurements to PX4 directly from ROS 2 applications, such as a VIO system or a map matching system.
|
||||
@@ -18,22 +18,22 @@ The `update` method expects a position measurement `struct` ([`LocalPositionMeas
|
||||
|
||||
The following steps are required to get started:
|
||||
|
||||
1. Make sure you have a working [ROS 2 setup](../ros2/user_guide.md), with [`px4_msgs`](https://github.com/PX4/px4_msgs) in the ROS 2 workspace.
|
||||
1. 请确保您在 ROS 2 工作区中有 [ROS 2 设置](../ros2/user_guide.md) 与 [`px4_msgs`](https://github.com/PX4/px4_msgs]。
|
||||
|
||||
2. Clone the repository into the workspace:
|
||||
2. 将代码仓库克隆到工作空间中
|
||||
|
||||
```sh
|
||||
cd $ros_workspace/src
|
||||
git clone --recursive https://github.com/Auterion/px4-ros2-interface-lib
|
||||
```
|
||||
|
||||
::: info
|
||||
To ensure compatibility, use the latest _main_ branches for PX4, _px4_msgs_ and the library.
|
||||
See also [here](https://github.com/Auterion/px4-ros2-interface-lib#compatibility-with-px4).
|
||||
提示信息
|
||||
为确保兼容性，请使用 PX4、px4_msgs（PX4 消息包）及该库的最新 main 分支。
|
||||
另请参阅 [here]（https://github.com/Auterion/px4-ros2-interface-lib#compatibility-with-px4）
|
||||
|
||||
:::
|
||||
|
||||
3. Build the workspace:
|
||||
3. 构建工作空间:
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
|
||||
@@ -5,7 +5,7 @@ PX4使用加速计数据进行速度估计。
|
||||
你无需将加速度计作为独立的外部设备进行连接。
|
||||
|
||||
- 大多数飞行控制器，例如[Pixhawk系列](../flight_controller/pixhawk_series.md)中的飞行控制器，都将加速度计作为飞行控制器[惯性测量单元（IMU）](https://en.wikipedia.org/wiki/Inertial_measurement_unit)的一部分。
|
||||
- 陀螺仪作为[外部惯性导航系统、姿态与航向参考系统或惯性导航增强型全球导航卫星系统](../sensor/inertial_navigation_systems.md)的一部分而存在。
|
||||
- Gyroscopes are present as part of an [external INS, AHRS or INS-enhanced GNSS system](../sensor/inertial_navigation_systems.md).
|
||||
|
||||
在首次使用载具之前必须校准加速计：
|
||||
|
||||
|
||||
@@ -9,6 +9,7 @@ However PX4 can also use some INS devices as either sources of raw data, or as a
|
||||
INS systems that can be used as a replacement for EKF2 in PX4:
|
||||
|
||||
- [InertialLabs](../sensor/inertiallabs.md)
|
||||
- [SBG Systems](../sensor/sbgecom.md): IMU/AHRS, GNSS/INS, Dual GNSS/INS systems that can be used as an external INS or as a source of raw sensor data.
|
||||
- [VectorNav](../sensor/vectornav.md): IMU/AHRS, GNSS/INS, Dual GNSS/INS systems that can be used as an external INS or as a source of raw sensor data.
|
||||
|
||||
## PX4 Firmware
|
||||
|
||||
@@ -0,0 +1,159 @@
|
||||
# SBG Systems INS/AHRS (Pulse, Ellipse, etc.)
|
||||
|
||||
[SBG-Systems](https://www.sbg-systems.com/) designs, manufactures, and support an extensive range of state-of-the-art inertial sensors such as Inertial Measurement Units (IMU), Attitude and Heading Reference Systems (AHRS), Inertial Navigation Systems with embedded GNSS (INS/GNSS), and so on.
|
||||
|
||||
PX4 supports [all SBG Systems products](https://www.sbg-systems.com/products/) and can use these as an [external INS](../sensor/inertial_navigation_systems.md) (bypassing/replacing the EKF2 estimator), or as a source of raw sensor data provided to the navigation estimator.
|
||||
|
||||
|
||||
|
||||
## 综述
|
||||
|
||||
SBG Systems products provide a range of benefits to PX4 users and can be integrated for:
|
||||
|
||||
- Higher accuracy heading, pitch, and roll estimates
|
||||
- More robust and reliable GNSS positioning
|
||||
- Improved positioning and attitude performance in GNSS-contested environments
|
||||
- Performance under challenging dynamic conditions (e.g. catapult launches, VTOL operations, high-g or high angular rate operations)
|
||||
|
||||
The sbgECom PX4 driver is streamlined to provide a simple plug-and-play architecture, removing engineering obstacles and allowing the acceleration of the design, development, and launch of platforms to keep pace with the rapid rate of innovation.
|
||||
|
||||
The driver supports [all SBG Systems products](https://www.sbg-systems.com/products/).
|
||||
In particular the following systems are recommended:
|
||||
|
||||
- **Pulse:** Recommended for fixed-wing systems without hovering, where static heading is not necessary.
|
||||
- **Ellipse:** Recommended for multicopter systems where hovering and low dynamics requires the use of static heading.
|
||||
|
||||
## 购买渠道
|
||||
|
||||
SBG Systems solutions are available directly from [MySBG](https://my.sbg-systems.com) (FR) or through their Global Sales Representatives. For more information on their solutions or for international orders, please contact contact@sbg-systems.com.
|
||||
|
||||
## 硬件安装
|
||||
|
||||
### 布线
|
||||
|
||||
Connect any unused flight controller serial interface, such as a spare `GPS` or `TELEM` port, to the SBG Systems product MAIN port (required by PX4).
|
||||
|
||||
### Mounting
|
||||
|
||||
The SBG Systems product sensor can be mounted in any orientation, in any position on the vehicle, without regard to center of gravity.
|
||||
All SBG Systems product sensors default to a coordinate system of x-forward, y-right, and z-down, making the default mounting as connector-back, base down.
|
||||
This can be changed to any rigid rotation using the sbgECom Reference Frame Rotation register.
|
||||
|
||||
If using a GNSS-enabled product, the GNSS antenna must be mounted rigidly with respect to the inertial sensor and with an unobstructed sky view. If using a dual-GNSS-enabled product (Ellipse-D), the secondary antenna must be mounted rigidly with respect to the primary antenna and the inertial sensor with an unobstructed sky view.
|
||||
|
||||
For more mounting and configuration requirements and recommendations, see the relevant [SBG SUPPORT CENTER](https://support.sbg-systems.com/sc).
|
||||
|
||||
## Firmware Configuration
|
||||
|
||||
### PX4 配置
|
||||
|
||||
To use the sbgECom driver:
|
||||
|
||||
1. Include the module in firmware in the [kconfig board configuration](../hardware/porting_guide_config.md#px4-board-configuration-kconfig) by setting the kconfig variables: `CONFIG_DRIVERS_INS_SBGECOM` or `CONFIG_COMMON_INS`.
|
||||
|
||||
2. [Set the parameter](../advanced_config/parameters.md) [SENS_SBG_CFG](../advanced_config/parameter_reference.md#SENS_SBG_CFG) to the hardware port connected to the SBG Systems product (for more information see [Serial Port Configuration](../peripherals/serial_configuration.md)).
|
||||
|
||||
::: warning
|
||||
Disable or change port of other sensors that are using the same one, for example [GPS_1_CONFIG](../advanced_config/parameter_reference.md#GPS_1_CONFIG) if using GPS1 port.
|
||||
|
||||
:::
|
||||
|
||||
3. Set [SBG_BAUDRATE](../advanced_config/parameter_reference.md#SBG_BAUDRATE) to the desired default baudrate value.
|
||||
|
||||
4. Allow the sbgECom driver to initialize by restarting PX4.
|
||||
|
||||
5. Configure driver to provide IMU data, GNSS data and INS :
|
||||
|
||||
1. Set [SBG_MODE](../advanced_config/parameter_reference.md#SBG_MODE) to the desired mode.
|
||||
2. Make sensor module select sensors by enabling [SENS_IMU_MODE](../advanced_config/parameter_reference.md#SENS_IMU_MODE).
|
||||
3. Prioritize SBG Systems sensors using [CAL_GYROn_PRIO](../advanced_config/parameter_reference.md#CAL_GYRO0_PRIO), [CAL_ACCn_PRIO](../advanced_config/parameter_reference.md#CAL_ACC0_PRIO), [CAL_BAROn_PRIO](../advanced_config/parameter_reference.md#CAL_BARO0_PRIO), [CAL_MAGn_PRIO](../advanced_config/parameter_reference.md#CAL_MAG0_PRIO), where _n_ is the instance number of the IMU component (0, 1, etc.).
|
||||
|
||||
::: tip
|
||||
In most cases the external IMU (SBG) is the highest-numbered.
|
||||
You can get a list of the IMU components available using [`uorb top -1`](../middleware/uorb.md#uorb-top-command), you can differentiate between them using the [`listener`](../modules/modules_command.md#listener) command and looking through the data, or just the rates.
|
||||
|
||||
Alternatively, you can check [CAL_GYROn_ID](../advanced_config/parameter_reference.md#CAL_GYRO0_ID) to see the device id.
|
||||
The priority is 0-255, where 0 is entirely disabled and 255 is highest priority.
|
||||
|
||||
:::
|
||||
|
||||
::: warning
|
||||
When configuring both SBG Systems and Pixhawk sensors to have non-zero priority, if the selected sensor is errored (timeout), it can change during operation without being notified.
|
||||
In this case, MAVLink messages will be updated with the newly selected sensor.
|
||||
|
||||
If you don't want to have this fallback mechanism, you must disable unwanted sensors.
|
||||
|
||||
:::
|
||||
|
||||
4. If using the sbgECom as an INS, disable EKF2 using [EKF2_EN](../advanced_config/parameter_reference.md#EKF2_EN).
|
||||
|
||||
6. Restart PX4.
|
||||
|
||||
Once enabled, the module will be detected on boot.
|
||||
IMU data should be published at 200Hz.
|
||||
|
||||
## SBG Systems Configuration
|
||||
|
||||
All High Performance and Ellipse 3.0 and higher SBG Systems INS can be configured directly from PX4 firmware:
|
||||
|
||||
1. Enable [SBG_CONFIGURATION_EN](../advanced_config/parameter_reference.md#SBG_CONFIGURATION_EN)
|
||||
|
||||
2. Provide a JSON file `sbg_settings.json` containing SBG Systems INS settings to be applied in your PX4 board `extras` directory (ex: `boards/px4/fmu-v5/extras`). The settings JSON file will be installed in `/etc/extras/sbg_settings.json` on the board.
|
||||
|
||||
::: tip
|
||||
The settings can be retrieved using [sbgEComAPI](https://github.com/SBG-Systems/sbgECom/tree/main/tools/sbgEComApi) or [sbgInsRestApi](https://developer.sbg-systems.com/sbgInsRestApi/1.3/#tag/Settings) and then modified as a JSON file.
|
||||
|
||||
:::
|
||||
|
||||
::: tip
|
||||
The settings file can be provided in the SD card in q`/fs/microsd/etc/extras/sbg_settings.json` to avoid rebuilding a new firmware to change JSON settings file.
|
||||
|
||||
:::
|
||||
|
||||
3. For testing purpose, it's also possible to modify SBG Systems INS settings on the fly:
|
||||
|
||||
- By passing a JSON file path as argument when starting sbgecom driver (ex: `sbgecom start -f /fs/microsd/new_sbg_settings.json`)
|
||||
- By passing a JSON string as argument when starting sbgecom driver: (ex: `sbgecom start -s {"output":{"comA":{"messages":{"airData":"onChange"}}}}`)
|
||||
|
||||
For older Ellipse SBG Systems INS or to configure any SBG Systems INS directly, all commands and registers can be found in the [SBG SUPPORT CENTER](https://support.sbg-systems.com/sc).
|
||||
|
||||
:::warning
|
||||
If the baudrate of the serial port on the INS product (used to communicate with PX4) is changed, the parameter [SBG_BAUDRATE](../advanced_config/parameter_reference.md#SBG_BAUDRATE) must be changed to match.
|
||||
:::
|
||||
|
||||
## Published Data
|
||||
|
||||
Upon initialization, the driver should print the following information to console (printed using `PX4_INFO`)
|
||||
|
||||
- Unit model number
|
||||
- Unit hardware version
|
||||
- Unit serial number
|
||||
- Unit firmware number
|
||||
|
||||
This should be accessible using the [`dmesg`](../modules/modules_system.md#dmesg) command.
|
||||
|
||||
The sbgECom driver always publishes the unit's data to the following uORB topics:
|
||||
|
||||
- [sensor_accel](../msg_docs/SensorAccel.md)
|
||||
- [sensor_gyro](../msg_docs/SensorGyro.md)
|
||||
- [sensor_mag](../msg_docs/SensorMag.md)
|
||||
|
||||
if configured as a GNSS, publishes:
|
||||
|
||||
- [sensor_gps](../msg_docs/SensorGps.md)
|
||||
|
||||
and, if configured as an INS, publishes:
|
||||
|
||||
- [estimator_status](../msg_docs/EstimatorStatus.md)
|
||||
- [vehicle_local_position](../msg_docs/VehicleLocalPosition.md)
|
||||
- [vehicle_global_positon](../msg_docs/VehicleGlobalPosition.md)
|
||||
- [vehicle_attitude](../msg_docs/VehicleAttitude.md)
|
||||
|
||||
:::tip
|
||||
Published topics can be viewed using the `listener` command.
|
||||
:::
|
||||
|
||||
## Hardware Specifications
|
||||
|
||||
- [Product Briefs](https://www.sbg-systems.com/products/)
|
||||
- [Datasheets](https://www.sbg-systems.com/contact/#products)
|
||||
@@ -1,6 +1,6 @@
|
||||
# Gazebo Classic Worlds
|
||||
# Gazebo 经典世界
|
||||
|
||||
This topic provides imagery/information about the [Gazebo Classic](../sim_gazebo_classic/index.md) worlds supported by PX4.
|
||||
这个主题提供了 PX4 支持的 [Gazebo Classic](../sim_gazebo_classic/index.md) 世界的图像/信息。
|
||||
|
||||
The [empty.world](#empty_world) is spawned by default, though this may be overridden by a [model specific world](#model_specific_worlds).
|
||||
Developers can also manually specify the world to load: [Gazebo Classic > Loading a Specific World](../sim_gazebo_classic/index.md#loading-a-specific-world).
|
||||
@@ -69,4 +69,4 @@ The model specific worlds are:
|
||||
- [uuv_hippocampus.world](https://github.com/PX4/PX4-SITL_gazebo-classic/blob/main/worlds/uuv_hippocampus.world): An empty world used to simulate an underwater environment for the [HippoCampus UUV](../sim_gazebo_classic/vehicles.md#hippocampus-tuhh-uuv).
|
||||
- [typhoon_h480.world](https://github.com/PX4/PX4-SITL_gazebo-classic/blob/main/worlds/typhoon_h480.world): Used by [Typhoon H480 (Hexrotor)](../sim_gazebo_classic/vehicles.md#typhoon-h480-hexrotor) vehicle model and includes a video widget to enable / disable video streaming.
|
||||
The world includes a gazebo plugin for a simulated camera.
|
||||
- [iris_irlock.world](https://github.com/PX4/PX4-SITL_gazebo-classic/blob/main/worlds/iris_irlock.world): Includes a IR beacon for testing [precision landing](../advanced_features/precland.md).
|
||||
- [iris_irlock.world](https://github.com/PX4/PX4-SITL_gazebo-classic/blob/main/worlds/iris_irlock.world): 包括用于测试[精确着陆]的IR 信标(../advanced_features/precland.md)。
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
This topic outlines the integration tests for the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md).
|
||||
|
||||
These test that mode registration, failsafes, and mode replacement, work as expected.
|
||||
这些测试用于验证模式注册、故障保护（failsafes）和模式替换功能是否按预期工作。
|
||||
|
||||
## CI Testing
|
||||
|
||||
When opening a pull request to PX4, CI runs the library integration tests.
|
||||
向 PX4 提交拉取请求（pull request）时，持续集成（CI）会运行该库的集成测试
|
||||
|
||||
## Running Tests Locally
|
||||
|
||||
|
||||
Reference in New Issue
Block a user