New Crowdin translations - ko (#26396)

Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
2026-05-22 14:24:21 +08:00 · 2026-02-11 15:22:48 +11:00
parent 7f010c1430
commit 90169b932b
14 changed files with 338 additions and 9 deletions
@@ -93,6 +93,7 @@
    - [후방 이동 튜닝](config_vtol/vtol_back_transition_tuning.md)
    - [항속 센서 미장착 VTOL](config_vtol/vtol_without_airspeed_sensor.md)
    - [VTOL 날씨 풍향](config_vtol/vtol_weathervane.md)
+    - [VTOL Ice Shedding](config_vtol/vtol_ice_shedding.md)
  - [비행 모드 ](flight_modes_vtol/index.md)
    - [Mission Mode (VTOL)](flight_modes_vtol/mission.md)
    - [Return Mode (VTOL)](flight_modes_vtol/return.md)
@@ -361,6 +362,8 @@

    - [Satellite Comms (Iridium/RockBlock)](advanced_features/satcom_roadblock.md)

+    - [Analog Video Transmitters](vtx/index.md)
+
  - [Power Systems](power_systems/index.md)
    - [Battery Estimation Tuning](config/battery.md)
    - [Battery Chemistry Overview](power_systems/battery_chemistry.md)
@@ -283,7 +283,7 @@ Acting on a detected failure during flight is deactivated by default (enable by
 During **takeoff** the failure detector [attitude trigger](#attitude-trigger) invokes the [disarm action](#act_disarm) if the vehicle flips (disarm kills the motors but, unlike flight termination, will not launch a parachute or perform other failure actions).
 Note that this check is _always enabled on takeoff_, irrespective of the `CBRK_FLIGHTTERM` parameter.

-The failure detector is active in all vehicle types and modes, except for those where the vehicle is _expected_ to do flips (i.e. [Acro mode (MC)](../flight_modes_mc/altitude.md), [Acro mode (FW)](../flight_modes_fw/altitude.md), and [Manual (FW)](../flight_modes_fw/manual.md)).
+The failure detector is active in all vehicle types and modes, except for those where the vehicle is _expected_ to do flips (i.e. [Acro mode (MC)](../flight_modes_mc/acro.md), [Acro mode (FW)](../flight_modes_fw/acro.md), and [Manual (FW)](../flight_modes_fw/manual.md)).

 ### 자세 감지기

@@ -9,3 +9,4 @@ As part of this you should calibrate the [Airspeed sensor](../config/airspeed.md
 - [Back-transition Tuning](../config_vtol/vtol_back_transition_tuning.md)
 - [VTOL w/o Airspeed Sensor](../config_vtol/vtol_without_airspeed_sensor.md)
 - [VTOL Weather Vane](../config_vtol/vtol_weathervane.md)
+- [Ice Shedding](../config_vtol/vtol_ice_shedding.md)
@@ -0,0 +1,22 @@
+# VTOL Ice Shedding feature
+
+## 개요
+
+Ice shedding is a feature that periodically spins unused motors in fixed-wing
+flight, to break off any ice that is starting to build up in the motors while it
+is still feasible to do so.
+
+It is configured by the paramter `CA_ICE_PERIOD`. When it is 0, the feature is
+disabled, when it is above 0, it sets the duration of the ice shedding cycle in
+seconds. In each cycle, the rotors are spun for two seconds at a motor output of
+0.01.
+
+:::warning
+When enabling the feature on a new airframe, there is the risk of producing
+torques that disturb the fixed-wing rate controller. To mitigate this risk:
+
+- Set your `PWM_MIN` values correctly, so that the motor output 0.01 actually
+  produces 1% thrust
+- Be prepared to take control and switch back to multicopter
+
+:::
@@ -34,7 +34,7 @@ If you update an existing file you are not required to make the whole file compl

 ### Line Length

- Maximum line length is 120 characters.
+- Maximum line length is 140 characters.

 ### File Extensions

@@ -335,7 +335,7 @@ The configuration can be done using the [UXRCE-DDS parameters](../advanced_confi
  - [UXRCE_DDS_NS_IDX](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) <Badge type="tip" text="PX4 v1.17" />: 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.
-  - [`UXRCE_DDS_FLCTRL`](../advanced_config/parameter_reference.md#UXRCE_DDS_FLCTRL) <Badge type="tip" text="PX4 main" />: Serial port hardware flow control enable.
+  - [`UXRCE_DDS_FLCTRL`](../advanced_config/parameter_reference.md#UXRCE_DDS_FLCTRL) <Badge type="tip" text="main (planned for: PX4 v1.18)" />: Serial port hardware flow control enable.
    To use hardware flow control, a custom MicroXRCE Agent needs to be adopted. Please refer to [this PR](https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/407) for the required changes, cherry-pick them on top of the [agent version](#build-run-within-ros-2-workspace) you need to use and then run the agent with the additional `--flow-control` option.

 :::info
@@ -89,15 +89,19 @@ This consists of a single _C_ file and a _cmake_ definition (which tells the too
     ```

     :::tip
+
     The main function must be named `<module_name>_main` and exported from the module as shown.

+
 :::

     :::tip
+
     `PX4_INFO` is the equivalent of `printf` for the PX4 shell (included from **px4_platform_common/log.h**).
     There are different log levels: `PX4_INFO`, `PX4_WARN`, `PX4_ERR`, `PX4_DEBUG`.
     Warnings and errors are additionally added to the [ULog](../dev_log/ulog_file_format.md) and shown on [Flight Review](https://logs.px4.io/).

+
 :::

 3. Create and open a new _cmake_ definition file named **CMakeLists.txt**.
@@ -166,7 +170,7 @@ This consists of a single _C_ file and a _cmake_ definition (which tells the too
 4. Create and open a new _Kconfig_ definition file named **Kconfig** and define your symbol for naming (see [Kconfig naming convention](../hardware/porting_guide_config.md#px4-kconfig-symbol-naming-convention)).
   아래 텍스트를 복사하십시오.

-   ```
+   ```text
   menuconfig EXAMPLES_PX4_SIMPLE_APP
   	bool "px4_simple_app"
   	default n
@@ -22,7 +22,11 @@ If not, there are other possible NN frameworks, such as [Eigen](https://eigen.tu
 This document explains how you can include the module in your PX4 build, and provides a broad overview of how it works.
 The other documents in the section provide more information about the integration, allowing you to replace the NN with a version trained on different data, or even to replace the TLFM library altogether.

-If you are looking for more resources to learn about the module, a website has been created with links to a youtube video and a workshop paper. A full master's thesis will be added later. [A Neural Network Mode for PX4 on Embedded Flight Controllers](https://ntnu-arl.github.io/px4-nns/).
+:::tip
+For more information, see the Masters thesis from which this module was created: [Deep Reinforcement Learning for Embedded Control Policies for Aerial Vehicles](https://nva.sikt.no/registration/019b26689144-efeebae8-84d6-4413-ad7f-9aceb4ff7374).
+
+In addition, the (Norwegian) website [A Neural Network Mode for PX4 on Embedded Flight Controllers](https://ntnu-arl.github.io/px4-nns/) has a youtube video and a workshop paper .
+:::

 ## Neural Network PX4 Firmware

@@ -35,7 +35,7 @@ The method we developed for training the RAPTOR policy is called Meta-Imitation

 You can torture test the RAPTOR policy in your browser at [https://raptor.rl.tools](https://raptor.rl.tools) or in the embedded app here:

-<iframe src="https://rl-tools.github.io/raptor.rl.tools?raptor=false" width="100%" height="1000" style="border: none;"></iframe>
+<iframe src="https://raptor.rl.tools?raptor=false" width="100%" height="1000" style="border: none;"></iframe>

 For more information please refer to the paper at [https://arxiv.org/abs/2509.11481](https://arxiv.org/abs/2509.11481).

@@ -11,7 +11,7 @@ PX4 traffic avoidance works with ADS-B or FLARM products that supply transponder
 It has been tested with the following devices:

 - [PingRX ADS-B Receiver](https://uavionix.com/product/pingrx-pro/) (uAvionix)
- [FLARM](https://flarm.com/products/uav/atom-uav-flarm-for-drones/) <!-- I think originally https://flarm.com/products/powerflarm/uav/ -->
+- [FLARM](https://www.flarm.com/en/drones/)

 ## 하드웨어 설정

@@ -14,7 +14,7 @@ At the time of writing, parts of the PX4 ROS 2 Control Interface are experimenta

 :::

-The [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) is a C++ library that simplifies controlling PX4 from ROS 2.
+The [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) is a C++ library (with Python bindings) that simplifies controlling PX4 from ROS 2.

 Developers use the library to create and dynamically register modes written using ROS 2.
 These modes are dynamically registered with PX4, and appear to be part of PX4 to a ground station or other external system.
@@ -26,6 +26,12 @@ These classes abstract the internal setpoints used by PX4, and that can therefor
 PX4 ROS 2 modes are easier to implement and maintain than PX4 internal modes, and provide more resources for developers in terms of processing power and pre-existing libraries.
 Unless the mode is safety-critical, requires strict timing or very high update rates, or your vehicle doesn't have a companion computer, you should [consider using PX4 ROS 2 modes in preference to PX4 internal modes](../concept/flight_modes.md#internal-vs-external-modes).

+:::tip
+If you want to use Python, check out the [examples in the repository](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/python).
+Not all classes have Python bindings yet — the [supported bindings are here](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/px4_ros2_py/src/px4_ros2).
+You are welcome to add and contribute missing classes.
+:::
+
 ## 개요

 This diagram provides a conceptual overview of how the control interface modes and mode executors interact with PX4.
@@ -7,7 +7,7 @@
 At the time of writing, parts of the PX4 ROS 2 Interface Library are experimental, and hence subject to change.
 :::

-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 [PX4 ROS 2 Interface Library](https://github.com/Auterion/px4-ros2-interface-lib) is a C++ library (with Python bindings) that simplifies controlling and interacting with PX4 from ROS 2.

 The library provides three high-level interfaces for developers:

@@ -15,6 +15,8 @@ LightWare는 UAV에 장착에 적합한 경량의 범용 레이저 고도계( "
 | [LW20/C](https://lightware.co.za/products/lw20-c-100-m) | 100                       | I2C 버스       | 감지 및 회피 애플리케이션을 위한 서보가 있는 방수 (IP67)                                                        |
 | [SF30/D](https://lightwarelidar.com/shop/sf30-d-200-m/) | 200                       | I2C 버스       | Waterproofed (IP67)                                                                        |
 | [SF45/B](../sensor/sf45_rotating_lidar.md)              | 50                        | 직렬           | Rotary Lidar (Used for [Collision Prevention](../computer_vision/collision_prevention.md)) |
+| [GRF250](https://lightwarelidar.com/shop/grf-250/)      | 250                       | I2C          | Gimbal Range Finder                                                                                           |
+| [GRF500](https://lightwarelidar.com/shop/grf-500/)      | 500                       | I2C          | Gimbal Range Finder                                                                                           |

 :::details
 Discontinued
@@ -0,0 +1,287 @@
+# Analog Video Transmitters
+
+Analog Video Transmitters (VTX) can be controlled by PX4 via a half-duplex UART connection implementing the SmartAudio v1, v2, and v2.1 and Tramp protocols.
+
+The protocols allow writing and reading:
+
+- device status.
+- transmission frequency in MHz or via band and channel index.
+- transmission power in dBm or mW.
+- operation modes.
+
+VTX settings are controlled by parameters and optionally via RC AUX channels or CRSF MSP commands.
+The driver stores frequency and power tables that map band/channel indices to actual transmission values.
+Configuration is device-specific and set up using the command line interface.
+
+## 시작하기
+
+Connect the SmartAudio or Tramp pin of the VTX to the TX pin of a free serial port on the flight controller.
+Then set the following parameters:
+
+- `VTX_SER_CFG`: Select the serial port used for VTX communication.
+- `VTX_DEVICE`: Selects the VTX device (generic SmartAudio/Tramp or a specific device).
+
+Note that since the VTX communication is half-duplex, you can, for example, use the single-pin Radio Controller port for the VTX and use a full duplex TELEM port for CRSF communication.
+
+You should now be able to see the VTX device in the driver status:
+
+```
+nsh> vtx status
+INFO  [vtx] UART device: /dev/ttyS4
+INFO  [vtx] VTX table "UNINITIALIZED":
+INFO  [vtx] Power levels:
+INFO  [vtx] RC mapping: Disabled
+INFO  [vtx] Parameters:
+INFO  [vtx]   band: 1
+INFO  [vtx]   channel: 1
+INFO  [vtx]   frequency: 0 MHz
+INFO  [vtx]   power level: 1
+INFO  [vtx]   power: 0 = 0 mW
+INFO  [vtx]   pit mode: off
+INFO  [vtx] SmartAudio v2:
+INFO  [vtx]   band: 1
+INFO  [vtx]   channel: 1
+INFO  [vtx]   frequency: 6110 MHz
+INFO  [vtx]   power level: 1
+INFO  [vtx]   power: 0 mW
+INFO  [vtx]   pit mode: on
+INFO  [vtx]   lock: unlocked
+```
+
+:::warning
+Without a configured power table, power mappings are unknown and default to 0 mW.
+Some VTX devices enter pit mode when power is set to 0, regardless of the `VTX_PIT_MODE` parameter.
+:::
+
+## VTX Table Configuration
+
+The VTX table stores frequency and power mappings for your specific device.
+
+The manufacturer usually provides this information in the form of a JSON file that can be translated into a [Betaflight CLI command set](https://www.betaflight.com/docs/development/VTX#vtx-table) that this driver implements for compatibility.
+
+### Power Level Configuration
+
+```
+# Set table name ≤16 characters
+vtxtable name "Peak THOR T67"
+
+# Set the power values that are sent to the VTX for each power level index
+# Note: SmartAudio v1 and v2 use index values!
+vtxtable powervalues 0 1 2 3 4
+# Note: SmartAudio v2.1 uses dBm values instead!
+#       vtxtable powervalues 14 23 27 30 35
+# Note: Tramp uses mW values instead!
+#       vtxtable powervalues 25 200 500 1000 3000
+
+# Set the corresponding power labels for each power level index ≤4 characters.
+# These are used for status reporting.
+vtxtable powerlabels 25 200 500 1W 3W
+
+# Set number of power levels
+vtxtable powerlevels 5
+
+# Save configuration
+vtxtable save
+```
+
+This will create a VTX table with 5 power levels.
+
+```nsh> vtxtable status
+INFO  [vtxtable] VTX table "Peak THOR T67":
+INFO  [vtxtable] Power levels:
+INFO  [vtxtable]   1:  0 = 25
+INFO  [vtxtable]   2:  1 = 200
+INFO  [vtxtable]   3:  2 = 500
+INFO  [vtxtable]   4:  3 = 1W
+INFO  [vtxtable]   5:  4 = 3W
+```
+
+### Frequency Table Configuration
+
+```
+# Set the name of each band and the frequencies of each channel
+vtxtable band 1 BAND_A A FACTORY 6110 6130 6150 6170 6190 6210 6230 6250
+vtxtable band 2 BAND_B B FACTORY 6270 6290 6310 6330 6350 6370 6390 6410
+vtxtable band 3 BAND_E E FACTORY 6430 6450 6470 6490 6510 6530 6550 6570
+vtxtable band 4 BAND_F F FACTORY 6590 6610 6630 6650 6670 6690 6710 6730
+vtxtable band 5 BAND_R R FACTORY 6750 6770 6790 6810 6830 6850 6870 6890
+vtxtable band 6 BAND_P P FACTORY 6910 6930 6950 6970 6990 7010 7030 7050
+vtxtable band 7 BAND_H H FACTORY 7070 7090 7110 7130 7150 7170 7190 7210
+vtxtable band 8 BAND_U U FACTORY 6115 6265 6425 6585 6745 6905 7065 7185
+
+# Set number of bands and channels
+vtxtable bands 8
+vtxtable channels 8
+
+# Save configuration
+vtxtable save
+```
+
+This will create a VTX table with 8 bands and 8 channels.
+Note that FACTORY sends the band and channel indexes to the VTX device and they use their internal frequency mapping. In this mode the frequency is just for indication purposes.
+In contrast, CUSTOM would send the actual frequency values to the VTX device, but not all devices support this mode.
+Setting a frequency to zero will skip setting it.
+
+```
+nsh> vtxtable status
+INFO  [vtxtable] VTX table 8x8: Peak THOR T67
+INFO  [vtxtable]  A: BAND_A          = 6110 6130 6150 6170 6190 6210 6230 6250
+INFO  [vtxtable]  B: BAND_B          = 6270 6290 6310 6330 6350 6370 6390 6410
+INFO  [vtxtable]  E: BAND_E          = 6430 6450 6470 6490 6510 6530 6550 6570
+INFO  [vtxtable]  F: BAND_F          = 6590 6610 6630 6650 6670 6690 6710 6730
+INFO  [vtxtable]  R: BAND_R          = 6750 6770 6790 6810 6830 6850 6870 6890
+INFO  [vtxtable]  P: BAND_P          = 6910 6930 6950 6970 6990 7010 7030 7050
+INFO  [vtxtable]  H: BAND_H          = 7070 7090 7110 7130 7150 7170 7190 7210
+INFO  [vtxtable]  U: BAND_U          = 6115 6265 6425 6585 6745 6905 7065 7185
+```
+
+### Table Constraints
+
+Maximum table dimensions:
+
+- ≤24 bands each with ≤16 channels and ≤32GHz frequency values.
+- ≤16 power levels.
+- ≤16 characters table name.
+- ≤12 characters band name and 1 character band letter.
+- ≤4 characters power label length (to support "2.5W").
+
+## AUX Channel Mapping
+
+The AUX mapping feature allows you to control VTX settings using RC AUX channels.
+Each mapping entry defines an AUX channel range that triggers a specific VTX configuration.
+
+To enable AUX mapping, set `VTX_MAP_CONFIG` to one of the following values:
+
+- `0`: Disabled
+- `1`: Disabled (reserved for CRSF MSP integration)
+- `2`: Map AUX channels to power level control only
+- `3`: Map AUX channels to band and channel control only
+- `4`: Map AUX channels to all settings (power, band, and channel)
+
+### Configuring AUX Map Entries
+
+Use the following command format to add mapping entries:
+
+```
+vtxtable <index> <aux_channel> <band> <channel> <power> <start_pwm> <end_pwm>
+```
+
+Parameters:
+
+- `index`: Map entry index (0-159)
+- `aux_channel`: AUX channel number (3-19, where AUX1=3)
+- `band`: Target band (1-24, or 0 to leave unchanged)
+- `channel`: Target channel (1-16, or 0 to leave unchanged)
+- `power`: Power level (1-16, 0 to leave unchanged, or -1 for pit mode)
+- `start_pwm`: Start of PWM range in microseconds (typically 900-2100)
+- `end_pwm`: End of PWM range in microseconds (typically 900-2100)
+
+:::info
+AUX channel numbering starts from 3 (AUX1=channel 3) to account for the first four RC channels 0-3 used for flight control.
+:::
+
+Example configuration for a 6-position dial controlling band/channel on AUX4 (channel 7):
+
+```
+vtx  0 7 7 1 0  900 1025
+vtx  1 7 7 2 0 1025 1100
+vtx  2 7 7 4 0 1100 1175
+vtx  3 7 7 6 0 1175 1225
+vtx  4 7 7 8 0 1225 1300
+vtx  5 7 3 8 0 1300 2100
+```
+
+Example configuration for power control on AUX3 (channel 6):
+
+```
+vtxtable 16 6 0 0 -1  900 1250
+vtxtable 17 6 0 0  1 1250 1525
+vtxtable 18 6 0 0  2 1525 1650
+vtxtable 19 6 0 0  3 1650 1875
+vtxtable 20 6 0 0  4 1875 2010
+```
+
+Save the configuration with:
+
+```
+vtxtable save
+```
+
+The map status can be verified with `vtxtable status`.
+
+## CRSF MSP Integration
+
+When using a CRSF receiver with MSP support, you can control VTX settings directly from your transmitter using MSP commands sent over the CRSF link.
+This feature must be enabled at compile time with the `VTX_CRSF_MSP_SUPPORT` Kconfig option.
+
+To enable CRSF MSP control, set `VTX_MAP_CONFIG` to one of:
+
+- `1`: MSP controls both frequency (band/channel) and power
+- `2`: MSP controls frequency (band/channel) only, AUX controls power
+- `3`: MSP controls power only, AUX controls band/channel
+
+When MSP integration is active, the driver responds to `MSP_SET_VTX_CONFIG` (0x59) commands.
+The transmitter can send band, channel, frequency, power level, and pit mode settings via MSP, which are automatically mapped to the corresponding PX4 parameters.
+
+:::tip
+The MSP integration allows seamless VTX control from transmitters that support VTX configuration via Lua scripts or built-in VTX menus without requiring additional hardware switches.
+:::
+
+## Build Configuration
+
+Both the VTX driver and VTX table support are configured via Kconfig options.
+
+Key configuration options:
+
+- `VTX_CRSF_MSP_SUPPORT`: Enables CRSF MSP command support (default: disabled)
+- `VTXTABLE_CONFIG_FILE`: File path for persistent configuration (default: `/fs/microsd/vtx_config`)
+- `VTXTABLE_AUX_MAP`: Enables AUX channel mapping (default: disabled)
+
+## Parameter Reference
+
+### VTX Settings Parameters
+
+- `VTX_BAND` (0-23): Frequency band selection (Band 1-24 in UI)
+- `VTX_CHANNEL` (0-15): Channel within band (Channel 1-16 in UI)
+- `VTX_FREQUENCY` (0-32000): Direct frequency in MHz (overrides band/channel when non-zero)
+- `VTX_POWER` (0-15): Power level (Level 1-16 in UI, as configured in table)
+- `VTX_PIT_MODE` (boolean): Pit mode for reduced power (default: disabled)
+
+### Configuration Parameters
+
+- `VTX_SER_CFG`: Serial port assignment for VTX communication
+- `VTX_MAP_CONFIG`: Controls how VTX settings are mapped:
+  - Without `VTX_CRSF_MSP_SUPPORT`:
+    - `0`: Disabled
+    - `1`: Disabled
+    - `2`: AUX controls power only
+    - `3`: AUX controls band/channel only
+    - `4`: AUX controls both power and band/channel
+  - With `VTX_CRSF_MSP_SUPPORT`:
+    - `0`: Disabled
+    - `1`: MSP controls both frequency and power
+    - `2`: MSP controls frequency, AUX controls power
+    - `3`: MSP controls power, AUX controls band/channel
+    - `4`: Not used with MSP support
+- `VTX_DEVICE`: Device-specific configuration (see below)
+
+## Device-Specific Configuration
+
+The `VTX_DEVICE` parameter allows device-specific workarounds.
+It encodes both the protocol type and device variant:
+
+- Low byte (bits 0-7): Protocol selection
+  - `0`: SmartAudio (default)
+  - `1`: Tramp
+- High byte (bits 8-15): Device-specific variant
+  - `0`: Generic device
+  - `20`: Peak THOR T67
+  - `40`: Rush Max Solo
+
+### Known Device Workarounds
+
+**Peak THOR T67** (`VTX_DEVICE` = 5120):
+This device incorrectly reports pit mode status but otherwise functions normally.
+The driver applies a workaround to override the reported status with the actual configured state.
+
+For generic devices, use `VTX_DEVICE` = 0 (SmartAudio) or `VTX_DEVICE` = 1 (Tramp).