mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-05-10 14:51:15 +08:00
New Crowdin translations - zh-CN (#25590)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
PX4 Build Bot
GitHub
@@ -7,6 +7,7 @@
|
||||
- [位置模式（多旋翼）](flight_modes_mc/position.md)
|
||||
- [Position Slow Mode (MC)](flight_modes_mc/position_slow.md)
|
||||
- [高度模式（多旋翼）](flight_modes_mc/altitude.md)
|
||||
- [Altitude Cruise Mode (MC)](flight_modes_mc/altitude_cruise.md)
|
||||
- [Stabilized Mode (MC)](flight_modes_mc/manual_stabilized.md)
|
||||
- [特技模式（多旋翼）](flight_modes_mc/acro.md)
|
||||
- [环绕模式（多旋翼）](flight_modes_mc/orbit.md)
|
||||
|
||||
@@ -481,11 +481,11 @@ Position, velocity or orientation measurements from an external vision system, e
|
||||
|
||||
The measurements that are fused are configured by setting the appropriate bits of [EKF2_EV_CTRL](../advanced_config/parameter_reference.md#EKF2_EV_CTRL) to `true`:
|
||||
|
||||
- `0`: Horizontal position data
|
||||
- `0`: 水平位置数据
|
||||
- `1`: Vertical position data.
|
||||
Height sources may additionally be configured using [EKF2_HGT_REF](../advanced_config/parameter_reference.md#EKF2_HGT_REF) (see section [Height](#height)).
|
||||
- `2`: Velocity data
|
||||
- `3`: Yaw data
|
||||
- `2`：速度数据
|
||||
- `3`:偏航角数据
|
||||
|
||||
Note that if yaw data is used (bit 3) the heading is with respect to the external vision frame; otherwise the heading is relative to North.
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ The FCs have much the same ports with similar names, and core peripherals are co
|
||||
| Full GPS plus Safety Switch | GPS1 | GPS&SAFETY | Primary GNSS module (GPS, compass, safety switch, buzzer, LED) |
|
||||
| Basic GPS | GPS2 | GPS2 | Secondary GNSS module (GNSS/compass) |
|
||||
| CAN | CAN1/CAN2 | CAN1/CAN2 | DroneCAN devices, such as GNSS modules, motors, etc |
|
||||
| Telemetry | TELEM (1,2,3) | TELEM (1,2,3) | Telemetry radios, companion computers, MAVLink cameras, etc. |
|
||||
| 数传 | TELEM (1,2,3) | TELEM (1,2,3) | Telemetry radios, companion computers, MAVLink cameras, etc. |
|
||||
| Analog Power | POWER (1,2) | POWER (1,2) | SMbus (I2C) power modules |
|
||||
| I2C | I2C | None | Other I2C peripherals |
|
||||
| SPI | SPI | SPI6 | SPI devices (note: 11 pin, not 6 as in standard) |
|
||||
|
||||
@@ -97,13 +97,13 @@ For more information see [Finding/Updating Parameters > Parameters Not In Firmwa
|
||||
|
||||
Four different modes are supported, controlled by the [TRIG_MODE](../advanced_config/parameter_reference.md#TRIG_MODE) parameter:
|
||||
|
||||
| Mode | 描述 |
|
||||
| ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 0 | Camera triggering is disabled. |
|
||||
| 1 | Works like a basic intervalometer that can be enabled and disabled by using the MAVLink command `MAV_CMD_DO_TRIGGER_CONTROL`. See [command interface](#mavlink-command-interface) for more details. |
|
||||
| 2 | Switches the intervalometer constantly on. |
|
||||
| 3 | Triggers based on distance. A shot is taken every time the set horizontal distance is exceeded. The minimum time interval between two shots is however limited by the set triggering interval. |
|
||||
| 4 | Triggers automatically when flying a survey in Mission mode. |
|
||||
| 模式 | 描述 |
|
||||
| -- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 0 | Camera triggering is disabled. |
|
||||
| 1 | Works like a basic intervalometer that can be enabled and disabled by using the MAVLink command `MAV_CMD_DO_TRIGGER_CONTROL`. See [command interface](#mavlink-command-interface) for more details. |
|
||||
| 2 | Switches the intervalometer constantly on. |
|
||||
| 3 | Triggers based on distance. A shot is taken every time the set horizontal distance is exceeded. The minimum time interval between two shots is however limited by the set triggering interval. |
|
||||
| 4 | Triggers automatically when flying a survey in Mission mode. |
|
||||
|
||||
:::info
|
||||
If it is your first time enabling the camera trigger app, remember to reboot after changing the `TRIG_MODE` parameter.
|
||||
|
||||
@@ -95,9 +95,9 @@ mode_req_other # other requirements, not covered above (for external
|
||||
|
||||
If the condition of restriction is not met:
|
||||
|
||||
- arming is not allowed, while the mode is selected
|
||||
- when already armed, the mode cannot be selected
|
||||
- when armed and the mode is selected, the relevant failsafe is triggered (e.g. RC loss for the manual control requirement).
|
||||
- 在选定模式时不允许进行解锁操作
|
||||
- 当已处于武装状态时，该模式无法被选择。
|
||||
- 当载具已解锁且该模式被选中时，相关的故障保护机制会被触发（例如，针对手动控制需求的遥控器信号丢失故障保护）。
|
||||
Check [Safety (Failsafe) Configuration](../config/safety.md) for how to configure failsafe behaviour.
|
||||
|
||||
This is the corresponding flow diagram for the manual control flag (`mode_req_manual_control`):
|
||||
|
||||
@@ -19,7 +19,7 @@ With _VScode_, configuration is stored in the PX4/PX4-Autopilot tree ([PX4-Autop
|
||||
|
||||
You must already have installed the command line [PX4 developer environment](../dev_setup/dev_env.md) for your platform and downloaded the _Firmware_ source code repo.
|
||||
|
||||
## Installation & Setup
|
||||
## 安装与设置
|
||||
|
||||
1. [Download and install VSCode](https://code.visualstudio.com/) (you will be offered the correct version for your OS).
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ Order this module from:
|
||||
- Safety Button
|
||||
- 蜂鸣器
|
||||
- Two Pixhawk Standard CAN Connectors (4 Pin JST GH)
|
||||
- F9P “UART 2” Connector
|
||||
- F9P `UART 2` Connector
|
||||
- 3 Pin JST GH
|
||||
- TX, RX, GND
|
||||
- Pixhawk Standard Debug Connector (6 Pin JST SH)
|
||||
@@ -87,6 +87,25 @@ You need to set necessary [DroneCAN](index.md) parameters and define offsets if
|
||||
- The parameters [EKF2_GPS_POS_X](../advanced_config/parameter_reference.md#EKF2_GPS_POS_X), [EKF2_GPS_POS_Y](../advanced_config/parameter_reference.md#EKF2_GPS_POS_Y) and [EKF2_GPS_POS_Z](../advanced_config/parameter_reference.md#EKF2_GPS_POS_Z) can be set to account for the offset of the ARK RTK GPS from the vehicles centre of gravity.
|
||||
- Set [CANNODE_TERM](../advanced_config/parameter_reference.md#CANNODE_TERM) to `1` on the GPS if this it that last node on the CAN bus.
|
||||
|
||||
### Setting Up Rover and Fixed Base
|
||||
|
||||
Position of the rover is established using RTCM messages from the RTK base module (the base module is connected to QGC, which sends the RTCM information to PX4 via MAVLink).
|
||||
|
||||
PX4 DroneCAN parameters:
|
||||
|
||||
- [UAVCAN_PUB_RTCM](../advanced_config/parameter_reference.md#UAVCAN_PUB_RTCM):
|
||||
- Makes PX4 publish RTCM messages ([RTCMStream](https://dronecan.github.io/Specification/7._List_of_standard_data_types/#rtcmstream)) to the bus (which it gets from the RTK base module via QGC).
|
||||
|
||||
Rover module parameters (also [set using QGC](../dronecan/index.md#qgc-cannode-parameter-configuration)):
|
||||
|
||||
- [CANNODE_SUB_RTCM](../advanced_config/parameter_reference.md#CANNODE_SUB_RTCM) tells the rover that it should subscribe to [RTCMStream](https://dronecan.github.io/Specification/7._List_of_standard_data_types/#rtcmstream) RTCM messages on the bus (from the moving base).
|
||||
|
||||
:::info
|
||||
Use [UAVCAN_PUB_MBD](../advanced_config/parameter_reference.md#UAVCAN_PUB_MBD) and [CANNODE_SUB_MBD](../advanced_config/parameter_reference.md#CANNODE_SUB_MBD) instead if you want to implement moving base (see below) at the same time.
|
||||
:::
|
||||
|
||||
For more information see [Rover and Fixed Base](../dronecan/index.md#rover-and-fixed-base) in the DroneCAN guide.
|
||||
|
||||
### Setting Up Moving Baseline & GPS Heading
|
||||
|
||||
The simplest way to set up moving baseline and GPS heading with two ARK RTK GPS modules is via CAN, though it can be done via UART to reduce traffic on the CAN bus if desired.
|
||||
@@ -128,10 +147,11 @@ Setup via UART:
|
||||
- On the _Moving Base_, set the following:
|
||||
- [GPS_UBX_MODE](../advanced_config/parameter_reference.md#GPS_UBX_MODE) to `2`.
|
||||
|
||||
For more information see [Rover and Moving Base](../dronecan/index.md#rover-and-moving-base) in the DroneCAN guide.
|
||||
|
||||
## LED含义
|
||||
|
||||
- The GPS status lights are located to the right of the connectors
|
||||
|
||||
- Blinking green is GPS fix
|
||||
- Blinking blue is received corrections and RTK Float
|
||||
- Solid blue is RTK Fixed
|
||||
|
||||
@@ -9,3 +9,18 @@ For more information, see the following articles for specific hardware/firmware:
|
||||
- [Vertiq](../peripherals/vertiq.md) (larger modules)
|
||||
- [VESC Project](../peripherals/vesc.md)
|
||||
- [RaccoonLab Cyphal and DroneCAN PWM nodes](raccoonlab_nodes.md)
|
||||
|
||||
## 硬件配置
|
||||
|
||||
General DroneCAN hardware configuration is covered in [DroneCAN > Hardware Setup](../dronecan/index.md#hardware-setup).
|
||||
|
||||
DroneCAN ESCs should be on their own dedicated CAN interface(s) because ESC messages can saturate the bus and starve other nodes of bandwidth.
|
||||
|
||||
## PX4 配置
|
||||
|
||||
DroneCAN peripherals are configured by following the procedure outlined in [DroneCAN](../dronecan/index.md).
|
||||
|
||||
In addition to the general setup, such as setting `UAVCAN_ENABLE` to `3`:
|
||||
|
||||
- Select the specific CAN interface(s) used for ESC data output using the [UAVCAN_ESC_IFACE](../advanced_config/parameter_reference.md#UAVCAN_ESC_IFACE) parameter (all that all interfaces are selected by default).
|
||||
- Configure the [motor order and servo outputs](../config/actuators.md).
|
||||
|
||||
@@ -276,6 +276,9 @@ PX4 DroneCAN parameters:
|
||||
|
||||
[DroneCAN ESCs and servos](../dronecan/escs.md) require the [motor order and servo outputs](../config/actuators.md) to be configured.
|
||||
|
||||
Select the specific CAN interface(s) used for ESC data output using the [UAVCAN_ESC_IFACE](../advanced_config/parameter_reference.md#UAVCAN_ESC_IFACE) parameter (all that all interfaces are selected by default).
|
||||
Note that DroneCAN ESCs should be on their own dedicated CAN interface(s) because ESC messages can saturate the bus and starve other nodes of bandwidth.
|
||||
|
||||
## QGC CANNODE Parameter Configuration
|
||||
|
||||
QGroundControl can inspect and modify parameters belonging to CAN devices attached to the flight controller, provided the device are connected to the flight controller before QGC is started.
|
||||
@@ -313,7 +316,10 @@ If successful, the firmware binary will be removed from the root directory and t
|
||||
|
||||
**Q**: The motors aren't spinning when armed.
|
||||
|
||||
**A**: Make sure `UAVCAN_ENABLE` is set to `3` to enable DroneCAN ESC output.
|
||||
**A**:
|
||||
|
||||
- Make sure `UAVCAN_ENABLE` is set to `3` to enable DroneCAN ESC output.
|
||||
- Make sure `UAVCAN_ESC_IFACE` is set to enable the CAN interface(s) used for ESCs.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ The main hardware documentation is [here](http://mindpx.net/assets/accessories/m
|
||||
| IMU | 10DOF |
|
||||
| IMU isolation | YES/Optional |
|
||||
| Radio Receiver | S.BUS/PPM/DSM/DSM2/DSMX/SUMD |
|
||||
| Telemetry | FrSky<sup>®</sup> D.Port, S.Port, Wifi, 3DR radio |
|
||||
| 数传 | FrSky<sup>®</sup> D.Port, S.Port, Wifi, 3DR radio |
|
||||
| On board TF card for flight data recording | YES |
|
||||
| OneShot ESC Support | YES |
|
||||
| Expansion Slots | 2x7(pin)x2 |
|
||||
|
||||
@@ -40,7 +40,7 @@ This flight controller is [manufacturer supported](../flight_controller/autopilo
|
||||
| microSD Card | [Information on supported cards](../dev_log/logging.md#sd-cards) |
|
||||
| 输入 | GPS/Mag |
|
||||
| | Spektrum |
|
||||
| | Telemetry |
|
||||
| | 数传 |
|
||||
| | CAN bus |
|
||||
| | PPM |
|
||||
| Outputs | 6 LEDs (2xRGB) |
|
||||
|
||||
@@ -67,7 +67,7 @@ This flight controller is [manufacturer supported](../flight_controller/autopilo
|
||||
| microSD Card | [Information on supported cards](../dev_log/logging.md#sd-cards) |
|
||||
| 输入 | GPS/Mag |
|
||||
| | Spektrum |
|
||||
| | Telemetry |
|
||||
| | 数传 |
|
||||
| | CAN bus |
|
||||
| | PPM |
|
||||
| Outputs | 6 LEDs (2xRGB) |
|
||||
|
||||
@@ -17,6 +17,8 @@ Manual-Easy:
|
||||
Airspeed is actively controlled if an airspeed sensor is installed.
|
||||
- [Altitude](../flight_modes_fw/altitude.md) — Easiest and safest _non-GPS_ manual mode.
|
||||
The only difference compared to _Position mode_ is that the pilot always directly controls the roll angle of the plane and there is no automatic course holding.
|
||||
- Altitude Cruise mode — It behaves exactly like _Altitude mode_, with the only difference being that the manual control failsafe can be disabled. This is done by setting the corresponding flag in [COM_RCL_EXCEPT](../advanced_config/parameter_reference.md#COM_RCL_EXCEPT). In that case the current altitude, airspeed and heading (by leveling out the roll angle) are kept until the manual control link is regained or the mode is exited.
|
||||
It is highly recommended to only disable the manual control loss failsafe for this mode if there is a stable data link connection to the vehicle at all times, or to enable the data link loss failsafe through [NAV_DLL_ACT](../advanced_config/parameter_reference.md#NAV_DLL_ACT).
|
||||
- [Stabilized mode](../flight_modes_fw/stabilized.md) — The pilot directly commands the roll and pitch angle and the vehicle keeps the setpoint until the sticks are moved again.
|
||||
Thrust is directly set by the pilot.
|
||||
Turn coordination is still handled by the controller.
|
||||
|
||||
@@ -21,7 +21,7 @@ The diagram below shows the mode behaviour visually (for a [mode 2 transmitter](
|
||||
RC/manual mode like [Stabilized mode](../flight_modes_mc/manual_stabilized.md) but with _altitude stabilization_ (centred sticks level vehicle and hold it to fixed altitude).
|
||||
The horizontal position of the vehicle can move due to wind (or pre-existing momentum).
|
||||
|
||||
- 回正摇杆（内带死区）：
|
||||
- Centered sticks:
|
||||
- RPY摇杆使飞机水平。
|
||||
- 油门（~50%）抗风保持当前姿态。
|
||||
- 外部中心：
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# Altitude Cruise Mode (Multicopter)
|
||||
|
||||
<img src="../../assets/site/difficulty_easy.png" title="Easy to fly" width="30px" /> <img src="../../assets/site/remote_control.svg" title="Manual/Remote control required" width="30px" /> <img src="../../assets/site/altitude_icon.svg" title="Altitude required (e.g. Baro, Rangefinder)" width="30px" />
|
||||
|
||||
_Altitude Cruise mode_ is a _relatively_ easy-to-fly manual control mode in which roll and pitch sticks control vehicle movement in the left-right and forward-back directions (relative to the "front" of the vehicle), yaw stick controls rate of rotation over the horizontal plane, and throttle controls speed of ascent-descent.
|
||||
|
||||
When the sticks are released/centered the vehicle will keep the current tilt and heading angle and maintain the current _altitude_.
|
||||
If moving in the horizontal plane the vehicle will accelerate until the wind resistance equals the acceleration caused by the set tilt angle.
|
||||
The vehicle will then continue to move with a constant velocity (unlike for Altitude mode, in which the vehicle will eventually slow down and stop).
|
||||
If the wind blows the aircraft will drift in the direction of the wind even if flying perfectly level.
|
||||
|
||||
:::tip
|
||||
_Altitude Cruise mode_ is intended for long distance flights where the same tilt angle is kept for a long period of time. It is just like [Altitude](../flight_modes_mc/altitude.md) mode but does not go back to level tilt when the sticks are released.
|
||||
:::
|
||||
|
||||
The diagram below shows the mode behaviour visually (for a [mode 2 transmitter](../getting_started/rc_transmitter_receiver.md#transmitter_modes)).
|
||||
|
||||
|
||||
|
||||
## 技术总结
|
||||
|
||||
A manual mode that is similar to [Altitude mode](../flight_modes_mc/altitude.md) but with different interpretation of roll and pitch sticks.
|
||||
|
||||
- Centered sticks:
|
||||
- Roll/Pitch sticks: the current tilt is kept.
|
||||
- Yaw: the current heading is kept.
|
||||
- Throttle (~50%) holds current altitude.
|
||||
- 外部中心：
|
||||
- Roll/Pitch sticks control the rate of change of the tilt angle, resulting in corresponding left-right and forward-back movement. A maximum stick deflection results in a tilting rate setpoint to go from level to max tilt within 0.5 seconds.
|
||||
- Yaw stick deflection rotates the tilt angle either left or right, causing the vehicle to change course. It is _not_ causing a direct rotation around the body yaw axis like in [Acro mode](../flight_modes_mc/acro.md).
|
||||
- 油门摇杆以预定的最大速率（和其他轴上的移动速度）控制上升速度。
|
||||
- 起飞：
|
||||
- 降落时，如果将油门杆抬高至 62.5%（从油门杆最低开始的整个范围），无人机将起飞。
|
||||
- Manual control input is required (such as RC control, joystick) to enter this mode. Other than in all other manual modes, it's though possible to disable the manual control loss failsafe by setting the corresponding flag in [COM_RCL_EXCEPT](../advanced_config/parameter_reference.md#COM_RCL_EXCEPT). In that case the current altitude, tilt and heading are kept until the manual control link is regained or the mode is exited.
|
||||
It is highly recommended to only disable the manual control loss failsafe for this mode if there is a stable data link connection to the vehicle at all times, and to enable the data link loss failsafe through [NAV_DLL_ACT](../advanced_config/parameter_reference.md#NAV_DLL_ACT).
|
||||
|
||||
## 参数
|
||||
|
||||
Most of the relevant parameters are already covered in the corresponding section in the [Altitude mode](../flight_modes_mc/altitude.md). Here a list of parameters of particular importance for Altitude Cruise.
|
||||
|
||||
| 参数 | 描述 |
|
||||
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| <a id="COM_RCL_EXCEPT"></a>[COM_RCL_EXCEPT](../advanced_config/parameter_reference.md#COM_RCL_EXCEPT) | The manual control failsafe can be disabled for Altitude Cruise by setting the corresponding bit in this parameter. |
|
||||
| <a id="NAV_DLL_ACT"></a>[NAV_DLL_ACT](../advanced_config/parameter_reference.md#NAV_DLL_ACT) | Data link lost failsafe action. Recommended to set if the manual control failsafe is disabled to avoid fly-aways. |
|
||||
| <a id="MPC_MAN_TILT_MAX"></a>[MPC_MAN_TILT_MAX](../advanced_config/parameter_reference.md#MPC_MAN_TILT_MAX) | The maximum tilt angle the vehicle will go to. At max stick deflection, it will take 0.5 seconds from level flight to this tilt angle. |
|
||||
@@ -21,10 +21,12 @@ Manual-Easy:
|
||||
- [Stabilized mode](../flight_modes_mc/manual_stabilized.md) — Releasing the sticks levels and maintains the vehicle horizontal posture (but not altitude or position).
|
||||
The vehicle will continue to move with momentum, and both altitude and horizontal position may be affected by wind.
|
||||
This mode is also used if "Manual mode" is selected in a ground station.
|
||||
- [Altitude Cruise mode](../flight_modes_mc/altitude_cruise.md) — Very similar to _Altitude mode_, with the difference that when the roll and pitch sticks are released the vehicle does not level out but keeps the tilt until further inputs are given.
|
||||
Additionally it is possible to disable the manual control failsafe for this mode, having the vehicle continue on it's set path even if there are no new control inputs.
|
||||
|
||||
Manual-Acrobatic
|
||||
|
||||
- [Acro](../flight_modes_mc/acro.md) — Manual mode for performing acrobatic maneuvers, such as rolls and loops.
|
||||
- [Acro](../flight_modes_mc/acro.md) — Manual mode for performing acrobatic manoeuvrers, such as rolls and loops.
|
||||
Releasing the sticks stops the vehicle rotating in the roll, pitch, yaw axes, but does not otherwise stabilise the vehicle.
|
||||
|
||||
Autonomous:
|
||||
|
||||
@@ -31,7 +31,7 @@ Throttle is rescaled (see [below](#params)) and passed directly to control alloc
|
||||
自动驾驶仪控制着飞机的姿态角，这意味着当 RC 摇杆居中时自驾仪调整飞机的滚转和俯仰角为零（从而实现飞机姿态的改平）。
|
||||
自动驾驶仪不能补偿由于风（或其他来源）引起的漂移。
|
||||
|
||||
- 回正摇杆（内带死区）：
|
||||
- Centered sticks:
|
||||
- Roll/Pitch sticks level vehicle.
|
||||
- 外部中心：
|
||||
- Roll/Pitch sticks control tilt angle in those orientations, resulting in corresponding left-right and forward-back movement.
|
||||
|
||||
@@ -43,7 +43,7 @@ While very rare on a well calibrated vehicle, sometimes there may be problems wi
|
||||
遥控模式下，横滚、俯仰、油门 (RPT) 杆控制相应轴/方向的运动。
|
||||
摇杆居中使机体水平并将其保持在固定的高度和位置并抗风。
|
||||
|
||||
- Centered roll, pitch, throttle sticks (within RC deadzone [MPC_HOLD_DZ](../advanced_config/parameter_reference.md#MPC_HOLD_DZ)) hold x, y, z position steady against any disturbance like wind.
|
||||
- Centered roll, pitch, throttle sticks (within RC deadzone [MAN_DEADZONE](#MAN_DEADZONE)) hold x, y, z position steady against any disturbance like wind.
|
||||
- 外部中心：
|
||||
- Roll/Pitch sticks control horizontal acceleration over ground in the vehicle's left-right and forward-back directions (respectively).
|
||||
- Throttle stick controls speed of ascent-descent.
|
||||
@@ -62,7 +62,7 @@ All the parameters in the [Multicopter Position Control](../advanced_config/para
|
||||
|
||||
| 参数 | 描述 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| <a id="MPC_HOLD_DZ"></a>[MPC_HOLD_DZ](../advanced_config/parameter_reference.md#MPC_HOLD_DZ) | 启用位置保持的摇杆死区。 默认值：0.1（摇杆全行程的 10％）。 |
|
||||
| <a id="MAN_DEADZONE"></a>[MAN_DEADZONE](../advanced_config/parameter_reference.md#MAN_DEADZONE) | 启用位置保持的摇杆死区。 默认值：0.1（摇杆全行程的 10％）。 |
|
||||
| <a id="MPC_Z_VEL_MAX_UP"></a>[MPC_Z_VEL_MAX_UP](../advanced_config/parameter_reference.md#MPC_Z_VEL_MAX_UP) | 最大垂直上升速度。 默认：3m/s。 |
|
||||
| <a id="MPC_Z_VEL_MAX_DN"></a>[MPC_Z_VEL_MAX_DN](../advanced_config/parameter_reference.md#MPC_Z_VEL_MAX_DN) | 最大垂直下降速度。 默认：1m/s。 |
|
||||
| <a id="MPC_LAND_ALT1"></a>[MPC_LAND_ALT1](../advanced_config/parameter_reference.md#MPC_LAND_ALT1) | 触发第一阶段降速的高度。 Below this altitude descending velocity gets limited to a value between [MPC_Z_VEL_MAX_DN](#MPC_Z_VEL_MAX_DN) (or `MPC_Z_V_AUTO_DN`) and [MPC_LAND_SPEED](#MPC_LAND_SPEED). Value needs to be higher than [MPC_LAND_ALT2](#MPC_LAND_ALT2). Default 10m. |
|
||||
|
||||
@@ -12,7 +12,7 @@ Selecting any other mode than those listed below will either stop the rover or c
|
||||
|
||||
## Manual Modes
|
||||
|
||||
| Mode | 描述 |
|
||||
| 模式 | 描述 |
|
||||
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [Manual](manual.md#manual-mode) | No autopilot support. User is responsible for keeping the rover on the desired course and maintaining speed and rate of turn. |
|
||||
| [Acro](manual.md#acro-mode) | + Maintains the yaw rate (feels more like driving a car than manual mode). <br>+ Allows maximum yaw rate to be limited (protects against roll over). |
|
||||
@@ -21,7 +21,7 @@ Selecting any other mode than those listed below will either stop the rover or c
|
||||
|
||||
## Auto Modes
|
||||
|
||||
| Mode | 描述 |
|
||||
| 模式 | 描述 |
|
||||
| ------------------------------- | --------------------------------------------------------------------------------------- |
|
||||
| [Mission](auto.md#mission-mode) | Automatic mode that causes the vehicle to execute a predefined mission. |
|
||||
| [Return](auto.md#return-mode) | Automatic mode that returns the vehicle to the launch position. |
|
||||
|
||||
@@ -14,7 +14,7 @@ The sticks provide the same "high level" control effects over direction and rate
|
||||
|
||||
The manual modes provide progressively increasing levels of autopilot support for maintaining a course, speed, and rate of turn, compensating for external factors such as slopes or uneven terrain.
|
||||
|
||||
| Mode | 描述 |
|
||||
| 模式 | 描述 |
|
||||
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [Manual](manual.md#manual-mode) | No autopilot support. User is responsible for keeping the rover on the desired course and maintaining speed and rate of turn. |
|
||||
| [Acro](manual.md#acro-mode) | + Maintains the yaw rate (feels more like driving a car than manual mode). <br>+ Allows maximum yaw rate to be limited (protects against roll over). |
|
||||
@@ -24,7 +24,7 @@ The manual modes provide progressively increasing levels of autopilot support fo
|
||||
:::details
|
||||
Overview mode mapping to control effect
|
||||
|
||||
| Mode | Speed | Turning | Required measurements |
|
||||
| 模式 | Speed | Turning | Required measurements |
|
||||
| ------------------------------ | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
|
||||
| [Manual](#manual-mode) | Directly map stick input to motor command. | Directly map stick input to steering angle/speed difference. | None. |
|
||||
| [Acro](#acro-mode) | Directly map stick input to motor command. | Stick input creates a yaw rate setpoint for the control system to regulate. | yaw rate. |
|
||||
|
||||
@@ -21,7 +21,7 @@ The supported frames can be seen in [Airframes Reference > Rover](../airframes/a
|
||||
|
||||
## Ackermann
|
||||
|
||||
<Badge type="tip" text="PX4 v1.16" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
An Ackermann rover controls its direction by pointing the front wheels in the direction of travel — the [Ackermann steering geometry](https://en.wikipedia.org/wiki/Ackermann_steering_geometry) compensates for the fact that wheels on the inside and outside of the turn move at different rates.
|
||||
This kind of steering is used on most commercial vehicles, including cars, trucks etc.
|
||||
@@ -34,7 +34,7 @@ PX4 does not require that the vehicle uses the Ackermann geometry and will work
|
||||
|
||||
## Differential
|
||||
|
||||
<Badge type="tip" text="PX4 v1.16" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
A differential rover's motion is controlled using a differential drive mechanism, where the left and right wheel speeds are adjusted independently to achieve the desired forward speed and yaw rate.
|
||||
Forward motion is achieved by driving both wheels at the same speed in the same direction.
|
||||
@@ -48,7 +48,7 @@ The differential setup also work for rovers with skid or tank steering.
|
||||
|
||||
## Mecanum
|
||||
|
||||
<Badge type="tip" text="PX4 v1.16" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
A Mecanum rover is a type of mobile robot that uses Mecanum wheels to achieve omnidirectional movement. These wheels are unique because they have rollers mounted at a 45-degree angle around their circumference, allowing the rover to move not only forward and backward but also side-to-side and diagonally without needing to rotate first.
|
||||
Each wheel is driven by its own motor, and by controlling the speed and direction of each motor, the rover can move in any direction or spin in place.
|
||||
|
||||
@@ -65,7 +65,7 @@ PX4 Micro XRCE-DDS Client is based on version `v2.x` which is not compatible wit
|
||||
On Ubuntu you can build from source and install the Agent standalone using the following commands:
|
||||
|
||||
```sh
|
||||
git clone -b v2.4.2 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
|
||||
git clone -b v2.4.3 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
|
||||
cd Micro-XRCE-DDS-Agent
|
||||
mkdir build
|
||||
cd build
|
||||
@@ -126,7 +126,7 @@ To build the agent within ROS:
|
||||
|
||||
```sh
|
||||
cd ~/px4_ros_uxrce_dds_ws/src
|
||||
git clone -b v2.4.2 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
|
||||
git clone -b v2.4.3 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
|
||||
```
|
||||
|
||||
3. Source the ROS 2 development environment, and compile the workspace using `colcon`:
|
||||
@@ -279,6 +279,9 @@ The configuration can be done using the [UXRCE-DDS parameters](../advanced_confi
|
||||
- [UXRCE_DDS_SYNCT](../advanced_config/parameter_reference.md#UXRCE_DDS_SYNCT): Bridge time synchronization enable.
|
||||
The uXRCE-DDS client module can synchronize the timestamp of the messages exchanged over the bridge.
|
||||
This is the default configuration. In certain situations, for example during [simulations](../ros2/user_guide.md#ros-gazebo-and-px4-time-synchronization), this feature may be disabled.
|
||||
- [`UXRCE_DDS_NS_IDX`](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX): Index-based namespace definition
|
||||
Setting this parameter to any value other than `-1` creates a namespace with the prefix `uav_` and the specified value, e.g. `uav_0`, `uav_1`, etc.
|
||||
See [namespace](#customizing-the-namespace) for methods to define richer or arbitrary namespaces.
|
||||
|
||||
:::info
|
||||
Many ports are already have a default configuration.
|
||||
@@ -354,7 +357,7 @@ Therefore,
|
||||
|
||||
## Customizing the Namespace
|
||||
|
||||
Custom topic and service namespaces can be applied at build time (changing [dds_topics.yaml](../middleware/dds_topics.md)) or at runtime (which is useful for multi vehicle operations):
|
||||
Custom topic and service namespaces can be applied at build time (changing [dds_topics.yaml](../middleware/dds_topics.md)), at runtime, or through a parameter (which is useful for multi vehicle operations):
|
||||
|
||||
- One possibility is to use the `-n` option when starting the [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) from command line.
|
||||
This technique can be used both in simulation and real vehicles.
|
||||
@@ -383,6 +386,22 @@ will generate topics under the namespaces:
|
||||
|
||||
:::
|
||||
|
||||
- A simple index-based namespace can be applied by setting the parameter [`UXRCE_DDS_NS_IDX`](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) to a value between 0 and 9999.
|
||||
This will generate a namespace such as `/uav_0`, `/uav_1`, and so on.
|
||||
This technique is ideal if vehicles must be persistently associated with namespaces because their clients are automatically started through PX4.
|
||||
|
||||
:::info
|
||||
PX4 parameters cannot carry rich text strings.
|
||||
Therefore, you cannot use [`UXRCE_DDS_NS_IDX`](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) to automatically start a client with an arbitrary message namespace through PX4.
|
||||
You can however specify a namespace when starting the client, using the `-n` argument:
|
||||
|
||||
```sh
|
||||
# In etc/extras.txt on the MicroSD card
|
||||
uxrce_dds_client start -n fancy_uav
|
||||
```
|
||||
|
||||
This can be included in `etc/extras.txt` as part of a custom [System Startup](../concept/system_startup.md).
|
||||
|
||||
## PX4 ROS 2 QoS Settings
|
||||
|
||||
PX4 QoS settings for publishers are incompatible with the default QoS settings for ROS 2 subscribers.
|
||||
@@ -516,7 +535,7 @@ For a list of services, details and examples see the [service documentation](../
|
||||
These guidelines explain how to migrate from using PX4 v1.13 [Fast-RTPS](../middleware/micrortps.md) middleware to PX4 v1.14 `uXRCE-DDS` middleware.
|
||||
These are useful if you have [ROS 2 applications written for PX4 v1.13](https://docs.px4.io/v1.13/en/ros/ros2_comm.html), or you have used Fast-RTPS to interface your applications to PX4 [directly](https://docs.px4.io/v1.13/en/middleware/micrortps.html#agent-in-an-offboard-fast-dds-interface-ros-independent).
|
||||
|
||||
:::info
|
||||
::: info
|
||||
This section contains migration-specific information.
|
||||
You should also read the rest of this page to properly understand uXRCE-DDS.
|
||||
:::
|
||||
|
||||
@@ -125,6 +125,31 @@ ilabs <command> [arguments...]
|
||||
status Print driver status
|
||||
```
|
||||
|
||||
## sbgecom
|
||||
|
||||
Source: [drivers/ins/sbgecom](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/ins/sbgecom)
|
||||
|
||||
Description du module
|
||||
|
||||
### Usage {#sbgecom_usage}
|
||||
|
||||
```
|
||||
sbgecom <command> [arguments...]
|
||||
Commands:
|
||||
start Start driver
|
||||
[-d <val>] Serial device
|
||||
default: /dev/ttyS0
|
||||
[-b <val>] Baudrate device
|
||||
default: 921600
|
||||
[-f <val>] Config JSON file path
|
||||
default: /etc/extras/sbg_settings\.json
|
||||
[-s <val>] Config JSON string
|
||||
|
||||
status Driver status
|
||||
|
||||
stop Stop driver
|
||||
```
|
||||
|
||||
## vectornav
|
||||
|
||||
Source: [drivers/ins/vectornav](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/ins/vectornav)
|
||||
|
||||
@@ -140,9 +140,9 @@ commander <command> [arguments...]
|
||||
transition VTOL transition
|
||||
|
||||
mode Change flight mode
|
||||
manual|acro|offboard|stabilized|altctl|posctl|position:slow|auto:mission|au
|
||||
to:loiter|auto:rtl|auto:takeoff|auto:land|auto:precland|ext1
|
||||
Flight mode
|
||||
manual|acro|offboard|stabilized|altctl|posctl|altitude_cruise|position:slow
|
||||
|auto:mission|auto:loiter|auto:rtl|auto:takeoff|auto:land|auto:
|
||||
precland|ext1 Flight mode
|
||||
|
||||
pair
|
||||
|
||||
@@ -154,6 +154,9 @@ commander <command> [arguments...]
|
||||
|
||||
lat|lon|alt Origin latitude longitude altitude
|
||||
|
||||
set_heading Set current heading
|
||||
heading degrees from True North [0 360]
|
||||
|
||||
poweroff Power off board (if supported)
|
||||
|
||||
stop
|
||||
@@ -1062,7 +1065,9 @@ uxrce_dds_client <command> [arguments...]
|
||||
values: <IP>
|
||||
[-p <val>] Agent listening port. If not provided, defaults to
|
||||
UXRCE_DDS_PRT
|
||||
[-n <val>] Client DDS namespace
|
||||
[-n <val>] Client DDS namespace. If not provided but UXRCE_DDS_NS_IDX is
|
||||
between 0 and 9999 inclusive, then uav_ + UXRCE_DDS_NS_IDX will
|
||||
be used
|
||||
|
||||
stop
|
||||
|
||||
|
||||
@@ -18,11 +18,11 @@ 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
|
||||
|
||||
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 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)
|
||||
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)
|
||||
|
||||
```
|
||||
|
||||
@@ -19,6 +19,6 @@ 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.
|
||||
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.
|
||||
|
||||
```
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ArmingCheckReply (UORB message)
|
||||
|
||||
Arming check reply.
|
||||
Arming check reply
|
||||
|
||||
This is a response to an ArmingCheckRequest message sent by the FMU to an external component, such as a ROS 2 navigation mode.
|
||||
The response contains the current set of external mode requirements, and a queue of events indicating recent failures to set the mode (which the FMU may then forward to a ground station).
|
||||
@@ -12,7 +12,7 @@ The message is not used by internal/FMU components, as their mode requirements a
|
||||
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/ArmingCheckReply.msg)
|
||||
|
||||
```c
|
||||
# Arming check reply.
|
||||
# Arming check reply
|
||||
#
|
||||
# This is a response to an ArmingCheckRequest message sent by the FMU to an external component, such as a ROS 2 navigation mode.
|
||||
# The response contains the current set of external mode requirements, and a queue of events indicating recent failures to set the mode (which the FMU may then forward to a ground station).
|
||||
@@ -25,33 +25,33 @@ 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).
|
||||
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_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
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ArmingCheckRequest (UORB message)
|
||||
|
||||
Arming check request.
|
||||
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.
|
||||
@@ -12,7 +12,7 @@ The reply will also include the registration_id for each external component, pro
|
||||
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/ArmingCheckRequest.msg)
|
||||
|
||||
```c
|
||||
# Arming check request.
|
||||
# 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.
|
||||
@@ -23,10 +23,10 @@ The reply will also include the registration_id for each external component, pro
|
||||
|
||||
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)
|
||||
uint32 valid_registrations_mask # [-] Bitmask of valid registration ID's (the bit is also cleared if flagged as unresponsive)
|
||||
|
||||
```
|
||||
|
||||
@@ -16,76 +16,77 @@ Battery instance information is also logged and streamed in MAVLink telemetry.
|
||||
# Battery instance information is also logged and streamed in MAVLink telemetry.
|
||||
|
||||
uint32 MESSAGE_VERSION = 1
|
||||
uint8 MAX_INSTANCES = 4
|
||||
uint8 MAX_INSTANCES = 3
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
bool connected # Whether or not a battery is connected. For power modules this is based on a voltage threshold.
|
||||
float32 voltage_v # [V] [@invalid 0] Battery voltage
|
||||
float32 current_a # [A] [@invalid -1] Battery current
|
||||
float32 current_average_a # [A] [@invalid -1] Battery current average (for FW average in level flight)
|
||||
float32 discharged_mah # [mAh] [@invalid -1] Discharged amount
|
||||
float32 remaining # [@range 0,1] [@invalid -1] Remaining capacity
|
||||
float32 scale # [@range 1,] [@invalid -1] Scaling factor to compensate for lower actuation power caused by voltage sag
|
||||
float32 time_remaining_s # [s] [@invalid NaN] Predicted time remaining until battery is empty under previous averaged load
|
||||
float32 temperature # [°C] [@invalid NaN] Temperature of the battery
|
||||
uint8 cell_count # [@invalid 0] Number of cells
|
||||
uint64 timestamp # [us] Time since system start
|
||||
|
||||
bool connected # Whether or not a battery is connected. For power modules this is based on a voltage threshold.
|
||||
float32 voltage_v # [V] [@invalid 0] Battery voltage
|
||||
float32 current_a # [A] [@invalid -1] Battery current
|
||||
float32 current_average_a # [A] [@invalid -1] Battery current average (for FW average in level flight)
|
||||
float32 discharged_mah # [mAh] [@invalid -1] Discharged amount
|
||||
float32 remaining # [@range 0,1] [@invalid -1] Remaining capacity
|
||||
float32 scale # [-] [@range 1,] [@invalid -1] Scaling factor to compensate for lower actuation power caused by voltage sag
|
||||
float32 time_remaining_s # [s] [@invalid NaN] Predicted time remaining until battery is empty under previous averaged load
|
||||
float32 temperature # [°C] [@invalid NaN] Temperature of the battery
|
||||
uint8 cell_count # [-] [@invalid 0] Number of cells
|
||||
|
||||
|
||||
uint8 source # [@enum SOURCE] Battery source
|
||||
uint8 SOURCE_POWER_MODULE = 0 # Power module
|
||||
uint8 SOURCE_EXTERNAL = 1 # External
|
||||
uint8 SOURCE_ESCS = 2 # ESCs
|
||||
uint8 source # [@enum SOURCE] Battery source
|
||||
uint8 SOURCE_POWER_MODULE = 0 # Power module
|
||||
uint8 SOURCE_EXTERNAL = 1 # External
|
||||
uint8 SOURCE_ESCS = 2 # ESCs
|
||||
|
||||
uint8 priority # Zero based priority is the connection on the Power Controller V1..Vn AKA BrickN-1
|
||||
uint16 capacity # [mAh] Capacity of the battery when fully charged
|
||||
uint16 cycle_count # Number of discharge cycles the battery has experienced
|
||||
uint16 average_time_to_empty # [minutes] Predicted remaining battery capacity based on the average rate of discharge
|
||||
uint16 manufacture_date # Manufacture date, part of serial number of the battery pack. Formatted as: Day + Month×32 + (Year–1980)×512
|
||||
uint16 state_of_health # [%] [@range 0, 100] State of health. FullChargeCapacity/DesignCapacity
|
||||
uint16 max_error # [%] [@range 1, 100] Max error, expected margin of error in the state-of-charge calculation
|
||||
uint8 id # ID number of a battery. Should be unique and consistent for the lifetime of a vehicle. 1-indexed
|
||||
uint16 interface_error # Interface error counter
|
||||
uint8 priority # [-] Zero based priority is the connection on the Power Controller V1..Vn AKA BrickN-1
|
||||
uint16 capacity # [mAh] Capacity of the battery when fully charged
|
||||
uint16 cycle_count # [-] Number of discharge cycles the battery has experienced
|
||||
uint16 average_time_to_empty # [minutes] Predicted remaining battery capacity based on the average rate of discharge
|
||||
uint16 manufacture_date # [-] Manufacture date, part of serial number of the battery pack. Formatted as: Day + Month×32 + (Year–1980)×512
|
||||
uint16 state_of_health # [%] [@range 0, 100] State of health. FullChargeCapacity/DesignCapacity
|
||||
uint16 max_error # [%] [@range 1, 100] Max error, expected margin of error in the state-of-charge calculation
|
||||
uint8 id # [-] ID number of a battery. Should be unique and consistent for the lifetime of a vehicle. 1-indexed
|
||||
uint16 interface_error # [-] Interface error counter
|
||||
|
||||
float32[14] voltage_cell_v # [V] [@invalid 0] Battery individual cell voltages
|
||||
float32 max_cell_voltage_delta # Max difference between individual cell voltages
|
||||
float32[14] voltage_cell_v # [V] [@invalid 0] Battery individual cell voltages
|
||||
float32 max_cell_voltage_delta # [V] Max difference between individual cell voltages
|
||||
|
||||
bool is_powering_off # Power off event imminent indication, false if unknown
|
||||
bool is_required # Set if the battery is explicitly required before arming
|
||||
bool is_powering_off # Power off event imminent indication, false if unknown
|
||||
bool is_required # Set if the battery is explicitly required before arming
|
||||
|
||||
uint8 warning # [@enum WARNING STATE] Current battery warning
|
||||
uint8 WARNING_NONE = 0 # No battery low voltage warning active
|
||||
uint8 WARNING_LOW = 1 # Low voltage warning
|
||||
uint8 WARNING_CRITICAL = 2 # Critical voltage, return / abort immediately
|
||||
uint8 WARNING_EMERGENCY = 3 # Immediate landing required
|
||||
uint8 WARNING_FAILED = 4 # Battery has failed completely
|
||||
uint8 STATE_UNHEALTHY = 6 # Battery is diagnosed to be defective or an error occurred, usage is discouraged / prohibited. Possible causes (faults) are listed in faults field
|
||||
uint8 STATE_CHARGING = 7 # Battery is charging
|
||||
uint8 warning # [@enum WARNING STATE] Current battery warning
|
||||
uint8 WARNING_NONE = 0 # No battery low voltage warning active
|
||||
uint8 WARNING_LOW = 1 # Low voltage warning
|
||||
uint8 WARNING_CRITICAL = 2 # Critical voltage, return / abort immediately
|
||||
uint8 WARNING_EMERGENCY = 3 # Immediate landing required
|
||||
uint8 WARNING_FAILED = 4 # Battery has failed completely
|
||||
uint8 STATE_UNHEALTHY = 6 # Battery is diagnosed to be defective or an error occurred, usage is discouraged / prohibited. Possible causes (faults) are listed in faults field
|
||||
uint8 STATE_CHARGING = 7 # Battery is charging
|
||||
|
||||
uint16 faults # [@enum FAULT] Smart battery supply status/fault flags (bitmask) for health indication
|
||||
uint8 FAULT_DEEP_DISCHARGE = 0 # Battery has deep discharged
|
||||
uint8 FAULT_SPIKES = 1 # Voltage spikes
|
||||
uint8 FAULT_CELL_FAIL= 2 # One or more cells have failed
|
||||
uint8 FAULT_OVER_CURRENT = 3 # Over-current
|
||||
uint8 FAULT_OVER_TEMPERATURE = 4 # Over-temperature
|
||||
uint8 FAULT_UNDER_TEMPERATURE = 5 # Under-temperature fault
|
||||
uint8 FAULT_INCOMPATIBLE_VOLTAGE = 6 # Vehicle voltage is not compatible with this battery (batteries on same power rail should have similar voltage)
|
||||
uint8 FAULT_INCOMPATIBLE_FIRMWARE = 7 # Battery firmware is not compatible with current autopilot firmware
|
||||
uint8 FAULT_INCOMPATIBLE_MODEL = 8 # Battery model is not supported by the system
|
||||
uint8 FAULT_HARDWARE_FAILURE = 9 # Hardware problem
|
||||
uint8 FAULT_FAILED_TO_ARM = 10 # Battery had a problem while arming
|
||||
uint8 FAULT_COUNT = 11 # Counter. Keep this as last element
|
||||
uint16 faults # [@enum FAULT] Smart battery supply status/fault flags (bitmask) for health indication
|
||||
uint8 FAULT_DEEP_DISCHARGE = 0 # Battery has deep discharged
|
||||
uint8 FAULT_SPIKES = 1 # Voltage spikes
|
||||
uint8 FAULT_CELL_FAIL= 2 # One or more cells have failed
|
||||
uint8 FAULT_OVER_CURRENT = 3 # Over-current
|
||||
uint8 FAULT_OVER_TEMPERATURE = 4 # Over-temperature
|
||||
uint8 FAULT_UNDER_TEMPERATURE = 5 # Under-temperature fault
|
||||
uint8 FAULT_INCOMPATIBLE_VOLTAGE = 6 # Vehicle voltage is not compatible with this battery (batteries on same power rail should have similar voltage)
|
||||
uint8 FAULT_INCOMPATIBLE_FIRMWARE = 7 # Battery firmware is not compatible with current autopilot firmware
|
||||
uint8 FAULT_INCOMPATIBLE_MODEL = 8 # Battery model is not supported by the system
|
||||
uint8 FAULT_HARDWARE_FAILURE = 9 # Hardware problem
|
||||
uint8 FAULT_FAILED_TO_ARM = 10 # Battery had a problem while arming
|
||||
uint8 FAULT_COUNT = 11 # Counter. Keep this as last element
|
||||
|
||||
float32 full_charge_capacity_wh # [Wh] Compensated battery capacity
|
||||
float32 remaining_capacity_wh # [Wh] Compensated battery capacity remaining
|
||||
uint16 over_discharge_count # Number of battery overdischarge
|
||||
float32 nominal_voltage # [V] Nominal voltage of the battery pack
|
||||
float32 full_charge_capacity_wh # [Wh] Compensated battery capacity
|
||||
float32 remaining_capacity_wh # [Wh] Compensated battery capacity remaining
|
||||
uint16 over_discharge_count # [-] Number of battery overdischarge
|
||||
float32 nominal_voltage # [V] Nominal voltage of the battery pack
|
||||
|
||||
float32 internal_resistance_estimate # [Ohm] Internal resistance per cell estimate
|
||||
float32 ocv_estimate # [V] Open circuit voltage estimate
|
||||
float32 ocv_estimate_filtered # [V] Filtered open circuit voltage estimate
|
||||
float32 volt_based_soc_estimate # [@range 0, 1] Normalized volt based state of charge estimate
|
||||
float32 voltage_prediction # [V] Predicted voltage
|
||||
float32 prediction_error # [V] Prediction error
|
||||
float32 estimation_covariance_norm # Norm of the covariance matrix
|
||||
float32 internal_resistance_estimate # [Ohm] Internal resistance per cell estimate
|
||||
float32 ocv_estimate # [V] Open circuit voltage estimate
|
||||
float32 ocv_estimate_filtered # [V] Filtered open circuit voltage estimate
|
||||
float32 volt_based_soc_estimate # [-] [@range 0, 1] Normalized volt based state of charge estimate
|
||||
float32 voltage_prediction # [V] Predicted voltage
|
||||
float32 prediction_error # [V] Prediction error
|
||||
float32 estimation_covariance_norm # [-] Norm of the covariance matrix
|
||||
|
||||
```
|
||||
|
||||
@@ -52,7 +52,9 @@ uint8 CS_SYNTHETIC_MAG_Z = 25 # 25 - true when we are using a synthesized measur
|
||||
uint8 CS_VEHICLE_AT_REST = 26 # 26 - true when the vehicle is at rest
|
||||
uint8 CS_GPS_YAW_FAULT = 27 # 27 - true when the GNSS heading has been declared faulty and is no longer being used
|
||||
uint8 CS_RNG_FAULT = 28 # 28 - true when the range finder has been declared faulty and is no longer being used
|
||||
uint8 CS_GNSS_VEL = 44 # 44 - true if GNSS velocity measurements are being fused
|
||||
uint8 CS_GNSS_VEL = 44 # 44 - true if GNSS velocity measurement fusion is intended
|
||||
uint8 CS_GNSS_FAULT = 45 # 45 - true if GNSS measurements have been declared faulty and are no longer used
|
||||
uint8 CS_YAW_MANUAL = 46 # 46 - true if yaw has been set manually
|
||||
|
||||
uint32 filter_fault_flags # Bitmask to indicate EKF internal faults
|
||||
# 0 - true if the fusion of the magnetometer X-axis has encountered a numerical error
|
||||
|
||||
@@ -54,7 +54,8 @@ bool cs_valid_fake_pos # 41 - true if a valid constant position is bein
|
||||
bool cs_constant_pos # 42 - true if the vehicle is at a constant position
|
||||
bool cs_baro_fault # 43 - true when the current baro has been declared faulty and is no longer being used
|
||||
bool cs_gnss_vel # 44 - true if GNSS velocity measurement fusion is intended
|
||||
bool cs_yaw_manual # 45 - true if yaw has been set manually
|
||||
bool cs_gnss_fault # 45 - true if GNSS measurements have been declared faulty and are no longer used
|
||||
bool cs_yaw_manual # 46 - true if yaw has been set manually
|
||||
|
||||
# fault status
|
||||
uint32 fault_status_changes # number of filter fault status (fs) changes
|
||||
|
||||
@@ -7,11 +7,11 @@ Pure pursuit status
|
||||
```c
|
||||
# Pure pursuit status
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 lookahead_distance # [m] [@range 0, inf] Lookahead distance of pure the pursuit controller
|
||||
float32 target_bearing # [rad] [@range -pi, pi] [@frame NED] Target bearing calculated by the pure pursuit controller
|
||||
float32 crosstrack_error # [m] [@range -inf (Left of the path), inf (Right of the path)] Shortest distance from the vehicle to the path
|
||||
float32 distance_to_waypoint # [m] [@range -inf, inf]Distance from the vehicle to the current waypoint
|
||||
float32 bearing_to_waypoint # [rad] [@range -pi, pi] [@frame NED]Bearing towards current waypoint
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 lookahead_distance # [m] [@range 0, inf] Lookahead distance of pure the pursuit controller
|
||||
float32 target_bearing # [rad] [@range -pi, pi] [@frame NED] Target bearing calculated by the pure pursuit controller
|
||||
float32 crosstrack_error # [m] [@range -inf (Left of the path), inf (Right of the path)] Shortest distance from the vehicle to the path
|
||||
float32 distance_to_waypoint # [m] [@range -inf, inf]Distance from the vehicle to the current waypoint
|
||||
float32 bearing_to_waypoint # [rad] [@range -pi, pi] [@frame NED]Bearing towards current waypoint
|
||||
|
||||
```
|
||||
|
||||
@@ -7,7 +7,7 @@ Rover Attitude Setpoint
|
||||
```c
|
||||
# Rover Attitude Setpoint
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 yaw_setpoint # [rad] [@range -inf, inf] [@frame NED] Yaw setpoint
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 yaw_setpoint # [rad] [@range -inf, inf] [@frame NED] Yaw setpoint
|
||||
|
||||
```
|
||||
|
||||
@@ -7,8 +7,8 @@ Rover Attitude Status
|
||||
```c
|
||||
# Rover Attitude Status
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 measured_yaw # [rad] [@range -pi, pi] [@frame NED]Measured yaw
|
||||
float32 adjusted_yaw_setpoint # [rad] [@range -pi, pi] [@frame NED] Yaw setpoint that is being tracked (Applied slew rates)
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 measured_yaw # [rad] [@range -pi, pi] [@frame NED]Measured yaw
|
||||
float32 adjusted_yaw_setpoint # [rad] [@range -pi, pi] [@frame NED] Yaw setpoint that is being tracked (Applied slew rates)
|
||||
|
||||
```
|
||||
|
||||
@@ -7,11 +7,11 @@ Rover Position Setpoint
|
||||
```c
|
||||
# Rover Position Setpoint
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32[2] position_ned # [m] [@range -inf, inf] [@frame NED] Target position
|
||||
float32[2] start_ned # [m] [@range -inf, inf] [@frame NED] [@invalid NaN Defaults to vehicle position] Start position which specifies a line for the rover to track
|
||||
float32 cruising_speed # [m/s] [@range 0, inf] [@invalid NaN Defaults to maximum speed] Cruising speed
|
||||
float32 arrival_speed # [m/s] [@range 0, inf] [@invalid NaN Defaults to 0] Speed the rover should arrive at the target with
|
||||
float32 yaw # [rad] [@range -pi,pi] [@frame NED] [@invalid NaN Defaults to vehicle yaw] Mecanum only: Specify vehicle yaw during travel
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32[2] position_ned # [m] [@range -inf, inf] [@frame NED] Target position
|
||||
float32[2] start_ned # [m] [@range -inf, inf] [@frame NED] [@invalid NaN Defaults to vehicle position] Start position which specifies a line for the rover to track
|
||||
float32 cruising_speed # [m/s] [@range 0, inf] [@invalid NaN Defaults to maximum speed] Cruising speed
|
||||
float32 arrival_speed # [m/s] [@range 0, inf] [@invalid NaN Defaults to 0] Speed the rover should arrive at the target with
|
||||
float32 yaw # [rad] [@range -pi,pi] [@frame NED] [@invalid NaN Defaults to vehicle yaw] Mecanum only: Specify vehicle yaw during travel
|
||||
|
||||
```
|
||||
|
||||
@@ -7,7 +7,7 @@ Rover Rate setpoint
|
||||
```c
|
||||
# Rover Rate setpoint
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 yaw_rate_setpoint # [rad/s] [@range -inf, inf] [@frame NED] Yaw rate setpoint
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 yaw_rate_setpoint # [rad/s] [@range -inf, inf] [@frame NED] Yaw rate setpoint
|
||||
|
||||
```
|
||||
|
||||
@@ -7,9 +7,9 @@ Rover Rate Status
|
||||
```c
|
||||
# Rover Rate Status
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 measured_yaw_rate # [rad/s] [@range -inf, inf] [@frame NED] Measured yaw rate
|
||||
float32 adjusted_yaw_rate_setpoint # [rad/s] [@range -inf, inf] [@frame NED] Yaw rate setpoint that is being tracked (Applied slew rates)
|
||||
float32 pid_yaw_rate_integral # [] [@range -1, 1] Integral of the PID for the closed loop yaw rate controller
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 measured_yaw_rate # [rad/s] [@range -inf, inf] [@frame NED] Measured yaw rate
|
||||
float32 adjusted_yaw_rate_setpoint # [rad/s] [@range -inf, inf] [@frame NED] Yaw rate setpoint that is being tracked (Applied slew rates)
|
||||
float32 pid_yaw_rate_integral # [-] [@range -1, 1] Integral of the PID for the closed loop yaw rate controller
|
||||
|
||||
```
|
||||
|
||||
@@ -7,8 +7,8 @@ Rover Speed Setpoint
|
||||
```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
|
||||
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
|
||||
|
||||
```
|
||||
|
||||
@@ -7,12 +7,12 @@ Rover Velocity Status
|
||||
```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
|
||||
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
|
||||
|
||||
```
|
||||
|
||||
@@ -7,7 +7,7 @@ Rover Steering setpoint
|
||||
```c
|
||||
# Rover Steering setpoint
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 normalized_steering_setpoint # [@range -1 (Left), 1 (Right)] [@frame Body] Ackermann: Normalized steering angle, Differential/Mecanum: Normalized speed difference between the left and right wheels
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 normalized_steering_setpoint # [-] [@range -1 (Left), 1 (Right)] [@frame Body] Ackermann: Normalized steering angle, Differential/Mecanum: Normalized speed difference between the left and right wheels
|
||||
|
||||
```
|
||||
|
||||
@@ -7,8 +7,8 @@ Rover Throttle setpoint
|
||||
```c
|
||||
# Rover Throttle setpoint
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 throttle_body_x # [] [@range -1 (Backwards), 1 (Forwards)] [@frame Body] Throttle setpoint along body X axis
|
||||
float32 throttle_body_y # [] [@range -1 (Left), 1 (Right)] [@frame Body] [@invalid NaN If not mecanum] Mecanum only: Throttle setpoint along body Y axis
|
||||
uint64 timestamp # [us] Time since system start
|
||||
float32 throttle_body_x # [-] [@range -1 (Backwards), 1 (Forwards)] [@frame Body] Throttle setpoint along body X axis
|
||||
float32 throttle_body_y # [-] [@range -1 (Left), 1 (Right)] [@frame Body] [@invalid NaN If not mecanum] Mecanum only: Throttle setpoint along body Y axis
|
||||
|
||||
```
|
||||
|
||||
@@ -96,6 +96,7 @@ uint16 VEHICLE_CMD_REQUEST_CAMERA_INFORMATION = 521 # Request camera information
|
||||
uint16 VEHICLE_CMD_SET_CAMERA_MODE = 530 # Set camera capture mode (photo, video, etc.).
|
||||
uint16 VEHICLE_CMD_SET_CAMERA_ZOOM = 531 # Set camera zoom.
|
||||
uint16 VEHICLE_CMD_SET_CAMERA_FOCUS = 532
|
||||
uint16 VEHICLE_CMD_EXTERNAL_ATTITUDE_ESTIMATE = 620 # Set an external estimate of vehicle attitude in degrees.
|
||||
uint16 VEHICLE_CMD_DO_GIMBAL_MANAGER_PITCHYAW = 1000 # Setpoint to be sent to a gimbal manager to set a gimbal pitch and yaw.
|
||||
uint16 VEHICLE_CMD_DO_GIMBAL_MANAGER_CONFIGURE = 1001 # Gimbal configuration to set which sysid/compid is in primary and secondary control.
|
||||
uint16 VEHICLE_CMD_IMAGE_START_CAPTURE = 2000 # Start image capture sequence.
|
||||
|
||||
@@ -48,7 +48,7 @@ uint8 NAVIGATION_STATE_AUTO_LOITER = 4 # Auto loiter mode
|
||||
uint8 NAVIGATION_STATE_AUTO_RTL = 5 # Auto return to launch mode
|
||||
uint8 NAVIGATION_STATE_POSITION_SLOW = 6
|
||||
uint8 NAVIGATION_STATE_FREE5 = 7
|
||||
uint8 NAVIGATION_STATE_FREE4 = 8
|
||||
uint8 NAVIGATION_STATE_ALTITUDE_CRUISE = 8 # Altitude with Cruise mode
|
||||
uint8 NAVIGATION_STATE_FREE3 = 9
|
||||
uint8 NAVIGATION_STATE_ACRO = 10 # Acro mode
|
||||
uint8 NAVIGATION_STATE_FREE2 = 11
|
||||
|
||||
@@ -16,8 +16,8 @@ Graphs showing how these are used [can be found here](../middleware/uorb_graph.m
|
||||
- [ActuatorMotors](ActuatorMotors.md) — Motor control message
|
||||
- [ActuatorServos](ActuatorServos.md) — Servo control message
|
||||
- [AirspeedValidated](AirspeedValidated.md)
|
||||
- [ArmingCheckReply](ArmingCheckReply.md) — Arming check reply.
|
||||
- [ArmingCheckRequest](ArmingCheckRequest.md) — Arming check request.
|
||||
- [ArmingCheckReply](ArmingCheckReply.md) — Arming check reply
|
||||
- [ArmingCheckRequest](ArmingCheckRequest.md) — Arming check request
|
||||
- [BatteryStatus](BatteryStatus.md) — Battery status
|
||||
- [ConfigOverrides](ConfigOverrides.md) — Configurable overrides by (external) modes or mode executors
|
||||
- [Event](Event.md) — Events interface
|
||||
|
||||
@@ -44,7 +44,9 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
|
||||
|
||||
### Control
|
||||
|
||||
- TBD
|
||||
- Added new flight mode(s): [Altitude Cruise (MC)](../flight_modes_mc/altitude_cruise.md), Altitude Cruise (FW).
|
||||
For fixed-wing the mode behaves the same as Altitude mode but you can disable the manual control loss failsafe. (PX4-Autopilot#25435: Add new flight mode: Altitude Cruise
|
||||
).
|
||||
|
||||
### Estimation
|
||||
|
||||
@@ -72,7 +74,8 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
|
||||
|
||||
### Multi-Rotor
|
||||
|
||||
- TBD
|
||||
- Removed parameters `MPC_{XY/Z/YAW}_MAN_EXPO` and use default value instead, as they were not deemed necessary anymore. ([PX4-Autopilot#25435: Add new flight mode: Altitude Cruise](https://github.com/PX4/PX4-Autopilot/pull/25435)).
|
||||
- Renamed `MPC_HOLD_DZ` to `MAN_DEADZONE` to have it globally available in modes that allow for a dead zone. ([PX4-Autopilot#25435: Add new flight mode: Altitude Cruise](https://github.com/PX4/PX4-Autopilot/pull/25435)).
|
||||
|
||||
### 垂直起降
|
||||
|
||||
|
||||
@@ -7,13 +7,13 @@ ROS 2 是ROS (机器人操作系统)最新版本 ， 一个通用的机器人库
|
||||
PX4开发团队强烈建议您使用/迁移到此版本的 ROS！
|
||||
|
||||
这是最新版本的 [ROS](https://www.ros.org/) (机器人操作系统)。
|
||||
它大大改进了外空军备竞赛“1”，尤其是允许与PX4更深、更低的延迟结合。
|
||||
它大大改进了ROS1，特别是允许与PX4更深、更低的延迟结合。
|
||||
:::
|
||||
|
||||
ROS得益于一个活跃的生态系统，在这个生态系统里，开发者会解决常见的机器人问题，他们也有权使用为Linux编写的其他软件库。
|
||||
例如，它可以用于[计算机视图](../computer_vision/index.md)解决方案。
|
||||
ROS得益于一个活跃的生态系统，在这个生态系统里，开发者会解决常见的机器人问题，他们也为Linux编写软件库。
|
||||
例如，它可以用于[计算机视觉](../computer_vision/index.md)解决方案。
|
||||
|
||||
ROS 2能够非常深入地与 PX4 集成 只要你可以在交战规则2中创建无法与内部的 PX4 模式区分的飞行模式， 并以高费率直接读取内部uORB主题。
|
||||
ROS 2深度与 PX4 集成， 在某种程度上，您能够在 ROS 2 中创建与内部 PX4 模式无法区分的飞行模式， 并高效率的直接订阅uORB内部的话题。
|
||||
建议（尤其是）从同伴计算机进行控制和通信，因为这种计算机的延迟率很低。 当利用来自Linux的现有库时，或在编写新的高层飞行模式时。
|
||||
|
||||
ROS 2 和 PX4 之间的通信使用中间件实现[XRCE-DDS] (../middleware/uxrce_dds.md)。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 使用 ROS 2 进行多车辆仿真
|
||||
# 使用 ROS 2 进行多车辆模拟
|
||||
|
||||
[XRCE-DDS](../middleware/uxrce_dds.md) 支持多个客户端通过 UDP 协议连接到同一个代理。
|
||||
这在模拟中特别有用，因为只有一个代理需要启动。
|
||||
@@ -8,7 +8,7 @@
|
||||
唯一的要求是
|
||||
|
||||
- 能够在不依赖 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）
|
||||
- 能够在单一车辆仿真中使用ROS 2（机器人操作系统 2）
|
||||
|
||||
## 工作原理
|
||||
|
||||
@@ -51,4 +51,4 @@ PX4 只在他们的 `target_system` 字段为 0 (路由通信) 或与 `MAV_SYS_I
|
||||
在所有其他情况下，信息都被忽视。
|
||||
因此，当 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.
|
||||
例如，若你想向 px4_instance=2 的第三台飞行器发送指令，则需要在所有 VehicleCommand消息中设置 target_system=3。
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
示例将首先发送设置点、进入offboard模式、解锁、起飞至5米，并悬停等待。
|
||||
虽然简单，但它显示了如何使用offboard控制以及如何向无人机发送指令。
|
||||
|
||||
It has been tested on Ubuntu 20.04 with ROS 2 Foxy and PX4 v1.14.
|
||||
该内容已在搭载 ROS 2 Foxy 与 PX4 v1.14 的 Ubuntu 20.04 系统上完成测试。
|
||||
|
||||
:::warning
|
||||
_Offboard_ control is dangerous.
|
||||
@@ -13,22 +13,22 @@ _Offboard_ control is dangerous.
|
||||
:::
|
||||
|
||||
:::info
|
||||
ROS and PX4 make a number of different assumptions, in particular with respect to [frame conventions](../ros/external_position_estimation.md#reference-frames-and-ros).
|
||||
ROS 与 PX4 存在若干不同的预设（假设），尤其是在坐标系约定（[frame conventions]）方面../ros/external_position_estimation.md#reference-frames-and-ros
|
||||
当主题发布或订阅时，坐标系类型之间没有隐含转换！
|
||||
|
||||
这个例子按照PX4的定义在NED坐标系下发布位置。
|
||||
To subscribe to data coming from nodes that publish in a different frame (for example the ENU, which is the standard frame of reference in ROS/ROS 2), use the helper functions in the [frame_transforms](https://github.com/PX4/px4_ros_com/blob/main/src/lib/frame_transforms.cpp) library.
|
||||
这个例子按照PX4的预期在NED坐标系下发布位置。
|
||||
若要订阅来自在不同框架内发布的节点的数据(例如ENU, 这是ROS/ROS 2中的标准参考框架，使用 [frame_transforms](https://github.com/PX4/px4_ros_com/blob/main/src/lib/frame_transforms.cpp)库中的辅助函数。
|
||||
:::
|
||||
|
||||
## 尝试一下
|
||||
## 小試身手
|
||||
|
||||
Follow the instructions in [ROS 2 User Guide](../ros2/user_guide.md) to install PX and run the simulator, install ROS 2, and start the XRCE-DDS Agent.
|
||||
请遵循 ROS 2 用户指南 （../ros2/user_guide.md）中的说明，完成安装 PX4和运行模拟器，安装 ROS 2和启动 XRCE-DDS 代理（Agent）。
|
||||
|
||||
After that we can follow a similar set of steps to those in [ROS 2 User Guide > Build ROS 2 Workspace](../ros2/user_guide.md#build-ros-2-workspace) to run the example.
|
||||
之后，我们可参照 ROS 2 用户指南 > 构建 ROS 2 工作空间 （../ros2/user_guide.md#build-ros-2-workspace）中的相似的步骤来运行这个例子。
|
||||
|
||||
:::tip
|
||||
Make sure that QGC is connected to PX4 before running the ROS 2 node.
|
||||
This is needed because, by default, you cannot arm a vehicle without a connection to ground station (QGC) or an established RC connection (this ensures there is always the option to regain manual control).
|
||||
运行 ROS 2 节点前，请确保 QGC已连接到 PX4。
|
||||
之所以需要这样做，是因为默认情况下，若未连接地面控制站（QGC）或已建立的RC连接，飞行器无法解锁（这一机制可确保始终存在重新获得手动控制权的途径）。
|
||||
:::
|
||||
|
||||
构建并运行示例：
|
||||
@@ -42,14 +42,14 @@ This is needed because, by default, you cannot arm a vehicle without a connectio
|
||||
cd ~/ws_offboard_control/src/
|
||||
```
|
||||
|
||||
3. Clone the [px4_msgs](https://github.com/PX4/px4_msgs) repo to the `/src` directory (this repo is needed in every ROS 2 PX4 workspace!):
|
||||
3. 将 px4_msgs 代码仓库克隆到 /src 目录下（每个 ROS 2 PX4 工作空间都需要该仓库！）：
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
# checkout the matching release branch if not using PX4 main.
|
||||
#若未使用 PX4 的 main 分支，请切换到对应的发布分支
|
||||
```
|
||||
|
||||
4. Clone the example repository [px4_ros_com](https://github.com/PX4/px4_ros_com) to the `/src` directory:
|
||||
4. 将示例代码仓库 px4_ros_com （https://github.com/PX4/px4_ros_com）克隆到 /src 目录下：
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
@@ -83,7 +83,7 @@ This is needed because, by default, you cannot arm a vehicle without a connectio
|
||||
|
||||
::::
|
||||
|
||||
6. Source the `local_setup.bash`:
|
||||
6. 来源 `local_setup.bash`：
|
||||
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
@@ -99,81 +99,81 @@ This is needed because, by default, you cannot arm a vehicle without a connectio
|
||||
|
||||
## 实现
|
||||
|
||||
The source code of the offboard control example can be found in [PX4/px4_ros_com](https://github.com/PX4/px4_ros_com) in the directory [/src/examples/offboard/offboard_control.cpp](https://github.com/PX4/px4_ros_com/blob/main/src/examples/offboard/offboard_control.cpp).
|
||||
离板控制示例的源代码可以在[ PX4/px4_ros_com ]目录里 [/src/examples/offboard/offboard_control.cpp](https://github.com/PX4/px4_ros_com/blob/main/src/examples/offboard/offboard_control.cpp)中找到 [X4/px4_ros_com](https://github.com/PX4/px4_ros_com)。
|
||||
|
||||
:::info
|
||||
PX4 publishes all the messages used in this example as ROS topics by default (see [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml)).
|
||||
PX4 默认情况下将此示例中使用的所有消息以ROS为话题发布(详见 [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml))。
|
||||
:::
|
||||
|
||||
PX4 requires that the vehicle is already receiving `OffboardControlMode` messages before it will arm in offboard mode, or before it will switch to offboard mode when flying.
|
||||
In addition, PX4 will switch out of offboard mode if the stream rate of `OffboardControlMode` messages drops below approximately 2Hz.
|
||||
PX4 要求，飞行器需先持续接收 OffboardControlMode（离板控制模式）消息，之后才能在离板模式下解锁（arm），或在飞行过程中切换至离板模式。
|
||||
此外，若 OffboardControlMode（离板控制模式）消息的数据流速率降至约 2Hz 以下，PX4 将会退出离板模式。
|
||||
该行为在ROS 2 节点的主循环中实现的，如下所示：
|
||||
|
||||
```cpp
|
||||
auto timer_callback = [this]() -> void {
|
||||
auto timer_callback = [this]() -> void {
|
||||
|
||||
if (offboard_setpoint_counter_ == 10) {
|
||||
// Change to Offboard mode after 10 setpoints
|
||||
this->publish_vehicle_command(VehicleCommand::VEHICLE_CMD_DO_SET_MODE, 1, 6);
|
||||
if (offboard_setpoint_counter_ == 10) {
|
||||
// Change to Offboard mode after 10 setpoints
|
||||
this->publish_vehicle_command(VehicleCommand::VEHICLE_CMD_DO_SET_MODE, 1, 6);
|
||||
|
||||
// Arm the vehicle
|
||||
this->arm();
|
||||
}
|
||||
// Arm the vehicle
|
||||
this->arm();
|
||||
}
|
||||
|
||||
// OffboardControlMode needs to be paired with TrajectorySetpoint
|
||||
publish_offboard_control_mode();
|
||||
publish_trajectory_setpoint();
|
||||
// OffboardControlMode needs to be paired with TrajectorySetpoint
|
||||
publish_offboard_control_mode();
|
||||
publish_trajectory_setpoint();
|
||||
|
||||
// stop the counter after reaching 11
|
||||
if (offboard_setpoint_counter_ < 11) {
|
||||
offboard_setpoint_counter_++;
|
||||
}
|
||||
// stop the counter after reaching 11
|
||||
if (offboard_setpoint_counter_ < 11) {
|
||||
offboard_setpoint_counter_++;
|
||||
}
|
||||
};
|
||||
timer_ = this->create_wall_timer(100ms, timer_callback);
|
||||
timer_ = this->create_wall_timer(100ms, timer_callback);
|
||||
```
|
||||
|
||||
循环运行在一个100毫秒计时器。
|
||||
For the first 10 cycles it calls `publish_offboard_control_mode()` and `publish_trajectory_setpoint()` to send [OffboardControlMode](../msg_docs/OffboardControlMode.md) and [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) messages to PX4.
|
||||
The `OffboardControlMode` messages are streamed so that PX4 will allow arming once it switches to offboard mode, while the `TrajectorySetpoint` messages are ignored (until the vehicle is in offboard mode).
|
||||
在最初的 10 个循环中，它会调用 publish_offboard_control_mode() 和 publish_trajectory_setpoint() 这两个函数，向 PX4 发送 OffboardControlMode（离板控制模式）（../msg_docs/OffboardControlMode.md） 和 TrajectorySetpoint（轨迹设定点）（../msg_docs/TrajectorySetpoint.md） 消息。
|
||||
OffboardControlMode消息会持续发送，以便 PX4 切换到离板模式后允许解锁；而 TrajectorySetpoint消息会被忽略（直到载具处于离板模式）
|
||||
|
||||
After 10 cycles `publish_vehicle_command()` is called to change to offboard mode, and `arm()` is called to arm the vehicle.
|
||||
在飞行器解锁并和切换模式后，它将开始跟踪位置设定值。
|
||||
在每个周期内仍然发送设定值，确保飞行器不会切换出offboard模式。
|
||||
10 个循环后，会调用 publish_vehicle_command() 函数切换至离板模式，并调用 arm() 函数对载具进行解锁。
|
||||
在载具解锁并和切换模式后，它将开始跟踪位置设定值。
|
||||
在每个周期内仍然发送设定值，确保载具不会切换出offboard模式。
|
||||
|
||||
The implementations of the `publish_offboard_control_mode()` and `publish_trajectory_setpoint()` methods are shown below.
|
||||
These publish the [OffboardControlMode](../msg_docs/OffboardControlMode.md) and [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) messages to PX4 (respectively).
|
||||
publish_offboard_control_mode() 和 publish_trajectory_setpoint() 这两个方法的实现代码如下所示。
|
||||
这些方法会分别发布到 PX4 的 [OffboardControlMode](../msg_docs/OffboardControlMode.md和 [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) 消息。
|
||||
|
||||
The `OffboardControlMode` is required in order to inform PX4 of the _type_ of offboard control behing used.
|
||||
Here we're only using _position control_, so the `position` field is set to `true` and all the other fields are set to `false`.
|
||||
OffboardControlMode（离板控制模式）消息是必需的，其作用是告知 PX4 当前所使用的离板控制类型。
|
||||
此处我们仅使用位置控制，因此将 `position` 字段设为`true`，而所有其他字段均设为 `false`。
|
||||
|
||||
```cpp
|
||||
/**
|
||||
* @brief Publish the offboard control mode.
|
||||
* For this example, only position and altitude controls are active.
|
||||
* @short 发布离板控制模式。
|
||||
*在本示例中，仅位置控制和高度控制处于激活状态
|
||||
*/
|
||||
void OffboardControl::publish_offboard_control_mode()
|
||||
{
|
||||
OffboardControlMode msg{};
|
||||
msg.position = true;
|
||||
msg.velocity = false;
|
||||
msg.acceleration = false;
|
||||
无效的离板控制：:publish_offboard_control_mode()
|
||||
Power
|
||||
OffboardControlModel msg{}；
|
||||
msg.position = true；
|
||||
msg.veocity = false；
|
||||
msg. cceleration = false;
|
||||
msg.attitude = false;
|
||||
msg.body_rate = false;
|
||||
msg.thrust_and_torque = false;
|
||||
msg.direct_actuator = false;
|
||||
msg.timestamp = this->get_clock()->now().nanoseconds() / 1000;
|
||||
msg.subust_and_torque = false;
|
||||
msg. irect_actuator = false;
|
||||
msg.timestamp = this->get_clock()->now ().nanoseconds() / 1000;
|
||||
offboard_control_mode_publisher_->publish(msg);
|
||||
}
|
||||
```
|
||||
|
||||
`TrajectorySetpoint` provides the position setpoint.
|
||||
In this case, the `x`, `y`, `z` and `yaw` fields are hardcoded to certain values, but they can be updated dynamically according to an algorithm or even by a subscription callback for messages coming from another node.
|
||||
`TrattorySettpoint` 提供了位置设定点。
|
||||
在这种情况下，`x`、`y`、`z`和`yaw`字段的值是硬编码为特定数值的。 但它们可以根据算法动态更新，甚至可以通过订阅回调函数来从另一个节点进行更新。
|
||||
|
||||
```cpp
|
||||
/**
|
||||
* @brief Publish a trajectory setpoint
|
||||
* For this example, it sends a trajectory setpoint to make the
|
||||
* vehicle hover at 5 meters with a yaw angle of 180 degrees.
|
||||
*@brief 发布轨迹设定点
|
||||
|
||||
在本示例中，该函数会发送一个轨迹设定点，使载具在 5 米高度悬停，并保持 180 度的偏航角。
|
||||
*/
|
||||
void OffboardControl::publish_trajectory_setpoint()
|
||||
{
|
||||
@@ -185,9 +185,9 @@ void OffboardControl::publish_trajectory_setpoint()
|
||||
}
|
||||
```
|
||||
|
||||
The `publish_vehicle_command()` sends [VehicleCommand](../msg_docs/VehicleCommand.md) messages with commands to the flight controller.
|
||||
We use it above to change the mode to offboard mode, and also in `arm()` to arm the vehicle.
|
||||
While we don't call `disarm()` in this example, it is also used in the implementation of that function.
|
||||
`publish_vehicle_command()` 将带有命令的 [VehicleCommand](../msg_docs/VehicleCommand.md)消息发送给载具。
|
||||
我们使用上面的方法将模式切换为 offboard 模式，同时也在 arm() 函数中用它来对载具进行解锁。
|
||||
我们在此示例中不调用 `disarm()` ，但它也用于执行此功能。
|
||||
|
||||
```cpp
|
||||
/**
|
||||
@@ -198,23 +198,23 @@ While we don't call `disarm()` in this example, it is also used in the implement
|
||||
*/
|
||||
void OffboardControl::publish_vehicle_command(uint16_t command, float param1, float param2)
|
||||
{
|
||||
VehicleCommand msg{};
|
||||
msg.param1 = param1;
|
||||
msg.param2 = param2;
|
||||
msg.command = command;
|
||||
msg.target_system = 1;
|
||||
msg.target_component = 1;
|
||||
msg.source_system = 1;
|
||||
msg.source_component = 1;
|
||||
msg.from_external = true;
|
||||
msg.timestamp = this->get_clock()->now().nanoseconds() / 1000;
|
||||
vehicle_command_publisher_->publish(msg);
|
||||
VehicleCommand msg{};
|
||||
msg.param1 = param1;
|
||||
msg.param2 = param2;
|
||||
msg.command = command;
|
||||
msg.target_system = 1;
|
||||
msg.target_component = 1;
|
||||
msg.source_system = 1;
|
||||
msg.source_component = 1;
|
||||
msg.from_external = true;
|
||||
msg.timestamp = this->get_clock()->now().nanoseconds() / 1000;
|
||||
vehicle_command_publisher_->publish(msg);
|
||||
}
|
||||
```
|
||||
|
||||
:::info
|
||||
[VehicleCommand](../msg_docs/VehicleCommand.md) is one of the simplest and most powerful ways to command PX4, and by subscribing to [VehicleCommandAck](../msg_docs/VehicleCommandAck.md) you can also confirm that setting a particular command was successful.
|
||||
The param and command fields map to [MAVLink commands](https://mavlink.io/en/messages/common.html#mav_commands) and their parameter values.
|
||||
[VehicleCommand](../msg_docs/VehicleCommand.md是命令PX4的最简单和最高效的方式之一。 通过订阅 [VehicleCommandAck](../msg_docs/VehicleCommandAck.md)，您也可以确认设置特定命令是否成功。
|
||||
参数字段和 指令字段对应于 [MAVLink commands](https://mavlink.io/en/messages/common.html#mav_commands)以及他们的参数值
|
||||
:::
|
||||
|
||||
## See Also
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,81 +1,82 @@
|
||||
# PX4 ROS 2 Message Translation Node
|
||||
# PX4 ROS 2 消息翻译节点
|
||||
|
||||
<Badge type="tip" text="PX4 v1.16" /> <Badge type="warning" text="Experimental" />
|
||||
<0/> <1/>
|
||||
|
||||
The message translation node allows ROS 2 applications that were compiled against different versions of the PX4 messages to interwork with newer versions of PX4, and vice versa, without having to change either the application or the PX4 side.
|
||||
消息翻译节点允许针对不同版本的 PX4 消息编译的 ROS 2 应用程序与更新版本的 PX4 交互。 反之亦然，而不必更改应用程序或PX4一侧。
|
||||
|
||||
## 综述
|
||||
|
||||
The translation of messages from one definition version to another is possible thanks to the introduction of [message versioning](../middleware/uorb.md#message-versioning).
|
||||
由于引入了[消息版本](../middleware/uorb.md#message-versioning)，将消息从一个定义版本翻译成另一个定义版本是可能的。
|
||||
|
||||
The translation node has access to all message versions previously defined by PX4.
|
||||
It dynamically observes the DDS data space, monitoring the publications, subscriptions and services originating from either PX4 via the [uXRCE-DDS Bridge](../middleware/uxrce_dds.md), or ROS 2 applications.
|
||||
When necessary, it converts messages to the current versions expected by both applications and PX4, ensuring compatibility.
|
||||
翻译节点可以访问之前由 PX4 定义的所有消息版本。
|
||||
它积极观察了光盘系统的数据空间，监测出版物。 通过[uXRCE-DDS桥](../middleware/uxrce_dds.md)或外空委2应用源于PX4的订阅和服务。
|
||||
必要时，它会将消息转换到应用程序和PX4预期的当前版本，确保兼容性。
|
||||
|
||||
|
||||
！[概述ROS 2消息转换节点]
|
||||
(../../assets/middleware/ros2/px4_ros2_interface_lib/translation_node.svg)
|
||||
|
||||
<!-- doc source: ../../assets/middleware/ros2/px4_ros2_interface_lib/translation_node.drawio -->
|
||||
|
||||
To support the coexistence of different versions of the same messages within the ROS 2 domain, the ROS 2 topic-names for publications, subscriptions, and services include their respective message version as a suffix.
|
||||
This naming convention takes the form `<topic_name>_v<version>`, as shown in the diagram above.
|
||||
支持不同版本的同一消息在交战规则2域内共存， 出版、订阅和服务的ROS 2主题名称包括各自的信息版本的后缀。
|
||||
这个命名协议的形式为`<topic_name>_v<version>`。
|
||||
|
||||
## 用法
|
||||
|
||||
### 安装
|
||||
|
||||
The following steps describe how to install and run the translation node on your machine.
|
||||
以下步骤描述如何在您的机器上安装和运行翻译节点。
|
||||
|
||||
1. (Optional) Create a new ROS 2 workspace in which to build the message translation node and its dependencies:
|
||||
1. (可选) 创建一个新的 ROS2 工作空间，用于构建消息翻译节点及其依赖：
|
||||
|
||||
```sh
|
||||
mkdir -p /path/to/ros_ws/src
|
||||
```
|
||||
|
||||
2. Run the following helper script to copy the message definitions and translation node into your ROS workspace directory.
|
||||
2. 运行下面的帮助脚本来复制消息定义并将节点翻译到您的ROS工作区目录。
|
||||
|
||||
```sh
|
||||
cd /path/to/ros_ws
|
||||
/path/to/PX4-Autopilot/Tools/copy_to_ros_ws.sh .
|
||||
```
|
||||
|
||||
3. Build and source the workspace.
|
||||
3. 构建并源自工作区。
|
||||
|
||||
```sh
|
||||
colcon build
|
||||
source /path/to/ros_ws/install/setup.bash
|
||||
```
|
||||
|
||||
4. Finally, run the translation node.
|
||||
4. 最后，运行翻译节点。
|
||||
|
||||
```sh
|
||||
ros2 run translation_node translation_node_bin
|
||||
```
|
||||
|
||||
You should see an output similar to:
|
||||
您应该看到一个相似的输出：
|
||||
|
||||
```sh
|
||||
[INFO] [1734525720.729530513] [translation_node]: Registered pub/sub topics and versions:
|
||||
[INFO] [1734525720.729594413] [translation_node]: Registered services and versions:
|
||||
[INFO] [1734525720.729530513] [translation_node]: 注册的 pub/子主题和版本:
|
||||
[INFO] [1734525720.729594413] [translation_node]: 注册的服务和版本:
|
||||
```
|
||||
|
||||
With the translation node running, any simultaneously running ROS 2 application designed to communicate with PX4 can do so, as long as it uses message versions recognized by the node.
|
||||
The translation node will print a warning if it encounters an unknown topic version.
|
||||
在正在运行翻译节点时，任何同时运行旨在与 PX4 通信的 ROS 2 应用程序都可以这样做。 只要它使用节点承认的消息版本。
|
||||
翻译节点如果遇到未知的主题版本，将打印警告。
|
||||
|
||||
:::info
|
||||
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.
|
||||
在 PX4 修改消息定义和/或翻译节点代码后， 您需要从点2重新运行以上步骤来相应更新您的ROS工作区。
|
||||
:::
|
||||
|
||||
### 在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:
|
||||
开发与 PX4 通信的 ROS 2 应用程序时，不必知道正在使用的消息的特定版本。
|
||||
消息版本可以以如以下方式一般添加到主题名称中：
|
||||
|
||||
:::: tabs
|
||||
|
||||
:::tab C++
|
||||
|
||||
```c++
|
||||
topic_name + "_v" + std::to_string(T::MESSAGE_VERSION)
|
||||
主题名称+ "_v" + std::to_string(T::MESSAGE_VERSION)
|
||||
```
|
||||
|
||||
:::
|
||||
@@ -83,30 +84,30 @@ topic_name + "_v" + std::to_string(T::MESSAGE_VERSION)
|
||||
:::tab Python
|
||||
|
||||
```python
|
||||
topic_name + "_v" + VehicleAttitude.MESSAGE_VERSION
|
||||
主题名称 + "_v" + VehicleAttitude.MESSAGE_VERSION
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
|
||||
where `T` is the message type, e.g. `px4_msgs::msg::VehicleAttitude`.
|
||||
其中‘T’消息类型，例如`px4_msgs::msg::VehicleAttitude`.
|
||||
|
||||
For example, the following implements a minimal subscriber and publisher node that uses two versioned PX4 messages and topics:
|
||||
例如，以下是一个实现最小化订阅者和发布者节点的示例，该节点使用两个带版本的 PX4 消息和主题：
|
||||
|
||||
:::: tabs
|
||||
|
||||
:::tab C++
|
||||
|
||||
```c++
|
||||
#include <string>
|
||||
#include <rclcpp/rclcpp.hpp>
|
||||
#include <px4_msgs/msg/vehicle_command.hpp>
|
||||
#include <px4_msgs/msg/vehicle_attitude.hpp>
|
||||
#include <0>
|
||||
#include <1>
|
||||
#include <2>
|
||||
#include <3>
|
||||
|
||||
// Template function to get the message version suffix
|
||||
// The correct message version is directly inferred from the message defintion
|
||||
template <typename T>
|
||||
template <4>
|
||||
std::string getMessageNameVersion() {
|
||||
if (T::MESSAGE_VERSION == 0) return "";
|
||||
return "_v" + std::to_string(T::MESSAGE_VERSION);
|
||||
@@ -116,13 +117,13 @@ class MinimalPubSub : public rclcpp::Node {
|
||||
public:
|
||||
MinimalPubSub() : Node("minimal_pub_sub") {
|
||||
// Use template function to define the correct topics automatically
|
||||
const std::string sub_topic = "/fmu/out/vehicle_attitude" + getMessageNameVersion<px4_msgs::msg::VehicleAttitude>();
|
||||
const std::string pub_topic = "/fmu/in/vehicle_command" + getMessageNameVersion<px4_msgs::msg::VehicleCommand>();
|
||||
const std::string sub_topic = "/fmu/out/vehicle_attitude" + getMessageNameVersion<5>();
|
||||
const std::string pub_topic = "/fmu/in/vehicle_command" + getMessageNameVersion<6>();
|
||||
|
||||
_subscription = this->create_subscription<px4_msgs::msg::VehicleAttitude>(
|
||||
_subscription = this->create_subscription<5>(
|
||||
sub_topic, 10,
|
||||
std::bind(&MinimalPubSub::attitude_callback, this, std::placeholders::_1));
|
||||
_publisher = this->create_publisher<px4_msgs::msg::VehicleCommand>(pub_topic, 10);
|
||||
_publisher = this->create_publisher<6>(pub_topic, 10);
|
||||
}
|
||||
|
||||
private:
|
||||
@@ -130,8 +131,8 @@ class MinimalPubSub : public rclcpp::Node {
|
||||
RCLCPP_INFO(this->get_logger(), "Received attitude message.");
|
||||
}
|
||||
|
||||
rclcpp::Publisher<px4_msgs::msg::VehicleCommand>::SharedPtr _publisher;
|
||||
rclcpp::Subscription<px4_msgs::msg::VehicleAttitude>::SharedPtr _subscription;
|
||||
rclcpp::Publisher<6>::SharedPtr _publisher;
|
||||
rclcpp::Subscription<5>::SharedPtr _subscription;
|
||||
};
|
||||
```
|
||||
|
||||
@@ -180,34 +181,34 @@ 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`.
|
||||
在 PX4 侧，如果消息定义包含字段`uint32 MESSAGE_VERSION = x`，DDS客户端自动添加版本后缀。
|
||||
|
||||
:::info
|
||||
主题版本0意味着不应添加`_v<version>`后缀。
|
||||
:::
|
||||
|
||||
## Development
|
||||
## 开发
|
||||
|
||||
### Definitions
|
||||
### 定义
|
||||
|
||||
A **message** defines the data format used for communication, whether over a topic or a service.
|
||||
Therefore a message can be either a _topic_ message defined by a `.msg` file, or a _service_ message defined by a `.srv` file.
|
||||
**消息** 定义了用于通信的数据格式，无论是主题还是服务。
|
||||
因此，消息可以是 ".msg" 文件定义的 _topic_ 消息，也可以是 ".srv" 文件定义的 _service_ 消息。
|
||||
|
||||
A **versioned message** is a message for which changes are tracked and each change results in a version bump, with the previous state of the definition being stored in history.
|
||||
The latest version of every message is stored in `msg/versioned/` for topics (or `srv/versioned` for services), and all older versions are stored in `msg/px4_msgs_old/msg/` (or `msg/px4_msgs_old/srv/`).
|
||||
**版本信息** 是指跟踪更改的消息，每次变更都会导致版本号递增，且定义的历史状态会被保存下来。
|
||||
每个消息的最新版本都存储在 `msg/versioned/` 中，用于主题(或`srv/versioned` 用于服务)， 所有旧版本都存储在`msg/px4_msgs_old/msg/`(或`msg/px4_msgs_old/srv/`)中。
|
||||
|
||||
A **version translation** defines a bidirectional mapping of the contents of one or more message definition across different versions.
|
||||
Each translation is stored as a separate `.h` header file under `msg/translation_node/translations/`.
|
||||
Message translations can be either _direct_ or _generic_.
|
||||
**版本翻译**定义了一个或多个消息定义的内容在不同版本之间的双向映射。
|
||||
每个翻译以单独的 .h 头文件形式存储在 msg/translation_node/translations/ 目录下。
|
||||
消息翻译可以是 _direct_或 _generic_。
|
||||
|
||||
- A **direct translation** defines a bidirectional mapping of the contents of a _single_ message between two of its versions.
|
||||
This is the simpler case and should be preferred if possible.
|
||||
- A **generic translation** defines a bidirectional mapping of the contents of `n` input messages to `m` output messages across different versions.
|
||||
This can be used for merging or splitting a message, or when moving a field from one message to another.
|
||||
- **直接翻译** 定义一个双向映射其两个版本之间消息的内容。
|
||||
这是更简单的情况，在可能的情况下应优先选择。
|
||||
- **通用翻译** 定义了双向映射`n`输入消息的内容到不同版本的`m`输出消息。
|
||||
这可用于合并或拆分消息，也可用于将某个字段从一个消息迁移至另一个消息。
|
||||
|
||||
### File Structure
|
||||
|
||||
Starting from PX4 v1.16, the PX4-Autopilot `msg/` and `srv/` directories are structured as follows:
|
||||
从 PX4 v1.16 版本开始，PX4-Autopilot（PX4 自动驾驶系统）的 msg/ 和 srv/ 目录结构如下：
|
||||
|
||||
```
|
||||
PX4-Autopilot
|
||||
@@ -222,15 +223,15 @@ PX4-Autopilot
|
||||
└── versioned/ # Latest versioned service message files
|
||||
```
|
||||
|
||||
This structure introduces new directories: `versioned/`, `px4_msgs_old/`, and `translation_node/`.
|
||||
这个结构引入了新的目录：“versioned/`，`px4_msgs_old/`，以及`translation_node/\`。
|
||||
|
||||
#### Directories `msg/versioned/` and `srv/versioned/`
|
||||
#### 目录`msg/versioned/` 和 `srv/versioned/`
|
||||
|
||||
- Contain the current latest version of each message.
|
||||
- Files in these directories must include a `MESSAGE_VERSION` field to indicate that they are versioned.
|
||||
- File names follow the conventional naming scheme (without a version suffix).
|
||||
- 包含每条消息当前的最新版本。
|
||||
- 这些目录中的文件必须包含 `MESSAGE_VERSION` 字段以表明它们是版本控制。
|
||||
- 文件名遵循常规命名规则（不带版本后缀）。
|
||||
|
||||
Example directory structure:
|
||||
示例目录结构：
|
||||
|
||||
```
|
||||
PX4-Autopilot
|
||||
@@ -244,13 +245,13 @@ PX4-Autopilot
|
||||
└── VehicleCommand.srv # e.g. MESSAGE_VERSION = 2
|
||||
```
|
||||
|
||||
#### Directory `px4_msgs_old/`
|
||||
#### 目录`px4_msgs_old/`
|
||||
|
||||
- Archives the history of all versioned messages, including both topic and service messages (resp. under `msg/` and `srv/` subdirectories).
|
||||
- Each file includes a `MESSAGE_VERSION` field.
|
||||
- File names reflect the message's version with a suffix (e.g., `V1`, `V2`).
|
||||
- 将所有版本信息的历史记录存档，包括主题和服务信息(resp. under `msg/`和`srv/`子目录)。
|
||||
- 每个文件都包含一个 MESSAGE_VERSION 字段。
|
||||
- 文件名反映了带有后缀的消息版本(如：`V1`、`V2`)。
|
||||
|
||||
Example directory structure (matching the example above):
|
||||
示例目录结构(匹配上面的示例)：
|
||||
|
||||
```
|
||||
...
|
||||
@@ -264,13 +265,13 @@ Example directory structure (matching the example above):
|
||||
└── VehicleCommandV1.srv
|
||||
```
|
||||
|
||||
#### Directory `translation_node/`
|
||||
#### 目录`translation_node/`
|
||||
|
||||
- Contains headers for translating between all different versions of messages.
|
||||
- Each translation (direct or generic) is a single `.h` header file.
|
||||
- The header `all_translation.h` acts as the main header, and includes all subsequent translation headers.
|
||||
- 包含用于在所有不同版本的消息之间进行翻译的标题。
|
||||
- 每个翻译 (直接或通用) 都是单个的 `.h` 标题文件。
|
||||
- 标题`all_translation.h`是主标题，包含所有其后的翻译标题。
|
||||
|
||||
Example directory structure (matching the example above):
|
||||
示例目录结构(匹配上面的示例)：
|
||||
|
||||
```
|
||||
...
|
||||
@@ -287,36 +288,36 @@ Example directory structure (matching the example above):
|
||||
└── translation_vehicle_command_v2.h # Direct translation v1 <-> latest (v2)
|
||||
```
|
||||
|
||||
### Updating a Versioned Message
|
||||
### 正在更新版本信息...
|
||||
|
||||
This section provides a step-by-step walkthrough and a basic working example of what the process of changing a versioned message looks like.
|
||||
本节提供了分步操作指南以及一个基础的可运行示例，以展示修改版本化消息的流程具体是怎样的。
|
||||
|
||||
The example describes the process of updating the `VehicleAttitude` message definition to contain an additional `new_field` entry, incrementing the message version from `3` to `4`, and creating a new direct translation in the process.
|
||||
该示例描述了更新VehicleAttitude消息定义的流程，具体包括：为其添加一个额外的new_field字段、将消息版本从3递增至4，并在此过程中创建一个新的直接转换。
|
||||
|
||||
1. **Create an Archived Definition of the Current Versioned Message**
|
||||
1. **创建当前版本信息的存档定义**
|
||||
|
||||
Copy the versioned `.msg` topic message file (or `.srv` service message file) to `px4_msgs_old/msg/` (or `px4_msgs_old/srv/`), and append its message version to the file name.
|
||||
将版本号的`.msg`主题消息文件(或`.srv`服务消息文件)复制到`px4_msgs_old/msg/`(或`px4_msgs_old/srv/`)，并将其消息版本附加到文件名。
|
||||
|
||||
For example:<br>
|
||||
Copy `msg/versioned/VehicleAttitude.msg` → `msg/versioned/px4_msgs_old/msg/VehicleAttitudeV3.msg`
|
||||
例如：<br>
|
||||
复制 `msg/versioned/VehicleAttitude.msg` → `msg/versioned/px4_msgs_old/msg/VehicleAttitudeV3.msg`
|
||||
|
||||
2. **Update Translation References to the Archived Definition**
|
||||
2. **更新对存档定义的转化引用**
|
||||
|
||||
Update the existing translations header files `msg/translation_node/translations/*.h` to reference the newly archived message definition.
|
||||
更新现有翻译标头文件 `msg/translation_node/translations/*.h` 以参考新存档的消息定义。
|
||||
|
||||
For example, update references in those files:<br>
|
||||
例如，更新这些文件中的引用:<br>
|
||||
|
||||
- Replace `px4_msgs::msg::VehicleAttitude` → `px4_msgs_old::msg::VehicleAttitudeV3`
|
||||
- Replace `#include <px4_msgs/msg/vehicle_attitude.hpp>` → `#include <px4_msgs_old/msg/vehicle_attitude_v3.hpp>`
|
||||
- 替换 `px4_msgs::msg::VehicleAttitude` → `px4_msgs_old::msg::VehicleAttitudeV3`
|
||||
- 替换`#include <px4_msgs/msg/vehicle_attitude.hpp>` -> \`#include <px4_msgs_old/msg/vehicle_attitude_v3.hpp>
|
||||
|
||||
3. **Update the Versioned Definition**
|
||||
3. **更新版本定义**
|
||||
|
||||
Update the versioned `.msg` topic message file (or `.srv` service message file) with required changes.
|
||||
更新版本的 `.msg` 主题消息文件 (或`.srv` 服务消息文件) 并进行必要的更改。
|
||||
|
||||
First increment the `MESSAGE_VERSION` field.
|
||||
Then update the message fields that prompted the version change.
|
||||
第一次递增`MESSAGE_VERSION`字段。
|
||||
然后更新促使版本变更的消息字段。
|
||||
|
||||
For example, update `msg/versioned/VehicleAttitude.msg` from:
|
||||
例如，更新 `msg/versioned/vehicleAttitde.msg` 从：
|
||||
|
||||
```txt
|
||||
uint32 MESSAGE_VERSION = 3
|
||||
@@ -324,20 +325,19 @@ The example describes the process of updating the `VehicleAttitude` message defi
|
||||
...
|
||||
```
|
||||
|
||||
to
|
||||
到
|
||||
|
||||
```txt
|
||||
uint32 MESSAGE_VERSION = 4 # Increment
|
||||
uint64 timestamp
|
||||
float32 new_field # Make definition changes
|
||||
...
|
||||
```
|
||||
|
||||
4. **Add a New Translation Header**
|
||||
4. **添加新的翻译标头**
|
||||
|
||||
Add a new version translation to bridge the archived version and the updated current version, by creating a new translation header.
|
||||
通过创建一个新的翻译标头来添加一个新的版本翻译来连接存档版本和更新的当前版本。
|
||||
|
||||
For example, create a direct translation header `translation_node/translations/translation_vehicle_attitude_v4.h`:
|
||||
例如，创建一个直接翻译标题`translation_node/translation_vaille_attitude_v4.h`：
|
||||
|
||||
```c++
|
||||
// Translate VehicleAttitude v3 <--> v4
|
||||
@@ -381,72 +381,70 @@ The example describes the process of updating the `VehicleAttitude` message defi
|
||||
// Discards `new_field` from MessageNewer
|
||||
}
|
||||
};
|
||||
|
||||
REGISTER_TOPIC_TRANSLATION_DIRECT(VehicleAttitudeV4Translation);
|
||||
```
|
||||
|
||||
Version translation templates are provided here:
|
||||
版本翻译模板在此提供：
|
||||
|
||||
- [Direct Topic Message Translation Template](https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/example_translation_direct_v1.h)
|
||||
- [Generic Topic Message Translation Template](https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/example_translation_multi_v2.h)
|
||||
- [Direct Service Message Translation Template](https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/example_translation_service_v1.h)
|
||||
|
||||
5. **Include New Headers in `all_translations.h`**
|
||||
5. **在`all_translations.h`中包含新标头**
|
||||
|
||||
Add all newly created headers to [`translations/all_translations.h`](https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/all_translations.h) so that the translation node can find them.
|
||||
将所有新创建的标题添加到[`translations/all_translations.h`](https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/all_translations.h)，以便翻译节点能够找到它们。
|
||||
|
||||
For example, append the following line to `all_translation.h`:
|
||||
例如，在`all_translation.h`上加上以下一行：
|
||||
|
||||
```c++
|
||||
#include "translation_vehicle_attitude_v4.h"
|
||||
```
|
||||
|
||||
Note that in the example above and in most cases, step 4 only requires the developer to create a direct translation for the definition change.
|
||||
This is because the changes only involved a single message.
|
||||
In more complex cases of splitting, merging and/or moving definitions then a generic translation must be created.
|
||||
请注意，在上述示例中以及在大多数情况下，步骤 4 仅要求开发者针对此次定义变更创建一个直接转换。
|
||||
这是因为更改只涉及一个消息。
|
||||
在更复杂的分割、合并和/或移动定义的情况下，必须创建一个通用转化。
|
||||
|
||||
For example when moving a field from one message to another, a single generic translation should be added with the two older message versions as input, and the two newer versions as output.
|
||||
This ensures there is no information lost when translating forward or backward.
|
||||
例如，当一个字段从一个消息移动到另一个消息时。 应增加一个单一通用翻译，两个较旧的信息版本作为输入，两个较新的版本作为输出。
|
||||
这就确保了在向前或向后翻译时不会丢失信息。
|
||||
|
||||
This is exactly the approach shown by the [Generic Topic Message Translation Template](https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/example_translation_multi_v2.h), omitting only the code for actually modifying fields in the `fromOlder()` and `toOlder()` methods.
|
||||
这正是 [Generic Topic Message Translation Template](https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/example_translation_multi_v2.h) 所显示的方法。 只省略`fromOlder()` 和 `toOlder()` 方法中的字段的代码。
|
||||
|
||||
:::warning
|
||||
If a nested message definition changes, all messages including that message also require a version update.
|
||||
For example this would be the case for message [PositionSetpointTriplet](../msg_docs/PositionSetpointTriplet.md) if it were versioned.
|
||||
This is primarily important for services which are more likely reference other message definitions.
|
||||
如果嵌套消息定义发生了变化，包括该消息在内的所有消息也需要版本更新。
|
||||
例如，如果消息 [PositionSetpointTriplet](../msg_docs/PositionSetpointTriplet.md)有版本，将会出现这种情况。
|
||||
这一点对于服务而言尤为重要，因为服务更有可能引用其他消息定义。
|
||||
:::
|
||||
|
||||
## Implementation Details
|
||||
## 实现细节
|
||||
|
||||
The translation node dynamically monitors the topics and services.
|
||||
It then instantiates the counterside of the publications and subscribers as required.
|
||||
For example if there is an external publisher for version 1 of a topic and subscriber for version 2.
|
||||
转换节点动态监测主题和服务。
|
||||
然后视需要举例说明出版物和订阅者的对应情况。
|
||||
例如，如果主题第1版有外部发行商，第2版则有订阅商。
|
||||
|
||||
Internally, it maintains a graph of all known topic and version tuples (which are the graph nodes).
|
||||
The graph is connected by the message translations.
|
||||
As arbitrary message translations can be registered, the graph can have cycles and multiple paths from one node to another.
|
||||
Therefore on a topic update, the graph is traversed using a shortest path algorithm.
|
||||
When moving from one node to the next, the message translation method is called with the current topic data.
|
||||
If a node contains an instantiated publisher (because it previously detected an external subscriber), the data is published.
|
||||
Thus, multiple subscribers of any version of the topic can be updated with the correct version of the data.
|
||||
在内部，它保存一份所有已知主题和版本管束的图表(即图节点)。
|
||||
该图通过消息转换实现连接。
|
||||
由于任意的消息转换可以注册，图可以有周期和从一个节点到另一个节点的多个路径。
|
||||
因此，在主题更新中，图形使用最短路径算法。
|
||||
当从一个节点移动到另一个节点时，消息翻译方法将与当前主题数据调用。
|
||||
如果节点包含实例化发布器 (因为它先前检测到外部订阅者)，数据将被发布。
|
||||
这样，本专题任何版本的多个订阅者都可以用正确的数据更新数据。
|
||||
|
||||
For translations with multiple input topics, the translation continues once all input messages are available.
|
||||
对于有多个输入主题的转化，转化将在所有输入消息都可用后继续。
|
||||
|
||||
## 局限
|
||||
|
||||
- Translation of service messages does not work on ROS Humble, but does on ROS Jazzy.
|
||||
This is because the current implementation depends on a service API that is not yet available in ROS Humble.
|
||||
Translation of topic messages is fully supported.
|
||||
- Services messages only support a linear history, i.e. no message splitting or merging.
|
||||
- Having both publishers and subscribers for two different versions of the same topic is currently not handled by the translation node and would trigger infinite circular publications.
|
||||
This refers to the following problematic configuration:
|
||||
- 服务消息的转化不适用于 ROS Humble，而是适用于ROSJazzy。
|
||||
这是因为当前的实现取决于尚未在ROS人类中提供的服务 API 。
|
||||
完全支持主题信息转化。
|
||||
- 服务消息只支持线性历史记录，即没有消息拆分或合并。
|
||||
- 两个不同版本的同一主题的出版商和订户目前都不是由转化节点处理的，会引发无限的循环出版物。
|
||||
这是指下列有问题的配置：
|
||||
|
||||
```
|
||||
app 1: pub topic_v1, sub topic_v1
|
||||
app 2: pub topic_v2, sub topic_v2
|
||||
```
|
||||
|
||||
In practice this configuration is unlikely to occur because ROS topics shared with the FMU are intended to be directional (e.g. `/fmu/out/vehicle_status` or `/fmu/in/trajectory_setpoint`), therefore apps typically do not publish and subscribe simultaneously to the same topic.
|
||||
The translation node could be extended to handle this corner-case if required.
|
||||
实际上，这种配置不大可能发生，因为与金融监督单位共享的外空系统专题是指向的(例如)。 `/fmu/out/vehicle_status` 或 `/fmu/in/tracjectory_setpoint` ，因此应用通常不会同时发布和订阅相同的主题。
|
||||
如果需要，可以扩展翻译节点来处理这个卷轴。
|
||||
|
||||
Original document with requirements: https://docs.google.com/document/d/18_RxV1eEjt4haaa5QkFZAlIAJNv9w5HED2aUEiG7PVQ/edit?usp=sharing
|
||||
需要原始文件：https://docs.google.com/document/d/18_RxV1eEjt4haaa5QkFZAlIAJNv9w5HED2aUEiG7PVQ/edit?usp=sharing
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user