mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-03-26 17:02:20 +08:00
New Crowdin translations - uk (#26147)
Some checks failed
Container build / Set Tags and Variables (push) Has been cancelled
Container build / Build Container (amd64) (push) Has been cancelled
Container build / Build Container (arm64) (push) Has been cancelled
Container build / Deploy To Registry (push) Has been cancelled
Docs - Crowdin - Upload Guide sources (en) / upload-to-crowdin (push) Has been cancelled
Docs - Deploy PX4 User Guide to AWS / build (push) Has been cancelled
Docs - Deploy PX4 User Guide to AWS / deploy (push) Has been cancelled
Fuzzing / Fuzzing (push) Has been cancelled
Some checks failed
Container build / Set Tags and Variables (push) Has been cancelled
Container build / Build Container (amd64) (push) Has been cancelled
Container build / Build Container (arm64) (push) Has been cancelled
Container build / Deploy To Registry (push) Has been cancelled
Docs - Crowdin - Upload Guide sources (en) / upload-to-crowdin (push) Has been cancelled
Docs - Deploy PX4 User Guide to AWS / build (push) Has been cancelled
Docs - Deploy PX4 User Guide to AWS / deploy (push) Has been cancelled
Fuzzing / Fuzzing (push) Has been cancelled
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
PX4 Build Bot
GitHub
@@ -315,15 +315,17 @@
|
||||
- [Розподіл приводу](config/actuators.md)
|
||||
- [Калібрування ESC (плати контролю двигунів)](advanced_config/esc_calibration.md)
|
||||
- [ESCs & Двигуни](peripherals/esc_motors.md)
|
||||
- [ESC Protocols](esc/esc_protocols.md)
|
||||
- [PWM ESCs та сервоприводи](peripherals/pwm_escs_and_servo.md)
|
||||
- [DShot ESCs](peripherals/dshot.md)
|
||||
- [OneShot ESCs та сервоприводи](peripherals/oneshot.md)
|
||||
- [DroneCAN ESCs](dronecan/escs.md)
|
||||
- [Zubax Telega](dronecan/zubax_telega.md)
|
||||
- [Прошивка PX4 Sapog ESC](dronecan/sapog.md)
|
||||
- [Holybro Kotleta](dronecan/holybro_kotleta.md)
|
||||
- [Vertiq](peripherals/vertiq.md)
|
||||
- [VESC](peripherals/vesc.md)
|
||||
- [PX4 Sapog ESC Firmware](dronecan/sapog.md)
|
||||
- [ARK 4IN1 ESC](esc/ark_4in1_esc.md)
|
||||
- [Holybro Kotleta](dronecan/holybro_kotleta.md)
|
||||
- [Vertiq Motor/ESC Modules](peripherals/vertiq.md)
|
||||
- [VESC Project ESCs](peripherals/vesc.md)
|
||||
- [Zubax Telega ESCs](dronecan/zubax_telega.md)
|
||||
|
||||
- [Радіокерування (RC)](getting_started/rc_transmitter_receiver.md)
|
||||
- [Налаштування радіо](config/radio.md)
|
||||
@@ -519,6 +521,7 @@
|
||||
- [PPS Time Synchronization](advanced/pps_time_sync.md)
|
||||
- [Проміжне програмне забезпечення](middleware/index.md)
|
||||
- [Повідомлення uORB](middleware/uorb.md)
|
||||
- [uORB Docs Standard](uorb/uorb_documentation.md)
|
||||
- [Граф uORB](middleware/uorb_graph.md)
|
||||
- [Опис повідомлень uORB](msg_docs/index.md)
|
||||
- [Versioned](msg_docs/versioned_messages.md)
|
||||
|
||||
@@ -1,7 +1,13 @@
|
||||
# CAN
|
||||
# CAN (DroneCAN & Cyphal)
|
||||
|
||||
[Мережа контролера (CAN)](https://en.wikipedia.org/wiki/CAN_bus) – це надійна дротова мережа, яка дозволяє компонентам дрона, таким як контролер польоту, ESC, датчики та інші периферійні пристрої, спілкуватися один з одним.
|
||||
Так як він розроблений, щоб бути демократичним та використовує диференційну сигналізацію, він є дуже надійним навіть на довгих кабельних ділянках (на великих транспортних засобах) і уникне виникнення однієї точки відмови.
|
||||
[Controller Area Network (CAN)](https://en.wikipedia.org/wiki/CAN_bus) is a robust wired network that allows drone components such as flight controller, ESCs, sensors, and other peripherals, to communicate with each other.
|
||||
|
||||
It is particularly recommended on larger vehicles.
|
||||
|
||||
## Загальний огляд
|
||||
|
||||
CAN it is designed to be democratic and uses differential signaling.
|
||||
For this reason it is very robust even over longer cable lengths (on large vehicles), and avoids a single point of failure.
|
||||
CAN також дозволяє отримання зворотного зв'язку від периферійних пристроїв та зручне оновлення прошивки через шину.
|
||||
|
||||
PX4 підтримує два програмні протоколи для взаємодії з пристроями CAN:
|
||||
@@ -18,29 +24,36 @@ PX4 підтримує два програмні протоколи для вз
|
||||
Відмінності між цими двома протоколами описані в [Cyphal vs. DroneCAN](https://forum.opencyphal.org/t/cyphal-vs-dronecan/1814).
|
||||
:::
|
||||
|
||||
:::warning
|
||||
У PX4 немає підтримки інших програмних протоколів CAN для безпілотних літальних апаратів, таких як KDECAN (на момент написання).
|
||||
:::
|
||||
|
||||
## Підключення
|
||||
|
||||
Проводка для мереж CAN однакова як для DroneCAN, так і для Cyphal/CAN (фактично, для всіх мереж CAN).
|
||||
|
||||
Пристрої з'єднані у ланцюжку в будь-якому порядку.
|
||||
Devices within a network are connected in a _daisy-chain_ in any order (this differs from UARTs peripherals, where you attach just one component per port).
|
||||
|
||||
:::warning
|
||||
Don't connect each CAN peripheral to a separate CAN port!
|
||||
Unlike UARTs, CAN peripherals are designed to be daisy chained, with additional ports such as `CAN2` used for [redundancy](redundancy).
|
||||
:::
|
||||
|
||||
На обох кінцях ланцюга між двома лініями передачі даних слід під’єднати термінальний резистор 120 Ом.
|
||||
Польотні контролери та деякі модулі GNSS мають вбудовані резистори завершення для зручності, тому їх слід розміщувати на протилежних кінцях ланцюга.
|
||||
В іншому випадку, ви можете використовувати резистор завершення, наприклад, [цей від Zubax Robotics](https://shop.zubax.com/products/uavcan-micro-termination-plug?variant=6007985111069), або припаяти його самостійно, якщо у вас є доступ до затискача JST-GH.
|
||||
|
||||
Наступна діаграма показує приклад шини CAN, що з'єднує автопілот з 4 контролерами ESC CAN та GNSS.
|
||||
It includes a redundant bus connected to `CAN 2`.
|
||||
|
||||
|
||||
|
||||
На схемі не показано електропроводку.
|
||||
Для підтвердження, чи компоненти потребують окремого живлення, чи можуть бути живлені від самої шини CAN, звертайтеся до інструкцій виробника.
|
||||
|
||||
:::info
|
||||
For more information, see [Cyphal/CAN device interconnection](https://wiki.zubax.com/public/cyphal/CyphalCAN-device-interconnection?pageId=2195476) (kb.zubax.com).
|
||||
Хоча стаття написана з урахуванням протоколу Cyphal, вона однаково стосується апаратного забезпечення DroneCAN і будь-яких інших налаштувань CAN.
|
||||
Для більш складних сценаріїв зверніться до розділу [Про топологію та термінацію шини CAN](https://forum.opencyphal.org/t/on-can-bus-topology-and-termination/1685).
|
||||
:::
|
||||
|
||||
### З’єднання
|
||||
|
||||
@@ -54,7 +67,30 @@ For more information, see [Cyphal/CAN device interconnection](https://wiki.zubax
|
||||
|
||||
DroneCAN та Cyphal/CAN підтримують використання другого (резервного) інтерфейсу CAN.
|
||||
Це абсолютно необов'язково, але збільшує надійність підключення.
|
||||
Всі контролери польоту Pixhawk мають 2 інтерфейси CAN; якщо ваші пристрої також підтримують 2 інтерфейси CAN, рекомендується підключити обидва для збільшення безпеки.
|
||||
|
||||
Pixhawk flight controllers come with 2 CAN interfaces; if your peripherals support 2 CAN interfaces as well, it is recommended to wire both up for increased safety.
|
||||
|
||||
### Flight Controllers with Multiple CAN Ports
|
||||
|
||||
[Flight Controllers](../flight_controller/index.md) may have up to three independent CAN ports, such as `CAN1`, `CAN2`, `CAN3` (neither DroneCAN or Cyphal support more than three).
|
||||
Note that you can't have both DroneCAN and Cyphal running on PX4 at the same time.
|
||||
|
||||
:::tip
|
||||
You only _need_ one CAN port to support an arbitrary number of CAN devices using a particular CAN protocol.
|
||||
Don't connect each CAN peripheral to a separate CAN port!
|
||||
:::
|
||||
|
||||
Generally you'll daisy all CAN peripherals off a single port, and if there is more than one CAN port, use the second one for [redundancy](redundancy).
|
||||
If three are three ports, you might use the remaining network for devices that support another CAN protocol.
|
||||
|
||||
The documentation for your flight controller should indicate which ports are supported/enabled.
|
||||
At runtime you can check what DroneCAN ports are enabled and their status using the following command on the [MAVLink Shell](../debug/mavlink_shell.md) (or some other console):
|
||||
|
||||
```sh
|
||||
uavcan status
|
||||
```
|
||||
|
||||
Note that you can also check the number of supported CAN interfaces for a board by searching for `CONFIG_BOARD_UAVCAN_INTERFACES` in its [default.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6xrt/default.px4board#) configuration file.
|
||||
|
||||
## Прошивка
|
||||
|
||||
|
||||
@@ -94,6 +94,7 @@ Set the following parameters in _QGroundControl_:
|
||||
- To optionally disable GPS aiding, set [EKF2_GPS_CTRL](../advanced_config/parameter_reference.md#EKF2_GPS_CTRL) to `0`.
|
||||
- Enable [UAVCAN_SUB_FLOW](../advanced_config/parameter_reference.md#UAVCAN_SUB_FLOW).
|
||||
- Enable [UAVCAN_SUB_RNG](../advanced_config/parameter_reference.md#UAVCAN_SUB_RNG).
|
||||
- Set [EKF2_RNG_CTRL](../advanced_config/parameter_reference.md#EKF2_RNG_CTRL) to `1`.
|
||||
- Set [EKF2_RNG_A_HMAX](../advanced_config/parameter_reference.md#EKF2_RNG_A_HMAX) to `10`.
|
||||
- Set [EKF2_RNG_QLTY_T](../advanced_config/parameter_reference.md#EKF2_RNG_QLTY_T) to `0.2`.
|
||||
- Set [UAVCAN_RNG_MIN](../advanced_config/parameter_reference.md#UAVCAN_RNG_MIN) to `0.08`.
|
||||
|
||||
@@ -91,6 +91,7 @@ Set the following parameters in _QGroundControl_:
|
||||
- To optionally disable GPS aiding, set [EKF2_GPS_CTRL](../advanced_config/parameter_reference.md#EKF2_GPS_CTRL) to `0`.
|
||||
- Enable [UAVCAN_SUB_FLOW](../advanced_config/parameter_reference.md#UAVCAN_SUB_FLOW).
|
||||
- Enable [UAVCAN_SUB_RNG](../advanced_config/parameter_reference.md#UAVCAN_SUB_RNG).
|
||||
- Set [EKF2_RNG_CTRL](../advanced_config/parameter_reference.md#EKF2_RNG_CTRL) to `1`.
|
||||
- Set [EKF2_RNG_A_HMAX](../advanced_config/parameter_reference.md#EKF2_RNG_A_HMAX) to `10`.
|
||||
- Set [EKF2_RNG_QLTY_T](../advanced_config/parameter_reference.md#EKF2_RNG_QLTY_T) to `0.2`.
|
||||
- Set [UAVCAN_RNG_MIN](../advanced_config/parameter_reference.md#UAVCAN_RNG_MIN) to `0.08`.
|
||||
|
||||
65
docs/uk/esc/ark_4in1_esc.md
Normal file
65
docs/uk/esc/ark_4in1_esc.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# ARK 4IN1 ESC (with/without Connectors)
|
||||
|
||||
4 in 1 Electronic Speed Controller (ESC) that is made in the USA, NDAA compliant, and DIU Blue Framework listed.
|
||||
|
||||
The ESC comes in variants without connectors that you can solder in place, and a variant that has built-in motor and battery connectors (no soldering required).
|
||||
|
||||
|
||||
|
||||
## Де купити
|
||||
|
||||
Замовте цей модуль з:
|
||||
|
||||
- [4IN1 ESC (with connectors)](https://arkelectron.com/product/ark-4in1-esc/) (ARK Electronics - US)
|
||||
- [ARK Electronics (without connectors)](https://arkelectron.com/product/ark-4in1-esc-cons/) (ARK Electronics US)
|
||||
|
||||
## Характеристики обладнання
|
||||
|
||||
- Battery Voltage: 3-8s
|
||||
- 6V Minimum
|
||||
- 65V Absolute Maximum
|
||||
|
||||
- Current Rating: 50A Continuous, 75A Burst Per Motor
|
||||
|
||||
- [STM32F0](https://www.st.com/en/microcontrollers-microprocessors/stm32f0-series.html)
|
||||
|
||||
- [AM32 Firmware](https://github.com/am32-firmware/AM32/pull/27)
|
||||
|
||||
- Onboard Current Sensor, Serial Telemetry
|
||||
- 100V/A
|
||||
|
||||
- Input Protocols
|
||||
- DShot (300, 600)
|
||||
- Bi-directional DShot
|
||||
- KISS Serial Telemetry
|
||||
- PWM
|
||||
|
||||
- 8 Pin JST-SH Input/Output
|
||||
|
||||
- 10 Pin JST-SH Debug
|
||||
|
||||
- Motor & Battery Connectors (with-connector version)
|
||||
|
||||
- MR30 Connector Limit Per Motor: 30A Continuous, 40A Burst
|
||||
- Four MR30 Motor Connectors
|
||||
|
||||
- Dimensions (with connectors)
|
||||
|
||||
- Size: 77.00mm x 42.00mm x 9.43mm
|
||||
- Mounting Pattern: 30.5mm
|
||||
- Weight: 24g
|
||||
|
||||
- Dimensions (without connectors)
|
||||
- Size: 43.00mm x 40.50mm x 7.60mm
|
||||
- Mounting Pattern: 30.5mm
|
||||
- Weight: 14.5g
|
||||
|
||||
Інше
|
||||
|
||||
- Made in the USA
|
||||
- Open source AM32 firmware
|
||||
- [DIU Blue Framework Listed](https://www.diu.mil/blue-uas/framework)
|
||||
|
||||
## Дивіться також
|
||||
|
||||
- [ARK 4IN1 ESC CONS](https://docs.arkelectron.com/electronic-speed-controller/ark-4in1-esc) (ARK Docs)
|
||||
66
docs/uk/esc/esc_protocols.md
Normal file
66
docs/uk/esc/esc_protocols.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# ESC Protocols
|
||||
|
||||
This topic lists the main [Electronic Speed Controller (ESC)](../peripherals/esc_motors.md) protocols supported by PX4.
|
||||
|
||||
## DShot
|
||||
|
||||
[DShot](../peripherals/dshot.md) is a digital ESC protocol that is highly recommended for vehicles that can benefit from reduced latency, in particular racing multicopters, VTOL vehicles, and so on.
|
||||
|
||||
It has reduced latency and is more robust than both [PWM](#pwm) and [OneShot](#oneshot-125).
|
||||
In addition it does not require ESC calibration, telemetry is available from some ESCs, and you can reverse motor spin directions.
|
||||
|
||||
PX4 configuration is done in the [Actuator Configuration](../config/actuators.md).
|
||||
Selecting a higher rate DShot ESC in the UI results in lower latency, but lower rates are more robust (and hence more suitable for large aircraft with longer leads); some ESCs only support lower rates (see datasheets for information).
|
||||
|
||||
Setup:
|
||||
|
||||
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
|
||||
- [DShot](../peripherals/dshot.md) also contains information about how to send commands etc.
|
||||
|
||||
## DroneCAN
|
||||
|
||||
[DroneCAN ESCs](../dronecan/escs.md) are recommended when DroneCAN is the primary bus used for your vehicle.
|
||||
The PX4 implementation is currently limited to update rates of 200 Hz.
|
||||
|
||||
DroneCAN shares many similar benefits to [DShot](#dshot) including high data rates, robust connection over long leads, telemetry feedback, no need for calibration of the ESC itself.
|
||||
|
||||
[DroneCAN ESCs](../dronecan/escs.md) are connected via the DroneCAN bus (setup and configuration are covered at that link).
|
||||
|
||||
## PWM
|
||||
|
||||
[PWM ESCs](../peripherals/pwm_escs_and_servo.md) are commonly used for fixed-wing vehicles and ground vehicles (vehicles that require a lower latency like multicopters typically use oneshot or dshot ESCs).
|
||||
|
||||
PWM ESCs communicate using a periodic pulse, where the _width_ of the pulse indicates the desired speed.
|
||||
The pulse width typically ranges between 1000 μs for zero power and 2000 μs for full power.
|
||||
The periodic frame rate of the signal depends on the capability of the ESC, and commonly ranges between 50 Hz and 490 Hz (the theoretical maximum being 500 Hz for a very small "off" cycle).
|
||||
A higher rate is better for ESCs, in particular where a rapid response to setpoint changes is needed.
|
||||
For PWM servos 50 Hz is usually sufficient, and many don't support higher rates.
|
||||
|
||||
|
||||
|
||||
In addition to being a relatively slow protocol PWM ESCs require [calibration](../advanced_config/esc_calibration.md) because the pulse widths representing low and high values can vary significantly.
|
||||
Unlike [DShot](#dshot) and [DroneCAN ESC](#dronecan) they do not have the ability to provide telemetry and feedback on ESC (or servo) state.
|
||||
|
||||
Setup:
|
||||
|
||||
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md)
|
||||
- [PX4 Configuration](../peripherals/pwm_escs_and_servo.md#px4-configuration)
|
||||
- [ESC Calibration](../advanced_config/esc_calibration.md)
|
||||
|
||||
## OneShot 125
|
||||
|
||||
[OneShot 125 ESCs](../peripherals/oneshot.md) are usually much faster than PWM ESCs, and hence more responsive and easier to tune.
|
||||
They are preferred over PWM for multicopters (but not as much as [DShot ESCs](#dshot), which do not require calibration, and may provide telemetry feedback).
|
||||
There are a number of variants of the OneShot protocol, which support different rates.
|
||||
PX4 only supports OneShot 125.
|
||||
|
||||
OneShot 125 is the same as PWM but uses pulse widths that are 8 times shorter (from 125 μs to 250 μs for zero to full power).
|
||||
This allows OneShot 125 ESCs to have a much shorter duty cycle/higher rate.
|
||||
For PWM the theoretical maximum is close to 500 Hz while for OneShot it approaches 4 kHz.
|
||||
The actual supported rate depends on the ESC used.
|
||||
|
||||
Setup:
|
||||
|
||||
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
|
||||
- [PX4 Configuration](../peripherals/oneshot.md#px4-configuration)
|
||||
- [ESC Calibration](../advanced_config/esc_calibration.md)
|
||||
@@ -280,6 +280,8 @@ For more information see: [Plotting uORB Topic Data in Real Time using PlotJuggl
|
||||
|
||||
## Дивіться також
|
||||
|
||||
- [uORB Documentation Standard](../uorb/uorb_documentation.md)
|
||||
|
||||
- _PX4 uORB Explained_ Blog series
|
||||
- [Part 1](https://px4.io/px4-uorb-explained-part-1/)
|
||||
- [Part 2](https://px4.io/px4-uorb-explained-part-2/)
|
||||
|
||||
@@ -3,80 +3,42 @@
|
||||
Багато дронів PX4 використовують безшовні двигуни, які керуються контролером польотів через електронний контролер швидкості (ESC).
|
||||
ESC бере сигнал від контролера польоту і використовує його для встановлення рівня потужності, яка постачається до двигуна.
|
||||
|
||||
PX4 supports a number of common protocols for sending the signals to ESCs: [PWM ESCs](../peripherals/pwm_escs_and_servo.md), [OneShot ESCs](../peripherals/oneshot.md), [DShot ESCs](../peripherals/dshot.md), [DroneCAN ESCs](../dronecan/escs.md), PCA9685 ESC (via I2C), and some UART ESCs (from Yuneec).
|
||||
PX4 supports a number of [common protocols](../esc/esc_protocols.md) for sending the signals to ESCs: [PWM ESCs](../peripherals/pwm_escs_and_servo.md), [OneShot ESCs](../peripherals/oneshot.md), [DShot ESCs](../peripherals/dshot.md), [DroneCAN ESCs](../dronecan/escs.md), PCA9685 ESC (via I2C), and some UART ESCs (from Yuneec).
|
||||
|
||||
## Supported ESC
|
||||
|
||||
The following list is non-exhaustive.
|
||||
|
||||
| ESC Device | Протоколи | Firmwares | Примітки |
|
||||
| ---------------------------- | ------------------------------------ | ------------------------ | ----------------------------------------------------- |
|
||||
| [ARK 4IN1 ESC] | [Dshot], [PWM] | [AM32] | Has versions with/without connnectors |
|
||||
| [Holybro Kotleta 20] | [DroneCAN], [PWM] | [PX4 Sapog ESC Firmware] | |
|
||||
| [Vertiq Motor & ESC modules] | [Dshot], [OneShot], Multishot, [PWM] | Vertiq firmware | Larger modules support DroneCAN, ESC and Motor in one |
|
||||
| [VESC ESCs] | [DroneCAN], [PWM] | VESC project firmware | |
|
||||
| [Zubax Telega] | [DroneCAN], [PWM] | Telega-based | ESC and Motor in one |
|
||||
|
||||
<!-- Links for table above -->
|
||||
|
||||
[ARK 4IN1 ESC]: ../esc/ark_4in1_esc.md
|
||||
[AM32]: https://am32.ca/
|
||||
[PX4 Sapog ESC Firmware]: ../dronecan/sapog.md
|
||||
[VESC ESCs]: ../peripherals/vesc.md
|
||||
[DroneCAN]: ../dronecan/escs.md
|
||||
[Dshot]: ../peripherals/dshot.md
|
||||
[OneShot]: ../peripherals/oneshot.md
|
||||
[PWM]: ../peripherals/pwm_escs_and_servo.md
|
||||
[Holybro Kotleta 20]: ../dronecan/holybro_kotleta.md
|
||||
[Vertiq Motor & ESC modules]: ../peripherals/vertiq.md
|
||||
[Zubax Telega]: ../dronecan/zubax_telega.md
|
||||
|
||||
## Дивіться також
|
||||
|
||||
Для додаткової інформації дивіться:
|
||||
|
||||
- [ESC Protocols](../esc/esc_protocols.md) — overview of main ESC/Servo protocols supported by PX4
|
||||
- [PWM ESCs and Servos](../peripherals/pwm_escs_and_servo.md)
|
||||
- [OneShot ESCs and Servos](../peripherals/oneshot.md)
|
||||
- [DShot](../peripherals/dshot.md)
|
||||
- [DroneCAN ESCs](../dronecan/escs.md)
|
||||
- [ESC Calibration](../advanced_config/esc_calibration.md)
|
||||
- [ESC Firmware and Protocols Overview](https://oscarliang.com/esc-firmware-protocols/) (oscarliang.com)
|
||||
|
||||
Огляд високого рівня основних протоколів ESC/Servo, які підтримуються PX4, наведено нижче.
|
||||
|
||||
## Протоколи ESC
|
||||
|
||||
### PWM
|
||||
|
||||
[PWM ESCs](../peripherals/pwm_escs_and_servo.md) are commonly used for fixed-wing vehicles and ground vehicles (vehicles that require a lower latency like multicopters typically use oneshot or dshot ESCs).
|
||||
|
||||
PWM ESCs communicate using a periodic pulse, where the _width_ of the pulse indicates the desired power level.
|
||||
Ширина імпульсу зазвичай коливається між 1000 мкс для нульової потужності та 2000 мкс для повної потужності.
|
||||
Періодична частота кадру сигналу залежить від можливості ESC і зазвичай коливається від 50 Гц до 490 Гц (теоретичний максимум становить 500 Гц для дуже малого циклу "вимкнено").
|
||||
Вища швидкість є кращою для ЕСК, особливо коли потрібна швидка реакція на зміни встановленої точки.
|
||||
Для серводвигунів з ШІМ зазвичай достатньо 50 Гц, і багато з них не підтримують вищі частоти.
|
||||
|
||||
|
||||
|
||||
In addition to being a relatively slow protocol PWM ESCs require [calibration](../advanced_config/esc_calibration.md) because the range values representing low and high values can vary significantly.
|
||||
Unlike [dshot](#dshot) and [DroneCAN ESC](#dronecan) they do not have the ability to provide telemetry and feedback on ESC (or servo) state.
|
||||
|
||||
Установка:
|
||||
|
||||
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md)
|
||||
- [PX4 Configuration](../peripherals/pwm_escs_and_servo.md#px4-configuration)
|
||||
- [ESC Calibration](../advanced_config/esc_calibration.md)
|
||||
|
||||
### Oneshot 125
|
||||
|
||||
[OneShot 125 ESCs](../peripherals/oneshot.md) are usually much faster than PWM ESCs, and hence more responsive and easier to tune.
|
||||
They are preferred over PWM for multicopters (but not as much as [DShot ESCs](#dshot), which do not require calibration, and may provide telemetry feedback).
|
||||
Існує кілька варіантів протоколу OneShot, які підтримують різні швидкості.
|
||||
PX4 підтримує лише OneShot 125.
|
||||
|
||||
OneShot 125 - це те саме, що і PWM, але використовує ширину імпульсів, яка в 8 разів коротша (від 125 мкс до 250 мкс для нуля до повної потужності).
|
||||
Це дозволяє ESC OneShot 125 мати набагато коротший цикл роботи / вищу швидкість.
|
||||
Для PWM теоретичний максимум становить близько 500 Гц, тоді як для OneShot він наближається до 4 кГц.
|
||||
Фактична підтримувана швидкість залежить від використаного ESC.
|
||||
|
||||
Установка:
|
||||
|
||||
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
|
||||
- [PX4 Configuration](../peripherals/oneshot.md#px4-configuration)
|
||||
- [ESC Calibration](../advanced_config/esc_calibration.md)
|
||||
|
||||
### DShot
|
||||
|
||||
[DShot](../peripherals/dshot.md) is a digital ESC protocol that is highly recommended for vehicles that can benefit from reduce latency, in particular racing multicopters, VTOL vehicles, and so on.
|
||||
|
||||
It has reduced latency and is more robust than both [PWM](#pwm) and [OneShot](#oneshot-125).
|
||||
Крім того, для його роботи не потрібна калібрування ESC, телеметрія доступна з деяких ESCs, і ви можете змінити напрямок обертання двигуна
|
||||
|
||||
PX4 configuration is done in the [Actuator Configuration](../config/actuators.md).
|
||||
Вибір ESC DShot з вищою швидкістю в інтерфейсі призводить до зниження затримки, але нижчі швидкості є більш надійними (і, отже, більш підходять для великих літаків з довшими проводами); деякі ESC підтримують лише нижчі швидкості (див. технічні характеристики для отримання інформації).
|
||||
|
||||
Установка:
|
||||
|
||||
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
|
||||
- [DShot](../peripherals/dshot.md) also contains information about how to send commands etc.
|
||||
|
||||
### DroneCAN
|
||||
|
||||
[DroneCAN ESCs](../dronecan/escs.md) are recommended when DroneCAN is the primary bus used for your vehicle.
|
||||
Реалізація PX4 наразі обмежена частотами оновлення 200 Гц.
|
||||
|
||||
DroneCAN shares many similar benefits to [Dshot](#dshot) including high data rates, robust connection over long leads, telemetry feedback, no need for calibration of the ESC itself.
|
||||
|
||||
[DroneCAN ESCs](../dronecan/escs.md) are connected via the DroneCAN bus (setup and configuration are covered at that link).
|
||||
|
||||
170
docs/uk/uorb/uorb_documentation.md
Normal file
170
docs/uk/uorb/uorb_documentation.md
Normal file
@@ -0,0 +1,170 @@
|
||||
# uORB Documentation Standard
|
||||
|
||||
This topic demonstrates and explains how to document uORB messages.
|
||||
|
||||
:::info
|
||||
At time of writing many topics have not been updated.
|
||||
:::
|
||||
|
||||
## Загальний огляд
|
||||
|
||||
The [AirspeedValidated](../msg_docs/AirspeedValidated.md) message shown below is a good example of a uORB topic that has been documented to the current standard.
|
||||
|
||||
```py
|
||||
# Validated airspeed
|
||||
#
|
||||
# Provides information about airspeed (indicated, true, calibrated) and the source of the data.
|
||||
# Used by controllers, estimators and for airspeed reporting to operator.
|
||||
|
||||
uint32 MESSAGE_VERSION = 1
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
|
||||
float32 indicated_airspeed_m_s # [m/s] [@invalid NaN] Indicated airspeed (IAS)
|
||||
float32 calibrated_airspeed_m_s # [m/s] [@invalid NaN] Calibrated airspeed (CAS)
|
||||
float32 true_airspeed_m_s # [m/s] [@invalid NaN] True airspeed (TAS)
|
||||
|
||||
int8 airspeed_source # [@enum SOURCE] Source of currently published airspeed values
|
||||
int8 SOURCE_DISABLED = -1 # Disabled
|
||||
int8 SOURCE_GROUND_MINUS_WIND = 0 # Ground speed minus wind
|
||||
int8 SOURCE_SENSOR_1 = 1 # Sensor 1
|
||||
int8 SOURCE_SENSOR_2 = 2 # Sensor 2
|
||||
int8 SOURCE_SENSOR_3 = 3 # Sensor 3
|
||||
int8 SOURCE_SYNTHETIC = 4 # Synthetic airspeed
|
||||
|
||||
float32 calibrated_ground_minus_wind_m_s # [m/s] [@invalid NaN] CAS calculated from groundspeed - windspeed, where windspeed is estimated based on a zero-sideslip assumption
|
||||
float32 calibraded_airspeed_synth_m_s # [m/s] [@invalid NaN] Synthetic airspeed
|
||||
float32 airspeed_derivative_filtered # [m/s^2] Filtered indicated airspeed derivative
|
||||
float32 throttle_filtered # [-] Filtered fixed-wing throttle
|
||||
float32 pitch_filtered # [rad] Filtered pitch
|
||||
```
|
||||
|
||||
The main things to note are:
|
||||
|
||||
- Documentation is added using formatted uORB comments.
|
||||
Any text on a line after the `#` character is a comment, except for lines that start with the text `# TOPIC` (which indicates a multi-topic message).
|
||||
- The message starts with a comment block consisting of short description (mandatory), followed by a longer description and then a space.
|
||||
- Field and constants almost all have comments.
|
||||
The comments are added on the same line as the field/constant, separated by one space.
|
||||
- Fields:
|
||||
- Comments are all on the same line as the field (extra lines become internal comments).
|
||||
- Comments start with metadata, such as the units (`[m/s]`, `[rad/s]`) or allowed values (`[@enum SOURCE]`), and can also list invalid values (`[@invalid NaN]`) and allowed ranges (`[@range min, max]`).
|
||||
- Units are required except for boolean fields or for fields with an enum value.
|
||||
`[-]` is used to indicate unitless fields.
|
||||
- Comments follow the metadata after a space.
|
||||
The line should not be terminated in a full stop.
|
||||
- Constants:
|
||||
- Don't have metadata: the description follows the comment marker after one space.
|
||||
- Some constants, such as `MESSAGE_VERSION`, don't need documentation because they are standardized.
|
||||
- Constants with the same name prefix are grouped together as enums after the associated field.
|
||||
|
||||
The following sections expand on the allowed formats.
|
||||
|
||||
## Message Description
|
||||
|
||||
Every message should start with a comment block that describes the message:
|
||||
|
||||
```py
|
||||
# Short description (mandatory)
|
||||
#
|
||||
# Longer description for the message if needed.
|
||||
# Can be multiline, and should have punctuation.
|
||||
# Should be followed by an empty line.
|
||||
```
|
||||
|
||||
This consists of a mandatory short description, optionally followed by an empty comment line, and then a longer description.
|
||||
|
||||
Short description (mandatory):
|
||||
|
||||
- A succinct explanation for the purpose of the message.
|
||||
- Usually just one line without a terminating full stop.
|
||||
- Minimally it may just mirror the message name.
|
||||
- For example, [`AirspeedValidated`](../msg_docs/AirspeedValidated.md) above has the short description `Validated airspeed`.
|
||||
|
||||
Long description (Optional):
|
||||
|
||||
- Additional context required to understand how the message is used.
|
||||
- In particular this should be anything that can't be inferred from the name, fields or constants, such as the publishers and expected consumers.
|
||||
It might also cover whether the message is only used for a particular frame type or mode.
|
||||
- The message is often multiline and contains punctuation.
|
||||
- May include comment lines that are empty, in order to indicate paragraphs.
|
||||
|
||||
Both short and long descriptions may be multi-line.
|
||||
Single line descriptions should not include a terminating full stop, but multiline comments should do so.
|
||||
|
||||
The message description block ends at the first non-comment line, which should be an empty line, but might be a field or constant.
|
||||
Any subsequent comment lines are considered "internal comments".
|
||||
|
||||
### Fields
|
||||
|
||||
A typical field comment looks like this:
|
||||
|
||||
```py
|
||||
float32 indicated_airspeed_m_s # [m/s] [@invalid NaN] Indicated airspeed (IAS)
|
||||
```
|
||||
|
||||
Field comments must all be on the same line as the field, and consist of optional metadata followed by a description:
|
||||
|
||||
- `metadata` (Optional)
|
||||
- Information about the field units and allowed values:
|
||||
- `[<unit>]`
|
||||
- The unit of measurement inside square brackets (note, no `@` delineator indicates a unit), such as `[m]` for metres.
|
||||
- Allowed units include: `m`, `m/s`, `m/s^2`, `rad`, `rad/s`, `rpm`, `V`, `A`, `mA`, `mAh`, `W`, `dBm`, `s`, `ms`, `us`, `Ohm`, `MB`, `Kb/s`, `degC`, `Pa`.
|
||||
- Units are required unless clearly invalid, such as when the field is a boolean, or is an enum value.
|
||||
- Unitless values should be specified as `[-]`.
|
||||
Note though that units are not required for boolean fields or enum fields.
|
||||
- `[@enum <enum_name>]`
|
||||
- The `enum_name` gives the prefix of constant values in the message that can be assigned to the field.
|
||||
Note that enums in uORB are just a naming convention: they are not explicitly declared.
|
||||
Multiple enum names allowed for a field indicates a possible error in the field design.
|
||||
- `[@range <lower_value>, <upper_value>]`
|
||||
- The allowed range of the field, specified as a `lower_value` and/or an `upper_value`.
|
||||
Either value can be omitted to indicate an unbounded upper or lower value.
|
||||
For example `[@range 0, 3]`, `[@range 5.3, ]`, `[@range , 3]`.
|
||||
- `[@invalid <value> <description>]`
|
||||
- The `value` to set the field to indicate that the field doesn't contain valid data, such as `[@invalid NaN]`.
|
||||
The `description` is optional, and might be used to indicate the conditions under which data is invalid.
|
||||
- `[@frame <value>]`
|
||||
- The `frame` in which the field is set, such as `[@frame NED]` or `[@frame Body]`.
|
||||
- `description`
|
||||
- A concise description of the purpose of the field, and including any important information that can't be inferred from the name!
|
||||
Use a capital first letter, and omit the full stop if the description is a single sentence.
|
||||
Multiple sentences may also omit the final full stop.
|
||||
|
||||
### Constants
|
||||
|
||||
Constants follow the documentation conventions as fields except they only have a description (no metadata).
|
||||
Documentation for a constant might look like this:
|
||||
|
||||
```py
|
||||
int8 SOURCE_GROUND_MINUS_WIND = 0 # Ground speed minus wind
|
||||
```
|
||||
|
||||
Constants are often grouped together following a field as enum values.
|
||||
Note below how the prefix `SOURCE` for the values is specified as an enum against the _field_.
|
||||
|
||||
```py
|
||||
int8 airspeed_source # [@enum SOURCE] Source of currently published airspeed values
|
||||
int8 SOURCE_DISABLED = -1 # Disabled
|
||||
int8 SOURCE_GROUND_MINUS_WIND = 0 # Ground speed minus wind
|
||||
...
|
||||
```
|
||||
|
||||
A small number of constants have a standardised meaning and do not require documentation.
|
||||
These are:
|
||||
|
||||
- `ORB_QUEUE_LENGTH`
|
||||
- `MESSAGE_VERSION`
|
||||
|
||||
### `# TOPICS`
|
||||
|
||||
The prefix `# TOPICS` is used to indicate topic names for multi-topic messages.
|
||||
For example, the [VehicleGlobalPosition.msg](../msg_docs/VehicleGlobalPosition.md) message definition is used to define the topic ids as shown:
|
||||
|
||||
```text
|
||||
# TOPICS vehicle_global_position vehicle_global_position_groundtruth external_ins_global_position
|
||||
# TOPICS estimator_global_position
|
||||
# TOPICS aux_global_position
|
||||
```
|
||||
|
||||
At time of writing there is no format for documenting these.
|
||||
Reference in New Issue
Block a user