mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-05-19 20:19:06 +08:00
New Crowdin translations - ko (#24713)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
PX4 Build Bot
GitHub
parent
601b06532a
commit
2f104ed83f
@ -716,6 +716,10 @@
|
||||
- [YawEstimatorStatus](msg_docs/YawEstimatorStatus.md)
|
||||
- [VehicleStatusV0](msg_docs/VehicleStatusV0.md)
|
||||
- [MAVLink Messaging](middleware/mavlink.md)
|
||||
- [Adding Messages](mavlink/adding_messages.md)
|
||||
- [Streaming Messages](mavlink/streaming_messages.md)
|
||||
- [Receiving Messages](mavlink/receiving_messages.md)
|
||||
- [Custom MAVLink Messages](mavlink/custom_messages.md)
|
||||
- [Standard Modes Protocol](mavlink/standard_modes.md)
|
||||
- [uXRCE-DDS (PX4-ROS 2/DDS Bridge)](middleware/uxrce_dds.md)
|
||||
- [모듈과 명령어](modules/modules_main.md)
|
||||
|
||||
@ -89,7 +89,7 @@ This protocol is commonly use is for connecting [optical flow](../sensor/optical
|
||||
| SCK | ![black][blkcircle] Black | ![yellow][ycircle] Yellow |
|
||||
| MISO | ![black][blkcircle] Black | ![blue][bluecircle] Blue |
|
||||
| MOSI | ![black][blkcircle] Black | ![green][gcircle] Green |
|
||||
| CS! | ![black][blkcircle] Black | ![white][wcircle] White |
|
||||
| CS1 | ![black][blkcircle] Black | ![white][wcircle] White |
|
||||
| CS2 | ![black][blkcircle] Black | ![blue][bluecircle] Blue |
|
||||
| GND | ![black][blkcircle] Black | ![black][blkcircle] Black |
|
||||
|
||||
|
||||
@ -83,7 +83,7 @@ void Mission::setActiveMissionItems() => https://github.com/PX4/PX4-Autopilot/bl
|
||||
Issuing command:
|
||||
MissionBlock::issue_command(const mission_item_s &item) => https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/navigator/mission_block.cpp#L543-L562
|
||||
At end this publishes the current vehicle command
|
||||
_navigator->publish_vehicle_command(vehicle_command);
|
||||
_navigator.publish_vehicle_command(vehicle_command);
|
||||
|
||||
Publishing command:
|
||||
void Navigator::publish_vehicle_command(vehicle_command_s &vehicle_command) => https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/navigator/navigator_main.cpp#L1395
|
||||
|
||||
@ -376,3 +376,31 @@ This section explains how you might manually run the same steps as the script (s
|
||||
```sh
|
||||
CONFIG_PUBLIC_KEY1="../../../keys/public/public_key.pub"
|
||||
```
|
||||
|
||||
## Flight Review & Encrypted logs
|
||||
|
||||
If your logs are secret enough to require encryption it is likely that you will not trust them on the public [Flight Review](../getting_started/flight_reporting.md) server (this is not particularly hardened against data loss or theft).
|
||||
|
||||
:::info
|
||||
The public [Flight Review](../getting_started/flight_reporting.md) service does not support encrypted logs.
|
||||
If you wish to use the service you can use the tools here to download and decrypt the files first.
|
||||
:::
|
||||
|
||||
This section explains how you can host a _private_ instance of the Flight Review server.
|
||||
This can use logs that you have downloaded and decrypted yourself, or you can include your private key in the server for automatic decryption of logs on upload.
|
||||
|
||||
단계는 다음과 같습니다:
|
||||
|
||||
1. Follow the Flight Review [installation and setup](https://github.com/PX4/flight_review?tab=readme-ov-file#installation-and-setup) instructions to clone and setup the server.
|
||||
|
||||
2. Put your private key in the source code at: `flight_review/app/private_key/private_key.pem`
|
||||
|
||||
3. Add this key location into the server config file: `flight_review/app/config_default.ini`.
|
||||
|
||||
The line to add should look something like this (for the file above):
|
||||
|
||||
```sh
|
||||
ulge_private_key = ../private_key/private_key.pem
|
||||
```
|
||||
|
||||
4. Follow the Flight Review Instructions to start your server.
|
||||
|
||||
@ -33,22 +33,15 @@ If needed you can also [get the source code specific to a particular release](..
|
||||
먼저 콘솔 환경에서 시뮬레이션 대상을 빌드합니다.
|
||||
이를 통하여 실제 하드웨어와 IDE로 사용전에 시스템 설정을 검증할 수 있습니다.
|
||||
|
||||
Navigate into the **PX4-Autopilot** directory.
|
||||
Depending on your operating system you will have installed either [Gazebo SITL](../sim_gazebo_gz/index.md) or [Gazebo Classic SITL](../sim_gazebo_classic/index.md) (if you don't know which you can try both).
|
||||
|
||||
:::: tabs
|
||||
|
||||
:::tab Gazebo
|
||||
Start [Gazebo SITL](../sim_gazebo_gz/index.md) using the following command:
|
||||
Navigate into the **PX4-Autopilot** directory and start [Gazebo SITL](../sim_gazebo_gz/index.md) using the following command:
|
||||
|
||||
```sh
|
||||
make px4_sitl gz_x500
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
:::tab Gazebo-Classic
|
||||
Start [Gazebo SITL](../sim_gazebo_gz/index.md) using the following command:
|
||||
:::details
|
||||
If you installed Gazebo Classic
|
||||
Start [Gazebo Classic SITL](../sim_gazebo_classic/index.md) using the following command:
|
||||
|
||||
```sh
|
||||
make px4_sitl gazebo-classic
|
||||
@ -56,8 +49,6 @@ make px4_sitl gazebo-classic
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
|
||||
This will bring up the PX4 console:
|
||||
|
||||
|
||||
@ -73,19 +64,9 @@ The drone can be flown by typing the following command (as shown in the console
|
||||
pxh> commander takeoff
|
||||
```
|
||||
|
||||
The vehicle will take off and you'll see this in the simulator UI:
|
||||
The vehicle will take off and you'll see this in the Gazebo simulator UI:
|
||||
|
||||
:::: tabs
|
||||
|
||||
:::tab Gazebo
|
||||
|
||||
:::
|
||||
|
||||
:::tab Gazebo-Classic
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
|
||||
The drone can be landed by typing `commander land` and the whole simulation can be stopped by doing **CTRL+C** (or by entering `shutdown`).
|
||||
|
||||
|
||||
@ -1,20 +1,24 @@
|
||||
# 우분투 개발 환경
|
||||
|
||||
The following instructions use a bash script to set up the PX4 development environment on the [Ubuntu Linux LTS](https://wiki.ubuntu.com/LTS) versions supported by PX4: Ubuntu 22.04 (Jammy Jellyfish), 20.04 (Focal Fossa), and 18.04 (Bionic Beaver).
|
||||
The following instructions use a bash script to set up the PX4 development environment on the [Ubuntu Linux LTS](https://wiki.ubuntu.com/LTS) versions supported by PX4: Ubuntu 24.04 (Nimble Numbat) and Ubuntu 22.04 (Jammy Jellyfish).
|
||||
|
||||
The environment includes:
|
||||
|
||||
- [Gazebo Simulator](../sim_gazebo_gz/index.md) ("Harmonic") on Ubuntu 22.04
|
||||
- [Gazebo Classic Simulator](../sim_gazebo_classic/index.md) on Ubuntu 20.04 and Ubuntu 18.04
|
||||
- [Gazebo Simulator](../sim_gazebo_gz/index.md) ("Harmonic")
|
||||
- [Build toolchain for Pixhawk (and other NuttX-based hardware)](../dev_setup/building_px4.md#nuttx-pixhawk-based-boards).
|
||||
|
||||
:::info
|
||||
The build toolchain for other flight controllers, simulators, and working with ROS are discussed in the [Other Targets](#other-targets) section below.
|
||||
:::
|
||||
On Ubuntu 22.04:
|
||||
|
||||
:::tip
|
||||
if you need to use Gazebo on Ubuntu 20.04 you can [manually install Gazebo "Garden"](../sim_gazebo_gz/index.md#installation-ubuntu-linux), with the caveat that this is end-of-life in November 2024.
|
||||
If you want to use Gazebo Classic on Ubuntu 22.04 (say) then you can manually install it by following the instructions in [Gazebo Classic > Installation](../sim_gazebo_classic/index.md#installation).
|
||||
- [Gazebo Classic Simulator](../sim_gazebo_classic/index.md) can be used instead of Gazebo.
|
||||
Gazebo is nearing feature-parity with Gazebo-Classic on PX4, and will soon replace it for all use cases.
|
||||
|
||||
The build toolchain for other flight controllers, simulators, and working with ROS are discussed in the [Other Targets](#other-targets) section below.
|
||||
|
||||
:::details
|
||||
Can I use an older version of Ubuntu?
|
||||
PX4 supports the current and last Ubuntu LTS release where possible.
|
||||
Older releases are not supported (so you can't raise defects against them), but may still work.
|
||||
For example, Gazebo Classic setup is included in our standard build instructions for macOS, Ubuntu 18.04 and 20.04, and Windows on WSL2 for the same hosts.
|
||||
:::
|
||||
|
||||
## Simulation and NuttX (Pixhawk) Targets
|
||||
@ -48,7 +52,9 @@ The script is intended to be run on _clean_ Ubuntu LTS installations, and may no
|
||||
- 스크립트가 진행되는 동안 모든 프롬프트를 확인합니다.
|
||||
- You can use the `--no-nuttx` and `--no-sim-tools` options to omit the NuttX and/or simulation tools.
|
||||
|
||||
3. 완료되면 컴퓨터를 재부팅합니다.
|
||||
3. If you need Gazebo Classic (Ubuntu 22.04 only) then you can manually remove Gazebo and install it by following the instructions in [Gazebo Classic > Installation](../sim_gazebo_classic/index.md#installation).
|
||||
|
||||
4. 완료되면 컴퓨터를 재부팅합니다.
|
||||
|
||||
:::details
|
||||
Additional notes
|
||||
@ -62,8 +68,8 @@ These notes are provided "for information only":
|
||||
```sh
|
||||
$arm-none-eabi-gcc --version
|
||||
|
||||
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)
|
||||
Copyright (C) 2019 Free Software Foundation, Inc.
|
||||
arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009
|
||||
Copyright (C) 2023 Free Software Foundation, Inc.
|
||||
This is free software; see the source for copying conditions. There is NO
|
||||
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
||||
```
|
||||
@ -80,17 +86,6 @@ These notes are provided "for information only":
|
||||
|
||||
:::
|
||||
|
||||
## 영상 가이드
|
||||
|
||||
This video shows how to install the toolchain for NuttX and simulation targets ([as covered below](#simulation-and-nuttx-pixhawk-targets)) along with the basic testing covered in [Building PX4 Software](../dev_setup/building_px4.md).
|
||||
|
||||
:::warning
|
||||
The video suggests that you build source using JMAVSim, entering the command: `make px4_sitl jmavsim`.
|
||||
As JMAVSim is now community-supported, you should instead build using Gazebo or Gazebo Classic, as shown in [Building the Code](../dev_setup/building_px4.md#first-build-using-a-simulator)
|
||||
:::
|
||||
|
||||
<lite-youtube videoid="OtValQdAdrU" title=" Setting up your PX4 development environment on Linux"/>
|
||||
|
||||
## Other Targets
|
||||
|
||||
The Ubuntu development environment for ROS, other simulators, and other hardware targets, is covered in their respective documentation.
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
PX4 개발에 VSCode를 사용하는 데에는 많은 이유가 있습니다.
|
||||
|
||||
- Getting setup _really_ only takes a few minutes.
|
||||
- A rich extension ecosystem that enables a huge range of tools needed for PX4 development: C/C++ (with solid _cmake_ integration), _Python_, _Jinja2_, ROS messages, and even DroneCAN dsdl.
|
||||
- A rich extension ecosystem that enables a huge range of tools needed for PX4 development: C/C++ (with solid _cmake_ integration), _Python_, _Jinja2_, ROS messages, and even DroneCAN DSDL.
|
||||
- 뛰어난 Github 통합 기능
|
||||
|
||||
IDE를 설정과 개발 방법에 대하여 설명합니다.
|
||||
@ -26,7 +26,9 @@ You must already have installed the command line [PX4 developer environment](../
|
||||
2. Open VSCode and add the PX4 source code:
|
||||
|
||||
- Select _Open folder ..._ option on the welcome page (or using the menu: **File > Open Folder**):
|
||||
|
||||
|
||||
|
||||
- A file selection dialog will appear.
|
||||
Select the **PX4-Autopilot** directory and then press **OK**.
|
||||
|
||||
|
||||
@ -7,10 +7,10 @@ Contact the [manufacturer](https://holybro.com/) for hardware support or complia
|
||||
|
||||
_Pixhawk 6C Mini_<sup>®</sup> is the latest update to the successful family of Pixhawk® flight controllers designed and made in collaboration with Holybro<sup>®</sup> and the PX4 team.
|
||||
|
||||
It is equipped with a high performance H7 Processor, and comes with IMU redundancy, temperature-controlled IMU board, and cost effective design, delivering incredible performance and reliability.
|
||||
It is equipped with a high performance H7 Processor and comes with IMU redundancy, temperature-controlled IMU board, and cost effective design, delivering incredible performance and reliability.
|
||||
It complies with the Pixhawk [Connector Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-009%20Pixhawk%20Connector%20Standard.pdf).
|
||||
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
This autopilot is [supported](../flight_controller/autopilot_pixhawk_standard.md) by the PX4 maintenance and test teams.
|
||||
@ -22,33 +22,33 @@ The Pixhawk® 6C Mini is the latest update to the successful family of Pixhawk®
|
||||
|
||||
Inside the Pixhawk® 6C Mini, you can find an STMicroelectronics® based STM32H743, paired with sensor technology from Bosch® & InvenSense®, giving you flexibility and reliability for controlling any autonomous vehicle, suitable for both academic and commercial applications.
|
||||
|
||||
The Pixhawk® 6C Mini's H7 microcontroller contain the Arm® Cortex®-M7 core running up to 480 MHz, has 2MB flash memory and 1MB RAM.
|
||||
The Pixhawk® 6C Mini's H7 microcontroller contain the Arm® Cortex®-M7 core running up to 480 MHz, and has 2MB flash memory and 1MB RAM.
|
||||
Thanks to the updated processing power, developers can be more productive and efficient with their development work, allowing for complex algorithms and models.
|
||||
|
||||
The Pixhawk 6C Mini includes high-performance, low-noise IMUs on board, designed to be cost effective while having IMU redundancy.
|
||||
A vibration isolation System to filter out high-frequency vibration and reduce noise to ensure accurate readings, allowing vehicles to reach better overall flight performances.
|
||||
|
||||
The Pixhawk® 6C Mini is perfect for developers at corporate research labs, startups, academics (research, professors, students), and commercial application.
|
||||
The Pixhawk® 6C Mini is perfect for developers at corporate research labs, startups, academics (research, professors, students), and commercial applications.
|
||||
|
||||
**Key Design Points**
|
||||
|
||||
- High performance STM32H743 Processor with more computing power & RAM
|
||||
- New cost-effective design with low-profile form factor
|
||||
- Newly designed integrated vibration isolation system to filter out high frequency vibration and reduce noise to ensure accurate readings
|
||||
- IMUs are temperature-controlled by onboard heating resistors, allowing optimum working temperature of IMUs 
|
||||
- IMUs are temperature-controlled by onboard heating resistors, allowing optimum working temperature of IMUs 
|
||||
|
||||
## Technical Specification
|
||||
|
||||
### **Processors & Sensors**
|
||||
|
||||
- FMU Processor: STM32H743 
|
||||
- 32 Bit Arm® Cortex®-M7, 480MHz, 2MB memory, 1MB SRAM 
|
||||
- FMU Processor: STM32H743 
|
||||
- 32 Bit Arm® Cortex®-M7, 480MHz, 2MB memory, 1MB SRAM 
|
||||
- IO Processor: STM32F103
|
||||
-  32 Bit Arm® Cortex®-M3, 72MHz, 64KB SRAM 
|
||||
- On-board sensors 
|
||||
-  Accel/Gyro: ICM-42688-P 
|
||||
- Accel/Gyro: BMI055 
|
||||
- Mag: IST8310 
|
||||
-  32 Bit Arm® Cortex®-M3, 72MHz, 64KB SRAM 
|
||||
- On-board sensors 
|
||||
-  Accel/Gyro: ICM-42688-P 
|
||||
- Accel/Gyro: BMI055 
|
||||
- Mag: IST8310 
|
||||
- 기압계: MS5611
|
||||
|
||||
### **Electrical data**
|
||||
@ -64,7 +64,7 @@ The Pixhawk® 6C Mini is perfect for developers at corporate research labs, star
|
||||
### **Mechanical data**
|
||||
|
||||
- Dimensions: 53.3 x 39 x 16.2 mm
|
||||
- Weight : 39.2g
|
||||
- Weight: 39.2g
|
||||
|
||||
### **Interfaces**
|
||||
|
||||
@ -123,7 +123,8 @@ Please refer to the [Pixhawk 4 Mini Wiring Quick Start](../assembly/quick_start_
|
||||
|
||||
## 크기
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 정격 전압
|
||||
|
||||
@ -131,14 +132,14 @@ _Pixhawk 6C Mini_ can be double-redundant on the power supply if two power sourc
|
||||
|
||||
**Normal Operation Maximum Ratings**
|
||||
|
||||
이러한 조건에서 전원은 아래의 순서대로 시스템에 전원을 공급하여야합니다.
|
||||
이러한 조건에서 전원은 아래의 순서대로 시스템에 전원을 공급하여야 합니다.
|
||||
|
||||
1. **POWER1** inputs (4.9V to 5.5V)
|
||||
2. **USB** input (4.75V to 5.25V)
|
||||
|
||||
**Absolute Maximum Ratings**
|
||||
|
||||
아래의 조건에서 시스템은 전원을 사용하지 않지만(작동하지 않음), 그대로 유지됩니다.
|
||||
Under these conditions, the system will not draw any power (will not be operational), but will remain intact.
|
||||
|
||||
1. **POWER1** inputs (operational range 4.1V to 5.7V, 0V to 10V undamaged)
|
||||
2. **USB** input (operational range 4.1V to 5.7V, 0V to 6V undamaged)
|
||||
|
||||
@ -9,30 +9,44 @@ _Pixhawk 6X_<sup>®</sup> is the latest update to the successful family of Pi
|
||||
|
||||
It is based on the [Pixhawk® Autopilot FMUv6X Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-012%20Pixhawk%20Autopilot%20v6X%20Standard.pdf), [Autopilot Bus Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-010%20Pixhawk%20Autopilot%20Bus%20Standard.pdf), and [Connector Standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-009%20Pixhawk%20Connector%20Standard.pdf).
|
||||
|
||||
Equipped with a high performance H7 Processor, modular design, triple redundancy, temperature-controlled IMU board, isolated sensor domains, delivering incredible performance, reliability, and flexibility.
|
||||
Equipped with a high-performance H7 Processor, modular design, triple redundancy, temperature-controlled IMU board, and isolated sensor domains, delivering incredible performance, reliability, and flexibility.
|
||||
|
||||
### Pixhawk 6X (Rev 3)
|
||||
### Pixhawk 6X (Rev 8)
|
||||
|
||||
<img src="../../assets/flight_controller/pixhawk6x/pixhawk6x_hero_upright.png" width="230px" title="Pixhawk6X Upright Image" /> <img src="../../assets/flight_controller/pixhawk6x/pixhawk6x_exploded_diagram.png" width="400px" title="Pixhawk6X Exploded Image" />
|
||||
<img src="../../assets/flight_controller/pixhawk6x/HB_6X_rev8_V2A.png" width="420px"/><img src="../../assets/flight_controller/pixhawk6x/hb_6x_internal_v2.png" width="320px"/>
|
||||
|
||||
### Pixhawk 6X (ICM-45686)
|
||||
#### Pixhawk 6X (Rev 3/4, discontinued)
|
||||
|
||||
<img src="../../assets/flight_controller/pixhawk6x/pixhawk6x_hero_upright.png" width="150px" title="Pixhawk6X Upright Image" /> <img src="../../assets/flight_controller/pixhawk6x/pixhawk6x_exploded_diagram.png" width="280px" title="Pixhawk6X Exploded Image" />
|
||||
|
||||
### Pixhawk 6X Baseboards Options
|
||||
|
||||
:::: tabs
|
||||
|
||||
:::tab Standard v2A
|
||||
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
:::tab Standard v2B
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
:::tab Mini
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
:::tab Jetson Baseboard
|
||||
|
||||
|
||||
:::
|
||||
|
||||
:::tab CM4 Baseboard
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
@ -53,15 +67,15 @@ An independent LDO powers every sensor set with independent power control. A vib
|
||||
|
||||
External sensor bus (SPI5) has two chip select lines and data-ready signals for additional sensors and payload with SPI-interface, and with an integrated Microchip Ethernet PHY, high-speed communication with mission computers via ethernet is now possible.
|
||||
|
||||
The Pixhawk® 6X is perfect for developers at corporate research labs, startups, academics (research, professors, students), and commercial application.
|
||||
The Pixhawk® 6X is perfect for developers at corporate research labs, startups, academics (research, professors, students), and commercial applications.
|
||||
|
||||
## Key Design Points
|
||||
|
||||
- High performance STM32H753 Processor
|
||||
- High-performance STM32H753 Processor
|
||||
- Modular flight controller: separated IMU, FMU, and Base system connected by a 100-pin & a 50-pin Pixhawk® Autopilot Bus connector.
|
||||
- Redundancy: 3x IMU sensors & 2x Barometer sensors on separate buses
|
||||
- Triple redundancy domains: Completely isolated sensor domains with separate buses and separate power control
|
||||
- Newly designed vibration isolation system to filter out high frequency vibration and reduce noise to ensure accurate readings
|
||||
- Newly designed vibration isolation system to filter out high-frequency vibration and reduce noise to ensure accurate readings
|
||||
- Ethernet interface for high-speed mission computer integration
|
||||
- IMUs are temperature-controlled by onboard heating resistors, allowing optimum working temperature of IMUs 
|
||||
|
||||
@ -71,7 +85,11 @@ The Pixhawk® 6X is perfect for developers at corporate research labs, startu
|
||||
- 32 Bit Arm® Cortex®-M7, 480MHz, 2MB flash memory, 1MB RAM
|
||||
- IO 프로세서: STM32F100
|
||||
- 32 비트 Arm® Cortex®-M3, 24MHz, 8KB SRAM
|
||||
- 내장 센서 :
|
||||
- On-board sensors (Shipping Currently, Rev 8)
|
||||
- Accel/Gyro: 3x ICM-45686 (with BalancedGyro™ Technology)
|
||||
- Barometer: ICP20100 & BMP388
|
||||
- Mag: BMM150
|
||||
- On-board sensors (Rev 3/4, discontinued)
|
||||
- Accel/Gyro: ICM-20649 or BMI088
|
||||
- Accel/Gyro: ICM-42688-P
|
||||
- Accel/Gyro: ICM-42670-P
|
||||
@ -191,14 +209,14 @@ The **POWER1** & **POWER2** ports on the Pixhawk 6X uses the 6 circuit [2.00mm P
|
||||
|
||||
**Normal Operation Maximum Ratings**
|
||||
|
||||
이러한 조건에서 전원은 아래의 순서대로 시스템에 전원을 공급하여야합니다.
|
||||
이러한 조건에서 전원은 아래의 순서대로 시스템에 전원을 공급하여야 합니다.
|
||||
|
||||
1. **POWER1** and **POWER2** inputs (4.9V to 5.5V)
|
||||
2. **USB** input (4.75V to 5.25V)
|
||||
|
||||
**Absolute Maximum Ratings**
|
||||
|
||||
아래의 조건에서 시스템은 전원을 사용하지 않지만(작동하지 않음), 그대로 유지됩니다.
|
||||
Under these conditions, the system will not draw any power (will not be operational) but will remain intact.
|
||||
|
||||
1. **POWER1** and **POWER2** inputs (operational range 4.1V to 5.7V, 0V to 10V undamaged)
|
||||
2. **USB** input (operational range 4.1V to 5.7V, 0V to 6V undamaged)
|
||||
@ -209,7 +227,7 @@ The **POWER1** & **POWER2** ports on the Pixhawk 6X uses the 6 circuit [2.00mm P
|
||||
Digital I2C battery monitoring is enabled by default (see [Quickstart > Power](../assembly/quick_start_pixhawk6x.md#power)).
|
||||
|
||||
:::info
|
||||
Analog battery monitoring via an ADC is not supported on this particular board, but may be supported in variations of this flight controller with a different baseboard.
|
||||
Analog battery monitoring via an ADC is not supported on this particular board but may be supported in variations of this flight controller with a different baseboard.
|
||||
:::
|
||||
|
||||
## 펌웨어 빌드
|
||||
|
||||
@ -13,6 +13,12 @@ Logs can be downloaded using [QGroundControl](http://qgroundcontrol.com/): **[An
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
Encrypted logs cannot be downloaded with QGroundControl, or uploaded to the public Flight Review service.
|
||||
The easiest way to download and extract encrypted logs is to use the [Log Encryption Tools](../dev_log/log_encryption.md).
|
||||
You can also host a [private Flight Review server](../dev_log/log_encryption.md#flight-review-encrypted-logs) that automatically decrypts logs on upload using your private key.
|
||||
:::
|
||||
|
||||
## 로그 분석
|
||||
|
||||
Upload the log file to the online [Flight Review](http://logs.px4.io) tool.
|
||||
|
||||
98
docs/ko/mavlink/adding_messages.md
Normal file
98
docs/ko/mavlink/adding_messages.md
Normal file
@ -0,0 +1,98 @@
|
||||
# Adding Standard MAVLink Definitions (Messages/Commands)
|
||||
|
||||
This topic explains how to add new MAVLink messages and commands that are expected to be _part of_ the normal PX4 build.
|
||||
|
||||
## Standard MAVLink Messages
|
||||
|
||||
The PX4/PX4-Autopilot source code uses only messages that have been standardized by MAVLink.
|
||||
That is to say, the standard definitions in [common.xml](https://mavlink.io/en/messages/common.html) in releases, and [development.xml](https://mavlink.io/en/messages/development.html) during development.
|
||||
These messages are present in at least one significant flight stack, and members of other flight stacks have accepted them as a reasonable design that would likely be adopted if the same functionality was required.
|
||||
|
||||
:::tip
|
||||
A [Custom MAVLink Message](../mavlink/custom_messages.md) is one that isn't part of the standard.
|
||||
These are defined in your own XML as part of your own fork of PX4.
|
||||
If you use [custom MAVLink messages](../mavlink/custom_messages.md) you will need maintain the definitions in PX4, your ground station, and any other SDKs that communicate with it.
|
||||
Generally you should use (or add to) the standard definitions if at all possible to reduce the maintenance burden.
|
||||
:::
|
||||
|
||||
New standard definitions are added first to `development.xml`, and then moved to `common.xml` following review and prototyping, and acceptance by the MAVLink team.
|
||||
|
||||
If you intend your message to become part of the default PX4 build you will need to propose it to the MAVLink community by submitting a pull request (PR) to [development.xml](https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/development.xml).
|
||||
The [MAVLink Developer guide](https://mavlink.io/en/getting_started/) explains how to define new messages in [How to Define MAVLink Messages & Enums](https://mavlink.io/en/guide/define_xml_element.html).
|
||||
|
||||
## Generating Message Headers
|
||||
|
||||
During development you can add your definitions to `PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0/development.xml` (or pull them from MAVLink).
|
||||
|
||||
When you build PX4, header files for these message definitions are generated in the build directory (`/build/<build target>/mavlink/`).
|
||||
If headers are not build for your messages, they may be incorrectly formatted, or use clashing ids.
|
||||
Inspect the build log for information.
|
||||
|
||||
## Implementing Message Senders/Receivers
|
||||
|
||||
Once the message headers for your definitions are generated in the PX4 build, you can use them in your code to send and receive the messages:
|
||||
|
||||
- [Streaming MAVLink Messages](../mavlink/streaming_messages.md)
|
||||
- [Receiving MAVLink Messages](../mavlink/receiving_messages.md)
|
||||
|
||||
## 시험
|
||||
|
||||
The first step in debugging is to confirm that any messages you've created are being sent/received as you expect.
|
||||
|
||||
You should should first use the `uorb top [<message_name>]` command to verify in real-time that your message is published and the rate (see [uORB Messaging](../middleware/uorb.md#uorb-top-command)).
|
||||
This approach can also be used to test incoming messages that publish a uORB topic (for other messages you might use `printf` in your code and test in SITL).
|
||||
|
||||
There are several approaches you can use to view MAVLink traffic:
|
||||
|
||||
- Create a [Wireshark MAVLink plugin](https://mavlink.io/en/guide/wireshark.html) for your dialect.
|
||||
This allows you to inspect MAVLink traffic on an IP interface - for example between _QGroundControl_ or MAVSDK and your real or simulated version of PX4.
|
||||
|
||||
:::tip
|
||||
It is much easier to generate a wireshark plugin and inspect traffic in Wireshark, than to rebuild QGroundControl with your dialect and use MAVLink Inspector.
|
||||
|
||||
:::
|
||||
|
||||
- [Log uORB topics](../dev_log/logging.md) associate with your MAVLink message.
|
||||
|
||||
- View received messages in the QGroundControl [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_inspector.html).
|
||||
You will need to [rebuild QGroundControl with the new message definitions](#updating-ground-stations).
|
||||
|
||||
### Set Streaming Rate using a Shell
|
||||
|
||||
For testing, it is sometimes useful to increase the streaming rate of individual topics at runtime (e.g. for inspection in QGC).
|
||||
This can be achieved using by calling the [mavlink](../modules/modules_communication.md#mavlink) module through the [QGC MAVLink console](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html) (or some other shell):
|
||||
|
||||
```sh
|
||||
mavlink stream -u <port number> -s <mavlink topic name> -r <rate>
|
||||
```
|
||||
|
||||
You can get the port number with `mavlink status` which will output (amongst others) `transport protocol: UDP (<port number>)`.
|
||||
An example would be:
|
||||
|
||||
```sh
|
||||
mavlink stream -u 14556 -s CA_TRAJECTORY -r 300
|
||||
```
|
||||
|
||||
## Updating Ground Stations
|
||||
|
||||
Ultimately you'll want to use your new MAVLink interface by providing the corresponding ground station or MAVSDK implementation.
|
||||
|
||||
The important thing to remember here is that MAVLink requires that you use a version of the library that is built to the same definition (XML file).
|
||||
So if you have created a custom message in PX4 you won't be able to use it unless you build QGC or MAVSDK with that same definition.
|
||||
|
||||
### Updating QGroundControl
|
||||
|
||||
You will need to [Build QGroundControl](https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/getting_started/index.html) including a pre-built C library that contains your custom messages.
|
||||
|
||||
QGC uses a pre-built C library that must be located at [/qgroundcontrol/libs/mavlink/include/mavlink](https://github.com/mavlink/qgroundcontrol/tree/master/libs/mavlink/include/mavlink) in the QGC source.
|
||||
|
||||
By default this is pre-included as a submodule from <https://github.com/mavlink/c_library_v2> but you can [generate your own MAVLink Libraries](https://mavlink.io/en/getting_started/generate_libraries.html).
|
||||
|
||||
QGC uses the **all.xml** dialect by default, which includes **common.xml**.
|
||||
You can include your messages in either file.
|
||||
|
||||
Note that if you use your own _custom dialect_ then it should include **ArduPilotMega.xml** (or it will miss all the existing messages), and you will need to change the dialect used by setting it in [`MAVLINK_CONF`](https://github.com/mavlink/qgroundcontrol/blob/master/QGCExternalLibs.pri#L52) when running _qmake_.
|
||||
|
||||
### Updating MAVSDK
|
||||
|
||||
See the MAVSDK docs for information about how to work with [MAVLink headers and dialects](https://mavsdk.mavlink.io/main/en/cpp/guide/build.html).
|
||||
49
docs/ko/mavlink/custom_messages.md
Normal file
49
docs/ko/mavlink/custom_messages.md
Normal file
@ -0,0 +1,49 @@
|
||||
# Custom MAVLink Messages
|
||||
|
||||
A custom [MAVLink message](../middleware/mavlink.md) is one that isn't in the standard MAVLink definitions that are included into PX4 by default.
|
||||
|
||||
:::info
|
||||
If you use a custom definition you will fork and maintain PX4, your ground station, and any other SDKs that communicate with it.
|
||||
Generally you should use (or add to) the standard definitions if at all possible to reduce the maintenance burden.
|
||||
:::
|
||||
|
||||
## Adding Custom XML
|
||||
|
||||
Custom definitions can be added in a new dialect file in the same directory as [when using the standard XML definitions](../mavlink/adding_messages.md).
|
||||
For example, create `PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0/custom_messages.xml`, and set `CONFIG_MAVLINK_DIALECT` to build the new file for SITL.
|
||||
This dialect file should include `development.xml` so that all the standard definitions are also included.
|
||||
|
||||
For initial prototyping, or if you intend your message to be "standard", you can also add your messages to `common.xml` (or `development.xml`).
|
||||
This simplifies building, because you don't need to modify the dialect that is built.
|
||||
|
||||
The MAVLink developer guide explains how to define new messages in [How to Define MAVLink Messages & Enums](https://mavlink.io/en/guide/define_xml_element.html).
|
||||
|
||||
You can check that your new messages are built by inspecting the headers generated in the build directory (`/build/<build target>/mavlink/`).
|
||||
If your messages are not built they may be incorrectly formatted, or use clashing ids.
|
||||
Inspect the build log for information.
|
||||
|
||||
Once the message is being built you can stream, receive, or otherwise use it, as described in the following sections.
|
||||
|
||||
:::info
|
||||
The [MAVLink Developer guide](https://mavlink.io/en/getting_started/) has more information about using the MAVLink toolchain.
|
||||
:::
|
||||
|
||||
## 사용자 지정 MAVLink 메시지 생성에 대한 대안
|
||||
|
||||
Sometimes there is the need for a custom MAVLink message with content that is not fully defined.
|
||||
|
||||
For example when using MAVLink to interface PX4 with an embedded device, the messages that are exchanged between the autopilot and the device may go through several iterations before they are stabilized.
|
||||
In this case, it can be time-consuming and error-prone to regenerate the MAVLink headers, and make sure both devices use the same version of the protocol.
|
||||
|
||||
An alternative - and temporary - solution is to re-purpose debug messages.
|
||||
Instead of creating a custom MAVLink message `CA_TRAJECTORY`, you can send a message `DEBUG_VECT` with the string key `CA_TRAJ` and data in the `x`, `y` and `z` fields.
|
||||
See [this tutorial](../debug/debug_values.md) for an example usage of debug messages.
|
||||
|
||||
:::info
|
||||
This solution is not efficient as it sends character string over the network and involves comparison of strings.
|
||||
It should be used for development only!
|
||||
:::
|
||||
|
||||
## Testing & Updating Ground Stations
|
||||
|
||||
Testing the code and updating ground stations is done in the same way as when [Adding New Standard MAVLink Definitions ](../mavlink/adding_messages.md).
|
||||
85
docs/ko/mavlink/receiving_messages.md
Normal file
85
docs/ko/mavlink/receiving_messages.md
Normal file
@ -0,0 +1,85 @@
|
||||
# Receiving MAVLink Messages
|
||||
|
||||
This topic explains how to receive a [MAVLink message](../middleware/mavlink.md) and publish it to uORB.
|
||||
|
||||
## 개요
|
||||
|
||||
The topic shows how we would handle a received `BATTERY_STATUS_DEMO` message (as defined in [Streaming MAVLink Messages](../mavlink/streaming_messages.md)) and then update the (existing) [BatteryStatus uORB message](../msg_docs/BatteryStatus.md) with the contained information.
|
||||
|
||||
This is the kind of implementation that you would provide to support a MAVLink battery integration with PX4.
|
||||
|
||||
## 단계
|
||||
|
||||
Add the headers for the uORB topic to publish to in [mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L77):
|
||||
|
||||
```cpp
|
||||
#include <uORB/topics/battery_status.h>
|
||||
```
|
||||
|
||||
Add a function signature for a function that handles the incoming MAVLink message in the `MavlinkReceiver` class in
|
||||
[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L126)
|
||||
|
||||
```cpp
|
||||
void handle_message_battery_status_demo(mavlink_message_t *msg);
|
||||
```
|
||||
|
||||
Normally you would add a uORB publisher for the uORB topic to publish in the `MavlinkReceiver` class in
|
||||
[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L296).
|
||||
In this case the [BatteryStatus](../msg_docs/BatteryStatus.md) uORB topic already exists:
|
||||
|
||||
```cpp
|
||||
uORB::Publication<battery_status_s> _battery_pub{ORB_ID(battery_status)};
|
||||
```
|
||||
|
||||
This creates a publication to a single uORB topic instance, which by default will be the _first_ instance.
|
||||
|
||||
:::info
|
||||
This implementation won't work on multi-battery systems, because several batteries might be publishing data to the first instance of the topic, and there is no way to differentiate them.
|
||||
To support multiple batteries we'd need to use `PublicationMulti` and map the MAVLink message instance IDs to specific uORB topic instances.
|
||||
:::
|
||||
|
||||
Implement the `handle_message_battery_status_demo` function in [mavlink_receiver.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp).
|
||||
|
||||
```cpp
|
||||
void
|
||||
MavlinkReceiver::handle_message_battery_status_demo(mavlink_message_t *msg)
|
||||
{
|
||||
if ((msg->sysid != mavlink_system.sysid) || (msg->compid == mavlink_system.compid)) {
|
||||
// ignore battery status coming from other systems or from the autopilot itself
|
||||
return;
|
||||
}
|
||||
|
||||
// external battery measurements
|
||||
mavlink_battery_status_t battery_mavlink;
|
||||
mavlink_msg_battery_status_decode(msg, &battery_mavlink);
|
||||
|
||||
battery_status_s battery_status{};
|
||||
battery_status.timestamp = hrt_absolute_time();
|
||||
|
||||
battery_status.remaining = (float)battery_mavlink.battery_remaining / 100.0f;
|
||||
battery_status.temperature = (float)battery_mavlink.temperature;
|
||||
battery_status.connected = true;
|
||||
|
||||
_battery_pub.publish(battery_status);
|
||||
}
|
||||
```
|
||||
|
||||
:::info
|
||||
Above we only write to the battery fields that are defined in the topic.
|
||||
In practice you'd update all fields with either valid or invalid values: this has been cut back for brevity.
|
||||
:::
|
||||
|
||||
and finally make sure it is called in [MavlinkReceiver::handle_message()](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp#L228)
|
||||
|
||||
```cpp
|
||||
MavlinkReceiver::handle_message(mavlink_message_t *msg)
|
||||
{
|
||||
switch (msg->msgid) {
|
||||
...
|
||||
case MAVLINK_MSG_ID_BATTERY_STATUS_DEMO:
|
||||
handle_message_battery_status_demo(msg);
|
||||
break;
|
||||
...
|
||||
}
|
||||
}
|
||||
```
|
||||
252
docs/ko/mavlink/streaming_messages.md
Normal file
252
docs/ko/mavlink/streaming_messages.md
Normal file
@ -0,0 +1,252 @@
|
||||
# Streaming MAVLink Messages
|
||||
|
||||
This tutorial demonstrates how to stream a uORB message as a MAVLink message, and applies to both standard and custom messages.
|
||||
|
||||
## 개요
|
||||
|
||||
[MAVLink messages](../middleware/mavlink.md) are streamed using a streaming class, derived from `MavlinkStream`, that has been added to the PX4 stream list.
|
||||
The class has framework methods that you implement so PX4 can get information it needs from the generated MAVLink message definition.
|
||||
It also has a `send()` method that is called each time the message needs to be sent — you override this to copy information from a uORB subscription to the MAVLink message object that is to be sent.
|
||||
|
||||
Once you have created a streaming class the corresponding message can be streamed on request.
|
||||
You can also configure PX4 to stream the message by default, depending on the MAVLink configuration.
|
||||
|
||||
## 전제 조건
|
||||
|
||||
Generally you will already have a [uORB](../middleware/uorb.md) message that contains information you'd like to stream and a definition of a MAVLink message that you'd like to stream it with.
|
||||
|
||||
For this example we're going to assume that you want to stream the (existing) [BatteryStatus](../msg_docs/BatteryStatus.md) uORB message to a new MAVLink battery status message, which we will name `BATTERY_STATUS_DEMO`.
|
||||
|
||||
Copy this `BATTERY_STATUS_DEMO` message into the message section of `development.xml` in your PX4 source code, which will be located at: `\src\modules\mavlink\mavlink\message_definitions\v1.0\development.xml`.
|
||||
|
||||
```xml
|
||||
<message id="11514" name="BATTERY_STATUS_DEMO">
|
||||
<description>Simple demo battery.</description>
|
||||
<field type="uint8_t" name="id" instance="true">Battery ID</field>
|
||||
<field type="int16_t" name="temperature" units="cdegC" invalid="INT16_MAX">Temperature of the whole battery pack (not internal electronics). INT16_MAX field not provided.</field>
|
||||
<field type="uint8_t" name="percent_remaining" units="%" invalid="UINT8_MAX">Remaining battery energy. Values: [0-100], UINT8_MAX: field not provided.</field>
|
||||
</message>
|
||||
```
|
||||
|
||||
:::info
|
||||
Note that this is a cut-down version of the not-yet-implemented [BATTERY_STATUS_V2](https://mavlink.io/en/messages/development.html#BATTERY_STATUS_V2) message with randomly chosen unused id of `11514`.
|
||||
Here we've put the message in `development.xml`, which is fine for testing and if the message is intended to eventually be part of the standard message set, but you might also put a [custom message](../mavlink/custom_messages.md) in its own dialect file.
|
||||
:::
|
||||
|
||||
Build PX4 for SITL and confirm that the associated message is generated in `/build/px4_sitl_default/mavlink/development/mavlink_msg_battery_status_demo.h`.
|
||||
|
||||
Because `BatteryStatus` already exists you will not need to do anything to create or build it.
|
||||
|
||||
## Define the Streaming Class
|
||||
|
||||
First create a file named `BATTERY_STATUS_DEMO.hpp` for your streaming class (named after the message to stream) inside the [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams) directory.
|
||||
|
||||
Add the headers for the uORB message(s) to the top of the file (the required MAVLink headers should already be available):
|
||||
|
||||
```cpp
|
||||
#include <uORB/topics/battery_status.h>
|
||||
```
|
||||
|
||||
:::info
|
||||
The uORB topic's snake-case header file is generated from the CamelCase uORB filename at build time.
|
||||
:::
|
||||
|
||||
Then copy the streaming class definition below into the file:
|
||||
|
||||
```cpp
|
||||
class MavlinkStreamBatteryStatusDemo : public MavlinkStream
|
||||
{
|
||||
public:
|
||||
static MavlinkStream *new_instance(Mavlink *mavlink)
|
||||
{
|
||||
return new MavlinkStreamBatteryStatusDemo(mavlink);
|
||||
}
|
||||
const char *get_name() const
|
||||
{
|
||||
return MavlinkStreamBatteryStatusDemo::get_name_static();
|
||||
}
|
||||
static const char *get_name_static()
|
||||
{
|
||||
return "BATTERY_STATUS_DEMO";
|
||||
}
|
||||
static uint16_t get_id_static()
|
||||
{
|
||||
return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO;
|
||||
}
|
||||
uint16_t get_id()
|
||||
{
|
||||
return get_id_static();
|
||||
}
|
||||
unsigned get_size()
|
||||
{
|
||||
return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO_LEN + MAVLINK_NUM_NON_PAYLOAD_BYTES;
|
||||
}
|
||||
|
||||
private:
|
||||
//Subscription to array of uORB battery status instances
|
||||
uORB::SubscriptionMultiArray<battery_status_s, battery_status_s::MAX_INSTANCES> _battery_status_subs{ORB_ID::battery_status};
|
||||
// SubscriptionMultiArray subscription is needed because battery has multiple instances.
|
||||
// uORB::Subscription is used to subscribe to a single-instance topic
|
||||
|
||||
/* do not allow top copying this class */
|
||||
MavlinkStreamBatteryStatusDemo(MavlinkStreamBatteryStatusDemo &);
|
||||
MavlinkStreamBatteryStatusDemo& operator = (const MavlinkStreamBatteryStatusDemo &);
|
||||
|
||||
protected:
|
||||
explicit MavlinkStreamBatteryStatusDemo(Mavlink *mavlink) : MavlinkStream(mavlink)
|
||||
{}
|
||||
|
||||
bool send() override
|
||||
{
|
||||
bool updated = false;
|
||||
|
||||
// Loop through _battery_status_subs (subscription to array of BatteryStatus instances)
|
||||
for (auto &battery_sub : _battery_status_subs) {
|
||||
// battery_status_s is a struct that can hold the battery object topic
|
||||
battery_status_s battery_status;
|
||||
|
||||
// Update battery_status and publish only if the status has changed
|
||||
if (battery_sub.update(&battery_status)) {
|
||||
// mavlink_battery_status_demo_t is the MAVLink message object
|
||||
mavlink_battery_status_demo_t bat_msg{};
|
||||
|
||||
bat_msg.id = battery_status.id - 1;
|
||||
bat_msg.percent_remaining = (battery_status.connected) ? roundf(battery_status.remaining * 100.f) : -1;
|
||||
|
||||
// check if temperature valid
|
||||
if (battery_status.connected && PX4_ISFINITE(battery_status.temperature)) {
|
||||
bat_msg.temperature = battery_status.temperature * 100.f;
|
||||
} else {
|
||||
bat_msg.temperature = INT16_MAX;
|
||||
}
|
||||
|
||||
//Send the message
|
||||
mavlink_msg_battery_status_demo_send_struct(_mavlink->get_channel(), &bat_msg);
|
||||
updated = true;
|
||||
}
|
||||
}
|
||||
|
||||
return updated;
|
||||
}
|
||||
|
||||
};
|
||||
```
|
||||
|
||||
Most streaming classes are very similar (see examples in [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams)):
|
||||
|
||||
- The streaming class derives from [`MavlinkStream`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_stream.h) and is named using the pattern `MavlinkStream<CamelCaseMessageName>`.
|
||||
|
||||
- The `public` definitions are "near-boilerplate", allowing PX4 to get an instance of the class (`new_instance()`), and then to use it to fetch the name, id, and size of the message from the MAVLink headers (`get_name()`, `get_name_static()`, `get_id_static()`, `get_id()`, `get_size()`).
|
||||
For your own streaming classes these can just be copied and modified to match the values for your MAVLink message.
|
||||
|
||||
- The `private` definitions subscribe to the uORB topics that need to be published.
|
||||
In this case the uORB topic has multiple instances: one for each battery.
|
||||
We use `uORB::SubscriptionMultiArray` to get an array of battery status subscriptions.
|
||||
|
||||
Here we also define constructors to prevent the definition being copied.
|
||||
|
||||
- The `protected` section is where the important work takes place!
|
||||
|
||||
Here we override the `send()` method, copying values from the subscribed uORB topic(s) into appropriate fields in the MAVLink message, and then send the message.
|
||||
|
||||
In this particular example we have an array of uORB instances `_battery_status_subs` (because we have multiple batteries).
|
||||
We iterate the array and use `update()` on each subscription to check if the associated battery instance has changed (and update a structure with the current data).
|
||||
This allows us to send the MAVLink message _only_ if the associated battery uORB topic has changed:
|
||||
|
||||
// Struct to hold current topic data.
|
||||
battery_status_s battery_status;
|
||||
|
||||
// update() populates battery_status and returns true if the status has changed
|
||||
if (battery_sub.update(&battery_status)) {
|
||||
// Use battery_status to populate message and send
|
||||
}
|
||||
|
||||
If wanted to send a MAVLink message whether or not the data changed, we could instead use `copy()` as shown:
|
||||
|
||||
battery_status_s battery_status;
|
||||
battery_sub.copy(&battery_status);
|
||||
|
||||
::: info
|
||||
For a single-instance topic like [VehicleStatus](../msg_docs/VehicleStatus.md) we would subscribe like this:
|
||||
|
||||
// Create subscription _vehicle_status_sub
|
||||
uORB::Subscription _vehicle_status_sub{ORB_ID(vehicle_status)};
|
||||
|
||||
And we could use the resulting subscription in the same way with update or copy.
|
||||
|
||||
vehicle_status_s vehicle_status{}; // vehicle_status_s is the definition of the uORB topic
|
||||
if (_vehicle_status_sub.update(&vehicle_status)) {
|
||||
// Use the vehicle_status as it has been updated.
|
||||
}
|
||||
|
||||
|
||||
:::
|
||||
|
||||
Next we include our new class in [mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp#L2193).
|
||||
Add the line below to the part of the file where all the other streams are included:
|
||||
|
||||
```cpp
|
||||
#include "streams/BATTERY_STATUS_DEMO.hpp"
|
||||
```
|
||||
|
||||
Finally append the stream class to the `streams_list` at the bottom of
|
||||
[mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp)
|
||||
|
||||
```C
|
||||
StreamListItem *streams_list[] = {
|
||||
...
|
||||
#if defined(BATTERY_STATUS_DEMO_HPP)
|
||||
create_stream_list_item<MavlinkStreamBatteryStatusDemo>(),
|
||||
#endif // BATTERY_STATUS_DEMO_HPP
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
The class is now available for streaming, but won't be streamed by default.
|
||||
We cover that in the next sections.
|
||||
|
||||
## Streaming by Default
|
||||
|
||||
The easiest way to stream your messages by default (as part of a build) is to add them to [mavlink_main.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_main.cpp) in the appropriate message group.
|
||||
|
||||
If you search in the file you'll find groups of messages defined in a switch statement:
|
||||
|
||||
- `MAVLINK_MODE_NORMAL`: Streamed to a GCS.
|
||||
- `MAVLINK_MODE_ONBOARD`: Streamed to a companion computer on a fast link, such as Ethernet
|
||||
- `MAVLINK_MODE_ONBOARD_LOW_BANDWIDTH`: Streamed to a companion computer for re-routing to a reduced-traffic link, such as a GCS.
|
||||
- `MAVLINK_MODE_GIMBAL`: Streamed to a gimbal
|
||||
- `MAVLINK_MODE_EXTVISION`: Streamed to an external vision system
|
||||
- `MAVLINK_MODE_EXTVISIONMIN`: Streamed to an external vision system on a slower link
|
||||
- `MAVLINK_MODE_OSD`: Streamed to an OSD, such as an FPV headset.
|
||||
- `MAVLINK_MODE_CUSTOM`: Stream nothing by default. Used when configuring streaming using MAVLink.
|
||||
- `MAVLINK_MODE_MAGIC`: Same as `MAVLINK_MODE_CUSTOM`
|
||||
- `MAVLINK_MODE_CONFIG`: Streaming over USB with higher rates than `MAVLINK_MODE_NORMAL`.
|
||||
- `MAVLINK_MODE_MINIMAL`: Stream a minimal set of messages. Normally used for poor telemetry links.
|
||||
- `MAVLINK_MODE_IRIDIUM`: Streamed to an iridium satellite phone
|
||||
|
||||
Normally you'll be testing on a GCS, so you could just add the message to the `MAVLINK_MODE_NORMAL` case using the `configure_stream_local()` method.
|
||||
For example, to stream CA_TRAJECTORY at 5 Hz:
|
||||
|
||||
```cpp
|
||||
case MAVLINK_MODE_CONFIG: // USB
|
||||
// Note: streams requiring low latency come first
|
||||
...
|
||||
configure_stream_local("BATTERY_STATUS_DEMO", 5.0f);
|
||||
...
|
||||
```
|
||||
|
||||
It is also possible to add a stream by calling the [mavlink](../modules/modules_communication.md#mavlink) module with the `stream` argument in a [startup script](../concept/system_startup.md).
|
||||
For example, you might add the following line to [/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink) in order to stream `BATTERY_STATUS_DEMO` at 50Hz on UDP port `14556` (`-r` configures the streaming rate and `-u` identifies the MAVLink channel on UDP port 14556).
|
||||
|
||||
```sh
|
||||
mavlink stream -r 50 -s BATTERY_STATUS_DEMO -u 14556
|
||||
```
|
||||
|
||||
## Streaming on Request
|
||||
|
||||
Some messages are only needed once, when particular hardware is connected, or under other circumstances.
|
||||
In order to avoid clogging communications links with messages that aren't needed you may not stream all messages by default, even at low rate.
|
||||
|
||||
If you needed, a GCS or other MAVLink API can request that particular messages are streamed at a particular rate using [MAV_CMD_SET_MESSAGE_INTERVAL](https://mavlink.io/en/messages/common.html#MAV_CMD_SET_MESSAGE_INTERVAL).
|
||||
A particular message can be requested just once using [MAV_CMD_REQUEST_MESSAGE](https://mavlink.io/en/messages/common.html#MAV_CMD_REQUEST_MESSAGE).
|
||||
|
||||
@ -5,13 +5,15 @@
|
||||
PX4 uses _MAVLink_ to communicate with ground stations and MAVLink SDKs, such as _QGroundControl_ and [MAVSDK](https://mavsdk.mavlink.io/), and as the integration mechanism for connecting to drone components outside of the flight controller: companion computers, MAVLink enabled cameras, and so on.
|
||||
|
||||
This topic provides a brief overview of fundamental MAVLink concepts, such as messages, commands, and microservices.
|
||||
It also provides tutorial instructions for how you can add PX4 support for:
|
||||
It also links instructions for how you can add PX4 support for:
|
||||
|
||||
- Streaming MAVLink messages
|
||||
- Handling incoming MAVLink messages and writing to a uORB topic.
|
||||
- [Adding Standard Messages](../mavlink/adding_messages.md)
|
||||
- [Streaming MAVLink messages](../mavlink/streaming_messages.md)
|
||||
- [Handling incoming MAVLink messages (and writing to a uORB topic)](../mavlink/receiving_messages.md)
|
||||
- [Custom MAVLink Messages](../mavlink/custom_messages.md)
|
||||
|
||||
:::info
|
||||
The topic does not cover _command_ handling and sending, or how to implement your own microservices.
|
||||
We do not yet cover _command_ handling and sending, or how to implement your own microservices.
|
||||
:::
|
||||
|
||||
## MAVLink Overview
|
||||
@ -40,12 +42,12 @@ Note that most generated libraries do not create code to implement microservices
|
||||
The MAVLink project standardizes a number of messages, commands, enumerations, and microservices, for exchanging data using the following definition files (note that higher level files _include_ the definitions of the files below them):
|
||||
|
||||
- [development.xml](https://mavlink.io/en/messages/development.html) — Definitions that are proposed to be part of the standard.
|
||||
The definitions move to `common.xml` if accepted following testing.
|
||||
The definitions move to `common.xml` if accepted following testing.
|
||||
- [common.xml](https://mavlink.io/en/messages/common.html) — A "library" of definitions meeting many common UAV use cases.
|
||||
These are supported by many flight stacks, ground stations, and MAVLink peripherals.
|
||||
Flight stacks that use these definitions are more likely to interoperate.
|
||||
These are supported by many flight stacks, ground stations, and MAVLink peripherals.
|
||||
Flight stacks that use these definitions are more likely to interoperate.
|
||||
- [standard.xml](https://mavlink.io/en/messages/standard.html) — Definitions that are actually standard.
|
||||
They are present on the vast majority of flight stacks and implemented in the same way.
|
||||
They are present on the vast majority of flight stacks and implemented in the same way.
|
||||
- [minimal.xml](https://mavlink.io/en/messages/minimal.html) — Definitions required by a minimal MAVLink implementation.
|
||||
|
||||
The project also hosts [dialect XML definitions](https://mavlink.io/en/messages/#dialects), which contain MAVLink definitions that are specific to a flight stack or other stakeholder.
|
||||
@ -79,448 +81,7 @@ The build toolchain generates the MAVLink 2 C header files at build time.
|
||||
The XML file for which headers files are generated may be defined in the [PX4 kconfig board configuration](../hardware/porting_guide_config.md#px4-board-configuration-kconfig) on a per-board basis, using the variable `CONFIG_MAVLINK_DIALECT`:
|
||||
|
||||
- For SITL `CONFIG_MAVLINK_DIALECT` is set to `development` in [boards/px4/sitl/default.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/sitl/default.px4board#L36).
|
||||
You can change this to any other definition file, but the file must include `common.xml`.
|
||||
You can change this to any other definition file, but the file must include `common.xml`.
|
||||
- For other boards `CONFIG_MAVLINK_DIALECT` is not set by default, and PX4 builds the definitions in `common.xml` (these are build into the [mavlink module](../modules/modules_communication.md#mavlink) by default — search for `menuconfig MAVLINK_DIALECT` in [src/modules/mavlink/Kconfig](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/Kconfig#L10)).
|
||||
|
||||
The files are generated into the build directory: `/build/<build target>/mavlink/`.
|
||||
|
||||
## Custom MAVLink Messages
|
||||
|
||||
A custom MAVLink message is one that isn't in the default definitions included into PX4.
|
||||
|
||||
:::info
|
||||
If you use a custom definition you will need maintain the definition in PX4, your ground station, and any other SDKs that communicate with it.
|
||||
Generally you should use (or add to) the standard definitions if at all possible to reduce the maintenance burden.
|
||||
:::
|
||||
|
||||
Custom definitions can be added in a new dialect file in the same directory as the standard XML definitions.
|
||||
For example, create `PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0/custom_messages.xml`, and set `CONFIG_MAVLINK_DIALECT` to build the new file for SITL.
|
||||
This dialect file should include `development.xml` so that all the standard definitions are also included.
|
||||
|
||||
For initial prototyping, or if you intend your message to be "standard", you can also add your messages to `common.xml` (or `development.xml`).
|
||||
This simplifies building, because you don't need to modify the dialect that is built.
|
||||
|
||||
The MAVLink developer guide explains how to define new messages in [How to Define MAVLink Messages & Enums](https://mavlink.io/en/guide/define_xml_element.html).
|
||||
|
||||
You can check that your new messages are built by inspecting the headers generated in the build directory (`/build/<build target>/mavlink/`).
|
||||
If your messages are not built they may be incorrectly formatted, or use clashing ids.
|
||||
Inspect the build log for information.
|
||||
|
||||
Once the message is being built you can stream, receive, or otherwise use it, as described in the following sections.
|
||||
|
||||
:::info
|
||||
The [MAVLink Developer guide](https://mavlink.io/en/getting_started/) has more information about using the MAVLink toolchain.
|
||||
:::
|
||||
|
||||
## Streaming MAVLink Messages
|
||||
|
||||
MAVLink messages are streamed using a streaming class, derived from `MavlinkStream`, that has been added to the PX4 stream list.
|
||||
The class has framework methods that you implement so PX4 can get information it needs from the generated MAVLink message definition.
|
||||
It also has a `send()` method that is called each time the message needs to be sent — you override this to copy information from a uORB subscription to the MAVLink message object that is to be sent.
|
||||
|
||||
This tutorial demonstrates how to stream a uORB message as a MAVLink message, and applies to both standard and custom messages.
|
||||
|
||||
### 전제 조건
|
||||
|
||||
Generally you will already have a [uORB](../middleware/uorb.md) message that contains information you'd like to stream and a definition of a MAVLink message that you'd like to stream it with.
|
||||
|
||||
For this example we're going to assume that you want to stream the (existing) [BatteryStatus](../msg_docs/BatteryStatus.md) uORB message to a new MAVLink battery status message, which we will name `BATTERY_STATUS_DEMO`.
|
||||
|
||||
Copy this `BATTERY_STATUS_DEMO` message into the message section of `development.xml` in your PX4 source code, which will be located at: `\src\modules\mavlink\mavlink\message_definitions\v1.0\development.xml`.
|
||||
|
||||
```xml
|
||||
<message id="11514" name="BATTERY_STATUS_DEMO">
|
||||
<description>Simple demo battery.</description>
|
||||
<field type="uint8_t" name="id" instance="true">Battery ID</field>
|
||||
<field type="int16_t" name="temperature" units="cdegC" invalid="INT16_MAX">Temperature of the whole battery pack (not internal electronics). INT16_MAX field not provided.</field>
|
||||
<field type="uint8_t" name="percent_remaining" units="%" invalid="UINT8_MAX">Remaining battery energy. Values: [0-100], UINT8_MAX: field not provided.</field>
|
||||
</message>
|
||||
```
|
||||
|
||||
:::info
|
||||
Note that this is a cut-down version of the not-yet-implemented [BATTERY_STATUS_V2](https://mavlink.io/en/messages/development.html#BATTERY_STATUS_V2) message with randomly chosen unused id of `11514`.
|
||||
Here we've put the message in `development.xml`, which is fine for testing and if the message is intended to eventually be part of the standard message set, but you might also put a [custom message](#custom-mavlink-messages) in its own dialect file.
|
||||
:::
|
||||
|
||||
Build PX4 for SITL and confirm that the associated message is generated in `/build/px4_sitl_default/mavlink/development/mavlink_msg_battery_status_demo.h`.
|
||||
|
||||
Because `BatteryStatus` already exists you will not need to do anything to create or build it.
|
||||
|
||||
### Define the Streaming Class
|
||||
|
||||
First create a file named `BATTERY_STATUS_DEMO.hpp` for your streaming class (named after the message to stream) inside the [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams) directory.
|
||||
|
||||
Add the headers for the uORB message(s) to the top of the file (the required MAVLink headers should already be available):
|
||||
|
||||
```cpp
|
||||
#include <uORB/topics/battery_status.h>
|
||||
```
|
||||
|
||||
:::info
|
||||
The uORB topic's snake-case header file is generated from the CamelCase uORB filename at build time.
|
||||
:::
|
||||
|
||||
Then copy the streaming class definition below into the file:
|
||||
|
||||
```cpp
|
||||
class MavlinkStreamBatteryStatusDemo : public MavlinkStream
|
||||
{
|
||||
public:
|
||||
static MavlinkStream *new_instance(Mavlink *mavlink)
|
||||
{
|
||||
return new MavlinkStreamBatteryStatusDemo(mavlink);
|
||||
}
|
||||
const char *get_name() const
|
||||
{
|
||||
return MavlinkStreamBatteryStatusDemo::get_name_static();
|
||||
}
|
||||
static const char *get_name_static()
|
||||
{
|
||||
return "BATTERY_STATUS_DEMO";
|
||||
}
|
||||
static uint16_t get_id_static()
|
||||
{
|
||||
return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO;
|
||||
}
|
||||
uint16_t get_id()
|
||||
{
|
||||
return get_id_static();
|
||||
}
|
||||
unsigned get_size()
|
||||
{
|
||||
return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO_LEN + MAVLINK_NUM_NON_PAYLOAD_BYTES;
|
||||
}
|
||||
|
||||
private:
|
||||
//Subscription to array of uORB battery status instances
|
||||
uORB::SubscriptionMultiArray<battery_status_s, battery_status_s::MAX_INSTANCES> _battery_status_subs{ORB_ID::battery_status};
|
||||
// SubscriptionMultiArray subscription is needed because battery has multiple instances.
|
||||
// uORB::Subscription is used to subscribe to a single-instance topic
|
||||
|
||||
/* do not allow top copying this class */
|
||||
MavlinkStreamBatteryStatusDemo(MavlinkStreamBatteryStatusDemo &);
|
||||
MavlinkStreamBatteryStatusDemo& operator = (const MavlinkStreamBatteryStatusDemo &);
|
||||
|
||||
protected:
|
||||
explicit MavlinkStreamBatteryStatusDemo(Mavlink *mavlink) : MavlinkStream(mavlink)
|
||||
{}
|
||||
|
||||
bool send() override
|
||||
{
|
||||
bool updated = false;
|
||||
|
||||
// Loop through _battery_status_subs (subscription to array of BatteryStatus instances)
|
||||
for (auto &battery_sub : _battery_status_subs) {
|
||||
// battery_status_s is a struct that can hold the battery object topic
|
||||
battery_status_s battery_status;
|
||||
|
||||
// Update battery_status and publish only if the status has changed
|
||||
if (battery_sub.update(&battery_status)) {
|
||||
// mavlink_battery_status_demo_t is the MAVLink message object
|
||||
mavlink_battery_status_demo_t bat_msg{};
|
||||
|
||||
bat_msg.id = battery_status.id - 1;
|
||||
bat_msg.percent_remaining = (battery_status.connected) ? roundf(battery_status.remaining * 100.f) : -1;
|
||||
|
||||
// check if temperature valid
|
||||
if (battery_status.connected && PX4_ISFINITE(battery_status.temperature)) {
|
||||
bat_msg.temperature = battery_status.temperature * 100.f;
|
||||
} else {
|
||||
bat_msg.temperature = INT16_MAX;
|
||||
}
|
||||
|
||||
//Send the message
|
||||
mavlink_msg_battery_status_demo_send_struct(_mavlink->get_channel(), &bat_msg);
|
||||
updated = true;
|
||||
}
|
||||
}
|
||||
|
||||
return updated;
|
||||
}
|
||||
|
||||
};
|
||||
```
|
||||
|
||||
Most streaming classes are very similar (see examples in [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams)):
|
||||
|
||||
- The streaming class derives from [`MavlinkStream`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_stream.h) and is named using the pattern `MavlinkStream<CamelCaseMessageName>`.
|
||||
|
||||
- The `public` definitions are "near-boilerplate", allowing PX4 to get an instance of the class (`new_instance()`), and then to use it to fetch the name, id, and size of the message from the MAVLink headers (`get_name()`, `get_name_static()`, `get_id_static()`, `get_id()`, `get_size()`).
|
||||
For your own streaming classes these can just be copied and modified to match the values for your MAVLink message.
|
||||
|
||||
- The `private` definitions subscribe to the uORB topics that need to be published.
|
||||
In this case the uORB topic has multiple instances: one for each battery.
|
||||
We use `uORB::SubscriptionMultiArray` to get an array of battery status subscriptions.
|
||||
|
||||
Here we also define constructors to prevent the definition being copied.
|
||||
|
||||
- The `protected` section is where the important work takes place!
|
||||
|
||||
Here we override the `send()` method, copying values from the subscribed uORB topic(s) into appropriate fields in the MAVLink message, and then send the message.
|
||||
|
||||
In this particular example we have an array of uORB instances `_battery_status_subs` (because we have multiple batteries).
|
||||
We iterate the array and use `update()` on each subscription to check if the associated battery instance has changed (and update a structure with the current data).
|
||||
This allows us to send the MAVLink message _only_ if the associated battery uORB topic has changed:
|
||||
|
||||
```cpp
|
||||
// Struct to hold current topic data.
|
||||
battery_status_s battery_status;
|
||||
|
||||
// update() populates battery_status and returns true if the status has changed
|
||||
if (battery_sub.update(&battery_status)) {
|
||||
// Use battery_status to populate message and send
|
||||
}
|
||||
```
|
||||
|
||||
If wanted to send a MAVLink message whether or not the data changed, we could instead use `copy()` as shown:
|
||||
|
||||
```cpp
|
||||
battery_status_s battery_status;
|
||||
battery_sub.copy(&battery_status);
|
||||
```
|
||||
|
||||
::: info
|
||||
For a single-instance topic like [VehicleStatus](../msg_docs/VehicleStatus.md) we would subscribe like this:
|
||||
|
||||
```cpp
|
||||
// Create subscription _vehicle_status_sub
|
||||
uORB::Subscription _vehicle_status_sub{ORB_ID(vehicle_status)};
|
||||
```
|
||||
|
||||
And we could use the resulting subscription in the same way with update or copy.
|
||||
|
||||
```cpp
|
||||
vehicle_status_s vehicle_status{}; // vehicle_status_s is the definition of the uORB topic
|
||||
if (_vehicle_status_sub.update(&vehicle_status)) {
|
||||
// Use the vehicle_status as it has been updated.
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
Next we include our new class in [mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp#L2193).
|
||||
Add the line below to the part of the file where all the other streams are included:
|
||||
|
||||
```cpp
|
||||
#include "streams/BATTERY_STATUS_DEMO.hpp"
|
||||
```
|
||||
|
||||
Finally append the stream class to the `streams_list` at the bottom of
|
||||
[mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp)
|
||||
|
||||
```C
|
||||
StreamListItem *streams_list[] = {
|
||||
...
|
||||
#if defined(BATTERY_STATUS_DEMO_HPP)
|
||||
create_stream_list_item<MavlinkStreamBatteryStatusDemo>(),
|
||||
#endif // BATTERY_STATUS_DEMO_HPP
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
The class is now available for streaming, but won't be streamed by default.
|
||||
We cover that in the next sections.
|
||||
|
||||
### Streaming by Default
|
||||
|
||||
The easiest way to stream your messages by default (as part of a build) is to add them to [mavlink_main.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_main.cpp) in the appropriate message group.
|
||||
|
||||
If you search in the file you'll find groups of messages defined in a switch statement:
|
||||
|
||||
- `MAVLINK_MODE_NORMAL`: Streamed to a GCS.
|
||||
- `MAVLINK_MODE_ONBOARD`: Streamed to a companion computer on a fast link, such as Ethernet
|
||||
- `MAVLINK_MODE_ONBOARD_LOW_BANDWIDTH`: Streamed to a companion computer for re-routing to a reduced-traffic link, such as a GCS.
|
||||
- `MAVLINK_MODE_GIMBAL`: Streamed to a gimbal
|
||||
- `MAVLINK_MODE_EXTVISION`: Streamed to an external vision system
|
||||
- `MAVLINK_MODE_EXTVISIONMIN`: Streamed to an external vision system on a slower link
|
||||
- `MAVLINK_MODE_OSD`: Streamed to an OSD, such as an FPV headset.
|
||||
- `MAVLINK_MODE_CUSTOM`: Stream nothing by default. Used when configuring streaming using MAVLink.
|
||||
- `MAVLINK_MODE_MAGIC`: Same as `MAVLINK_MODE_CUSTOM`
|
||||
- `MAVLINK_MODE_CONFIG`: Streaming over USB with higher rates than `MAVLINK_MODE_NORMAL`.
|
||||
- `MAVLINK_MODE_MINIMAL`: Stream a minimal set of messages. Normally used for poor telemetry links.
|
||||
- `MAVLINK_MODE_IRIDIUM`: Streamed to an iridium satellite phone
|
||||
|
||||
Normally you'll be testing on a GCS, so you could just add the message to the `MAVLINK_MODE_NORMAL` case using the `configure_stream_local()` method.
|
||||
For example, to stream CA_TRAJECTORY at 5 Hz:
|
||||
|
||||
```cpp
|
||||
case MAVLINK_MODE_CONFIG: // USB
|
||||
// Note: streams requiring low latency come first
|
||||
...
|
||||
configure_stream_local("BATTERY_STATUS_DEMO", 5.0f);
|
||||
...
|
||||
```
|
||||
|
||||
It is also possible to add a stream by calling the [mavlink](../modules/modules_communication.md#mavlink) module with the `stream` argument in a [startup script](../concept/system_startup.md).
|
||||
For example, you might add the following line to [/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink) in order to stream `BATTERY_STATUS_DEMO` at 50Hz on UDP port `14556` (`-r` configures the streaming rate and `-u` identifies the MAVLink channel on UDP port 14556).
|
||||
|
||||
```sh
|
||||
mavlink stream -r 50 -s BATTERY_STATUS_DEMO -u 14556
|
||||
```
|
||||
|
||||
### Streaming on Request
|
||||
|
||||
Some messages are only needed once, when particular hardware is connected, or under other circumstances.
|
||||
In order to avoid clogging communications links with messages that aren't needed you may not stream all messages by default, even at low rate.
|
||||
|
||||
If you needed, a GCS or other MAVLink API can request that particular messages are streamed at a particular rate using [MAV_CMD_SET_MESSAGE_INTERVAL](https://mavlink.io/en/messages/common.html#MAV_CMD_SET_MESSAGE_INTERVAL).
|
||||
A particular message can be requested just once using [MAV_CMD_REQUEST_MESSAGE](https://mavlink.io/en/messages/common.html#MAV_CMD_REQUEST_MESSAGE).
|
||||
|
||||
## Receiving MAVLink Messages
|
||||
|
||||
This section explains how to receive a message over MAVLink and publish it to uORB.
|
||||
|
||||
It assumes that we are receiving the `BATTERY_STATUS_DEMO` message and we want to update the (existing) [BatteryStatus uORB message](../msg_docs/BatteryStatus.md) with the contained information.
|
||||
This is the kind of implementation that you would provide to support a MAVLink battery integration with PX4.
|
||||
|
||||
Add the headers for the uORB topic to publish to in [mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L77):
|
||||
|
||||
```cpp
|
||||
#include <uORB/topics/battery_status.h>
|
||||
```
|
||||
|
||||
Add a function signature for a function that handles the incoming MAVLink message in the `MavlinkReceiver` class in
|
||||
[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L126)
|
||||
|
||||
```cpp
|
||||
void handle_message_battery_status_demo(mavlink_message_t *msg);
|
||||
```
|
||||
|
||||
Normally you would add a uORB publisher for the uORB topic to publish in the `MavlinkReceiver` class in
|
||||
[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L296).
|
||||
In this case the [BatteryStatus](../msg_docs/BatteryStatus.md) uORB topic already exists:
|
||||
|
||||
```cpp
|
||||
uORB::Publication<battery_status_s> _battery_pub{ORB_ID(battery_status)};
|
||||
```
|
||||
|
||||
This creates a publication to a single uORB topic instance, which by default will be the _first_ instance.
|
||||
|
||||
:::info
|
||||
This implementation won't work on multi-battery systems, because several batteries might be publishing data to the first instance of the topic, and there is no way to differentiate them.
|
||||
To support multiple batteries we'd need to use `PublicationMulti` and map the MAVLink message instance IDs to specific uORB topic instances.
|
||||
:::
|
||||
|
||||
Implement the `handle_message_battery_status_demo` function in [mavlink_receiver.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp).
|
||||
|
||||
```cpp
|
||||
void
|
||||
MavlinkReceiver::handle_message_battery_status_demo(mavlink_message_t *msg)
|
||||
{
|
||||
if ((msg->sysid != mavlink_system.sysid) || (msg->compid == mavlink_system.compid)) {
|
||||
// ignore battery status coming from other systems or from the autopilot itself
|
||||
return;
|
||||
}
|
||||
|
||||
// external battery measurements
|
||||
mavlink_battery_status_t battery_mavlink;
|
||||
mavlink_msg_battery_status_decode(msg, &battery_mavlink);
|
||||
|
||||
battery_status_s battery_status{};
|
||||
battery_status.timestamp = hrt_absolute_time();
|
||||
|
||||
battery_status.remaining = (float)battery_mavlink.battery_remaining / 100.0f;
|
||||
battery_status.temperature = (float)battery_mavlink.temperature;
|
||||
battery_status.connected = true;
|
||||
|
||||
_battery_pub.publish(battery_status);
|
||||
}
|
||||
```
|
||||
|
||||
:::info
|
||||
Above we only write to the battery fields that are defined in the topic.
|
||||
In practice you'd update all fields with either valid or invalid values: this has been cut back for brevity.
|
||||
:::
|
||||
|
||||
and finally make sure it is called in [MavlinkReceiver::handle_message()](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp#L228)
|
||||
|
||||
```cpp
|
||||
MavlinkReceiver::handle_message(mavlink_message_t *msg)
|
||||
{
|
||||
switch (msg->msgid) {
|
||||
...
|
||||
case MAVLINK_MSG_ID_BATTERY_STATUS_DEMO:
|
||||
handle_message_battery_status_demo(msg);
|
||||
break;
|
||||
...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 사용자 지정 MAVLink 메시지 생성에 대한 대안
|
||||
|
||||
Sometimes there is the need for a custom MAVLink message with content that is not fully defined.
|
||||
|
||||
For example when using MAVLink to interface PX4 with an embedded device, the messages that are exchanged between the autopilot and the device may go through several iterations before they are stabilized.
|
||||
In this case, it can be time-consuming and error-prone to regenerate the MAVLink headers, and make sure both devices use the same version of the protocol.
|
||||
|
||||
An alternative - and temporary - solution is to re-purpose debug messages.
|
||||
Instead of creating a custom MAVLink message `CA_TRAJECTORY`, you can send a message `DEBUG_VECT` with the string key `CA_TRAJ` and data in the `x`, `y` and `z` fields.
|
||||
See [this tutorial](../debug/debug_values.md) for an example usage of debug messages.
|
||||
|
||||
:::info
|
||||
This solution is not efficient as it sends character string over the network and involves comparison of strings.
|
||||
It should be used for development only!
|
||||
:::
|
||||
|
||||
## 시험
|
||||
|
||||
As a first step, and while debugging, commonly you'll just want to confirm that any messages you've created are being sent/received as you expect.
|
||||
|
||||
You should should first use the `uorb top [<message_name>]` command to verify in real-time that your message is published and the rate (see [uORB Messaging](../middleware/uorb.md#uorb-top-command)).
|
||||
This approach can also be used to test incoming messages that publish a uORB topic (for other messages you might use `printf` in your code and test in SITL).
|
||||
|
||||
There are several approaches you can use to view MAVLink traffic:
|
||||
|
||||
- Create a [Wireshark MAVLink plugin](https://mavlink.io/en/guide/wireshark.html) for your dialect.
|
||||
This allows you to inspect MAVLink traffic on an IP interface - for example between _QGroundControl_ or MAVSDK and your real or simulated version of PX4.
|
||||
|
||||
:::tip
|
||||
It is much easier to generate a wireshark plugin and inspect traffic in Wireshark, than to rebuild QGroundControl with your dialect and use MAVLink Inspector.
|
||||
|
||||
:::
|
||||
|
||||
- [Log uORB topics](../dev_log/logging.md) associate with your MAVLink message.
|
||||
|
||||
- View received messages in the QGroundControl [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_inspector.html).
|
||||
You will need to rebuild QGroundControl with the custom message definitions, [as described below](#updating-qgroundcontrol)
|
||||
|
||||
### Set Streaming Rate using a Shell
|
||||
|
||||
For testing, it is sometimes useful to increase the streaming rate of individual topics at runtime (e.g. for inspection in QGC).
|
||||
This can be achieved using by calling the [mavlink](../modules/modules_communication.md#mavlink) module through the [QGC MAVLink console](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html) (or some other shell):
|
||||
|
||||
```sh
|
||||
mavlink stream -u <port number> -s <mavlink topic name> -r <rate>
|
||||
```
|
||||
|
||||
You can get the port number with `mavlink status` which will output (amongst others) `transport protocol: UDP (<port number>)`.
|
||||
An example would be:
|
||||
|
||||
```sh
|
||||
mavlink stream -u 14556 -s CA_TRAJECTORY -r 300
|
||||
```
|
||||
|
||||
## Updating Ground Stations
|
||||
|
||||
Ultimately you'll want to use your new MAVLink interface by providing the corresponding ground station or MAVSDK implementation.
|
||||
|
||||
The important thing to remember here is that MAVLink requires that you use a version of the library that is built to the same definition (XML file).
|
||||
So if you have created a custom message in PX4 you won't be able to use it unless you build QGC or MAVSDK with that same definition.
|
||||
|
||||
### Updating QGroundControl
|
||||
|
||||
You will need to [Build QGroundControl](https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/getting_started/index.html) including a pre-built C library that contains your custom messages.
|
||||
|
||||
QGC uses a pre-built C library that must be located at [/qgroundcontrol/libs/mavlink/include/mavlink](https://github.com/mavlink/qgroundcontrol/tree/master/libs/mavlink/include/mavlink) in the QGC source.
|
||||
|
||||
By default this is pre-included as a submodule from <https://github.com/mavlink/c_library_v2> but you can [generate your own MAVLink Libraries](https://mavlink.io/en/getting_started/generate_libraries.html).
|
||||
|
||||
QGC uses the all.xml dialect by default, which includes **common.xml**.
|
||||
You can include your messages in either file or in your own dialect.
|
||||
However if you use your own dialect then it should include ArduPilotMega.xml (or it will miss all the existing messages), and you will need to change the dialect used by setting it in [`MAVLINK_CONF`](https://github.com/mavlink/qgroundcontrol/blob/master/QGCExternalLibs.pri#L52) when running _qmake_.
|
||||
|
||||
### Updating MAVSDK
|
||||
|
||||
See the MAVSDK docs for information about how to work with [MAVLink headers and dialects](https://mavsdk.mavlink.io/main/en/cpp/guide/build.html).
|
||||
|
||||
@ -225,16 +225,16 @@ ist8310 <command> [arguments...]
|
||||
status print status info
|
||||
```
|
||||
|
||||
## lis2mdl
|
||||
## iis2mdc
|
||||
|
||||
Source: [drivers/magnetometer/lis2mdl](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/magnetometer/lis2mdl)
|
||||
Source: [drivers/magnetometer/iis2mdc](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/magnetometer/iis2mdc)
|
||||
|
||||
<a id="lis2mdl_usage"></a>
|
||||
<a id="iis2mdc_usage"></a>
|
||||
|
||||
### 사용법
|
||||
|
||||
```
|
||||
lis2mdl <command> [arguments...]
|
||||
iis2mdc <command> [arguments...]
|
||||
Commands:
|
||||
start
|
||||
[-I] Internal I2C bus(es)
|
||||
|
||||
@ -1,8 +1,9 @@
|
||||
# Gazebo Classic Simulation
|
||||
|
||||
:::warning
|
||||
_Gazebo Classic_ is supported with PX4 up to Ubuntu Linux 20.04.
|
||||
In Ubuntu 22.04 and later you must use [Gazebo](../sim_gazebo_gz/index.md) (which was [formerly known](https://www.openrobotics.org/blog/2022/4/6/a-new-era-for-gazebo) as "Gazebo Ignition").
|
||||
[Gazebo](../sim_gazebo_gz/index.md) is nearing feature-parity with Gazebo Classic on PX4, and will soon replace it.
|
||||
Until then you can continue to use Gazebo-Classic on Ubuntu 22.04 for the few cases where you still need to.
|
||||
For more information see [PX4-Autopilot#23602: GZ Feature tracker](https://github.com/PX4/PX4-Autopilot/issues/23602).
|
||||
:::
|
||||
|
||||
Gazebo Classic is a powerful 3D simulation environment for autonomous robots that is particularly suitable for testing object-avoidance and computer vision.
|
||||
@ -32,11 +33,8 @@ See [Simulation](../simulation/index.md) for general information about simulator
|
||||
If you plan to use PX4 with ROS you **should follow the** [ROS Instructions](../simulation/ros_interface.md) to install both ROS and Gazebo Classic (and thereby avoid installation conflicts).
|
||||
:::
|
||||
|
||||
Gazebo Classic setup is included in our [standard build instructions](../dev_setup/dev_env.md) for macOS, Ubuntu 18.04 and 20.04, and Windows on WSL2 for the same hosts.
|
||||
|
||||
For Ubuntu 22.04 LTS and later, the installation script ([/Tools/setup/ubuntu.sh](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/setup/ubuntu.sh)) installs the [Gazebo](../sim_gazebo_gz/index.md) simulator instead.
|
||||
|
||||
If you want to use Gazebo Classic on Ubuntu 22.04 you can use the following commands to remove [Gazebo](../sim_gazebo_gz/index.md) (Harmonic) and then reinstall Gazebo-Classic 11:
|
||||
The standard installation script ([/Tools/setup/ubuntu.sh](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/setup/ubuntu.sh)) installs the [Gazebo](../sim_gazebo_gz/index.md) (Harmonic) simulator.
|
||||
If you want to use Gazebo Classic on _Ubuntu 22.04 (only)_ you can use the following commands to remove Gazebo and then reinstall Gazebo-Classic 11:
|
||||
|
||||
```sh
|
||||
sudo apt remove gz-harmonic
|
||||
@ -47,10 +45,10 @@ sudo aptitude install gazebo libgazebo11 libgazebo-dev
|
||||
Note that `aptitude` is needed because it can resolve dependency conflicts (by removing certain packages) that `apt` is unable to handle.
|
||||
|
||||
:::tip
|
||||
You could also modify the installation script to install Gazebo Classic on later versions before it is run for the first time.
|
||||
:::
|
||||
You could also modify the installation script to install Gazebo Classic on Ubuntu 22.04 before it is run for the first time.
|
||||
|
||||
Additional installation instructions can be found on gazebosim.org.
|
||||
:::
|
||||
|
||||
## Running the Simulation
|
||||
|
||||
@ -189,7 +187,7 @@ To run at double real-time:
|
||||
PX4_SIM_SPEED_FACTOR=2 make px4_sitl_default gazebo-classic
|
||||
```
|
||||
|
||||
실시간 절반으로 실행하려면:
|
||||
To run at half real-time:
|
||||
|
||||
```sh
|
||||
PX4_SIM_SPEED_FACTOR=0.5 make px4_sitl_default gazebo-classic
|
||||
@ -518,18 +516,18 @@ Lockstep makes it possible to [change the simulation speed](#change-simulation-s
|
||||
|
||||
#### Lockstep Sequence
|
||||
|
||||
잠금단계의 순서는 다음과 같습니다.
|
||||
The sequence of steps for lockstep are:
|
||||
|
||||
1. The simulation sends a sensor message [HIL_SENSOR](https://mavlink.io/en/messages/common.html#HIL_SENSOR) including a timestamp `time_usec` to update the sensor state and time of PX4.
|
||||
2. PX4 receives this and does one iteration of state estimation, controls, etc. and eventually sends an actuator message [HIL_ACTUATOR_CONTROLS](https://mavlink.io/en/messages/common.html#HIL_ACTUATOR_CONTROLS).
|
||||
3. 시뮬레이션은 액추에이터/모터 메시지를 수신후에, 물리적 시뮬레이션후에 PX4로 전송할 다음 센서 메시지를 계산합니다.
|
||||
3. The simulation waits until it receives the actuator/motor message, then simulates the physics and calculates the next sensor message to send to PX4 again.
|
||||
|
||||
시스템은 시뮬레이션 시간을 포함하는 센서 메시지를 전송하는 "프리휠링" 기간으로 시작하므로, 초기화되고 액추에이터 메시지로 응답시까지 PX4를 실행합니다.
|
||||
The system starts with a "freewheeling" period where the simulation sends sensor messages including time and therefore runs PX4 until it has initialized and responds with an actuator message.
|
||||
|
||||
#### Disabling Lockstep
|
||||
|
||||
SITL이 이 기능을 지원하지 않는 시뮬레이터와 함께 사용되는 경우에는 잠금단계 시뮬레이션을 비활성화할 수 있습니다.
|
||||
이 경우 시뮬레이터와 PX4는 호스트 시스템 시간을 사용하며 서로를 기다리지 않습니다.
|
||||
The lockstep simulation can be disabled if, for example, SITL is to be used with a simulator that does not support this feature.
|
||||
In this case the simulator and PX4 use the host system time and do not wait on each other.
|
||||
|
||||
To disable lockstep in:
|
||||
|
||||
|
||||
@ -185,7 +185,7 @@ For example, to run the Gazebo simulation of the X500 frame at 2 times the real
|
||||
PX4_SIM_SPEED_FACTOR=2 make px4_sitl gz_x500
|
||||
```
|
||||
|
||||
실시간 절반으로 실행하려면:
|
||||
To run at half real-time:
|
||||
|
||||
```sh
|
||||
PX4_SIM_SPEED_FACTOR=0.5 make px4_sitl gz_x500
|
||||
|
||||
@ -136,7 +136,7 @@ To run at double real-time:
|
||||
PX4_SIM_SPEED_FACTOR=2 make px4_sitl_default jmavsim
|
||||
```
|
||||
|
||||
실시간 절반으로 실행하려면:
|
||||
To run at half real-time:
|
||||
|
||||
```sh
|
||||
PX4_SIM_SPEED_FACTOR=0.5 make px4_sitl_default jmavsim
|
||||
@ -194,18 +194,18 @@ Lockstep makes it possible to [change the simulation speed](#change-simulation-s
|
||||
|
||||
#### Lockstep Sequence
|
||||
|
||||
잠금단계의 순서는 다음과 같습니다.
|
||||
The sequence of steps for lockstep are:
|
||||
|
||||
1. The simulation sends a sensor message [HIL_SENSOR](https://mavlink.io/en/messages/common.html#HIL_SENSOR) including a timestamp `time_usec` to update the sensor state and time of PX4.
|
||||
2. PX4 receives this and does one iteration of state estimation, controls, etc. and eventually sends an actuator message [HIL_ACTUATOR_CONTROLS](https://mavlink.io/en/messages/common.html#HIL_ACTUATOR_CONTROLS).
|
||||
3. 시뮬레이션은 액추에이터/모터 메시지를 수신후에, 물리적 시뮬레이션후에 PX4로 전송할 다음 센서 메시지를 계산합니다.
|
||||
3. The simulation waits until it receives the actuator/motor message, then simulates the physics and calculates the next sensor message to send to PX4 again.
|
||||
|
||||
시스템은 시뮬레이션 시간을 포함하는 센서 메시지를 전송하는 "프리휠링" 기간으로 시작하므로, 초기화되고 액추에이터 메시지로 응답시까지 PX4를 실행합니다.
|
||||
The system starts with a "freewheeling" period where the simulation sends sensor messages including time and therefore runs PX4 until it has initialized and responds with an actuator message.
|
||||
|
||||
#### Disabling Lockstep
|
||||
|
||||
SITL이 이 기능을 지원하지 않는 시뮬레이터와 함께 사용되는 경우에는 잠금단계 시뮬레이션을 비활성화할 수 있습니다.
|
||||
이 경우 시뮬레이터와 PX4는 호스트 시스템 시간을 사용하며 서로를 기다리지 않습니다.
|
||||
The lockstep simulation can be disabled if, for example, SITL is to be used with a simulator that does not support this feature.
|
||||
In this case the simulator and PX4 use the host system time and do not wait on each other.
|
||||
|
||||
To disable lockstep in:
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user