From ddfe58fcf9d498007b8a6301fe048f0d1d7ad950 Mon Sep 17 00:00:00 2001 From: NootSoGreen <47856015+NootSoGreen@users.noreply.github.com> Date: Tue, 22 Oct 2024 00:28:36 +0800 Subject: [PATCH] Docs: Checked wiki for spelling errors (#474) * checked guides, configurator, tuning sections of wiki for spelling errors * Update docs/wiki/guides/archive/Single-Wire-Software-Serial.md Co-authored-by: Mark Haslinghuis * Update docs/wiki/guides/current/Magnetometer.md Co-authored-by: Mark Haslinghuis --------- Co-authored-by: Mark Haslinghuis --- .../wiki/configurator/firmware-flasher-tab.md | 14 +++--- docs/wiki/configurator/ports-tab.md | 4 +- docs/wiki/configurator/power-tab.md | 4 +- docs/wiki/configurator/presets-tab.md | 2 +- docs/wiki/configurator/setup-tab.md | 4 +- .../getting-started/hardware/esc-firmware.md | 14 +++--- docs/wiki/getting-started/hardware/index.md | 6 +-- docs/wiki/getting-started/hardware/vtx.md | 6 +-- docs/wiki/getting-started/setup-guide.md | 8 ++-- docs/wiki/getting-started/troubleshooting.md | 4 +- .../guides/archive/Barometer-Configuration.md | 2 +- .../archive/Betaflight-2-x-CLI-commands.md | 2 +- .../guides/archive/Failsafe-Before-4-3.md | 2 +- docs/wiki/guides/archive/GPS-Rescue-Mode.md | 10 ++-- ...And-Dterm-Filtering-Recommendations-3-1.md | 2 +- ...-Spektrum-SPM4649T-and-other-satellites.md | 2 +- .../archive/Single-Wire-Software-Serial.md | 2 +- docs/wiki/guides/archive/Unified-Targets.md | 2 +- docs/wiki/guides/archive/failsafe-old.md | 4 +- docs/wiki/guides/current/3D-Setup.md | 4 +- .../current/BBE-MinMax-control-manual.md | 8 ++-- docs/wiki/guides/current/Barometer.md | 2 +- docs/wiki/guides/current/Buzzer-Mute-Mode.md | 2 +- docs/wiki/guides/current/Community-Presets.md | 4 +- docs/wiki/guides/current/DFU-Hijacking.md | 2 +- .../guides/current/DSHOT-RPM-Filtering.md | 4 +- docs/wiki/guides/current/Deep-Dive.md | 10 ++-- docs/wiki/guides/current/FAQ.md | 26 +++++------ docs/wiki/guides/current/Failsafe.md | 4 +- docs/wiki/guides/current/Feed-Forward-2-0.md | 2 +- .../current/Flight-Controller-Orientation.md | 2 +- .../current/Freestyle-Tuning-Principles.md | 2 +- .../current/GPS-Rescue-Mode-v4-1-to-v4-3.md | 8 ++-- docs/wiki/guides/current/GPS-Rescue-v4-4.md | 10 ++-- docs/wiki/guides/current/GPS-Rescue-v4-5.md | 8 ++-- .../wiki/guides/current/Hardware-Reference.md | 2 +- .../guides/current/I-Term-Relax-Explained.md | 2 +- docs/wiki/guides/current/IRC-Tramp.md | 2 +- .../guides/current/Installing-Betaflight.md | 2 +- docs/wiki/guides/current/Launch-Control.md | 2 +- docs/wiki/guides/current/Magnetometer.md | 8 ++-- .../guides/current/OSD-Font-Upload-Problem.md | 2 +- docs/wiki/guides/current/PID-Tuning-Guide.md | 46 +++++++++---------- .../wiki/guides/current/Pinio-and-PinioBox.md | 4 +- .../current/Servos-And-SERVO_TILT-for-3-1.md | 4 +- docs/wiki/guides/current/SmartAudio.md | 2 +- .../Soft-Mounting-and-Noise-Reduction.md | 8 ++-- docs/wiki/guides/current/SoftSerial.md | 4 +- docs/wiki/guides/current/Telemetry.md | 2 +- docs/wiki/guides/current/VTX-CLI-Settings.md | 2 +- docs/wiki/guides/current/VTX-Tables.md | 4 +- docs/wiki/tuning/4-2-Tuning-Notes.md | 8 ++-- docs/wiki/tuning/4-3-Tuning-Notes.md | 4 +- 53 files changed, 150 insertions(+), 150 deletions(-) diff --git a/docs/wiki/configurator/firmware-flasher-tab.md b/docs/wiki/configurator/firmware-flasher-tab.md index 906edc83f1..6259def65f 100644 --- a/docs/wiki/configurator/firmware-flasher-tab.md +++ b/docs/wiki/configurator/firmware-flasher-tab.md @@ -137,7 +137,7 @@ SPI configuration details are resolved via software (part of the configuration d ### Telemetry Protocol Select the telemetry protocol you need. -For CRSF, ELRS, FPORT or GHST protocols, this is included by default to simplify configuraton. +For CRSF, ELRS, FPORT or GHST protocols, this is included by default to simplify configuration. ### Other Options @@ -150,7 +150,7 @@ These are custom functions or features that you can add to the firmware. | Altitude Hold Mode | Enable Altitude Hold Mode support. See [#13816](https://github.com/betaflight/betaflight/pull/13816) | | Batt. Continue | See [#11084](https://github.com/betaflight/betaflight/pull/11084) | | Cam. Control | Enable Camera Control | -| Dashboard | Enable external i2c Oled Display device (to be deprecated) | +| Dashboard | Enable external i2c OLED Display device (to be deprecated) | | EMFAT (AutoRun, Icon) | Enable FAT emulation and icon for onboard flash or MSC | | ESC Serial (SK) Inc. 4way | Enable SimonK and ESC Serial support for flashing via 4way interface | | Flash Storage | 4.4 and earlier only. Enables Blackbox Flash Storage support. In 4.5, is auto-included via the FC config file. To manually add Flash to a 4.5 build, enter `FLASH` in `Custom Defines` | @@ -186,18 +186,18 @@ This field is only available in expert mode, and is intended for development and It defaults to the latest commit (master), meaning the most recent commit of the selected firmware branch. The dropdown includes some recent commits if you want to go back a bit. -Each GitHub pull request has a uniqe ID. The user can include a specific, yet to be merged, `Pull Request`, over the top of master, by typing the number of the pull request, preceded by the `#` character. For example, to include Pull Request #13605, just enter `#13605` in the Custom Defines field. +Each GitHub pull request has a unique ID. The user can include a specific, yet to be merged, `Pull Request`, over the top of master, by typing the number of the pull request, preceded by the `#` character. For example, to include Pull Request #13605, just enter `#13605` in the Custom Defines field. It is also possible to make a build from any previous point in time by entering the sha of the commit. -## Troubeshooting +## Troubleshooting :::tip - Use a good quality data cable, not a power cable. - USB hubs or OTG cables are sometimes needed with recent computers and in other cases they can cause issues. - Try disconnecting all cables from your PC first, try rebooting, other ports, upgrade system drivers. Remove other USB connections. -- Try DFU mode (use boot button on FC while plugging in, use Activate Boot Loader / DFU button in setup tab or use bl command in CLI. +- Try DFU mode (use boot button on FC while plugging in, use Activate Boot Loader / DFU button in setup tab or use bl command in CLI.) - Sometimes peripherals on the flight controller such as receivers or GPS devices can hijack port communication, preventing entering DFU mode. These may require de-soldering. - Linux needs configuration to allow flashing. - MacOS or Windows do not need any drivers. @@ -207,7 +207,7 @@ It is also possible to make a build from any previous point in time by entering :::info -If your board pheriperals are not recognized after flashing, please help us add the required configuration details. Some boards have inadequate file definitions, or the manufacturer has changed something on the board. +If your board peripherals are not recognized after flashing, please help us add the required configuration details. Some boards have inadequate file definitions, or the manufacturer has changed something on the board.
Reach out to us on our [Discord server](https://discord.betaflight.com/invite) or create an issue in the Betaflight unified targets repo. @@ -225,7 +225,7 @@ The `Show Log` link will open the build log and show the defines being applied t The log file incudes a full string for use when flashing the same build locally is provided, both for Docker and Make. -At any time after flashing, the log can be re-loaded using the `log` buttom at the lower right side of Configurator's S`Setup` page. A summary of the included build options can be displayed using the nearby `Options` button. +At any time after flashing, the log can be re-loaded using the `log` button at the lower right side of Configurator's S`Setup` page. A summary of the included build options can be displayed using the nearby `Options` button. ### Local Flashing diff --git a/docs/wiki/configurator/ports-tab.md b/docs/wiki/configurator/ports-tab.md index 33b2b531f9..9a7fe3e1f4 100644 --- a/docs/wiki/configurator/ports-tab.md +++ b/docs/wiki/configurator/ports-tab.md @@ -32,7 +32,7 @@ when conflicting options are set ## Serial RX Used to set the UART to receive serial data from a receiver. This is the most common use of a UART port. -If you toggle this on, you likely do not need to touch any ohter options for this port +If you toggle this on, you likely do not need to touch any other options for this port ## Telemetry Output @@ -47,7 +47,7 @@ Receiver ## Sensor Input When you want the port to receive data from a sensor. This is used for things like BLHeli_32 ESC telemetry, -or GPS. To get GPS working, you may need to manualy assign a baud rate as well +or GPS. To get GPS working, you may need to manually assign a baud rate as well ## Peripherals diff --git a/docs/wiki/configurator/power-tab.md b/docs/wiki/configurator/power-tab.md index f4122743d3..15278012e0 100644 --- a/docs/wiki/configurator/power-tab.md +++ b/docs/wiki/configurator/power-tab.md @@ -61,12 +61,12 @@ voltage is not displayed correctly, you can adjust this value up/down to fix it ### Divider / Multiplier Value This defines how the value read by the ICs ADC converts into a voltage value that makes sense to the pilot. -In easy terms this sets how the ratio difference between the two voltage divider resistors are used in the voltage calculation formular. +In easy terms this sets how the ratio difference between the two voltage divider resistors are used in the voltage calculation formula. Example: Scale: 110 = 10:1 voltage divider (10k:1k ohm resistors) Divider: 10 = sets the direct resistor to resistor ratio -Multiplier: 1 = this is to finetune the outcome of the calculation, a value of 1 is "no correction" +Multiplier: 1 = this is to fine-tune the outcome of the calculation, a value of 1 is "no correction" ## Amperage Meter diff --git a/docs/wiki/configurator/presets-tab.md b/docs/wiki/configurator/presets-tab.md index 8a394155f4..9e5509bb81 100644 --- a/docs/wiki/configurator/presets-tab.md +++ b/docs/wiki/configurator/presets-tab.md @@ -29,7 +29,7 @@ Narrow down your search by using the search filters. You can filter by: - **Status** - Select from various statuses to filter presets by - **OFFICIAL** - Presets that are made and/or officially supported by the Betaflight team. Usually more advanced and/or specific to a particular setting - - **COMMUNTIY** - Presets that are made by other users in the community. Often for specific products + - **COMMUNITY** - Presets that are made by other users in the community. Often for specific products (like VTX tables) and pilot rates - **EXPERIMENTAL** - Presets that are in development and in the process of being tested diff --git a/docs/wiki/configurator/setup-tab.md b/docs/wiki/configurator/setup-tab.md index c7fb31e072..288a798803 100644 --- a/docs/wiki/configurator/setup-tab.md +++ b/docs/wiki/configurator/setup-tab.md @@ -76,8 +76,8 @@ Shows some basic data from the flight controller. This includes: Shows the GPS data if the flight controller has a GPS module connected and set up. This includes: - **3D Fix** - Shows if the GPS has a 3D fix or not, a fix is needed for proper GPS functionality -- **Sats** - Shows the current ammoount of satellites the GPS has a lock on. The more the better, usually 6 or more is needed for a good fix -- **Lattitude/Longittude** - Shows the current lat/long coordinates of the drone +- **Sats** - Shows the current amount of satellites the GPS has a lock on. The more the better, usually 6 or more is needed for a good fix +- **Latitude/Longitude** - Shows the current lat/long coordinates of the drone ### Instruments diff --git a/docs/wiki/getting-started/hardware/esc-firmware.md b/docs/wiki/getting-started/hardware/esc-firmware.md index d870c1e6c6..8616b0a477 100644 --- a/docs/wiki/getting-started/hardware/esc-firmware.md +++ b/docs/wiki/getting-started/hardware/esc-firmware.md @@ -12,7 +12,7 @@ An ESC is the Electronic Speed Controller which supplies power to the craft's mo ## Bidirectional DShot Firmware -The Bidirectional DShot protocol can be enabled in the [Configurator Motors Tab](/docs/wiki/configurator/motors-tab#escmotor-features). Modern Bidirectional DShot is different (and more robust) in BetaFlight 4.5 than BetaFlight 4.0. The ESC firmware must be correct to ensure support for DShot Telemetry and provide the best Betaflight performance. We strongly recommend the use of DShot in conjunection with RPM filtering for the benefits in handling and smooth flight. +The Bidirectional DShot protocol can be enabled in the [Configurator Motors Tab](/docs/wiki/configurator/motors-tab#escmotor-features). Modern Bidirectional DShot is different (and more robust) in BetaFlight 4.5 than BetaFlight 4.0. The ESC firmware must be correct to ensure support for DShot Telemetry and provide the best Betaflight performance. We strongly recommend the use of DShot in conjunction with RPM filtering for the benefits in handling and smooth flight. ### Bidirectional DShot Versions @@ -43,7 +43,7 @@ Developers note - prior to 2.00 the AM32 project used a repo for each family of | Version | Recommended | Comment | | ------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2.00 | `N` | Cleanup of target structure, unify projects | -| 2.01 | `N` | Increase 10khztimer to 20khz, increase max duty cycle change. | +| 2.01 | `N` | Increase 10khz timer to 20khz, increase max duty cycle change. | | 2.02 | `N` | Increase startup power for inverted output targets. | | 2.03 | `N` | Move chime from DShot direction change commands to save command. | | 2.04 | `Y` | Fix current protection, max duty cycle not increasing. Fix double startup chime. Change current averaging method for more precision. Fix startup ramp speed adjustment. | @@ -76,11 +76,11 @@ BLHeli_32 is only available pre-installed on ESCs, the cost of BLHeli_32 license ### BlueJay -BlueJay fully supports RPM filtering and EDT telemetry and is the recommended ESC firmware for 8bit ESCs. Orginally developed by Mathias, a Betaflight developer, more recently BlueJay has been transferred to the BirdSanctuary team and is maintained by Damosvil and Stylesuxx in close partnership with the esc-configurator project. +BlueJay fully supports RPM filtering and EDT telemetry and is the recommended ESC firmware for 8bit ESCs. Originally developed by Mathias, a Betaflight developer, more recently BlueJay has been transferred to the BirdSanctuary team and is maintained by Damosvil and Stylesuxx in close partnership with the esc-configurator project. BlueJay is easily flashed with an elegant online flashing tool [ESC Configurator](https://esc-configurator.com/). An older offline configurator (https://github.com/mathiasvr/bluejay-configurator/releases) is available but not recommended for current releases. The firmware supports both L and H type ESCs as well as newer Z type, with a range of options, and has been tested on various ESC models. -[Extended DShot Telementry (EDT)](https://github.com/bird-sanctuary/extended-DShot-telemetry) was created by the BlueJay team and allows ESCs without a separate telemetry UART to send additional telemetry alongside RPM data. EDT enables BlueJay ESCs to report voltage, current and temperature as well as signalling error events. +[Extended DShot Telemetry (EDT)](https://github.com/bird-sanctuary/extended-DShot-telemetry) was created by the BlueJay team and allows ESCs without a separate telemetry UART to send additional telemetry alongside RPM data. EDT enables BlueJay ESCs to report voltage, current and temperature as well as signalling error events. | Version | Recommended | Comment | | ---------- | ----------- | ------------------------------------------------------------------------------------------------------ | @@ -109,7 +109,7 @@ JazzMaverick was poorly documented and has not been maintained for years. ::: The current build of JazzMaverick's BLHeli fork is 16.9, often referred to as [BlHeli-M](https://www.rcgroups.com/forums/showthread.php?3621257-BLHeli_M-Maverick-version). The easiest way to flash 16.9 is with Asizon's Configurator. -For earlier versions, go to [JazzMaverick](https://github.com/JazzMaverick/BLHeli/tree/JazzMaverick-patch-1/BLHeli_S%20SiLabs)'s code on github. Flash as usual with the conventional [BlHeli-S Configurator](https://github.com/blheli-configurator/blheli-configurator/releases) or use the convenient browser-based [ESC Configurator](https://esc-configurator.com/). Take a look wich version you have to flash correctly. Use either version 16.73 or 16.9. +For earlier versions, go to [JazzMaverick](https://github.com/JazzMaverick/BLHeli/tree/JazzMaverick-patch-1/BLHeli_S%20SiLabs)'s code on github. Flash as usual with the conventional [BlHeli-S Configurator](https://github.com/blheli-configurator/blheli-configurator/releases) or use the convenient browser-based [ESC Configurator](https://esc-configurator.com/). Take a look which version you have to flash correctly. Use either version 16.73 or 16.9. Betaflight strongly recommends that users avoid JazzMaverick due to the lack of maintenance and the author's experimental approach. This ESC firmware included versions with non-linear throttle response and other features that surprised or confused users. @@ -117,7 +117,7 @@ Betaflight strongly recommends that users avoid JazzMaverick due to the lack of [BLHeli-S](https://www.rcgroups.com/forums/showthread.php?2640796-BLHeli_S-Smooth-as-Silk) introduced support for the BusyBee line of 8bit MCUs for ESC use. These MCUs featured hardware PWM generation unlike the earlier [BLHeli](https://www.rcgroups.com/forums/showthread.php?2136895-BLHeli-for-Atmel-and-Silabs-united-by-BLHeliSuite) hardware, synchronising the motor PWM tyo the MCU clock and supporting higher eRPM speed output. Damped light mode was also standard, allowing all ESCs to decelerate as well as accelerate the motor. -Whilst these features may sound great these are now standard features and available in all other ESC firmware on this page. Note that DShot support was only added in revision 16.5 and turtle mode and DShot beeper only arrived in the last official 16.7 release. If you recieve an ESC with BLHeli-S we recommend connecting to [ESC Configurator](https://esc-configurator.com/) and flashing BlueJay, you can check a box to copy over the reversed/forward settings from BLHeli-S to BlueJay. +Whilst these features may sound great these are now standard features and available in all other ESC firmware on this page. Note that DShot support was only added in revision 16.5 and turtle mode and DShot beeper only arrived in the last official 16.7 release. If you receive an ESC with BLHeli-S we recommend connecting to [ESC Configurator](https://esc-configurator.com/) and flashing BlueJay, you can check a box to copy over the reversed/forward settings from BLHeli-S to BlueJay. :::info These versions are for informational purposes only. Always upgrade BLHeli-S equipment to use BlueJay. @@ -131,5 +131,5 @@ These versions are for informational purposes only. Always upgrade BLHeli-S equi | 16.3 | `N` | Implemented programmable temperature protection. Improved protection of bootloader and generally reduced risk of flash corruption. Some small changes for improved sync hold. | | 16.4 | `N` | Fixed bug where bootloader operation could be blocked by a defective "eeprom" signature. | | 16.5 | `N` | Added support for DShot150, DShot300 and DShot600. | -| 16.6 | `N` | Oixed signal detection issue of multishot at 32kHz. Improved bidirectional mode for high input signal rates. | +| 16.6 | `N` | Fixed signal detection issue of multishot at 32kHz. Improved bidirectional mode for high input signal rates. | | 16.7 | `N` | Addition of DShot commands for beeps and temporary reverse direction (largely by bycedjohnson) | diff --git a/docs/wiki/getting-started/hardware/index.md b/docs/wiki/getting-started/hardware/index.md index 00e83a6875..5e88580a80 100644 --- a/docs/wiki/getting-started/hardware/index.md +++ b/docs/wiki/getting-started/hardware/index.md @@ -38,7 +38,7 @@ In order of power, from least to most: ### Voltage Regulator -The voltage regulator is responsible for taking the input voltage and stepping it up/down to the voltage that the MCU and other components need. The MCU and oboard sensors usually run at 3.3V, and external peripherals like receivers, cameras, and some lower-power VTXs run at 5V. For running higher power VTXs, or basically most of the Digital options out there, you may see a 9/10/12V regulator (though 12V is recommended nowadays). +The voltage regulator is responsible for taking the input voltage and stepping it up/down to the voltage that the MCU and other components need. The MCU and onboard sensors usually run at 3.3V, and external peripherals like receivers, cameras, and some lower-power VTXs run at 5V. For running higher power VTXs, or basically most of the Digital options out there, you may see a 9/10/12V regulator (though 12V is recommended nowadays). :::caution @@ -48,7 +48,7 @@ If one or more of the regulators are overloaded, they may cause the rest of the ### OSD -To get OSD on analog video, the FC takes in the raw video signal directly from the camera, and feeds it through the MAX7456 chip (also the AT7456E - a drop-in replacement) which is used to overlay basic sprites defined in the font file ontop of the video. The modified analog video is then sent out to the VTX to be transmitted. +To get OSD on analog video, the FC takes in the raw video signal directly from the camera, and feeds it through the MAX7456 chip (also the AT7456E - a drop-in replacement) which is used to overlay basic sprites defined in the font file on top of the video. The modified analog video is then sent out to the VTX to be transmitted. :::note @@ -123,6 +123,6 @@ Used to get the position of the FC, and the speed it's moving at, utilizing the :::danger -Most GPS units on the market are based on the M8 chipset from uBlox. However, there are newer modules that use the M10 chipset. These work much better than M8... with a slight catch. As of the 4.4.1 release, The M10 is not supported for autoconfiguration in Betaflight yet, so you'll have to configure it manually in the u-center software. If not configured properly, it will lead to unreliable performance. +Most GPS units on the market are based on the M8 chipset from uBlox. However, there are newer modules that use the M10 chipset. These work much better than M8... with a slight catch. As of the 4.4.1 release, The M10 is not supported for auto-configuration in Betaflight yet, so you'll have to configure it manually in the u-center software. If not configured properly, it will lead to unreliable performance. ::: diff --git a/docs/wiki/getting-started/hardware/vtx.md b/docs/wiki/getting-started/hardware/vtx.md index 2b9e86ba0e..dcd23673c4 100644 --- a/docs/wiki/getting-started/hardware/vtx.md +++ b/docs/wiki/getting-started/hardware/vtx.md @@ -6,12 +6,12 @@ Video Transmitters are commonly referred to as VTX units. These are typically an Analogue video systems transmit a CVBS signal in either PAL or NTSC using channels in the 5.8GHz band. -- Orginally the FPV hardware in quadcopters was based on analogue security cameras and the associated transmission equipment. +- Originally the FPV hardware in quadcopters was based on analogue security cameras and the associated transmission equipment. - Early boards required manual channel selection using physical switches on the transmitter which was inconvenient for pilots - Pilots could easily power on and interrupt video for pilots already flying. - Cameras improved over time and VTX hardware has become more tightly integrated into the overall FPV experience. - - [SmartAudio from TBS](/docs/wiki/guides/current/SmartAudio) and [Tramp from ImmersionRC](/docs/wiki/guides/current/IRC-Tramp) - allow users to change their video channel, band and power output from the FC. Pilots must supply a list of valid channnels, bands and power levels to the FC called a [VTX Table](/docs/wiki/guides/current/VTX-Tables) - - [OpenVTX](https://github.com/OpenVTx/OpenVTx) introduced MSP VTX control. MSP VTXs can annouce available channel, band and power information so VTX Tables are not required. + - [SmartAudio from TBS](/docs/wiki/guides/current/SmartAudio) and [Tramp from ImmersionRC](/docs/wiki/guides/current/IRC-Tramp) - allow users to change their video channel, band and power output from the FC. Pilots must supply a list of valid channels, bands and power levels to the FC called a [VTX Table](/docs/wiki/guides/current/VTX-Tables) + - [OpenVTX](https://github.com/OpenVTx/OpenVTx) introduced MSP VTX control. MSP VTXs can announce available channel, band and power information so VTX Tables are not required. - [ExpressLRS backpack](https://github.com/ExpressLRS/Backpack/wiki) combines the ability to control any SmartAudio, Tramp or MSP VTX whilst simultaneously setting the same channel on the goggles. Originally the OSD for these systems was a separate add-in board such as Minim OSD, these have been replaced by OSD chips onboard the FC. This AT7456 is used on many FCs for this purpose and combines a black/white text-based OSD onto a video feed from the camera before sending the video signal to the VTX for transmission. diff --git a/docs/wiki/getting-started/setup-guide.md b/docs/wiki/getting-started/setup-guide.md index 799d084d66..68c2dca17d 100644 --- a/docs/wiki/getting-started/setup-guide.md +++ b/docs/wiki/getting-started/setup-guide.md @@ -228,7 +228,7 @@ Choosing the correct DShot speed: - The DShot speed also depends on the gyro (and thus also the PID loop) speed. If you have a gyro that runs at 8kHz (MPU6000), you can use DShot600. If you have a gyro that runs at 3.2KHz (BMI270), you should use DShot300. Using higher - DShot speeds on slower gyros shoudn't cause any issues, but it also won't give you any benefits + DShot speeds on slower gyros shouldn't cause any issues, but it also won't give you any benefits ::: @@ -290,9 +290,9 @@ Once you have the range set, then repeat the process for the other modes. You wi The OSD allows you to display information in the video feed from your quadcopter. In the [OSD Tab](/docs/wiki/configurator/osd-tab), you can set up the different elements that will be displayed. -You have a list of all the elements on the left, and three columns of checkboxes next to it. Each culumn is for one +You have a list of all the elements on the left, and three columns of checkboxes next to it. Each column is for one OSD profile. OSD profiles are a way to have different layouts for different situations and be able to easily switch -between them. Enabling the checbox for an element in the first column will enable it for the first OSD profile, the +between them. Enabling the checkbox for an element in the first column will enable it for the first OSD profile, the second column for the second OSD profile, and so on. When you enable an element, it will show up in the preview, and you can drag it around to move it as you like. There @@ -304,7 +304,7 @@ You should have at least the following elements enabled: - `Warnings` - Displays warnings for low battery, low RSSI, and other things - `Battery average cell voltage` - Displays the average cell voltage of the battery, regardless of the number of cells - `Link quality`, `RSNR Value`, `RSSI Value`, `RSSI dBm Value` - Different ways of measuring the strength and/or quality of the radio - link. Choose the one that works best for your radio systemm, can usually be found in the manufacturer documentation + link. Choose the one that works best for your radio system, can usually be found in the manufacturer documentation ## Ready to Fly! diff --git a/docs/wiki/getting-started/troubleshooting.md b/docs/wiki/getting-started/troubleshooting.md index 0566fee231..7ff52af2cc 100644 --- a/docs/wiki/getting-started/troubleshooting.md +++ b/docs/wiki/getting-started/troubleshooting.md @@ -10,7 +10,7 @@ It is an unfortunate fact that sometimes things just go wrong. Be that on by a f ### No COM Port Appears -- Make sure that you are plugging the USB cable into the flight controller. There may be parts thay may have a USB port, so don't confuse it with your flight controller A DJI Air Unit is a video transmitter. +- Make sure that you are plugging the USB cable into the flight controller. There may be parts that may have a USB port, so don't confuse it with your flight controller A DJI Air Unit is a video transmitter. Neither should you try to connect your radio to the configurator. Betaflight Configurator is not meant be used to set up your radio, use your radio's software for that (OpenTX companion, EdgeTX Buddy, etc.) - Make sure you are using a USB cable that is capable of data transfer. Some USB cables are only for charging - You may need to install the drivers for your flight controller. There is a download link for the ImpulseRC Driver @@ -40,7 +40,7 @@ If all of the sensor indicators in the configurator are grayed out, it means tha - If you have flashed the wrong firmware, the flight controller may not have the correct drivers for the sensors. Make sure you chose the correct target for your flight controller when flashing, and applied the custom defaults when prompted to -- With Betaflight 4.4 and the new cloud build system, make sure that you have the appropriate options selected when bulding the firmware +- With Betaflight 4.4 and the new cloud build system, make sure that you have the appropriate options selected when building the firmware ### Gyro Response Does Not Match Real Movement diff --git a/docs/wiki/guides/archive/Barometer-Configuration.md b/docs/wiki/guides/archive/Barometer-Configuration.md index 11b79abd79..1a7c89830a 100644 --- a/docs/wiki/guides/archive/Barometer-Configuration.md +++ b/docs/wiki/guides/archive/Barometer-Configuration.md @@ -13,7 +13,7 @@ This page explains CLI variables/command to configure barometers at runtime to b | Variable | Range | Description | | ------------------ | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `baro_bustype` | `NONE`, `I2C`, `SPI` | Specifies a type of bus a selected barometer device is connected. | -| `baro_i2c_device` | `0` ~ Max I2C bus ordinate for MCU type (1 origin, same as `x` in `I2Cx` expression in `target.h`) | Specifies a bus ordinate of the I2C bus the device is connected when `baro_bustype` is `I2C`. `0` meanns "none". | +| `baro_i2c_device` | `0` ~ Max I2C bus ordinate for MCU type (1 origin, same as `x` in `I2Cx` expression in `target.h`) | Specifies a bus ordinate of the I2C bus the device is connected when `baro_bustype` is `I2C`. `0` means "none". | | `baro_i2c_address` | `0` ~ `119` (0x77) | Specifies an I2C address of the device in 7-bit representation. `0` is a special value to specify "_driver default address_". Values `1`~`7` are invalid and behavior is unpredictable. | | `baro_spi_device` | `0` ~ Max SPI bus ordinate for MCU type (1 origin, same as `x` in `SPIx` expression in `target.h`) | Specifies a bus ordinate of the SPI bus the device is connected when `baro_bustype` is `SPI`. `0` means "none". | | `baro_hardware` | `NONE`, `AUTO`, `BMP280`, `MS5611`, `BMP085` | `NONE` = Barometer support disabled. `AUTO` = Firmware will determine device to use under pre-defined rule. `BMP280`, `MS5611` and `BMP085` = Explicitly specifies device to use. | diff --git a/docs/wiki/guides/archive/Betaflight-2-x-CLI-commands.md b/docs/wiki/guides/archive/Betaflight-2-x-CLI-commands.md index ff1d6f0045..5be01f8880 100644 --- a/docs/wiki/guides/archive/Betaflight-2-x-CLI-commands.md +++ b/docs/wiki/guides/archive/Betaflight-2-x-CLI-commands.md @@ -203,7 +203,7 @@ Also reduce the amount of AUX channels to reduce time for task RX. Notes copied from Forum: - ATTITUDE is as it says acc calculations. -- ACCEL is only sampling of accelerometer and filtering and ATTITUDE is real processing of it, which doesnt have to be fast. 100hz is more than enough! +- ACCEL is only sampling of accelerometer and filtering and ATTITUDE is real processing of it, which doesn't have to be fast. 100hz is more than enough! - When posting to the Forum please type "version", "status" and "tasks" and post all three of these CLI outputs as well as which PIDC is used. Version is important since it shows What ßF version and processor binary (.hex or .bin) file was loaded. diff --git a/docs/wiki/guides/archive/Failsafe-Before-4-3.md b/docs/wiki/guides/archive/Failsafe-Before-4-3.md index def4d866cb..d81f67879c 100644 --- a/docs/wiki/guides/archive/Failsafe-Before-4-3.md +++ b/docs/wiki/guides/archive/Failsafe-Before-4-3.md @@ -11,7 +11,7 @@ Flight controller based failsafe is where the flight controller attempts to dete It is possible to use both types at the same time, which 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. -Alternatively you may configure a transmitter switch to activate failsafe mode. This is useful for fieldtesting the failsafe system and as a **_`PANIC`_** switch when you lose orientation. +Alternatively you may configure a transmitter switch to activate failsafe mode. This is useful for field testing the failsafe system and as a **_`PANIC`_** switch when you lose orientation. ## Flight controller failsafe system diff --git a/docs/wiki/guides/archive/GPS-Rescue-Mode.md b/docs/wiki/guides/archive/GPS-Rescue-Mode.md index c11ad7fbca..7b7b191344 100644 --- a/docs/wiki/guides/archive/GPS-Rescue-Mode.md +++ b/docs/wiki/guides/archive/GPS-Rescue-Mode.md @@ -50,13 +50,13 @@ This is the distance, in meters, at which your quad will start descending toward `set gps_rescue_ascend_rate = [number] (default is 500)` (added in betaflight 4.1) -This is the vertical speed at which your quad will climb, espressed in centimeters for second +This is the vertical speed at which your quad will climb, expressed in centimeters for second `set gps_rescue_descend_rate = [number] (default is 150)` (added in betaflight 4.1) -This is the vertical speed at which your quad will descend, espressed in centimeters for second +This is the vertical speed at which your quad will descend, expressed in centimeters for second -`gps_rescue_throttle_min` and `gps_rescue_throttle_max` in betaflight 4.1 only limit the escursion of the the new pid controller(https://github.com/betaflight/betaflight/pull/8015) +`gps_rescue_throttle_min` and `gps_rescue_throttle_max` in betaflight 4.1 only limit the excursion of the the new pid controller(https://github.com/betaflight/betaflight/pull/8015) `gps_rescue_alt_mode = [MAX_ALT, FIXED_ALT, CURRENT_ALT]` (added in betaflight 4.1) @@ -66,7 +66,7 @@ now we can set the altitude of gps rescue **FIXED_ALT**, the quad will always try to return to the height set (`gps_rescue_initial_alt`) -**CURRENT_ALT**, the quad will return maintaining the readed altitude during the rescue activation (not suggested) +**CURRENT_ALT**, the quad will return maintaining the altitude read during the rescue activation (not suggested) ### At this point you are ready to test Rescue Mode. @@ -150,7 +150,7 @@ If GPS Rescue is mapped to a switch and/or set as a failsafe procedure, a minimu ### Common pitfalls for old versions -- For Betaflight versions prior to 4.0, it's highly encouraged to enable Air Mode, and optionally to finetune failsafe Stage1 settings, as a workaround for the crash detection issue immediately after activating Rescue Mode. Basically, ensure your settings will avoid the quad to be free-falling when entering into Stage2. +- For Betaflight versions prior to 4.0, it's highly encouraged to enable Air Mode, and optionally to fine tune failsafe Stage1 settings, as a workaround for the crash detection issue immediately after activating Rescue Mode. Basically, ensure your settings will avoid the quad to be free-falling when entering into Stage2. - When changing failsafe parameters with Betaflight Configurator 10.4 or lower, the failsafe procedure will be silently reset. Ensure that you set the failsafe procedure manually on CLI after saving modifications on the failsafe tab. - Every time the quad is armed, the home point is updated. Prior to BF 4.0, home point was updated on disarm but could be missed if switching rapidly. Best practice for launching in all versions is to arm, wait a few seconds until home point shows up in osd with 0 distance, and then start flying. Otherwise, disarm, wait a few seconds and repeat. Since Betaflight 4.0 you can use this cli command `set gps_set_home_point_once = ON` in this way only the first arm after the battery is connected will be used as home point. - If you're using Crossfire, make sure to configure the Failsafe parameter as "Cut" on your "CROSSFIRE RX" menu. diff --git a/docs/wiki/guides/archive/Gyro-And-Dterm-Filtering-Recommendations-3-1.md b/docs/wiki/guides/archive/Gyro-And-Dterm-Filtering-Recommendations-3-1.md index 5d30463654..9db8a0afda 100644 --- a/docs/wiki/guides/archive/Gyro-And-Dterm-Filtering-Recommendations-3-1.md +++ b/docs/wiki/guides/archive/Gyro-And-Dterm-Filtering-Recommendations-3-1.md @@ -249,7 +249,7 @@ Well, first get the noise level under control with basic filtering (no notch fil If the P trace has a prominent noise peak, apply a gyro notch filter to specifically block that out - but only if the amplitude is big enough that you can see it in the P trace itself. If the noise is less than 1% of signal, like if you can't really see it in P trace compared to signal, ignore the spectrum and don't use any notch. -If you need two gyro notch filters for speciific gyro peaks, use them. +If you need two gyro notch filters for specific gyro peaks, use them. After doing all this, then look at the Dterm trace. You must have some basic Dterm filtering. If the Dterm trace appears to have less than a few percent noise, you don't need to do anything, you could conceivably use less filtering an get better performance. If you have a broad band of noise on D, then you may need to lower the overall D lowpass or use a BiQuad on D. diff --git a/docs/wiki/guides/archive/RSSI-with-Spektrum-SPM4649T-and-other-satellites.md b/docs/wiki/guides/archive/RSSI-with-Spektrum-SPM4649T-and-other-satellites.md index 7d5f0975fe..20bae1ca8c 100644 --- a/docs/wiki/guides/archive/RSSI-with-Spektrum-SPM4649T-and-other-satellites.md +++ b/docs/wiki/guides/archive/RSSI-with-Spektrum-SPM4649T-and-other-satellites.md @@ -14,7 +14,7 @@ All you have to do is to Done. -The Betaflight and Spektrum RSSI % values are not the same. Currently not user adjustable in Betaflight. In your Tx you should however be able to select three different units. "%", "dBm" or "%R". None of those scales in the same way as BetaFlight. Spektrum "%" and "dBm" drops too fast close up and "%R" to fast at range end. The scaling in BetaFflight is a compromise between the two, the green line below. +The Betaflight and Spektrum RSSI % values are not the same. Currently not user adjustable in Betaflight. In your Tx you should however be able to select three different units. "%", "dBm" or "%R". None of those scales in the same way as BetaFlight. Spektrum "%" and "dBm" drops too fast close up and "%R" to fast at range end. The scaling in Betaflight is a compromise between the two, the green line below. ![RSSI vs Distancel menu](/img/ideal_rssi_to_range.jpg) diff --git a/docs/wiki/guides/archive/Single-Wire-Software-Serial.md b/docs/wiki/guides/archive/Single-Wire-Software-Serial.md index 6a7f874acc..681f37f3aa 100644 --- a/docs/wiki/guides/archive/Single-Wire-Software-Serial.md +++ b/docs/wiki/guides/archive/Single-Wire-Software-Serial.md @@ -34,7 +34,7 @@ OMNIBUS(F3) (by @jflyper) | --- | --------- | ------- | ----- | ------ | ----------------------------------------------- | | A8 | LED strip | NG | NG | NG | | | B4 | PPM (\*1) | OK | ? | OK | When PPM not in use | -| B6 | PWM8/SCL | OK | OK | OK | I2C must be de-configured? Need furthe testing. | +| B6 | PWM8/SCL | OK | OK | OK | I2C must be de-configured? Need further testing.| | B7 | PWM7/SDA | OK | ? | ? | Ditto | @olexs: B07 (PWM7/SDA) works with S.Audio on 3.2, no extra config needed (I2C resources aren't mapped per default). diff --git a/docs/wiki/guides/archive/Unified-Targets.md b/docs/wiki/guides/archive/Unified-Targets.md index 97a4c3f25e..defa4b95d2 100644 --- a/docs/wiki/guides/archive/Unified-Targets.md +++ b/docs/wiki/guides/archive/Unified-Targets.md @@ -38,7 +38,7 @@ Date: 2020-01-15T19:44:32Z **FAQ**: What is Manufacturer ID: `MTKS` -What do these four letters mean? They refer to the manufacturer of the board. The list is available in [Manufacterers.md](https://github.com/betaflight/unified-targets/blob/master/Manufacturers) +What do these four letters mean? They refer to the manufacturer of the board. The list is available in [Manufacturers.md](https://github.com/betaflight/unified-targets/blob/master/Manufacturers) Tip: remember to save a backup of your config, like as a `diff`, _before_ you flash a new version of betaflight. **Please note** it is only save to import certain settings back. If unsure please start with a fresh configuration. diff --git a/docs/wiki/guides/archive/failsafe-old.md b/docs/wiki/guides/archive/failsafe-old.md index 0d61c8e50b..8aa2327f9a 100644 --- a/docs/wiki/guides/archive/failsafe-old.md +++ b/docs/wiki/guides/archive/failsafe-old.md @@ -10,7 +10,7 @@ Do not rely on any information presented here. **Test failsafe without propellers.** Arm the Quadcopter and shut the radio off. -Full range receiver and Satellite behave diffently from brand to brand, read the operator's manual. +Full range receiver and Satellite behave differently from brand to brand, read the operator's manual. What is a failsafe? @@ -22,7 +22,7 @@ Why should I set my Failsafe? Failsafe places the flight controller in a "safer" state. Typically, a small quadcopter can fall without severe damage but with bigger quads, it might be better to land. The basic rule: it is better to drop from the sky unarmed than have a flyaway, randomly chasing people. -You might want to set the RCcommand on failsafe for each channel. I usually set throttle to hold leaving pitch, roll and yaw to "auto". Auxilliary 1 switch to "unarmed", for me it is "set 1000" and AUX 2 "set 2000" ( I have a mini-Quad with a beeper which makes it easier to locate). +You might want to set the RCcommand on failsafe for each channel. I usually set throttle to hold leaving pitch, roll and yaw to "auto". Auxiliary 1 switch to "unarmed", for me it is "set 1000" and AUX 2 "set 2000" ( I have a mini-Quad with a beeper which makes it easier to locate). -Enable Expert Mode ![Failsafe Tab](https://user-images.githubusercontent.com/25552059/44224354-2a14cb80-a158-11e8-884a-c9abeca80c3f.PNG) diff --git a/docs/wiki/guides/current/3D-Setup.md b/docs/wiki/guides/current/3D-Setup.md index 3aa513d2ff..077d385fd6 100644 --- a/docs/wiki/guides/current/3D-Setup.md +++ b/docs/wiki/guides/current/3D-Setup.md @@ -46,7 +46,7 @@ Consult your ESC manual for how to enable bi-directional mode on your ESC. - **BL Heli ESC:** -(norm/reverse/birectional slider in BLHeli GUI) and set max pwm in the ESC GUI to the maximum your transmitter outputs on the throttle channel (normally 2000us) and min pwm to the minimum (normally 1000us) and the midpoint to halfway between (normally 1500us). The ESC will not ouput to the motors if its input is at the midpoint +/- a small deadband. +(norm/reverse/birectional slider in BLHeli GUI) and set max pwm in the ESC GUI to the maximum your transmitter outputs on the throttle channel (normally 2000us) and min pwm to the minimum (normally 1000us) and the midpoint to halfway between (normally 1500us). The ESC will not output to the motors if its input is at the midpoint +/- a small deadband. - **Kiss 24A ESC:** @@ -114,7 +114,7 @@ Some flight testing with Kiss 24A ESCs using Build #861 on a CC3D Revo F4 has be 30-04-2017: Additional information for BLHeli*S is that there's currently an issue where the motors \_may* spin a different way using DShot to using oneshot/pwm and therefore motor direction MUST be checked when switching to DShot with 3D, you may need to set some motors to Bi-Directional and others to Bi-Directional reverse. -DShot has an inverted lower section when compared to standard 3D. This means that full negative thrust in DShot3D is 1499 and minumum negative thrust is 1000 (as opposed to standard/oneshot 3D where full negative thrust would be 1000 and minimum would be 1499). Positive thrust has it's minimum at 1501 and maximum at 2000 _Positive values are a guess, needs confirmation_ You will notice this in the configurator. +DShot has an inverted lower section when compared to standard 3D. This means that full negative thrust in DShot3D is 1499 and minimum negative thrust is 1000 (as opposed to standard/oneshot 3D where full negative thrust would be 1000 and minimum would be 1499). Positive thrust has it's minimum at 1501 and maximum at 2000 _Positive values are a guess, needs confirmation_ You will notice this in the configurator. Idle Percent is used for idle speed in BOTH directions. diff --git a/docs/wiki/guides/current/BBE-MinMax-control-manual.md b/docs/wiki/guides/current/BBE-MinMax-control-manual.md index 98ff687be9..64d22f7ff6 100644 --- a/docs/wiki/guides/current/BBE-MinMax-control-manual.md +++ b/docs/wiki/guides/current/BBE-MinMax-control-manual.md @@ -5,7 +5,7 @@ The current MinMax curves settings are showed at 'Configure graphs' dialog box i ![image](./images/1.jpg) The MinMax values can be changed: -- By direct input into table cells at 'Configure graphs' dialog box. It is possible to changes values manualy or set default values by double mouse click at values field. +- By direct input into table cells at 'Configure graphs' dialog box. It is possible to changes values manually or set default values by double mouse click at values field. - By using context menu To show context menu you must do right mouse click on Minimum or Maximum values field what you want to edit. @@ -35,7 +35,7 @@ The single curve submenu has same actions: ![image](./images/3.jpg) -## Contect menu +## Context menu If you open context menu for one curves chart, then you see the short menu: @@ -60,7 +60,7 @@ Click 'Apply change' or 'Cancel' button on the main 'Configure graphs' dialog bo You can select curves what you need by using the checkboxes to apply values. Click 'At all global log time' menu item to set MinMax values from log data during all time. Click 'At local window time' menu item to set MinMax values from current time interval at the chart window. -Click 'At markere time range' menu item to set MinMax values from markered time interval what you select by using "I", "O" keys. If it is not select then will apply all log time interval. +Click 'At marker time range' menu item to set MinMax values from markered time interval what you select by using "I", "O" keys. If it is not select then will apply all log time interval. Click 'Back' menu item to go back to main menu or click 'Close' menu item to close it. Click 'Apply change' or 'Cancel' button on the main 'Configure graphs' dialog box to close the menu and dialog box immediately ![image](./images/7.jpg) @@ -83,7 +83,7 @@ Click 'Apply change' or 'Cancel' button on the main 'Configure graphs' dialog bo ### The 'Zoom in', 'Zoom out' extended submenu. -You can set the zoom procent value and select curves what you need by using the checkboxes to apply zoom. +You can set the zoom percent value and select curves what you need by using the checkboxes to apply zoom. Click 'ZOOM IN', 'ZOOM OUT' items for apply zoom Click 'Back' menu item to go back to main menu or click 'Close' menu item to close it. Click 'Apply change' or 'Cancel' button on the main 'Configure graphs' dialog box to close the menu and dialog box immediately diff --git a/docs/wiki/guides/current/Barometer.md b/docs/wiki/guides/current/Barometer.md index 1bd8e62b93..882dc4dabe 100644 --- a/docs/wiki/guides/current/Barometer.md +++ b/docs/wiki/guides/current/Barometer.md @@ -154,7 +154,7 @@ If, with the default `baro_i2c_address = 0` setting, or automatic barometer dete | Variable | Range | Description | | ------------------ | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `baro_bustype` | `NONE`, `I2C`, `SPI` | Specifies a type of bus a selected barometer device is connected. | -| `baro_i2c_device` | `0` ~ Max I2C bus ordinate for MCU type (1 origin, same as `x` in `I2Cx` expression in `target.h`) | Specifies a bus ordinate of the I2C bus the device is connected when `baro_bustype` is `I2C`. `0` meanns "none". | +| `baro_i2c_device` | `0` ~ Max I2C bus ordinate for MCU type (1 origin, same as `x` in `I2Cx` expression in `target.h`) | Specifies a bus ordinate of the I2C bus the device is connected when `baro_bustype` is `I2C`. `0` means "none". | | `baro_i2c_address` | `0` ~ `119` (0x77) | Specifies an I2C address of the device in 7-bit representation. `0` is a special value to specify "_driver default address_". Values `1`~`7` are invalid and behavior is unpredictable. | | `baro_spi_device` | `0` ~ Max SPI bus ordinate for MCU type (1 origin, same as `x` in `SPIx` expression in `target.h`) | Specifies a bus ordinate of the SPI bus the device is connected when `baro_bustype` is `SPI`. `0` means "none". | | `baro_hardware` | `NONE`, `AUTO`, `BMP280`, `MS5611`, `BMP085` | `NONE` = Barometer support disabled. `AUTO` = Firmware will determine device to use under pre-defined rule. `BMP280`, `MS5611` and `BMP085` = Explicitly specifies device to use. | diff --git a/docs/wiki/guides/current/Buzzer-Mute-Mode.md b/docs/wiki/guides/current/Buzzer-Mute-Mode.md index 251cd943ae..ebd25102de 100644 --- a/docs/wiki/guides/current/Buzzer-Mute-Mode.md +++ b/docs/wiki/guides/current/Buzzer-Mute-Mode.md @@ -8,5 +8,5 @@ Eg.: ``` AUX5 < 1500 -> 'Beeper mute' is active, 'Beeper' is inactive. - AUX5 > 1500 -> 'Beepr mute' is inactive, 'Beeper' is active. + AUX5 > 1500 -> 'Beeper mute' is inactive, 'Beeper' is active. ``` diff --git a/docs/wiki/guides/current/Community-Presets.md b/docs/wiki/guides/current/Community-Presets.md index 33fc0ca6f4..db0f2177b0 100644 --- a/docs/wiki/guides/current/Community-Presets.md +++ b/docs/wiki/guides/current/Community-Presets.md @@ -1,6 +1,6 @@ # Community Presets -### The below presets are _**by the community, for the community**_. You will see the BF version the preset is targeted toward and the pilot's name who published their recommended preset(s). We encourage communitymembers to provide their own presets on this page. To do so, you simply need a Github account. Enjoy! +### The below presets are _**by the community, for the community**_. You will see the BF version the preset is targeted toward and the pilot's name who published their recommended preset(s). We encourage community members to provide their own presets on this page. To do so, you simply need a Github account. Enjoy! ### IMPORTANT: These settings are NOT provided or endorsed by the Betaflight project. They are examples that others have found helpful for their particular quad. THEY MAY NOT BE SUITABLE FOR YOUR QUAD! A better use might be to examine similar configurations to yours and get ideas on possible tuning directions rather than blindly copy/pasting someone else's settings. Always test carefully and safely. @@ -385,7 +385,7 @@ CLI Copy/Paste ```python -# For racing 5" craft, preferred ESC settingss are 48kHz PWM, 23° Timing, 0.25 Rampup Power, DemagComp=Low +# For racing 5" craft, preferred ESC settings are 48kHz PWM, 23° Timing, 0.25 Rampup Power, DemagComp=Low # Settings for All Quadcopters - Motors Reversed set debug_mode = GYRO_SCALED diff --git a/docs/wiki/guides/current/DFU-Hijacking.md b/docs/wiki/guides/current/DFU-Hijacking.md index 0930f10d4e..05f06d28ed 100644 --- a/docs/wiki/guides/current/DFU-Hijacking.md +++ b/docs/wiki/guides/current/DFU-Hijacking.md @@ -16,7 +16,7 @@ STM32 family of MCUs, when in boot loader mode, look for input from several diff ## Possible Workarounds -Work arounds against DFU hijacking by chatty devices are as follow. +Workarounds against DFU hijacking by chatty devices are as follow. 1. Shut the chatty device up by powering them down or physically disconnecting while flashing. Using a power supply pad not powered when only USB is connected is an alternative way of doing this. diff --git a/docs/wiki/guides/current/DSHOT-RPM-Filtering.md b/docs/wiki/guides/current/DSHOT-RPM-Filtering.md index 6ea3d829bc..7d4f53c44c 100644 --- a/docs/wiki/guides/current/DSHOT-RPM-Filtering.md +++ b/docs/wiki/guides/current/DSHOT-RPM-Filtering.md @@ -2,7 +2,7 @@ ### Recent Announcements -- [Bluejay](https://github.com/mathiasvr/bluejay) is a new, free, well-supported BlHeli-S firmware that supports DShot telemetry, with a range of options. It is most easily flashed using the [https://esc-configurator.com](https://esc-configurator.com) online ESC configurato, which can flash both BlHeli-S and Bluejay to BLHeli-S ESCs, and AM32 to BlHeli-32 ESCs. +- [Bluejay](https://github.com/mathiasvr/bluejay) is a new, free, well-supported BlHeli-S firmware that supports DShot telemetry, with a range of options. It is most easily flashed using the [https://esc-configurator.com](https://esc-configurator.com) online ESC configurator, which can flash both BlHeli-S and Bluejay to BLHeli-S ESCs, and AM32 to BlHeli-32 ESCs. - [JESC](https://jflight.net) was the first ESC firmware to support RPM filtering on BLHeli_S escs. It was written by the JoeLucid, who wrote the DShot telemetry code that underpins all bidirectional DShot functionality, such as Dynamic Idle and RPM Filtering. JESC is free on L ESCs, but payment is required for H ESCs. 48khz and 96khz PWM versions are available. - [BlHeli-32](https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM) fully supports Bidirectional DShot in versions 32.7.0 and higher - [AM32](https://github.com/AlkaMotors/AM32-MultiRotor-ESC-firmware) can also be flashed (but not readily un-flashed) to BlHeli-32 type ESCs, and also fully supports Bidirectional DShot. @@ -62,7 +62,7 @@ With 4.1 and above it's no longer necessary to install a snippet. Instead just u ### Config Verification -Your FC is now set up for bidirectional DShot - let's verify that it works. To do so power cycle FC and ESC. Connect the lipo first to the ESC, then the USB cable. Now open the Motors tab in Betaflight Configurator. There should be no red line indicating significant errors on any motor. When you spin the motors you should see the reported rpm. The reported error percentage should not exceed 1%. All motors should report an RPM of 0 unless spun. +Your FC is now set up for bidirectional DShot - let's verify that it works. To do so power cycle FC and ESC. Connect the LIPO first to the ESC, then the USB cable. Now open the Motors tab in Betaflight Configurator. There should be no red line indicating significant errors on any motor. When you spin the motors you should see the reported rpm. The reported error percentage should not exceed 1%. All motors should report an RPM of 0 unless spun. **Important:** If you connect your FC via USB cable without connecting your LIPO battery, then at the Motors tab in Betaflight Configurator you will notice an invalid indication "Error 100%" (E: 100%). Connect the LIPO and wait ESC to initialize, the indication will drop down to 0% (E: 0%). Disconnecting the battery will keep showing 0% errors afterwards. diff --git a/docs/wiki/guides/current/Deep-Dive.md b/docs/wiki/guides/current/Deep-Dive.md index 1b0d699cff..9ac72d9160 100644 --- a/docs/wiki/guides/current/Deep-Dive.md +++ b/docs/wiki/guides/current/Deep-Dive.md @@ -131,7 +131,7 @@ http://www.rcgroups.com/forums/showpost.php?p=34028986&postcount=18516 ## Motor update -I am also coming from the world of VOIP what is completaly different than control laws, but there jitter is even much more of an issue in realtime audio/video processing. There are several ways to deal with it. Another option would be dropping motor output signals when they come to soon....before the old signal finished. That would be the only other option. +I am also coming from the world of VOIP what is completely different than control laws, but there jitter is even much more of an issue in realtime audio/video processing. There are several ways to deal with it. Another option would be dropping motor output signals when they come to soon....before the old signal finished. That would be the only other option. Another example: The new way runs cycletime of 125us and PID loop of 375us The motor update happens at begin of the new cycletime and not the begin of new PID looptime! @@ -142,14 +142,14 @@ Having faster motor rate than loop rate is complete nonsense as the value will s Thats why i am reworking the tasking at the moment. The ideal motor handling would be to only write motors when there are new mixer calculations available and with the time interval between the motor updates never lower than the desired period. Longer motor updates are even not bad just as long as next motor update doesnt fall into previous one. -Lets say the pid controller / mixer requests full motor power on oneshot125 which is about 250us PWM interval.....if we were updating motors at 2k interval than there is in total 250us free interval where it doesnt matter when you update it. so allowed jitter period is a bit less than 250us. +Lets say the pid controller / mixer requests full motor power on oneshot125 which is about 250us PWM interval.....if we were updating motors at 2k interval than there is in total 250us free interval where it doesn't matter when you update it. so allowed jitter period is a bit less than 250us. On 4k speed the motor update period is totally not allowed to jitter to make full throttle possible. -It doesnt matter if the motor gets updated too late but should never be updated too soon. +It doesn't matter if the motor gets updated too late but should never be updated too soon. -With low looptimes like now we are reaching the point where motor updates happen near the end of cycletime. So there is no such thing as delay there. It doesnt matter if you do something at the end or beginning. -Imagine like running circles you can't tell what is begin or end. The order doesnt matter anymore. +With low looptimes like now we are reaching the point where motor updates happen near the end of cycletime. So there is no such thing as delay there. It doesn't matter if you do something at the end or beginning. +Imagine like running circles you can't tell what is begin or end. The order doesn't matter anymore. It's near the end of the cycletime where there is the most jitter. The time variations there are between 0 and 100us. Especially on low looptimes with scheduled tasking mechanism to get the maximum efficiency the end of loop cycle is really jittery. So when moving the motor update to the beginning of the loop you always have the constant timing. The variable delay you would have when writing the motors at the end of the loop now becomes a constant delay. diff --git a/docs/wiki/guides/current/FAQ.md b/docs/wiki/guides/current/FAQ.md index e3ec552c92..cb9815aac2 100644 --- a/docs/wiki/guides/current/FAQ.md +++ b/docs/wiki/guides/current/FAQ.md @@ -98,7 +98,7 @@ Read the [Installing BetaFlight ](Installing-Betaflight) support page. ## What's the history of Betaflight and it's relationship to Cleanflight ? -A little history. This all started with OpenSource MultiWii code based on Arduino 8-bit boards. When the 32-bit STM32 processors become available the MutliWii code was ported to the STM32 and was called BaseFlight. Due to politics others forked the BaseFlight code to CleanFlight. More recently Boris decided that he could possibly make improvements on the way the PID control loop works and forked an Experimental version as BetaFlight. +A little history. This all started with OpenSource MultiWii code based on Arduino 8-bit boards. When the 32-bit STM32 processors become available the MultiWii code was ported to the STM32 and was called BaseFlight. Due to politics others forked the BaseFlight code to CleanFlight. More recently Boris decided that he could possibly make improvements on the way the PID control loop works and forked an Experimental version as BetaFlight. Therefore documentation on ßF and CF tends to only show what is new or changed and the documentation of previous Firmware must be read. ## What is the difference between Min_Check Min_command and Min_throttle and stick inputs ? @@ -128,7 +128,7 @@ Code from MW2.3 config.h file DEADBAND is only removing stick center value (all channels except throttle) to eliminate stick center jitter and non-returning to exactly 1500. no more, no less. Do not use this term for anything else. -Reading the MutliWii WIKI and even the MultiWii code config.h file will help to understand what these values are. A link is in the ßF Wiki, FAQ: getting started. +Reading the MultiWii WIKI and even the MultiWii code config.h file will help to understand what these values are. A link is in the ßF Wiki, FAQ: getting started. In CF and ßF the expected stick end point values are set with (I don't know in what versions these came about but were not in the original port of MW to BF code): Code: @@ -145,8 +145,8 @@ The FC firmware uses the mid_rc and these to calculate a stick value to hand off If a channel does not get to these end points then the FC will simply not see full movement, either on one side or both. This is one reason I and others and the MW Wiki and CF docs state to adjust the radios stick end points to these defaults. The other is ensuring the stick exceed the min_check, max_check thresholds so stick commands work. -Another explanation be joshua bardwell: -Max and min channel values are determined by the rxrange command. They default to 1000 and 2000. Max_check and min_check are used to decide if you are entering a stick command. Here is the kicker--how do you disarm the copter if yaw is active? You would have to go full deflection and the copter would yaw like crazy. In order to address this, when the throttle is below min_check, and when stick arming is used (vs. switch arming), the yaw input is disabled. If you are using motor_stop, the motors also stop running when the throttle is below min_check. Sometimes, this behavior is referred to as a deadzone at the bottom of the throttle stick travel. Many people refer to this as Deadband but causes much confusion with stick center DEADBAND CLI settings, therefore DEADZONE is prefered +Another explanation from Joshua Bardwell: +Max and min channel values are determined by the rxrange command. They default to 1000 and 2000. Max_check and min_check are used to decide if you are entering a stick command. Here is the kicker--how do you disarm the copter if yaw is active? You would have to go full deflection and the copter would yaw like crazy. In order to address this, when the throttle is below min_check, and when stick arming is used (vs. switch arming), the yaw input is disabled. If you are using motor_stop, the motors also stop running when the throttle is below min_check. Sometimes, this behavior is referred to as a deadzone at the bottom of the throttle stick travel. Many people refer to this as Deadband but causes much confusion with stick center DEADBAND CLI settings, therefore DEADZONE is preferred You can see that there is no need for a corresponding disabling of inputs at the top of the throttle range, because you never input any stick commands that require the top of the range when you are flying. The only stick command that is input when you are flying is disarm, and that is low yaw and low throttle. So there is a dead space at the bottom of the throttle range (below min_check) but no dead space at the top of any channel range. @@ -239,7 +239,7 @@ Some users were mailing Boris about the fact their radios couldn't be configured After some readings in other open source projects and some of the older discussions, he realized that the key for this was in the mixer logic as someone already had a proof of concept code to improve it, which is pretty much scaling the PID's to our throttle level and stopping the stabilization when one motor reaches min throttle. Now Boris understood why folks always preferred this Idle up switch as it was automatically gaining a little bit more stabilization. But this is just a workaround where you loose some throttle below! The current mixer logic sounds reasonable as the early developers were always considering the low throttle values as a NON flying situation. Guess what? In 2015 we fly a lot with 0 or low throttle and especially in the mini quad scene! This has to be changed! The real answer lies in smarter mixer approach where the calculated PID output would always consider the maximum available motor output range to be able to get the desired correction. -With AIR mode the copter will always think it's in the "AIR" and will always try to correct as fast as possible and never become weak. We of course need this stabilization once in AIR! This has it's consequences for our ground situations which you have to be aware of. With Air mode it would mean that the motors could be spooling up after arming, but there is some protection built for that. When you arm and keep throttle stick low (below min check) it will know it is on the ground and the motors will not spool up. Once you move your throttle to higher position for more than 1 second and pitch and roll are not centered anymore it will fully activate the stabilization with 0 throttle! So you have to be aware that if you would land very quickly after first take off that the motors now are able to spool up as the copter thinks its flying and has max ability to correct. Dont worry you can disarm now or you can keep throttle low with roll + pitch stick centered and it will still spool down or at least it will not spool up anymore. +With AIR mode the copter will always think it's in the "AIR" and will always try to correct as fast as possible and never become weak. We of course need this stabilization once in AIR! This has it's consequences for our ground situations which you have to be aware of. With Air mode it would mean that the motors could be spooling up after arming, but there is some protection built for that. When you arm and keep throttle stick low (below min check) it will know it is on the ground and the motors will not spool up. Once you move your throttle to higher position for more than 1 second and pitch and roll are not centered anymore it will fully activate the stabilization with 0 throttle! So you have to be aware that if you would land very quickly after first take off that the motors now are able to spool up as the copter thinks its flying and has max ability to correct. Don't worry you can disarm now or you can keep throttle low with roll + pitch stick centered and it will still spool down or at least it will not spool up anymore. ### A quicky explanation from ctzsnooze: @@ -419,7 +419,7 @@ Here is a list of FCs compiled around the end of January 2016. The opinions rega | **[LUX](http://www.rcgroups.com/forums/showthread.php?t=2554204)** | F3 MPU6500-SPI | Y | VCP USB, UARTs 1,2,3 | Looks good. Doesn't have a dataflash chip. Uses the STM's Virtual Com Port which requires special procedures. Uses MPU6500 which is not ideal. | | **[KISS](http://www.rcgroups.com/forums/showthread.php?t=2555204)** | F3 MPU6050-I2C | Y | VCP USB | Doesn't run Betaflight (yet) LOL. | | **[SPRacingF3Mini board](http://www.rcgroups.com/forums/showthread.php?t=2592215)** | F3 | Y | VCP USB | Now supported in 2.4.0-RC6. With SD Card Socket, Race Transponder and 5V BEC. Looks good for Racing copters. | -| **[MotoLab Tempest](http://www.rcgroups.com/forums/showthread.php?t=2715556)** | F3 MPU600-SPI | Y | VCP USB, UARTs 1,2,3 | Built in 5V switching regulator. Bi-directional ESC pins for HLBeli pass-through. Plus a PDB | +| **[MotoLab Tempest](http://www.rcgroups.com/forums/showthread.php?t=2715556)** | F3 MPU600-SPI | Y | VCP USB, UARTs 1,2,3 | Built in 5V switching regulator. Bi-directional ESC pins for BLHeli pass-through. Plus a PDB | ### Additional Information: @@ -469,12 +469,12 @@ Code: PTerm = (RateError * P * TPA) / 128; ``` -The difference above is that P gain number on rewrite is higher, but is being divided by 128 in the PTerm calculation, while luxfloat uses directly the number you entered from cli. Note that RateError number is using degrees/sec in luxfloat and in rewrite its abstraction from the original gyro output, but both can produce same PTerm when right P is selected. +The difference above is that P gain number on rewrite is higher, but is being divided by 128 in the PTerm calculation, while Luxfloat uses directly the number you entered from cli. Note that RateError number is using degrees/sec in Luxfloat and in rewrite its abstraction from the original gyro output, but both can produce same PTerm when right P is selected. So if you can find P component what can produce the same PTerm result you will get same behaviour. Practical translation: -1.0 in luxfloat means exactly 4.0 in rewrite just for Pterm. +1.0 in Luxfloat means exactly 4.0 in rewrite just for Pterm. This same translation formula can be done on all numbers like rates, Dterm and Iterm. @@ -484,21 +484,21 @@ The 'P' and 'D' Terms in Luxfloat are now shown as 4 times higher to allow bette Additional comment from Boris on MW-rewrite verse Luxfloat: There should not be any difference between both in terms of PID's and rates. Well there is one slight difference actually, which I forgot to mention and even I forgot about it. -rewrite still has a bit higher D range. To be exact rewrite has 2x higher delta for Dterm due to averaging summing instead of average dividing the sum. I would rather like to remove this, but dont want to cause people having to retune their rewrite. But even though with this Dterm rewrite should in theory handle bounces better....right? But that isnt the case. +rewrite still has a bit higher D range. To be exact rewrite has 2x higher delta for Dterm due to averaging summing instead of average dividing the sum. I would rather like to remove this, but don't want to cause people having to retune their rewrite. But even though with this Dterm rewrite should in theory handle bounces better....right? But that isn't the case. -I know why. Rewrite has a Dterm deadband integrated in the integer logic, which helps keeping some noise away. But the lower numbers can cause some aliasing in dterm and some lower frequencies which aren't there may be thrown into pid controller. -There will be some more data about this soon to confirm, but luxfloat may now become a winner certainly now where it became better tunable. +I know why. Rewrite has a Dterm deadband integrated in the integer logic, which helps keeping some noise away. But the lower numbers can cause some aliasing in Dterm and some lower frequencies which aren't there may be thrown into pid controller. +There will be some more data about this soon to confirm, but Luxfloat may now become a winner certainly now where it became better tunable. New in ßF 2.8 and above: the PIDC names LUXFLOAT & MWREWRITE are no longer used since Boris has rewritten the code and they not longer use the same algorithm as before. The new names are FLOAT & INTEGER. ## What PIDs do and how do they do it ? -Here a good basic PID explaination by Bruce for those who want to learn about it. +Here a good basic PID explanation by Bruce for those who want to learn about it. https://www.youtube.com/watch?v=0vqWyramGy8 ## Is there a good resource for learning how to tune using Black Box ? -a. "I would check out Joshua Bardwells youtube channel. I haven't watched all these videos... I just picked them from his channel. +a. "I would check out Joshua Bardwell's youtube channel. I haven't watched all these videos... I just picked them from his channel. Quote: http://www.youtube.com/watch?v=FH_m5rI6MKY diff --git a/docs/wiki/guides/current/Failsafe.md b/docs/wiki/guides/current/Failsafe.md index e18068d648..76403a88a2 100644 --- a/docs/wiki/guides/current/Failsafe.md +++ b/docs/wiki/guides/current/Failsafe.md @@ -112,7 +112,7 @@ Stage 2 Failsafe is entered when signal loss persists longer then the configured - the selected `Stage 2 Failsafe_procedure` applies. - `!FS!` will be shown in the Flight Mode field of the OSD. -- `RUNAWAY_TAKEOFF` protection is enabled in failsage before 4.3, but later versions disable it, to avoid unwanted mid-air disarms that could occur in GPS Rescue. +- `RUNAWAY_TAKEOFF` protection is enabled in failsafe before 4.3, but later versions disable it, to avoid unwanted mid-air disarms that could occur in GPS Rescue. Entering Stage 2 is not possible until 5 seconds after the flight controller boots up. This is to prevent unwanted activation, as in the case of TX/RX gear with long bind procedures, before the Rx sends out valid data. @@ -260,7 +260,7 @@ See [Rx documentation](/docs/development/Rx). Time for a recovered signal to be considered valid while in Stage 2 Failsafe. The signal must be 'good' for at least this time before control is returned to the pilot; the pilot cannot re-arm during this period. In GPS Return mode, this is the time required before the pilot's stick inputs will be assessed for the restoration of control. In Betaflight 4.5, this period is 0.5s by default, unless the `RACE_PRO` option was built into the firmware, when it is 0.1s by default. In Betaflight 4.4, this period is 1.0s. `RXLOSS` will still be shown in the OSD during the `failsafe_recovery_delay` period, since technically the signal is not yet considered OK. -Note that during the `failsafe_recovery_delay` period, the quad cannot be re-armed. To be re-armed, the quad must first be disarmed. If the arm stick is in the armed position when the `failsafe_recovery_delay` expires, the warning `NOT_DISARMED` will be shown. It means that you need to toggle the arm switch back to the disarm psoition, and then you can re-arm. +Note that during the `failsafe_recovery_delay` period, the quad cannot be re-armed. To be re-armed, the quad must first be disarmed. If the arm stick is in the armed position when the `failsafe_recovery_delay` expires, the warning `NOT_DISARMED` will be shown. It means that you need to toggle the arm switch back to the disarm position, and then you can re-arm. #### `failsafe_stick_threshold` diff --git a/docs/wiki/guides/current/Feed-Forward-2-0.md b/docs/wiki/guides/current/Feed-Forward-2-0.md index 101037ec75..a09dfd4b28 100644 --- a/docs/wiki/guides/current/Feed-Forward-2-0.md +++ b/docs/wiki/guides/current/Feed-Forward-2-0.md @@ -50,7 +50,7 @@ This is a 'digital' way of calculating FF from each new RC 'step'. It gives a cl `set ff_interpolate_sp = ON` analyses each new incoming RC data packet, and the calculated change in setpoint is converted to an immediate step up in FF. Each step up is held constant until the next RC data step arrives. -The sharp corner of the FF step can be smoothed according to the rc_smoothing_derivative lowpass filter frequency. This is set dynamically by default in AUTO mode, but can be manually overriden if desired. 120hz is a good smoothing value for a clean feed-forward trace. 20hz smoothes out traces with a fair bit of up and down; 10hz may be needed for very long range and cinematic quads where the large steps from 50hz mode and poor quality links can make the quad jerky in turns. +The sharp corner of the FF step can be smoothed according to the rc_smoothing_derivative lowpass filter frequency. This is set dynamically by default in AUTO mode, but can be manually overridden if desired. 120hz is a good smoothing value for a clean feed-forward trace. 20hz smooths out traces with a fair bit of up and down; 10hz may be needed for very long range and cinematic quads where the large steps from 50hz mode and poor quality links can make the quad jerky in turns. Dropped RC packets will normally cause sudden FF drops to zero. `set ff_interpolate_sp = AVERAGE` is intended to help manage this specific issue. Alternatively, a low rc_smoothing_derivative filtering value can smooth the drops out a bit, at the cost of incoming RC delay. diff --git a/docs/wiki/guides/current/Flight-Controller-Orientation.md b/docs/wiki/guides/current/Flight-Controller-Orientation.md index 0dfbc765a9..9bf56b8cb7 100644 --- a/docs/wiki/guides/current/Flight-Controller-Orientation.md +++ b/docs/wiki/guides/current/Flight-Controller-Orientation.md @@ -10,7 +10,7 @@ It is important to note that there is a sequence of so-called Euler angles (axes The internal rotation convention bf uses to represent the FC orientation is R = Rz(-Yaw) _ Ry(-Pitch) _ Rx(-Roll). On one hand the rotation matrix R describes how the FC with respect to the origin of the quad is rotated. On the other hand R describes the transformation of sensor readings of the FC as they were measured with a flight controller aligned with the quads frame (arrow pointing forward / x axis). -For the alignment process its easier to think in the inverse transform R^T = Rx^T(-Roll) _ Ry^T(-Pitch) _ Rz^T(-Yaw). So we yaw first around the z axis, then pitch the yawed frame around its new y axis and finally roll the yawed and pitched frame around its new x axis. Due to the minus sign positiv angle direction is described by the left hand rule, e.g. to yaw positive you grab the z axis with your left hand and rotate towards the direction of your fingers. +For the alignment process its easier to think in the inverse transform R^T = Rx^T(-Roll) _ Ry^T(-Pitch) _ Rz^T(-Yaw). So we yaw first around the z axis, then pitch the yawed frame around its new y axis and finally roll the yawed and pitched frame around its new x axis. Due to the minus sign positive angle direction is described by the left hand rule, e.g. to yaw positive you grab the z axis with your left hand and rotate towards the direction of your fingers. You can use the following link to figure out your board alignment angles: https://www.geogebra.org/3d/sj5aeucn diff --git a/docs/wiki/guides/current/Freestyle-Tuning-Principles.md b/docs/wiki/guides/current/Freestyle-Tuning-Principles.md index 5543ad421b..35d8d47c9b 100644 --- a/docs/wiki/guides/current/Freestyle-Tuning-Principles.md +++ b/docs/wiki/guides/current/Freestyle-Tuning-Principles.md @@ -256,7 +256,7 @@ Thrust Linear helps to boost the PID gains low throttle helping to offset reduce ## RC smoothing -Higher than default RC smoothing helps reducing stick input gliches caused by noise in the RC link. +Higher than default RC smoothing helps reducing stick input glitches caused by noise in the RC link. ### Suggested setting: diff --git a/docs/wiki/guides/current/GPS-Rescue-Mode-v4-1-to-v4-3.md b/docs/wiki/guides/current/GPS-Rescue-Mode-v4-1-to-v4-3.md index 5a843c26dc..38c13d122e 100644 --- a/docs/wiki/guides/current/GPS-Rescue-Mode-v4-1-to-v4-3.md +++ b/docs/wiki/guides/current/GPS-Rescue-Mode-v4-1-to-v4-3.md @@ -54,13 +54,13 @@ This is the distance, in meters, at which your quad will start descending toward `set gps_rescue_ascend_rate = [number] (default is 500)` (added in betaflight 4.1) -This is the vertical speed at which your quad will climb, espressed in centimeters for second +This is the vertical speed at which your quad will climb, expressed in centimeters for second `set gps_rescue_descend_rate = [number] (default is 150)` (added in betaflight 4.1) -This is the vertical speed at which your quad will descend, espressed in centimeters for second +This is the vertical speed at which your quad will descend, expressed in centimeters for second -`gps_rescue_throttle_min` and `gps_rescue_throttle_max` in betaflight 4.1 only limit the escursion of the the new pid controller(https://github.com/betaflight/betaflight/pull/8015) +`gps_rescue_throttle_min` and `gps_rescue_throttle_max` in betaflight 4.1 only limit the excursion of the the new pid controller(https://github.com/betaflight/betaflight/pull/8015) `gps_rescue_alt_mode = [MAX_ALT, FIXED_ALT, CURRENT_ALT]` (added in betaflight 4.1) @@ -70,7 +70,7 @@ now we can set the altitude of gps rescue **FIXED_ALT**, the quad will always try to return to the height set (`gps_rescue_initial_alt`) -**CURRENT_ALT**, the quad will return maintaining the readed altitude during the rescue activation (not suggested) +**CURRENT_ALT**, the quad will return maintaining the altitude read during the rescue activation (not suggested) ### At this point you are ready to test Rescue Mode. diff --git a/docs/wiki/guides/current/GPS-Rescue-v4-4.md b/docs/wiki/guides/current/GPS-Rescue-v4-4.md index 7412fa89e1..562ef47eb3 100644 --- a/docs/wiki/guides/current/GPS-Rescue-v4-4.md +++ b/docs/wiki/guides/current/GPS-Rescue-v4-4.md @@ -57,12 +57,12 @@ Level mode must provide a stable hover, after careful acc trimming. The throttle - A properly trimmed accelerometer -- A working GPS module. Modern UBlox units work well. Check that they support Ublox, 10hz updates, and that they have a backup battery, so that it will regain satellites during repeated power cycles much more quickly. +- A working GPS module. Modern UBlox units work well. Check that they support UBlox, 10hz updates, and that they have a backup battery, so that it will regain satellites during repeated power cycles much more quickly. - `set GPS_PROVIDER = GPS_UBLOX` enables `UBLOX` mode. This is recommended and is now the default. - if the GPS doesn't support `UBLOX`, try `NMEA`. Some, but not all, NMEA-only units will provide 10Hz data updates, and can work really well. NMEA at 1Hz makes it very difficult for the quad to fly home; it will jerk and jump every second, with very erratic rescue flight behaviour. - test the accuracy of your GPS by watching it in Configurator while stable on a desk outdoors. Zoom in on the map and see how the position moves around, especially if the quad is put on an angle and some satellites are lost. Note that altitude estimation is quite unstable. It can take a long time for the GPS to really settle down. -- If a Baro is present, enabling it will improve IMU altitude estimations significantly. We recommend enabling Baro by default, especially for short flights (eg up to 10-15min). Usually this results in better altitude control and more reliable landings. Check the baro data in the sensors tab after enabling the `ALTITUDE` debug. It should be reasonably smooth after arming. Whether or not Baro is helpful is readily seen by doing some LOS rescues at low altitude over flat ground. For longer flights, and some Baro hardware, Baro drift can be more of a problem than GPS drift. Hence do some testing with it on or off and then set your Baro trust value appropriately for the kind of flying you intend to do. +- If a Baro is present, enabling it will improve IMU altitude estimations significantly. We recommend enabling Baro by default, especially for short flights (eg up to 10-15min). Usually this results in better altitude control and more reliable landings. Check the Baro data in the sensors tab after enabling the `ALTITUDE` debug. It should be reasonably smooth after arming. Whether or not Baro is helpful is readily seen by doing some LOS rescues at low altitude over flat ground. For longer flights, and some Baro hardware, Baro drift can be more of a problem than GPS drift. Hence do some testing with it on or off and then set your Baro trust value appropriately for the kind of flying you intend to do. - If a Compass (mag, or magnetometer) is available, and if it has been properly calibrated, and the data is noise free, it may improve heading estimation. Compasses must be positioned well away from magnetic fields, including those from current flowing through wires. This is very difficult even on a 7" setup. Using an incorrectly calibrated or noisy compass will adversely affect the rescue. Be sure to log your compass data and check that it is accurate and clean before enabling it. In most 5" or smaller drones, Mag is too noisy to be useful. @@ -72,7 +72,7 @@ This table lists GPS modules that we have first hand experience with. We recommend getting one that works with UBlox at 10hz and has hot start capability. A magnetometer is useful only if the GPS unit can be mounted well away from any other electronics. -| Module | Ublox | 10hz | Hot Start | Mag | Notes | +| Module | UBlox | 10hz | Hot Start | Mag | Notes | | ------------------- | ----- | ---- | --------- | -------- | --------------------------------------------------------------------------- | | Matek SAM-M8Q | yes | yes | yes | No | works well | | Matek M8Q-5883 | yes | yes | yes | QMC5883L | works well, mag noisy unless placed carefully | @@ -115,7 +115,7 @@ Basic setup: - configure a Mode switch to activate Failsafe - test carefully -**3. Directly enter GPS Rescue with the GPS Rescue Mode swith** +**3. Directly enter GPS Rescue with the GPS Rescue Mode switch** Here we want the quad to immediately level out, climb and start to fly home - no waiting. It makes sense when used as an emergency 'safety return' switch, perhaps, in cases where you're long-ranging and lose FPV signal, or in Acro and lose control in the distance. Just hit the GPS Rescue Mode switch and it should level out, climb, and head back to home. Undo the switch, and you're immediately back in control. @@ -219,7 +219,7 @@ The `GPS_RESCUE_ALT_MODE` setting, in association with the `GPS_RESCUE_RETURN_AL | `GPS_RESCUE_THROTTLE_MAX` | The highest throttle value that can be applied by the GPS Rescue code. This is unlikely to need increasing unless the quad is very heavy. | | `GPS_RESCUE_THROTTLE_HOVER ` | **Important** The hover throttle value that approximates the value required during the fly home phase, or will result in a steady slow climb in level mode. This is the basic throttle value about which the throttle PIDs vary throttle (within limits). It is important to set this value correctly, to ensure that the craft climbs, rather than drops, right at the start of a rescue, and descends in 'DO NOTHING' mode. | | `GPS_RESCUE_SANITY_CHECKS` | Sets what happens if the Rescue fails. See the Sanity checks section | -| `GPS_RESCUE_USE_MAG` | Use magmetometer (compass) data to improve heading accuracy. Do not enable this unless the mag is calibrated and a log shows high-quality noise free compass data. | +| `GPS_RESCUE_USE_MAG` | Use magnetometer (compass) data to improve heading accuracy. Do not enable this unless the mag is calibrated and a log shows high-quality noise free compass data. | | `GPS_RESCUE_ALLOW_ARMING_WITHOUT_FIX` | Option that permits arming without a home fix (never do this, see below) | | `GPS_RESCUE_MIN_SATS` | Value 5 - 50. The number of satellites required, as well as a 3D fix, for the Home point to be set, and to permit arming when GPS Rescue is configured. Setting this to lower values risks poor GPS control. Default is 8 and with less than 5 we have no 3D fix and cannot control altitude from GPS alone. With a Baro this could be set to 5, since Baro can provide altitude with only a 2D GPS fix, but this possibility has not been tested. | | `ALTITUDE_LPF` | The cutoff value in Hz \* 100 that will be used to smooth the altitude value | diff --git a/docs/wiki/guides/current/GPS-Rescue-v4-5.md b/docs/wiki/guides/current/GPS-Rescue-v4-5.md index 829b27cd37..48626bf5da 100644 --- a/docs/wiki/guides/current/GPS-Rescue-v4-5.md +++ b/docs/wiki/guides/current/GPS-Rescue-v4-5.md @@ -121,7 +121,7 @@ Typical applications include: - **Heading** will be wrong, right at the start, if there is no Mag. After takeoff, the GPS requires at least several seconds of clean straight pitch forward speed in order to determine the heading of the quad from the course over ground. Check the arrow in the OSD! It must point correctly to home within 5-10s (50-80m) of take-off. If you are going to rely on the rescue, and the arrow isn't right after 10s, return to home, land, power cycle, and try again. - **High head-winds in the return leg may cause rescue failure**. High winds can cause sideways drift during the rescue, IMU disorientation if the course over ground does not match the direction of the nose of the quad, and may simply blow the quad backwards. The quad must be configured with sufficient max pitch angle and sufficient max throttle to defeat a headwind. Before taking on high winds, do a test rescue and check that the quad can overcome the wind. - **Do not enable the Compass _unless_ it has been properly calibrated and the data confirmed, by logging, to be useful and accurate.** -- **Use UBlox; don't use NMEA**. GPS units configured to use NMEA often update only once per second, or even slower. This makes GPS Rescue very jerky, and almost unusuable. We provide strong UBlox support, and little or no NMEA support. It's much better to use UBlox. +- **Use UBlox; don't use NMEA**. GPS units configured to use NMEA often update only once per second, or even slower. This makes GPS Rescue very jerky, and almost unusable. We provide strong UBlox support, and little or no NMEA support. It's much better to use UBlox. - **SBAS** mode may cause problems getting reliable GPS data, and may not function in some regions; if so, try setting SBAS mode off. - **Unreliable GPS Modules**. GPS modules vary greatly in performance and reliability. Don't use unreliable modules, meaning those where you do not quickly get at least 10 solid sats, and modules that lose sats readily when the quad is put at an angle. - **Using `GPS_RESCUE_ALLOW_ARMING_WITHOUT_FIX` is NOT recommended!** While you can take off without the long wait for the GPS fix, if you do need a rescue, due to Rx loss, the quad will immediately disarm and crash. This option should only be used when the pilot only needs to record basic GPS info to the log, or their radio, to help them find it after they crash. @@ -151,7 +151,7 @@ Modules with a backup battery will regain satellites more quickly during subsequ A good GPS will, from a cold start, get around 20 sats within a couple of minutes, and have 10-12 involved in the 3D 'fix', each showing a good signal level. The module should acquire each satellite progressively and not chop and change between them. Angling the quad should not cause loss of satellites involved in the fix. Zoom in on the map and see how the position moves around, especially if the quad is put on an angle and some satellites are lost. The position on the map should be stable. If it wanders around by many meters, that's not good. Since the module is 'still' on the table, the 'speed' should be zero. It never is, of course, but with a solid fix, the 'speed' should not exceed 10-20 cm/s and should mostly be under 10cm/s when it has a good 'fix'. Do not use a module that shows speeds > 25cm/s persistently while still, takes a long time to acquire satellites, doesn't have strong signal strength, moves around on the map, and loses position information when angled 45 degrees. Generally, physically larger GPS modules work better than smaller units. Note that the quality and speed of the fix has nothing to do with Betaflight; it is intrinsic to the performance of the module itself. ::: -- If a Baro is present, enabling it will improve altitude estimations significantly, especially for short duration flights (5-10 minutes). Usually this results in better altitude control and more reliable landings. Check the baro data in the sensors tab after enabling the `ALTITUDE` debug. It should be reasonably smooth after arming. Whether or not Baro is helpful is readily seen by doing some LOS rescues at low altitude over flat ground. For longer flights, and with some Baro hardware, Baro drift can be more of a problem than GPS drift. Hence long-range pilots may prefer to not use Baro; they should do some testing with it on or off and then set the Baro trust value appropriately for the kind of flying you intend to do. +- If a Baro is present, enabling it will improve altitude estimations significantly, especially for short duration flights (5-10 minutes). Usually this results in better altitude control and more reliable landings. Check the Baro data in the sensors tab after enabling the `ALTITUDE` debug. It should be reasonably smooth after arming. Whether or not Baro is helpful is readily seen by doing some LOS rescues at low altitude over flat ground. For longer flights, and with some Baro hardware, Baro drift can be more of a problem than GPS drift. Hence long-range pilots may prefer to not use Baro; they should do some testing with it on or off and then set the Baro trust value appropriately for the kind of flying you intend to do. - If a Compass (mag, or magnetometer) is available, and if it has been properly calibrated, and the data is noise free, it may improve heading estimation. Compasses must be positioned well away from magnetic fields, including those from current flowing through wires. This is very difficult even on a 7" setup. Using an incorrectly calibrated or noisy compass will adversely affect the rescue. Be sure to log your compass data and check that it is accurate and clean before enabling it. In most 5" or smaller drones, Mag is too noisy to be useful. Do not use the mag unless you log its information after flying a known 'square' course very accurately. The log should show clean 90 degree heading changes in the mag data. If not, don't use it. If in doubt, don't use it. We will be improving Mag integration in coming firmware releases. @@ -358,7 +358,7 @@ The `GPS_RESCUE_ALT_MODE` setting, in association with the `GPS_RESCUE_RETURN_AL | `GPS_RESCUE_VELOCITY_D` | D gain value that increases pitch angle when the quad decelerates (loses velocity to home) | | `ALTITUDE_LPF` | The cutoff value in Hz \* 100 that will be used to smooth the altitude value. Too much smoothing leads to wobble. | | `ALTITUDE_D_LPF` | The cutoff value in Hz \* 100 that will be used to smooth the altitude derivative (vertical velocity) value. This also smooths the Vario signal at present. | -| `GPS_RESCUE_USE_MAG` | Use magmetometer (compass) data to improve heading accuracy. Do not enable this unless the mag is calibrated and a log shows high-quality noise free compass data. | +| `GPS_RESCUE_USE_MAG` | Use magnetometer (compass) data to improve heading accuracy. Do not enable this unless the mag is calibrated and a log shows high-quality noise free compass data. | ## PID Tuning suggestions: @@ -502,7 +502,7 @@ Notes: - Vario is smoothed only while armed, and is only present if Vario is enabled in the firmware build - GPS connection Nav Data interval is the time between GPS packets by comparing their time-stamp - GPS connection time since last Nav data is a stepped ramp, stepping up each time the GPS code runs, and reseting when new Nav data arrives. -- GPS connection dynamic model requested is normally 1 (default acquire model) at the startand 7 (default flight model) when we gain a 3D fix +- GPS connection dynamic model requested is normally 1 (default acquire model) at the start and 7 (default flight model) when we gain a 3D fix - GPS connection state is calculated as main State \* 100 + step, eg 413 is in the `CONFIGURE` main state, at step 13 - GPS connection Ack state is calculated as 0 = `IDLE`, 1 = `WAITING`, 2 = `ACK`, 3 = `NACK` diff --git a/docs/wiki/guides/current/Hardware-Reference.md b/docs/wiki/guides/current/Hardware-Reference.md index e23b9e7b2f..9b9bd0d6b0 100644 --- a/docs/wiki/guides/current/Hardware-Reference.md +++ b/docs/wiki/guides/current/Hardware-Reference.md @@ -20,7 +20,7 @@ If you are adding a new flight controller then: ### MPU (SPI versus I2C) -### MPU Interrrupt +### MPU Interrupt ### Blackbox Flash diff --git a/docs/wiki/guides/current/I-Term-Relax-Explained.md b/docs/wiki/guides/current/I-Term-Relax-Explained.md index 04b28aaed6..bd01bf4f67 100644 --- a/docs/wiki/guides/current/I-Term-Relax-Explained.md +++ b/docs/wiki/guides/current/I-Term-Relax-Explained.md @@ -29,7 +29,7 @@ For example, in the above log trace a higher cutoff value allows for better setp ## Known Drawbacks -Bacause I is 'locked' to the pre-existing value before entering a fast maneuver, when it comes back on the old I offset takes a little while to resolve. +Because I is 'locked' to the pre-existing value before entering a fast maneuver, when it comes back on the old I offset takes a little while to resolve. ![](https://user-images.githubusercontent.com/2025999/75109721-61eeb000-5626-11ea-81ef-75bee6628d59.jpg) diff --git a/docs/wiki/guides/current/IRC-Tramp.md b/docs/wiki/guides/current/IRC-Tramp.md index 3197c4fa1e..67a2a778e1 100644 --- a/docs/wiki/guides/current/IRC-Tramp.md +++ b/docs/wiki/guides/current/IRC-Tramp.md @@ -63,7 +63,7 @@ https://github.com/betaflight/betaflight-tx-lua-scripts/releases ## Modify VTX Settings (TBS Unify / Tramp HV / RTC6705 ) using Spektrum VTX Setup Menu -Any VTX that is configurable from CMS and CLI can also be controlled using a Spektrum TX with VTX Setup menues, introduced in betaflight 3.3.0. +Any VTX that is configurable from CMS and CLI can also be controlled using a Spektrum TX with VTX Setup menus, introduced in betaflight 3.3.0. ![Spektrum VTX Setup menu](/img/Spektrum_VTX_Control_menu.jpg) diff --git a/docs/wiki/guides/current/Installing-Betaflight.md b/docs/wiki/guides/current/Installing-Betaflight.md index eaf407aae3..59b8119311 100644 --- a/docs/wiki/guides/current/Installing-Betaflight.md +++ b/docs/wiki/guides/current/Installing-Betaflight.md @@ -141,7 +141,7 @@ If you see your ttyUSB device disappear right after the board is connected, chan sudo systemctl stop ModemManager.service ``` -If your system lacks the systemctl command, use any equivalent command that works on your system to disable services. You can likely add your device ID to a blacklist configuration file to stop ModemManager from touching the device, if you need it for cellural networking, but that is beyond the scope of cleanflight documentation. +If your system lacks the systemctl command, use any equivalent command that works on your system to disable services. You can likely add your device ID to a blacklist configuration file to stop ModemManager from touching the device, if you need it for cellular networking, but that is beyond the scope of cleanflight documentation. If you see the ttyUSB device appear and immediately disappear from the list in Cleanflight Configurator when you plug in your flight controller via USB, chances are that NetworkManager thinks your board is a GSM modem and hands it off to the ModemManager daemon as the flight controllers are not known to the blacklisted diff --git a/docs/wiki/guides/current/Launch-Control.md b/docs/wiki/guides/current/Launch-Control.md index fc1a367aa5..d508f8f448 100644 --- a/docs/wiki/guides/current/Launch-Control.md +++ b/docs/wiki/guides/current/Launch-Control.md @@ -28,7 +28,7 @@ For Launch Control to be enabled the mode must be configured. The state of the m **`launch_control_mode`**: Allows `NORMAL` (default), `PITCHONLY`, and `FULL`. - `NORMAL`: designed for launching off the ground balanced on a bottom-mount battery. Roll and pitch will hold position. Yaw control is available but the PID controller will not attempt to hold yaw position. -- `PITCHONLY`: for use with race launch stands or possibly off the gound with top-mount batteries. Disables roll and yaw completely. Also the front motors are kept at idle to minimize chances of falling off the stand. Do not use this mode if trying to balance off a battery as the quad will fall forward since the front motors will not react. +- `PITCHONLY`: for use with race launch stands or possibly off the ground with top-mount batteries. Disables roll and yaw completely. Also the front motors are kept at idle to minimize chances of falling off the stand. Do not use this mode if trying to balance off a battery as the quad will fall forward since the front motors will not react. - `FULL`: Like `NORMAL` but adds position holding for yaw as well. Use care with this option as yaw tends to windup if left too long. **`launch_trigger_allow_reset`**: Allows `OFF` and `ON` (default). diff --git a/docs/wiki/guides/current/Magnetometer.md b/docs/wiki/guides/current/Magnetometer.md index 4d89a7d375..5661fecac1 100644 --- a/docs/wiki/guides/current/Magnetometer.md +++ b/docs/wiki/guides/current/Magnetometer.md @@ -102,7 +102,7 @@ The sensor in most standalone Mag modules, e.g. the GY-271 board, is soldered on - centrally - in the same plane of the FC, typically both devices 'flat to the frame' -- as far as possible, away from motors, other metallic onjects, and high-current wires +- as far as possible, away from motors, other metallic objects, and high-current wires - with the X axis pointing forward, directly to the nose of the quad, Y left and Z up The sensor in most GPS modules is mounted _upside-down_. The Z axis points _downwards_. They require a _'flip'_ orientation. @@ -168,7 +168,7 @@ No matter how the magnetometer is mounted, is absolutely essential to confirm pr :::tip -When the Mag orientation (alignment) is correct, the 'quad icon' in the Home screen of Configurator should move smoothly and appropriately as the quad is rotated, pitched and rolled. Note that when the quad's attitude is changed very quickly, the heading will initially react quickly, using Gyro and Acc data, and then over the next half second will be adjusted according to the Mag data. If the orientation of the Mag data axes is wrong, or the calibration is off, then the 'quad icon' will turn correctly at first, but then quickly shift to an incorrect heading. That's a red flag; you'll need to fix the 0rientation, and re-calibrate. +When the Mag orientation (alignment) is correct, the 'quad icon' in the Home screen of Configurator should move smoothly and appropriately as the quad is rotated, pitched and rolled. Note that when the quad's attitude is changed very quickly, the heading will initially react quickly, using Gyro and Acc data, and then over the next half second will be adjusted according to the Mag data. If the orientation of the Mag data axes is wrong, or the calibration is off, then the 'quad icon' will turn correctly at first, but then quickly shift to an incorrect heading. That's a red flag; you'll need to fix the orientation, and re-calibrate. ::: @@ -377,7 +377,7 @@ Another alternative method: Check the `mag_calibration` CLI numbers after each run to confirm that you are getting consistent values. -You can be happy that things are pretty good if the values are within 20-30 field strengt units from run to run. +You can be happy that things are pretty good if the values are within 20-30 field strength units from run to run. The calibration can be confirmed by: @@ -444,7 +444,7 @@ _Drafted by **ctzsnooze** in 2023-09 for Betaflight 4.5. Huge shout out to **led [^2]: [Inclination or Dip - PhysicsMax](https://physicsmax.com/inclination-dip-7371) [^3]: [Magnetic Field Calculators - NOAA](https://www.ngdc.noaa.gov/geomag/calculators/magcalc.shtml) [^4]: [Inclination and Declination map](https://www.magnetic-declination.com) -[^5]: [AK8963 datasheet (disccontinued)](https://www.alldatasheet.com/datasheet-pdf/pdf/535561/AKM/AK8963.html) +[^5]: [AK8963 datasheet (discontinued)](https://www.alldatasheet.com/datasheet-pdf/pdf/535561/AKM/AK8963.html) [^6]: [AK8975 datasheet (discontinued)](https://www.alldatasheet.com/datasheet-pdf/pdf/535562/AKM/AK8975.html) [^7]: [HMC5883L datasheet](https://cdn-shop.adafruit.com/datasheets/HMC5883L_3-Axis_Digital_Compass_IC.pdf) [^8]: [QMC5883L datasheet](https://datasheet.lcsc.com/szlcsc/QST-QMC5883L-TR_C192585.pdf) diff --git a/docs/wiki/guides/current/OSD-Font-Upload-Problem.md b/docs/wiki/guides/current/OSD-Font-Upload-Problem.md index c493020e22..56e9ba31f1 100644 --- a/docs/wiki/guides/current/OSD-Font-Upload-Problem.md +++ b/docs/wiki/guides/current/OSD-Font-Upload-Problem.md @@ -4,7 +4,7 @@ Betaflight-configurator font upload function via USB doesn't seem to work on some flight controllers. -![OrsarLiang](https://oscarliang.com/ctt/uploads/2017/07/betaflight-osd-font-manager.jpg) +![OscarLiang](https://oscarliang.com/ctt/uploads/2017/07/betaflight-osd-font-manager.jpg) No matter how many times you upload the font, the OSD still display the default font. diff --git a/docs/wiki/guides/current/PID-Tuning-Guide.md b/docs/wiki/guides/current/PID-Tuning-Guide.md index 540d3ee09c..7bbface731 100644 --- a/docs/wiki/guides/current/PID-Tuning-Guide.md +++ b/docs/wiki/guides/current/PID-Tuning-Guide.md @@ -97,7 +97,7 @@ voltage chart vs remaining capacity. ![PID animation](https://github.com/bw1129/PIDtoolbox/raw/master/images/PID_Compensation_Animated.gif) -- **P** = The present (proportional) +- **P** = The Present (proportional) - **I** = The Past (integral) - **D** = The Future (derivative / damping) !Dangerous @@ -128,7 +128,7 @@ You can lower P to reduce the oscillations, but reduce it too much and your quad - **High P-gain** means the copter accelerates harder to reach the target rotational rate - **Higher P-gain** feels `sharper` - **Lower P-gain** feels `softer` -- **too high P-gain** results in more (slow, sluggish) oscillation +- **Too high P-gain** results in more (slow, sluggish) oscillation ## I-Term (integral) @@ -170,7 +170,7 @@ Another side effect of **excessive D-term is the decrease in the quad’s respon `set debug_mode=d_min` -- Proportial to the _change in magnitude_ of error +- Proportional to the _change in magnitude_ of error - Anticipates the _future state_ of the system based on its current movement - It reduces the P-term overshoot and oscillation (_damping effect_) - But accelerates the P term too! @@ -191,7 +191,7 @@ Another side effect of **excessive D-term is the decrease in the quad’s respon ## d min -Set the lowest D-term, it then get dymacially increased (to PID's maximum D-term) on sharper stick movements +Set the lowest D-term, it then get dynamically increased (to PID's maximum D-term) on sharper stick movements D Min provides a way to have a lower level of D in normal flight and a higher level for quick maneuvers that might cause overshoot, like flips and rolls. It also brings D up during prop wash. Gain adjusts how fast D gets up to its maximum value and is based on gyro to determine sharp moves and propwash events. Advance makes D go up earlier by using setpoint instead of gyro to determine sharp moves. @@ -199,7 +199,7 @@ D Min provides a way to have a lower level of D in normal flight and a higher le - Raise P till quad is "sharp" - Raise D till it's soft enough -- Raise I till (too much looses control (slow response) +- Raise I till (too much looses control (slow response)) - if oscillation is fast, reduce D - if oscillation is slow, raise D (or lower P) @@ -208,7 +208,7 @@ D Min provides a way to have a lower level of D in normal flight and a higher le ``` P -> Higher makes Quad more sharp (oscillates if too high or low) I -> High Makes the quad more digital / mechanical (measures errors) holds the attitude better if raised -D -> High values dampes the P (works against P, flattens the curve) D-term relates on the gyro measurements +D -> High values dampen the P (works against P, flattens the curve) D-term relates on the gyro measurements ``` ### Solve @@ -228,10 +228,10 @@ D -> High values dampes the P (works against P, flattens the curve) D-term relat - my tuning approach focuses on: - minimizing propwash - eliminating bouncebacks after flips and rolls - - solitd attitude hold on throttle change + - solid attitude hold on throttle change - the main maneuvers I use to tune are sharp turns, flips and rolls, and throttle punches -## PID Tuning (borrowed from Betaflights manual) +## PID Tuning (borrowed from Betaflight's manual) [Guide](PID-Tuning-Guide) @@ -267,7 +267,7 @@ Finally, refine the relationship between P and I by looking for a tendency to re ### PID Masterclass -#### Autoselect Profile dependend on your Battery Voltage +#### Autoselect Profile depending on your Battery Voltage This selects profile 1 if you connect a 3S battery and selects profile 2 if you connect a 4S battery @@ -364,7 +364,7 @@ Most often noisier than other axis # Oscillations -- Regular to the fixed freqzency = P-term issue +- Regular to the fixed frequency = P-term issue - Randomly / irregular Vibration could be D-term (amplifies noise) - Props (punch throttle) oscillation higher frequency @@ -381,8 +381,8 @@ These sudden movements cause the prop's spin to create turbulence, causing insta - Smoothing Type = Filter - Ch Smoothed = RPYT -- If you dont smooth on Y then you cant have ff on yaw -- Input cuttoffType = AUTO +- If you don't smooth on Y then you cant have ff on yaw +- Input cutoffType = AUTO - Input FilterType = BIQUAD - Derivative CutoffType = AUTO - Derivative FilterType = BIQUAD @@ -458,7 +458,7 @@ Zero FeedForward allows D-term to dampen the quad all the time, even when the qu ``` -set f_ptich = 100 +set f_pitch = 100 set f_roll = 100 beacon RX_SET @@ -497,7 +497,7 @@ Most motors take time to spin up / slow down. They need to be pushed harder at t ### Setpoint (deprecated) / FeedForward-transition - Reduces the weight when the stick is returning to center -- 0.15 = 15% of sticktravel is smooth +- 0.15 = 15% of stick travel is smooth - When nose is raising/lowering when giving throttle punch raise AG. - Is a virtual `I` booster if changed. @@ -531,7 +531,7 @@ Integrated Yaw is a feature which corrects a fundamental issue with quad control ## I-term relax Type -Limits the accumulation of I Term when fast movements happen. This helps specially to reduce the bounceback at the end of rolls and other fast movements. You can choose the axes in which this is active, and if the fast movement is detectd using the Gyro or the Setpoint (stick). +Limits the accumulation of I Term when fast movements happen. This helps specially to reduce the bounceback at the end of rolls and other fast movements. You can choose the axes in which this is active, and if the fast movement is detected using the Gyro or the Setpoint (stick). - **Gyro** = more for Freestyle pilots (good at bouncebacks, bad in turns) - uses a high-pass filter based on rate of change stick movements @@ -564,7 +564,7 @@ TPA basically allows an aggressively tuned multi-rotor (one that feels very lock - tpa_mode: PD/D (Only acts on D-term by default) - tpa_rate: TPA 0.6 means 60% PIDs decrease on full throttle -- tpa_breakpoint: TPA breakpoint 1250(25%) - throttle value at wich TPA starts to work +- tpa_breakpoint: TPA breakpoint 1250(25%) - throttle value at which TPA starts to work ![TPA](https://user-images.githubusercontent.com/15355893/165534786-978e3129-04e6-4943-9be0-bcc79ed3d622.png) @@ -642,7 +642,7 @@ Mostly `set debug_mode = GYRO_SCALED` could be used. - below zero your quad is more heavy to the right - above zero your quad is more heavy to the left -- could also occour on windy days (force from outside) +- could also occur on windy days (force from outside) - is your gyro multiplied by a gain ### PID error @@ -650,7 +650,7 @@ Mostly `set debug_mode = GYRO_SCALED` could be used. - is the offset of your setpoint and gyro - the "perfect tuned quad" always has zero PID error - gyro should exactly track setpoint -- biggest errors occour if you start a sharp pitch or roll +- biggest errors occur if you start a sharp pitch or roll - propwash also generates PID error - drives the PID @@ -710,7 +710,7 @@ PID-error = Setpoint - Gyro - `resource show` `resource list (bf 3.x)` then it shows which Pins are used (Example: LedStrip, I2C) - `resource i2c_scl 1 none` unassign current I2C - `resource led_strip 1 none` unassign current LedStrip -- `resouce camera_control B06` Whatever your PIN ID you have +- `resource camera_control B06` Whatever your PIN ID you have - `resource list` check if your change is applied - `set camera_control_key_delay = 125` - `save` @@ -760,7 +760,7 @@ https://drohnen360.com/was-bedeutet-pwm-ppm-sumd-sbus-f-port/ **2RSS** - Antenna 2 Signal Strength Uplink - received signal strength antenna 2 (RSSI) -**TRSS** - TX Radio Signal Strength ()Signalstärke Downlink) +**TRSS** - TX Radio Signal Strength (Signalstärke Downlink) **RQly** - Uplink - link quality (valid packets) (Empfangsqualität Empfänger) @@ -835,7 +835,7 @@ save` Done -## Supermario as startup sound +## Super Mario as startup sound ### Motor 1 @@ -881,7 +881,7 @@ C6 8 G5 8 C6 8 E6 8 G6 8 C7 8 G6 8 G#5 8 C6 8 D#6 8 G#6 8 D#6 8 G#6 8 C7 8 D#7 8 Update BLHeli && Upgrade to latest Firmware Count your Magnets on motors and type that in Betaflight Configurator -Set Dhsot 300/600 +Set Dshot 300/600 go to Motors tab, connect your Battery and look that error rate (percentage) MUST be 0% (100% if Batt not connected) OG to Filter settings and Switch on Gyro RPM Filter Harmonics 1 (most cases) (BUT YOU SHOULD SET IT TO 3 ) @@ -890,7 +890,7 @@ you can now use dynamic notch to watch something else (noise) than the motors (l Set Dyn filter range to "low" Q to 200 -Make a slight test flight, if motors cool or slighly warm you can reduce filter by move "Gyro Filter Multiplier" and "D term Filter muliplier" to the right (less filtering) +Make a slight test flight, if motors cool or slightly warm you can reduce filter by move "Gyro Filter Multiplier" and "D term Filter multiplier" to the right (less filtering) Do not use very new props (to prevent too less filtering) ##### you can use this too diff --git a/docs/wiki/guides/current/Pinio-and-PinioBox.md b/docs/wiki/guides/current/Pinio-and-PinioBox.md index dd57f603c0..c3a2162784 100644 --- a/docs/wiki/guides/current/Pinio-and-PinioBox.md +++ b/docs/wiki/guides/current/Pinio-and-PinioBox.md @@ -165,7 +165,7 @@ Array length: 4 Default value: 0,255,255,255 ``` -This is PINIO #1(mapped to pin `B00`), so we only look at the _first_ of the four comma seperated values in the arrays. +This is PINIO #1(mapped to pin `B00`), so we only look at the _first_ of the four comma separated values in the arrays. The value of `pinio_box` is `0`, which -- according to the table above -- is set to the `BOXARM` box/mode. So if the craft gets armed, this gets activated, too. @@ -240,7 +240,7 @@ This time, we want to switch the VTX with an actual switch on the sender. For th For this, we use one of the `BOXUSER` modes/boxes (IDs 40 to 43). This will add a matching User mode/function in the Modes tab of the Configurator, which can then be mapped to a channel on the sender. -Let's say we have a "clean" flight controller without any preconfigured PINIOs or User functions and the PPM pin is the one to be used for this: +Let's say we have a "clean" flight controller without any pre-configured PINIOs or User functions and the PPM pin is the one to be used for this: ``` #resource diff --git a/docs/wiki/guides/current/Servos-And-SERVO_TILT-for-3-1.md b/docs/wiki/guides/current/Servos-And-SERVO_TILT-for-3-1.md index 5a26d56cb8..40401f1b68 100644 --- a/docs/wiki/guides/current/Servos-And-SERVO_TILT-for-3-1.md +++ b/docs/wiki/guides/current/Servos-And-SERVO_TILT-for-3-1.md @@ -166,7 +166,7 @@ I have found these instructions work with the Betaflight 3.2.2, Something has ch I have not tried between version 3.2.2 - 3.4.0 either. I am at the moment trying to figure out what has changed, and why, but, if you want to try with higher versions, try it, and try to figure it out. Betaflight 3.2.2 works with a minimum of effort to get your craft flying. -In the future, I want to experiment with GPS rescue for tricopter, which Betaflight 3.2.2 does not support, so I am going to go foward to version 3.4.1 which supports GPS rescue, and start there. +In the future, I want to experiment with GPS rescue for tricopter, which Betaflight 3.2.2 does not support, so I am going to go forward to version 3.4.1 which supports GPS rescue, and start there. If you power down the board, press the bootloader button on the Matek F411 flight controller, and plug back in like a lot of other boards, it does not enter bootloader mode, and there is NO blinking led confirming bootloader mode, at least with my windows 10 laptop. It does not work. @@ -229,7 +229,7 @@ feature CHANNEL_FOWARDING Need to be OFF. -Selecting TRICOPTER sets yaw output to servo automaticly. +Selecting TRICOPTER sets yaw output to servo automatically. How to set the tail servo: diff --git a/docs/wiki/guides/current/SmartAudio.md b/docs/wiki/guides/current/SmartAudio.md index 37eadda052..95bb6fd467 100644 --- a/docs/wiki/guides/current/SmartAudio.md +++ b/docs/wiki/guides/current/SmartAudio.md @@ -127,7 +127,7 @@ In Betaflight, a SmartAudio device operates in one of two operational models: #### Race -This is a model that gives minimum interferance to other pilots. +This is a model that gives minimum interference to other pilots. A SmartAudio device powers up in pit mode, and remain in pit mode until transmission is commenced. When operating in this model, left most character of the status line is `R`. diff --git a/docs/wiki/guides/current/Soft-Mounting-and-Noise-Reduction.md b/docs/wiki/guides/current/Soft-Mounting-and-Noise-Reduction.md index 632ddcda5d..e2315affb7 100644 --- a/docs/wiki/guides/current/Soft-Mounting-and-Noise-Reduction.md +++ b/docs/wiki/guides/current/Soft-Mounting-and-Noise-Reduction.md @@ -51,12 +51,12 @@ I did something like this about 30 years ago when testing frequency response of ## Soft Mounting the FC board -#### A nice Over view of the Yaw Twitch and/or throttle oscillations from ctzsnooze +#### A nice overview of the Yaw Twitch and/or throttle oscillations from ctzsnooze Lots of us have seen exactly this behaviour. I am surprised that you seem so astonished now that you find it happens to you. It happens randomly. It could happen to anyone. It just happened to happen to you. :-) It goes away with replacing the gyro chip, replacing the FC, or soft mounting the FC; these fixes work whether or not capacitors are added. Sometimes it goes away by just adding capacitors. -Since soft mounting is a reliable fix, external vibration seems the likely culprit, difficult otherwise to explain how soft mounting often causes it to just disappear. Blheli-s ESCs are more commonly implicated than non-BLHeli-s ESC's and in some cases capacitors help so there may be an electrical contribution. It is far more common on yaw than the other axes. The yaw sensor within the chip must be physically different from pitch/roll since the axes relative to the layer of silicon for yaw vs pitch/roll are quite different. +Since soft mounting is a reliable fix, external vibration seems the likely culprit, difficult otherwise to explain how soft mounting often causes it to just disappear. BLHeli-s ESCs are more commonly implicated than non-BLHeli-s ESC's and in some cases capacitors help so there may be an electrical contribution. It is far more common on yaw than the other axes. The yaw sensor within the chip must be physically different from pitch/roll since the axes relative to the layer of silicon for yaw vs pitch/roll are quite different. That's all we know for sure. How these factors actually cause the oscillation, and why it is yaw exclusive, is completely speculative. When soft mounting doesn't work it's usually because it isn't done in such a way as to effectively isolate the FC. @@ -65,7 +65,7 @@ I've seen such extreme examples as to render the quad un-flyable, and also much Although the magnitude is increased by higher yaw P it is not simple feedback oscillation, there is no threshold value of P below which it disappears. The actual oscillation frequencies are so low as to not be attenuated by the o-rings. Exactly what the o-rings block is not clear. It cannot be eliminated by filtering the gyro data - as has been pointed out before, out the primary oscillation frequency is within the range we need for to fly the quad normally. -It is not a software issue in blheli or Betaflight, we can be sure of that. Replacing the gyro chip doesn't change that software yet it does fix the problem. +It is not a software issue in BLHeli or Betaflight, we can be sure of that. Replacing the gyro chip doesn't change that software yet it does fix the problem. My gut feeling is that this is an inherent issue in these gyro chip themselves, and that some individual examples of these chips get it much worse than others. That's why I recommend replacing the gyro chip or the whole FC if simple soft mounting fails to solve the problem. When you guys say you are soft mounting, be aware you need to over drill the holes to 4mm and ideally bevel the top and bottom of the hole so that the FC 'floats' in all axes. You need to check for free movement. If you don't drill out the holes the bolt holes will stick on yaw on the bolts and transmit vibrations directly. Also you can't have anything stiff pushing on the FC, ideally all wires to/from it need to be very fine silicone. @@ -155,7 +155,7 @@ https://www.rcgroups.com/forums/showpost.php?p=36698872&postcount=2693 #### Some experiments and observations from AILERON8: -I've found it's these lower frequencies where the soft motor mounts work best. Sometimes shifting the noise upward, but often eliminating it altogether. In addition to trying-out the dynamic notch filter on two quads I spent last weekend playing with my motor softmounts. Empirical testing only, e.g., quads with busted BB's at the moment unfortunately. I also noticed how the higher sounding prop resonance from one of my quads didn't change (as much) with motor soft mounting. My FC soft mounts seemed to be more effective at alleviating the mid-to-high frequencies of the singing unbalanced butter cutters I was testing. It was far from an exhaustive design of experiment, but there was definitely a trend where my silicone and/or rubber soft mounts helped to get rid of the lower motor and frame resonance without having to place additional BF filters. Using the same butters I also noticed how removing my gyro notches had a noticeable impact on mid throttle oscillation reduction as it related to the noisy props. At least on the one quad I was testing, and that's not the first time I've experienced this effect. I'm hoping to do more testing this upcoming weekend and finally get some BB logs to show cause & effect. +I've found it's these lower frequencies where the soft motor mounts work best. Sometimes shifting the noise upward, but often eliminating it altogether. In addition to trying-out the dynamic notch filter on two quads I spent last weekend playing with my motor soft mounts. Empirical testing only, e.g., quads with busted BB's at the moment unfortunately. I also noticed how the higher sounding prop resonance from one of my quads didn't change (as much) with motor soft mounting. My FC soft mounts seemed to be more effective at alleviating the mid-to-high frequencies of the singing unbalanced butter cutters I was testing. It was far from an exhaustive design of experiment, but there was definitely a trend where my silicone and/or rubber soft mounts helped to get rid of the lower motor and frame resonance without having to place additional BF filters. Using the same butters I also noticed how removing my gyro notches had a noticeable impact on mid throttle oscillation reduction as it related to the noisy props. At least on the one quad I was testing, and that's not the first time I've experienced this effect. I'm hoping to do more testing this upcoming weekend and finally get some BB logs to show cause & effect. Let me clarify on my first statement: not actually "shifting" the frequencies higher, but reducing the amplitude of the lower frequencies, leaving the higher frequency noise alone. diff --git a/docs/wiki/guides/current/SoftSerial.md b/docs/wiki/guides/current/SoftSerial.md index 3df1fd0826..4f682387e1 100644 --- a/docs/wiki/guides/current/SoftSerial.md +++ b/docs/wiki/guides/current/SoftSerial.md @@ -88,7 +88,7 @@ It is possible, but not recommended, to use softserial for MSP ports in 4.4 and ### Enabling Softserial -Softserial requires custom CLI commands. An unused pin with an associated timer must be found. The most common are PPM or LED_STRIP pins. Not all such pins will work on all boards, and you may need to do some reseach about using softserial on your board before you can make it work. +Softserial requires custom CLI commands. An unused pin with an associated timer must be found. The most common are PPM or LED_STRIP pins. Not all such pins will work on all boards, and you may need to do some research about using softserial on your board before you can make it work. First go to the CLI and type `resource`, to get a list of the currently assigned pin numbers for each of the currently available pads on the device. @@ -114,7 +114,7 @@ Note: - `resource show all` in CLI will provide a full list of all serial ports, timers etc. - just because the resources are re-assigned, it does not mean that the Softserial port will work properly. -Oscarliang provides a good summary of [how to set up softserial](https://oscarliang.com/betaflight-soft-serial/). Remember that the commands have changed in Betaflight 4.5. +Oscar Liang provides a good summary of [how to set up softserial](https://oscarliang.com/betaflight-soft-serial/). Remember that the commands have changed in Betaflight 4.5. ### The CLI Serial command. diff --git a/docs/wiki/guides/current/Telemetry.md b/docs/wiki/guides/current/Telemetry.md index bc335d9ace..dfe4117d4b 100644 --- a/docs/wiki/guides/current/Telemetry.md +++ b/docs/wiki/guides/current/Telemetry.md @@ -46,7 +46,7 @@ Here is the set of telemetry fields send via the Crossfire protocol. ### Smartport protocol -Here is the set of telemtry fields sent via Smartport can be seen here : https://github.com/betaflight/betaflight/blob/daa6df80248c9a806b7d77c402d415a15f4e2667/src/main/telemetry/smartport.c#L89 +Here is the set of telemetry fields sent via Smartport can be seen here : https://github.com/betaflight/betaflight/blob/daa6df80248c9a806b7d77c402d415a15f4e2667/src/main/telemetry/smartport.c#L89 ### Other protocols All telemetry protocols can be inspected here : https://github.com/betaflight/betaflight/tree/master/src/main/telemetry diff --git a/docs/wiki/guides/current/VTX-CLI-Settings.md b/docs/wiki/guides/current/VTX-CLI-Settings.md index 25fef83dc5..411b90254f 100644 --- a/docs/wiki/guides/current/VTX-CLI-Settings.md +++ b/docs/wiki/guides/current/VTX-CLI-Settings.md @@ -4,7 +4,7 @@ As of Betaflight version 3.3.0, the CLI settings below can be used to configure addressable video transmitters (such as TBS-[SmartAudio](/docs/wiki/guides/current/SmartAudio) and -IRC-[Tramp](IRC-Tramp)[)](IRC-Tramp) +IRC-[Tramp](IRC-Tramp)) that are connected to the flight controller.\ \ At startup the settings are applied to the transmitter. If the video diff --git a/docs/wiki/guides/current/VTX-Tables.md b/docs/wiki/guides/current/VTX-Tables.md index fefadd3d4d..06faa8946d 100644 --- a/docs/wiki/guides/current/VTX-Tables.md +++ b/docs/wiki/guides/current/VTX-Tables.md @@ -68,7 +68,7 @@ Example to cycle VTX power ``` | 0 seconds | 1 second | 2 seconds | 3 seconds | 4 seconds | 5 seconds | 6 seconds or more| -[-HOLD BUTTON------------------------------|-RELEASE BUTTON-NOW------------|-RELEASED TO LATE TO CHANGE POWER | +|-HOLD BUTTON------------------------------|-RELEASE BUTTON-NOW------------|-RELEASED TO LATE TO CHANGE POWER | | 4 Flashes | 3 flashes | 3 flashes | 2 flashes | 2 flashes | 1 flash | 1 flash | | 0 seconds | 1 second | 2 seconds | 3 seconds | 4 seconds | 5 seconds | 6 seconds or more | |-HOLD BUTTON------------------------------|-RELEASE BUTTON-NOW------------|-RELEASED TOO LATE TO CHANGE POWER| @@ -80,5 +80,5 @@ The VTX button works with ALL VTX systems including onboard RTC6705, Tramp and S If the VTX can be turned off then POWER 0 will turn off the VTX and POWER 1 will set the VTX into it's lowest power output. If the VTX cannot be turned off then POWER 0 will set the VTX into it's lowest power output. -Some videotransmitters have restrictions on its usage. For example, SmartAudio V1.0 and V2.0 devices can only enter pitmode on power-up. +Some video transmitters have restrictions on their usage. For example, SmartAudio V1.0 and V2.0 devices can only enter pitmode on power-up. Betaflight can make the these devices leave pitmode, but not enter it. diff --git a/docs/wiki/tuning/4-2-Tuning-Notes.md b/docs/wiki/tuning/4-2-Tuning-Notes.md index ededef9858..0fdb8261ab 100644 --- a/docs/wiki/tuning/4-2-Tuning-Notes.md +++ b/docs/wiki/tuning/4-2-Tuning-Notes.md @@ -320,11 +320,11 @@ Default boost is 15, and that works for nearly all quads. Racers may prefer 20. ### Spike limiting: ff_spike_limit -`ff_spike_limit` provides simple soft cliping method, to chop the tops off large FF spikes. The default should be acceptable for most radios. Most people should leave this value at defaults. +`ff_spike_limit` provides simple soft clipping method, to chop the tops off large FF spikes. The default should be acceptable for most radios. Most people should leave this value at defaults. Higher numbers will allow progressively bigger spikes through. Racers or people with clean radios who want full feed forward aggression can increase this value, but should look closely at their feed forward trace to see what happens. -The biggest normal single FF step change that a pilot ever generates is when they suddenly return from full stick deflection, ie on terminating a fast flip. If having the least possible delay at this point is important, maye try shifting the spike limit higher. +The biggest normal single FF step change that a pilot ever generates is when they suddenly return from full stick deflection, ie on terminating a fast flip. If having the least possible delay at this point is important, maybe try shifting the spike limit higher. ### Overshoot limiting: ff_max_rate_limit @@ -391,7 +391,7 @@ This means '100% compensation for voltage sag'. The code compensates for voltage changes from 4.2V down to the user's configured warning voltage of 3.5V. -A fall from 4.2V to 3.5V is about a 16% reduction in voltage. Withs 100% compensation, a motor output reduction of about 16% will be applied when the battery is full. As the battery voltage falls, motor output is dynamically boosted back towards normal, canceling out the effect of the sag. Once the battery falls to 3.5V or lower, motor output will be normal, or back to 100%, and no further compensation is possible. +A fall from 4.2V to 3.5V is about a 16% reduction in voltage. With 100% compensation, a motor output reduction of about 16% will be applied when the battery is full. As the battery voltage falls, motor output is dynamically boosted back towards normal, canceling out the effect of the sag. Once the battery falls to 3.5V or lower, motor output will be normal, or back to 100%, and no further compensation is possible. Both throttle and motor limits may need to be adjusted after enabling sag compensation. If you already have a static `motor_output_limit` value below 100, this code further reduces motor output below that value. You may want to lift `motor_output_limit` by about 10 for similar overall performance. If you have a throttle limit, there is usually no need to change it. @@ -408,7 +408,7 @@ To only cover the slow fall, set `vbat_sag_lpf_period` to 200 (20 seconds period To respond quickly, stick with the default `vbat_sag_lpf_period` of 2, or 200ms. This has a time constant of about 33ms, fast enough to respond very quickly to fast throttle blips and quick split-S turn type sags. -Whoops tend to be flown at lower voltages than mini quads, so the warning voltage is often set lower, eg 3.3V. The attenuation range, and the initial maximum motor output suppression value, will be a bit bigger. In this case, slightly reduceing the compensation amount, eg to say 80%, will stop it feeling very dull at the start. However, some whoops sag a lot, and on some a value above 100 may be useful to get a constant feeling across the battery range. +Whoops tend to be flown at lower voltages than mini quads, so the warning voltage is often set lower, eg 3.3V. The attenuation range, and the initial maximum motor output suppression value, will be a bit bigger. In this case, slightly reducing the compensation amount, eg to say 80%, will stop it feeling very dull at the start. However, some whoops sag a lot, and on some a value above 100 may be useful to get a constant feeling across the battery range. No adjustments are required when using HV cells. diff --git a/docs/wiki/tuning/4-3-Tuning-Notes.md b/docs/wiki/tuning/4-3-Tuning-Notes.md index c2ce006724..cd367fe23d 100644 --- a/docs/wiki/tuning/4-3-Tuning-Notes.md +++ b/docs/wiki/tuning/4-3-Tuning-Notes.md @@ -556,11 +556,11 @@ The `jitter_reduction_factor` value is the threshold for the RC Command change, Both link frequency and link bit depth have an impact on a suitable jitter reduction value. At low link frequencies, eg 50hz, most RC steps are large, and there really isn't much of a jitter issue to worry about. So the defaults and the suggested freestyle values actually do OK for 50hz to 150hz. -Higher link speeds, 250Hz and above, run into a problem where there is only a limited number of steps available, and not much time for a change to be detected. Crossfire and FrSky protocals only provide 800 steps across the full RC range, or only 400 steps from center to max position. If the pilot moves the stick slowly over one second to max, some RC steps will be one, and others two, packets high. Small steps like that vary by 100% from step to step, leading to a lot of jitter in feedforward, which thinks that the sticks are shaking massively. The person's intrinsic jitter and the gimbal itself makes jitter noise of at least this magnitude, and feedforward would ordinarily amplify it - just like D amplifies gyro noise. +Higher link speeds, 250Hz and above, run into a problem where there is only a limited number of steps available, and not much time for a change to be detected. Crossfire and FrSky protocols only provide 800 steps across the full RC range, or only 400 steps from center to max position. If the pilot moves the stick slowly over one second to max, some RC steps will be one, and others two, packets high. Small steps like that vary by 100% from step to step, leading to a lot of jitter in feedforward, which thinks that the sticks are shaking massively. The person's intrinsic jitter and the gimbal itself makes jitter noise of at least this magnitude, and feedforward would ordinarily amplify it - just like D amplifies gyro noise. This is where the jitter reduction code helps remove that residual noise in higher speed links; its kind of like a dynamic, zero delay filter, applied to feedforward when the signal to noise ratio would be bad. It applies first order filtering to the simple setpoint derivative and second order filtering to the boost element. -Hence the jitter reduction system markedly reduces gimbal jitter on all systems, but is most effective, and important, in higher link rate systems with only 800 steps. For that reason we suggest keeping it at the default value on all RC links, increasing it for freeestyle and cinematic, and maybe dropping back to 5 but only on clean RC links for race purposes. +Hence the jitter reduction system markedly reduces gimbal jitter on all systems, but is most effective, and important, in higher link rate systems with only 800 steps. For that reason we suggest keeping it at the default value on all RC links, increasing it for freestyle and cinematic, and maybe dropping back to 5 but only on clean RC links for race purposes. The newer 11 and 12 bit RC link protocols with 2000 steps will provide better resolution, however gimbal noise will remain a problem, and hence the jitter reduction code is likely to remain needed for the forseeable future.