fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-04-14 10:07:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

New Crowdin translations - ko (#25659)

Browse Source 
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
PX4 Build Bot 2025-10-01 13:53:06 +10:00 committed by GitHub
parent 4dab1108c3
commit bd71881f8a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
11 changed files with 415 additions and 109 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/ko/SUMMARY.md
View File

@ -436,6 +436,7 @@
- [Attitude Tuning](config_rover/attitude_tuning.md)
- [Velocity Tuning](config_rover/velocity_tuning.md)
- [Position Tuning](config_rover/position_tuning.md)
- [Apps & API](flight_modes_rover/api.md)
- [Complete Vehicles](complete_vehicles_rover/index.md)
- [Aion Robotics R1](complete_vehicles_rover/aion_r1.md)
- [Submarines (experimental)](frames_sub/index.md)
@ -872,6 +873,7 @@
- [PX4 ROS 2 Interface Library](ros2/px4_ros2_interface_lib.md)
- [Control Interface](ros2/px4_ros2_control_interface.md)
- [Navigation Interface](ros2/px4_ros2_navigation_interface.md)
- [Waypoint Missions](ros2/px4_ros2_waypoint_missions.md)
- [ROS 2 Message Translation Node](ros2/px4_ros2_msg_translation_node.md)
- [ROS 1 (Deprecated)](ros/ros1.md)
- [ROS/MAVROS 설치 가이드](ros/mavros_installation.md)

54
docs/ko/debug/failure_injection.md
View File

@ -9,7 +9,7 @@ Failure injection is disabled by default, and can be enabled using the [SYS_FAIL
Failure injection still in development.
At time of writing (PX4 v1.14):
- 시뮬레이션에서만 사용할 수 있습니다(실제 비행에서 실패 주입 모두 지원 예정).
- Support may vary by failure type and between simulatiors and real vehicle.
- It requires support in the simulator.
It is supported in Gazebo Classic
- 많은 실패 유형이 광범위하게 구현되지 않았습니다.
@ -33,31 +33,31 @@ failure <component> <failure_type> [-i <instance_number>]
- _component_:
- 센서:
- `gyro`: Gyro.
- `accel`: Accelerometer.
- `gyro`: Gyroscope
- `accel`: Accelerometer
- `mag`: Magnetometer
- `baro`: Barometer
- `gps`: GPS
- `gps`: Global navigation satellite system
- `optical_flow`: Optical flow.
- `vio`: Visual inertial odometry.
- `vio`: Visual inertial odometry
- `distance_sensor`: Distance sensor (rangefinder).
- `airspeed`: Airspeed sensor.
- `airspeed`: Airspeed sensor
- 시스템:
- `battery`: Battery.
- `motor`: Motor.
- `servo`: Servo.
- `avoidance`: Avoidance.
- `rc_signal`: RC Signal.
- `mavlink_signal`: MAVLink signal (data telemetry).
- `battery`: Battery
- `motor`: Motor
- `servo`: Servo
- `avoidance`: Avoidance
- `rc_signal`: RC Signal
- `mavlink_signal`: MAVLink data telemetry connection
- _failure_type_:
- `ok`: Publish as normal (Disable failure injection).
- `off`: Stop publishing.
- `stuck`: Report same value every time (_could_ indicate a malfunctioning sensor).
- `garbage`: Publish random noise. 초기화되지 않은 메모리를 읽는 것처럼 보입니다.
- `wrong`: Publish invalid values (that still look reasonable/aren't "garbage").
- `slow`: Publish at a reduced rate.
- `delayed`: Publish valid data with a significant delay.
- `intermittent`: Publish intermittently.
- `ok`: Publish as normal (Disable failure injection)
- `off`: Stop publishing
- `stuck`: Constantly report the same value which _can_ happen on a malfunctioning sensor
- `garbage`: Publish random noise. This looks like reading uninitialized memory
- `wrong`: Publish invalid values that still look reasonable/aren't "garbage"
- `slow`: Publish at a reduced rate
- `delayed`: Publish valid data with a significant delay
- `intermittent`: Publish intermittently
- _instance number_ (optional): Instance number of affected sensor.
0 (기본값) 지정된 유형의 모든 센서를 나타냅니다.
@ -65,16 +65,16 @@ failure <component> <failure_type> [-i <instance_number>]
To simulate losing RC signal without having to turn off your RC controller:
1. Enable the parameter [SYS_FAILURE_EN](../advanced_config/parameter_reference.md#SYS_FAILURE_EN).
1. Enable the parameter [SYS_FAILURE_EN](../advanced_config/parameter_reference.md#SYS_FAILURE_EN). And specifically to turn off motors also [CA_FAILURE_MODE](../advanced_config/parameter_reference.md#CA_FAILURE_MODE).
2. Enter the following commands on the MAVLink console or SITL _pxh shell_:
```sh
# Fail RC (turn publishing off)
failure rc_signal off
```sh
# Fail RC (turn publishing off)
failure rc_signal off
# Restart RC publishing
failure rc_signal ok
```
# Restart RC publishing
failure rc_signal ok
```
## MAVSDK 실패 플러그인

128
docs/ko/flight_modes/offboard.md
View File

@ -62,6 +62,11 @@ bool thrust_and_torque
bool direct_actuator
```
:::warning
The following list shows the `OffboardControlMode` options for copter, fixed-wing, and VTOL.
For rovers see the [rover section](#rover).
:::
The fields are ordered in terms of priority such that `position` takes precedence over `velocity` and later fields, `velocity` takes precedence over `acceleration`, and so on.
The first field that has a non-zero value (from top to bottom) defines what valid estimate is required in order to use offboard mode, and the setpoint message(s) that can be used.
For example, if the `acceleration` field is the first non-zero value, then PX4 requires a valid `velocity estimate`, and the setpoint must be specified using the `TrajectorySetpoint` message.
@ -90,20 +95,93 @@ Before using offboard mode with ROS 2, please spend a few minutes understanding
- Velocity setpoint (`velocity` different from `NaN` and `position` set to `NaN`). Non-`NaN` values acceleration are used as feedforward terms for the inner loop controllers.
- Acceleration setpoint (`acceleration` different from `NaN` and `position` and `velocity` set to `NaN`)
- All values are interpreted in NED (Nord, East, Down) coordinate system and the units are \[m\], \[m/s\] and \[m/s^2\] for position, velocity and acceleration, respectively.
- All values are interpreted in NED (Nord, East, Down) coordinate system and the units are `[m]`, `[m/s]` and `[m/s^2]` for position, velocity and acceleration, respectively.
- [px4_msgs::msg::VehicleAttitudeSetpoint](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/VehicleAttitudeSetpoint.msg)
- The following input combination is supported:
- quaternion `q_d` + thrust setpoint `thrust_body`.
Non-`NaN` values of `yaw_sp_move_rate` are used as feedforward terms expressed in Earth frame and in \[rad/s\].
Non-`NaN` values of `yaw_sp_move_rate` are used as feedforward terms expressed in Earth frame and in `[rad/s]`.
- The quaternion represents the rotation between the drone body FRD (front, right, down) frame and the NED frame. The thrust is in the drone body FRD frame and expressed in normalized \[-1, 1\] values.
- The quaternion represents the rotation between the drone body FRD (front, right, down) frame and the NED frame.
The thrust is in the drone body FRD frame and expressed in normalized \[-1, 1\] values.
- [px4_msgs::msg::VehicleRatesSetpoint](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/VehicleRatesSetpoint.msg)
- The following input combination is supported:
- `roll`, `pitch`, `yaw` and `thrust_body`.
- All the values are in the drone body FRD frame. The rates are in \[rad/s\] while thrust_body is normalized in \[-1, 1\].
- All the values are in the drone body FRD frame.
The rates are in `[rad/s]` while thrust_body is normalized in `[-1, 1]`.
### 탐사선
Rover modules must set the control mode using `OffboardControlMode` and use the appropriate messages to configure the corresponding setpoints.
The approach is similar to other vehicle types, but the allowed control mode combinations and setpoints are different:
| Category | 사용법 | Setpoints |
| -------------------------------------------------------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| (Recommended) [Rover Setpoints](#rover-setpoints) | General rover control | [RoverPositionSetpoint](../msg_docs/RoverPositionSetpoint.md), [RoverSpeedSetpoint](../msg_docs/RoverSpeedSetpoint.md), [RoverAttitudeSetpoint](../msg_docs/RoverAttitudeSetpoint.md), [RoverRateSetpoint](../msg_docs/RoverRateSetpoint.md), [RoverThrottleSetpoint](../msg_docs/RoverThrottleSetpoint.md), [RoverSteeringSetpoint](../msg_docs/RoverSteeringSetpoint.md) |
| [Actuator Setpoints](#actuator-setpoints) | Direct actuator control | [ActuatorMotors](../msg_docs/ActuatorMotors.md), [ActuatorServos](../msg_docs/ActuatorServos.md) |
| (Deprecated) [Trajectory Setpoint](#deprecated-trajectory-setpoint) | General vehicle control | [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) |
#### Rover Setpoints
The rover modules use a hierarchical structure to propagate setpoints:
![Rover Control Structure](../../assets/middleware/ros2/px4_ros2_interface_lib/rover_control_structure.svg)
The "highest" setpoint that is provided will be used within the PX4 rover modules to generate the setpoints that are below it (overriding them!).
With this hierarchy there are clear rules for providing a valid control input:
- Provide a position setpoint **or**
- One of the setpoints on the "left" (speed **or** throttle) **and** one of the setpoints on the "right" (attitude, rate **or** steering).
All combinations of "left" and "right" setpoints are valid.
The following are all valid setpoint combinations and their respective control flags that must be set through [OffboardControlMode](../msg_docs/OffboardControlMode.md) (set all others to _false_).
Additionally, for some combinations we require certain setpoints to be published with `NAN` values so that the setpoints of interest are not overridden by the rover module (due to the hierarchy above).
&check; are the relevant setpoints we publish, and &cross; are the setpoint that need to be published with `NAN` values.
| Setpoint Combination | Control Flag | [RoverPositionSetpoint](../msg_docs/RoverPositionSetpoint.md) | [RoverSpeedSetpoint](../msg_docs/RoverSpeedSetpoint.md) | [RoverThrottleSetpoint](../msg_docs/RoverThrottleSetpoint.md) | [RoverAttitudeSetpoint](../msg_docs/RoverAttitudeSetpoint.md) | [RoverRateSetpoint](../msg_docs/RoverRateSetpoint.md) | [RoverSteeringSetpoint](../msg_docs/RoverSteeringSetpoint.md) |
| -------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------- |
| Position | position | &check; | | | | | |
| Speed + Attitude | velocity | | &check; | | &check; | | |
| Speed + Rate | velocity | | &check; | | &cross; | &check; | |
| Speed + Steering | velocity | | &check; | | &cross; | &cross; | &check; |
| Throttle + Attitude | attitude | | | &check; | &check; | | |
| Throttle + Rate | body_rate | | | &check; | | &check; | |
| Throttle + Steering | thrust_and_torque | | | &check; | | | &check; |
:::info
If you intend to use the rover setpoints, we recommend using the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) instead since it simplifies the publishing of these setpoints.
:::
#### Actuator Setpoints
Instead of controlling the vehicle using position, speed, rate and other setpoints, you can directly control the motors and actuators using [ActuatorMotors](../msg_docs/ActuatorMotors.md) and [ActuatorServos](../msg_docs/ActuatorServos.md).
In [OffboardControlMode](../msg_docs/OffboardControlMode.md) set `direct_actuator` to _true_ and all other flags to _false_.
:::info
This bypasses the rover modules including any limits on steering rates or accelerations and the inverse kinematics step.
We recommend using [RoverSteeringSetpoint](../msg_docs/RoverSteeringSetpoint.md) and [RoverThrottleSetpoint](../msg_docs/RoverThrottleSetpoint.md) instead for low level control (see [Rover Setpoints](#rover-setpoints)).
:::
#### (Deprecated) Trajectory Setpoint
:::warning
The [Rover Setpoints](#rover-setpoints) are a replacement for the [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) and we highly recommend using those instead as they have a well defined behaviour and offer more flexibility.
:::
The rover modules support the _position_, _velocity_ and _yaw_ fields of the [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md).
However, only one of the fields is active at a time and is defined by the flags of [OffboardControlMode](../msg_docs/OffboardControlMode.md):
| Control Mode Flag | Active Trajectory Setpoint Field |
| ----------------- | -------------------------------- |
| position | position |
| velocity | velocity |
| attitude | yaw |
:::info
Ackermann rovers do not support the yaw setpoint.
:::
### Generic Vehicle
@ -116,8 +194,10 @@ The following offboard control modes bypass all internal PX4 control loops and s
- [px4_msgs::msg::ActuatorMotors](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/ActuatorMotors.msg) + [px4_msgs::msg::ActuatorServos](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/ActuatorServos.msg)
- You directly control the motor outputs and/or servo outputs.
- Currently works at lower level than then `control_allocator` module. Do not publish these messages when not in offboard mode.
- All the values normalized in \[-1, 1\]. For outputs that do not support negative values, negative entries map to `NaN`.
- Currently works at lower level than then `control_allocator` module.
Do not publish these messages when not in offboard mode.
- All the values normalized in `[-1, 1]`.
For outputs that do not support negative values, negative entries map to `NaN`.
- `NaN` maps to disarmed.
## MAVLink Messages
@ -207,41 +287,7 @@ The following MAVLink messages and their particular fields and field values are
### 탐사선
- [SET_POSITION_TARGET_LOCAL_NED](https://mavlink.io/en/messages/common.html#SET_POSITION_TARGET_LOCAL_NED)
- The following input combinations are supported (in `type_mask`): <!-- https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/FlightTasks/tasks/Offboard/FlightTaskOffboard.cpp#L166-L170 -->
- Position setpoint (only `x`, `y`, `z`)
- Specify the _type_ of the setpoint in `type_mask`:
::: info
The _setpoint type_ values below are not part of the MAVLink standard for the `type_mask` field.
::
값들은 다음과 같습니다:
- -12288 : Loiter 설정점 (설정점에 매우 가까워지면 기체는 멈춤).
- Velocity setpoint (only `vx`, `vy`, `vz`)
- PX4 supports the coordinate frames (`coordinate_frame` field): [MAV_FRAME_LOCAL_NED](https://mavlink.io/en/messages/common.html#MAV_FRAME_LOCAL_NED) and [MAV_FRAME_BODY_NED](https://mavlink.io/en/messages/common.html#MAV_FRAME_BODY_NED).
- [SET_POSITION_TARGET_GLOBAL_INT](https://mavlink.io/en/messages/common.html#SET_POSITION_TARGET_GLOBAL_INT)
- The following input combinations are supported (in `type_mask`): <!-- https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/FlightTasks/tasks/Offboard/FlightTaskOffboard.cpp#L166-L170 -->
- Position setpoint (only `lat_int`, `lon_int`, `alt`)
- Specify the _type_ of the setpoint in `type_mask` (not part of the MAVLink standard).
값들은 다음과 같습니다:
- 다음 비트가 설정되지 않으면 정상적인 동작입니다.
- -12288 : Loiter 설정점 (설정점에 매우 가까워지면 기체는 멈춤).
- PX4 supports the coordinate frames (`coordinate_frame` field): [MAV_FRAME_GLOBAL](https://mavlink.io/en/messages/common.html#MAV_FRAME_GLOBAL).
- [SET_ATTITUDE_TARGET](https://mavlink.io/en/messages/common.html#SET_ATTITUDE_TARGET)
- 다음 입력 조합이 지원됩니다.
- Attitude/orientation (`SET_ATTITUDE_TARGET.q`) with thrust setpoint (`SET_ATTITUDE_TARGET.thrust`).
::: info
Only the yaw setting is actually used/extracted.
:::
Rover does not support a MAVLink offboard API (ROS2 is supported).
## 오프보드 매개변수

29
docs/ko/flight_modes_rover/api.md Normal file
View File

@ -0,0 +1,29 @@
# Apps & API
The rover modules have been tested and integrated with a subset of the available [Apps & API](../middleware/index.md) methods.
We specifically provide guides for using [ROS 2](../ros2/index.md) to interface a companion computer with PX4 via [uXRCE-DDS](../middleware/uxrce_dds.md).
| Method | 설명 |
| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [PX4 ROS 2 Interface](#px4-ros-2-interface) (Recommended) | Register a custom mode and publish [RoverSetpointTypes](../ros2/px4_ros2_control_interface.md#rover-setpoints). |
| [ROS 2 Offboard Control](#ros-2-offboard-control) | Use the PX4 internal [Offboard Mode](../flight_modes/offboard.md) and publish messages defined in [dds_topics.yaml](../middleware/dds_topics.md). |
## PX4 ROS 2 Interface
We recommend the use of the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) which allows you to register a custom drive mode and exposes [RoverSetpointTypes](../ros2/px4_ros2_control_interface.md#rover-setpoints).
By using these setpoints (instead of the PX4 internal rover setpoints), you are guaranteed to send valid control inputs to your vehicle and the control flags for the setpoints you are using are automatically set for you.
Registering a custom drive mode instead of using [ROS 2 Offboard Control](#ros-2-offboard-control) additionally provides the advantages listed [here](../concept/flight_modes.md#internal-vs-external-modes).
To get familiar with this method, read through the guide for the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) where we also provide an example app for rover.
## ROS 2 Offboard Control
[ROS 2 Offboard Control](../ros2/offboard_control.md) uses the PX4 internal [Offboard Mode](../flight_modes/offboard.md).
While you can subscribe/publish to all topics specified in [dds_topics.yaml](../middleware/dds_topics.md), not all rover modules support all of these topics (see [Supported Setpoints](../flight_modes/offboard.md#rover)).
Unlike the [RoverSetpointTypes](../ros2/px4_ros2_control_interface.md#rover-setpoints) exposed through the [PX4 ROS 2 Interface](#px4-ros-2-interface), there is no guarantee that the published setpoints lead to a valid control input.
In addition, the correct control mode flags must be set through [OffboardControlMode](../msg_docs/OffboardControlMode.md).
This requires a deeper understanding of PX4 and the structure of the rover modules.
For general information on setting up offboard mode read through [Offboard Mode](../flight_modes/offboard.md) and then consult [Supported Setpoints](../flight_modes/offboard.md#rover).

3
docs/ko/frames_rover/index.md
View File

@ -57,8 +57,9 @@ Each wheel is driven by its own motor, and by controlling the speed and directio
## See Also
- [Drive Modes](../flight_modes_rover/index.md).
- [Drive Modes](../flight_modes_rover/index.md)
- [Configuration/Tuning](../config_rover/index.md)
- [Apps & API](../flight_modes_rover/api.md)
- [Complete Vehicles](../complete_vehicles_rover/index.md)
## 시뮬레이션

2
docs/ko/releases/main.md
View File

@ -67,6 +67,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### uXRCE-DDS / ROS2
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [Fixed Wing lateral/longitudinal setpoint](../ros2/px4_ros2_control_interface.md#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype) (`FwLateralLongitudinalSetpointType`) and [VTOL transitions](../ros2/px4_ros2_control_interface.md#controlling-a-vtol). ([PX4-Autopilot#24056](https://github.com/PX4/PX4-Autopilot/pull/24056)).
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [ROS-based waypoint missions](../ros2/px4_ros2_waypoint_missions.md).
### MAVLink
@ -89,6 +90,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### 탐사선
- Removed deprecated rover module ([PX4-Autopilot#25054](https://github.com/PX4/PX4-Autopilot/pull/25054)).
- Add support for [Apps & API](../flight_modes_rover/api.md) ([PX4-Autopilot#25074](https://github.com/PX4/PX4-Autopilot/pull/25074), [PX4-ROS2-Interface-Lib#140](https://github.com/Auterion/px4-ros2-interface-lib/pull/140)).
### ROS 2

4
docs/ko/ros2/offboard_control.md
View File

@ -1,6 +1,6 @@
# ROS 2 오프보드 제어 예
The following C++ example shows how to do position control in [offboard mode](../flight_modes/offboard.md) from a ROS 2 node.
The following C++ example shows how to do multicopter position control in [offboard mode](../flight_modes/offboard.md) from a ROS 2 node.
The example starts sending setpoints, enters offboard mode, arms, ascends to 5 metres, and waits.
While simple, it shows the main principles of how to use offboard control and how to send vehicle commands.
@ -22,7 +22,7 @@ To subscribe to data coming from nodes that publish in a different frame (for ex
## Trying it out
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.
Follow the instructions in [ROS 2 User Guide](../ros2/user_guide.md) to install PX and run the multicopter simulator, install ROS 2, and start the 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.

37
docs/ko/ros2/px4_ros2_control_interface.md
View File

@ -347,6 +347,7 @@ The following sections provide a list of supported setpoint types:
- [MulticopterGotoSetpointType](#go-to-setpoint-multicoptergotosetpointtype): <Badge type="warning" text="MC only" /> Smooth position and (optionally) heading control
- [FwLateralLongitudinalSetpointType](#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype): <Badge type="warning" text="FW only" /> <Badge type="tip" text="main (planned for: PX4 v1.17)" /> Direct control of lateral and longitudinal fixed wing dynamics
- [DirectActuatorsSetpointType](#direct-actuator-control-setpoint-directactuatorssetpointtype): Direct control of motors and flight surface servo setpoints
- [Rover Setpoints](#rover-setpoints): <Badge type="tip" text="main (planned for: PX4 v1.17)" /> Direct access to rover control setpoints (Position, Speed, Attitude, Rate, Throttle and Steering).
:::tip
The other setpoint types are currently experimental, and can be found in: [px4_ros2/control/setpoint_types/experimental](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/px4_ros2_cpp/include/px4_ros2/control/setpoint_types/experimental).
@ -358,6 +359,8 @@ You can add your own setpoint types by adding a class that inherits from `px4_ro
<Badge type="warning" text="MC only" />
<Badge type="warning" text="Multicopter only" />
:::info
This setpoint type is currently only supported for multicopters.
:::
@ -551,6 +554,40 @@ For example to control a quadrotor, you need to set the first 4 motors according
If you want to control an actuator that does not control the vehicle's motion, but for example a payload servo, see [below](#controlling-an-independent-actuator-servo).
:::
#### Rover Setpoints
<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />
The rover modules use a hierarchical structure to propagate setpoints:
![Rover Control Structure](../../assets/middleware/ros2/px4_ros2_interface_lib/rover_control_structure.svg)
:::info
The "highest" setpoint that is provided will be used within the PX4 rover modules to generate the setpoints that are below it (Overriding them!).
With this hierarchy there are clear rules for providing a valid control input:
- Provide a position setpoint, **or**
- One of the setpoints on the "left" (speed **or** throttle) **and** one of the setpoints on the "right" (attitude, rate **or** steering). All combinations of "left" and "right" setpoints are valid.
For ease of use we expose these valid combinations as new SetpointTypes.
:::
The RoverSetpointTypes exposed through the control interface are combinations of these setpoints that lead to a valid control input:
| SetpointType | Position | Speed | 스로틀 | Attitude | 주파수 | Steering | Control Flags |
| ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------------ |
| [RoverPosition](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverPositionSetpointType.html#details) | &check; | (&check;) | (&check;) | (&check;) | (&check;) | (&check;) | Position, Velocity, Attitude, Rate, Control Allocation |
| [RoverSpeedAttitude](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverSpeedAttitudeSetpointType.html) | | &check; | (&check;) | &check; | (&check;) | (&check;) | Velocity, Attitude, Rate, Control Allocation |
| [RoverSpeedRate](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverSpeedRateSetpointType.html) | | &check; | (&check;) | | &check; | (&check;) | Velocity, Rate, Control Allocation |
| [RoverSpeedSteering](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverSpeedSteeringSetpointType.html) | | &check; | (&check;) | | | &check; | Velocity, Control Allocation |
| [RoverThrottleAttitude](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverThrottleAttitudeSetpointType.html) | | | &check; | &check; | (&check;) | (&check;) | Attitude, Rate, Control Allocation |
| [RoverThrottleRate](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverThrottleRateSetpointType.html) | | | &check; | | &check; | (&check;) | Rate, Control Allocation |
| [RoverThrottleSteering](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverThrottleSteeringSetpointType.html) | | | &check; | | | &check; | Control Allocation |
&check; are the setpoints we publish, and (&check;) are generated internally by the PX4 rover modules according to the hierarchy above.
An example for a rover specific drive mode using the `RoverSpeedAttitudeSetpointType` is provided [here](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/cpp/modes/rover_velocity).
### Controlling a VTOL
<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />

7
docs/ko/ros2/px4_ros2_interface_lib.md
View File

@ -9,15 +9,12 @@ At the time of writing, parts of the PX4 ROS 2 Interface Library are experimenta
The [PX4 ROS 2 Interface Library](https://github.com/Auterion/px4-ros2-interface-lib) is a C++ library that simplifies controlling and interacting with PX4 from ROS 2.
The library provides two high-level interfaces for developers:
The library provides three high-level interfaces for developers:
1. The [Control Interface](./px4_ros2_control_interface.md) allows developers to create and dynamically register modes written using ROS 2.
It provides classes for sending different types of setpoints, ranging from high-level navigation tasks all the way down to direct actuator controls.
2. The [Navigation Interface](./px4_ros2_navigation_interface.md) enables sending vehicle position estimates to PX4 from ROS 2 applications, such as a VIO system.
<!--
## Overview
-->
3. [Waypoint Missions](./px4_ros2_waypoint_missions.md) allows waypoint missions to run entirely in ROS 2.
## Installation in a ROS 2 Workspace

190
docs/ko/ros2/px4_ros2_waypoint_missions.md Normal file
View File

@ -0,0 +1,190 @@
# PX4 ROS 2 Waypoint Missions
<Badge type="tip" text="PX4 v1.16" /> <Badge type="tip" text="Multicopter (only)" /> <Badge type="warning" text="Experimental" />
The [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) provides a high-level interface for executing ROS-based waypoint missions in ROS 2.
The main use-case is for creating missions where a custom behavior is required, such as a pickup action within a mission.
:::warning
ROS 2 missions are not compatible with MAVLink mission definitions, plan files, or ground stations.
They completely bypass the existing PX4 mission mode and waypoint logic, and cannot be planned or displayed within a ground station.
:::
ROS 2 waypoint missions are effectively special PX4 ROS 2 custom modes that are run based on the content of a [JSON mission definition](#mission-definition).
Mission definitions can contain actions that reference existing PX4 modes, such as Takeoff mode or RTL, and can also be extended with arbitrary custom actions written in ROS.
A [mode executor](px4_ros2_control_interface.md#mode-executor) is used to schedule the modes.
Mission definitions can be hard coded in the custom mission mode (either in code or statically loaded from a JSON string), or directly generated within the application.
They can also be dynamically loaded based on modification of a particular JSON file — this allows for building a more generic mission framework with a fixed set of custom actions.
The file can then be written by any other application, for example a HTTP or MAVFTP server.
The current implementation only supports multicopters but is designed to be extendable to any other vehicle type.
## Comparison to PX4/MAVLink Missions
There are some benefits and drawbacks to using ROS-based missions, which are provided in the following paragraphs.
### Benefits
- Allows to extend mission capabilities by registering custom actions.
- More control over how the mission is executed.
A custom trajectory executor can be implemented, which can use any of the existing PX4 setpoint types to track the trajectory.
- Reduced complexity on the flight controller side by running non-safety-critical and non-real-time code on a more high-level companion computer.
- It can be extended to support other trajectory types, like Bezier or Dubin curves.
### Drawbacks
- QGroundControl currently does not display the mission or progress during execution, and cannot upload or download a mission.
Therefore you will need another mechanism to provide a mission, such as from a web server, a custom GCS, or by generating it directly inside the application.
- The current implementation only supports multicopters (it uses the [GotoSetpointType](../ros2/px4_ros2_control_interface.md#go-to-setpoint-gotosetpointtype), which only works for multicopters, and VTOL in MC mode).
It is designed to be extendable to any other vehicle type.
## 개요
This diagram provides a conceptual overview of the main classes and their interactions:
![Waypoint missions overview diagram](../../assets/middleware/ros2/px4_ros2_interface_lib/waypoint_missions.svg)
<!-- Source: https://drive.google.com/file/d/1BXx4fegVE71eq0kDMMuRnhcLnJeDawWe/view?usp=sharing -->
Missions can be defined in [JSON](#mission-definition), either as a file, or directly inside the application.
There is a file change monitor (`MissionFileMonitor`), that can be used to automatically load a mission from a specific file whenever it is created by another application (e.g. upload via MAVFTP or a cloud service).
The **`MissionExecutor`** class contains the state machine to progress the mission index, and is at the core of the implementation:
- Internally, it builds on top of the [Modes and Mode Executors](px4_ros2_control_interface.md#overview) and registers itself through a custom mode and executor with PX4.
- It handles switching in and out of missions: it gets activated when the user switches to the custom mode that represents the mission and the vehicle is armed.
The mode name can be customized (`My Mission` in the example below).
The mission can be paused, which makes the vehicle switch into _Hold mode_.
To resume the mission, the custom mode has to be selected again.
- When an action switches into another mode (for example Takeoff), QGroundControl will display this mode until it is completed.
The mission executor will then automatically continue.
- Custom actions can be registered.
- The mission can be set.
It then checks that all the actions which the mission defines are available and can be run.
- The state can be stored persistently by providing a file name, allowing for battery swapping.
The **`ActionInterface`** is an interface class for custom actions.
They are identified by a name, and any number of these can be registered with the `MissionExecutor`.
A custom action is then run whenever a mission item with matching name is executed, and any extra arguments from the JSON definition are passed as arguments (for example an altitude for a takeoff action).
Actions can call other actions, run any mode (PX4 or external by its ID), run a trajectory, or run any other external action before deciding when to continue the mission.
There is a set of default actions, for example for RTL, Land, etc.
These simply trigger the corresponding PX4 mode.
They can be disabled or replaced with custom implementations.
There are also some special actions (which can be replaced as well):
- `OnFailure`: this is called in case of a failure, e.g. a mode switch failed, a non-existing action is called (by another action) or by an explicit call to `MissionExecutor::abort()`.
The default is to run RTL, with fallback to Land.
- `OnResume`: this is called when resuming a mission (either from the ground or in-air).
It handles a number of cases:
- when called with an argument `action="storeState"`: this can be used to store the current position when the mission is deactivated, so it can be resumed from the same position.
Currently it does not store anything.
- otherwise, when called without a valid mission index or 0, it directly continues.
- otherwise, when called while in-air, it also directly continues.
- otherwise, if landed and if the current mission item is an action that supports resuming from landed, it continues to let the action handle the resuming.
- otherwise, if landed, it finds the takeoff action from the mission, runs it, and then flies to the previous waypoint from the current index to continue the mission.
- `ChangeSettings`: this can be used to change the mission settings, such as the velocity.
The settings are applied to all following items in the mission.
The **`TrajectoryExecutorInterface`** is an interface class to execute segments of a trajectory.
It can use any setpoint that PX4 and the current vehicle supports for tracking the trajectory.
This class is vehicle-type specific.
The current default implementation (`multicopter::WaypointTrajectoryExecutor`) uses a Goto setpoint (and thus is limited to multicopters).
The default can be replaced with a custom implementation.
## 사용법
The following provides a small example.
It defines a custom action and a mission that uses it.
```c++
class CustomAction : public px4_ros2::ActionInterface {
public:
CustomAction(px4_ros2::ModeBase & mode) : _node(mode.node()) { }
std::string name() const override {return "customAction";}
void run(
const std::shared_ptr<px4_ros2::ActionHandler> & handler,
const px4_ros2::ActionArguments & arguments,
const std::function<void()> & on_completed) override
{
RCLCPP_INFO(_node.get_logger(), "Running custom action");
// Do something...
on_completed();
}
private:
rclcpp::Node & _node;
};
class MyMission {
public:
MyMission(const std::shared_ptr<rclcpp::Node> & node) : _node(node)
{
const auto mission = px4_ros2::Mission(nlohmann::json::parse(R"(
{
"version": 1,
"mission": {
"items": [
{
"type": "takeoff"
},
{
"type": "navigation",
"navigationType": "waypoint",
"x": 47.3977419,
"y": 8.5455939,
"z": 500,
"frame": "global"
},
{
"type": "navigation",
"navigationType": "waypoint",
"x": 47.39791657,
"y": 8.54595214,
"z": 500,
"frame": "global"
},
{
"type": "customAction"
},
{
"type": "rtl"
}
]
}
}
)"));
_mission_executor = std::make_unique<px4_ros2::MissionExecutor>("My Mission",
px4_ros2::MissionExecutor::Configuration().addCustomAction<CustomAction>(), *node);
if (!_mission_executor->doRegister()) {
throw std::runtime_error("Failed to register mission executor");
}
_mission_executor->setMission(mission);
_mission_executor->onProgressUpdate([&](int current_index) {
RCLCPP_INFO(_node->get_logger(), "Current mission index: %i", current_index);
});
_mission_executor->onCompleted([&] {
RCLCPP_INFO(_node->get_logger(), "Mission completed callback");
});
}
private:
std::shared_ptr<rclcpp::Node> _node;
std::unique_ptr<px4_ros2::MissionExecutor> _mission_executor;
};
```
A full example with a few custom actions can be found under [github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/cpp/modes/mission/include](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/cpp/modes/mission/include).
## Mission Definition
The mission JSON file can contain mission defaults and a list of mission items, including user-defined types with custom arguments.
Waypoint coordinates currently need to be defined in global frame, and other frame types might be added in future.
The schema can be found under [github.com/Auterion/px4-ros2-interface-lib/blob/main/mission/schema.yaml](https://github.com/Auterion/px4-ros2-interface-lib/blob/main/mission/schema.yaml).
It provides more details and can be used to validate a JSON file.

68
docs/ko/sim_gazebo_gz/index.md
View File

@ -20,6 +20,8 @@ See [Simulation](../simulation/index.md) for general information about simulator
Gazebo Harmonic is installed by default on Ubuntu 22.04 as part of the normal [development environment setup](../dev_setup/dev_env_linux_ubuntu.md#simulation-and-nuttx-pixhawk-targets).
Gazebo versions Harmonic, Ionic, and Jetty are supported on Ubuntu 24.04. The latest installed Gazebo release is used by default.
:::info
The PX4 installation scripts are based on the instructions: [Binary Installation on Ubuntu](https://gazebosim.org/docs/harmonic/install_ubuntu/) (gazebosim.org).
:::
@ -316,33 +318,33 @@ Here are some examples of the different scenarios covered above.
1. **Start simulator + default world + spawn vehicle at default pose**
```sh
PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
2. **Start simulator + default world + spawn vehicle at custom pose (y=2m)**
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_POSE="0,2" PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_POSE="0,2" PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
3. **Start simulator + default world + link to existing vehicle**
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_NAME=x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_NAME=x500 ./build/px4_sitl_default/bin/px4
```
4. **Start simulator in standalone mode + connect to Gazebo instance running default world**
```sh
PX4_GZ_STANDALONE=1 PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_GZ_STANDALONE=1 PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
In a separate terminal run:
In a separate terminal run:
```sh
python /path/to/simulation-gazebo
```
```sh
python /path/to/simulation-gazebo
```
## Adding New Worlds and Models
@ -358,38 +360,38 @@ To add a new model:
2. Define the default parameters for Gazebo in the airframe configuration file (this example is from [x500 quadcopter](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/airframes/4001_gz_x500)):
```ini
PX4_SIMULATOR=${PX4_SIMULATOR:=gz}
PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}
PX4_SIM_MODEL=${PX4_SIM_MODEL:=<your model name>}
```
```ini
PX4_SIMULATOR=${PX4_SIMULATOR:=gz}
PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}
PX4_SIM_MODEL=${PX4_SIM_MODEL:=<your model name>}
```
- `PX4_SIMULATOR=${PX4_SIMULATOR:=gz}` sets the default simulator (Gz) for that specific airframe.
- `PX4_SIMULATOR=${PX4_SIMULATOR:=gz}` sets the default simulator (Gz) for that specific airframe.
- `PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}` sets the [default world](https://github.com/PX4/PX4-gazebo-models/blob/main/worlds/default.sdf) for that specific airframe.
- `PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}` sets the [default world](https://github.com/PX4/PX4-gazebo-models/blob/main/worlds/default.sdf) for that specific airframe.
- Setting the default value of `PX4_SIM_MODEL` lets you start the simulation with just:
- Setting the default value of `PX4_SIM_MODEL` lets you start the simulation with just:
```sh
PX4_SYS_AUTOSTART=<your new airframe id> ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=<your new airframe id> ./build/px4_sitl_default/bin/px4
```
3. Add CMake Target for the [airframe](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/airframes/CMakeLists.txt).
- If you plan to use "regular" mode, add your model SDF to `Tools/simulation/gz/models/`.
- If you plan to use _standalone_ mode, add your model SDF to `~/.simulation-gazebo/models/`
- If you plan to use "regular" mode, add your model SDF to `Tools/simulation/gz/models/`.
- If you plan to use _standalone_ mode, add your model SDF to `~/.simulation-gazebo/models/`
You can of course also use both.
You can of course also use both.
### Adding a World
To add a new world:
1. Add your world to the list of worlds found in the [`CMakeLists.txt` here](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/simulation/gz_bridge/CMakeLists.txt).
This is required in order to allow `CMake` to generate correct targets.
This is required in order to allow `CMake` to generate correct targets.
- If you plan to use "normal" mode, add your world sdf to `Tools/simulation/gz/worlds/`.
- If you plan to use _standalone_ mode, add your world SDF to `~/.simulation-gazebo/worlds/`
- If you plan to use "normal" mode, add your world sdf to `Tools/simulation/gz/worlds/`.
- If you plan to use _standalone_ mode, add your world SDF to `~/.simulation-gazebo/worlds/`
:::info
As long as the world file and the model file are in the Gazebo search path (`GZ_SIM_RESOURCE_PATH`) it is not necessary to add them to the PX4 world and model directories.