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

Move PX4 Guide source into /docs (#24490)

Browse Source 
* Add vitepress tree

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

* Add nojekyll, package.json, LICENCE etc

* Add crowdin docs upload/download scripts

* Add docs flaw checker workflows

* Used docs prefix for docs workflows

* Crowdin obvious fixes

* ci: docs move to self hosted runner

runs on a beefy server for faster builds

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

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

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

* ci: update runners

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

* Add docs/en

* Add docs assets and scripts

* Fix up editlinks to point to PX4 sources

* Download just the translations that are supported

* Add translation sources for zh, uk, ko

* Update latest tranlsation and uorb graphs

* update vitepress to latest

---------

Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Co-authored-by: Ramon Roche <mrpollo@gmail.com>
This commit is contained in:
Hamish Willee
2025-03-13 16:08:27 +11:00
committed by GitHub
co-authored by Ramon Roche
parent 8e6d2ebe4a
commit 88d623bedb
5176 changed files with 558771 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ko/advanced/community_supported_dev_env.md
+23
View File
@@ -0,0 +1,23 @@
# Community Supported Developer Tools
This section contains information about _community-supported_ development setups, IDEs, simulators, and other tools.
:::warning
These setups are not maintained, tested, or supported, by the core development team.
They may or may not work with current versions of PX4.
See [Toolchain Installation](../dev_setup/dev_env.md) for information about the environments and tools supported by the core development team.
:::
The tools have variable levels of support from their communities (some are well supported and others are not).
Questions about these tools should be raised on the [discussion forums](../contribute/support.md#forums-and-chat)
- Development Platforms/Setups
- [CentOS Linux](../dev_setup/dev_env_linux_centos.md)
- [Arch Linux](../dev_setup/dev_env_linux_arch.md)
- [Windows VM Toolchain](../dev_setup/dev_env_windows_vm.md) — Ubuntu setup running in VM on Windows.
- [Windows Cygwin Toolchain](../dev_setup/dev_env_windows_cygwin.md) — Windows setup only works to PX4 v1.12
- [Windows Cygwin Toolchain Maintenance](../dev_setup/dev_env_windows_cygwin_packager_setup.md)
- IDEs
- [Qt Creator IDE](../dev_setup/qtcreator.md)
- [Simulators](../simulation/community_supported_simulators.md) — [Simulation-In-Hardware](../sim_sih/index.md), [FlightGear](../sim_flightgear/index.md), [JSBSim](../sim_jsbsim/index.md), [AirSim](../sim_airsim/index.md), [HITL](../simulation/hitl.md)
docs/ko/advanced/computer_vision.md
+92
View File
@@ -0,0 +1,92 @@
# 컴퓨터 비전 (Optical Flow, MoCap, VIO, Avoidance)
[Computer vision](https://en.wikipedia.org/wiki/Computer_vision) techniques enable computers to use visual data to make sense of their environment.
PX4 uses computer vision systems (primarily running on [Companion Computers](../companion_computer/index.md)) in order to support the following features:
- [Optical Flow](#optical-flow) provides 2D velocity estimation (using a downward facing camera and a downward facing distance sensor).
- [Motion Capture](#motion-capture) provides 3D pose estimation using a vision system that is _external_ to the vehicle.
주로 실내 내비게이션에 사용됩니다.
- [Visual Inertial Odometry](#visual-inertial-odometry-vio) provides 3D pose and velocity estimation using an onboard vision system and IMU.
It is used for navigation when GNSS position information is absent or unreliable.
- [Collision Prevention](../computer_vision/collision_prevention.md) is used to stop vehicles before they can crash into an obstacle (primarily when flying in manual modes).
:::tip
The [PX4 Vision Autonomy Development Kit](../complete_vehicles_mc/px4_vision_kit.md) (Holybro) is a robust and inexpensive kit for developers working with computer vision on PX4.
:::
## 모션 캡쳐
Motion Capture (MoCap) is a technique for estimating the 3D _pose_ (position and orientation) of a vehicle using a positioning mechanism that is _external_ to the vehicle.
MoCap systems most commonly detect motion using infrared cameras, but other types of cameras, Lidar, or Ultra Wideband (UWB) may also be used.
:::info
MoCap is commonly used to navigate a vehicle in situations where GPS is absent (e.g. indoors), and provides position relative to a _local_ coordinate system.
:::
자세한 모션 캡쳐 기술은 다음을 참고하십시오:
- [External Position Estimation](../ros/external_position_estimation.md)
- [Flying with Motion Capture (VICON, NOKOV, Optitrack)](../tutorials/motion-capture.md)
- [Using PX4's Navigation Filter (EKF2) > External Vision System](../advanced_config/tuning_the_ecl_ekf.md#external-vision-system)
## Visual Inertial Odometry (VIO)
Visual Inertial Odometry (VIO) is used for estimating the 3D _pose_ (position and orientation) and _velocity_ of a moving vehicle relative to a _local_ starting position.
보통 GPS가 빠졌거나 (예: 실내) 신뢰할 수 없을 때(예: 다리 아래로 비행할 경우) 기체 운행에 활용합니다.
VIO uses [Visual Odometry](https://en.wikipedia.org/wiki/Visual_odometry) to estimate vehicle _pose_ from visual information, combined with inertial measurements from an IMU (to correct for errors associated with rapid vehicle movement resulting in poor image capture).
:::info
One difference between VIO and [MoCap](#motion-capture) is that VIO cameras/IMU are vehicle-based, and additionally provide velocity information.
:::
PX4의 VIO 설정 방법을 더 알아보려면 다음을 참고하십시오:
- [Using PX4's Navigation Filter (EKF2) > External Vision System](../advanced_config/tuning_the_ecl_ekf.md#external-vision-system)
- [T265 Setup guide](../peripherals/camera_t265_vio.md)
## 광류 센서
[Optical Flow](../sensor/optical_flow.md) provides 2D velocity estimation (using a downward facing camera and a downward facing distance sensor).
광류 센서 기술을 더 알아보려면 다음을 참고하십시오.
- [Optical Flow](../sensor/optical_flow.md)
- [Using PX4's Navigation Filter (EKF2) > Optical Flow](../advanced_config/tuning_the_ecl_ekf.md#optical-flow)
## Comparisons
### Optical Flow vs VIO for Local Position Estimation
Both these techniques use cameras and measure differences between frames.
Optical flow uses a downward facing camera, while VIO uses a stereo camera or a 45 degree tracking camera.
Assuming both are well calibrated, which is better for local position estimation?
The consensus [appears to be](https://discuss.px4.io/t/vio-vs-optical-flow/34680):
Optical flow:
- Downward facing optical flow gives you a planar velocity thats corrected for angular velocity with the gyro.
- Requires an accurate distance to the ground and assumes a planar surface.
Given those conditions it can be just as accurate/reliable as VIO (such as indoor flight)
- Is more robust than VIO as it has fewer states.
- Is significantly cheaper and easier to set up as it only requires a flow sensor, a rangefinder, and setting up a few parameters (which can be connected to the flight controller).
VIO:
- Is more expensive to purchase and harder to set up.
It requires a separate companion computer, calibration, software, configuration and so on.
- Will be less effective if there are no point features to track (in practice the real world generally has point features).
- Is more flexible, allowing additional features such as obstacle avoidance and mapping.
A combination (fusing both) is probably the most reliable, though not necessary in most real-world scenarios.
Normally you will select the system that suits your operating environment, required features, and cost constraints:
- Use VIO if you plan on flying outdoors without GPS (or outdoors and indoors), or if you need to support obstacle avoidance and other computer vision features.
- Use Optical Flow if you plan on only flying indoors (without GPS) and cost is an important consideration.
## 외부 참고 자료
- [XTDrone](https://github.com/robin-shaun/XTDrone/blob/master/README.en.md) - ROS + PX4 simulation environment for computer vision.
The [XTDrone Manual](https://www.yuque.com/xtdrone/manual_en) has everything you need to get started!
docs/ko/advanced/gimbal_control.md
+187
View File
@@ -0,0 +1,187 @@
# Gimbal Configuration
This page explains how to configure and control a gimbal that has an attached camera (or any other payload).
## 개요
PX4 contains a generic mount/gimbal control driver that supports different input and output methods:
- The input method defines the protocol used to command a gimbal mount that is managed by PX4.
This might be an RC controller, a MAVLink command sent by a GCS, or both — automatically switching between them.
- The output method defines how PX4 communicates with the connected gimbal.
The recommended protocol is MAVLink v2, but you can also connect directly to a flight controller PWM output port.
PX4 takes the input signal and routes/translates it to be sent through to the output.
Any input method can be selected to drive any output.
Both the input and output are configured using parameters.
The input is set using the parameter [MNT_MODE_IN](../advanced_config/parameter_reference.md#MNT_MODE_IN).
By default this is set to `Disabled (-1)` and the driver does not run.
After selecting the input mode, reboot the vehicle to start the mount driver.
You should set `MNT_MODE_IN` to one of: `RC (1)`, `MAVlink gimbal protocol v2 (4)` or `Auto (0)` (the other options are deprecated).
If you select `Auto (0)`, the gimbal will automatically select either RC or or MAVLink input based on the latest input.
Note that the auto-switch from MAVLink to RC requires a large stick motion!
The output is set using the [MNT_MODE_OUT](../advanced_config/parameter_reference.md#MNT_MODE_OUT) parameter.
By default the output is set to a PXM port (`AUX (0)`).
If the [MAVLink Gimbal Protocol v2](https://mavlink.io/en/services/gimbal_v2.html) is supported by your gimbal, you should instead select `MAVLink gimbal protocol v2 (2)`.
The full list of parameters for setting up the mount driver can be found in [Parameter Reference > Mount](../advanced_config/parameter_reference.md#mount).
The relevant settings for a number of common gimbal configurations are described below.
## MAVLink 짐벌(MNT_MODE_OUT=MAVLINK)
Each physical gimbal device on the system must have its own high level gimbal manager, which is discoverable by a ground station using the MAVLink gimbal protocol.
The ground station sends high level [MAVLink Gimbal Manager](https://mavlink.io/en/services/gimbal_v2.html#gimbal-manager-messages) commands to the manager of the gimbal it wants to control, and the manager will in turn send appropriate lower level "gimbal device" commands to control the gimbal.
PX4 can be configured as the gimbal manager to control a single gimbal device (which can either be physically connected or be a MAVLink gimbal that implements the [gimbal device interface](https://mavlink.io/en/services/gimbal_v2.html#gimbal-device-messages)).
To enable a MAVLink gimbal, first set parameter [MNT_MODE_IN](../advanced_config/parameter_reference.md#MNT_MODE_IN) to `MAVlink gimbal protocol v2` and [MNT_MODE_OUT](../advanced_config/parameter_reference.md#MNT_MODE_OUT) to `MAVLink gimbal protocol v2`.
The gimbal can be connected to _any free serial port_ using the instructions in [MAVLink Peripherals (GCS/OSD/Companion)](../peripherals/mavlink_peripherals.md) (also see [Serial Port Configuration](../peripherals/serial_configuration.md#serial-port-configuration)).
For example, if the `TELEM2` port on the flight controller is unused you can connect it to the gimbal and set the following PX4 parameters:
- [MAV_1_CONFIG](../advanced_config/parameter_reference.md#MAV_1_CONFIG) to **TELEM2** (if `MAV_1_CONFIG` is already used for a companion computer (say), use `MAV_2_CONFIG`).
- [MAV_1_MODE](../advanced_config/parameter_reference.md#MAV_1_MODE) to **NORMAL**
- [SER_TEL2_BAUD](../advanced_config/parameter_reference.md#SER_TEL2_BAUD) to manufacturer recommended baud rate.
### Multiple Gimbal Support
PX4 can automatically create a gimbal manager for a connected PWM gimbal or the first MAVLink gimbal device with the same system id it detects on any interface.
It does not automatically create gimbal manager for any other MAVLink gimbal devices that it detects.
You can support additional MAVLink gimbals provided that they:
- Implement the gimbal _manager_ protocol.
- Are visible to the ground station and PX4 on the MAVLink network.
This may require that traffic forwarding be configured between PX4, the GCS, and the gimbal.
- Have a unique component id, and this component id must be in the range 7 - 255.
## Gimbal on FC PWM Output (MNT_MODE_OUT=AUX)
The gimbal can also be controlled by connecting it to up to three flight controller PWM ports and setting the output mode to `MNT_MODE_OUT=AUX`.
The output pins that are used to control the gimbal are set in the [Acuator Configuration > Outputs](../config/actuators.md#actuator-outputs) by selecting any three unused Actuator Outputs and assigning them the following output functions:
- `Gimbal Roll`: Output controls gimbal roll.
- `Gimbal Pitch`: Output controls Gimbal pitch.
- `Gimbal Yaw`: Output controls Gimbal yaw.
For example, you might have the following settings to assign the gimbal roll, pitch and yaw to AUX1-3 outputs.
![Gimbal Actuator config](../../assets/config/actuators/qgc_actuators_gimbal.png)
The PWM values to use for the disarmed, maximum and minimum values can be determined in the same way as other servo, using the [Actuator Test sliders](../config/actuators.md#actuator-testing) to confirm that each slider moves the appropriate axis, and changing the values so that the gimbal is in the appropriate position at the disarmed, low and high position in the slider.
The values may also be provided in gimbal documentation.
## Gimbal Control in Missions
[Gimbal Manager commands](https://mavlink.io/en/services/gimbal_v2.html#gimbal-manager-messages) may be used in missions if supported by the vehicle type.
For example [MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW) is supported in [multicopter mission mode](../flight_modes_mc/mission.md).
In theory you can address commands to a particular gimbal, specifying its component id using the "Gimbal device id" parameter.
However at time of writing (December 2024) this is [not supported](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/gimbal/input_mavlink.cpp#L889): all mission commands are sent to the (only) gimbal managed by the PX4 gimbal manager (if this is a MAVLink gimbal, it will be the gimbal with component id defined in the parameter [MNT_MAV_COMPID](../advanced_config/parameter_reference.md#MNT_MAV_COMPID), which is set by default to [MAV_COMP_ID_GIMBAL (154)](https://mavlink.io/en/messages/common.html#MAV_COMP_ID_GIMBAL)).
Gimbal movement is not immediate.
To ensure that the gimbal has time to move into position before the mission progresses to the next item (if gimbal feedback is not provided or lost), you should set [MIS_COMMAND_TOUT](../advanced_config/parameter_reference.md#MIS_COMMAND_TOUT) to be greater than the time taken for the gimbal to traverse its full range.
After this timeout the mission will proceed to the next item.
## Simulation / SITL
The following simulation environments come with a preconfigured simulated gimbal.
You can test the gimbal using the [QGroundControl UI](#qgc-testing) or by sending [driver commands](#driver-testing)
:::tip
If you only need to test the [gimbal driver](../modules/modules_driver.md#gimbal), then you can do this on any model or simulators.
Just make sure that the driver runs, using `gimbal start` in the MAVLink console, then configure the driver parameters.
:::
### Gazebo
To run the [Gazebo](../sim_gazebo_gz/index.md) simulation [Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-gimbal-front-facing), use:
```sh
make px4_sitl gz_x500_gimbal
```
![Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../../assets/simulation/gazebo/vehicles/x500_gimbal.png)
### Gazebo Classic
To run the [Gazebo Classic](../sim_gazebo_classic/index.md) simulation [Typhoon H480 model](../sim_gazebo_classic/vehicles.md#typhoon-h480-hexrotor), use:
```sh
make px4_sitl gazebo-classic_typhoon_h480
```
![Typhoon H480 in Gazebo Classic](../../assets/simulation/gazebo_classic/vehicles/typhoon.jpg)
![Gazebo Gimbal Simulation](../../assets/simulation/gazebo_classic/gimbal-simulation.png)
## 시험
### QGC Testing
The on-screen gimbal control can be used to move/test a connected MAVLink camera:
1. Start your preferred [simulator](#simulation-sitl) or connect to a real device.
2. Open QGroundControl and enable the on-screen camera control (Application settings).
![Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../../assets/qgc/fly/gimbal_control_x500gz.png)
3. Make sure the vehicle is armed and flying, e.g. by entering with `commander takeoff`.
4. To change gimbal target position, click in the QGC GUI up, down, left, right, or use the buttons on the gimbal control (**Center**, **Tilt 90**, **Yaw lock**).
### Driver Testing
You can test a gimbal by sending `gimbal` driver commands in the [QGroundControl MAVLink Console](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html):
1. Start your preferred [simulator](#simulation-sitl) or connect to a real device.
2. Open QGroundControl and connect to your vehicle.
3. Open the MAVLink Console using the menu: **Analyze > Mavlink Console**.
4. Make sure the vehicle is armed and flying, e.g. by entering the command: `commander takeoff`.
To check gimbal status enter:
```sh
gimbal status
```
To set the gimbal yaw to 30 degrees, use the command:
```sh
gimbal test yaw 30
```
More generally, you can set the angle or angular rate command using a command with this format:
```sh
gimbal test <axis> <value>
```
- `axis`:
- `<roll|pitch|yaw>` for angles
- `<rollrate|pitchrate|yawrate>` for angular rates
- `value`:
- `<degrees>` for angles
- `<degrees / second>` for angular rates
To set the MAVLink component that is in primary control of the gimbal:
```sh
gimbal primary-control <sys_id> <comp_id>
```
- `sys_id`: MAVLink system ID
- `comp_id`: MAVLink component ID
For other commands, see the [`gimbal`](../modules/modules_driver.md#gimbal) driver module document.
### MAVLink Testing
The gimbal can be tested by sending MAVLink gimbal manager commands using [MAVSDK](../robotics/mavsdk.md) or some other MAVLink library.
Note that the simulated gimbal stabilizes itself, so if you send MAVLink commands, set the `stabilize` flags to `false`.
docs/ko/advanced/index.md
+1
View File
@@ -0,0 +1 @@
# 고급 주제
docs/ko/advanced/out_of_tree_modules.md
+87
View File
@@ -0,0 +1,87 @@
# 외부 모듈(별도)
외부 모듈은 개발자가 PX4 펌웨어에 추가(또는 업데이트)하려는 독점 모듈을 관리/그룹화할 수 있는 편리한 메커니즘을 제공합니다.
외부 모듈은 내부 모듈과 같이 사용할 수 있으며, uORB로 내부 모듈과 상호 작용할 수 있습니다.
PX4 빌드에 외부("out of tree") 모듈을 추가하는 방법을 설명합니다.
:::tip
We encourage you to contribute your changes into PX4, where possible!
:::
## 사용법
외부 모듈을 만들려면:
- Create an _external directory_ folder for grouping the external modules:
- This can be located anywhere outside of the **PX4-Autopilot** tree.
- It must have the same structure as **PX4-Autopilot** (i.e. it must contain a directory called **src**).
- Later we refer to this directory using `EXTERNAL_MODULES_LOCATION`.
- Copy an existing module (e.g. **examples/px4_simple_app**) to the external directory, or directly create a new module.
- Rename the module (including `MODULE` in **CMakeLists.txt**) or remove it from the existing PX4-Autopilot _cmake_ build config.
이것은 내부 모듈과의 충돌을 피하기 위한 것입니다.
- Add a file **CMakeLists.txt** in the external directory with content:
```cmake
set(config_module_list_external
modules/<new_module>
PARENT_SCOPE
)
```
- Add a line `EXTERNAL` to the `modules/<new_module>/CMakeLists.txt` within
`px4_add_module()`, for example like this:
```cmake
px4_add_module(
MODULE modules__test_app
MAIN test_app
STACK_MAIN 2000
SRCS
px4_simple_app.c
DEPENDS
platforms__common
EXTERNAL
)
```
## 별도 uORB 메시지 정의
uORB 메시지는 트리 외부에서 정의할 수 있습니다. For this, the `$EXTERNAL_MODULES_LOCATION/msg` folder must exist.
- Place all new message definitions within the `$EXTERNAL_MODULES_LOCATION/msg` directory.
The format of these new out-of-tree message definitions are the same as for any other [uORB message definition](../middleware/uorb.md#adding-a-new-topic).
- Add a file `$EXTERNAL_MODULES_LOCATION/msg/CMakeLists.txt` with content:
```cmake
set(config_msg_list_external
<message1>.msg
<message2>.msg
<message3>.msg
PARENT_SCOPE
)
```
where `<message#>.msg` is the name of the uORB message definition file to be processed and used for uORB message generation.
외부 uORB 메시지는 일반 uORB 메시지와 동일한 위치에 생성됩니다.
The uORB topic headers are generated in `<build_dir>/uORB/topics/`, and the message source files are
generated in `<build_dir>/msg/topics_sources/`.
The new uORB messages can be used like any other uORB message as described [here](../middleware/uorb.md#adding-a-new-topic).
:::warning
The out-of-tree uORB message definitions cannot have the same name as any of the normal uORB messages.
:::
## 외부 모듈 및 uORB 메시지 빌드
Execute `make px4_sitl EXTERNAL_MODULES_LOCATION=<path>`.
다른 빌드 대상을 사용할 수 있지만, 빌드 디렉토리가 아직 존재하지 않아야 합니다.
If it already exists, you can also just set the _cmake_ variable in the build folder.
For subsequent incremental builds `EXTERNAL_MODULES_LOCATION` does not need to be specified.
docs/ko/advanced/package_delivery.md
+67
View File
@@ -0,0 +1,67 @@
# Package Delivery in Missions
<Badge type="tip" text="PX4 v1.14" />
A package delivery mission is an extension of a waypoint mission, where a user can plan delivering a package as a waypoint.
This topic explains the architecture for the package delivery feature.
It is intended for developers working on extending the architecture, for example to support new payload delivery mechanisms.
:::info
Currently only [Grippers](../peripherals/gripper.md) can be used for package delivery.
Winches are not yet supported.
:::
:::info
The detailed documentation on how to setup a package delivery mission plan can be found [here](../flying/package_delivery_mission.md).
Setup for the `payload_deliverer` module is covered in the documentation for the delivery mechanism, such as [Gripper](../peripherals/gripper.md#px4-configuration).
:::
## Package Delivery Architecture Diagram
![Package delivery architecture overview](../../assets/advanced_config/payload_delivery_mission_architecture.png)
Package Delivery feature is centered around the [VehicleCommand](../msg_docs/VehicleCommand.md) & [VehicleCommandAck](../msg_docs/VehicleCommandAck.md) messages.
The central idea lies in having an entity that handles the `DO_GRIPPER` or `DO_WINCH` vehicle command, executes it and sends back an acknowledgement when the successful delivery is confirmed.
Because PX4 automatically broadcasts the `VehicleCommand` uORB message to a UART port configured to communicate in MAVLink as a [`COMMAND_LONG`](https://mavlink.io/en/messages/common.html#COMMAND_LONG) message, an external payload can receive the command and execute it.
Likewise, since PX4 automatically translates the [`COMMAND_ACK`](https://mavlink.io/en/messages/common.html#COMMAND_ACK) message coming in from an external source through a UART port configured for MAVLink into a `vehicle_command_ack` uORB message, an external payload's acknowledgement for a successful package deployment can be received by PX4's `navigator` module.
Below, each entity involved in the package delivery architecture is explained.
## Navigator
Navigator handles the reception of the vehicle command ACK (described below).
Upon reception of a successful deployment ack message, it sets the flag in Mission block level to signal that the payload deployment has been successful.
This allows the mission to proceed to a next item (e.g. Waypoint) safely, as we are sure with the acknowledgement that the deployment has been successful.
## Vehicle Command ACK
We are waiting for the ACK coming from either internally (via `payload_deliverer` module), or externally (external entity sending the MAVLink message `COMMAND_ACK`) to determine if the package delivery action has been successful (either `DO_GRIPPER` or `DO_WINCH`).
## Mission
The Gripper / Winch command is placed as a `Mission Item`.
This is possible since all the Mission item has the `MAV_CMD` to execute (e.g. Land, Takeoff, Waypoint, etc) which can get set to either `DO_GRIPPER` or `DO_WINCH`.
In the Mission logic (green box above) if either Gripper/Winch mission item is reached, it implements brake_for_hold functionality (which sets the `valid` flag of the next mission item waypoint to `false`) for rotary wings (e.g. Multicopter) so that the vehicle would hold it's position while the deployment is getting executed.
For fixed-wing and other vehicles, no special braking condition is considered.
So if you have a loiter mission item for a fixed-wing, it will execute the delivery whilst doing the loiter, and won’t come to a stop (as it’s impossible)
## Mission Block
`MissionBlock` is the parent class of `Mission` that handles the part "Is Mission completed?".
This all performed in the `is_mission_item_reached_or_completed` function, to handle the time delay / mission item advancement.
Also it implements the actual issue_command function, which will issue a vehicle command corresponding to the mission item's `MAV_CMD`, which will then be received by an external payload or the `payload_deliverer` module internally.
## Payload Deliverer
This is a dedicated module that handles gripper / winch support, which is used for the standard [package delivery mission plan](../flying/package_delivery_mission.md).
Setup for the `payload_deliverer` module is covered within setting up an actual package release mechanism setup documentation like [Gripper](../peripherals/gripper.md#px4-configuration).
docs/ko/advanced/parameters_and_configurations.md
+365
View File
@@ -0,0 +1,365 @@
# Parameters & Configurations
PX4 uses the _param subsystem_ (a flat table of `float` and `int32_t` values) and text files (for startup scripts) to store its configuration.
This section discusses the _param_ subsystem in detail.
매개변수를 나열, 저장 및 로드하는 방법과 매개변수를 정의하고 지상국에서 사용하는 방법을 설명합니다.
:::tip
[System startup](../concept/system_startup.md) and the way that [frame configuration](../dev_airframes/adding_a_new_frame.md) startup scripts work are detailed on other pages.
:::
## 명령줄 사용법
The PX4 [system console](../debug/system_console.md) offers the [param](../modules/modules_command.md#param) tool, which can be used to set parameters, read their value, save them, and export and restore to/from files.
### 매개변수 가져오기 및 설정
The `param show` command lists all system parameters:
```sh
param show
```
To be more selective, a partial parameter name with wildcard "\*" can be used:
```sh
nsh> param show RC_MAP_A*
Symbols: x = used, + = saved, * = unsaved
x RC_MAP_AUX1 [359,498] : 0
x RC_MAP_AUX2 [360,499] : 0
x RC_MAP_AUX3 [361,500] : 0
x RC_MAP_ACRO_SW [375,514] : 0
723 parameters total, 532 used.
```
You can use the `-c` flag to show all parameters that have changed (from their defaults):
```sh
param show -c
```
You can use `param show-for-airframe` to show all parameters that have changed from their defaults for just the current airframe's definition file (and defaults it imports).
### 매개변수 내보내기 및 로드
You can save any parameters that have been _changed_ (that are different from airframe defaults).
The standard `param save` command will store the parameters in the current default file:
```sh
param save
```
인수가 제공되면, 이 새 위치 대신 매개변수를 저장합니다.
```sh
param save /fs/microsd/vtol_param_backup
```
There are two different commands to _load_ parameters:
- `param load` first does a full reset of all parameters to their defaults, and then overwrites parameter values with any values stored in the file.
- `param import` just overwrites parameter values with the values from the file and then saves the result (i.e. effectively calls `param save`).
The `load` effectively resets the parameters to the state when the parameters were saved (we say "effectively" because any parameters saved in the file will be updated, but other parameters may have different firmware-defined default values than when the parameters file was created).
By contrast, `import` merges the parameters in the file with the current state of the vehicle.
예를 들어, 시스템 설정의 나머지 부분을 덮어쓰지 않고 보정 데이터가 포함된 매개변수 파일을 가져오는 데 사용할 수 있습니다.
두 경우에 대한 예를 아래에서 설명합니다.
```sh
# 파일을 저장하고 나면 매개변수 값 초기화
param load /fs/microsd/vtol_param_backup
# 추가로 매개변수 값 저장 (불러온다고 해서 자동으로 끝나지는 않음)
param save
```
```sh
# 현재 매개변수 값 목록에 저장한 매개변수 값 병합
param import /fs/microsd/vtol_param_backup
```
## 매개변수 생성/정의
매개변수 정의에는 두 부분이 있습니다.
- [Parameter metadata](#parameter-metadata) specifies the default value for each parameter in firmware along with other metadata for presentation (and editing) of parameters in ground control stations and documentation.
- [C/C++ Code](#c-c-api) that provides access to get and/or subscribe to parameter values from within PX4 modules and drivers.
메타데이터와 코드를 작성하기 위한 몇 가지 접근 방식을 아래에서 설명합니다.
Where possible code should use newer [YAML metadata](#yaml-metadata) and [C++ API](#c-api) over the older C parameter/code definitions, as these are more flexible and robust.
Parameter metadata is [compiled into the firmware](#publishing-parameter-metadata-to-a-gcs),
and made available to ground stations via the [MAVLink Component Information service](https://mavlink.io/en/services/component_information.html).
### 매개변수 이름
매개변수 이름은 ASCII 문자 16자 이하입니다.
By convention, every parameter in a group should share the same (meaningful) string prefix followed by an underscore, and `MC_` and `FW_` are used for parameters related specifically to Multicopter or Fixed-wing systems.
이 관례는 강제 사항은 아닙니다.
The name must match in both code and [parameter metadata](#parameter-metadata) to correctly associate the parameter with its metadata (including default value in Firmware).
### C / C++ API
PX4 모듈 및 드라이버에서 매개변수 사용할 수 있는 C 및 C++ API가 있습니다.
API 간의 중요한 차이점 중 하나는 C++ 버전이 매개변수 값(예: GCS에서) 변경과 동기화하는 보다 효율적인 표준화 메커니즘이 있다는 것입니다.
매개변수는 언제든지 다른 값으로 변경될 수 있으므로, 동기화가 중요합니다.
Your code should _always_ use the current value from the parameter store.
If getting the latest version is not possible, then a reboot will be required after the parameter is changed (set this requirement using the `@reboot_required` metadata).
또한, C++ 버전은 유형 안전성이 더 우수하고 메모리 사용량이 적습니다.
단점은 매개변수 이름을 컴파일 타임에 알아야 하는 반면에, C API는 동적으로 생성된 이름을 문자열로 사용할 수 있습니다.
#### C++ API
The C++ API provides macros to declare parameters as _class attributes_.
You add some "boilerplate" code to regularly listen for changes in the [uORB Topic](../middleware/uorb.md) associated with _any_ parameter update.
그런 다음, 프레임워크 코드는 매개변수 속성에 영향을 미치는 uORB 메시지 추적을 처리하고 동기화 상태를 유지합니다.
나머지 코드에서는 정의된 매개변수 속성을 사용할 수 있으며, 항상 최신 상태를 유지합니다!
제일 먼저, 모듈 또는 드라이버의 클래스 헤더에 필요한 필수 헤더를 포함합니다.
- **px4_platform_common/module_params.h** to get the `DEFINE_PARAMETERS` macro:
```cpp
#include <px4_platform_common/module_params.h>
```
- **parameter_update.h** to access the uORB `parameter_update` message:
```cpp
#include <uORB/topics/parameter_update.h>
```
- **Subscription.hpp** for the uORB C++ subscription API:
```cpp
#include <uORB/Subscription.hpp>
```
Derive your class from `ModuleParams`, and use `DEFINE_PARAMETERS` to specify a list of parameters and their associated parameter attributes.
매개변수의 이름은 매개변수 메타데이터 정의와 동일하여야 합니다.
```cpp
class MyModule : ..., public ModuleParams
{
public:
...
private:
/**
* Check for parameter changes and update them if needed.
*/
void parameters_update();
DEFINE_PARAMETERS(
(ParamInt<px4::params::SYS_AUTOSTART>) _sys_autostart, /**< example parameter */
(ParamFloat<px4::params::ATT_BIAS_MAX>) _att_bias_max /**< another parameter */
)
// Subscriptions
uORB::SubscriptionInterval _parameter_update_sub{ORB_ID(parameter_update), 1_s};
};
```
매개변수 업데이트와 관련된 uORB 메시지를 확인하기 위해 상용구로 cpp 파일을 업데이트합니다.
Call `parameters_update();` periodically in code to check if there has been an update:
```cpp
void Module::parameters_update()
{
if (_parameter_update_sub.updated()) {
parameter_update_s param_update;
_parameter_update_sub.copy(&param_update);
// If any parameter updated, call updateParams() to check if
// this class attributes need updating (and do so).
updateParams();
}
}
```
위의 함수에서 :
- `_parameter_update_sub.updated()` tells us if there is _any_ update to the `param_update` uORB message (but not what parameter is affected).
- If there has been "some" parameter updated, we copy the update into a `parameter_update_s` (`param_update`), to clear the pending update.
- Then we call `ModuleParams::updateParams()`.
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
The parameter attributes (`_sys_autostart` and `_att_bias_max` in this case) can then be used to represent the parameters, and will be updated whenever the parameter value changes.
:::tip
The [Application/Module Template](../modules/module_template.md) uses the new-style C++ API but does not include [parameter metadata](#parameter-metadata).
:::
#### C API
C API는 모듈과 드라이버 모두에서 사용할 수 있습니다.
먼저 매개변수 API를 포함합니다.
```C
#include <parameters/param.h>
```
Then retrieve the parameter and assign it to a variable (here `my_param`), as shown below for `PARAM_NAME`.
The variable `my_param` can then be used in your module code.
```C
int32_t my_param = 0;
param_get(param_find("PARAM_NAME"), &my_param);
```
:::info
If `PARAM_NAME` was declared in parameter metadata then its default value will be set, and the above call to find the parameter should always succeed.
:::
`param_find()` is an "expensive" operation, which returns a handle that can be used by `param_get()`.
If you're going to read the parameter multiple times, you may cache the handle and use it in `param_get()` when needed
```cpp
# Get the handle to the parameter
param_t my_param_handle = PARAM_INVALID;
my_param_handle = param_find("PARAM_NAME");
# Query the value of the parameter when needed
int32_t my_param = 0;
param_get(my_param_handle, &my_param);
```
### 매개변수 메타데이터
PX4는 확장 매개변수 메타데이터 시스템을 사용하여 사용자에게 매개변수를 표시하고 펌웨어의 매개변수들의 기본값을 설정합니다.
:::tip
Correct metadata is critical for good user experience in a ground station.
:::
Parameter metadata can be stored anywhere in the source tree as either **.c** or **.yaml** parameter definitions (the YAML definition is newer, and more flexible).
일반적으로 연결된 모듈과 함께 저장됩니다.
The build system extracts the metadata (using `make parameters_metadata`) to build the [parameter reference](../advanced_config/parameter_reference.md) and the parameter information [used by ground stations](#publishing-parameter-metadata-to-a-gcs).
:::warning
After adding a _new_ parameter file you should call `make clean` before building to generate the new parameters (parameter files are added as part of the _cmake_ configure step, which happens for clean builds and if a cmake file is modified).
:::
#### YAML 메타데이터
:::info
At time of writing YAML parameter definitions cannot be used in _libraries_.
:::
YAML meta data is intended as a full replacement for the **.c** definitions.
다중 인스턴스 정의와 같은 새로운 기능과 함께 동일한 메타데이터를 모두 지원합니다.
- The YAML parameter metadata schema is here: [validation/module_schema.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml).
- An example of YAML definitions being used can be found in the MAVLink parameter definitions: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/module.yaml).
- YAML 파일은 다음을 추가하여 cmake 빌드 시스템에 등록됩니다.
```cmake
MODULE_CONFIG
module.yaml
```
to the `px4_add_module` section of the `CMakeLists.txt` file of that module.
#### 다중 인스턴스(템플릿) YAML 메타 데이터
Templated parameter definitions are supported in [YAML parameter definitions](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml) (templated parameter code is not supported).
The YAML allows you to define instance numbers in parameter names, descriptions, etc. using `${i}`.
예를 들어 아래는 MY_PARAM_1_RATE, MY_PARAM_2_RATE 등을 생성합니다.
```yaml
MY_PARAM_${i}_RATE:
description:
short: Maximum rate for instance ${i}
```
다음 YAML 정의는 시작과 끝 인덱스를 제공합니다.
- `num_instances` (default 1): Number of instances to generate (>=1)
- `instance_start` (default 0): First instance number. If 0, `${i}` expands to [0, N-1]\`.
For a full example see the MAVLink parameter definitions: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/module.yaml)
#### c 매개변수 메타데이터
The legacy approach for defining parameter metadata is in a file with extension **.c** (at time of writing this is the approach most commonly used in the source tree).
매개변수 메타데이터 섹션은 다음 예와 같습니다.
```cpp
/**
* Pitch P gain
*
* Pitch proportional gain, i.e. desired angular speed in rad/s for error 1 rad.
*
* @unit 1/s
* @min 0.0
* @max 10
* @decimal 2
* @increment 0.0005
* @reboot_required true
* @group Multicopter Attitude Control
*/
PARAM_DEFINE_FLOAT(MC_PITCH_P, 6.5f);
```
```cpp
/**
* Acceleration compensation based on GPS
* velocity.
*
* @group Attitude Q estimator
* @boolean
*/
PARAM_DEFINE_INT32(ATT_ACC_COMP, 1);
```
The `PARAM_DEFINE_*` macro at the end specifies the type of parameter (`PARAM_DEFINE_FLOAT` or `PARAM_DEFINE_INT32`), the name of the parameter (which must match the name used in code), and the default value in firmware.
주석 블록의 행은 모두 선택 사항이며, 주로 지상국에서 표시 및 편집 옵션을 제어합니다.
The purpose of each line is given below (for more detail see [module_schema.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml)).
```cpp
/**
* <title>
*
* <longer description, can be multi-line>
*
* @unit <the unit, e.g. m for meters>
* @min <the minimum sane value. Can be overridden by the user>
* @max <the maximum sane value. Can be overridden by the user>
* @decimal <the minimum sane value. Can be overridden by the user>
* @increment <the "ticks" in which this value will increment in the UI>
* @reboot_required true <add this if changing the param requires a system restart.>
* @boolean <add this for integer parameters that represent a boolean value>
* @group <a title for parameters that form a group>
*/
```
## GCS에 매개변수 메타데이터 게시
The parameter metadata JSON file is compiled into firmware (or hosted on the Internet), and made available to ground stations via the [MAVLink Component Metadata service](https://mavlink.io/en/services/component_information.html).
This ensures that metadata is always up-to-date with the code running on the vehicle.
This process is the same as for [events metadata](../concept/events_interface.md#publishing-event-metadata-to-a-gcs).
For more information see [PX4 Metadata (Translation & Publication)](../advanced/px4_metadata.md)
## 추가 정보
- [Finding/Updating Parameters](../advanced_config/parameters.md)
- [Parameter Reference](../advanced_config/parameter_reference.md)
- [Param implementation](https://github.com/PX4/PX4-Autopilot/blob/main/platforms/common/include/px4_platform_common/param.h#L129) (information on `.get()`, `.commit()`, and other methods)
docs/ko/advanced/px4_metadata.md
+89
View File
@@ -0,0 +1,89 @@
# PX4 Metadata
PX4 uses and generates data that has associated human- and machine- readable metadata:
- [Parameters](../advanced_config/parameters.md) configure PX4 behaviour.
- A parameter is represented by an ID string that maps to a value stored in PX4.
- The associated metadata includes a description of the setting, its possible values, information about how the value might be presented (say for bitmasks).
- [Events](../concept/events_interface.md) provide notification of events, such as reasons for a failsafe, low battery warnings, end of calibration, and so on.
- An event is represented by an id, and is sent with a log level and arguments.
- The associated metadata includes a message, a description and a list of arguments (including their type) of each event.
- [Actuators](../config/actuators.md) configuration customizes the specific geometry of the vehicle, assigns actuators and motors to flight controller outputs, and tests the actuator and motor response.
- The metadata contains information about supported vehicle geometries, a list of output drivers, and how to configure them.
- _QGroundControl_ uses that information to dynamically build a configuration UI.
The metadata and metadata translations are shared with external systems, such as QGroundControl, allowing them to display information about parameters and events, and to configure vehicle geometry and actuator output mappings.
This topic explains how you can define metadata and help translate strings (and "just for your information", how it all works).
## Metadata Translation
Translations for PX4 metadata are done using Crowdin in the [PX4-Metadata-Translations](https://crowdin.com/project/px4-metadata-translations) project.
For more information about working with PX4 and Crowdin see [Translation](../contribute/translation.md).
## Defining Metadata
PX4 metadata is defined in PX4 source code alongside its associated data.
This is done either in a C/C++ comment with special markup to indicate metadata fields and their values, or using YAML files.
For more information see the topics for each data type:
- [Parameters & Configurations > Creating/Defining Parameters](../advanced/parameters_and_configurations.md#creating-defining-parameters)
- [Events Interface](../concept/events_interface.md)
- [Actuator Metadata](#actuator-metadata) (below)
## Metadata Toolchain
The process for handling metadata is the same for all metadata types.
Metadata is collected into JSON files every time PX4 is built.
For most flight controllers (as most have enough FLASH available), the JSON file is xz-compressed and stored within the generated binary.
The file is then shared to ground stations using the MAVLink [Component Metadata Protocol](https://mavlink.io/en/services/component_information.html).
Using the component metadata protocol ensures that the recipient can always fetch up-to-date metadata for the code running on the vehicle.
Events metadata is also added to the log files, allowing log analysis tools (such as Flight Review) to use the correct metadata to display events.
Binaries for flight controller targets with constrained memory do not store the parameter metadata in the binary, but instead reference the same data stored on `px4-travis.s3.amazonaws.com`.
This applies, for example, to the [Omnibus F4 SD](../flight_controller/omnibus_f4_sd.md).
The metadata is uploaded via [github CI](https://github.com/PX4/PX4-Autopilot/blob/main/.github/workflows/metadata.yml) for all build targets (and hence will only be available once parameters have been merged into main).
:::info
You can identify memory constrained boards because they specify `CONFIG_BOARD_CONSTRAINED_FLASH=y` in their [px4board definition file](https://github.com/PX4/PX4-Autopilot/blob/main/boards/omnibus/f4sd/default.px4board).
If doing custom development on a FLASH-constrained board you can adjust the URL [here](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/component_information/CMakeLists.txt#L41) to point to another server.
:::
The metadata on `px4-travis.s3.amazonaws.com` is used if parameter metadata is not present on the vehicle.
It may also be used as a fallback to avoid a very slow download over a low-rate telemetry link.
The metadata JSON files for CI builds of `main` are also copied to the github repo: [PX4/PX4-Metadata-Translations](https://github.com/PX4/PX4-Metadata-Translations/).
This integrates with Crowdin to get translations, which are stored in the [translated](https://github.com/PX4/PX4-Metadata-Translations/tree/main/translated) folder as xz-compressed translation files for each language.
These are referenced by the vehicle component metadata, and are downloaded when needed.
For more information see [PX4-Metadata-Translations](https://github.com/PX4/PX4-Metadata-Translations/) and [Component Metadata Protocol > Translation](https://mavlink.io/en/services/component_information.html#translation).
:::info
The parameter XML file of the main branch is copied into the QGC source tree via CI and is used as a fallback in cases where no metadata is available via the component metadata protocol (this approach predates the existence of the component metadata protocol).
:::
### Actuator Metadata
The following diagram shows how actuator metadata is assembled from the source code and used by QGroundControl:
![Actuators Metadata](../../assets/diagrams/actuator_metadata_processing.svg)
<!-- Source: https://docs.google.com/drawings/d/1hMQmIijdFjr21rREcXj50qz0C1b47JW0OEa6p5P231k/edit -->
- **Left**: the metadata is defined in `module.yml` files in different modules.
The `control_allocator` modules defines the geometries, while each output driver defines its set of channels and configuration parameters.
[The schema file](https://github.com/PX4/PX4-Autopilot/blob/main/validation/module_schema.yaml) documents the structure of these yaml files.
- **Middle**: At build time, the `module.yml` files for all enabled modules for the currently built target are parsed and turned into an `actuators.json` file using the [Tools/module_config/generate_actuators_metadata.py](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/module_config/generate_actuators_metadata.py) script.
There is also [schema file](https://github.com/mavlink/mavlink/blob/master/component_metadata/actuators.schema.json) for this.
- **Right**: At runtime, the JSON file is requested by QGroundControl via MAVLink Component Metadata API (described above).
## 추가 정보
- [Parameters & Configurations](../advanced/parameters_and_configurations.md)
- [Events Interface](../concept/events_interface.md)
- [Translation](../contribute/translation.md)
- [Component Metadata Protocol](https://mavlink.io/en/services/component_information.html) (mavlink.io)
- [PX4-Metadata-Translations](https://github.com/PX4/PX4-Metadata-Translations/) (Github)
docs/ko/advanced/realsense_intel_driver.md
+105
View File
@@ -0,0 +1,105 @@
# 우분투에 인텔 리얼센스 R200 드라이버 설치
이 튜토리얼에서는 촬영 이미지를 ROS(Robot Operation System)를 통하여 액세스할 수 있도록, Linux 환경에서 Intel RealSense R200 카메라 드라이버를 설치 방법을 설명합니다.
RealSense R200 카메라 헤드는 다음과 같습니다.
![Intel Realsense Camera front view](../../assets/hardware/sensors/realsense/intel_realsense.png)
버추어 박스의 게스트 운영체제로 동작하는 우분투 운영체제(OS)에서 드라이버를 설치합니다.
The specifications of the host computer where the Virtual Box is running, the Virtual Box and the guest system are given below:
- 호스트 운영체제: 윈도우 8
- 프로세서: Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
- 버추어박스: 오라클 가상 머신. 버전 5.0.14 r105127
- 확장: Virtual Box용 확장 패키지 설치(USB3 지원에 필요)
- 게스트 운영체제: 리눅스 - 우분투 14.04.3 LTS
지침서의 순서는 다음 방식을 따릅니다. 첫 부분에서는 버추어박스에 게스트 운영체제로 우분투 14.04 설치 방법을 설명합니다. 두번째 부분에서는 ROS 인디고와 카메라 드라이버 설치 방법을 알려줍니다. The ensuing frequently used expressions have the following meaning:
- 버추어 박스(VB): 서로 다른 가상 머신을 실행하는 프로그램. 이 경우 오라클 가상 머신입니다.
- 가상 머신(VM): 버추어 박스에서 게스트 시스템으로 실행하는 운영체제. 이 경우 우분투를 지칭합니다.
## 버추어 박스에 우분투 14.04.3 LTS 설치
- 64비트 리눅스를 설치할 새 가상 머신(VM)을 만드십시오.
- Download the iso file of Ubuntu 14.04.3 LTS: ([ubuntu-14.04.3-desktop-amd64.iso](https://ubuntu.com/download/desktop)).
- 우분투를 설치하십시오:
- 설치 과정에서 다음 두가지 옵션을 끄십시오:
- 설치 중 업데이트 다운로드
- 서드파티 소프트웨어 설치
- 설치 후, 전체 데스크톱(화면)에 우분투 화면이 뜨도록 버추어 박스를 활성화합니다:
- Start VM Ubuntu and login, Click on **Devices->Insert Guest Additions CD image** in the menu bar of the Virtual Box.
- Click on **Run** and enter password on the windows that pop up in Ubuntu.
- 설치가 끝난 후에 가상머신을 다시 시작하십시오.
이제, 전체 데스크톱 화면에 가상 머신 화면이 표시되어야합니다.
- 업데이트 설치 여부를 묻는 창이 우분투에 뜰 경우, 거절하십시오.
- 버추어 박스 USB 3 컨트롤러 활성:
- 가상 머신을 종료합니다.
- 가상 머신 설정에서 메뉴 선택 USB로 이동하고 "USB 3.0(xHCI)"를 선택합니다.
Virtual Box용 확장 패키지를 설치한 경우에만 가능합니다.
- 가상 머신을 다시 시작합니다.
## ROS 인디고 설치
- Follow instructions given at [ROS indigo installation guide](http://wiki.ros.org/indigo/Installation/Ubuntu):
- 데스크톱 전체 버전을 설치하십시오.
- "Initialize rosdep"과 "Environment setup" 부분에 설명한 단계를 실행하십시오.
## 카메라 드라이버 설치
- git을 설치하십시오:
```sh
sudo apt-get install git
```
- Download and install the driver:
- Clone [RealSense_ROS repository](https://github.com/bestmodule/RealSense_ROS):
```sh
git clone https://github.com/bestmodule/RealSense_ROS.git
```
- Follow instructions given in [here](https://github.com/bestmodule/RealSense_ROS/tree/master/r200_install).
- 패키지 설치할 지 여부를 물어보면 엔터키를 입력하십시오.
```sh
Intel Low Power Subsystem support in ACPI mode (MFD_INTEL_LPSS_ACPI) [N/m/y/?] (NEW)
```
```sh
Intel Low Power Subsystem support in PCI mode (MFD_INTEL_LPSS_PCI) [N/m/y/?] (NEW)
```
```sh
Dell Airplane Mode Switch driver (DELL_RBTN) [N/m/y/?] (NEW)
```
- 설치 프로세스가 끝날 때 나타날 수 있는 다음 오류 메시지는 드라이버의 오작동으로 이어지지 않아야 합니다.
```sh
rmmod: ERROR: Module uvcvideo is not currently loaded
```
- 설치 과정이 끝나면, 가상 머신을 다시 시작하십시오.
- 카메라 드라이버 시험:
- 인텔 리얼센스 카메라 헤드를 USB3 케이블로 USB3 방식을 따르는 컴퓨터의 포트에 연결하십시오.
- Click on Devices->USB-> Intel Corp Intel RealSense 3D Camera R200 in the menu bar of the Virtual Box, in order to forward the camera USB connection to the Virtual Machine.
- [패키지 해제 폴더]/Bin/DSReadCameraInfo 파일을 실행하십시오:
- 다음 오류 메시지가 나타나면 카메라 연결을 해제하십시오(컴퓨터에서 물리적으로 USB 케이블을 뽑아내십시오). Plug it in again + Click on Devices->USB-> Intel Corp Intel RealSense 3D Camera R200 in the menu bar of the Virtual Box again and execute again the file [unpacked folder]/Bin/DSReadCameraInfo.
```sh
DSAPI call failed at ReadCameraInfo.cpp:134!
```
- 카메라 드라이버가 동작하고 Intel RealSense R200을 인식하면, Intel RealSense R200 카메라 헤드 정보를 살펴보아야 합니다.
- ROS 노들릿(nodlet) 설치 및 시험:
- Follow the installation instructions in the "Installation" section given [here](https://github.com/bestmodule/RealSense_ROS/blob/master/realsense_dist/2.3/doc/RealSense-ROS-R200-nodelet.md), to install the ROS nodlet.
- Follow the instructions in the "Running the R200 nodelet" section given [here](https://github.com/bestmodule/RealSense_ROS/blob/master/realsense_dist/2.3/doc/RealSense-ROS-R200-nodelet.md), to test the ROS nodlet together with the Intel RealSense R200 camera head.
- 모든 기능이 동작하면 ROS 토픽에 Intel RealSense R200 카메라로부터 제각기 다른 데이터 스트림이 나타납니다.
docs/ko/advanced/rtk_gps.md
+101
View File
@@ -0,0 +1,101 @@
# RTK GPS (PX4 통합)
[Real Time Kinematic](https://en.wikipedia.org/wiki/Real_Time_Kinematic) (RTK) provides centimeter-level GPS accuracy.
RTK와 PX4 통합 방법을 설명합니다.
:::tip
Instructions for _using_ RTK GNSS are provided in [Hardware > RTK GPS](../gps_compass/rtk_gps.md).
:::
## 개요
RTK는 신호 보다는 신호의 반송파 위상을 사용합니다.
여러 모바일 스테이션에서 실시간 수정을 제공하기 위하여 단일 참조 스테이션에 의존합니다.
PX4로 RTK를 설정에는 2개의 RTK GPS 모듈과 데이터 링크가 필요합니다.
The fixed-position ground-based GPS unit is called the _Base_ and the in-air unit is called the _Rover_.
The Base unit connects to _QGroundControl_ (via USB) and uses the datalink to stream RTCM corrections to the vehicle (using the MAVLink [GPS_RTCM_DATA](https://mavlink.io/en/messages/common.html#GPS_RTCM_DATA) message).
자동조종장치에서 MAVLink 패킷의 압축을 풀고 로버에 전송하여, RTK 솔루션을 처리합니다.
The datalink should typically be able to handle an uplink rate of 300 bytes per second (see the [Uplink Datarate](#uplink-datarate) section below for more information).
## 지원 RTK GPS 모듈
The list of devices that we have tested can be found [in the user guide](../gps_compass/rtk_gps.md#supported-devices).
:::info
Most devices come with two variants, a base and a rover.
올바른 변형을 선택하여야 합니다.
:::
## 자동 설정
The PX4 GPS stack automatically sets up the GPS modules to send and receive the correct messages over the UART or USB, depending on where the module is connected (to _QGroundControl_ or the autopilot).
As soon as the autopilot receives `GPS_RTCM_DATA` MAVLink messages, it automatically forwards the RTCM data to the attached GPS module over existing data channels (a dedicated channel for correction data is not required).
:::info
The u-blox U-Center RTK module configuration tool is not needed/used!
:::
:::info
Both _QGroundControl_ and the autopilot firmware share the same [PX4 GPS driver stack](https://github.com/PX4/GpsDrivers).
실제로, 새 프로토콜 또는 메시지 지원시 한쪽에만 추가하면 됩니다.
:::
### RTCM 메시지
명시되어 있지 않은 경우에는 QGroundControl은 RTCM3.2 프레임을 1Hz로 출력하도록 RTK 베이스 스테이션을 구성합니다.
- **1005** - Station coordinates XYZ for antenna reference point (Base position), 0.2 Hz.
- **1077** - Full GPS pseudo-ranges, carrier phases, Doppler and signal strength (high resolution).
- **1087** - Full GLONASS pseudo-ranges, carrier phases, Doppler and signal strength (high resolution).
- **1230** - GLONASS code-phase biases.
- **1097** - Full Galileo pseudo-ranges, carrier phases, Doppler and signal strength (high resolution)
- **1127** - Full BeiDou pseudo-ranges, carrier phases, Doppler and signal strength (high resolution)
## 업링크 데이터 속도
The raw RTCM messages from the base are packed into a MAVLink `GPS_RTCM_DATA` message and sent over the datalink.
MAVLink 메시지의 최대 길이는 182바이트입니다. RTCM 메시지에 따라 MAVLink 메시지는 채워지지 않을 수도 있습니다.
RTCM Base Position 메시지(1005)의 길이는 22바이트이고, 나머지는 모두 가시 위성의 수와 위성의 신호 수에 따라 가변 길이입니다(M8P와 같은 L1 장치의 경우 1만).
Since at a given time, the _maximum_ number of satellites visible from any single constellation is 12, under real-world conditions, theoretically an uplink rate of 300 B/s is sufficient.
If _MAVLink 1_ is used, a 182-byte `GPS_RTCM_DATA` message is sent for every RTCM message, irrespective of its length.
결과적으로, 대략적인 업링크 요구 사항은 초당 약 700+바이트입니다.
이는 저대역폭 반이중 원격 측정 모듈(예: 3DR 원격 측정 라디오)에서 링크 포화로 이어질 수 있습니다.
If _MAVLink 2_ is used then any empty space in the `GPS_RTCM_DATA message` is removed.
결과적인 업링크 요구 사항은 이론적인 값(초당 ~300바이트)과 거의 같습니다.
:::tip
PX4 automatically switches to MAVLink 2 if the GCS and telemetry modules support it.
:::
MAVLink 2는 고성능 RTK을 위하여, 낮은 대역폭 링크를 사용합니다. 텔레메트리 체인에서 MAVLink 2를 사용하는지를 확인해야합니다.
You can verify the protocol version by using the `mavlink status` command on the system console:
```sh
nsh> mavlink status
instance #0:
GCS heartbeat: 593486 us ago
mavlink chan: #0
type: 3DR RADIO
rssi: 219
remote rssi: 219
txbuf: 94
noise: 61
remote noise: 58
rx errors: 0
fixed: 0
flow control: ON
rates:
tx: 1.285 kB/s
txerr: 0.000 kB/s
rx: 0.021 kB/s
rate mult: 0.366
accepting commands: YES
MAVLink version: 2
transport protocol: serial (/dev/ttyS1 @57600)
```
docs/ko/advanced/switching_state_estimators.md
+48
View File
@@ -0,0 +1,48 @@
# 상태 추정기 전환
어떤 상태 추정기를 사용할 수 있고 어떻게 전환할 수 있는 지를 설명합니다.
:::tip
EKF2 is the default and should be used unless you have a reason not to (in particular on vehicles with a GNSS/GPS).
The Q-Estimator can be used if you don't have GPS, and is commonly used in [multicopter racers](../config_mc/racer_setup.md).
:::
## 가용 추정기
사용 가능한 추정기는 다음과 같습니다.
- **EKF2 attitude, position and wind states estimator** (_recommended_) - An extended Kalman filter estimating attitude, 3D position / velocity and wind states.
- **LPE position estimator** (_deprecated_) - An extended Kalman filter for 3D position and velocity states.
:::warning
LPE is deprecated.
It works (at time of writing, in PX4 v1.14) but is no longer supported or maintained.
:::
- **Q attitude estimator** - A very simple, quaternion based complementary filter for attitude.
It does not require a GPS, magnetometer, or barometer.
<!-- Q estimator is supported (at time of writing in PX4 v1.14). Test added in PX4-Autopilot/pull/21922 -->
## 다양한 추정기 활성화 방법
<!-- Changed in https://github.com/PX4/PX4-Autopilot/pull/22567 after v1.14 -->
To enable a particular estimator enable its parameter and disable the others:
- [EKF2_EN](../advanced_config/parameter_reference.md#EKF2_EN) - EKF2 (default/recommended)
- [ATT_EN](../advanced_config/parameter_reference.md#ATT_EN) - Q Estimator (quaternion based attitude estimator)
- [LPE_EN](../advanced_config/parameter_reference.md#LPE_EN) - LPE (not supported for Fixed-wing)
:::warning
It is important to enable one, and only one, estimator.
If more than one is enabled, the first to publish the UOrb topics [vehicle_attitude](../msg_docs/VehicleAttitude.md) or [vehicle_local_position](../msg_docs/VehicleLocalPosition.md) is used.
If none are enabled then the topics are not published.
:::
:::info
For FMU-v2 (only) you will also need to build PX4 to specifically include required estimator (e.g. EKF2: `make px4_fmu-v2`, LPE: `make px4_fmu-v2_lpe`).
이는 FMU-v2가 두 추정기를 모두 포함하기에는 리소스가 너무 제한되어 있기 때문입니다.
다른 Pixhawk FMU 버전에는 둘 다 포함되어 있습니다.
:::
docs/ko/advanced/system_tunes.md
+92
View File
@@ -0,0 +1,92 @@
# 시스템 알림음
PX4 defines a number of [standard tones/tunes](../getting_started/tunes.md) that are used to provide audio notification for important system states and problems (e.g. system startup, arming success, battery warnings, etc.)
Tunes are specified using strings (in [ANSI Music notation](http://artscene.textfiles.com/ansimusic/information/ansimtech.txt)) and played by code using the [tunes](https://github.com/PX4/PX4-Autopilot/tree/main/src/lib/tunes) library.
The tunes library also contains the list of default system tunes - see [lib/tunes/tune_definition.desc](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc).
PX4에는 기본 알림음 또는 사용자 정의 알림음을 재생(테스트)하는 모듈이 있습니다.
자체 알림음을 만들고 시스템 알림음을 추가/교체하는 방법을 설명합니다.
## 알림음 만들기
Tune strings are defined using [ANSI Music notation](http://artscene.textfiles.com/ansimusic/information/ansimtech.txt).
:::tip
More information about the format can be found in [QBasic PLAY statement](https://en.wikibooks.org/wiki/QBasic/Appendix#PLAY) (Wikibooks) and has been reproduced in [tune_definition.desc](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc).
:::
새로운 곡을 만드는 가장 쉬운 방법은 음악 편집기를 사용하는 것입니다.
이를 통해 음악을 편집하고 컴퓨터에서 재생한 다음 PX4에서 재생할 수 있는 형식으로 내보낼 수 있습니다.
ANSI 음악은 ANSI BBS 시스템 시대에 인기가 있었고, 최고의 편집 도구는 DOS 유틸리티입니다.
On Windows, one option is to use _Melody Master_ within _Dosbox_.
소프트웨어 사용 절차는 다음과 같습니다.
1. Download [DosBox](http://www.dosbox.com/) and install the app
2. Download [Melody Master](ftp://archives.thebbs.org/ansi_utilities/melody21.zip) and unzip into a new directory
3. Open the _Dosbox_ console
4. 멜로디 마스터 디렉터리를 아래와 같이 도스박스에서 마운트하십시오.
```sh
mount c C:\<path_to_directory\Melody21
```
5. Start _Melody Master_ with the following commands
```sh
c:
start
```
6. You will then have the option to click through a few screens, then press **1** to display _Melody Master_:
![Melody Master 2.1](../../assets/tunes/tunes_melody_master_2_1.jpg)
화면의 절반 하단부에서 도구 사용에 필요한 키보드 단축키를 안내해줍니다(악보를 움직이고 음표 길이를 선택할 수 있는 등의 작업 가능).
7. 음악을 저장할 준비가 끝나면:
- Press **F2** to give the tune a name and save it in the _/Music_ sub folder of your Melody Master installation.
- Press **F7**, the scroll down the list of output formats on the right to get to ANSI.
The file will be exported to the _root_ of the Melody Master directory (with the same name and a file-type specific extension).
8. 파일을 여십시오.
출력 내용은 다음과 같습니다:
![ANSI Output from file](../../assets/tunes/tune_musicmaker_ansi_output.png)
9. The string that can be played in PX4 is the bit between `MNT` and `P64`: `150L1O3DL16CL32<B>C<AEL16A`
## 알림음 시험
When you're ready to try it out a new tune on PX4, use the [tune_control](../modules/modules_system.md#tune-control) library.
For example, to test the tune we "created" above you would enter the following command on a console or shell (e.g. the [MAVLink Shell](../debug/mavlink_shell.md)):
```sh
tune_control play -m "150L1O3DL16CL32<B>C<AEL16A"
```
:::info
Out of the box, the `tune_control` is only present on real hardware (not the simulator).
:::
## 기존 알림음 변경
Tunes are defined within [tune_definition.desc](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/tunes/tune_definition.desc).
If you just need to replace an existing tune, then you can replace the file in your own fork, and update the tune strings defined in `PX4_DEFINE_TUNE`.
## 새 알림음 추가
곧 추가 예정.
<!--
1. Assumption is that you need to define a new `PX4_DEFINE_TUNE` with its own number in the file.
2. Need to look at how tunes are played. Problem for another day.
-->