Mirror/inav
1
0
Fork 0
mirror of https://github.com/iNavFlight/inav.git synced 2025-07-12 19:10:27 +03:00
Code Issues Wiki Activity

Merge pull request #10932 from sensei-hacker/to-merge-from-master-8.1-docs

Browse source 
Branches clean up : merge docs from master to maintenance-8.x.x
This commit is contained in:
Sensei 2025-06-27 19:11:20 -05:00 • committed by GitHub
commit dfa253b135
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
12 changed files with 149 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

1
.github/ISSUE_TEMPLATE/Bug_report.md vendored
View file

@ -14,6 +14,7 @@ assignees: ''
* [INAV Official on Telegram](https://t.me/INAVFlight)
**Please double-check that nobody reported the issue before by using search in this bug tracker.**
**For Bug-Reports, please use the following template and provide as much information as possible. Bug-Reports that don't follow the template, might be closed unanswered. If you are not sure if you found a bug, ask for further input in the community channels or open a Github discussion.**
**PLEASE DELETE THE TEXT ABOVE AFTER READING AND UNDERSTANDING IT**

11
docs/Buzzer.md
View file

@ -102,6 +102,15 @@ To restore set from preferences use:
```
beeper -PREFERED
```
To activate an external beeper via aux channel switch, assign aux channel and set both:
```
beeper RX_SET
beeper MULTI_BEEPS
```
If MULTI_BEEPS is not set, the beeper will not sound after GPS lock.
As with other CLI commands, the `save` command is needed to save the new settings.
@ -117,7 +126,5 @@ Passive buzzers are supported on FCs which are designed to work with passive buz
Examples of a known-working buzzers.
* [Hcm1205x Miniature Buzzer 5v](http://www.rapidonline.com/Audio-Visual/Hcm1205x-Miniature-Buzzer-5v-35-0055)
* [5V Electromagnetic Active Buzzer Continuous Beep](https://inavflight.com/shop/s/bg/943524)
* [Radio Shack Model: 273-074 PC-BOARD 12VDC (3-16v) 70DB PIEZO BUZZER](http://www.radioshack.com/pc-board-12vdc-70db-piezo-buzzer/2730074.html#.VIAtpzHF_Si)
* [MultiComp MCKPX-G1205A-3700 TRANSDUCER, THRU-HOLE, 4V, 30MA](http://uk.farnell.com/multicomp/mckpx-g1205a-3700/transducer-thru-hole-4v-30ma/dp/2135914?CMP=i-bf9f-00001000)
* [3-24V Piezo Electronic Tone Buzzer Alarm 95DB](https://inavflight.com/shop/s/bg/919348)

8
docs/LED pin PWM.md
View file

@ -7,12 +7,15 @@ Normally LED pin is used to drive WS2812 led strip. LED pin is held low, and eve
As alternative function, it is possible to generate PWM signal with specified duty ratio on the LED pin.
Feature can be used to drive external devices. It is also used to simulate [OSD joystick](OSD%20Joystick.md) to control cameras.
Feature can be used to drive external devices such as a VTX power switch. Setting the PWM duty cycle to 100% or 0% can
provide an extra PINIO pin. It is also used to simulate [OSD joystick](OSD%20Joystick.md) to control cameras.
PWM frequency is fixed to 24kHz with duty ratio between 0 and 100%:
![alt text](/docs/assets/images/led_pin_pwm.png "led pin pwm")
Note that the LED feature needs to be enabled when using the PIN in this mode (feature LED_STRIP).
There are four modes of operation:
- low
- high
@ -88,3 +91,6 @@ To drive power LED with brightness control, Mosfet should be used:
![alt text](/docs/assets/images/ledpinpwmpowerled.png "led pin pwm power_led")
# Programming tab example for using the LED pin as a PINIO, such as for turning a VTX or camera on and off
![screenshot of programming tab using led as pinio](/docs/assets/images/led-as-pinio.png)

24
docs/OSD.md
View file

@ -14,17 +14,18 @@ General OSD information is in this document. Other documents cover specific OSD-
## Features and Limitations
Not all OSDs are created equally. This table shows the differences between the different systems available.
| OSD System | Character grid | Character | Canvas | MSP DisplayPort | All elements supported |
|---------------|----------------|-----------|--------|-----------------|-------------------------|
| Analogue PAL | 30 x 16 | X | | | YES |
| Analogue NTSC | 30 x 13 | X | | | YES |
| PixelOSD | As PAL or NTSC | | X | | YES |
| DJI OSD | 30 x 16 | X | | | NO - BF Characters only |
| DJI WTFOS | 60 x 22 | X | | X | YES |
| HDZero | 50 x 18 | X | | X | YES |
| Avatar | 53 x 20 | X | | X | YES |
| DJI O3 | 53 x 20 (HD) | X | | X (partial) | NO - BF Characters only |
| DJI NATIVE | 53 x 20 (HD) | X | | X | YES (TBC) |
| OSD System | Character grid | Character | Canvas | MSP DisplayPort | All elements supported |
|-----------------------------|----------------|-----------|--------|-----------------|-------------------------|
| Analogue PAL | 30 x 16 | X | | | YES |
| Analogue NTSC | 30 x 13 | X | | | YES |
| PixelOSD | As PAL or NTSC | | X | | YES |
| DJI OSD | 30 x 16 | X | | | NO - BF Characters only |
| DJI WTFOS | 60 x 22 | X | | X | YES |
| HDZero | 50 x 18 | X | | X | YES |
| Avatar | 53 x 20 | X | | X | YES |
| DJI O3 Goggles V2 + WTFOS | 53 x 20 | X | | X | YES |
| DJI Goggles 2 and newer | 53 x 20 (HD) | X | | X | YES (no custom fonts) |
## OSD Elements
Here are the OSD Elements provided by INAV.
@ -197,6 +198,7 @@ Here are the OSD Elements provided by INAV.
| 163 | OSD_COURSE_TO_FENCE | 8.0.0 | |
| 164 | OSD_H_DIST_TO_FENCE | 8.0.0 | |
| 165 | OSD_V_DIST_TO_FENCE | 8.0.0 | |
| 166 | OSD_NAV_FW_ALT_CONTROL_RESPONSE | 8.0.0 | |
# Pilot Logos

6
docs/Programming Framework.md
View file

@ -75,7 +75,7 @@ IPF can be edited using INAV Configurator user interface, or via CLI. To use COn
| 26 | Invert Roll | Inverts ROLL axis input for PID/PIFF controller |
| 27 | Invert Pitch | Inverts PITCH axis input for PID/PIFF controller |
| 28 | Invert Yaw | Inverts YAW axis input for PID/PIFF controller |
| 29 | Override Throttlw | Override throttle value that is fed to the motors by mixer. Operand is scaled in us. `1000` means throttle cut, `1500` means half throttle |
| 29 | Override Throttle | Override throttle value that is fed to the motors by mixer. Operand is scaled in us. `1000` means throttle cut, `1500` means half throttle |
| 30 | Set VTx Band | Sets VTX band. Accepted values are `1-5` |
| 31 | Set VTx Channel | Sets VTX channel. Accepted values are `1-8` |
| 32 | Set OSD Layout | Sets OSD layout. Accepted values are `0-3` |
@ -94,11 +94,11 @@ IPF can be edited using INAV Configurator user interface, or via CLI. To use COn
| 45 | Flight Axis Angle Override | Sets the target attitude angle for axis. In other words, when active, it enforces Angle mode (Heading Hold for Yaw) on this axis (Angle mode does not have to be active). `Operand A` defines the axis: `0` - Roll, `1` - Pitch, `2` - Yaw. `Operand B` defines the angle in degrees |
| 46 | Flight Axis Rate Override | Sets the target rate (rotation speed) for axis. `Operand A` defines the axis: `0` - Roll, `1` - Pitch, `2` - Yaw. `Operand B` defines the rate in degrees per second |
| 47 | Edge | Momentarily true when triggered by `Operand A`. `Operand A` is the activation operator [`boolean`], `Operand B` _(Optional)_ is the time for the edge to stay active [ms]. After activation, operator will return `true` until the time in Operand B is reached. If a pure momentary edge is wanted. Just leave `Operand B` as the default `Value: 0` setting. |
| 48 | Delay | Delays activation after being triggered. This will return `true` when `Operand A` _is_ true, and the delay time in `Operand B` [ms] has been exceeded. |
| 48 | Delay | Delays activation after being triggered. This will return `true` when `Operand A` _is_ true, and has been true for the last `Operand B` [ms]. |
| 49 | Timer | A simple on - off timer. `true` for the duration of `Operand A` [ms]. Then `false` for the duration of `Operand B` [ms]. |
| 50 | Delta | This returns `true` when the value of `Operand A` has changed by the value of `Operand B` or greater within 100ms. ( \|ΔA\| >= B ) |
| 51 | Approx Equals (A ~ B) | `true` if `Operand B` is within 1% of `Operand A`. |
| 52 | LED Pin PWM | Value `Operand A` from [`0` : `100`] starts PWM generation on LED Pin. See [LED pin PWM](LED%20pin%20PWM.md). Any other value stops PWM generation (stop to allow ws2812 LEDs updates in shared modes). |
| 52 | LED Pin PWM | Value `Operand A` from [`0` : `100`] PWM / PINIO generation on LED Pin. See [LED pin PWM](LED%20pin%20PWM.md). Any other value stops PWM generation (stop to allow ws2812 LEDs updates in shared modes). |
| 53 | Disable GPS Sensor Fix | Disables the GNSS sensor fix. For testing GNSS failure. |
| 54 | Mag calibration | Trigger a magnetometer calibration. |

2
docs/Safehomes.md
View file

@ -6,7 +6,7 @@ The "Home" position is used for the landing point when landing is enabled or in
For airplanes, the landing procedure is explained very well by Pawel Spychalski [here.](https://quadmeup.com/inav-1-8-automated-landing-for-fixed-wings/)
<img src="https://quadmeup.com/wp-content/uploads/2017/06/fixed-wing-landing-1024x683.png" width="600">
![Fixed wing loiter and descend](assets/images/loiter_and_descend.png)
One potential risk when landing is that there might be buildings, trees and other obstacles in the way as the airplance circles lower toward the ground at the arming point. Most people don't go the middle of the field when arming their airplanes.

34
docs/Serial.md
View file

@ -89,3 +89,37 @@ The allowable baud rates are as follows:
| 14 | 1500000 |
| 15 | 2000000 |
| 16 | 2470000 |
### Function numbers as of 2025
| Function | Number |
| -------------------------- | -------------------------------------------------- |
| NONE | 0, |
| MSP | (1 << 0), // 1 |
| GPS | (1 << 1), // 2 |
| UNUSED_3 | (1 << 2), // 4 //Was FUNCTION_TELEMETRY_FRSKY |
| TELEMETRY_HOTT | (1 << 3), // 8 |
| TELEMETRY_LTM | (1 << 4), // 16 |
| TELEMETRY_SMARTPORT | (1 << 5), // 32 |
| RX_SERIAL | (1 << 6), // 64 |
| BLACKBOX | (1 << 7), // 128 |
| TELEMETRY_MAVLINK | (1 << 8), // 256 |
| TELEMETRY_IBUS | (1 << 9), // 512 |
| RCDEVICE | (1 << 10), // 1024 |
| VTX_SMARTAUDIO | (1 << 11), // 2048 |
| VTX_TRAMP | (1 << 12), // 4096 |
| UNUSED_1 | (1 << 13), // 8192: former\ UAV_INTERCONNECT |
| OPTICAL_FLOW | (1 << 14), // 16384 |
| LOG | (1 << 15), // 32768 |
| RANGEFINDER | (1 << 16), // 65536 |
| VTX_FFPV | (1 << 17), // 131072 |
| ESCSERIAL | (1 << 18), // 262144: this is used for both SERIALSHOT and ESC_SENSOR telemetry |
| TELEMETRY_SIM | (1 << 19), // 524288 |
| FRSKY_OSD | (1 << 20), // 1048576 |
| DJI_HD_OSD | (1 << 21), // 2097152 |
| SERVO_SERIAL | (1 << 22), // 4194304 |
| TELEMETRY_SMARTPORT_MASTER | (1 << 23), // 8388608 |
| UNUSED_2 | (1 << 24), // 16777216 |
| MSP_OSD | (1 << 25), // 33554432 |

12
docs/VTOL.md
View file

@ -42,7 +42,7 @@ We highly value your feedback as it plays a crucial role in the development and
5. *(Optional)* **Automated Switching (RTH):**
- Optionally, set up automated switching in case of failsafe.
# STEP0: Load parameter preset/templates
# STEP 0: Load parameter preset/templates
Find a working diff file if you can and start from there. If not, select keep current settings and apply following parameter in cli but read description about which one to apply.
```
@ -113,7 +113,7 @@ set mc_iterm_relax = RPY
save
```
# STEP1: Configuring as a normal fixed-wing in Profile 1
# STEP 1: Configuring as a normal fixed-wing in Profile 1
1. **Select the fisrt Mixer Profile and PID Profile:**
- In the CLI, switch to the mixer_profile and pid_profile you wish to set first. You can also switch mixer_profile/pid_profile through gui if with aforementioned presets loaded.
@ -133,7 +133,7 @@ save
![Alt text](Screenshots/mixerprofile_fw_mixer.png)
# STEP2: Configuring as a Multi-Copter in Profile 2
# STEP 2: Configuring as a Multi-Copter in Profile 2
1. **Switch to Another Mixer Profile with PID Profile:**
- In the CLI, switch to another mixer_profile along with the appropriate pid_profile. You can also switch mixer_profile/pid_profile through gui if with aforementioned presets loaded.
@ -161,7 +161,7 @@ save
- Configure mixer ROLL/YAW mixing according to tail_sitting orientation in the tail_sitting MC mode. YAW axis is the trust axis.
- Conduct a bench test and see the orientation of the model changes in inav-configurator setup tab
# STEP3: Mode Tab Settings:
# STEP 3: Mode Tab Settings:
### We recommend using an 3-pos switch on you radio to activate these modes, So pilot can jump in or bell out at any moment.
### Here is a example, in the bottom of inav-configurator Modes tab:
![Alt text](Screenshots/mixer_profile.png)
@ -177,7 +177,7 @@ save
Conduct a bench test on the model (without props attached). The model can now switch between fixed-wing and multi-copter modes while armed. Furthermore, it is capable of mid-air switching, resulting in an immediate stall upon entering fixed-wing profile
# STEP4: Tilting Servo Setup (Recommended)
# STEP 4: Tilting Servo Setup (Recommended)
### Setting up the tilting servos to operate correclty is crucial for correct yaw control of the craft. Using the default setup works, but will most likely result in your craft crawling forward with evey yaw input.
The steps below describe how you can fine-tune the tilting servos such as to obtian the desired result.
@ -229,7 +229,7 @@ Optional Setup Step for Tilt Servos:
If you have set up the mixer as suggested in STEP1 and STEP2, you may have to deal with negative values for the mixer. You may wish to reverese a servo so that you don't have to deal with the negative signs. In that case, you may have to adjust the MIN and MAX values from point 4 again, so that your tilt servos are operating correctly. Check the operation of the servos once again for the YAW control in multicopter/tricipter mode as well as the horixontal position of the tilt servos in fixed-wing mode.
# STEP5: Transition Mixing (Multi-Rotor Profile)(Recommended)
# STEP 5: Transition Mixing (Multi-Rotor Profile)(Recommended)
### Transition Mixing is typically useful in multi-copter profile to gain airspeed in prior to entering the fixed-wing profile. When the `MIXER TRANSITION` mode is activated, the associated motor or servo will move according to your configured Transition Mixing.
Please note that transition input is disabled when a navigation mode is activated. The use of Transition Mixing is necessary to enable additional features such as VTOL RTH with out stalling.

BIN
docs/assets/images/Approach-Drawing-Side.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 38 KiB

Before After
Before After

BIN
docs/assets/images/led-as-pinio.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
docs/assets/images/loiter_and_descend.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 74 KiB

75
docs/development/Contributing.md Normal file
View file

@ -0,0 +1,75 @@
# You can help bring INAV forward!
INAV is a big project and fully community-driven. This is why we need you, to make INAV better with every release!
There are always many new features and fixes ready to go into INAV, contributed by a lot of developers. To ensure that
all quality standards are met, all these great additions need to be checked, tested and potentially fixed before we
can add them to the code. This is why we always need your help, to keep the standards high and our aircraft safe!
If you are a bit tech-savvy and curious to try new things in the hobby you are invited to join us and help with the development.
Also, if you are good at writing in English, you are welcome to help with the documentation.
## How are changes made in INAV? (Testing and reviewing pull requests)
Most changes done to INAV are done by what’s called a “pull request”, or “PR”. Each month, there are about 30 pull
requests - 30 new features or fixes added to INAV.
Each is waiting for someone
to test them, or update the related documentation, or just look over the code. If you are curious about what's coming,
then have a look at the [INAV Pull Requests](https://github.com/iNavFlight/inav/pulls)
And the ones for [Configurator](https://github.com/iNavFlight/inav-configurator/pulls)
Some of the ones ready to be tested are shown here:
[Testing Required](https://github.com/iNavFlight/inav/pulls?q=is%3Aopen+is%3Apr+label%3A"Testing+Required")
Some are just documentation updates and we’d like someone to review to see if you think it reads clearly and is accurate, such as these:
[Documentation
PRs](https://github.com/iNavFlight/inav/pulls?q=is%3Aopen+is%3Apr+label%3A"Review+needed"+label%3ADocumentation)
## Documentation Updates
Another important part of software development is the documentation. This is something that INAV has struggled with in the past, and we want to get better at it. Check the new features, read the description from the developer, and make sure proper documentation for any new feature is provided. Not enough information in the PR? Feel free to make the developers aware of it. You see potential in better guides or descriptions? You are welcome to add or change things, to make them more accessible for newcomers. It is often better for someone BESIDES the developer to write or at least review the documentation for a feature because we want it to be clear and understandable to someone who doesn't already fully understand it.
The better our documentation is, the higher the chance for people to test and try awesome new features. Also everyone has to spend less time asking and answering questions - asking for help or explaining things to people who struggle to understand. This helps reduce frustration all around.
You can edit the wiki pages directly on Github. Look for the "Edit" button at the top right of any INAV wiki page.
## Github “Issues”
Nothing is perfect. Sometimes bugs might still happen or sometimes a misunderstanding causes problems. This is what pops up in the Github "Issues". Every ticket that is opened there has to be checked by someone familiar with the topic. We have to validate if it could be a user error or an actual problem. Maybe it's a wish for a change or a feature that has to be discussed.
Any help with these tickets and their validation is appreciated. Keeping this part of the project organized and clean is essential, in order to not miss important things.
If you know what the user can do to fix the problem, you can provide the necessary help and we can close the issue. People tend to expect authoritative, accurate answers on Github, so it is often helpful to point the user to the right place in the docs, or check the documentation yourself if you're unsure, then help them.
If you suspect a potential bug, ask for any additional information that might be relevant and ideally, try to validate and replicate the issue. This makes the life of the developers much easier and allows us to provide a fix faster.
## It's all about PEOPLE (socials etc)
INAV is used on quadcopters, on planes, rovers, and boats, but really - INAV is for PEOPLE.
It's all about helping people enjoy the hobby. If you're a people person, your activity in the
Facebook groups, the Telegram group, and on the Discord are really appreciated. Some of the
developers writing the math-heavy code aren't social butterflies, so they aren't active on Facebook.
If you see someone posting about a problem and you can direct them how to post in Issue on the Github,
that's really helpful. Relaying information between Telegram, Facebook, Discord, and Github is appreciated.
If you have a web site or a Youtube channel, or are interested in building one, the resources are
really helpful to the people using INAV.
## Coders
We also need people who are familiar with either HTML and Javascript to help with new features and fixes in
Configurator, or C programmers for INAV features and fixes. Especially reviewing the changes that have already been
submitted. If you are an experienced programmer who is willing to spend some time and contribute to the project, even
better! Less experienced programmers can also contribute, with small fixes, but especially by *reviewing* code that is
submitted. If you can read code you may spot typos, or things that just don't seem to make sense. This is also a great
way to learn.
Keep in mind that we are not a corporation. No one will tell you what to do. You have an idea for a great new feature? Do it! You see something that is broken and you think you can fix? Feel free to fix it! You are unsure if your idea will be accepted? The core-developer team is always there to ask and discuss things and prevent unnecessary work.
## How to get started
You are welcome to join the [INAV Discord](https://discord.gg/peg2hhbYwN) if you would like to chat with other
contributors in real time. You can also just go directly to the pull requests, Issues, and Discussions on the INAV
[Github](https://github.com/iNavFlight/inav/) and start participating in the discussions.
Also, see the [Configurator Github](https://github.com/iNavFlight/inav-configurator/)
Or, feel free to update the [wiki](https://github.com/iNavFlight/inav/wiki)
To make your own pull requests to update the code or the documentation in the docs/ folder, the [Development.md](https://github.com/iNavFlight/inav/blob/master/docs/development/Development.md#using-git-and-github) page will walk you
through how to do that.
Let's all come together and make the best INAV possible!