From 8bbd42d9525eec2f6a269f8eeb1f6fa6719e529f Mon Sep 17 00:00:00 2001 From: Raphael Hunziker Date: Thu, 10 Sep 2026 08:23:28 +0200 Subject: [PATCH 1/4] docs: update MAVLink page for INAV 10.0 Port the current firmware documentation (docs/Mavlink.md on maintenance-10.x) into the user docs. The previous page still described the single-port mavlink_*_rate settings that no longer exist in 10.x. Adds an info box that points readers of older releases to the matching documentation version. --- docs/06-advanced-features/mavlink.mdx | 363 ++++++++++++++++++++------ 1 file changed, 284 insertions(+), 79 deletions(-) diff --git a/docs/06-advanced-features/mavlink.mdx b/docs/06-advanced-features/mavlink.mdx index 32bd3db..66da620 100644 --- a/docs/06-advanced-features/mavlink.mdx +++ b/docs/06-advanced-features/mavlink.mdx @@ -1,109 +1,314 @@ --- title: MAVLink -desciption: INAV's implementation of the MAVLink protocol. +description: INAV's implementation of the MAVLink protocol (INAV 10.0 and later). --- -## MAVLink INAV Implementation +:::info +This page describes the MAVLink implementation of INAV 10.0 and later. +Earlier releases used a single MAVLink port and the `mavlink_*_rate` settings without the `port1_` prefix. +Select the matching version of the documentation for those releases. +::: -INAV has a partial implementation of MAVLink that is intended primarily for simple telemetry and operation. -It supports RC, missions, telemetry and some features such as Guided mode; but it is very different from a compliant MAVLink spec vehicle such as Pixhawk or Ardupilot and important differences exist, as such it is not 100% compatible and cannot be expected to work the same way. The standard MAVLink header library is used in compilation. -## Fundamental differences from ArduPilot/PX4 +INAV has a selective but broad MAVLink implementation. +It is still not a drop-in MAVLink autopilot stack like ArduPilot or PX4, but it now covers much more than simple telemetry: multiport routing, mission upload/download, waypoint reached notifications, guided/navigation control, request-response services, RC override for MAVLink serial RX, high-latency mode, MSP-over-MAVLink tunnel, and native MLRS receiver integration. -- **No MAVLink parameter API**: INAV sends a single stub parameter and otherwise ignores parameter traffic. Configure the aircraft through the INAV Configurator or CLI instead. -- **Limited command support**: Commands that are not implemented are ignored. -- **Mission handling**: uploads are rejected while armed; mission items must use `MAV_FRAME_GLOBAL` (RTH items use `MAV_FRAME_MISSION`). -- **Mode reporting**: `custom_mode` approximates ArduPilot modes and may not match all INAV states. -- **Flow control expectations**: INAV honours `RADIO_STATUS.txbuf` to avoid overrunning radios; without it, packets are simply paced at 20 ms intervals. -- **Half-duplex etiquette**: when half-duplex is enabled, INAV waits one telemetry tick after any received frame before transmitting to reduce collisions. +INAV supports up to 4 concurrent MAVLink telemetry ports (`MAX_MAVLINK_PORTS`), one endpoint per serial port configured with `FUNCTION_TELEMETRY_MAVLINK`. -### Relevant CLI options +INAV builds against the checked-in generated `storm32` MAVLink headers/dialect bundle, which includes the native mLRS messages used by the implementation. +The STorM32 dialect is a superset of the ArduPilot and common message sets. -- `mavlink_sysid` - system ID used in every outbound packet (default 1), the system will only respond/act on packets addresses to their sysid. -- `mavlink_autopilot_type` - heartbeat autopilot ID (`GENERIC` or `ARDUPILOT`). -- `mavlink_version` - force MAVLink v1 when set to 1. -- Stream rates (Hz): `mavlink_ext_status_rate`, `mavlink_rc_chan_rate`, `mavlink_pos_rate`, `mavlink_extra1_rate`, `mavlink_extra2_rate`, `mavlink_extra3_rate`. Each group is polled up to 50 Hz; a rate of 0 disables the group. -- `mavlink_min_txbuffer` - minimum remote TX buffer level before sending when `RADIO_STATUS` provides flow control. -- `mavlink_radio_type` - scales `RADIO_STATUS` RSSI/SNR for **generic**, **ELRS**, or **SiK** links. +## Target support -## Supported Outgoing Messages +MAVLink is built only into targets with more than 512 KB of flash (STM32F405, STM32F745, STM32F765, STM32H743, AT32F435, etc.). +On 512 KB targets, which includes every STM32F722 and STM32F411 board, the whole subsystem is absent: no MAVLink telemetry, no MAVLink serial RX, and no MSP-over-MAVLink tunnel. +Everything described on this page applies only to the larger targets. -Messages are organized into MAVLink datastream groups. Each group sends **one message per trigger** at the configured rate: +## What INAV currently supports -- `SYS_STATUS`: Advertises detected sensors (gyro/accel/compass, baro, pitot, GPS, optical flow, rangefinder, RC, blackbox) and whether they are healthy. Includes main loop load, battery voltage/current/percentage, and logging capability. -- `RC_CHANNELS_RAW`: for v1, `RC_CHANNELS_SCALED`: for v2, Up to 18 input channels plus RSSI mapped to MAVLink units. -- `GPS_RAW_INT`: for GNSS fix quality, HDOP/VDOP, velocity, and satellite count when a fix (or estimated fix) exists. -- `GLOBAL_POSITION_INT`: couples GPS position with INAV's altitude and velocity estimates. -- `GPS_GLOBAL_ORIGIN`: broadcasts the current home position. -- `ATTITUDE`: Roll, pitch, yaw, and angular rates. -- `VFR_HUD`: with airspeed (if a healthy pitot is available), ground speed, throttle, altitude, and climb rate. -- `HEARTBEAT`: encodes arming state and maps INAV flight modes onto ArduPilot-style `custom_mode`: values (see mappings below). -- `BATTERY_STATUS`: with per-cell voltages (cells 11-14 in `voltages_ext`), current draw, consumed mAh/Wh, and remaining percentage when available. -- `SCALED_PRESSURE`: for IMU/baro temperature. -- `STATUSTEXT`: when the OSD has a pending system message; severity follows OSD attributes (notice/warning/critical). +- Multiport MAVLink telemetry on up to 4 serial ports, with per-port stream rates, radio type, and high-latency mode. +- Learned route discovery and forwarding between MAVLink ports based on `(sysid, compid) -> ingress port`. +- Stateful mission upload, download, clear, retry, persistence, `MISSION_CURRENT`, and `MISSION_ITEM_REACHED`. +- Guided / GCS-nav control via `MAV_CMD_DO_REPOSITION`, altitude changes, yaw changes, and selected `SET_POSITION_TARGET_*` messages. +- Request-response services including `PING`, `TIMESYNC`, `REQUEST_DATA_STREAM`, message interval control, version discovery, and indexed mode discovery. +- `RC_CHANNELS_OVERRIDE` for MAVLink serial RX setups. +- Per-port `HIGH_LATENCY2` mode. +- MSP-over-MAVLink tunnel using `TUNNEL` payload type `0x8001`. +- Native MLRS receiver integration using `MLRS_RADIO_LINK_STATS`, `MLRS_RADIO_LINK_INFORMATION`, and `MLRS_RADIO_LINK_FLOW_CONTROL`. -## Supported Incoming Messages +## Important differences and omissions -- `HEARTBEAT`: used to detect ADS‑B participants when `type` is `MAV_TYPE_ADSB`. -- `MISSION_COUNT`: starts an upload transaction (capped at `NAV_MAX_WAYPOINTS`). -- `MISSION_ITEM`: stores waypoints; rejects uploads while armed or with unsupported frames/sequence errors. -- `MISSION_REQUEST_LIST` / `MISSION_REQUEST`: download active mission items; returns `MISSION_ACK` on bad sequence. -- `MISSION_CLEAR_ALL`: clears stored mission. -- `COMMAND_INT` with `MAV_CMD_DO_REPOSITION` in -- `RC_CHANNELS_OVERRIDE` passes channel values to the MAVLink serial receiver backend. -- `RADIO_STATUS` updates remote TX buffer level and scales RSSI/SNR according to `mavlink_radio_type` (also feeds link stats for MAVLink RX receivers). -- `ADSB_VEHICLE` populates the internal traffic list when ADS‑B is enabled. -- `PARAM_REQUEST_LIST` elicits a stub `PARAM_VALUE` response so ground stations stop requesting parameters (INAV does not expose parameters over MAVLink). +- **No MAVLink parameter API**: INAV sends a single stub parameter and otherwise ignores parameter traffic. Configure the aircraft through the INAV Configurator or CLI instead. +- **Selective command support**: INAV implements a useful subset of MAVLink commands and ACKs unsupported commands as `UNSUPPORTED`. +- **Mission handling is partial**: uploads are rejected while armed except for legacy guided waypoint writes, mission frames are validated per command, and MSP mission parity gaps remain. +- **Mode reporting is approximate**: `custom_mode` is mapped to ArduPilot-style modes for compatibility and does not represent every INAV state exactly. +- **Single local component identity**: INAV always originates as `MAV_COMP_ID_AUTOPILOT1`; attached radios, GCSes, and companions are always remote components, never local per-port FC identities. +- **Flow control is per-port and opportunistic**: INAV uses remote TX buffer information from `RADIO_STATUS.txbuf`, or from `MLRS_RADIO_LINK_FLOW_CONTROL.txbuf` on MLRS links. Without flow-control input it falls back to blind 20 ms pacing. +- **Half-duplex etiquette still applies**: on a MAVLink serial RX port configured for `serialrx_halfduplex`, INAV waits one telemetry tick after a received frame before transmitting. +### Usage guidance -## Supported Commands +- If you rely on RC via MAVLink, set `receiver_type = SERIAL` and `serialrx_provider = MAVLINK`. The serial port carrying MAVLink RC override traffic must also be configured for MAVLink telemetry so the MAVLink parser is active on that link. +- If MAVLink RX and telemetry intentionally share one half-duplex wire, enable `serialrx_halfduplex` for that setup. +- Leave `mavlink_version = 2` unless you intentionally need MAVLink1 compatibility. Native MLRS messages, MSP tunnel, high-latency mode, `AUTOPILOT_VERSION`, and `PROTOCOL_VERSION` all depend on MAVLink2 behavior. +- SITL builds explicitly include MAVLink telemetry and MAVLink serial RX so this receiver path can be exercised in simulation. +- To reduce bandwidth, lower stream rates for groups you do not need, or disable them entirely by setting the rate to 0. +- If a GCS or companion needs telemetry on ports 2..4, explicitly request streams (`REQUEST_DATA_STREAM` or `MAV_CMD_SET_MESSAGE_INTERVAL`) because only heartbeat is enabled by default. +- If you depend on directed forwarding between links, ensure each remote endpoint transmits at least one frame early so route learning is populated. -Limited implementation of the Command protocol. +### Relevant CLI settings -- **COMMAND_INT**: - - `MAV_CMD_DO_REPOSITION`: sets the Follow Me/GCS Nav waypoint when in GCS NAV mode, supports only `MAV_FRAME_GLOBAL`, otherwise returns `DENIED` or `UNSUPPORTED`. +- `mavlink_sysid` - system ID used in every outbound packet (default 1); most inbound handlers only act on packets targeted to this system ID. +- `mavlink_autopilot_type` - heartbeat autopilot ID (`GENERIC` or `ARDUPILOT`). +- `mavlink_version` - MAVLink version to use (`2` by default, `1` only when forced for compatibility). +- Stream rates (Hz): each group is polled up to 50 Hz; a rate of 0 disables the group. These CLI rates exist for port 1 only; ports 2..4 have no configurable stream-rate settings and are controlled at runtime (see below). + - `mavlink_port1_ext_status_rate` + - `mavlink_port1_rc_chan_rate` + - `mavlink_port1_pos_rate` + - `mavlink_port1_extra1_rate` + - `mavlink_port1_extra2_rate` + - `mavlink_port1_extra3_rate` +- Port 1 uses configured CLI rates (`mavlink_port1_*_rate`). +- Ports 2..4 start with heartbeat only (1 Hz), all other streams disabled. +- `mavlink_port{1-4}_min_txbuffer` - minimum remote TX buffer level before sending when per-port flow-control information is available. +- `mavlink_port{1-4}_radio_type` - selects `GENERIC`, `ELRS`, `SIK`, or `MLRS`. `GENERIC` / `ELRS` / `SIK` use `RADIO_STATUS` interpretation; `MLRS` uses native `MLRS_RADIO_LINK_*` traffic on the RX-sharing MAVLink port. +- `mavlink_port{1-4}_high_latency` - turns on MAVLink `HIGH_LATENCY2` mode on that port. -## Mode mappings (INAV → MAVLink/ArduPilot) +## Local identity, compatibility, and advertised capabilities -INAV encodes `custom_mode` to translate INAV modes to ArduPilot copter or plane modes. Modes without a clear equivalent are omitted (`ENUM_END`). - -- **Multirotor profiles** - - ACRO / ACRO AIR → **ACRO** - - ANGLE / HORIZON / ANGLE HOLD → **STABILIZE** - - ALT HOLD → **ALT_HOLD** - - POS HOLD → **LOITER** - - POS HOLD + GCS NAV → **GUIDED** - - RTH → **RTL** - - MISSION → **AUTO** - - LAUNCH → **THROW** - - FAILSAFE → **RTL**, **LAND**, or no mapping depending on failsafe phase -- **Fixed-wing profiles** - - MANUAL → **MANUAL** - - ACRO / ACRO AIR → **ACRO** - - ANGLE → **FBWA** - - HORIZON / ANGLE HOLD → **STABILIZE** - - ALT HOLD → **FBWB** - - RTH → **RTL** - - MISSION → **AUTO** - - CRUISE → **CRUISE** - - LAUNCH → **TAKEOFF** - - FAILSAFE → **RTL**, **AUTO**, or no mapping depending on failsafe phase +- INAV always transmits as MAVLink component `MAV_COMP_ID_AUTOPILOT1`. +- The FC does not create local per-port MAVLink identities. Attached devices are learned as remote components from incoming traffic. +- `AUTOPILOT_VERSION` advertises ArduPilot-compatible flight software version `4.7.0`. +- When MAVLink2 is active, `AUTOPILOT_VERSION` advertises these protocol capabilities: + - `MAV_PROTOCOL_CAPABILITY_MAVLINK2` + - `MAV_PROTOCOL_CAPABILITY_MISSION_FLOAT` + - `MAV_PROTOCOL_CAPABILITY_MISSION_INT` + - `MAV_PROTOCOL_CAPABILITY_COMMAND_INT` + - `MAV_PROTOCOL_CAPABILITY_SET_POSITION_TARGET_LOCAL_NED` + - `MAV_PROTOCOL_CAPABILITY_SET_POSITION_TARGET_GLOBAL_INT` ## Datastream groups and defaults -Default rates (Hz) are shown; adjust with the CLI keys above. +Default rates (Hz) are shown; adjust with the CLI keys above for port 1. +Ports 2..N use a secondary startup profile (heartbeat at 1 Hz, other streams disabled). | Datastream group | Messages | Default rate | | --- | --- | --- | | `EXTENDED_STATUS` | `SYS_STATUS` | 2 Hz | -| `RC_CHANNELS` | `RC_CHANNELS_RAW` (v1) / `RC_CHANNELS_SCALED` (v2) | 1 Hz | +| `RC_CHANNELS` | `RC_CHANNELS_RAW` (v1) / `RC_CHANNELS` (v2) | 1 Hz | | `POSITION` | `GPS_RAW_INT`, `GLOBAL_POSITION_INT`, `GPS_GLOBAL_ORIGIN` | 2 Hz | -| `EXTRA1` | `ATTITUDE` | 3 Hz | -| `EXTRA2` | `VFR_HUD`, `HEARTBEAT` | 2 Hz | -| `EXTRA3` | `BATTERY_STATUS`, `SCALED_PRESSURE`, `STATUSTEXT` (when present) | 1 Hz | +| `EXTRA1` | `ATTITUDE` | 2 Hz | +| `EXTRA2` | `VFR_HUD` | 2 Hz | +| `HEARTBEAT` | `HEARTBEAT` | 1 Hz (independent of stream groups) | +| `EXT_SYS_STATE` | `EXTENDED_SYS_STATE` | 1 Hz (defaults to `mavlink_port1_extra3_rate`) | +| `EXTRA3` | `BATTERY_STATUS`, `SCALED_PRESSURE`, `SYSTEM_TIME`, `STATUSTEXT` (when present and not suppressed as an unchanged repeat) | 1 Hz | + +### Routing, forwarding, and local handling + +- INAV learns routes from incoming traffic as `(sysid, compid) -> ingress port`. +- Broadcast messages are forwarded to all other MAVLink ports except `RADIO_STATUS` and `MLRS_RADIO_LINK_FLOW_CONTROL`, which stay local to the ingress port. +- Targeted messages are forwarded only to ports with a learned route for that target. +- Practical caveat: the first targeted message to a never-seen endpoint may not forward until that endpoint has sent at least one MAVLink frame. +- INAV's local FC identity is always `(mavlink_sysid, MAV_COMP_ID_AUTOPILOT1)`. +- Traffic from the local system ID but a different component ID is treated as a remote component and can be learned into the route table. +- Local/system broadcasts (`target_system = 0` or local system ID with `target_component = 0`) are fanned out to all local ports only for: + - `REQUEST_DATA_STREAM` + - `MAV_CMD_SET_MESSAGE_INTERVAL` + - `MAV_CMD_CONTROL_HIGH_LATENCY` +- Other incoming commands/messages are handled once on the resolved local ingress path, but broadcast-targeted control requests still execute locally. + +### Reconnect and status re-announcement + +INAV tracks each remote peer's presence from its `HEARTBEAT` frames, keyed per `(sysid, compid)` route entry rather than per port. +A peer counts as having just (re)connected on a port when INAV sees its first heartbeat, a heartbeat after a gap of more than 5 seconds, or a heartbeat that has moved to a different port (failover). +On such a (re)connect INAV: + +- resets that port's `STATUSTEXT` de-spam state, so the next OSD/system message is sent immediately instead of waiting out the repeat interval, and +- re-sends the current arming-disable reason to that port, independent of whether the global arming-disable flags have changed, rate-limited to once per 10 seconds per port. + +If the route table is full when a new peer first appears, reconnect detection for that peer degrades gracefully to the broadcast-only behavior (no per-peer re-announcement). + +## Native MLRS receiver integration + +When `mavlink_port{1-4}_radio_type = MLRS`, INAV uses native receiver-emitted MLRS messages rather than treating `RADIO_STATUS` as the real MLRS data source. + +- INAV expects `MLRS_RADIO_LINK_STATS`, `MLRS_RADIO_LINK_INFORMATION`, and `MLRS_RADIO_LINK_FLOW_CONTROL`. +- These messages are accepted only from `MAV_COMP_ID_TELEMETRY_RADIO`. +- `MLRS_RADIO_LINK_STATS` and `MLRS_RADIO_LINK_INFORMATION` must target the local system. `target_component` may be `0` or `MAV_COMP_ID_AUTOPILOT1`. +- INAV stores MLRS runtime state per ingress MAVLink port and clears that state with the normal port lifecycle. +- Only the ingress port that is also the active MAVLink serial RX port may update the global `rxLinkStatistics`. +- `MLRS_RADIO_LINK_STATS` feeds: + - RC link quality into `uplinkLQ` + - serial link quality into `downlinkLQ` + - RSSI, SNR, and active antenna into the receiver stats model +- `MLRS_RADIO_LINK_INFORMATION` feeds: + - mode and band strings + - TX/RX power + - receive sensitivity metadata +- `MLRS_RADIO_LINK_FLOW_CONTROL` applies only to the ingress port's pacing / TX-buffer runtime state and is not forwarded to other MAVLink ports. +- `RADIO_STATUS` remains the generic / legacy radio path for non-MLRS links (`GENERIC`, `ELRS`, `SIK`) and should not be treated as the real MLRS integration path. + +## Supported outgoing messages + +Messages are organized into MAVLink datastream groups. +Each group sends one message per trigger at the configured rate. + +- `SYS_STATUS`: advertises detected sensors (gyro/accel/compass, baro, pitot, GPS, optical flow, rangefinder, RC, blackbox) and whether they are healthy. Includes main loop load, battery voltage/current/percentage, and logging capability. +- `RC_CHANNELS_RAW` (v1) / `RC_CHANNELS` (v2): up to 18 input channels plus RSSI mapped to MAVLink units. +- `GPS_RAW_INT`: GNSS fix quality, HDOP/VDOP, velocity, satellite count, and receiver-native ellipsoid altitude and accuracy extensions when available. +- `GLOBAL_POSITION_INT`: GPS position plus INAV altitude and velocity estimates. +- `GPS_GLOBAL_ORIGIN`: current home position. +- `ATTITUDE`: roll, pitch, yaw, and angular rates. +- `VFR_HUD`: airspeed (if a healthy pitot is available), ground speed, throttle, altitude, and climb rate. +- `HEARTBEAT`: arming state plus ArduPilot-style `custom_mode` mapping from INAV flight modes. +- `EXTENDED_SYS_STATE`: landed-state reporting. +- `BATTERY_STATUS`: per-cell voltages (cells 11-14 in `voltages_ext`), current draw, consumed mAh/Wh, and remaining percentage when available. +- `SCALED_PRESSURE`: baro pressure and temperature data. +- `SYSTEM_TIME`: boot time plus RTC Unix time when the RTC is valid. +- `STATUSTEXT`: pending OSD/system messages, changed arming-disable reasons, and flight-mode transitions. OSD/system messages carry a mapped severity (NOTICE by default, WARNING when the source OSD element is inverted, CRITICAL when it blinks); arming-disable and mode notices are always sent at NOTICE severity. Repeated OSD-derived status text is suppressed per MAVLink port; changed text is sent immediately, while unchanged notice/warning/critical messages are re-announced at progressively shorter severity-based intervals (30 s / 10 s / 5 s). Changed arming-disable reasons are broadcast to every enabled port as `Arming disabled: `. INAV flight-mode transitions are broadcast as notices in the form `Notice: INAV: Entering `, with explicit `Notice: INAV: Entering GCS NAV mode` / `Notice: INAV: Exiting GCS NAV mode` transitions while GCS-assisted navigation engages or ends. See [Reconnect and status re-announcement](#reconnect-and-status-re-announcement) for how these are re-sent when a peer (re)connects. +- `MISSION_CURRENT`: broadcast at 1 Hz with mission count, current item, execution mode, and mission state. +- `MISSION_ITEM_REACHED`: sent when navigation reports a mission waypoint reached and broadcast to all enabled MAVLink ports. +- `AUTOPILOT_VERSION`: on request, advertises ArduPilot-compatible version `4.7.0` and the capabilities listed above (MAVLink2 only). +- `PROTOCOL_VERSION`: on request, reports the configured MAVLink protocol version (MAVLink2 only). +- `MESSAGE_INTERVAL`: reply payload for `MAV_CMD_GET_MESSAGE_INTERVAL`. +- `HOME_POSITION`: on request, when a home fix exists. +- `AVAILABLE_MODES`, `AVAILABLE_MODES_MONITOR`, `CURRENT_MODE`: optional MAVLink Standard Modes microservice messages, available only when built with `USE_MAVLINK_STANDARD_MODES`. + +## Supported incoming messages + +- `HEARTBEAT`: used to detect ADS-B participants when `type` is `MAV_TYPE_ADSB`. +- `PING`: broadcast requests are echoed to the requesting system/component. +- `TIMESYNC`: broadcast or locally targeted requests receive the local boot time in nanoseconds. +- `MISSION_COUNT`: starts an upload transaction. Stored INAV waypoints remain capped at `NAV_MAX_WAYPOINTS`; the upload transaction also allows QGC planned-home and non-storage command items. The owning system/component and ingress port are retained for the transaction. +- `MISSION_ITEM` / `MISSION_ITEM_INT`: stores mission waypoints; rejects unsupported frames / sequence errors. Upload while armed is rejected except legacy guided waypoint writes. +- `MISSION_REQUEST_LIST`, `MISSION_REQUEST`, `MISSION_REQUEST_INT`: stateful mission download with partner checks and one-item retransmission support. +- `MISSION_ACK`: completes an active mission download. +- `MISSION_CLEAR_ALL`: clears the runtime and saved mission. +- `COMMAND_LONG` / `COMMAND_INT`: command transport for supported `MAV_CMD_*` handlers. +- `REQUEST_DATA_STREAM`: legacy stream-rate control per stream group. +- `SET_POSITION_TARGET_GLOBAL_INT`: writes the GCS-guided waypoint when the frame is supported; altitude-only requests are also accepted when X/Y are masked out and GCS navigation is valid. +- `SET_POSITION_TARGET_LOCAL_NED`: accepts altitude-only requests in `MAV_FRAME_LOCAL_OFFSET_NED` when X/Y are zero or ignored and GCS navigation is valid. +- `RC_CHANNELS_OVERRIDE`: passes channel values to the MAVLink serial receiver backend. +- `MLRS_RADIO_LINK_STATS`: native MLRS per-port link stats from `MAV_COMP_ID_TELEMETRY_RADIO`, with local target-system / target-component checks. +- `MLRS_RADIO_LINK_INFORMATION`: native MLRS per-port link metadata from `MAV_COMP_ID_TELEMETRY_RADIO`, with local target-system / target-component checks. +- `MLRS_RADIO_LINK_FLOW_CONTROL`: native MLRS per-port flow-control input from `MAV_COMP_ID_TELEMETRY_RADIO`; applied only to the ingress port runtime. +- `RADIO_STATUS`: updates remote TX buffer level and generic / legacy link stats according to `mavlink_port{1-4}_radio_type`. This remains the non-MLRS radio path. +- `ADSB_VEHICLE`: populates the internal traffic list when ADS-B is enabled. +- `PARAM_REQUEST_LIST`: elicits a stub `PARAM_VALUE` response so ground stations stop requesting parameters. +- `TUNNEL`: accepts private payload type `0x8001` for MSP-over-MAVLink on MAVLink2 links. + +## Supported commands + +INAV implements a selective but useful subset of the MAVLink Command protocol. +Unsupported commands are ACKed as `UNSUPPORTED`. + +- `MAV_CMD_COMPONENT_ARM_DISARM`: arms through the normal INAV arming checks or disarms with `DISARM_SWITCH`. The ACK is accepted only when the requested armed state is reached. +- `MAV_CMD_NAV_RETURN_TO_LAUNCH`: enters the normal INAV RTH mode path while armed by adding a temporary `BOXNAVRTH` mode source to the normal RC mode selector. RTH altitude, safehome, landing, and fixed-wing autoland behavior remain controlled by the existing INAV configuration. This does not set the failsafe/geozone forced-RTH latch; a later pilot RC flight-mode change or disarm clears the temporary source. +- `MAV_CMD_DO_SET_MODE`: supports the ArduPilot-style RTL/RTH custom-mode request and routes it to the same normal RTH mode path as `MAV_CMD_NAV_RETURN_TO_LAUNCH`. It also accepts the ArduPilot Loiter/PosHold pause modes (`PLANE_MODE_LOITER`, `COPTER_MODE_LOITER`, `COPTER_MODE_POSHOLD`, `COPTER_MODE_BRAKE`) and enters normal INAV PosHold at the current position and altitude. Other mode changes remain unsupported. +- `MAV_CMD_NAV_LAND`: while armed with usable navigation estimates, creates a transient LAND waypoint at the current position and enters the same normal landing path used by a mission `NAV_WP_ACTION_LAND`. It does not use emergency landing and does not modify the uploaded mission. Command location fields are ignored; mission items retain their supplied landing position. +- `MAV_CMD_DO_SET_HOME`: writes the existing INAV waypoint `0` home through `setWaypoint(0, ...)`. `param1 = 1` uses the current GNSS position; `param1 = 0` uses the supplied global location. The existing WP#0 gates still apply: armed state, usable position estimate, valid GPS origin, and GCS-assisted navigation enabled. +- `MAV_CMD_DO_REPOSITION`: sets the Follow Me / GCS-nav waypoint when GCS nav is valid. Accepts `MAV_FRAME_GLOBAL`, `MAV_FRAME_GLOBAL_INT`, `MAV_FRAME_GLOBAL_RELATIVE_ALT`, and `MAV_FRAME_GLOBAL_RELATIVE_ALT_INT`; otherwise `UNSUPPORTED`. `param3` is the optional fixed-wing PosHold loiter-radius override in meters; `0` clears the temporary override back to `nav_fw_loiter_radius`, and `NaN` leaves it unchanged. `param4`, when finite and in the range `0`–`360`, sets a target heading for the reposition point; other values leave the heading unset. +- `MAV_CMD_DO_CHANGE_ALTITUDE`: changes the current altitude target. `param1` is the target altitude in meters and `param2` is interpreted as the MAVLink frame (`MAV_FRAME_GLOBAL`, `MAV_FRAME_GLOBAL_INT`, `MAV_FRAME_GLOBAL_RELATIVE_ALT`, `MAV_FRAME_GLOBAL_RELATIVE_ALT_INT`); unsupported frames are rejected. +- `MAV_CMD_CONDITION_YAW`: changes the current heading target when the active navigation state has yaw control. Accepts absolute heading (`param4 = 0`) and relative turns (`param4 != 0`); turn rate is ignored. +- `MAV_CMD_SET_MESSAGE_INTERVAL` / `MAV_CMD_GET_MESSAGE_INTERVAL`: adjust or query per-message periodic output for `HEARTBEAT`, `SYS_STATUS`, `EXTENDED_SYS_STATE`, RC channels, `GPS_RAW_INT`, `GLOBAL_POSITION_INT`, `GPS_GLOBAL_ORIGIN`, `ATTITUDE`, `VFR_HUD`, `BATTERY_STATUS`, `SCALED_PRESSURE`, and `SYSTEM_TIME`. `REQUEST_DATA_STREAM` still controls the legacy base stream groups; `SET_MESSAGE_INTERVAL` overrides individual messages on top. +- `MAV_CMD_GET_HOME_POSITION`: replies with `HOME_POSITION` when a home fix exists. +- `MAV_CMD_REQUEST_MESSAGE`: emits one selected message or `UNSUPPORTED`. `MESSAGE_INTERVAL` uses `param2` as the queried message ID. When built with `USE_MAVLINK_STANDARD_MODES`, `AVAILABLE_MODES` uses `param2` as its one-based index and `AVAILABLE_MODES_MONITOR` is also supported. +- `MAV_CMD_REQUEST_AUTOPILOT_CAPABILITIES`: returns `AUTOPILOT_VERSION` (MAVLink2 only; MAVLink1 returns `UNSUPPORTED`) advertising ArduPilot-compatible version `4.7.0` and the capabilities listed above. +- `MAV_CMD_REQUEST_PROTOCOL_VERSION`: returns `PROTOCOL_VERSION` (MAVLink2 only; MAVLink1 returns `UNSUPPORTED`). +- `MAV_CMD_CONTROL_HIGH_LATENCY`: enables or disables `HIGH_LATENCY2` scheduling on the ingress MAVLink port (`param1 = 0` or `1`). Enabling is rejected on MAVLink1 links. + +`MAV_CMD_NAV_TAKEOFF` has an explicit command stub and currently returns `UNSUPPORTED`. + +## Mode mappings (INAV -> MAVLink / ArduPilot) + +`custom_mode` is derived from active INAV telemetry flight mode (`getFlightModeForTelemetry()`), then mapped per vehicle type. +The default ArduPilot-compatible path reports modes through `HEARTBEAT.custom_mode`. +The MAVLink Standard Modes microservice is separate and disabled unless the firmware is built with `USE_MAVLINK_STANDARD_MODES`; if enabled, GUIDED is reported as a named non-standard mode because MAVLink common standard modes do not define a GUIDED enum. + +- **Multirotor profiles** + - ACRO / ACRO AIR -> **ACRO** + - ANGLE / HORIZON / ANGLE HOLD -> **STABILIZE** + - ALT HOLD -> **ALT_HOLD** + - POS HOLD -> **GUIDED** (if GCS valid), otherwise **POSHOLD** + - RTH -> **RTL** + - MISSION -> **AUTO** + - LAUNCH -> **THROW** + - FAILSAFE -> **RTL** (RTH / other phases) or **LAND** (landing phase) + - Any other unmapped mode falls back to **STABILIZE** +- **Fixed-wing profiles** + - MANUAL -> **MANUAL** + - ACRO / ACRO AIR -> **ACRO** + - ANGLE -> **FBWA** + - HORIZON / ANGLE HOLD -> **STABILIZE** + - ALT HOLD -> **FBWB** + - POS HOLD -> **GUIDED** (if GCS valid), otherwise **LOITER** + - RTH -> **RTL** + - MISSION -> **AUTO** + - CRUISE -> **CRUISE** + - LAUNCH -> **TAKEOFF** + - FAILSAFE -> **RTL** (RTH / other phases) or **AUTOLAND** (landing phase) + - Any other unmapped mode falls back to **MANUAL** + +## MAVLink missions + +INAV supports MAVLink mission upload, download, clear, live mission-state reporting, and waypoint-reached notifications. +Uploads retry the outstanding request every 1.5 seconds and abort after five unsuccessful retries. +Downloads time out after five seconds of inactivity. +Only the system/component and ingress port that started a transfer may continue it. +Completed uploads and clears update nonvolatile waypoint storage on targets that provide it. +Mission downloads always reply with `MISSION_ITEM_INT`, including in response to a legacy float `MISSION_REQUEST`. + +Mission upload is staged before it touches the live INAV waypoint list. +The MAVLink stream is translated into a temporary INAV mission, validated, and committed only after the full upload succeeds, so rejected uploads do not leave a half-written mission in the FC. +QGC planned home item `0` is skipped because INAV stores home separately; MAVLink sequence `1` becomes INAV waypoint `1`. + +The upload translator handles MAVLink mission items that are modifiers rather than standalone INAV waypoints. +`MAV_CMD_NAV_WAYPOINT` stores a normal waypoint, or `POSHOLD_TIME` when hold time is set. +`MAV_CMD_NAV_LOITER_TIME` stores `POSHOLD_TIME`; `MAV_CMD_NAV_LAND` stores `LAND`; `MAV_CMD_DO_JUMP` stores `JUMP` with its target remapped after translation. +`MAV_CMD_NAV_RETURN_TO_LAUNCH` stores `RTH` (with the land-after-RTH flag and, for coordinate frames, an altitude); `MAV_CMD_DO_SET_ROI` (with `MAV_ROI_LOCATION`) stores `SET_POI`; `MAV_CMD_CONDITION_YAW` stores `SET_HEAD`. +`MAV_CMD_DO_CHANGE_SPEED` sets a pending leg speed for following geographic waypoints. +`MAV_CMD_CONDITION_DELAY`, `MAV_CMD_CONDITION_CHANGE_ALT`, and `MAV_CMD_DO_CHANGE_ALTITUDE` modify the previous applicable geographic waypoint instead of consuming an INAV waypoint slot. + +The implementation works with common MAVLink mission planners such as QGC for simple mission flows. +However, the differences between MAVLink missions and INAV's fuller MSP navigation model mean MAVLink still cannot represent every INAV mission feature. +Use MultiWii Planner or the INAV Configurator when you need full MSP mission semantics. + +:::warning +A mission downloaded over MAVLink is a best-effort reconstruction from INAV's stored MSP waypoint list, not a reliable canonical mission source. +Downloaded items can differ from the original uploaded plan in item count, sequence numbers, command shape, modifier placement, and MSP-specific fields. +Keep the original mission plan outside the FC and verify important missions through MSP / INAV-native tooling. +::: + +## MSP mission parity gaps (MAVLink and MSP) + +- WAYPOINT: MSP->MAV sends lat/lon/alt but drops leg speed `p1` and all user-action bits in `p3` (only alt-mode bit drives frame). MAV->MSP stores lat/lon/alt, can apply pending leg speed into `p1`, and keeps only alt-mode bit in `p3`; user bits are lost. +- POSHOLD_TIME / LOITER_TIME: loiter time `p1` OK; pending leg speed can be stored in `p2` on upload. User-action bits in `p3` are discarded both directions. +- LAND: lat/lon/alt OK. As with WAYPOINT, a pending `DO_CHANGE_SPEED` leg speed can be written into `p1` on upload, but leg speed is dropped on download. Ground elevation `p2` and user-action bits in `p3` are cleared in both directions (only the alt-mode bit is retained from frame on upload). +- RTH: the land-after-RTH flag in `p1` is captured on upload (`p1 = 1` when `MAV_CMD_NAV_RETURN_TO_LAUNCH param1 > 0`) but dropped on download (always sent as `0`), so it does not survive a round trip; user-action bits dropped; alt is sent only if the MAVLink frame is a coordinate frame, and returns with the alt-mode bit set on upload. +- JUMP: target and repeat count OK. +- SET_POI: lat/lon/alt OK; `param1` is fixed to `MAV_ROI_LOCATION`; user-action bits in `p3` are dropped (alt-mode bit respected on upload). +- SET_HEAD: heading `p1` OK; user-action bits in `p3` are not represented. +- Net effect: actions and positions OK, but MSP-specific fields (leg speed, LAND elevation adjustment, RTH land flag, user-action bits in `p3`) do not survive a MAV -> MSP -> MAV round trip — some are captured on upload, but downloads drop them — so MAVLink missions cannot fully represent INAV's native MSP waypoint model (see the `wp` field definitions in [Navigation.md](https://github.com/iNavFlight/inav/blob/master/docs/Navigation.md#cli-command-wp-to-manage-waypoints)). + +## MSP over MAVLink tunnel + +This feature uses the MAVLink [Tunnel service](https://mavlink.io/en/services/tunnel.html) to let the INAV Configurator use MSP over an existing MAVLink telemetry link, typically a radio link where there is no separate wireless MSP device. +**It is not intended as a general-purpose serial tunnel, and it is not a replacement for normal MAVLink control / telemetry traffic.** +CLI mode is unavailable in MSP-over-MAVLink. + +- INAV accepts `TUNNEL` messages with private payload type `0x8001` as an MSP byte stream carried over MAVLink2. +- `target_system` must match `mavlink_sysid`. +- `target_component` may be `0` or `MAV_COMP_ID_AUTOPILOT1`. +- `target_component = 0` is handled on the ingress MAVLink port only; it is not fanned out to other local MAVLink ports. +- MSP replies are sent back to the requester as one or more `TUNNEL` messages on that same ingress port. +- MSP framing is preserved end-to-end: MSPv1 requests get MSPv1 replies, and MSPv2 requests get MSPv2 replies. +- Reboot (`MSP_REBOOT`) is supported over the tunnel. Serial passthrough and ESC 4way passthrough are rejected before execution. + +## High latency mode -## Operating tips +High-latency mode uses the MAVLink [High Latency service](https://mavlink.io/en/services/high_latency.html) to replace normal scheduled telemetry on one port with periodic `HIGH_LATENCY2` summaries for very low-bandwidth or intermittent links. -- Set `mavlink_radio_type` to **ELRS** or **SiK** if you use those links to get accurate link quality scaling in `RADIO_STATUS`. -- If you rely on RC override via MAVLink, ensure the serial receiver type is set to `SERIALRX_MAVLINK` and consider enabling `telemetry_halfduplex` when RX shares the port. -- To reduce bandwidth, lower the stream rates for groups you do not need, or disable them entirely by setting the rate to 0. \ No newline at end of file +- High latency mode is per-port, controlled by `mavlink_port{1-4}_high_latency` or by `MAV_CMD_CONTROL_HIGH_LATENCY` received on that port. +- It requires MAVLink2. MAVLink1 cannot enable or carry `HIGH_LATENCY2`. +- When enabled on a port, normal stream scheduling on that port is replaced by `HIGH_LATENCY2` at 5 second intervals. +- This is intended for slow and high-latency telemetry such as cellular, satellite, or LoRa, not for normal rich telemetry, mission planning, or configurator use. From d50a5a45206cae40d05720efca264b9279697bd5 Mon Sep 17 00:00:00 2001 From: Raphael Hunziker Date: Thu, 10 Sep 2026 08:23:29 +0200 Subject: [PATCH 2/4] docs: load the CLI reference from the matching firmware ref The CLI Variables page fetched Settings.md from tag 9.0.1 for both the next docs and the 9.1.0 docs. RemoteMarkdown now accepts branch names as well as release tags (a ref starting with a digit is a tag), caches only tags, and the pages use maintenance-10.x (next) and 9.1.0 respectively. --- docs/cli.mdx | 2 +- src/components/RemoteMarkdown.tsx | 15 +++++++++++---- versioned_docs/version-9.1.0/cli.mdx | 2 +- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/docs/cli.mdx b/docs/cli.mdx index 7b31e80..847d9e8 100644 --- a/docs/cli.mdx +++ b/docs/cli.mdx @@ -5,4 +5,4 @@ sidebar_position: 100 import RemoteMarkdown from '@site/src/components/RemoteMarkdown'; - \ No newline at end of file + \ No newline at end of file diff --git a/src/components/RemoteMarkdown.tsx b/src/components/RemoteMarkdown.tsx index 96997e5..3434fc1 100644 --- a/src/components/RemoteMarkdown.tsx +++ b/src/components/RemoteMarkdown.tsx @@ -11,6 +11,10 @@ interface RemoteMarkdownProps { } const DEFAULT_TAG = 'master'; + +// A ref starting with a digit is treated as a release tag (e.g. "9.1.0"). +// Anything else is treated as a branch (e.g. "master", "maintenance-10.x"). +const isReleaseTag = (ref: string): boolean => /^[0-9]/.test(ref); const CACHE_PREFIX = 'remote-markdown-'; interface CacheData { @@ -48,7 +52,7 @@ const setCachedData = (tag: string, markdown: string, html: string) => { }; const constructUrl = (tag: string): string => { - const ref = tag === 'master' ? 'refs/heads/master' : `refs/tags/${tag}`; + const ref = isReleaseTag(tag) ? `refs/tags/${tag}` : `refs/heads/${tag}`; return `https://raw.githubusercontent.com/iNavFlight/inav/${ref}/docs/Settings.md`; }; @@ -72,8 +76,9 @@ const RemoteMarkdown: React.FC = ({ setLoading(true); setError(null); - // Check cache for non-master tags - if (tag !== 'master') { + // Release tags never change, so they can be served from the cache. + // Branches move, so they are always fetched fresh. + if (isReleaseTag(tag)) { const cached = getCachedData(tag); if (cached && cached.tag === tag) { if (isMounted) { @@ -102,7 +107,9 @@ const RemoteMarkdown: React.FC = ({ setMarkdown(source); setHtml(rendered); - setCachedData(tag, source, rendered); + if (isReleaseTag(tag)) { + setCachedData(tag, source, rendered); + } } catch (err) { const message = err instanceof Error ? err.message : String(err); if (isMounted) { diff --git a/versioned_docs/version-9.1.0/cli.mdx b/versioned_docs/version-9.1.0/cli.mdx index 7b31e80..71cb2ad 100644 --- a/versioned_docs/version-9.1.0/cli.mdx +++ b/versioned_docs/version-9.1.0/cli.mdx @@ -5,4 +5,4 @@ sidebar_position: 100 import RemoteMarkdown from '@site/src/components/RemoteMarkdown'; - \ No newline at end of file + \ No newline at end of file From 7bd13e3977520819bdeba781973c355462c3f520 Mon Sep 17 00:00:00 2001 From: Raphael Hunziker Date: Thu, 10 Sep 2026 08:23:29 +0200 Subject: [PATCH 3/4] docs: fix broken links, stale setting names and typos - Replace wiki and firmware-repo links with the internal pages that exist now (failsafe, navigation modes, compass, GPS, mixer, battery, RTH, PID tuning). - Fix the download link in System Preparation and the reversed mixer link in the Outputs tab page. - Use the real CLI setting names: failsafe_off_delay, servo_lpf_hz, nav_mc_hover_thr, nav_wp_max_safe_distance, airmode_throttle_threshold. - Fix the sidebar_position front matter typo in the multirotor setup guide. - Refresh version examples (9.1.0 / Configurator 9.1.1) on the Welcome and Install pages. - Programming framework operation 52 is PINIO PWM in 10.x; update the row and link to the new firmware document. - Spelling pass over all pages (codespell plus a dictionary check) and removal of doubled words. --- docs/01-welcome.mdx | 18 +++++------ docs/02-release-notes.mdx | 24 +++++++-------- .../01-hardware-overview.mdx | 14 ++++----- .../02-system-preparation.mdx | 2 +- docs/03-getting-started/03-install-inav.mdx | 6 ++-- .../04-accel-calibration.mdx | 2 +- .../06-mr-gettingstarted.mdx | 30 +++++++++---------- .../fw_gettingstartedguide/01-overview.mdx | 6 ++-- .../fw_gettingstartedguide/02-fwsetup.mdx | 10 +++---- .../alignment-tool-tab.mdx | 2 +- docs/04-inav-configurator/calibration-tab.mdx | 4 +-- docs/04-inav-configurator/mixer-tab.mdx | 2 +- docs/04-inav-configurator/outputs-tab.mdx | 4 +-- docs/04-inav-configurator/receiver-tab.mdx | 4 +-- docs/05-core-features/battery.mdx | 4 +-- docs/05-core-features/blackblox.mdx | 6 ++-- docs/05-core-features/buzzer.mdx | 2 +- docs/05-core-features/compass.mdx | 6 ++-- .../fixed-wing-autolaunch.mdx | 6 ++-- .../flight-modes-navigation.mdx | 8 ++--- .../flight-modes-standard.mdx | 8 ++--- docs/05-core-features/gps.mdx | 4 +-- .../inav-for-betaflight-users.mdx | 2 +- docs/05-core-features/led-strips.mdx | 14 ++++----- docs/05-core-features/mixer.mdx | 8 ++--- docs/05-core-features/osd.mdx | 8 ++--- docs/05-core-features/rth.mdx | 6 ++-- docs/05-core-features/stick-controls.mdx | 4 +-- .../fixed-wing-autoland.mdx | 10 +++---- .../gps-fix-estimation.mdx | 20 ++++++------- .../lightweight-telemetry.mdx | 4 +-- .../msp-navigation-messages.mdx | 2 +- .../programming-framework.mdx | 28 ++++++++--------- .../remote-management-control-telemetry.mdx | 2 +- docs/06-advanced-features/vtol.mdx | 28 ++++++++--------- .../navigation-pid-tuning-fw.mdx | 12 ++++---- .../navigation-pid-tuning-mc.mdx | 6 ++-- .../pid-attentuation-and-scaling.mdx | 2 +- docs/08-mission-control/geozones.mdx | 8 ++--- docs/08-mission-control/safehomes.mdx | 4 +-- docs/08-mission-control/waypoint-missions.mdx | 8 ++--- src/components/HomepageFeatures/index.tsx | 2 +- src/pages/download.tsx | 2 +- 43 files changed, 176 insertions(+), 176 deletions(-) diff --git a/docs/01-welcome.mdx b/docs/01-welcome.mdx index ba0869c..3d1a0a3 100644 --- a/docs/01-welcome.mdx +++ b/docs/01-welcome.mdx @@ -19,11 +19,11 @@ The software suite consists of the following components: ## How to Use The Docs The docs have been structured in as logical manner as possible. -It is advisible for all newcomers to INAV to visit the Getting Started section to learn how INAV works and setup an aircraft. +It is advisable for all newcomers to INAV to visit the Getting Started section to learn how INAV works and setup an aircraft. ### Getting Started -This section is where all newcomers should visit to get acquianted with INAV. +This section is where all newcomers should visit to get acquainted with INAV. It provides all the fundamental information for understanding key concepts and getting an aircraft configured for flight. The sections are organized sequentially and should be followed in order. @@ -52,8 +52,8 @@ C -- Forked --> E; ``` In the beginning, there were no off-the-shelf flight controllers that were plug and play ready for your quad or plane. -The multirotor hobby began during the Ninentdo Wii era when the accessibility of inexpensive accelerometer and gyro sensors from the Wiimote Nunchucks inspired intrepid electronics hackers to repurpose them with Arduinos for multirotor flight controls - thus the MultiWii flight controller software was born. -The deveopment and popularity of MultiWii FC led to commercially available products like the KK/2.0 series. +The multirotor hobby began during the Nintendo Wii era when the accessibility of inexpensive accelerometer and gyro sensors from the Wiimote Nunchucks inspired intrepid electronics hackers to repurpose them with Arduinos for multirotor flight controls - thus the MultiWii flight controller software was born. +The development and popularity of MultiWii FC led to commercially available products like the KK/2.0 series. Because MultiWii was based around the Arduino ATmega328, limitations were quickly reached with what could be done due to limited memory. Allegedly, the former MultiWii flight controller rush led a small electronics company called Zhuque Intelligent New Shenzhen Co. Ltd to use their surplus STM32F103 to develop a multirotor flight controller called Freeflight, which ran their own firmware. @@ -75,11 +75,11 @@ This system makes it easy to see which versions of INAV are compatible. The version number is made up of 3 sections, separated by dots. These are major.minor.patch. -So with **INAV 7.1.2**: +So with **INAV 9.1.0**: -- **7** is the major version number +- **9** is the major version number - **1** is the minor version number -- **2** is the patch version number +- **0** is the patch version number Both the firmware and Configurator follow the same versioning scheme. The major version numbers match. @@ -88,7 +88,7 @@ This does not have to be a big change or new feature. It can be something as simple as adding a new symbol on the OSD (due to the font update) or changing or removing a CLI parameter. When the major version number is increased, the minor and patch version numbers are reset to 0. -**Minor** version numbers are increased when a a feature is added or updated that does not break backwards compatibility. +**Minor** version numbers are increased when a feature is added or updated that does not break backwards compatibility. This can be complete new features, even new CLI parameters. When the minor version number is increased, the patch version number is reset to 0. @@ -97,4 +97,4 @@ When the minor version number is increased, the patch version number is reset to With INAV you must match the major version number of the [firmware](https://github.com/iNavFlight/inav) and [Configurator](https://github.com/iNavFlight/inav-configurator). This has been the case for a long time, even pre-SemVer. Before SemVer, the major and minor version numbers also had to be matched. -Now, it is recommended to use the latest version of Configurator that has the same major version number of your firmware. For example with firmware 7.0.0 it is recommended to use Configurator 7.1.2. +Now, it is recommended to use the latest version of Configurator that has the same major version number of your firmware. For example with firmware 9.0.1 it is recommended to use Configurator 9.1.1. diff --git a/docs/02-release-notes.mdx b/docs/02-release-notes.mdx index 8888107..ee28832 100644 --- a/docs/02-release-notes.mdx +++ b/docs/02-release-notes.mdx @@ -54,7 +54,7 @@ Due to GNSS data processing losses than occur when `gps_ublox_nav_hz` is set hig In general, **lower** UBLOX update rates will allow your GNSS module to provide better position accuracy when **more** constellations are selected. But there is also a trade-off. The update positions will becoming more broadly spread-out at higher flight speeds. Changes can be made in the _Configurator GPS Tab_ to suit your hardware and flight requirements. -Read [PR](https://github.com/iNavFlight/inav/pull/11262) , [Issue](https://github.com/iNavFlight/inav/issues/11202#issue-3758761282) and [GPS and Compass setup](https://github.com/iNavFlight/inav/wiki/GPS-and-Compass-setup#gnss-ublox-update-rate) for more information on the topic if required. +Read [PR](https://github.com/iNavFlight/inav/pull/11262) , [Issue](https://github.com/iNavFlight/inav/issues/11202#issue-3758761282) and [GNSS Ublox Update Rate](./05-core-features/gps.mdx#gnss-ublox-update-rate) for more information on the topic if required. ### Multicopter set magless heading @@ -77,7 +77,7 @@ Relevant commits - [#11270 ](https://github.com/iNavFlight/inav/pull/11270) , [# - The handling of the OSD STATS after disarming has been improved. CRSF RX data is now being displayed. As well as the `Saving Setting` and `Disarmed by` advisories are again working correctly on HD. [link](https://github.com/iNavFlight/inav/pull/11506) - System message updates and improvements have been added for Surface mode and Geozones. [link](https://github.com/iNavFlight/inav/pull/11425) -- Simplification of the OSD [Multifunction](https://github.com/iNavFlight/inav/wiki/Modes#multi-function) mode tools operation. With the addition of battery Voltage and Capacity, Pitot failure and Compass calibration. +- Simplification of the OSD [Multifunction](./05-core-features/flight-modes-standard.mdx#multi-function) mode tools operation. With the addition of battery Voltage and Capacity, Pitot failure and Compass calibration. - If multicopter compass deviation occurs (toilet bowling) in Poshold, a system message warning is displayed until the mode is cancelled. [link](https://github.com/iNavFlight/inav/pull/10854) ### Other changes @@ -293,12 +293,12 @@ Please follow the instructions on [this](https://github.com/iNavFlight/inav/wiki ### Fixedwing airspeed APA and pitch angle enhanced TPA support -Fixeding aircraft can now use a pitot sensor or virtual airspeed to dynamically adjust the PIDFF gains inflight. This adds the advantage of a tighter stabilization response across the whole flight speed envelope. -Full details of setup and tuning can be found [here](https://github.com/iNavFlight/inav/wiki/PID-Attenuation-and-scaling). Under the topics `APA` and `TPA and Pitch angle`. +Fixedwing aircraft can now use a pitot sensor or virtual airspeed to dynamically adjust the PIDFF gains inflight. This adds the advantage of a tighter stabilization response across the whole flight speed envelope. +Full details of setup and tuning can be found [here](./07-pid-tuning/pid-attentuation-and-scaling.mdx). Under the topics `APA` and `TPA and Pitch angle`. ### Minimum ground speed flexibility -Via the [Programming Framework](https://github.com/iNavFlight/inav/blob/master/docs/Programming%20Framework.md). It allows the user to have more flexibility when flying in higher wind conditions. To ensure the airplane makes headway. +Via the [Programming Framework](./06-advanced-features/programming-framework.mdx). It allows the user to have more flexibility when flying in higher wind conditions. To ensure the airplane makes headway. In addition, you can program it to dynamically adjust the minimum ground speed according to the Wind direction and Wind speed. More information can be found in this [link](https://github.com/iNavFlight/inav/pull/10720). @@ -314,7 +314,7 @@ Changes have been made to improve its operation on a broader range of airframes. - Altitude Velocity controller `nav_fw_alt_use_position = OFF` (default) - Altitude Position controller `nav_fw_alt_use_position = ON` -See [here]() for more information. And the _required_ PID tune settings for either control method. +See [here](./07-pid-tuning/navigation-pid-tuning-fw.mdx#altitude-control-methods) for more information. And the _required_ PID tune settings for either control method. ### Position estimator improvements @@ -345,7 +345,7 @@ QMC5883P magnetometer driver - Improved yaw estimation for magless multicopter operation. [PR link](https://github.com/iNavFlight/inav/pull/11114) - _The default `ahrs_acc_ignore_rate` setting has also been lowered from 20 to 15._ - Mavlink clean-ups and fixes - [11060](https://github.com/iNavFlight/inav/pull/11060) [11061](https://github.com/iNavFlight/inav/pull/11061) [11062](https://github.com/iNavFlight/inav/pull/11062) - MSP changes - [11146](https://github.com/iNavFlight/inav/pull/11146) [11171](https://github.com/iNavFlight/inav/pull/11171) [11093](https://github.com/iNavFlight/inav/pull/11093) [11032](https://github.com/iNavFlight/inav/pull/11032) [10571](https://github.com/iNavFlight/inav/pull/10571) [11099](https://github.com/iNavFlight/inav/pull/11099) -- JavaScript support tab for INAV programming framework. [PR link](https://github.com/iNavFlight/inav/pull/11143) [Docs update](https://github.com/iNavFlight/inav/blob/master/docs/Programming%20Framework.md#javascript-based-programming-alternative) +- JavaScript support tab for INAV programming framework. [PR link](https://github.com/iNavFlight/inav/pull/11143) [Docs update](./06-advanced-features/programming-framework.mdx#javascript-based-programming-alternative) ### OSD/CMS changes @@ -374,7 +374,7 @@ The **Minimum Ground Speed** and **Throttle Gauge** additions to the OSD require | Programming Framework | Minimum Ground Speed [m/s] | The current minimum ground speed allowed in navigation flight modes | | Programming Framework | Horizontal Wind Speed [cm/s] | Estimated wind speed. If the wind estimator is unavailable or the wind estimation is invalid, -1 is returned | | Programming Framework | Wind Direction [deg] | Estimated wind direction. If the wind estimator is unavailable or the wind estimation is invalid, -1 is returned | -| Programming Framework | Relative Wind Offset [deg] | The relative offset between the heading of the aircraft and the heading of the wind. 0 indicates flying directly into a headwing. Negative numbers are a left offset. For example, if -20° is shown, turning right will correct towards 0. If the wind estimator is unavailable or the wind estimation is invalid, 0 is returned | +| Programming Framework | Relative Wind Offset [deg] | The relative offset between the heading of the aircraft and the heading of the wind. 0 indicates flying directly into a headwind. Negative numbers are a left offset. For example, if -20° is shown, turning right will correct towards 0. If the wind estimator is unavailable or the wind estimation is invalid, 0 is returned | ## CLI @@ -390,14 +390,14 @@ The first three CLI settings have been renamed or changed in INAV 9.0. When load | [mixer_control_profile_linking](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#mixer_control_profile_linking) | Renames old `mixer_pid_profile_linking` | | [osd_pan_servo_range_decadegrees](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#osd_pan_servo_range_decadegrees) | Renames old `osd_pan_servo_pwm2centideg` | | [blackbox_arm_control](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#blackbox_arm_control) | Can extend blackbox logging up to 60 seconds after disarming | -| [acc_temp_correction](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#acc_temp_correction) | Accelerometer temperature correction factor to compensate for acceleromter drift | +| [acc_temp_correction](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#acc_temp_correction) | Accelerometer temperature correction factor to compensate for accelerometer drift | | [baro_temp_correction](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#baro_temp_correction) | Baro temperature correction factor to compensate for Baro altitude drift | | [osd_adsb_warning_style](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#osd_adsb_warning_style) | ADSB warning element style - COMPACT or EXTENDED | | [nav_fw_alt_use_position](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_alt_use_position) | Use position for fixed wing altitude control rather than velocity | | [mavlink_autopilot_type](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#mavlink_autopilot_type) | Sets the Mavlink telemetry type - GENERIC or ARDUPILOT | -| [transition_pid_mmix_multiplier_pitch](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#transition_pid_mmix_multiplier_pitch) | Intended to solve pitch coupling in transtion mode on tilting rotor VTOL | -| [transition_pid_mmix_multiplier_roll](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#transition_pid_mmix_multiplier_roll) | intended to solve roll/yaw coupling oscillation in transtion mode on tilting rotor VTOL | -| [transition_pid_mmix_multiplier_yaw](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#transition_pid_mmix_multiplier_yaw) | Intended to solve yaw/roll coupling oscillation in transtion mode on tilting rotor VTOL | +| [transition_pid_mmix_multiplier_pitch](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#transition_pid_mmix_multiplier_pitch) | Intended to solve pitch coupling in transition mode on tilting rotor VTOL | +| [transition_pid_mmix_multiplier_roll](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#transition_pid_mmix_multiplier_roll) | intended to solve roll/yaw coupling oscillation in transition mode on tilting rotor VTOL | +| [transition_pid_mmix_multiplier_yaw](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#transition_pid_mmix_multiplier_yaw) | Intended to solve yaw/roll coupling oscillation in transition mode on tilting rotor VTOL | | [apa_pow](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#apa_pow) | Sets the strength and speed range of dynamic airspeed PID scaling | | [tpa_pitch_compensation](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#tpa_pitch_compensation) | Sets the strength which pitch angle will override the throttle dynamic PID scaling | diff --git a/docs/03-getting-started/01-hardware-overview.mdx b/docs/03-getting-started/01-hardware-overview.mdx index d2c8d91..f2ecab6 100644 --- a/docs/03-getting-started/01-hardware-overview.mdx +++ b/docs/03-getting-started/01-hardware-overview.mdx @@ -19,7 +19,7 @@ This section outlines the components needed depending on the kind of build. - Flight controller - Radio control link receiver -INAV can function without any extra sensors and be used as a simple flight stablization system. +INAV can function without any extra sensors and be used as a simple flight stabilization system. This can be useful for certain visual line of sight flying (VLOS). ### Navigation Essentials @@ -39,7 +39,7 @@ In addition to everything in [Navigation Essentials](./01-hardware-overview.mdx# - Camera compatible with VTX system There are now a multitude of video systems for FPV available. -These range from the inexpesive, old, but still widely used analog video systems to digital systems such as DJI, Caddx Walksnail, Caddx Ascent, Betafpv P1, and OpenIPC. +These range from the inexpensive, old, but still widely used analog video systems to digital systems such as DJI, Caddx Walksnail, Caddx Ascent, Betafpv P1, and OpenIPC. :::info It is possible to fly FPV without a GPS, but is not recommended. @@ -102,7 +102,7 @@ A popular example of single board FC is the AtomRC F405 Navi as pictured below:
Credit: AtomRC
These FCs typically contain all the hardware needed to power and wire up hardware needed for fixed wings. -Since fixed wings in the hobby are usually single or twin motors, the electronic speed controllers (ESC) for the motors will have to be sourced seperately and soldered onto the specified pads on the FC. +Since fixed wings in the hobby are usually single or twin motors, the electronic speed controllers (ESC) for the motors will have to be sourced separately and soldered onto the specified pads on the FC. Whether single board or stacked, all will contain a PCB layer that's flat bottomed and intended to be used as a mounting surface. @@ -110,7 +110,7 @@ Whether single board or stacked, all will contain a PCB layer that's flat bottom Flight Controllers are typically equipped with accelerometers. These devices are sensitive to shocks. When the device is not yet installed to an aircraft, it has very little mass by itself. -If you drop or bump the controller, a big force will be applied on the interal components of the accelerometer, which could potentially damage them. +If you drop or bump the controller, a big force will be applied on the internal components of the accelerometer, which could potentially damage them. **Bottom line: Handle the board very carefully until it's installed on an aircraft!** ::: @@ -153,12 +153,12 @@ As an illustrated example, the wiring guide for the AtomRC F405 Navi is shown be
Credit: AtomRC
#### Power Wires -Powers wires from the battery and to the ESC(s), should be a thicker gauage wire. +Powers wires from the battery and to the ESC(s), should be a thicker gauge wire. Depending on the size of the aircraft, a good starting point for average, parkflier sized aircraft is 16awg to 14awg. It's also a good idea to mount a capacitor on the battery pad. The capacitor is provided in FC packaging along with the wiring accessories for all the peripherals. -There are two ways to mount the capacitor: directly on with the legs or slightly discretly using wire extensions. +There are two ways to mount the capacitor: directly on with the legs or slightly discreetly using wire extensions. For larger builds that have bigger motors and more current flow, 12awg is a good idea. Keep in mind the servos' current draw is within limits of the FC's servo BEC, otherwise the servos will have to be powered with an external voltage regulator. @@ -167,7 +167,7 @@ Keep in mind the servos' current draw is within limits of the FC's servo BEC, ot ### Flight Controller (FC) -Multicopter FCs are fairly standarized and come in three distinct form factors: +Multicopter FCs are fairly standardized and come in three distinct form factors: - 30.5mm stack - 20mm stack - 25mm AIO stack diff --git a/docs/03-getting-started/02-system-preparation.mdx b/docs/03-getting-started/02-system-preparation.mdx index ce06fa0..67a8bb6 100644 --- a/docs/03-getting-started/02-system-preparation.mdx +++ b/docs/03-getting-started/02-system-preparation.mdx @@ -63,4 +63,4 @@ sudo usermod -aG dialout $USER ## Download INAV Configurator -The Configurator can now be [downloaded](../../../download) and installed for your relevant operating system from the Github releases page of INAV Configurator. +The Configurator can now be [downloaded](/download) and installed for your relevant operating system from the Github releases page of INAV Configurator. diff --git a/docs/03-getting-started/03-install-inav.mdx b/docs/03-getting-started/03-install-inav.mdx index 765537b..8bfdb28 100644 --- a/docs/03-getting-started/03-install-inav.mdx +++ b/docs/03-getting-started/03-install-inav.mdx @@ -27,7 +27,7 @@ Flashing INAV is all done on the Firmware Flasher tab in Configurator: ### Brand New FC or FC with Other Firmware :::info -While you can flash older versions of INAV, Configurator is meant to work with the version of INAV of the same major version (INAV Configurator 9.0.2 is for all version of INAV 9) +While you can flash older versions of INAV, Configurator is meant to work with the version of INAV of the same major version (INAV Configurator 9.1.1 is for all versions of INAV 9) ::: A brand new FC will not have any firmware on it so it will need to be started in DFU mode. @@ -39,7 +39,7 @@ It will either be on the FC itself or on a daughter board for some fixed wing FC Select that target name in the first drop down menu. 1. Then select the version you wish to install. 1. Ensure the box that says "No Reboot Sequence" is enabled -1. In the bottom right corner of the Configurator, selct "Load Firmware [Online]" and then "Flash". +1. In the bottom right corner of the Configurator, select "Load Firmware [Online]" and then "Flash". INAV will show a progress bar that indicates it is flashing. ### Upgrading a FC With INAV Already Installed @@ -53,7 +53,7 @@ Settings from an older major version of the firmware will not always carry over 1. Navigate to the Firmware Flasher tab. 1. The FC should automatically be identified with its respective target. 1. Select the version you wish to install and ensure "No Reboot Sequence" is disabled. -1. Load the firware online and flash. +1. Load the firmware online and flash. ## Post Install diff --git a/docs/03-getting-started/04-accel-calibration.mdx b/docs/03-getting-started/04-accel-calibration.mdx index e2a0a86..65a3765 100644 --- a/docs/03-getting-started/04-accel-calibration.mdx +++ b/docs/03-getting-started/04-accel-calibration.mdx @@ -51,7 +51,7 @@ There is no need to place the model perfectly aligned, the algorithm does not ca If the FC board is rotated in any way that differs from its default orientation markings, the board alignment settings must be changed to match (_see the "Alignment Tool" tab in the INAV configurator_). -You can verify the correct board orientation by banking your your aircraft left and right, forward and back and rotate left and right. +You can verify the correct board orientation by banking your aircraft left and right, forward and back and rotate left and right. In all examples the 3D model image in configurator **must** move accordingly. Accelerometer calibration **does not** record a leveled model. diff --git a/docs/03-getting-started/06-mr-gettingstarted.mdx b/docs/03-getting-started/06-mr-gettingstarted.mdx index 4aa40c7..b75e1e1 100644 --- a/docs/03-getting-started/06-mr-gettingstarted.mdx +++ b/docs/03-getting-started/06-mr-gettingstarted.mdx @@ -1,6 +1,6 @@ --- title: Multirotor Setup Guide -sidebar_posiiton: 6 +sidebar_position: 6 --- > [!NOTE] @@ -20,11 +20,11 @@ If the type of model you have is not under the presets. Go to the `Mixer Tab` an Many of the more common mixers are available here. (Tri, Hex, Octo etc) Press **Load and Apply** to make your choice. For less common mixer types, see [Custom mixes for exotic setups](https://github.com/iNavFlight/inav/wiki/Custom-mixes-for-exotic-setups#setups-that-can-be-implemented-with-custom-mixer). -Other Mixer related information can also be found [here](https://github.com/iNavFlight/inav/wiki/Mixer-Tab) and [here](https://github.com/iNavFlight/inav/blob/master/docs/Mixer.md). +Other Mixer related information can also be found on the [Mixer Tab](../04-inav-configurator/mixer-tab.mdx) and [Mixer](../05-core-features/mixer.mdx) pages. * Go to the `Calibration Tab` and follow the instructions given to perform an `Accelerometer Calibration`. Run the advanced 6-point [sensor calibration](./04-accel-calibration.mdx). -* If you use a magnetometer (recommended), it will also require setup in the `Alignment Tool Tab` and `Calibration Tab`. More specific information with regards to Flight Controller / Magnetometer alignment and calibration can be under [GPS and Compass setup](https://github.com/iNavFlight/inav/wiki/GPS-and-Compass-setup). +* If you use a magnetometer (recommended), it will also require setup in the `Alignment Tool Tab` and `Calibration Tab`. More specific information with regards to Flight Controller / Magnetometer alignment and calibration can be found on the [Compass](../05-core-features/compass.mdx) and [GPS](../05-core-features/gps.mdx) pages. You may need to attach a battery for magnetometer calibration if your GNSS/mag module is not powered by the FCs 4.5v USB pins. * Once the above is complete. Make sure the Copter moves identical to the virtual image in the `Status Tab`. @@ -43,26 +43,26 @@ The `Motor Mixer Wizard` in the `Mixer Tab` can be used to allocate a motor outp ## 2. Setup failsafe and a couple of important navigation settings -Adjusting these setting won't take long, but they are often overlooked in setup consquently leading to poor navigation performance or a crash landing in a Failsafe condition. +Adjusting these settings won't take long, but they are often overlooked in setup consequently leading to poor navigation performance or a crash landing in a Failsafe condition. -* `nav_mc_hover_thr` - Please read [here](https://github.com/iNavFlight/inav/wiki/Navigation-modes#using-althold-with-a-multicopter-mc) for a more detailed explanation of why it is important to adjust this setting. +* `nav_mc_hover_thr` - Please read [here](../05-core-features/flight-modes-navigation.mdx#using-althold-with-a-multicopter-mc) for a more detailed explanation of why it is important to adjust this setting. -* `failsafe_throttle` and `failsafe_of_delay` - Please read through this short explanation [here](https://github.com/iNavFlight/inav/wiki/Failsafe#configuration-of-inav) to help understand why adjusting these settings is required. +* `failsafe_throttle` and `failsafe_off_delay` - Please read through this short explanation [here](../04-inav-configurator/failsafe-tab.mdx#configuration-of-inav) to help understand why adjusting these settings is required. -[Guide for setting up failsafe](https://github.com/iNavFlight/inav/wiki/Failsafe#setting-up-failsafe-for-rth) +[Guide for setting up failsafe](../04-inav-configurator/failsafe-tab.mdx#setting-up-failsafe-for-rth) -More advanced MC operation and tuning information can be found under [Navigation modes](https://github.com/iNavFlight/inav/wiki/Navigation-modes) and -[Navigation PID tuning (MC)](https://github.com/iNavFlight/inav/wiki/Navigation-PID-tuning-(MC)). +More advanced MC operation and tuning information can be found under [Navigation modes](../05-core-features/flight-modes-navigation.mdx) and +[Navigation PID tuning (MC)](../07-pid-tuning/navigation-pid-tuning-mc.mdx). ## 3. Tune your copter's Pitch/Roll/Yaw/Level PIDs and other values INAV multicopter tuning can be made easier for new users with [EZ-Tune](https://github.com/iNavFlight/inav/wiki/EZ%E2%80%90TUNE). When you load a platform preset after flashing your hardware, multicopter EZ-Tune will be enabled by default in the Tuning Tab. -If you wish to run your own tun, turn it off using the EZ-Tune ENABLED button. +If you wish to run your own tune, turn it off using the EZ-Tune ENABLED button. :::tip -The default presets many not always be correct due to the influence your selected hardware can have upon the PID tune such as frame type, motors, props, battery etc. +The default presets may not always be correct due to the influence your selected hardware can have upon the PID tune such as frame type, motors, props, battery etc. > **Example:** A lower powered 5" cruiser running on a 3 cell battery, will generally require a different tune from a 5" race quad running on a 6 cell battery. > The reason being is because the 6s quad will provide far more impulse thrust per weight for the PID controller to work with. Actually making tuning easier. But often requires some of the gains to be lower from the default, because the PID setpoint error can be dealt with much faster. ::: @@ -95,7 +95,7 @@ Overlooking this step can cause your battery to become over discharged during th Continually discharging lithium chemistry batteries below 20% of their rated capacity under higher loads can reduce its capacity and also shorten the batteries life expectancy. ::: -More in-depth battery setup information can be found [here](https://github.com/iNavFlight/inav/blob/master/docs/Battery.md). +More in-depth battery setup information can be found on the [Battery](../05-core-features/battery.mdx) page. ## 5. Selecting filters @@ -135,13 +135,13 @@ The gyro filters are placed in the order of importance found from flight experie ### Mechanical Filter Optimization -Mechnically removing vibrations will have the most effect in reducing noise. +Mechanically removing vibrations will have the most effect in reducing noise. - Use silicon vibration dampeners for your flight controller. - Do not tighten the stack bolts too tight. -This will crush the dampener, reducing their ability to adsorb vibrations. Only tighten them firm enough to stop movement. You may have to use thread lock to prevent the nuts coming loose. +This will crush the dampener, reducing their ability to absorb vibrations. Only tighten them firm enough to stop movement. You may have to use thread lock to prevent the nuts coming loose. ## 6. Get to know the CLI values. INAV offers a lot of customization through CLI variables. -It is strongly recommended to read through [CLI Variable reference](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md) and [available CLI variables](https://github.com/iNavFlight/inav/blob/master/docs/Cli.md) \ No newline at end of file +It is strongly recommended to read through [CLI Variable reference](../cli.mdx) and [available CLI variables](https://github.com/iNavFlight/inav/blob/master/docs/Cli.md) \ No newline at end of file diff --git a/docs/03-getting-started/fw_gettingstartedguide/01-overview.mdx b/docs/03-getting-started/fw_gettingstartedguide/01-overview.mdx index 2c6da47..cf314c9 100644 --- a/docs/03-getting-started/fw_gettingstartedguide/01-overview.mdx +++ b/docs/03-getting-started/fw_gettingstartedguide/01-overview.mdx @@ -45,8 +45,8 @@ RCRX --> RCTX: Telemetry ## Core Concepts -INAV has the ability to fly many differnt kinds of airplanes. -There are conventional high wing/low wing, flying wings, electric ducted fan jets, sailplanes, multi motor configurations, differetial thrust setups, and more. +INAV has the ability to fly many different kinds of airplanes. +There are conventional high wing/low wing, flying wings, electric ducted fan jets, sailplanes, multi motor configurations, differential thrust setups, and more. Regardless of the kind of airplane, they all operate on several key principles needed for flight. ### Forces @@ -79,7 +79,7 @@ As speed increases, drag does as well. **Weight** is caused by the force of gravity pulling the mass of the aircraft down. The weight of the aircraft is the primary cause of this. The center of gravity is related to the weight as it can be considered the center of weight of the aircraft, resulting in where it will pivot in the air. -FPV platforms with large batteries may not always result in significantly longer flight itmes as the airframe will be fighting the additional weight. +FPV platforms with large batteries may not always result in significantly longer flight times as the airframe will be fighting the additional weight. ### Angle of Attack diff --git a/docs/03-getting-started/fw_gettingstartedguide/02-fwsetup.mdx b/docs/03-getting-started/fw_gettingstartedguide/02-fwsetup.mdx index 3e51b55..15e24ae 100644 --- a/docs/03-getting-started/fw_gettingstartedguide/02-fwsetup.mdx +++ b/docs/03-getting-started/fw_gettingstartedguide/02-fwsetup.mdx @@ -15,7 +15,7 @@ The main parts of this page are: 1. [Wiring](./02-fwsetup.mdx#hooking-everything-up) 1. [Software Configuration](./02-fwsetup.mdx#inav-configuration) -## Prerequsites +## Prerequisites 1. Have [INAV Configurator](../02-system-preparation.mdx) installed and working. 1. [Flash the FC](../03-install-inav.mdx#flash-inav-to-the-fc) with its firmware through INAV Configurator @@ -45,7 +45,7 @@ The mixer tab in INAV Configurator where this setting is configured is shown bel 1. **Timer Outputs** - shows the available timers and their functions. By default, all timers are set as `AUTO`. -To manually set the fuction, click the dropdown. +To manually set the function, click the dropdown. The available functions are: MOTOR, SERVO, and LED. 1. **Output Mapping** - is a table that shows which timers in Box 1 are mapped to which motor and/or servos. @@ -54,7 +54,7 @@ The available functions are: MOTOR, SERVO, and LED. To add a motor, press *Add new mixer rule* and a new motor index will automatically populate the table. -1. **Servo Mixer** - is wher servo outputs are mapped to their respective pins. +1. **Servo Mixer** - is where servo outputs are mapped to their respective pins. Just like a motor, press *Add new mixer rule* and a new servo index will automatically populate the table. :::tip @@ -98,7 +98,7 @@ Digital video systems are connected to a UART, typically one that is paired with ## INAV Configuration After the airplane is physically wired up, the next step is to configure everything in software using INAV Configurator. -At this stage, the FC should have had its accelerometer calibrated as descibed in the earlier [Acceleromter Calibration Page](../04-accel-calibration.mdx). +At this stage, the FC should have had its accelerometer calibrated as described in the earlier [Accelerometer Calibration Page](../04-accel-calibration.mdx). The proceeding subsections will outline how to configure the rest of INAV to have a working airplane. Each subsection is titled based off the respective tab in INAV Configurator and should be followed sequentially. @@ -152,7 +152,7 @@ Before continuing any further, now is a good time to configure the receiver to e 1. Assuming that a CRSF based serial receiver was used during the FC wiring steps and that the wiring diagram was followed for the respective FC used, assign the UART that the receiver is connected to as RX in the Ports tab in INAV Configurator. Save and reboot. -1. Then head to the Reciever tab and select receiver type as *Serial*. +1. Then head to the Receiver tab and select receiver type as *Serial*. After rebooting, the Receiver tab will show the working channels that it is receiving from the radio. diff --git a/docs/04-inav-configurator/alignment-tool-tab.mdx b/docs/04-inav-configurator/alignment-tool-tab.mdx index d662fd7..1957771 100644 --- a/docs/04-inav-configurator/alignment-tool-tab.mdx +++ b/docs/04-inav-configurator/alignment-tool-tab.mdx @@ -8,4 +8,4 @@ This is critical to setting up INAV. You may have mounted the FC upside-down or backwards and this is where you can save this new orientation. When you go back to the Setup Tab, you should see the 3D Graphic move the same as your actual aircraft. -![Alignemnt Tool Tab](/img/app/alignment-tool-tab.png) \ No newline at end of file +![Alignment Tool Tab](/img/app/alignment-tool-tab.png) \ No newline at end of file diff --git a/docs/04-inav-configurator/calibration-tab.mdx b/docs/04-inav-configurator/calibration-tab.mdx index 714de3d..638b793 100644 --- a/docs/04-inav-configurator/calibration-tab.mdx +++ b/docs/04-inav-configurator/calibration-tab.mdx @@ -44,7 +44,7 @@ There is no need to place the model perfectly aligned, the algorithm does not ca If you have your board rotated in any way, change board alignment to match (_see the "Alignment Tool" tab in the INAV configurator_). -You can verify the correct board orientation by banking your your aircraft left and right, forward and back and rotate left and right. +You can verify the correct board orientation by banking your aircraft left and right, forward and back and rotate left and right. In all examples the 3D model image in configurator **must** move accordingly. Accelerometer calibration **does not** record a leveled model. @@ -72,7 +72,7 @@ If not please follow the guide in [setting-up-the-compass-alignment](../05-core- When using an external magnetometer 9/10 times you need to physically remove (_remove chip from board or cut a trace_) the internal one if you have on. You can't use two identical chips/magnetometers on the same I2C bus. -The 1/10 time you dont need to physically remove your internal mag is when you have different magnetometers on the flight controller and the external one. +The 1/10 time you don't need to physically remove your internal mag is when you have different magnetometers on the flight controller and the external one. Example you cannot use two HMC5883L magnetometers. ### Performing the Calibration diff --git a/docs/04-inav-configurator/mixer-tab.mdx b/docs/04-inav-configurator/mixer-tab.mdx index 7c1a67e..a65ee1b 100644 --- a/docs/04-inav-configurator/mixer-tab.mdx +++ b/docs/04-inav-configurator/mixer-tab.mdx @@ -16,7 +16,7 @@ This allows for a giant variety of motor and control surface configurations to b The intent of INAV is to fly your aircraft either in partial or full navigation modes. As such, all Modern radios have the ability to have custom settings for delta wings, v-tail aircraft, etc. -However, this is basically a mix that is running on the radio and trying to use these custom radio configurations through INAV might appear to work in manual mode on the bench, but INAV can't be configured to "understand" how to control your plane with these custom radio configurations and will cause your airplane to fly out of control when another other mode is engadeged or failsafe tries to save your aircraft. +However, this is basically a mix that is running on the radio and trying to use these custom radio configurations through INAV might appear to work in manual mode on the bench, but INAV can't be configured to "understand" how to control your plane with these custom radio configurations and will cause your airplane to fly out of control when another other mode is engaged or failsafe tries to save your aircraft. **Turn off all custom radio configurations. This also applies to trims and expos. These are done in INAV. diff --git a/docs/04-inav-configurator/outputs-tab.mdx b/docs/04-inav-configurator/outputs-tab.mdx index 41d33c2..14fddf9 100644 --- a/docs/04-inav-configurator/outputs-tab.mdx +++ b/docs/04-inav-configurator/outputs-tab.mdx @@ -64,7 +64,7 @@ CLI commands to configure servos: The `servo` command is used to list or modify servo's configuration. To list the current servo's configuration run the `servo` command without parameters. -To change the configuration of a servo use the `servo` command with the following syntax: `servo `. `` is representing the index of the servo output defined by a servo mixer (See (mixer documentation)[https://github.com/iNavFlight/inav/blob/master/docs/Mixer.md]). The other parameters must be positive integers apart from the rate wich valid range is [-125, 125]. +To change the configuration of a servo use the `servo` command with the following syntax: `servo `. `` is representing the index of the servo output defined by a servo mixer (See the [mixer documentation](../05-core-features/mixer.mdx)). The other parameters must be positive integers apart from the rate which valid range is [-125, 125]. ### Servo filtering @@ -84,7 +84,7 @@ One method for tuning the filter cutoff is as follows: 2. Tap the vehicle at its end in the axis under evaluation. Directly commanding the servo in question to move may also be used. In the tricopter example, tap the end of the tail boom from the side, or command a yaw using your transmitter. -3. If your vehicle oscillates for several seconds or even continues oscillating indefinitely, then the filter cutoff frequency should be reduced. Reduce the value of `servo_lowpass_freq` by half its current value and repeat the previous step. +3. If your vehicle oscillates for several seconds or even continues oscillating indefinitely, then the filter cutoff frequency should be reduced. Reduce the value of `servo_lpf_hz` by half its current value and repeat the previous step. 4. If the oscillations are dampened within roughly a second or are no longer present, then you are done. Be sure to run `save`. diff --git a/docs/04-inav-configurator/receiver-tab.mdx b/docs/04-inav-configurator/receiver-tab.mdx index b921045..9b7eb3a 100644 --- a/docs/04-inav-configurator/receiver-tab.mdx +++ b/docs/04-inav-configurator/receiver-tab.mdx @@ -104,7 +104,7 @@ Never, never use trims on your radio when using INAV. INAV has its own trim system. ::: -This is also a good time to rerun a calibration on your radio's gimbles. +This is also a good time to rerun a calibration on your radio's gimbals. Find a video on YouTube specific to your radio model. ### RSSI Channel _(Received Signal Strength Indicator)_ @@ -141,4 +141,4 @@ save ``` You can also use rxrange to reverse the direction of an input channel, e.g. `rxrange 0 2000 1000`. -But be sure to know what you are doing whenever usinf the cli. +But be sure to know what you are doing whenever using the cli. diff --git a/docs/05-core-features/battery.mdx b/docs/05-core-features/battery.mdx index fa8500a..9e9aa8f 100644 --- a/docs/05-core-features/battery.mdx +++ b/docs/05-core-features/battery.mdx @@ -67,10 +67,10 @@ Should be higher than maximum cell voltage to take into account possible drift i `vbat_max_cell_voltage` - Maximum voltage per cell when the battery is fully charged. Used for the OSD voltage based battery gauge (0.01V unit, i.e. 420 = 4.20V) `vbat_warning_cell_voltage` - Cell warning voltage. -A cell voltage bellow this value triggers the first (short beeps) voltage based battery alarm if used and also the blinking of the OSD voltage indicator if the battery capacity is not used instead (see bellow) (0.01V unit, i.e. 370 = 3.70V) +A cell voltage below this value triggers the first (short beeps) voltage based battery alarm if used and also the blinking of the OSD voltage indicator if the battery capacity is not used instead (see below) (0.01V unit, i.e. 370 = 3.70V) `vbat_min_cell_voltage` - Cell minimum voltage. -A cell voltage bellow this value triggers the second (long beeps) voltage based battery alarm if used and the OSD gauge will display 0% if the battery capacity is not used instead (see bellow) (0.01V unit, i.e. 350 = 3.50V) +A cell voltage below this value triggers the second (long beeps) voltage based battery alarm if used and the OSD gauge will display 0% if the battery capacity is not used instead (see below) (0.01V unit, i.e. 350 = 3.50V) e.g. diff --git a/docs/05-core-features/blackblox.mdx b/docs/05-core-features/blackblox.mdx index e7e63e2..0b12882 100644 --- a/docs/05-core-features/blackblox.mdx +++ b/docs/05-core-features/blackblox.mdx @@ -278,7 +278,7 @@ In INAV we use a set of specific variables, each variable may contain multiple a **navPos**, **navVel**, **navTgtPos** and **navTgtVel** each hold arrays [0-2], which represent distances due North [0], due East [1] and straight Up [2], all relative to the "point of origin". North and East are fused from accelerometer and GPS data, while Up is fused from accelerometer + barometer for multicopters and accelerometer + gps for airplanes if no barometer is available. Read the Inertial position estimator|Inertial-position-estimator-(INAV) section in the [[Developer info]] page for detailed explanation. -"Point of origin" might be different from "Home". "Home" is defined as position at the time of arming. While "Point of origin" is recorded after a valid GPS fix is aquired. +"Point of origin" might be different from "Home". "Home" is defined as position at the time of arming. While "Point of origin" is recorded after a valid GPS fix is acquired. For further information about the coordinate system used please read the Coordinate systems|Coordinate-systems section on the [[Developer info]] page. @@ -332,7 +332,7 @@ Due to the complexity of the tasks being performed in later INAV releases. e.g. Some fields that are logged, are not yet accessible with Blackbox Explorer, particularly navigation related.. Other options: -* [backbox_decode](https://github.com/iNavFlight/blackbox-tools) Decode to CSV file +* [blackbox_decode](https://github.com/iNavFlight/blackbox-tools) Decode to CSV file * [flightlog2kml](https://codeberg.org/stronnag/flightlog2kml), [fl2xui](https://codeberg.org/stronnag/fl2xui/). Decode to KML (for Google Earth). * [mwptools](https://codeberg.org/stronnag/mwptools/). Interactive log replay, inter-alia. @@ -341,7 +341,7 @@ Some fields that are logged, are not yet accessible with Blackbox Explorer, part | Name of field in txt file | Name in Blackbox Log Viewer | Explanation | . | .. | |:--------------------------: |:----------------------------: |:------------: |:---: |:----------:| | loopIteration | not used | counter from main loop | | | -| time (us) | x-axis of diagram | real time in micoseconds | | |sensors/acceleration.h +| time (us) | x-axis of diagram | real time in microseconds | | |sensors/acceleration.h | axisRate[0] | gyros[roll] (.. deg/s) | rotation rate | roll | deg/sec | | axisRate[1] | gyros[pitch] (.. deg/s) | rotation rate | pitch | deg/sec | | axisRate[2] | gyros[yaw] (.. deg/s) | rotation rate | yaw | deg/sec | diff --git a/docs/05-core-features/buzzer.mdx b/docs/05-core-features/buzzer.mdx index d03315c..ca9a4b8 100644 --- a/docs/05-core-features/buzzer.mdx +++ b/docs/05-core-features/buzzer.mdx @@ -96,7 +96,7 @@ Disabled: ON_USB *Note: SYSTEM_INIT sequence is not affected by ON_USB setting and will still be played on USB connection. Disable both ON_USB and SYSTEM_INIT to disable buzzer completely when FC is powered from USB.* -*Note: ON_USB setting requires present and configured battery voltage metter.* +*Note: ON_USB setting requires present and configured battery voltage meter.* To disable all features use: diff --git a/docs/05-core-features/compass.mdx b/docs/05-core-features/compass.mdx index 2b95219..69b2a20 100644 --- a/docs/05-core-features/compass.mdx +++ b/docs/05-core-features/compass.mdx @@ -17,7 +17,7 @@ The compass must be mounted parallel to FC. When using an external magnetometer, 9/10 times you need to physically remove (_remove chip from board or cut a trace_) the internal one if you have on. :::info -Two identical chips/magnetometers on the same I2C bus cannot be used. The 1/10 time you dont need to physically remove your internal mag is when you have different magnetometers on the flight controller and the external one. +Two identical chips/magnetometers on the same I2C bus cannot be used. The 1/10 time you don't need to physically remove your internal mag is when you have different magnetometers on the flight controller and the external one. Example you cannot use two HMC5883L magnetometers. ::: @@ -54,7 +54,7 @@ As an example, the Matek M10Q is pictured below: :::info When using presets, the compass's orientation is locked relative to the FC! -This means that even when not placing the FC in the manufacturer's default orientation (eg upsidedown or rotated 90 degrees) and modifying that in the Alignment Tab, the compass will follow that orientation change. +This means that even when not placing the FC in the manufacturer's default orientation (eg upside down or rotated 90 degrees) and modifying that in the Alignment Tab, the compass will follow that orientation change. This will likely have unintended consequences so double check the compass orientation! ::: @@ -98,7 +98,7 @@ When to manually align compass: - The compass does not have any clear arrow indications - There is no preset available in INAV for the compass being used -- The FC is mounted in an unconventional position and orientation (eg. upsidedown, cockeyed X degrees, etc.) +- The FC is mounted in an unconventional position and orientation (eg. upside down, cockeyed X degrees, etc.) - Compass is mounted at an angle ### Steps For Manual Compass Setup diff --git a/docs/05-core-features/fixed-wing-autolaunch.mdx b/docs/05-core-features/fixed-wing-autolaunch.mdx index ab46bb2..563df56 100644 --- a/docs/05-core-features/fixed-wing-autolaunch.mdx +++ b/docs/05-core-features/fixed-wing-autolaunch.mdx @@ -23,7 +23,7 @@ When it has aborted it goes to whichever mode is selected. This can be Angle, Ac It's safe to keep `NAV LAUNCH` activated during flight after the launch has been completed. `NAV LAUNCH` has a flight speed check. -If accidenal disarm occurs, the user is given 5 seconds to rearm before `NAV LAUNCH` becomes active again. +If accidental disarm occurs, the user is given 5 seconds to rearm before `NAV LAUNCH` becomes active again. See the INAV CLI [Settings document](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md) for all available parameters, they start with `nav_fw_launch`. The most used settings for launch mode can be found on the **Advanced Tuning** page in INAV Configurator. @@ -177,7 +177,7 @@ If you just want this as a low, visual aid for launch mode. You can set this to somewhere between 1050 and 1200. It should be high enough that the motor spins, but only just. If you want assistance in launching your aircraft, the idle throttle should be set high enough to assist with the push, but not so high that it is uncontrollable in your hands. -This will very much be dependant on your aircraft, motor, prop, even how you hold it, so you will need to experiment or use the tool at the bottom of this page for an estimate. +This will very much be dependent on your aircraft, motor, prop, even how you hold it, so you will need to experiment or use the tool at the bottom of this page for an estimate. The default setting is `1000`; which is idle throttle is disabled. If you don't change anything else, the motor will start spinning at idle throttle as soon as you raise the throttle in the [activate launch sequence](./fixed-wing-autolaunch.mdx#activate-autolaunch-sequence). @@ -223,7 +223,7 @@ If you have a tractor plane, this setting can be low safely. :::warning If the motor speeds up too quickly and you have a pusher plane, you risk a prop strike to your hand. -Therefore, please be carful when adjusting this. +Therefore, please be careful when adjusting this. ::: ### Minimum Launch Time diff --git a/docs/05-core-features/flight-modes-navigation.mdx b/docs/05-core-features/flight-modes-navigation.mdx index 218e0fe..a6772bc 100644 --- a/docs/05-core-features/flight-modes-navigation.mdx +++ b/docs/05-core-features/flight-modes-navigation.mdx @@ -117,7 +117,7 @@ Max. navigation speed | [nav_max_auto_speed](https://github.com/iNavFlight/inav/ Max. CRUISE speed | [nav_manual_speed](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_manual_speed) | Maximum speed allowed when processing pilot input for POSHOLD/CRUISE control mode [cm/s] [Multirotor only] Max. navigation climb rate | [nav_mc_auto_climb_rate](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_auto_climb_rate) | Maximum climb/descent rate that UAV is allowed to reach during navigation modes. [cm/s] Max. Alt-hold climb rate | [nav_mc_manual_climb_rate](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_manual_climb_rate) | Maximum climb/descent rate firmware is allowed when processing pilot input for ALTHOLD control mode [cm/s] -Multirotor max. banking angle | [nav_mc_bank_angle](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_bank_angle) | Maximum banking angle (deg) that multicopter navigation is allowed to set. Machine must be able to satisfy this angle without loosing altitude. +Multirotor max. banking angle | [nav_mc_bank_angle](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_bank_angle) | Maximum banking angle (deg) that multicopter navigation is allowed to set. Machine must be able to satisfy this angle without losing altitude. Stick position for althold hover | [nav_mc_althold_throttle](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_althold_throttle) | If set to STICK the FC remembers the throttle stick position when enabling ALTHOLD and treats it as the neutral midpoint for holding altitude. If set to MID_STICK or HOVER the neutral midpoint is set to the mid stick position or the hover throttle position respectively. Hover throttle | [nav_mc_hover_thr](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_hover_thr) | Multicopter hover throttle hint for altitude controller. Should be set to approximate throttle value when drone is hovering. Slow down when approaching waypoint | [nav_mc_wp_slowdown](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_wp_slowdown) | When ON, NAV engine will slow down when switching to the next waypoint. This prioritizes turning over forward movement. When OFF, NAV engine will continue to the next waypoint and turn as it goes. @@ -278,7 +278,7 @@ Applicable: Only when in POSHOLD MC Braking mode is a subset of POSHOLD. Its purpose is to allow faster braking when the pitch stick is released back to center. -It also provides the advantage of setting the stopping position where the copter finishes braking, isntead of it backing-up to the point you released the stick, when braking mode isn't active. +It also provides the advantage of setting the stopping position where the copter finishes braking, instead of it backing-up to the point you released the stick, when braking mode isn't active. MC Braking mode requires the following conditions to be met for its operation: - Must be in POSHOLD @@ -362,7 +362,7 @@ This will allow the airplane to loiter around the arming or safehome location un The operation of the landing detector disarming functions can be found [RTH - Landing Detector](./rth.mdx#landing-detector). -There are many different RTH fly-home altitude modes, see the [RTH mode page](https://github.com/iNavFlight/inav/wiki/Navigation-Mode:-Return-to-Home) for details. +There are many different RTH fly-home altitude modes, see the [RTH mode page](./rth.mdx) for details. ## MISSION CHANGE @@ -398,7 +398,7 @@ The [MSP navigation message protocol documentation](../06-advanced-features/msp- ### Fixed Wing Waypoint Tracking Accuracy and Turns Waypoint tracking accuracy makes the craft fly along the course line between two waypoints instead of simply heading toward the next one. 2 settings control the alignment behaviour. [nav_fw_wp_tracking_accuracy](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_tracking_accuracy) sets the deadband distance from the course line in metres. Tracking is not actively controlled within the deadband, so larger values give smoother flight adjustments but less accurate tracking. A 2 m deadband works well in most cases and 0 disables tracking entirely. [nav_fw_wp_tracking_max_angle](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_tracking_max_angle) -sets the maximum alignment convergence angle to the waypoint course line (see below). This is the maximum angle allowed during alignment and in reality will only be acheived when some distance away from the course line with the angle reducing as the craft gets closer to alignment. Lower values result in smoother alignment with the course line but a greater distance along the course line will be required until this is achieved. +sets the maximum alignment convergence angle to the waypoint course line (see below). This is the maximum angle allowed during alignment and in reality will only be achieved when some distance away from the course line with the angle reducing as the craft gets closer to alignment. Lower values result in smoother alignment with the course line but a greater distance along the course line will be required until this is achieved. From INAV 10.0 the turns at the waypoints themselves are flown by the coordinated turn coordinator, selected with [nav_fw_wp_turn_mode](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_turn_mode). It works out the turn radius the plane actually needs from its current speed and bank angle and begins the turn early enough to roll out aligned with the next leg. diff --git a/docs/05-core-features/flight-modes-standard.mdx b/docs/05-core-features/flight-modes-standard.mdx index 46bde8f..1db86be 100644 --- a/docs/05-core-features/flight-modes-standard.mdx +++ b/docs/05-core-features/flight-modes-standard.mdx @@ -124,7 +124,7 @@ There is little to no benefit to having Airmode enabled with other flight modes For Fixedwing Airmode to become active for flight, it requires `airmode_throttle_threshold` to be met, which uses different settings for [airmode_type](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#airmode_type) than for multicopter. They are - `STICK_CENTER` and `STICK_CENTER_ONCE`. -`STICK_CENTER_ONCE` is activated by the same method - using `airmode_throttle_threshold`, but instead of disabling Airmode when the throttle is lowered below the `throttle_threshold`, it will keep Airmode active until disarmed. +`STICK_CENTER_ONCE` is activated by the same method - using `airmode_throttle_threshold`, but instead of disabling Airmode when the throttle is lowered below the `airmode_throttle_threshold`, it will keep Airmode active until disarmed. This is more beneficial for fixedwing platforms like powered gliders so they maintain Airmode stabilization at zero throttle. The requirement to also move the sticks from center to activate Airmode prevents I-term windup before launch if you don't throw the airplane immediately after raising the throttle. @@ -160,7 +160,7 @@ It was designed so it can also be used with - `COURSE HOLD` or `ALT HOLD`. Altho ## ARM -Arm activates numerous conditions required for fligh and allows the motor/s to become active for propulsion. +Arm activates numerous conditions required for flight and allows the motor/s to become active for propulsion. Some of these conditions are: * Starts flight logging. Including Blackbox and flight stats * Records the RTH location and altitude @@ -501,7 +501,7 @@ Also note that the automatic version of this introduced in 3.0 requires a GPS an *The purpose of this mode is to set new midpoints for servos 2 to 5. Make sure you assign these servo numbers to your control surfaces or they will not be trimmed. -If you have another servo (e.g. a servo gimbal) assigned to to servos 2 to 5, then this servo will be trimmed.* +If you have another servo (e.g. a servo gimbal) assigned to servos 2 to 5, then this servo will be trimmed.* This is so when switching into manual mode the plane will fly straight, its also to help the PIFF controller know where the plane is expected to fly straight. @@ -516,7 +516,7 @@ New midpoints will be saved. You may want to inspect your new midpoints after landing, if the servo offset is a lot you may alter your linkage mechanically and redo servo midpoint. -This is not to be confused with tuning your aircraft for leveled flight in `ANGLE` and other attitude-conteolled modes. to do this use [AUTO LEVEL TRIM](./flight-modes-standard.mdx#auto-level-trim-fw). +This is not to be confused with tuning your aircraft for leveled flight in `ANGLE` and other attitude-controlled modes. to do this use [AUTO LEVEL TRIM](./flight-modes-standard.mdx#auto-level-trim-fw). ## SOARING (FW) diff --git a/docs/05-core-features/gps.mdx b/docs/05-core-features/gps.mdx index aa189da..d13eb48 100644 --- a/docs/05-core-features/gps.mdx +++ b/docs/05-core-features/gps.mdx @@ -82,8 +82,8 @@ INAV will enable UBLOX periodic messages according to the UBLOX version: | 0x01 | 0x03 | UBX-NAV-STATUS Receiver Navigation status | 5,6 | < 9.0.0 | | 0x01 | 0x12 | UBX-NAV-VELNED Velocity Solution in NED | 5,6 | < 9.0.0 | | 0x01 | 0x21 | UBX-NAV-TIMEUTC GPS Time Solution | 5,6 | < 9.0.0 | -| 0x01 | 0x35 | UBX-NAV-SAT Sattelite Infrmation | 5,6,7 | < 9.0.0 | -| 0x01 | 0x35 | UBX-NAV-SAT Sattelite Infrmation | 8 | | +| 0x01 | 0x35 | UBX-NAV-SAT Satellite Information | 5,6,7 | < 9.0.0 | +| 0x01 | 0x35 | UBX-NAV-SAT Satellite Information | 8 | | | 0x01 | 0x42 | UBX-NAV-SIG Signal Information | 9,10 | >= 8.0.0 | | 0x01 | 0x07 | UBX-NAV-PVT Navigation Position Velocity Time Solution | 7,8,9,10 | | diff --git a/docs/05-core-features/inav-for-betaflight-users.mdx b/docs/05-core-features/inav-for-betaflight-users.mdx index 16f42e4..f7cb357 100644 --- a/docs/05-core-features/inav-for-betaflight-users.mdx +++ b/docs/05-core-features/inav-for-betaflight-users.mdx @@ -9,7 +9,7 @@ While BetaFlight evolved to provide a higher level of race and freestyle flight INAV evolved to provide navigation flight capabilities and more diverse multi-platform configuration. In recent times Betaflight has gained basic support for more diverse multicopter and fixedwing platforms. But it does not provide the same level of features, tune-ability and easy of setup for those platforms as INAV does. -**Muliticopter Support:** +**Multicopter Support:** - `Bi-copter` - `Tri-copter` diff --git a/docs/05-core-features/led-strips.mdx b/docs/05-core-features/led-strips.mdx index dd15df9..9a7ecc0 100644 --- a/docs/05-core-features/led-strips.mdx +++ b/docs/05-core-features/led-strips.mdx @@ -5,7 +5,7 @@ description: How to configure addressable LED strips INAV supports the use of addressable LED strips. -Addressable LED strips allow each LED in the strip to be programmed with a unique and independant color. +Addressable LED strips allow each LED in the strip to be programmed with a unique and independent color. This is far more advanced than the normal RGB strips which require that all the LEDs in the strip show the same color. Addressable LED strips can be used to show information from the flight controller system. @@ -63,7 +63,7 @@ Just ensure that the GROUND is the same for all BEC outputs and LEDs. If using a large number of LEDs. It would be more efficient to use 12v LEDs and power them with a separate regulated supply, especially if using long strips. -The data line (LED pad) from the flight controller wll have to be used. +The data line (LED pad) from the flight controller will have to be used. Make sure there is continuity between the ground on the LEDS and the ground on the flight controller. | Target | Pin | LED Strip | Signal | @@ -221,7 +221,7 @@ This mode binds the LED color to remaining battery capacity. | Red | 20% | | Deep pink | 0% | -When Warning or Critial voltage is reached, LEDs will blink slowly or fast. +When Warning or Critical voltage is reached, LEDs will blink slowly or fast. Note: this mode requires a current sensor. If you don't have the actual device you can set up a virtual current sensor (see [Battery](./battery.mdx)). #### Blink @@ -323,11 +323,11 @@ the same time. Thrust should normally be combined with Color or Mode/Orientatio This mode is allows you to use one or multiple led rings (e.g. NeoPixel ring) for an afterburner effect. The light pattern rotates clockwise as throttle increases. -A better effect is acheived when LEDs configured for thrust ring have no other functions. +A better effect is achieved when LEDs configured for thrust ring have no other functions. LED direction and X/Y positions are irrelevant for thrust ring LED state. The order of the LEDs that have the state determines how the LED behaves. -Each LED of the ring can be a different color. The color can be selected between the 16 colors availables. +Each LED of the ring can be a different color. The color can be selected between the 16 available colors. For example, led 0 is set as a `R`ing thrust state led in color 13 as follow. @@ -401,7 +401,7 @@ color 14 0,0,0 color 15 0,0,0 ``` -### Mode Colors Assignement +### Mode Colors Assignment Mode Colors can be configured using the cli `mode_color` command. @@ -560,7 +560,7 @@ LEDs 1-2, 4-5, 7-8 and 10-11 should be positioned so the face east/north/west/so LEDs 12-13 should be placed facing down, in the middle LEDs 14-15 should be placed facing up, in the middle -### Exmple 28 LED config +### Example 28 LED config ``` # right rear cluster diff --git a/docs/05-core-features/mixer.mdx b/docs/05-core-features/mixer.mdx index 698cc13..c61a452 100644 --- a/docs/05-core-features/mixer.mdx +++ b/docs/05-core-features/mixer.mdx @@ -14,7 +14,7 @@ To use a mixer preset first select the platform type then the mixer preset match The `Load and apply` button will load the mixer, save it and ask to reboot the flight controller. The `Load mixer` button only loads the preset mixing rules, you can then edit them to suit your needs and when you are done you need to press the `Save and Reboot` button to save the rules. -Watch [this video](https://www.youtube.com/watch?v=0cLFu-5syi0) for a detailed description of the GUI and the documentation bellow for more details. +Watch [this video](https://www.youtube.com/watch?v=0cLFu-5syi0) for a detailed description of the GUI and the documentation below for more details. ## Platform type @@ -33,7 +33,7 @@ Currently, following platform types are supported: A motor mixing rule is needed for each motor. Each rule defines weights that determine how the motor it applies to will change its speed relative to the requested throttle and flight dynamics: roll rate, pitch rate and yaw rate. -The heigher a weight the more the input will have an impact on the speed of the motor. Refer to the following table for the meaning of each weight. +The higher a weight the more the input will have an impact on the speed of the motor. Refer to the following table for the meaning of each weight. | Weight | Definition | | ---------------------- | ---------- | @@ -62,7 +62,7 @@ The absolute value of the index is not important, what matters is only the relat The rule with the smaller servo index will apply to the first servo, the next higher servo index to the second servo, etc. More than one rule can use the same servo index. The output of the rules with the same servo index are added together to give the final output for the specified servo. -* Input: the input for the mixing rule, see a summary of the input types table bellow. +* Input: the input for the mixing rule, see a summary of the input types table below. * Weight: percentage of the input to forward to the servo. Range [-1000, 1000]. Mixing rule output = input * weight. If the output of a set of mixing rules is lower/higher than the defined servo min/max the output is clipped (the servo will never travel farther than the set min/max). * Speed: maximum rate of change of the mixing rule output. @@ -115,7 +115,7 @@ To disable a mixing rule set the weight to 0. ## Logic Conditions Logic Conditions allows to activate/deactivate `smix` rules based on user input and flight parameters. -If Logic Condition evaluates as `false`, smix rule connected with with LC will not be active and used inside the Mixer. +If Logic Condition evaluates as `false`, smix rule connected with LC will not be active and used inside the Mixer. This mechanism allows to move servos when desired conditions are met. For example, if an airplane is equipped with a pitot tube and flaps, flaps can be automatically deployed when airspeed goes below a threshold. diff --git a/docs/05-core-features/osd.mdx b/docs/05-core-features/osd.mdx index b227622..a378194 100644 --- a/docs/05-core-features/osd.mdx +++ b/docs/05-core-features/osd.mdx @@ -226,7 +226,7 @@ Base fonts and information can be found in the [OSD folder](https://github.com/i Each system will need a specific method to create the font image files, so they will not be covered here. There are two pilot logos. -Default small INAV Pilot logoThe small pilot logo appears on standard OSD layouts, when you add the elemement to the OSD screen. This is a 3 character wide symbol (characters 469-471). +Default small INAV Pilot logoThe small pilot logo appears on standard OSD layouts, when you add the element to the OSD screen. This is a 3 character wide symbol (characters 469-471). Default large INAV Pilot logoThe large pilot logo appears on the power on and arming screens, when you enable the feature in the CLI. To do this, set the `osd_use_pilot_logo` parameter to `on`. This is a 10 character wide, 4 character high symbol (characters 472-511). @@ -251,9 +251,9 @@ This will allow a larger, single logo. ![Power on screen example with 0 spacing between logos](/img/features-core/osd-01.png) ## Post Flight Statistics -The post flight statistcs are set in the firmware. +The post flight statistics are set in the firmware. Statistics are only hidden if the supporting hardware is not present. -Due to size contraints. +Due to size constraints. The post flight statistics are spread over 2 pages on analogue systems. ### Statistics shown @@ -274,7 +274,7 @@ The post flight statistics are spread over 2 pages on analogue systems. | Average Efficiency | Current Sensor & GPS | 1 | | | Minimum RSSI | | 2 | | | Minimum LQ | CRSF | 2 | | -| Minmum dBm | CRSF | 2 | | +| Minimum dBm | CRSF | 2 | | | Minimum Satellites | GPS | 2 | | | Maximum Satellites | GPS | 2 | | | Minimum ESC Temperature | ESC Telemetry | 2 | | diff --git a/docs/05-core-features/rth.mdx b/docs/05-core-features/rth.mdx index dfbb6ec..6fa4b9c 100644 --- a/docs/05-core-features/rth.mdx +++ b/docs/05-core-features/rth.mdx @@ -31,8 +31,8 @@ The difference is only seen in the way plane's climb or descend in a loitering s - [Extra](./rth.mdx#extra-altitude) - [Fixed](./rth.mdx#fixed-altitude) - [Max](./rth.mdx#maximum-altitude-since-launch) -- [Atleast](./rth.mdx#at-least-predefined-altitude-above-launch-point) -- [Altleast + Linear descent](./rth.mdx#at-least-predefined-altitude-with-linear-descent-legacy-setting) +- [At least](./rth.mdx#at-least-predefined-altitude-above-launch-point) +- [At least + Linear descent](./rth.mdx#at-least-predefined-altitude-with-linear-descent-legacy-setting) - [Linear (INAV 7.0+)](./rth.mdx#linear-descent) **Climb first modes** @@ -315,7 +315,7 @@ When [nav_landing_bump_detection](https://github.com/iNavFlight/inav/blob/master - The Z axis touch-down rebound exceeds 2g, then falls back below 1g within 100mS. - The XY (horizontal) velocity must be low. (requiring GNSS fix) -- Throttle is below `hover_throttle`. +- Throttle is below `nav_mc_hover_thr`. ### Failsafe inverted crash detection - Multicopter only diff --git a/docs/05-core-features/stick-controls.mdx b/docs/05-core-features/stick-controls.mdx index ef35a06..5135124 100644 --- a/docs/05-core-features/stick-controls.mdx +++ b/docs/05-core-features/stick-controls.mdx @@ -15,7 +15,7 @@ Arming and disarming is done using a switch, set up on the modes page. ### Arming Override -Arming is disabled when Nav modes are configured and no GPS lock is available **or** if a waypoint mission is loaded but the first WP is farther than the `nav_wp_safe_distance` setting. +Arming is disabled when Nav modes are configured and no GPS lock is available **or** if a waypoint mission is loaded but the first WP is farther than the `nav_wp_max_safe_distance` setting. This Arming block can be bypassed if need be by setting `nav_extra_arming_safety` to `ALLOW_BYPASS` and moving the Yaw stick to the high position (usually full right rudder) when the Arm switch is used. This bypasses GPS Arm blocking pre INAV 4.0.0 and both GPS and "First WP too far" Arm blocking from INAV 4.0.0. @@ -123,7 +123,7 @@ When using the default stick arming, lowering your throttle below min_check will With motor stop enabled, lowering your throttle below min_check will also result in motors off and the esc's being sent min_command. Min_check must be set to a level that is 100% reliably met by the throttle throw. A setting too low may result in a dangerous condition where the copter can’t be disarmed. -It is ok to set this below `throttle_idle` (min_throttle) because the FC will automaticly scale the output to the ESCs +It is ok to set this below `throttle_idle` (min_throttle) because the FC will automatically scale the output to the ESCs `throttle_idle` (previously `min_throttle)` - Typically set to just above reliable spin up of all motors. diff --git a/docs/06-advanced-features/fixed-wing-autoland.mdx b/docs/06-advanced-features/fixed-wing-autoland.mdx index 34ace1f..3d411df 100644 --- a/docs/06-advanced-features/fixed-wing-autoland.mdx +++ b/docs/06-advanced-features/fixed-wing-autoland.mdx @@ -8,7 +8,7 @@ description: All about configuring autoland for fixed wings INAV supports advanced automatic landings for fixed wing aircraft from version 7.1. The procedure is based on landings for man-carrying aircraft so that safe landings at a specific location are possible. Supported are landings at Safehome after "Return to Home" or at a defined LAND waypoint for missions. -Every landing locations can be defined with a target point and 2 different approach headings (colinear to the landing strips) with exclusive direction or opposite directions allowed. +Every landing locations can be defined with a target point and 2 different approach headings (collinear to the landing strips) with exclusive direction or opposite directions allowed. This enables up to 4 different approach directions, based on the landing site and surrounding area. ## General Procedure: @@ -84,7 +84,7 @@ In cm/s. Min: 0; Max: 3000, Default: 140 ## Landing Site Parameters -### The following parameters are set for each landing site (Safefome/LAND waypoint): +### The following parameters are set for each landing site (Safehome/LAND waypoint): All settings can also be conveniently made in the Configurator via Mission Control. @@ -105,17 +105,17 @@ This means that practically 4 landing directions can be saved. :::warning > [!CAUTION] -The Configuator automatically determines the ground altitude based on databases on the Internet, which may be inaccurate. +The Configurator automatically determines the ground altitude based on databases on the Internet, which may be inaccurate. Please always compare with the measured GPS altitude at the landing site to avoid crashes. ::: -### General Paramters And Tuning Tips +### General Parameters And Tuning Tips * `nav_fw_wp_tracking_accuracy`: Its highly recommended that this parameter is used and tuned well. Only with WP-Tracking enabled, the Aircraft will try to precisely align with the runway during approach. -If WP-Tracking is not used, the Plane will head straight to the landiung location without flying in line with the intended landing strip. +If WP-Tracking is not used, the Plane will head straight to the landing location without flying in line with the intended landing strip. Wind can intensively alter the final landing heading. * `nav_fw_pitch2thr`: The navigation throttle modifier has to be tuned well to allow stable navigation during climbs and descents to prevent a stall. diff --git a/docs/06-advanced-features/gps-fix-estimation.mdx b/docs/06-advanced-features/gps-fix-estimation.mdx index 36001fb..8256ce8 100644 --- a/docs/06-advanced-features/gps-fix-estimation.mdx +++ b/docs/06-advanced-features/gps-fix-estimation.mdx @@ -22,15 +22,15 @@ It works for fixed wing only. Plane should have the following sensors: -- acceleromenter, gyroscope +- accelerometer, gyroscope - barometer - GPS - magnetometer (optional, highly recommended) - pitot (optional) -By befault, all navigation modes are disabled when GPS fix is lost. If RC signal is lost also, plane will not be able to enable RTH. Plane will switch to LANDING instead. When flying above unreachable spaces, plane will be lost. +By default, all navigation modes are disabled when GPS fix is lost. If RC signal is lost also, plane will not be able to enable RTH. Plane will switch to LANDING instead. When flying above unreachable spaces, plane will be lost. -GPS fix estimation allows to recover plane using magnetometer and baromener only. +GPS fix estimation allows to recover plane using magnetometer and barometer only. GPS Fix is also estimated on GPS Sensor timeouts (hardware failures). @@ -52,7 +52,7 @@ To navigate without GPS fix, we make the following assumptions: - plane is flying in the direction where nose is pointing - (if pitot tube is not installed) plane is flying with constant airspeed, specified in settings -It is possible to roughly estimate position using theese assumptions. +It is possible to roughly estimate position using these assumptions. To increase accuracy, plane will use information about wind direction and speed, estimated before GPS fix was lost. To increase groundspeed estimation accuracy, plane will use pitot tube data(if available). @@ -73,15 +73,15 @@ The problem that emerges without a compass is heading drift. The longer a plane flies without magnetometer or GPS, the bigger is its course estimation error. After few minutes and few turns, "north" direction estimation can be completely broken. -In general, accuracy is enough to perform RTH U-turn when both RC controls and GPS are lost, and roughtly keep RTH direction in areas with occasional GPS outages. +In general, accuracy is enough to perform RTH U-turn when both RC controls and GPS are lost, and roughly keep RTH direction in areas with occasional GPS outages. ![image](/img/features-adv/gps-estimation.png) (purple line - estimated position, black line - real position). -It is recommened to use GPS fix estimation without magnetometer as last resort only. +It is recommended to use GPS fix estimation without magnetometer as last resort only. For example, if plane is flying above lake, landing means loss of plane. -With GPS Fix estimation, plane will try to do RTH in very rought direction, instead of landing. +With GPS Fix estimation, plane will try to do RTH in a very rough direction, instead of landing. It is up to user to estimate the risk of fly-away. @@ -155,7 +155,7 @@ To decrease drift: - use airspeed sensor. If airspeed sensor is not installed, fly in cruise mode without throttle override. - do smooth, large turns -- make sure compass is pointing in nose direction precicely +- make sure compass is pointing in nose direction precisely - calibrate compass correctly This video shows real world test where GPS was disabled occasionally. Wind is 10km/h south-west: @@ -165,8 +165,8 @@ This video shows real world test where GPS was disabled occasionally. Wind is 10 The purple line shows estimated position. Black line shows real position. -"EST ERR" sensor shows estimation error in metters. Estimation is running when satellite icon displays "ES". -Estimated position snaps to real position when GPS fix is reaquired. +"EST ERR" sensor shows estimation error in meters. Estimation is running when satellite icon displays "ES". +Estimated position snaps to real position when GPS fix is reacquired. ## Is It Possible to Implement This for Multirotors? diff --git a/docs/06-advanced-features/lightweight-telemetry.mdx b/docs/06-advanced-features/lightweight-telemetry.mdx index d22ef26..d296d0a 100644 --- a/docs/06-advanced-features/lightweight-telemetry.mdx +++ b/docs/06-advanced-features/lightweight-telemetry.mdx @@ -15,7 +15,7 @@ Since its introduction to INAV, a number of extension have been added; these are ### Overview The LTM protocol starts with "$T", followed by a function byte, the payload and a simple CRC checksum. -Its weakness is that there is no length parameter (so the receiver needs to know, apriori,the length for each function), and the single byte checksum is not as robust as the multi-byte checksum in for example the ublox GPS protocol. +Its weakness is that there is no length parameter (so the receiver needs to know, a priori, the length for each function), and the single byte checksum is not as robust as the multi-byte checksum in for example the ublox GPS protocol. However, the high data rate ensures that good data should be delivered over occasional transmission errors. In practice, LTM is an excellent light weight telemetry solution. @@ -47,7 +47,7 @@ The follow telemetry frames are supported: | S | Status Frame | 5Hz at > 2400 baud | | O | Origin Frame | 1 Hz rate | | N | Navigation Frame (INAV extension) | ~4 Hz rate | -| X | GPS eXended data (INAV extension) | 1 Hz rate | +| X | GPS eXtended data (INAV extension) | 1 Hz rate | In addition, LTM was used by NRF24L01 / deviationtx INAV protocol, which defines an additional frame for in-TX tuning. This frame is not transmitted by INAV for telemetry. diff --git a/docs/06-advanced-features/msp-navigation-messages.mdx b/docs/06-advanced-features/msp-navigation-messages.mdx index 3d1e6e0..6ae31f0 100644 --- a/docs/06-advanced-features/msp-navigation-messages.mdx +++ b/docs/06-advanced-features/msp-navigation-messages.mdx @@ -536,7 +536,7 @@ The MSP NAV message set is implemented by [mwptools](https://github.com/stronnag ## XML Mission Files [INAV Configurator](https://github.com/iNavFlight/inav-configurator), [mwptools](https://github.com/stronnag/mwptools), ezgui / mp4i (and WinGUI) share a common, interoperable, XML mission file format. -A XSD can be found in the [INAV developer documenation](https://github.com/iNavFlight/inav/tree/master/docs/development/wp_mission_schema). +A XSD can be found in the [INAV developer documentation](https://github.com/iNavFlight/inav/tree/master/docs/development/wp_mission_schema). ## Encoding MSP Messages diff --git a/docs/06-advanced-features/programming-framework.mdx b/docs/06-advanced-features/programming-framework.mdx index b87ddad..a9d403f 100644 --- a/docs/06-advanced-features/programming-framework.mdx +++ b/docs/06-advanced-features/programming-framework.mdx @@ -3,7 +3,7 @@ title: INAV Programming Framework (IPF) description: Add additional functionality through programming logic --- -INAV Programming Framework (IPF) is a mechanism that allows you to to create +INAV Programming Framework (IPF) is a mechanism that allows you to create custom functionality in INAV. You can choose for certain actions to be done based on custom conditions you select. @@ -84,7 +84,7 @@ for complete documentation on using JavaScript to program your flight controller | 12 | NOT | The boolean opposite to `Operand A` | | 13 | Sticky | `Operand A` is the activation operator, `Operand B` is the deactivation operator. After the activation is `true`, the operator will return `true` until Operand B is evaluated as `true`| | 14 | Basic: Add | Add `Operand A` to `Operand B` and returns the result | -| 15 | Basic: Subtract | Substract `Operand B` from `Operand A` and returns the result | +| 15 | Basic: Subtract | Subtract `Operand B` from `Operand A` and returns the result | | 16 | Basic: Multiply | Multiply `Operand A` by `Operand B` and returns the result | | 17 | Basic: Divide | Divide `Operand A` by `Operand B` and returns the result. NOTE: If `Operand B` = `0`, the `Divide` operation will simply return `Operand A`| | 18 | Set GVAR | Store value from `Operand B` into the Global Variable addressed by `Operand A`. Bear in mind, that operand `Global Variable` means: Value stored in Global Variable of an index! To store in GVAR 1 use `Value 1` not `Global Variable 1` | @@ -93,7 +93,7 @@ for complete documentation on using JavaScript to program your flight controller | 21 | Set IO Port | Set I2C IO Expander pin `Operand A` to value of `Operand B`. `Operand A` accepts values `0-7` and `Operand B` accepts `0` and `1` | | 22 | Override Arming Safety | Allows the craft to arm on any angle even without GPS fix. WARNING: This bypasses all safety checks, even that the throttle is low, so use with caution. If you only want to check for certain conditions, such as arm without GPS fix. You will need to add logic conditions to check the throttle is low. | | 23 | Override Throttle Scale | Override throttle scale to the value defined by operand. Operand type `0` and value `50` means throttle will be scaled by 50%. | -| 24 | Swap Roll & Yaw | basically, when activated, yaw stick will control roll and roll stick will control yaw. Required for tail-sitters VTOL during vertical-horizonral transition when body frame changes | +| 24 | Swap Roll & Yaw | basically, when activated, yaw stick will control roll and roll stick will control yaw. Required for tail-sitters VTOL during vertical-horizontal transition when body frame changes | | 25 | Set VTx Power Level | Sets VTX power level. Accepted values are `0-3` for SmartAudio and `0-4` for Tramp protocol | | 26 | Invert Roll | Inverts ROLL axis input for PID/PIFF controller | | 27 | Invert Pitch | Inverts PITCH axis input for PID/PIFF controller | @@ -121,7 +121,7 @@ for complete documentation on using JavaScript to program your flight controller | 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`] PWM / PINIO generation on LED Pin. See [LED pin PWM](https://github.com/iNavFlight/inav/blob/master/docs/LED%20pin%20PWM.md). Any other value stops PWM generation (stop to allow ws2812 LEDs updates in shared modes). | +| 52 | PINIO PWM | `Operand A` = duty cycle (0-100). `Operand B` = channel (0 for LED strip idle level, 1-4 for PINIO channels). Channels 1-4 support full PWM; channel 0 is binary (>0 = HIGH). See [PINIO PWM](https://github.com/iNavFlight/inav/blob/maintenance-10.x/docs/PINIO%20PWM.md). | | 53 | Disable GPS Sensor Fix | Disables the GNSS sensor fix. For testing GNSS failure. | | 54 | Mag calibration | Trigger a magnetometer calibration. | | 55 | Set Gimbal Sensitivity | Scales `Operand A` from [`-16` : `15`] @@ -167,7 +167,7 @@ for complete documentation on using JavaScript to program your flight controller | 20 | Is Controlling Position | Is the position being controlled? boolean `0`/`1` | | 21 | Is Emergency Landing | Is the aircraft emergency landing? boolean `0`/`1` | | 22 | Is RTH | Is RTH active? boolean `0`/`1` | -| 23 | Is Landing | Is the aircaft automatically landing? boolean `0`/`1` | +| 23 | Is Landing | Is the aircraft automatically landing? boolean `0`/`1` | | 24 | Is Failsafe | Is the flight controller in a failsafe? boolean `0`/`1` | | 25 | Stabilized Roll | Roll PID controller output `[-500:500]` | | 26 | Stabilized Pitch | Pitch PID controller output `[-500:500]` | @@ -180,20 +180,20 @@ for complete documentation on using JavaScript to program your flight controller | 33 | Active Control Profile | Integer for the active config profile `[1..MAX_PROFILE_COUNT]` | | 34 | Battery cells | Number of battery cells detected | | 35 | AGL status [0/1] | Boolean `1` when AGL can be trusted, `0` when AGL estimate can not be trusted | -| 36 | AGL [cm] | Integer altitude above The Groud Altitude in `cm` | +| 36 | AGL [cm] | Integer altitude above the ground altitude in `cm` | | 37 | Rangefinder [cm] | Integer raw distance provided by the rangefinder in `cm` | | 38 | Active Mixer Profile | Which mixer is currently active (for vtol etc) | | 39 | Mixer Transition Active | Boolean `0`/`1`. Are we currently switching between mixers (quad to plane etc) | | 40 | Yaw [deg] | Current heading (yaw) in `degrees` | -| 41 | FW Land Sate | Integer `1` - `5`, indicates the status of the FW landing, 0 Idle, 1 Downwind, 2 Base Leg, 3 Final Approach, 4 Glide, 5 Flare | +| 41 | FW Land State | Integer `1` - `5`, indicates the status of the FW landing, 0 Idle, 1 Downwind, 2 Base Leg, 3 Final Approach, 4 Glide, 5 Flare | | 42 | Current battery profile | The active battery profile. Integer `[1..MAX_PROFILE_COUNT]` | | 43 | Flown Loiter Radius [m] | The actual loiter radius flown by a fixed wing during hold modes, in `meters` | | 44 | Downlink Link Quality | | | 45 | Uplink RSSI [dBm] | | | 46 | Minimum Ground Speed [m/s] | The current minimum ground speed allowed in navigation flight modes | -| 47 | Horizontal Wind Speed [cm/s] | Estimated wind speed. If the wind estimator is unavailble or the wind estimation is invalid, -1 is returned | -| 48 | Wind Direction [deg] | Estimated wind direction. If the wind estimator is unavailble or the wind estimation is invalid, -1 is returned | -| 49 | Relative Wind Offset [deg] | The relative offset between the heading of the aircraft and the heading of the wind. 0 indicates flying directly into a headwing. Negative numbers are a left offset. For example, if -20° is shown, turning right will correct towards 0. If the wind estimator is unavailble or the wind estimation is invalid, 0 is returned | +| 47 | Horizontal Wind Speed [cm/s] | Estimated wind speed. If the wind estimator is unavailable or the wind estimation is invalid, -1 is returned | +| 48 | Wind Direction [deg] | Estimated wind direction. If the wind estimator is unavailable or the wind estimation is invalid, -1 is returned | +| 49 | Relative Wind Offset [deg] | The relative offset between the heading of the aircraft and the heading of the wind. 0 indicates flying directly into a headwind. Negative numbers are a left offset. For example, if -20° is shown, turning right will correct towards 0. If the wind estimator is unavailable or the wind estimation is invalid, 0 is returned | #### FLIGHT_MODE @@ -254,7 +254,7 @@ They are not the Waypoint User Actions. See the [Waypoints](./programming-framew ### Flags -All flags are reseted on ARM and DISARM event. +All flags are reset on ARM and DISARM event. | bit | Decimal | Function | |-------|-----------|-----------| @@ -271,7 +271,7 @@ All flags are reseted on ARM and DISARM event. ## Programming PID -IPF makes a set of general user PIDFF controllers avaliable for use in your program. These PIDFF controllers are not tied to any roll/pitch/yaw profiles or other controls. +IPF makes a set of general user PIDFF controllers available for use in your program. These PIDFF controllers are not tied to any roll/pitch/yaw profiles or other controls. The output of these controllers can be used in an IPF program by using the `Programming PID` operand. The `` of the controller is the target value for the controller to hit. The `` is the measurement of the current value. For instance, `` could be the speed you want to go, and `` is the current speed. @@ -354,7 +354,7 @@ logic 3 1 -1 31 4 2 0 0 0 ``` Steps: -1. Normalize range `[1000:2000]` to `[0:1000]` by substracting `1000` +1. Normalize range `[1000:2000]` to `[0:1000]` by subtracting `1000` 2. Scale range `[0:1000]` to `[0:7]` 3. Increase range by `1` to have the range of `[1:8]` 4. Assign LC#2 to VTX channel function @@ -371,7 +371,7 @@ logic 3 1 -1 25 4 2 0 0 0 ``` Steps: -1. Normalize range [1000:2000] to [0:1000] by substracting `1000` +1. Normalize range [1000:2000] to [0:1000] by subtracting `1000` 2. Scale range [0:1000] to [0:3] 3. Increase range by `1` to have the range of [1:4] 4. Assign LC#2 to VTX power function diff --git a/docs/06-advanced-features/remote-management-control-telemetry.mdx b/docs/06-advanced-features/remote-management-control-telemetry.mdx index 3a41ffb..c3f42ce 100644 --- a/docs/06-advanced-features/remote-management-control-telemetry.mdx +++ b/docs/06-advanced-features/remote-management-control-telemetry.mdx @@ -87,7 +87,7 @@ The consumer has to be able to handle the transition (the arming MSP -> LTM / M ### MultiWii Serial Protocol Multiwii Serial Protocol originated on the MultiWii Flight controller around 2010. -The original documention is available in the now defunct Multiwii wiki. +The original documentation is available in the now defunct Multiwii wiki. Those details should not be relied upon for INAV / Betaflight implementations (or even 2.4 MultiWii). INAV supports the following variations: diff --git a/docs/06-advanced-features/vtol.mdx b/docs/06-advanced-features/vtol.mdx index 67755ac..9494fac 100644 --- a/docs/06-advanced-features/vtol.mdx +++ b/docs/06-advanced-features/vtol.mdx @@ -203,10 +203,10 @@ Conduct a bench test on the model (without props attached). The model can now sw ### STEP 4: Tilting Servo Setup (Recommended) :::info -Setting up the tilting servos to operate correctly 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. +Setting up the tilting servos to operate correctly 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 every yaw input. ::: -The steps below describe how you can fine-tune the tilting servos to obtian the optimum result. +The steps below describe how you can fine-tune the tilting servos to obtain the optimum result. 1. **Set the tilt servos at 45 degrees:** - Connect and power the tilting servos with your flight controller. @@ -214,7 +214,7 @@ The steps below describe how you can fine-tune the tilting servos to obtian the - Check the Outputs tab and make sure that the tilt servo channels are exactly at 1500μs. - In this mode, your tilt servos should be at the 45-degree position and you can now mount the motor and prop to your tilt servo such that the angle of the motor mounting plate is at 45 degrees upwards. - NOTE 1: If you have dedicated tilt servos, you may have engraved indices on the servos and tilting motor assembly to help you with this step. If the servos don't end up exactly at 45 degrees due to the teeth on the servo and the control arm/plate, don't worry, this will be automatically adjusted after completing the other steps below. - - NOTE 2: If you are using control rods to adjust the tilt of the servos, adjust the lenth of your control rod and the position of the control arm to position the control arm as close as possible to the mid position. It will depend on the oriatation of the servo, but generally speaking, the control arm of the servo should be pointed perpendicular to the fuselage when the motor mounts are at the 45 degree setting. + - NOTE 2: If you are using control rods to adjust the tilt of the servos, adjust the length of your control rod and the position of the control arm to position the control arm as close as possible to the mid position. It will depend on the orientation of the servo, but generally speaking, the control arm of the servo should be pointed perpendicular to the fuselage when the motor mounts are at the 45 degree setting. 2. **Switch to Multicopter/Tricopter:** - Assuming that you have set up your mixer similar to STEP1 and STEP2, you can now switch to the tricopter/multicopter mode and your servos should be tilting the motors upwards. If this is not the case, reverse the servo(s) in the Outputs tab such that the servo(s) is/are pointed upwards. @@ -224,36 +224,36 @@ The steps below describe how you can fine-tune the tilting servos to obtian the 3. **Adjust the maximum throws for the Multicopter/Tricopter mode:** - While in tricopter mode, navigate to the Outputs tab and adjust the MIN and MAX endpoint values to position the motors slightly backward. - Rotate the prop such that it is pointed backwards towards the wing/motor mount and ensure that the gap is the same on both sides by adjusting the MIN and MAX values for the tilt servo channels. - - NOTE: You can check the distance with calipers or gauge blocks. Alternatively, you can adjust the MIN and MAX for your tilting servos such that the props are just touching the top of the wing or motor mount, and then you can increase/decrease the MIN and MAX values for each channel by the same ammount for both servos. This should ensure that you have the same gap between the tip of the prop and the wing or motor mount for both sides. + - NOTE: You can check the distance with calipers or gauge blocks. Alternatively, you can adjust the MIN and MAX for your tilting servos such that the props are just touching the top of the wing or motor mount, and then you can increase/decrease the MIN and MAX values for each channel by the same amount for both servos. This should ensure that you have the same gap between the tip of the prop and the wing or motor mount for both sides. 4. **Adjust the minimum position for the Fixed-wing mode:** - Repeat the same step as point 3 with the model in fixed-wing mode, where the servos are tilted forwards. - For this step, you just have to make sure that the motors are pointed exactly forwards. - You can do this by adjusting the respective MIN and MAX values in the Output tab for the tilt servo channels while in fixed-wing mode. - - NOTE: Ensuring that your servos are tilted exactly forward is a crucial step as it can cause the plane to roll slightly if that it is not the case. However, ensuring the exact aligment will depend on your specific setup. If you are using dedicated tilting motor servos rather than standard servos with control arms and pushrods, you can make sure that you are exact by measuring the distance between the front edge of the tilting servo and the of the motor mounting plate. If the disances are the uniform across each mount and same on both motors, your servos are pointed forwads correctly. + - NOTE: Ensuring that your servos are tilted exactly forward is a crucial step as it can cause the plane to roll slightly if that it is not the case. However, ensuring the exact alignment will depend on your specific setup. If you are using dedicated tilting motor servos rather than standard servos with control arms and pushrods, you can make sure that you are exact by measuring the distance between the front edge of the tilting servo and the of the motor mounting plate. If the distances are the uniform across each mount and same on both motors, your servos are pointed forwards correctly. 5. **Adjust the vertical position of the tilt servos:** - Switch back to multicopter/tricopter mode and open the Mixer tab. - - Start adjusting the `MAX` mixer lines from STEP2 such that the servos are pointed exactly upwards. In other words, start reducing the values of 100 and -100 to something like 80 and -80 until the motors are are pointed exaxctly upwards. - - You will have to `Save & reboot` for adjustement for the changes to take effect, so be patient, take your time and don't forget to `Save & reboot`. + - Start adjusting the `MAX` mixer lines from STEP2 such that the servos are pointed exactly upwards. In other words, start reducing the values of 100 and -100 to something like 80 and -80 until the motors are pointed exactly upwards. + - You will have to `Save & reboot` for adjustment for the changes to take effect, so be patient, take your time and don't forget to `Save & reboot`. - Move the YAW stick to either extreme position and ensure that the servos are tilting the motors both forwards and backwards. - NOTE: When yawing fully left, the left motor should tilt backwards and the right motor should tilt forwards. -6. **Adjsut the throws of the tilt servos:** +6. **Adjust the throws of the tilt servos:** - The final step is to adjust the throws of the servos such that they are the same in both directions. - To do this, move back to the Mixer tab while in multicopter/tricopter mode and start adjusting the previously set up 50 and -50 values from the Stabilised Yaw lines. - You can try with lower values of about 30 and -30 and then increase the values until you reach the maximum travel point. - - NOTE: The maximum is reached when both servos are moving the same ammount in oposite directions and one servo does not continue to move after the other has stopped. + - NOTE: The maximum is reached when both servos are moving the same amount in opposite directions and one servo does not continue to move after the other has stopped. 7. **Check correct operation and direction:** - Cycle back and forth between the plane, transition and tricopter modes to make sure that your servos are maintaining the same setting. - For the fixed wing setting, your tilt servos should point the motors exactly forwards. - - For the multicoper/tricopter mode, the tilt servos should point the motors exactly upwards and when moving the yaw stick, both servos should tilt the motors the same ammount in opposite directions. + - For the multicopter/tricopter mode, the tilt servos should point the motors exactly upwards and when moving the yaw stick, both servos should tilt the motors the same amount in opposite directions. Optional Setup Step for Tilt Servos: 8. **Reversing tilt servos and mixer signs:** - 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 horizontal position of the tilt servos in fixed-wing mode. + 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 reverse 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/tricopter mode as well as the horizontal position of the tilt servos in fixed-wing mode. ### STEP 5: Transition Mixing (Multi-Rotor Profile)(Recommended) @@ -300,14 +300,14 @@ Verify that all the motors work in the Outputs Tab. #### Servo Mix -While in multicopter mode, the differential thurst of the motors provide roll control. +While in multicopter mode, the differential thrust of the motors provide roll control. Yaw and pitch are provided by the air moving over the elevons. Just like in fixed wing mode, create an elevon mix for yaw and pitch or copy the same mix over. ### Step 4: Enable FC Offset Because the FC changes its orientation while in tailsitter mode (multicopter), INAV needs to be told about this so the IMU is able to properly control the aircraft. -This is enabled with the paramter `tailsitter_orientation_offset = ON `. +This is enabled with the parameter `tailsitter_orientation_offset = ON `. - The baseline board aliment is FW mode (ROLL axis is the thrust axis). Set `tailsitter_orientation_offset = ON ` in the tail_sitting MC mode. @@ -329,7 +329,7 @@ Arm or force arm (WITH PROPS OFF) and apply roll inputs on your radio. ## Quad Plane Setup -A quad plane is one where there are 4 individual lift motors that are used for the vertial lift phase of flight that are then switched off for forward flight in fixed wing mode. +A quad plane is one where there are 4 individual lift motors that are used for the vertical lift phase of flight that are then switched off for forward flight in fixed wing mode. The setup procedure is the same as that's described for tilt rotors with the modification that the multirotor mixer uses a quadcopter instead. Depending on the quadcopter motor layout, select quad X or quad + in the mixer for the multirotor's mixer profile. diff --git a/docs/07-pid-tuning/navigation-pid-tuning-fw.mdx b/docs/07-pid-tuning/navigation-pid-tuning-fw.mdx index a1224d7..d7bc870 100644 --- a/docs/07-pid-tuning/navigation-pid-tuning-fw.mdx +++ b/docs/07-pid-tuning/navigation-pid-tuning-fw.mdx @@ -114,10 +114,10 @@ While [nav_fw_pitch2thr_threshold](https://github.com/iNavFlight/inav/blob/maste **Inability to obtain an accurate horizontal position can be caused by a number of reasons:** -- Poor GNSS satellite accuracy and EPH position data - _Ensure you have a HDOP less than 1.2 for best precision. And never above 1.8._ [See here](https://github.com/iNavFlight/inav/wiki/GPS-and-Compass-setup#installing-the-gnss-unit---antenna-orientation) +- Poor GNSS satellite accuracy and EPH position data - _Ensure you have a HDOP less than 1.2 for best precision. And never above 1.8._ [See here](../05-core-features/gps.mdx#installing-the-gnss-unit---antenna-orientation) - Main stabilization **PID_FF** and **RATES** are poorly tuned. -- [SERVO AUTOTRIM](https://github.com/iNavFlight/inav/wiki/Modes#servo-autotrim-fw) is not tuned correctly. -- Poorly Installed, Aligned or Calibrated magnetometer (compass) - _If a magnetometer is used, read [here](https://github.com/iNavFlight/inav/wiki/GPS-and-Compass-setup#setting-up-the-compass-alignment) to provide the best results._ +- [SERVO AUTOTRIM](../05-core-features/flight-modes-standard.mdx#servo-autotrim-fw) is not tuned correctly. +- Poorly Installed, Aligned or Calibrated magnetometer (compass) - _If a magnetometer is used, read the [Compass](../05-core-features/compass.mdx) page to provide the best results._ - High accelerometer vibrations from the motor(s) or prop(s). - _Can lead to attitude and heading inaccuracy or drift._ - The control surface throws are too great or too little. Or its C.G. with respect to the aerofoils Center of Lift/Pressure is incorrect. - If all the previous conditions are satisfied - _Incorrectly tuned POS_XY_P, POS_XY_I or POS_HDG_P if [nav_use_fw_yaw_control ](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_use_fw_yaw_control) = ON_ @@ -156,7 +156,7 @@ The advantage of this, is you won't need to tune the PID gains. You can leave th Fixedwing stabilization uses the [TURN ASSIST](../05-core-features/flight-modes-standard.mdx#turn-assist) feature to help maintain control over the aircraft. It is active in all navigation modes. But can be disabled in the modes tab if desired. -Fixedwing AutoTune does not operate on the yaw axis. This means the tuning has to be done [manually](https://github.com/iNavFlight/inav/wiki/Tune-INAV-PID%E2%80%90FF-controller-for-fixedwing#manually-tuning-rates-and-feedforward---how-it-works). +Fixedwing AutoTune does not operate on the yaw axis. This means the tuning has to be done [manually](./tune-pidff-fw.mdx#manually-tuning-rates-and-feedforward---how-it-works). The gains you derive when tuning the Yaw PID controller will differ, depending on the control method used. A Rudder induces yaw rotation from control surface area and deflection. While Differential thrust or Vectored thrust does so actively. Meaning the _Gains_ , _Feedforward_ and _Mixers_ adjustments will be more sensitive to change if using the latter on more powerful models. _Differential thrust yaw stabilization strength is also dependent on how much throttle stick you have applied._ @@ -169,7 +169,7 @@ While the **mmix** motor yaw weight works together with `fw_ff_yaw` to achieve t The default motor mixer weight for yaw is [`0.3 -0.3`]. When increasing the yaw motor mixer weight, it MUST be done in **harmony** with the first three navigation setting mentioned hereafter. Under normal flight conditions, the default motor mixer weight is adequate. While it maybe acceptable to go as high as [`0.7 -0.7`] on highly aerobatic airplanes. But it should be noted that this WILL affect yaw based navigation if those first three settings are increased too far beyond their recommended values. -More mixer related information can be found [here](https://github.com/iNavFlight/inav/blob/master/docs/Mixer.md). +More mixer related information can be found on the [Mixer](../05-core-features/mixer.mdx) page. _Yaw axis tuning should only be attempted after you have first successfully tuned the airplane on the roll and pitch axis._ @@ -224,7 +224,7 @@ If you experience this, it may be beneficial to disable the sensor in the Config - `inav_w_z_surface_v` - Weight applied to the Rangefinders estimated _climb rate_. When a rangefinder is present, within its operational distance above the ground. :::tip -When choosing a [Lidar rangefinder](https://github.com/iNavFlight/inav/blob/master/docs/Rangefinder.md) for fixedwing landing assistance. Ensure you do not purchased a cheaper unit with minimal range. e.g. 2meters or less. +When choosing a [Lidar rangefinder](../05-core-features/optical-flow-rangefinder.mdx) for fixedwing landing assistance. Ensure you do not purchased a cheaper unit with minimal range. e.g. 2meters or less. Such Lidar sensors have great difficulty working at even one quarter of their recommended range in direct sun light. Always select a higher quality unit with a stronger laser diode and lens, to provide more operational range. ::: diff --git a/docs/07-pid-tuning/navigation-pid-tuning-mc.mdx b/docs/07-pid-tuning/navigation-pid-tuning-mc.mdx index 8254c7b..c82327c 100644 --- a/docs/07-pid-tuning/navigation-pid-tuning-mc.mdx +++ b/docs/07-pid-tuning/navigation-pid-tuning-mc.mdx @@ -38,7 +38,7 @@ This is because the output from the navigation controllers are place into action - Incorrectly set [nav_mc_hover_thr](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_mc_hover_thr) - Adjust this setting to suit what your copter requires to hold a vertical stationary hover. - Insufficient POS*P, POS_I and/or VEL_P, VEL_I - \_The default multicopter Altitude PID gains are set conservative for safety.* - Non-functional barometer - _Go to the Configurator "\_Sensors tab_" and verify that barometer graph changes as you move the copter up and down.\_ -- Poor GNSS satellite accuracy and EPV altitude data - _Ensure you have a HDOP less than 1.2 for best precision. And never above 1.8. [Possible causes](https://github.com/iNavFlight/inav/wiki/GPS-and-Compass-setup#installing-the-gnss-unit---antenna-orientation)_ +- Poor GNSS satellite accuracy and EPV altitude data - _Ensure you have a HDOP less than 1.2 for best precision. And never above 1.8. [Possible causes](../05-core-features/gps.mdx#installing-the-gnss-unit---antenna-orientation)_ - Seriously under-powered copter - _ALTHOLD is only able to compensate to some degree. If your copter hovers at 1700 linear throttle without any expo, ALTHOLD might fail to compensate._ - Gaining altitude during fast flight - _Can be caused by increased air pressure being applied to the barometer. This is measured as a reduction in altitude - Try covering your barometer with open-cell foam._ @@ -161,7 +161,7 @@ However, lowering it to 1, can still help on copters that pitch/roll bounce, as Increasing its value beyond 30 can make the corresponding axis more jittery when trying to maintain a level attitude. Its responsiveness will also be dependent on - **1)** Motor power **2)** ESC braking effect **3)** The tightness of the main stabilization PID tune. -- `mc_i_level` works as a Low Pass Filter for the LEVEL controllers update rate. The default value of 15 is optimal, and works in conjunction with [`acc_lpf_hz`](https://github.com/iNavFlight/inav/wiki/Multirotor-guide#5-selecting-filters). This means that `fw_i_level` will add no benefit if set higher than the accelerometers low-pass cutoff frequency. +- `mc_i_level` works as a Low Pass Filter for the LEVEL controllers update rate. The default value of 15 is optimal, and works in conjunction with [`acc_lpf_hz`](../03-getting-started/06-mr-gettingstarted.mdx#5-selecting-filters). This means that `fw_i_level` will add no benefit if set higher than the accelerometers low-pass cutoff frequency. In some cases it may be better to lower it a few points. Because most larger multicopters can not adjust their level attitude at 15 times per second or greater. @@ -212,7 +212,7 @@ If you've connected and configured everything correctly. You should see the Sonar & Opflow sensors active and ready (blue). If they have appeared in red, plug in the flight battery for them to show as active or recheck the serial TX/RX wiring. -At miniumum, you should have Gyro, Accelerometer, Barometer, Flow and Sonar active for the rangefinder to operate. +At minimum, you should have Gyro, Accelerometer, Barometer, Flow and Sonar active for the rangefinder to operate. ![Sensors highlight Opflow and Lidar](/img/pid-tune/mc-nav-pid-tune-02.png) diff --git a/docs/07-pid-tuning/pid-attentuation-and-scaling.mdx b/docs/07-pid-tuning/pid-attentuation-and-scaling.mdx index f8ee4ec..9d9e3e7 100644 --- a/docs/07-pid-tuning/pid-attentuation-and-scaling.mdx +++ b/docs/07-pid-tuning/pid-attentuation-and-scaling.mdx @@ -130,7 +130,7 @@ See [TPA and Pitch angle plot](./pid-attentuation-and-scaling.mdx#example-of-a-f * `tpa_pitch_compensation` - is used to calculate the collective effect pitch _(gravity)_ will exert on-top of the raw throttle command, to _reverse_ the way gains are dynamically adjusted in response to the throttle. Put simply - Boosted gains will begin to Attenuate, and Attenuated gains will begin to Boost under certain flight conditions. -Range `0 - 20` - default = 8, DECREASING its value will provide a weaker gravity induced pitch angle influence over the raw throttle, and therefor the gains. +Range `0 - 20` - default = 8, DECREASING its value will provide a weaker gravity induced pitch angle influence over the raw throttle, and therefore the gains. Conversely, INCREASING it will provide a stronger pitch angle influence over the raw throttle. See [TPA and Pitch angle plot](./pid-attentuation-and-scaling.mdx#example-of-a-fixedwing-tpa--pitch-angle) diff --git a/docs/08-mission-control/geozones.mdx b/docs/08-mission-control/geozones.mdx index 0e0c426..82467fc 100644 --- a/docs/08-mission-control/geozones.mdx +++ b/docs/08-mission-control/geozones.mdx @@ -64,7 +64,7 @@ The most important feature for safety is the automatic path planning for RTH (St - Exclusive NFZ with an upper or lower limit other than 0 can be overflown and underflown. The Automatic avoidance will only fly above NFZ if possible and never below. - Actions: - Avoid: Also called “Bounce” (only airplanes): The aircraft flies away from the boundary at the same angle it approached it, like a pool ball bouncing off the table border. Multirotor will switch into "Position Hold". - - Hold: Position in front of the boundary is held. Airplances will adjust their loiter center according to the loider radius, to stay away from the border while circling. + - Hold: Position in front of the boundary is held. Airplanes will adjust their loiter center according to the loiter radius, to stay away from the border while circling. - RTH: Triggers Return To Home. The Failsafe RTH Procedure is executed, so RTH Trackback is also used if enabled for Failsafe situations. - None: No action (only info in OSD). - RTH: @@ -111,7 +111,7 @@ The Geozone Information are stored in two separate data arrays. The first array The following commands are available for users: - `geozone` without argument lists the current settings -- `geozone reset ` resets a specific geozone and all related vertices. If no ID proveded, all geozones and vertices will be deleted. +- `geozone reset ` resets a specific geozone and all related vertices. If no ID provided, all geozones and vertices will be deleted. - `geozone vertex` - lists all vertices. - `geozone vertex reset` - deletes all vertices. - `geozone vertex reset ` - Deletes all vertices of the zone. @@ -130,10 +130,10 @@ The following information are for app-developers. _DO NOT EDIT GEOZONES MANUALLY - fence action: 0 = None, 1 = Avoid, 2 = Position hold, 3 = Return To Home - vertices count: 0-126 - Sanity check if number of vertices matches with configured zones -`geozone vertex ` +`geozone vertex ` - zone id: (0-63) The zone id to which this vertex belongs - vertex idx: Index of the vertex (0-126) -- latitude/ logitude: Longitude and latitude of the vertex. Values in decimal degrees * 1e7. Example:the value 47.562004o becomes 475620040 +- latitude/ longitude: Longitude and latitude of the vertex. Values in decimal degrees * 1e7. Example:the value 47.562004o becomes 475620040 diff --git a/docs/08-mission-control/safehomes.mdx b/docs/08-mission-control/safehomes.mdx index ea56981..4533776 100644 --- a/docs/08-mission-control/safehomes.mdx +++ b/docs/08-mission-control/safehomes.mdx @@ -12,7 +12,7 @@ For airplanes, information about the auto landing procedure can be found in the ![Fixed wing loiter and descend](/img/mission-control/safehome-loiter-decend.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. +One potential risk when landing is that there might be buildings, trees and other obstacles in the way as the airplane circles lower toward the ground at the arming point. Most people don't go the middle of the field when arming their airplanes. To solve this issue, the idea of Safehomes is available in INAV. @@ -134,7 +134,7 @@ Parameters: - `` - Longitude. Note that coordinates from Google Maps only have five or six decimals, so you need to pad zero decimals until you have seven before removing the decimal period to set the correct safehome location. -For example, coordinates 54.353319 -4.517927 obtained from Google Maps need to be entered as 543533190 -45179270, coordiniates 43.54648 -7.86545 as 435464800 -78654500 and 51.309842 -0.095651 as 513098420 -00956510. +For example, coordinates 54.353319 -4.517927 obtained from Google Maps need to be entered as 543533190 -45179270, coordinates 43.54648 -7.86545 as 435464800 -78654500 and 51.309842 -0.095651 as 513098420 -00956510. Safehomes are saved along with your regular settings and will appear in `diff` and `dump` output. Use `save` to save any changes, as with other settings. diff --git a/docs/08-mission-control/waypoint-missions.mdx b/docs/08-mission-control/waypoint-missions.mdx index db30653..5932a6b 100644 --- a/docs/08-mission-control/waypoint-missions.mdx +++ b/docs/08-mission-control/waypoint-missions.mdx @@ -63,7 +63,7 @@ Waypoint radius | [nav_wp_radius](https://github.com/iNavFlight/inav/blob/master Waypoint safe distance | [nav_wp_max_safe_distance](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_wp_max_safe_distance) | The first waypoint in the mission should be closer than this value [m]. A value of 0 disables this check. Load Waypoints on Boot | [nav_wp_load_on_boot](https://github.com/iNavFlight/inav/blob/9.0.1/docs/Settings.md#nav_wp_load_on_boot) | If set to ON, waypoints will be automatically loaded from EEPROM to the FC during startup. Enforce Altitude at Waypoint | [nav_wp_enforce_altitude](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_wp_enforce_altitude) | Forces craft to achieve the set WP altitude as well as position before moving to next WP. Position is held and altitude adjusted as required before moving on. 0 = disabled, otherwise setting defines altitude capture tolerance [cm], e.g. 100 means required altitude is achieved when within 100cm of waypoint altitude setting. -Waypoint Tracking Accuracy | [nav_fw_wp_tracking_accuracy](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_tracking_accuracy) | Waypoint tracking accuracy forces the craft to quickly head toward and track along the waypoint course line as closely as possible. Setting adjusts tracking deadband distance fom waypoint courseline [m]. Tracking isn't actively controlled within the deadband providing smoother flight adjustments but less accurate tracking. A 2m deadband should work OK in most cases. Setting to 0 disables waypoint tracking accuracy. +Waypoint Tracking Accuracy | [nav_fw_wp_tracking_accuracy](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_tracking_accuracy) | Waypoint tracking accuracy forces the craft to quickly head toward and track along the waypoint course line as closely as possible. Setting adjusts tracking deadband distance from waypoint courseline [m]. Tracking isn't actively controlled within the deadband providing smoother flight adjustments but less accurate tracking. A 2m deadband should work OK in most cases. Setting to 0 disables waypoint tracking accuracy. Waypoint Tracking Angle | [nav_fw_wp_tracking_max_angle](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_tracking_max_angle) | Sets the maximum allowed alignment convergence angle to the waypoint course line when nav_fw_wp_tracking_accuracy is active [degrees]. Lower values result in smoother alignment with the course line but will take more distance until this is achieved. Waypoint Turn Mode | [nav_fw_wp_turn_mode](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_turn_mode) | Fixed wing only. How the plane turns at mission waypoints: `COORD_FLYBY` (default) cuts the corner and passes the waypoint abeam, `COORD_FLYOVER` flies over the waypoint before turning onto the next leg, `COORD_FLYINTO` crosses the waypoint already aligned with the outbound leg, `DIRECT` restores the pre INAV 10.0 turns. See [Fixed Wing Waypoint Turns](../06-advanced-features/fixed-wing-waypoint-turns.mdx). Max Turn Lead Time | [nav_fw_wp_turn_max_lead_time](https://github.com/iNavFlight/inav/blob/master/docs/Settings.md#nav_fw_wp_turn_max_lead_time) | Fixed wing only. Ceiling on how early a coordinated turn may start before the waypoint [ms]. Raise it for fast or sluggish models flying sharp corners, lower it to keep turns close to the waypoint. `COORD_FLYBY` only. @@ -74,7 +74,7 @@ Restart Waypoint Mission | [nav_wp_mission_restart](https://github.com/iNavFligh ## Waypoint Types -INAV offers serveral different waypoint types that each have unique functions. +INAV offers several different waypoint types that each have unique functions. This section describes each of the waypoint types. ### Waypoint @@ -115,7 +115,7 @@ A POI waypoint tells the multicopter to point its head (its front) to the POI un Multiple POI waypoints can be used in a single mission. The POI will be active on the *n-1* to *n+i* where *i* is an arbitrary number of waypoints after the POI waypoint. -If the POI waypoint is the first waypint, it will be active on the *n* to *n+i* waypoints until a SET_HEAD is reset on waypoint *n+i* or the mission ends. +If the POI waypoint is the first waypoint, it will be active on the *n* to *n+i* waypoints until a SET_HEAD is reset on waypoint *n+i* or the mission ends. **Example:** @@ -134,7 +134,7 @@ The CLI setting `nav_disarm_on_landing` is honoured. -For fixed wings there are additional parameters given to specifiy the landing behavior. +For fixed wings there are additional parameters given to specify the landing behavior. These parameters are: ![land wp](/img/mission-control/wp-land.png) diff --git a/src/components/HomepageFeatures/index.tsx b/src/components/HomepageFeatures/index.tsx index 7abb4d2..471d143 100644 --- a/src/components/HomepageFeatures/index.tsx +++ b/src/components/HomepageFeatures/index.tsx @@ -24,7 +24,7 @@ const FeatureList: FeatureItem[] = [ Svg: require('@site/static/img/assets/code.svg').default, description: ( <> - INAV is free and open source software that is actively developed by many contributers from around the world. Large version releases occur annually and smaller, maintenance releases throughout the year. + INAV is free and open source software that is actively developed by many contributors from around the world. Large version releases occur annually and smaller, maintenance releases throughout the year. ), }, diff --git a/src/pages/download.tsx b/src/pages/download.tsx index 2850dba..ecbd39e 100644 --- a/src/pages/download.tsx +++ b/src/pages/download.tsx @@ -61,7 +61,7 @@ export default function Downloads() { />

Enhance the INAV experience with the Lua widget for EdgeTX - and OpenTX based radios that fully uses telemtry data. + and OpenTX based radios that fully uses telemetry data.

From 19f62de0aacf01f128833fa2c308cefa559252b8 Mon Sep 17 00:00:00 2001 From: Raphael Hunziker Date: Thu, 10 Sep 2026 19:53:58 +0200 Subject: [PATCH 4/4] docs: keep the CLI reference readable when GitHub is unreachable Caching was limited to release tags, so the branch-backed page had to reach GitHub on every mount and any transient failure replaced the whole page with an error message. Successful responses are now stored for branches as well. A branch still asks for a fresh copy every time, but when that request fails the last successful copy is shown together with a note naming its date. A release tag is still served straight from the cache without a request. --- src/components/RemoteMarkdown.tsx | 63 ++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 21 deletions(-) diff --git a/src/components/RemoteMarkdown.tsx b/src/components/RemoteMarkdown.tsx index 3434fc1..a416d94 100644 --- a/src/components/RemoteMarkdown.tsx +++ b/src/components/RemoteMarkdown.tsx @@ -68,6 +68,7 @@ const RemoteMarkdown: React.FC = ({ const [html, setHtml] = useState(''); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); + const [staleSince, setStaleSince] = useState(null); useEffect(() => { let isMounted = true; @@ -75,22 +76,23 @@ const RemoteMarkdown: React.FC = ({ const loadMarkdown = async () => { setLoading(true); setError(null); + setStaleSince(null); - // Release tags never change, so they can be served from the cache. - // Branches move, so they are always fetched fresh. - if (isReleaseTag(tag)) { - const cached = getCachedData(tag); - if (cached && cached.tag === tag) { - if (isMounted) { - setMarkdown(cached.markdown); - setHtml(cached.html); - setLoading(false); - } - return; + const stored = getCachedData(tag); + const cached = stored && stored.tag === tag ? stored : null; + + // A release tag always points at the same commit, so a cached copy of it + // is still current and no request is needed. + if (cached && isReleaseTag(tag)) { + if (isMounted) { + setMarkdown(cached.markdown); + setHtml(cached.html); + setLoading(false); } + return; } - // Fetch from remote + // A branch moves, so ask for a fresh copy every time. try { const url = constructUrl(tag); const response = await fetch(url); @@ -107,12 +109,19 @@ const RemoteMarkdown: React.FC = ({ setMarkdown(source); setHtml(rendered); - if (isReleaseTag(tag)) { - setCachedData(tag, source, rendered); - } + setCachedData(tag, source, rendered); } catch (err) { const message = err instanceof Error ? err.message : String(err); - if (isMounted) { + if (!isMounted) { + return; + } + // Show the last copy that was fetched successfully instead of replacing + // the whole page with an error when the request fails. + if (cached) { + setMarkdown(cached.markdown); + setHtml(cached.html); + setStaleSince(cached.fetchedAt); + } else { setError(message); } } finally { @@ -151,11 +160,23 @@ const RemoteMarkdown: React.FC = ({ } return ( -
+ <> + {staleSince !== null && ( +
+ GitHub could not be reached. This is the copy stored in your browser + on {new Date(staleSince).toLocaleString()}. +
+ )} +
+ ); };