mirror of
https://github.com/betaflight/betaflight.git
synced 2025-07-16 21:05:35 +03:00
Normalize all the line endings
This commit is contained in:
Dominic Clifton
parent
4237370b60
commit
d60183d91d
396 changed files with 158300 additions and 158300 deletions
104
docs/Autotune.md
104
docs/Autotune.md
|
|
@ -1,53 +1,53 @@
|
|||
# Autotune
|
||||
|
||||
Autotune helps to automatically tune your multirotor.
|
||||
|
||||
## Configuration.
|
||||
|
||||
Autotune only works in HORIZON or ANGLE mode, before using auto-tune it's best you setup so there is as little drift as possible.
|
||||
Autotuning is best on a full battery in good flying conditions, i.e. no or minimal wind.
|
||||
|
||||
Configure a two position switch on your transmitter to activate the AUTOTUNE and HORIZON or ANGLE modes using the auxilary configuration.
|
||||
You may find a momentary switch more suitable than a toggle switch.
|
||||
|
||||
|
||||
## Using autotuning
|
||||
|
||||
Turn off the autotune switch. If the autotune switch is on while not armed the warning LED will flash and you cannot arm.
|
||||
|
||||
Launch the multirotor.
|
||||
|
||||
Turn on/hold the autotune switch on your transmitter.
|
||||
|
||||
Observe roll left/right. A beep code will sound on the beeper.
|
||||
|
||||
Turn off/release the switch while still flying to stop this phase of tuning.
|
||||
|
||||
PID settings will have been updated for ROLL/YAW.
|
||||
|
||||
Turn on/hold the switch again.
|
||||
|
||||
Observe pitch forwards/backwards. A beep code will sound on the beeper.
|
||||
|
||||
Turn off/release the switch while still flying to stop this phase of tuning.
|
||||
|
||||
PID settings will have been updated for PITCH/YAW.
|
||||
|
||||
PIDS are updated, fly and see if it's better.
|
||||
|
||||
If it's worse, flip the switch again to restore previous pids that were present prior to arming.
|
||||
|
||||
Land.
|
||||
|
||||
Verify results via an app while power still applied if desired.
|
||||
|
||||
Cutting the power will loose the unsaved pids.
|
||||
|
||||
If you're happy with the pids then while disarmed flip the autotune switch again to save all settings then flip it back so you can arm again.
|
||||
|
||||
A beeper will sound indicating the settings are saved.
|
||||
|
||||
|
||||
# References
|
||||
|
||||
# Autotune
|
||||
|
||||
Autotune helps to automatically tune your multirotor.
|
||||
|
||||
## Configuration.
|
||||
|
||||
Autotune only works in HORIZON or ANGLE mode, before using auto-tune it's best you setup so there is as little drift as possible.
|
||||
Autotuning is best on a full battery in good flying conditions, i.e. no or minimal wind.
|
||||
|
||||
Configure a two position switch on your transmitter to activate the AUTOTUNE and HORIZON or ANGLE modes using the auxilary configuration.
|
||||
You may find a momentary switch more suitable than a toggle switch.
|
||||
|
||||
|
||||
## Using autotuning
|
||||
|
||||
Turn off the autotune switch. If the autotune switch is on while not armed the warning LED will flash and you cannot arm.
|
||||
|
||||
Launch the multirotor.
|
||||
|
||||
Turn on/hold the autotune switch on your transmitter.
|
||||
|
||||
Observe roll left/right. A beep code will sound on the beeper.
|
||||
|
||||
Turn off/release the switch while still flying to stop this phase of tuning.
|
||||
|
||||
PID settings will have been updated for ROLL/YAW.
|
||||
|
||||
Turn on/hold the switch again.
|
||||
|
||||
Observe pitch forwards/backwards. A beep code will sound on the beeper.
|
||||
|
||||
Turn off/release the switch while still flying to stop this phase of tuning.
|
||||
|
||||
PID settings will have been updated for PITCH/YAW.
|
||||
|
||||
PIDS are updated, fly and see if it's better.
|
||||
|
||||
If it's worse, flip the switch again to restore previous pids that were present prior to arming.
|
||||
|
||||
Land.
|
||||
|
||||
Verify results via an app while power still applied if desired.
|
||||
|
||||
Cutting the power will loose the unsaved pids.
|
||||
|
||||
If you're happy with the pids then while disarmed flip the autotune switch again to save all settings then flip it back so you can arm again.
|
||||
|
||||
A beeper will sound indicating the settings are saved.
|
||||
|
||||
|
||||
# References
|
||||
|
||||
* Brad Quick for the initial Autotune algorithm in BradWii.
|
||||
|
|
@ -1,18 +1,18 @@
|
|||
# Board - CC3D
|
||||
|
||||
The OpenPilot Copter Control 3D aka CC3D is a board more tuned to Acrobatic flying or GPS based
|
||||
auto-piloting. It only has one sensor, the MPU6000 SPI based Accelerometer/Gyro.
|
||||
It also features a 16mbit SPI based EEPROM chip. It has 6 ports labelled as inputs (one pin each)
|
||||
and 6 ports labelled as motor/servo outputs (3 pins each).
|
||||
|
||||
If issues are found with this board please report via the github issue tracker.
|
||||
|
||||
# Serial Ports
|
||||
|
||||
| Value | Identifier | Board Markings | Notes |
|
||||
| ----- | ------------ | -------------- | -----------------------------------------|
|
||||
| 1 | USART1 | MAIN PORT | Has a hardware inverter for SBUS |
|
||||
| 2 | USART3 | FLEX PORT | |
|
||||
|
||||
Software serial is not supported yet due to timer and pin configuration mappings.
|
||||
|
||||
# Board - CC3D
|
||||
|
||||
The OpenPilot Copter Control 3D aka CC3D is a board more tuned to Acrobatic flying or GPS based
|
||||
auto-piloting. It only has one sensor, the MPU6000 SPI based Accelerometer/Gyro.
|
||||
It also features a 16mbit SPI based EEPROM chip. It has 6 ports labelled as inputs (one pin each)
|
||||
and 6 ports labelled as motor/servo outputs (3 pins each).
|
||||
|
||||
If issues are found with this board please report via the github issue tracker.
|
||||
|
||||
# Serial Ports
|
||||
|
||||
| Value | Identifier | Board Markings | Notes |
|
||||
| ----- | ------------ | -------------- | -----------------------------------------|
|
||||
| 1 | USART1 | MAIN PORT | Has a hardware inverter for SBUS |
|
||||
| 2 | USART3 | FLEX PORT | |
|
||||
|
||||
Software serial is not supported yet due to timer and pin configuration mappings.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
# Board - Naze32
|
||||
|
||||
The Naze32 target supports all Naze hardware revisions. Revison 4 and Revision 5 are used and
|
||||
frequently flown by the primary maintainer. Previous Naze hardware revisions may have issues,
|
||||
if found please report via the github issue tracker.
|
||||
|
||||
# Serial Ports
|
||||
|
||||
| Value | Identifier | Board Markings | Notes |
|
||||
| ----- | ------------ | -------------- | -----------------------------------------|
|
||||
| 1 | USART1 | RX/TX / TELEM | Also connected to USB port via CP2102 IC |
|
||||
| 2 | USART2 | RC3/4 | |
|
||||
| 3 | SoftSerial 1 | RC5/6 | |
|
||||
| 4 | SoftSerial 2 | RC7/8 | |
|
||||
|
||||
# Board - Naze32
|
||||
|
||||
The Naze32 target supports all Naze hardware revisions. Revison 4 and Revision 5 are used and
|
||||
frequently flown by the primary maintainer. Previous Naze hardware revisions may have issues,
|
||||
if found please report via the github issue tracker.
|
||||
|
||||
# Serial Ports
|
||||
|
||||
| Value | Identifier | Board Markings | Notes |
|
||||
| ----- | ------------ | -------------- | -----------------------------------------|
|
||||
| 1 | USART1 | RX/TX / TELEM | Also connected to USB port via CP2102 IC |
|
||||
| 2 | USART2 | RC3/4 | |
|
||||
| 3 | SoftSerial 1 | RC5/6 | |
|
||||
| 4 | SoftSerial 2 | RC7/8 | |
|
||||
|
||||
|
|
|
|||
|
|
@ -1,22 +1,22 @@
|
|||
# Buzzer
|
||||
|
||||
Cleanflight supports a buzzer which is used for the following purposes, and more:
|
||||
|
||||
Low Battery alarm (when battery monitoring enabled)
|
||||
Notification of calibration complete status.
|
||||
AUX operated beeping - useful for locating your aircraft after a crash.
|
||||
Failsafe status.
|
||||
|
||||
Buzzer is enabled by default on platforms that have buzzer connections.
|
||||
|
||||
## Types of buzzer supported
|
||||
|
||||
The buzzers are enabled/disabled by simply enabling or disabling a GPIO output pin on the board.
|
||||
This means the buzzer must be able to generate it's own tone simply by having power applied to it.
|
||||
|
||||
Buzzers that need an analogue or PWM signal do not work and will make clicking noises or no sound at all.
|
||||
|
||||
Example of a known-working buzzer.
|
||||
|
||||
http://www.rapidonline.com/Audio-Visual/Hcm1205x-Miniature-Buzzer-5v-35-0055
|
||||
|
||||
# Buzzer
|
||||
|
||||
Cleanflight supports a buzzer which is used for the following purposes, and more:
|
||||
|
||||
Low Battery alarm (when battery monitoring enabled)
|
||||
Notification of calibration complete status.
|
||||
AUX operated beeping - useful for locating your aircraft after a crash.
|
||||
Failsafe status.
|
||||
|
||||
Buzzer is enabled by default on platforms that have buzzer connections.
|
||||
|
||||
## Types of buzzer supported
|
||||
|
||||
The buzzers are enabled/disabled by simply enabling or disabling a GPIO output pin on the board.
|
||||
This means the buzzer must be able to generate it's own tone simply by having power applied to it.
|
||||
|
||||
Buzzers that need an analogue or PWM signal do not work and will make clicking noises or no sound at all.
|
||||
|
||||
Example of a known-working buzzer.
|
||||
|
||||
http://www.rapidonline.com/Audio-Visual/Hcm1205x-Miniature-Buzzer-5v-35-0055
|
||||
|
||||
|
|
|
|||
|
|
@ -1,69 +1,69 @@
|
|||
#Development
|
||||
|
||||
This document is primarily for developers only.
|
||||
|
||||
##Unit testing
|
||||
|
||||
Ideally, there should be tests for any new code. However, since this is a legacy codebase which was not designed to be tested this might be a bit difficult.
|
||||
|
||||
If you want to make changes and want to make sure it's tested then focus on the minimal set of changes required to add a test.
|
||||
|
||||
Tests currently live in the `test` folder and they use the google test framework.
|
||||
The tests are compiled and run natively on your development machine and not on the target platform.
|
||||
This allows you to develop tests and code and actually execute it to make sure it works without needing a development board or simulator.
|
||||
|
||||
This project could really do with some functional tests which test the behaviour of the application.
|
||||
|
||||
All pull requests to add/improve the testability of the code or testing methods are highly sought!
|
||||
|
||||
##General principals
|
||||
|
||||
1. Name everything well.
|
||||
2. Strike a balance between simplicity and not-repeating code.
|
||||
3. Methods that return a boolean should be named as a question, and should not change state. e.g. 'isOkToArm()'
|
||||
4. Methods that start with the word 'find' can return a null, methods that start with 'get' should not.
|
||||
5. Methods should have verb or verb-phrase names, like `deletePage` or `save`. Variables should not, they generally should be nouns. Tell the system to 'do' something 'with' something. e.g. deleteAllPages(pageList).
|
||||
6. Keep methods short - it makes it easier to test.
|
||||
7. Don't be afraid of moving code to a new file - it helps to reduce test dependencies.
|
||||
8. Avoid noise-words in variable names, like 'data' or 'info'. Think about what you're naming and name it well. Don't be afraid to rename anything.
|
||||
9. Avoid comments taht describe what the code is doing, the code should describe itself. Comments are useful however for big-picture purposes and to document content of variables.
|
||||
10. If you need to document a variable do it at the declarion, don't copy the comment to the `extern` usage since it will lead to comment rot.
|
||||
11. Seek advice from other developers - know you can always learn more.
|
||||
12. Be professional - attempts at humor or slating existing code in the codebase itself is not helpful when you have to change/fix it.
|
||||
13. Know that there's always more than one way to do something and that code is never final - but it does have to work.
|
||||
|
||||
###Running the tests.
|
||||
|
||||
The tests and test build system is very simple and based of the googletest example files, it will be improved in due course.
|
||||
|
||||
```
|
||||
cd test
|
||||
make
|
||||
```
|
||||
|
||||
This will build a set of executable files, one for each `*_unittest.cc` file.
|
||||
|
||||
You can run them on the command line to execute the tests and to see the test report.
|
||||
|
||||
You can also step-debug the tests in eclipse and you can use the GoogleTest test runner to make building and re-running the tests simple.
|
||||
|
||||
The tests are currently always compiled with debugging information enabled, there may be additional warnings, if you see any warnings please attempt to fix them and submit pull requests with the fixes.
|
||||
|
||||
|
||||
##TODO
|
||||
|
||||
* Test OpenLRSNG's RSSI PWM on AUX5-8.
|
||||
* Add support for UART3/4 on STM32F3.
|
||||
* Cleanup validateAndFixConfig and pwm_mapping.c to use some kind of feature/timer/io pin mapping to remove #ifdef
|
||||
* Split RX config into RC config and RX config.
|
||||
* Enabling/disabling features should not take effect until reboot since. Main loop executes and uses new flags as they are set in the cli but
|
||||
appropriate init methods will not have been called which results in undefined behaviour and could damage connected devices - this is a legacy
|
||||
problem from baseflight.
|
||||
* Solve all the naze rev4/5 HSE_VALUE == 8000000/1200000 checking, the checks should only apply to the naze32 target. See system_stm32f10x.c/SetSysClock().
|
||||
|
||||
##Known Issues
|
||||
|
||||
* Softserial RX on STM32F3 does not work. TX is fine.
|
||||
* Dynamic throttle PID does not work with new pid controller.
|
||||
* Autotune does not work yet with with new pid controller.
|
||||
|
||||
#Development
|
||||
|
||||
This document is primarily for developers only.
|
||||
|
||||
##Unit testing
|
||||
|
||||
Ideally, there should be tests for any new code. However, since this is a legacy codebase which was not designed to be tested this might be a bit difficult.
|
||||
|
||||
If you want to make changes and want to make sure it's tested then focus on the minimal set of changes required to add a test.
|
||||
|
||||
Tests currently live in the `test` folder and they use the google test framework.
|
||||
The tests are compiled and run natively on your development machine and not on the target platform.
|
||||
This allows you to develop tests and code and actually execute it to make sure it works without needing a development board or simulator.
|
||||
|
||||
This project could really do with some functional tests which test the behaviour of the application.
|
||||
|
||||
All pull requests to add/improve the testability of the code or testing methods are highly sought!
|
||||
|
||||
##General principals
|
||||
|
||||
1. Name everything well.
|
||||
2. Strike a balance between simplicity and not-repeating code.
|
||||
3. Methods that return a boolean should be named as a question, and should not change state. e.g. 'isOkToArm()'
|
||||
4. Methods that start with the word 'find' can return a null, methods that start with 'get' should not.
|
||||
5. Methods should have verb or verb-phrase names, like `deletePage` or `save`. Variables should not, they generally should be nouns. Tell the system to 'do' something 'with' something. e.g. deleteAllPages(pageList).
|
||||
6. Keep methods short - it makes it easier to test.
|
||||
7. Don't be afraid of moving code to a new file - it helps to reduce test dependencies.
|
||||
8. Avoid noise-words in variable names, like 'data' or 'info'. Think about what you're naming and name it well. Don't be afraid to rename anything.
|
||||
9. Avoid comments taht describe what the code is doing, the code should describe itself. Comments are useful however for big-picture purposes and to document content of variables.
|
||||
10. If you need to document a variable do it at the declarion, don't copy the comment to the `extern` usage since it will lead to comment rot.
|
||||
11. Seek advice from other developers - know you can always learn more.
|
||||
12. Be professional - attempts at humor or slating existing code in the codebase itself is not helpful when you have to change/fix it.
|
||||
13. Know that there's always more than one way to do something and that code is never final - but it does have to work.
|
||||
|
||||
###Running the tests.
|
||||
|
||||
The tests and test build system is very simple and based of the googletest example files, it will be improved in due course.
|
||||
|
||||
```
|
||||
cd test
|
||||
make
|
||||
```
|
||||
|
||||
This will build a set of executable files, one for each `*_unittest.cc` file.
|
||||
|
||||
You can run them on the command line to execute the tests and to see the test report.
|
||||
|
||||
You can also step-debug the tests in eclipse and you can use the GoogleTest test runner to make building and re-running the tests simple.
|
||||
|
||||
The tests are currently always compiled with debugging information enabled, there may be additional warnings, if you see any warnings please attempt to fix them and submit pull requests with the fixes.
|
||||
|
||||
|
||||
##TODO
|
||||
|
||||
* Test OpenLRSNG's RSSI PWM on AUX5-8.
|
||||
* Add support for UART3/4 on STM32F3.
|
||||
* Cleanup validateAndFixConfig and pwm_mapping.c to use some kind of feature/timer/io pin mapping to remove #ifdef
|
||||
* Split RX config into RC config and RX config.
|
||||
* Enabling/disabling features should not take effect until reboot since. Main loop executes and uses new flags as they are set in the cli but
|
||||
appropriate init methods will not have been called which results in undefined behaviour and could damage connected devices - this is a legacy
|
||||
problem from baseflight.
|
||||
* Solve all the naze rev4/5 HSE_VALUE == 8000000/1200000 checking, the checks should only apply to the naze32 target. See system_stm32f10x.c/SetSysClock().
|
||||
|
||||
##Known Issues
|
||||
|
||||
* Softserial RX on STM32F3 does not work. TX is fine.
|
||||
* Dynamic throttle PID does not work with new pid controller.
|
||||
* Autotune does not work yet with with new pid controller.
|
||||
|
||||
|
|
|
|||
112
docs/Display.md
112
docs/Display.md
|
|
@ -1,56 +1,56 @@
|
|||
# Display
|
||||
|
||||
Cleanflight supports displays to provide information to you about your aircraft and cleanflight state.
|
||||
|
||||
##Supported Hardware
|
||||
|
||||
At this time no other displays are supported other than the SSD1306 / UG-2864HSWEG01.
|
||||
|
||||
### SSD1306 OLED displays
|
||||
|
||||
The SSD1306 display is a 128x64 OLED display that is visible in full sunlight, small and consumes very little current.
|
||||
This makes it ideal for aircraft use.
|
||||
|
||||
There are various models of SSD1306 boards out there, they are not all equal and some require addtional modifications
|
||||
before they work. Choose wisely!
|
||||
|
||||
Links to screens:
|
||||
|
||||
http://www.banggood.com/0_96-Inch-I2C-IIC-SPI-Serial-128-X-64-OLED-LCD-LED-Display-Module-p-922246.html
|
||||
http://www.wide.hk/products.php?product=I2C-0.96%22-OLED-display-module-%28-compatible-Arduino-%29
|
||||
http://witespyquad.gostorego.com/accessories/readytofly-1-oled-128x64-pid-tuning-display-i2c.html
|
||||
http://www.multiwiicopter.com/products/1-oled
|
||||
|
||||
The banggood.com screen is the cheapest at the time fo writing and will correctly send I2C ACK signals.
|
||||
|
||||
#### Crius CO-16
|
||||
|
||||
This screen is best avoided but will work if you modify it.
|
||||
|
||||
Step 1
|
||||
|
||||
As supplied the I2C ack signal is not sent because the manufacturer did not bridge D1 and D2 together. To fix this solder
|
||||
the two pins together as they enter the screen. Failure to do this will result is a screen that doesn't display anything.
|
||||
|
||||
Step 2
|
||||
|
||||
Pin 14 must be disconnected from the main board using a scalpel. Then connect a 10nF or 100nF capacitor between pins 30 and the
|
||||
lifted pin 14.
|
||||
|
||||
Step 3
|
||||
|
||||
Connect a 100K resistor between Pin 9 and the lifted Pin 14.
|
||||
|
||||
Failure to perform steps 2 and 3 will result in a display that only works on power up some of the time any may display random dots
|
||||
or other display corruption.
|
||||
|
||||
More can be read about this procedure here: http://www.multiwii.com/forum/viewtopic.php?f=6&t=2705&start=10
|
||||
|
||||
There are diagrams in the Wiring directory.
|
||||
|
||||
## Connections
|
||||
|
||||
Connect +5v, Ground, I2C SDA and I2C SCL from the flight controller to the display.
|
||||
|
||||
|
||||
|
||||
# Display
|
||||
|
||||
Cleanflight supports displays to provide information to you about your aircraft and cleanflight state.
|
||||
|
||||
##Supported Hardware
|
||||
|
||||
At this time no other displays are supported other than the SSD1306 / UG-2864HSWEG01.
|
||||
|
||||
### SSD1306 OLED displays
|
||||
|
||||
The SSD1306 display is a 128x64 OLED display that is visible in full sunlight, small and consumes very little current.
|
||||
This makes it ideal for aircraft use.
|
||||
|
||||
There are various models of SSD1306 boards out there, they are not all equal and some require addtional modifications
|
||||
before they work. Choose wisely!
|
||||
|
||||
Links to screens:
|
||||
|
||||
http://www.banggood.com/0_96-Inch-I2C-IIC-SPI-Serial-128-X-64-OLED-LCD-LED-Display-Module-p-922246.html
|
||||
http://www.wide.hk/products.php?product=I2C-0.96%22-OLED-display-module-%28-compatible-Arduino-%29
|
||||
http://witespyquad.gostorego.com/accessories/readytofly-1-oled-128x64-pid-tuning-display-i2c.html
|
||||
http://www.multiwiicopter.com/products/1-oled
|
||||
|
||||
The banggood.com screen is the cheapest at the time fo writing and will correctly send I2C ACK signals.
|
||||
|
||||
#### Crius CO-16
|
||||
|
||||
This screen is best avoided but will work if you modify it.
|
||||
|
||||
Step 1
|
||||
|
||||
As supplied the I2C ack signal is not sent because the manufacturer did not bridge D1 and D2 together. To fix this solder
|
||||
the two pins together as they enter the screen. Failure to do this will result is a screen that doesn't display anything.
|
||||
|
||||
Step 2
|
||||
|
||||
Pin 14 must be disconnected from the main board using a scalpel. Then connect a 10nF or 100nF capacitor between pins 30 and the
|
||||
lifted pin 14.
|
||||
|
||||
Step 3
|
||||
|
||||
Connect a 100K resistor between Pin 9 and the lifted Pin 14.
|
||||
|
||||
Failure to perform steps 2 and 3 will result in a display that only works on power up some of the time any may display random dots
|
||||
or other display corruption.
|
||||
|
||||
More can be read about this procedure here: http://www.multiwii.com/forum/viewtopic.php?f=6&t=2705&start=10
|
||||
|
||||
There are diagrams in the Wiring directory.
|
||||
|
||||
## Connections
|
||||
|
||||
Connect +5v, Ground, I2C SDA and I2C SCL from the flight controller to the display.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
128
docs/Failsafe.md
128
docs/Failsafe.md
|
|
@ -1,64 +1,64 @@
|
|||
# Failsafe
|
||||
|
||||
There are two types of failsafe:
|
||||
|
||||
1. receiver based failsafe
|
||||
2. flight controller based failsafe
|
||||
|
||||
Receiver based failsafe is where you, from your transmitter and receiver, configure channels to output desired signals if your receiver detects signal loss.
|
||||
The idea is that you set throttle and other controls so the aircraft descends in a controlled manner.
|
||||
|
||||
Flight controller based failsafe is where the flight controller attempts to detect signal loss from your receiver.
|
||||
|
||||
It is possible to use both types at the same time and may be desirable. Flight controller failsafe can even help if your receiver signal wires come loose, get damaged or your receiver malfunctions in a way the receiver itself cannot detect.
|
||||
|
||||
## Flight controller failsafe system
|
||||
|
||||
The failsafe system is not activated until 5 seconds after the flight controller boots up. This is to prevent failsafe from activating in the case of TX/RX gear with long bind procedures before they send out valid data.
|
||||
|
||||
After the failsafe has been forced a landing, the flight controller cannot be armed and has to be reset.
|
||||
|
||||
The failsafe system attempts to detect when your receiver looses signal. It then attempts to prevent your aircraft from flying away uncontrollably.
|
||||
|
||||
The failsafe is activated when:
|
||||
|
||||
a) no valid channel data from the RX via Serial RX.
|
||||
b) the first 4 Parallel PWM/PPM channels do not have valid signals.
|
||||
|
||||
There are a few settings for it, as below.
|
||||
|
||||
Failsafe delays are configured in 0.1 second steps.
|
||||
|
||||
1 step = 0.1sec
|
||||
1 second = 10 steps
|
||||
|
||||
### `failsafe_delay`
|
||||
|
||||
Guard time for failsafe activation after signal lost.
|
||||
|
||||
### `failsafe_off_delay`
|
||||
|
||||
Delay after failsafe activates before motors finally turn off. If you fly high you may need more time.
|
||||
|
||||
### `failsafe_throttle`
|
||||
|
||||
Throttle level used for landing. Specify a value that causes the aircraft to descend at about 1M/sec.
|
||||
|
||||
Use standard RX usec values. See Rx documentation.
|
||||
|
||||
### `failsafe_min_usec`
|
||||
|
||||
The shortest PWM/PPM pulse considered valid.
|
||||
|
||||
Only valid when using Parallel PWM or PPM receivers.
|
||||
|
||||
### `failsafe_max_usec`
|
||||
|
||||
The longest PWM/PPM pulse considered valid.
|
||||
|
||||
Only valid when using Parallel PWM or PPM receivers.
|
||||
|
||||
This setting helps catch when your RX stops sending any data when the RX looses signal.
|
||||
|
||||
With a Graupner GR-24 configured for PWM output with failsafe on channels 1-4 set to OFF in the receiver settings
|
||||
then this setting, at it's default value, will allow failsafe to be activated.
|
||||
# Failsafe
|
||||
|
||||
There are two types of failsafe:
|
||||
|
||||
1. receiver based failsafe
|
||||
2. flight controller based failsafe
|
||||
|
||||
Receiver based failsafe is where you, from your transmitter and receiver, configure channels to output desired signals if your receiver detects signal loss.
|
||||
The idea is that you set throttle and other controls so the aircraft descends in a controlled manner.
|
||||
|
||||
Flight controller based failsafe is where the flight controller attempts to detect signal loss from your receiver.
|
||||
|
||||
It is possible to use both types at the same time and may be desirable. Flight controller failsafe can even help if your receiver signal wires come loose, get damaged or your receiver malfunctions in a way the receiver itself cannot detect.
|
||||
|
||||
## Flight controller failsafe system
|
||||
|
||||
The failsafe system is not activated until 5 seconds after the flight controller boots up. This is to prevent failsafe from activating in the case of TX/RX gear with long bind procedures before they send out valid data.
|
||||
|
||||
After the failsafe has been forced a landing, the flight controller cannot be armed and has to be reset.
|
||||
|
||||
The failsafe system attempts to detect when your receiver looses signal. It then attempts to prevent your aircraft from flying away uncontrollably.
|
||||
|
||||
The failsafe is activated when:
|
||||
|
||||
a) no valid channel data from the RX via Serial RX.
|
||||
b) the first 4 Parallel PWM/PPM channels do not have valid signals.
|
||||
|
||||
There are a few settings for it, as below.
|
||||
|
||||
Failsafe delays are configured in 0.1 second steps.
|
||||
|
||||
1 step = 0.1sec
|
||||
1 second = 10 steps
|
||||
|
||||
### `failsafe_delay`
|
||||
|
||||
Guard time for failsafe activation after signal lost.
|
||||
|
||||
### `failsafe_off_delay`
|
||||
|
||||
Delay after failsafe activates before motors finally turn off. If you fly high you may need more time.
|
||||
|
||||
### `failsafe_throttle`
|
||||
|
||||
Throttle level used for landing. Specify a value that causes the aircraft to descend at about 1M/sec.
|
||||
|
||||
Use standard RX usec values. See Rx documentation.
|
||||
|
||||
### `failsafe_min_usec`
|
||||
|
||||
The shortest PWM/PPM pulse considered valid.
|
||||
|
||||
Only valid when using Parallel PWM or PPM receivers.
|
||||
|
||||
### `failsafe_max_usec`
|
||||
|
||||
The longest PWM/PPM pulse considered valid.
|
||||
|
||||
Only valid when using Parallel PWM or PPM receivers.
|
||||
|
||||
This setting helps catch when your RX stops sending any data when the RX looses signal.
|
||||
|
||||
With a Graupner GR-24 configured for PWM output with failsafe on channels 1-4 set to OFF in the receiver settings
|
||||
then this setting, at it's default value, will allow failsafe to be activated.
|
||||
|
|
|
|||
56
docs/Gps.md
56
docs/Gps.md
|
|
@ -1,28 +1,28 @@
|
|||
# GPS
|
||||
|
||||
Two GPS protocols are supported. NMEA text and UBLOX Binary.
|
||||
|
||||
## GPS Provider
|
||||
|
||||
Set the `gps_provider` appropriately.
|
||||
|
||||
| Value | Meaning |
|
||||
| ----- | -------- |
|
||||
| 0 | NMEA |
|
||||
| 1 | UBLOX |
|
||||
|
||||
## SBAS
|
||||
|
||||
When using a UBLOX GPS the SBAS mode can be configured using `gps_sbas_mode`.
|
||||
|
||||
The default is AUTO.
|
||||
|
||||
| Value | Meaning | Region |
|
||||
| ----- | -------- | ------------- |
|
||||
| 0 | AUTO | Global |
|
||||
| 1 | EGNOS | Europe |
|
||||
| 2 | WAAS | North America |
|
||||
| 3 | MSAS | Asia |
|
||||
| 4 | GAGAN | India |
|
||||
|
||||
If you use a regional specific setting you may achieve a faster GPS lock than using AUTO.
|
||||
# GPS
|
||||
|
||||
Two GPS protocols are supported. NMEA text and UBLOX Binary.
|
||||
|
||||
## GPS Provider
|
||||
|
||||
Set the `gps_provider` appropriately.
|
||||
|
||||
| Value | Meaning |
|
||||
| ----- | -------- |
|
||||
| 0 | NMEA |
|
||||
| 1 | UBLOX |
|
||||
|
||||
## SBAS
|
||||
|
||||
When using a UBLOX GPS the SBAS mode can be configured using `gps_sbas_mode`.
|
||||
|
||||
The default is AUTO.
|
||||
|
||||
| Value | Meaning | Region |
|
||||
| ----- | -------- | ------------- |
|
||||
| 0 | AUTO | Global |
|
||||
| 1 | EGNOS | Europe |
|
||||
| 2 | WAAS | North America |
|
||||
| 3 | MSAS | Asia |
|
||||
| 4 | GAGAN | India |
|
||||
|
||||
If you use a regional specific setting you may achieve a faster GPS lock than using AUTO.
|
||||
|
|
|
|||
|
|
@ -1,101 +1,101 @@
|
|||
# Migrating from baseflight
|
||||
|
||||
## Procedure
|
||||
|
||||
First ensure your main flight battery is disconnected or your props are off!
|
||||
|
||||
Before flashing with cleanflight, dump your configs for each profile via the CLI and save to a text file.
|
||||
|
||||
profile 0
|
||||
dump
|
||||
profile 1
|
||||
dump
|
||||
profile 2
|
||||
dump
|
||||
|
||||
Then after flashing cleanflight paste the output from each dump command into the cli, switching profiles as you go.
|
||||
|
||||
You'll note that some commands are not recognised by cleanflight when you do this. For the commands that are not recognised look
|
||||
up the new configuration options and choose appropriate values for the settings. See below for a list of differences.
|
||||
|
||||
Once you've done this for the first profile, save the config. Then verify your config is OK, e.g. features serial ports, etc.
|
||||
When you've verified the first profile is OK repeat for the other profiles.
|
||||
|
||||
It's also advisable to take screenshots of your AUX settings from baseflight configurator and then after re-applying the settings
|
||||
verify your aux config is correct - some changes were made and some aux settings are not backwards compatible.
|
||||
|
||||
## CLI command differences from baseflight
|
||||
|
||||
In general all CLI commands use underscore characters to separate words for consistency. In baseflight the format of CLI commands is somewhat haphazard.
|
||||
|
||||
### gps_baudrate
|
||||
reason: simplify
|
||||
|
||||
Cleanflight uses normal baud rate values for gps baudrate, baseflight uses an index.
|
||||
|
||||
If an unsupported baud rate value is used the gps code will select 115200 baud.
|
||||
|
||||
example: `set gps_baudrate = 115200`
|
||||
|
||||
|
||||
### gps_type
|
||||
reason: renamed to `gps_provider` for consistency
|
||||
|
||||
### serialrx_type
|
||||
reason: renamed to `serialrx_provider` for consistency
|
||||
|
||||
### rssi_aux_channel
|
||||
reason: improved functionality
|
||||
|
||||
Cleanflight supports using any RX channel for rssi. Baseflight only supports AUX1 to 4.
|
||||
|
||||
In Cleanflight a value of 0 disables the feature, a higher value indicates the channel number to read RSSI information from.
|
||||
|
||||
Example: to use RSSI on AUX1 in Cleanflight use `set rssi_aux_channel = 5`, since 5 is the first AUX channel.
|
||||
|
||||
### failsafe_detect_threshold
|
||||
reason: improved functionality
|
||||
|
||||
See `failsafe_min_usec` and `failsafe_max_usec` in Failsafe documentation.
|
||||
|
||||
### emfavoidance
|
||||
reason: renamed to `emf_avoidance` for consistency
|
||||
|
||||
### yawrate
|
||||
reason: renamed to `yaw_rate` for consistency
|
||||
|
||||
### yawdeadband
|
||||
reason: renamed to `yaw_deadband` for consistency
|
||||
|
||||
### midrc
|
||||
reason: renamed to `midrc` for consistency
|
||||
|
||||
### mincheck
|
||||
reason: renamed to `min_check` for consistency
|
||||
|
||||
### maxcheck
|
||||
reason: renamed to `max_check` for consistency
|
||||
|
||||
### minthrottle
|
||||
reason: renamed to `min_throttle` for consistency
|
||||
|
||||
### maxthrottle
|
||||
reason: renamed to `max_throttle` for consistency
|
||||
|
||||
### mincommand
|
||||
reason: renamed to `min_command` for consistency
|
||||
|
||||
### deadband3d_low
|
||||
reason: renamed to `3d_deadband_low` for consistency
|
||||
|
||||
### deadband3d_high
|
||||
reason: renamed to `3d_deadband_high` for consistency
|
||||
|
||||
### deadband3d_throttle
|
||||
reason: renamed to `3d_deadband_throttle` for consistency
|
||||
|
||||
### neutral3d
|
||||
reason: renamed to `3d_neutral` for consistency
|
||||
|
||||
### alt_hold_throttle_neutral
|
||||
reason: renamed to 'alt_hold_deadband'
|
||||
# Migrating from baseflight
|
||||
|
||||
## Procedure
|
||||
|
||||
First ensure your main flight battery is disconnected or your props are off!
|
||||
|
||||
Before flashing with cleanflight, dump your configs for each profile via the CLI and save to a text file.
|
||||
|
||||
profile 0
|
||||
dump
|
||||
profile 1
|
||||
dump
|
||||
profile 2
|
||||
dump
|
||||
|
||||
Then after flashing cleanflight paste the output from each dump command into the cli, switching profiles as you go.
|
||||
|
||||
You'll note that some commands are not recognised by cleanflight when you do this. For the commands that are not recognised look
|
||||
up the new configuration options and choose appropriate values for the settings. See below for a list of differences.
|
||||
|
||||
Once you've done this for the first profile, save the config. Then verify your config is OK, e.g. features serial ports, etc.
|
||||
When you've verified the first profile is OK repeat for the other profiles.
|
||||
|
||||
It's also advisable to take screenshots of your AUX settings from baseflight configurator and then after re-applying the settings
|
||||
verify your aux config is correct - some changes were made and some aux settings are not backwards compatible.
|
||||
|
||||
## CLI command differences from baseflight
|
||||
|
||||
In general all CLI commands use underscore characters to separate words for consistency. In baseflight the format of CLI commands is somewhat haphazard.
|
||||
|
||||
### gps_baudrate
|
||||
reason: simplify
|
||||
|
||||
Cleanflight uses normal baud rate values for gps baudrate, baseflight uses an index.
|
||||
|
||||
If an unsupported baud rate value is used the gps code will select 115200 baud.
|
||||
|
||||
example: `set gps_baudrate = 115200`
|
||||
|
||||
|
||||
### gps_type
|
||||
reason: renamed to `gps_provider` for consistency
|
||||
|
||||
### serialrx_type
|
||||
reason: renamed to `serialrx_provider` for consistency
|
||||
|
||||
### rssi_aux_channel
|
||||
reason: improved functionality
|
||||
|
||||
Cleanflight supports using any RX channel for rssi. Baseflight only supports AUX1 to 4.
|
||||
|
||||
In Cleanflight a value of 0 disables the feature, a higher value indicates the channel number to read RSSI information from.
|
||||
|
||||
Example: to use RSSI on AUX1 in Cleanflight use `set rssi_aux_channel = 5`, since 5 is the first AUX channel.
|
||||
|
||||
### failsafe_detect_threshold
|
||||
reason: improved functionality
|
||||
|
||||
See `failsafe_min_usec` and `failsafe_max_usec` in Failsafe documentation.
|
||||
|
||||
### emfavoidance
|
||||
reason: renamed to `emf_avoidance` for consistency
|
||||
|
||||
### yawrate
|
||||
reason: renamed to `yaw_rate` for consistency
|
||||
|
||||
### yawdeadband
|
||||
reason: renamed to `yaw_deadband` for consistency
|
||||
|
||||
### midrc
|
||||
reason: renamed to `midrc` for consistency
|
||||
|
||||
### mincheck
|
||||
reason: renamed to `min_check` for consistency
|
||||
|
||||
### maxcheck
|
||||
reason: renamed to `max_check` for consistency
|
||||
|
||||
### minthrottle
|
||||
reason: renamed to `min_throttle` for consistency
|
||||
|
||||
### maxthrottle
|
||||
reason: renamed to `max_throttle` for consistency
|
||||
|
||||
### mincommand
|
||||
reason: renamed to `min_command` for consistency
|
||||
|
||||
### deadband3d_low
|
||||
reason: renamed to `3d_deadband_low` for consistency
|
||||
|
||||
### deadband3d_high
|
||||
reason: renamed to `3d_deadband_high` for consistency
|
||||
|
||||
### deadband3d_throttle
|
||||
reason: renamed to `3d_deadband_throttle` for consistency
|
||||
|
||||
### neutral3d
|
||||
reason: renamed to `3d_neutral` for consistency
|
||||
|
||||
### alt_hold_throttle_neutral
|
||||
reason: renamed to 'alt_hold_deadband'
|
||||
|
|
|
|||
76
docs/Rssi.md
76
docs/Rssi.md
|
|
@ -1,38 +1,38 @@
|
|||
# RSSI
|
||||
|
||||
RSSI is a measurement of signal strength. RSSI is very handy so you know when you are going out of range or there is interference.
|
||||
|
||||
Some receivers have RSSI outputs. 3 types are supported.
|
||||
|
||||
1. RSSI via PPM channel
|
||||
2. RSSI via Parallel PWM channel
|
||||
3. RSSI via ADC with PPM RC that has an RSSI output - aka RSSI ADC
|
||||
|
||||
## RSSI via PPM
|
||||
|
||||
Configure your receiver to output RSSI on a spare channel, then select the channel used via the cli.
|
||||
|
||||
e.g. if you used channel 1 then you would set:
|
||||
|
||||
```
|
||||
set rssi_channel = 1
|
||||
```
|
||||
|
||||
## RSSI via Parallel PWM channel
|
||||
|
||||
Connect the RSSI signal to any PWM input channel then set the RSSI channel as you would for RSSI via PPM
|
||||
|
||||
## RSSI ADC
|
||||
|
||||
Connect the RSSI signal to the RC2/CH2 input. The signal must be between 0v and 3.3v to indicate between 0% and 100% RSSI.
|
||||
Use inline resistors to lower voltage if required, inline smoothing capacitors may also help.
|
||||
|
||||
FrSky D4R-II and X8R supported.
|
||||
|
||||
Enable using the RSSI_ADC feature:
|
||||
|
||||
```
|
||||
feature RSSI_ADC
|
||||
```
|
||||
|
||||
The feature can not be used when RX_PARALLEL_PWM is enabled.
|
||||
# RSSI
|
||||
|
||||
RSSI is a measurement of signal strength. RSSI is very handy so you know when you are going out of range or there is interference.
|
||||
|
||||
Some receivers have RSSI outputs. 3 types are supported.
|
||||
|
||||
1. RSSI via PPM channel
|
||||
2. RSSI via Parallel PWM channel
|
||||
3. RSSI via ADC with PPM RC that has an RSSI output - aka RSSI ADC
|
||||
|
||||
## RSSI via PPM
|
||||
|
||||
Configure your receiver to output RSSI on a spare channel, then select the channel used via the cli.
|
||||
|
||||
e.g. if you used channel 1 then you would set:
|
||||
|
||||
```
|
||||
set rssi_channel = 1
|
||||
```
|
||||
|
||||
## RSSI via Parallel PWM channel
|
||||
|
||||
Connect the RSSI signal to any PWM input channel then set the RSSI channel as you would for RSSI via PPM
|
||||
|
||||
## RSSI ADC
|
||||
|
||||
Connect the RSSI signal to the RC2/CH2 input. The signal must be between 0v and 3.3v to indicate between 0% and 100% RSSI.
|
||||
Use inline resistors to lower voltage if required, inline smoothing capacitors may also help.
|
||||
|
||||
FrSky D4R-II and X8R supported.
|
||||
|
||||
Enable using the RSSI_ADC feature:
|
||||
|
||||
```
|
||||
feature RSSI_ADC
|
||||
```
|
||||
|
||||
The feature can not be used when RX_PARALLEL_PWM is enabled.
|
||||
|
|
|
|||
86
docs/Rx.md
86
docs/Rx.md
|
|
@ -1,43 +1,43 @@
|
|||
# Receivers (RX)
|
||||
|
||||
## Parallel PWM
|
||||
|
||||
8 channel support, 1 channel per input pin. On some platforms using parallel input will disable the use of serial ports
|
||||
and softserial making it hard to use telemetry or gps features.
|
||||
|
||||
## PPM (PPM SUM)
|
||||
|
||||
12 channels via a single input pin, not as accurate or jitter free as methods that use serial communications.
|
||||
|
||||
## MultiWii serial protocol (MSP)
|
||||
|
||||
Allows you to use MSP commands as the RC input. Only 8 channel support to maintain compatibility with MSP.
|
||||
|
||||
## Spektrum
|
||||
|
||||
12 channels via serial currently supported.
|
||||
|
||||
## SUMD
|
||||
|
||||
8 channels supported currently, 12 or more is technically possible.
|
||||
|
||||
## SBUS
|
||||
|
||||
12 channels via serial supported currently.
|
||||
|
||||
|
||||
### Configuration
|
||||
|
||||
See the Configuration document some some RX configuration examples.
|
||||
|
||||
#### PPM/PWM input filtering.
|
||||
|
||||
Hardware input filtering can be enabled if you are experiencing interference on the signal sent via your PWM/PPM RX.
|
||||
|
||||
Use the `input_filtering_mode` cli command to select a mode.
|
||||
|
||||
| Value | Meaning |
|
||||
| ----- | --------- |
|
||||
| 0 | Disabled |
|
||||
| 1 | Enabled |
|
||||
|
||||
# Receivers (RX)
|
||||
|
||||
## Parallel PWM
|
||||
|
||||
8 channel support, 1 channel per input pin. On some platforms using parallel input will disable the use of serial ports
|
||||
and softserial making it hard to use telemetry or gps features.
|
||||
|
||||
## PPM (PPM SUM)
|
||||
|
||||
12 channels via a single input pin, not as accurate or jitter free as methods that use serial communications.
|
||||
|
||||
## MultiWii serial protocol (MSP)
|
||||
|
||||
Allows you to use MSP commands as the RC input. Only 8 channel support to maintain compatibility with MSP.
|
||||
|
||||
## Spektrum
|
||||
|
||||
12 channels via serial currently supported.
|
||||
|
||||
## SUMD
|
||||
|
||||
8 channels supported currently, 12 or more is technically possible.
|
||||
|
||||
## SBUS
|
||||
|
||||
12 channels via serial supported currently.
|
||||
|
||||
|
||||
### Configuration
|
||||
|
||||
See the Configuration document some some RX configuration examples.
|
||||
|
||||
#### PPM/PWM input filtering.
|
||||
|
||||
Hardware input filtering can be enabled if you are experiencing interference on the signal sent via your PWM/PPM RX.
|
||||
|
||||
Use the `input_filtering_mode` cli command to select a mode.
|
||||
|
||||
| Value | Meaning |
|
||||
| ----- | --------- |
|
||||
| 0 | Disabled |
|
||||
| 1 | Enabled |
|
||||
|
||||
|
|
|
|||
|
|
@ -1,141 +1,141 @@
|
|||
# Serial Configuration
|
||||
|
||||
Cleanflight has enhanced serial port flexibility but configuration is slightly more complex as a result.
|
||||
|
||||
Cleanflight has the concept of a function (MSP, GPS, Serial RX, etc) and a port (USARTx, SoftSerial x). Not all
|
||||
functions can be used on all ports due to hardware pin mapping, conflicting features and software constraints.
|
||||
|
||||
To make configuration easier common usage scenarios are listed below.
|
||||
|
||||
## Serial port scenarios
|
||||
|
||||
```
|
||||
0 UNUSED
|
||||
1 MSP, CLI, TELEMETRY, GPS-PASTHROUGH
|
||||
2 GPS ONLY
|
||||
3 RX SERIAL ONLY
|
||||
4 TELEMETRY ONLY
|
||||
5 MSP, CLI, GPS-PASTHROUGH
|
||||
6 CLI ONLY
|
||||
7 GPS-PASSTHROUGH ONLY
|
||||
8 MSP ONLY
|
||||
```
|
||||
|
||||
## Contraints
|
||||
|
||||
* There must always be a port available to use for MSP
|
||||
* There must always be a port available to use for CLI
|
||||
* To use a port for a function, the function's corresponding feature must be enabled first.
|
||||
e.g. to use GPS enable the GPS feature.
|
||||
* If the configuration is invalid the serial port configuration will reset to it's defaults and features may be disabled.
|
||||
|
||||
## Examples
|
||||
|
||||
All examples assume default configuration (via cli `defaults` command)
|
||||
|
||||
a) GPS and FrSky TELEMETRY (when armed)
|
||||
|
||||
- TELEMETRY,MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- GPS on UART2
|
||||
|
||||
```
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
save
|
||||
```
|
||||
|
||||
b) RX SERIAL and FrSky TELEMETRY (when armed)
|
||||
|
||||
- TELEMETRY,MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- RX SERIAL on UART2
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_SERIAL
|
||||
feature TELEMETRY
|
||||
set serial_port_2_scenario = 3
|
||||
save
|
||||
```
|
||||
|
||||
b) RX SERIAL and FrSky TELEMETRY via softserial
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- RX SERIAL on UART2
|
||||
- TELEMETRY on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_SERIAL
|
||||
feature TELEMETRY
|
||||
feature SOFTSERIAL
|
||||
set serial_port_2_scenario = 3
|
||||
set serial_port_3_scenario = 4
|
||||
save
|
||||
```
|
||||
|
||||
c) GPS and FrSky TELEMETRY via softserial
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- GPS on UART2
|
||||
- TELEMETRY on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_PPM
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
feature SOFTSERIAL
|
||||
set serial_port_3_scenario = 4
|
||||
save
|
||||
```
|
||||
d) RX SERIAL, GPS and TELEMETRY (when armed) MSP/CLI via softserial
|
||||
|
||||
- GPS on UART1
|
||||
- RX SERIAL on UART2
|
||||
- TELEMETRY,MSP,CLI,GPS PASSTHROUGH on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
feature RX_SERIAL
|
||||
feature SOFTSERIAL
|
||||
set serial_port_1_scenario = 2
|
||||
set serial_port_2_scenario = 3
|
||||
set serial_port_3_scenario = 1
|
||||
set msp_baudrate = 19200
|
||||
set cli_baudrate = 19200
|
||||
set gps_passthrough_baudrate = 19200
|
||||
save
|
||||
```
|
||||
|
||||
e) HoTT Telemetry via UART2
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- HoTT telemetry on UART2
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_PPM
|
||||
feature TELEMETRY
|
||||
set serial_port_2_scenario = 4
|
||||
set telemetry_provider = 1
|
||||
```
|
||||
|
||||
f) GPS, HoTT Telemetry via SoftSerial 1
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- GPS on UART2
|
||||
- HoTT telemetry on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_PPM
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
feature SOFTSERIAL
|
||||
set serial_port_3_scenario = 4
|
||||
set telemetry_provider = 1
|
||||
save
|
||||
```
|
||||
|
||||
# Serial Configuration
|
||||
|
||||
Cleanflight has enhanced serial port flexibility but configuration is slightly more complex as a result.
|
||||
|
||||
Cleanflight has the concept of a function (MSP, GPS, Serial RX, etc) and a port (USARTx, SoftSerial x). Not all
|
||||
functions can be used on all ports due to hardware pin mapping, conflicting features and software constraints.
|
||||
|
||||
To make configuration easier common usage scenarios are listed below.
|
||||
|
||||
## Serial port scenarios
|
||||
|
||||
```
|
||||
0 UNUSED
|
||||
1 MSP, CLI, TELEMETRY, GPS-PASTHROUGH
|
||||
2 GPS ONLY
|
||||
3 RX SERIAL ONLY
|
||||
4 TELEMETRY ONLY
|
||||
5 MSP, CLI, GPS-PASTHROUGH
|
||||
6 CLI ONLY
|
||||
7 GPS-PASSTHROUGH ONLY
|
||||
8 MSP ONLY
|
||||
```
|
||||
|
||||
## Contraints
|
||||
|
||||
* There must always be a port available to use for MSP
|
||||
* There must always be a port available to use for CLI
|
||||
* To use a port for a function, the function's corresponding feature must be enabled first.
|
||||
e.g. to use GPS enable the GPS feature.
|
||||
* If the configuration is invalid the serial port configuration will reset to it's defaults and features may be disabled.
|
||||
|
||||
## Examples
|
||||
|
||||
All examples assume default configuration (via cli `defaults` command)
|
||||
|
||||
a) GPS and FrSky TELEMETRY (when armed)
|
||||
|
||||
- TELEMETRY,MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- GPS on UART2
|
||||
|
||||
```
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
save
|
||||
```
|
||||
|
||||
b) RX SERIAL and FrSky TELEMETRY (when armed)
|
||||
|
||||
- TELEMETRY,MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- RX SERIAL on UART2
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_SERIAL
|
||||
feature TELEMETRY
|
||||
set serial_port_2_scenario = 3
|
||||
save
|
||||
```
|
||||
|
||||
b) RX SERIAL and FrSky TELEMETRY via softserial
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- RX SERIAL on UART2
|
||||
- TELEMETRY on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_SERIAL
|
||||
feature TELEMETRY
|
||||
feature SOFTSERIAL
|
||||
set serial_port_2_scenario = 3
|
||||
set serial_port_3_scenario = 4
|
||||
save
|
||||
```
|
||||
|
||||
c) GPS and FrSky TELEMETRY via softserial
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- GPS on UART2
|
||||
- TELEMETRY on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_PPM
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
feature SOFTSERIAL
|
||||
set serial_port_3_scenario = 4
|
||||
save
|
||||
```
|
||||
d) RX SERIAL, GPS and TELEMETRY (when armed) MSP/CLI via softserial
|
||||
|
||||
- GPS on UART1
|
||||
- RX SERIAL on UART2
|
||||
- TELEMETRY,MSP,CLI,GPS PASSTHROUGH on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
feature RX_SERIAL
|
||||
feature SOFTSERIAL
|
||||
set serial_port_1_scenario = 2
|
||||
set serial_port_2_scenario = 3
|
||||
set serial_port_3_scenario = 1
|
||||
set msp_baudrate = 19200
|
||||
set cli_baudrate = 19200
|
||||
set gps_passthrough_baudrate = 19200
|
||||
save
|
||||
```
|
||||
|
||||
e) HoTT Telemetry via UART2
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- HoTT telemetry on UART2
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_PPM
|
||||
feature TELEMETRY
|
||||
set serial_port_2_scenario = 4
|
||||
set telemetry_provider = 1
|
||||
```
|
||||
|
||||
f) GPS, HoTT Telemetry via SoftSerial 1
|
||||
|
||||
- MSP,CLI,GPS PASSTHROUGH on UART1
|
||||
- GPS on UART2
|
||||
- HoTT telemetry on SOFTSERIAL1
|
||||
|
||||
```
|
||||
feature -RX_PARALLEL_PWM
|
||||
feature RX_PPM
|
||||
feature TELEMETRY
|
||||
feature GPS
|
||||
feature SOFTSERIAL
|
||||
set serial_port_3_scenario = 4
|
||||
set telemetry_provider = 1
|
||||
save
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,29 +1,29 @@
|
|||
# Sonar
|
||||
|
||||
A sonar sensor can be used to measure altitude for use with altitude hold modes.
|
||||
|
||||
The current sensor takes over from the pressure sensor at low altitudes, but only when
|
||||
the angle of the aircraft is small.
|
||||
|
||||
## Hardware
|
||||
|
||||
Currently the only supported sensor is the HCSR04 sensor.
|
||||
|
||||
## Connections
|
||||
|
||||
### Naze/Flip32+
|
||||
|
||||
| Mode | Trigger | Echo | Inline 1k resistors |
|
||||
| ------------- | ------------- | ------------- | ------------------- |
|
||||
| Parallel PWM | PB8 / Motor 5 | PB9 / Motor 6 | NO (5v tolerant) |
|
||||
| PPM/Serial RX | PB0 / RC7 | PB1 / RC8 | YES (3.3v input) |
|
||||
|
||||
Current meter cannot be used in conjunction with Parallel PWM and Sonar.
|
||||
|
||||
### Olimexino
|
||||
|
||||
| Trigger | Echo | Inline 1k resistors |
|
||||
| ------------- | ------------- | ------------------- |
|
||||
| PB0 / RC7 | PB1 / RC8 | YES (3.3v input) |
|
||||
|
||||
Current meter cannot be used in conjunction sonar.
|
||||
# Sonar
|
||||
|
||||
A sonar sensor can be used to measure altitude for use with altitude hold modes.
|
||||
|
||||
The current sensor takes over from the pressure sensor at low altitudes, but only when
|
||||
the angle of the aircraft is small.
|
||||
|
||||
## Hardware
|
||||
|
||||
Currently the only supported sensor is the HCSR04 sensor.
|
||||
|
||||
## Connections
|
||||
|
||||
### Naze/Flip32+
|
||||
|
||||
| Mode | Trigger | Echo | Inline 1k resistors |
|
||||
| ------------- | ------------- | ------------- | ------------------- |
|
||||
| Parallel PWM | PB8 / Motor 5 | PB9 / Motor 6 | NO (5v tolerant) |
|
||||
| PPM/Serial RX | PB0 / RC7 | PB1 / RC8 | YES (3.3v input) |
|
||||
|
||||
Current meter cannot be used in conjunction with Parallel PWM and Sonar.
|
||||
|
||||
### Olimexino
|
||||
|
||||
| Trigger | Echo | Inline 1k resistors |
|
||||
| ------------- | ------------- | ------------------- |
|
||||
| PB0 / RC7 | PB1 / RC8 | YES (3.3v input) |
|
||||
|
||||
Current meter cannot be used in conjunction sonar.
|
||||
|
|
|
|||
|
|
@ -1,80 +1,80 @@
|
|||
# Telemetry
|
||||
|
||||
Telemetry allows you to know what is happening on your aircraft while you are flying it. Among other things you can receive battery voltages and GPS positions on your transmitter.
|
||||
|
||||
Telemetry can be either always on, or enabled when armed. If no serial port is set to be telemetry-only then telemetry will only be enabled when armed.
|
||||
|
||||
Telemetry is enabled using the 'TELEMETRY` feature.
|
||||
|
||||
```
|
||||
feature TELEMETRY
|
||||
```
|
||||
|
||||
Three telemetry providers are currently supported, FrSky (the default), Graupner HoTT V4 and MultiWii Serial Protocol (MSP)
|
||||
|
||||
Use the `telemetry_provider` cli command to select one.
|
||||
|
||||
| Value | Meaning |
|
||||
| ----- | --------------- |
|
||||
| 0 | FrSky (Default) |
|
||||
| 1 | HoTT |
|
||||
| 2 | MSP |
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
set telemetry_provider = 1
|
||||
```
|
||||
|
||||
There are further examples in the Configuration section of the documentation.
|
||||
|
||||
## FrSky telemetry
|
||||
|
||||
FrSky telemetry is transmit only and just requires a single connection from the TX pin of a serial port to the RX pin on an FrSky telemetry receiver.
|
||||
|
||||
FrSky telemetry signals are inverted. To connect a cleanflight capable board to an FrSKy receiver you have some options.
|
||||
|
||||
1. A hardware inverter - Built in to some flight controllers.
|
||||
2. Use software serial and enable frsky_inversion.
|
||||
3. Use a flight controller that has software configurable hardware inversion (e.g. STM32F30x).
|
||||
|
||||
For 1, just connect your inverter to a usart or software serial port.
|
||||
|
||||
For 2 and 3 use the cli command as follows:
|
||||
|
||||
```
|
||||
set frsky_inversion = 1
|
||||
```
|
||||
|
||||
## HoTT telemetry
|
||||
|
||||
HoTT telemetry can be used when the TX and RX pins of a serial port are connected using a diode and a single wire to the T port on a HoTT receiver.
|
||||
|
||||
Only Electric Air Modules and GPS Modules are emulated, remember to enable them on your transmitter - in the Telemetry Menu on the MX-20.
|
||||
|
||||
Serial ports use two wires but HoTT uses a single wire so some electronics are required so that the signals don't get mixed up.
|
||||
|
||||
Connect as follows:
|
||||
```
|
||||
HoTT TX/RX -> Serial RX (connect directly)
|
||||
Serial TX -> 1N4148 Diode -(| )-> HoTT TX/RX (connect via diode)
|
||||
```
|
||||
|
||||
The diode should be arranged to allow the data signals to flow the right way
|
||||
|
||||
```
|
||||
-(| )- == Diode, | indicates cathode marker.
|
||||
```
|
||||
|
||||
As noticed by Skrebber the GR-12 (and probably GR-16/24, too) are based on a PIC 24FJ64GA-002, which has 5V tolerant digital pins.
|
||||
|
||||
Note: The softserial ports are not listed as 5V tolerant in the STM32F103xx data sheet pinouts and pin description section. Verify if you require a 5v/3.3v level shifters.
|
||||
|
||||
## MultiWii Serial Protocol (MSP)
|
||||
|
||||
MSP Telemetry simply transmitts MSP packets in sequence to any MSP device attached to the telemetry port. It rotates though a fixes sequence of command responses.
|
||||
|
||||
It is transmit only, it can work at any supported baud rate.
|
||||
|
||||
MSP telemetry is currently only output on serial ports that are set to MSP, NOT telemetry.
|
||||
This will likely change in the future so that the MSP telemetry uses ports configured as telemetry just like the other providers do.
|
||||
# Telemetry
|
||||
|
||||
Telemetry allows you to know what is happening on your aircraft while you are flying it. Among other things you can receive battery voltages and GPS positions on your transmitter.
|
||||
|
||||
Telemetry can be either always on, or enabled when armed. If no serial port is set to be telemetry-only then telemetry will only be enabled when armed.
|
||||
|
||||
Telemetry is enabled using the 'TELEMETRY` feature.
|
||||
|
||||
```
|
||||
feature TELEMETRY
|
||||
```
|
||||
|
||||
Three telemetry providers are currently supported, FrSky (the default), Graupner HoTT V4 and MultiWii Serial Protocol (MSP)
|
||||
|
||||
Use the `telemetry_provider` cli command to select one.
|
||||
|
||||
| Value | Meaning |
|
||||
| ----- | --------------- |
|
||||
| 0 | FrSky (Default) |
|
||||
| 1 | HoTT |
|
||||
| 2 | MSP |
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
set telemetry_provider = 1
|
||||
```
|
||||
|
||||
There are further examples in the Configuration section of the documentation.
|
||||
|
||||
## FrSky telemetry
|
||||
|
||||
FrSky telemetry is transmit only and just requires a single connection from the TX pin of a serial port to the RX pin on an FrSky telemetry receiver.
|
||||
|
||||
FrSky telemetry signals are inverted. To connect a cleanflight capable board to an FrSKy receiver you have some options.
|
||||
|
||||
1. A hardware inverter - Built in to some flight controllers.
|
||||
2. Use software serial and enable frsky_inversion.
|
||||
3. Use a flight controller that has software configurable hardware inversion (e.g. STM32F30x).
|
||||
|
||||
For 1, just connect your inverter to a usart or software serial port.
|
||||
|
||||
For 2 and 3 use the cli command as follows:
|
||||
|
||||
```
|
||||
set frsky_inversion = 1
|
||||
```
|
||||
|
||||
## HoTT telemetry
|
||||
|
||||
HoTT telemetry can be used when the TX and RX pins of a serial port are connected using a diode and a single wire to the T port on a HoTT receiver.
|
||||
|
||||
Only Electric Air Modules and GPS Modules are emulated, remember to enable them on your transmitter - in the Telemetry Menu on the MX-20.
|
||||
|
||||
Serial ports use two wires but HoTT uses a single wire so some electronics are required so that the signals don't get mixed up.
|
||||
|
||||
Connect as follows:
|
||||
```
|
||||
HoTT TX/RX -> Serial RX (connect directly)
|
||||
Serial TX -> 1N4148 Diode -(| )-> HoTT TX/RX (connect via diode)
|
||||
```
|
||||
|
||||
The diode should be arranged to allow the data signals to flow the right way
|
||||
|
||||
```
|
||||
-(| )- == Diode, | indicates cathode marker.
|
||||
```
|
||||
|
||||
As noticed by Skrebber the GR-12 (and probably GR-16/24, too) are based on a PIC 24FJ64GA-002, which has 5V tolerant digital pins.
|
||||
|
||||
Note: The softserial ports are not listed as 5V tolerant in the STM32F103xx data sheet pinouts and pin description section. Verify if you require a 5v/3.3v level shifters.
|
||||
|
||||
## MultiWii Serial Protocol (MSP)
|
||||
|
||||
MSP Telemetry simply transmitts MSP packets in sequence to any MSP device attached to the telemetry port. It rotates though a fixes sequence of command responses.
|
||||
|
||||
It is transmit only, it can work at any supported baud rate.
|
||||
|
||||
MSP telemetry is currently only output on serial ports that are set to MSP, NOT telemetry.
|
||||
This will likely change in the future so that the MSP telemetry uses ports configured as telemetry just like the other providers do.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue