Dev Call Aug 10, 2026

plane_follow.lua autotest with two SITL instances (#33432)

master ← timtuxworth:pr-planefollow-autotest-dual

opened 03:46PM - 13 Jun 26 UTC

timtuxworth

+1369 -211

### Summary Add an autotest for plane_follow.lua ### Classification & Test…ing (check all that apply and add your own) - [X] Checked by a human programmer - [X] Non-functional change - [X] No-binary change - [X] Infrastructure change (e.g. unit tests, helper scripts) - [X] Automated test(s) verify changes (e.g. unit test, autotest) - [X] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request This adds an autotest for plane_follow.lua which requires running two SITL instances at the same time, so includes substantial changes to vehicle_test_suite.py to accommodate this. I had extensive help from Claude on this, but it was pretty much "supervised" with Claude making suggestions and me reviewing each change and accepting or rejecting the suggestions. ### Description This adds a "PlaneFollowApplet" test which uses the existing SITL instance as the "follow" vehicle and starts a second SITL instance as the target. Then the target starts an auto mission and the follow vehicle is monitored while it attempts to track the target. To make this work, many infrastructure functions need a "mav" parameter and sometimes a target_sysid parameter to allow selecting which instance to talk to. e.g. `def disarm_vehicle(self, timeout=60, force=False, mav=None, target_sysid=None): ` The default is "None", so existing calls to these function will continue to work as is. In some cases the functions now have a "multi mav" path to allow them to work correctly if running with multiple live "mav" (SITL instances). This pattern might be usable to test the Copter FOLLOW mode. Now runs at a 15x speedup which is about 50% of regular tests which typically achieve about 25x (even though set to an aspirational 100x)

AP_HAL_ChibiOS: add support for FlyFishRC F405 flight controller (#33624)

master ← RomanKalinchuk:add-FlyFishRCF405-board

opened 01:09PM - 01 Jul 26 UTC

RomanKalinchuk

+1266 -0

### Summary Add hardware support for the FlyFishRC F405 flight controller bas…ed on the STM32F405xx MCU. ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [ ] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [x] Tested on hardware - [ ] Logs attached - [ ] Logs available on request Tested ArduRover firmware on hardware. Board boots, USB enumerates, and connects successfully to QGroundControl. ### Description New board definition for the FlyFishRC F405 flight controller. Hardware: - MCU: STM32F405xx - IMU: ICM-42688-P (SPI1, CW90 rotation) - Barometer: DPS310 (I2C1, 0x76) - OSD: MAX7456 (SPI2) - Dataflash: SPI3 - 8 PWM/DShot outputs (TIM1, TIM3, TIM8) - 1 NeoPixel output (TIM2) - 6 UARTs (USART1 RC, USART6 GPS) - USB CDC (OTG_FS) - Battery voltage and current sensing - Buzzer, PINIO (VTX/camera switch)

AP_Rangefinder: add power down state and use it for TFMini Plus (#33712)

master ← IamPete1:rangefinder_powerDown

opened 03:11AM - 14 Jul 26 UTC

+174 -35

### Summary This builds on https://github.com/ArduPilot/ardupilot/pull/33…709. It allows the TFMini Plus to be turned off based on the existing max range param `RNGFNDx_PWRRNG`. The TFMini Plus has a operating range of 12m, so you might set it to power off when the vehicle is above 150m for example. The goal here is to save power. ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [ ] Automated test(s) verify changes (e.g. unit test, autotest) - [x] Tested manually, description below (e.g. SITL) - [x] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description Just basing this on height above ground from the vehicle could be quite wrong in some cases. Plane will use the terrain database if available but fall back to home. A better approach might be to use flight phase, but might cause race conditions where for example rangefinder is not on until the landing has stated so there is no good readings until the rangefinder has powered up. I suspect most of the other rangefinders could implement this, although it is not possible over DroneCAN as far as I can tell. We could also just remove the functionality, its currently only used by the PWM backend.

Plane: gradual RTL altitude descent in QRTL approach (#33786)

master ← Hwurzburg:qrtl-gradual-rtl-alt-descent

opened 06:04PM - 21 Jul 26 UTC

Hwurzburg

+166 -8

## Summary - Changes how QRTL's approach phase handles altitude when the vehicle… is well above `RTL_ALTITUDE` when the return leg starts. - Previously, once QRTL's approach phase began, the target altitude snapped straight to `RTL_ALTITUDE` regardless of how much higher the vehicle actually was, causing an immediate steep descent while still far from home. - The target now ramps down gradually from the vehicle's actual altitude at the start of the leg down to `RTL_ALTITUDE`, reaching it at the same distance-from-home threshold where the existing `RTL_ALTITUDE -> Q_RTL_ALT` approach ramp already begins — so the two ramps join continuously. - If the vehicle is at or below `RTL_ALTITUDE` at that point, behaviour is unchanged. - This is now the standard QRTL behaviour (no `Q_OPTIONS` bit needed). ## Test plan - [x] `./waf plane` builds cleanly - [x] Added `QRTLGradualAltDescent` SITL autotest (`Tools/autotest/quadplane.py`, run via `test.QuadPlane.QRTLGradualAltDescent`), which flies out ~900m, triggers QRTL, and asserts the vehicle does not shed more than 15m of altitude in the first 15 seconds, then completes a normal VTOL landing. - [x] Verified the test fails without the fix (drop of 17m in 7s reverting `mode_qrtl.cpp`/`mode.h`) and passes with it.

Tools: build_options.py: remove bad dep for MAVLINK_SIGNING (#33798)

master ← peterbarker:pr/bad-signing-dep

opened 04:00AM - 23 Jul 26 UTC

+1 -1

### Summary fixes bad dependency in build_options.py entry for mavlink-signin…g feature - it definitely doesn't need rangefinder! ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [x] Non-functional change - [x] No-binary change - [x] Infrastructure change (e.g. unit tests, helper scripts) - [ ] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description copy/paste error from duplicated line

Make your-commit-messages-suck error message clearer in CI (#33802)

master ← peterbarker:pr-claude/subsystem-prefix-better

opened 05:13AM - 23 Jul 26 UTC

+66 -21

### Summary Tries to make the error message presented on bad commit prefix cl…earer ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [x] Non-functional change - [x] No-binary change - [x] Infrastructure change (e.g. unit tests, helper scripts) - [ ] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ``` Testing — built six throwaway prefix-less commits, ran the checker against them, then git reset --hard them away: ┌────────────────────────────────────────────────────┬────────────────────┐ │ commit touches │ suggested │ ├────────────────────────────────────────────────────┼────────────────────┤ │ libraries/AP_GPS/AP_GPS.cpp │ AP_GPS: │ ├────────────────────────────────────────────────────┼────────────────────┤ │ │ autotest: │ │ Tools/autotest/arducopter.py │ (preferred over │ │ │ Tools) │ ├────────────────────────────────────────────────────┼────────────────────┤ │ │ AP_HAL_ChibiOS: │ │ libraries/AP_HAL_ChibiOS/hwdef/Pixhawk1/hwdef.dat │ (preferred over │ │ │ hwdef) │ ├────────────────────────────────────────────────────┼────────────────────┤ │ Tools/autotest/arduplane.py + │ Tools: (the shared │ │ Tools/scripts/build_ci.sh │ candidate) │ ├────────────────────────────────────────────────────┼────────────────────┤ │ libraries/AP_GPS/AP_GPS.h + ArduPlane/Plane.h │ falls back to e.g. │ │ │ 'AP_Compass:' │ ├────────────────────────────────────────────────────┼────────────────────┤ │ unmapped zzz_unmapped/f.txt │ falls back to e.g. │ │ │ 'AP_Compass:' │ └────────────────────────────────────────────────────┴────────────────────┘ ``` ### Description Adjusts the error message to give a likely-looking subsystem rather than the static "AP_Compass". Also rewords things to try to make it clear we're talking about the commit message - not the PR title. We're *still* not clear enough on the subject.

Plane: Quadplane: enable weathervane in VTOL auto (#33836)

master ← IamPete1:plane_VTOL_auto_weatherbane

opened 02:21PM - 26 Jul 26 UTC

+36 -4

### Summary This enables weathervaning in VTOL auto (Q_ENABLE = 2). ##…# Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [ ] Automated test(s) verify changes (e.g. unit test, autotest) - [x] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description This does mean that weathervane can kick in and out, based on the speed threshold for example, once it kicks out the vehicle will default back to pointing at the next waypoint.

Plane: Quadplane: add a loiter stage in VTOL land approach with a loiter time of `Q_RTL_PAUSE_TIME` (#33842)

master ← IamPete1:quadplane_qtl_loiter

opened 09:01PM - 26 Jul 26 UTC

+116 -21

### Summary This adds a param for a delay above the landing location before t…he landing decent is started. By default it is 0 so there is no change in behavior. ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [x] Automated test(s) verify changes (e.g. unit test, autotest) - [x] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description The default is set to 5 seconds for tailsitters which replaces https://github.com/ArduPilot/ardupilot/pull/26417 and fixes https://github.com/ArduPilot/ardupilot/issues/25771 and https://github.com/ArduPilot/ardupilot/issues/29943

AP_OSD: use Betaflight SYM_TOTAL_DISTANCE for DisplayPort distance icon (#33908)

master ← coreyfarley:osd-displayport-dist-symbol

opened 11:11PM - 31 Jul 26 UTC

coreyfarley

+2 -2

### Summary Fixes the DJI O4 OSD showing a throttle icon next to the distance…-flown panel by remapping SYM_DIST from 0x04 to 0x71 in the MSP DisplayPort BTFL font table. Also remaps SYM_LQ from 0xF8, which rendered no icon, to 0x7B (SYM_LINK_QUALITY). Fixes #33895 ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [ ] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [x] Tested on hardware - [ ] Logs attached - [ ] Logs available on request Hardware testing by @boa-pe: MicoairH743v2 + DJI O4 and O4 Pro + Goggles 3 and both icons confirmed displaying correctly (see PR comments) Compiled successfully for SITL copter. Glyph correctness verified against the OSD glyph [reference](https://betaflight.com/docs/development/OSD-Glyps) The reporter's parameter file (shared in the forum thread) confirms MSP_OPTIONS=4 (Betaflight fonts) and OSD_TYPE=5 (MSP DisplayPort) ### Description The OSDn_DIST (distance flown) panel prefixes its values with SYM_DIST. On MSP DisplayPort with Betaflight fonts enabled, SYM_DIST was mapped to font index 0x04 which in the Betaflight font is SYM_THR. This resulted in the DJI goggles drawing a throttle symbol next to the distance value. This remap to 0x71 is the proper total distance glyph Betaflight uses - SYM_TOTAL_DISTANCE. SYM_LQ (link quality) was similar, mapped to 0xF8 which has no glyph defined in the Betaflight font, so no icon rendered. 0x7B is defined as SYM_LINK_QUALITY in osd_symbols.h

Move defines back out of _config.h back into .h files (#33915)

master ← peterbarker:pr-claude/move-defines-from-config.h-to-.h

opened 11:04PM - 02 Aug 26 UTC

+269 -259

### Summary moves config for libraries back into the header files from the co…nfig.h files ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [x] Non-functional change - [x] No-binary change (verified) - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [ ] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description the _config.h files are *not* supposed to be some sort of externally-visible-vs-internally-visibly split for library defines. They are expected to be the bare minimum to allow the feature defines to work. Move as much information as sensible back from _config.h to .h file This improves TU re-use as the `_config.h` files are included quite widely - so improving compiler cache hitrates (esp. when combined with PRs that make transitively including `hwdef.h` via `AP_HAL_Boards.h` less of a problem). Also fixes a few transient include problems.

Lift airspeed and wind estimation up into AP_AHRS_Backend, use in ExternalAHRS (#33946)

master ← peterbarker:pr-claude/ahrs-airspeed-eas-lift

opened 02:21AM - 05 Aug 26 UTC

+195 -67

### Summary Moves estimation up from being DCM-specific to be generally avail…able to backends which can provide a groundspeed (or there's an airspeed sensor) ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [x] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description Moves various methods up to AP_AHRS_Backend from AP_AHRS_DCM. Moved method now takes the information required as parameters. There's nothing DCM-specific about either the delta-fuse or wind triangle calculations. Future enhancements will probably create a little estimation object containing all of the members. I have retained the current member names to prevent code churn and make the code changes in this PR less scary. The wording of "velocity source" is quite intentional - we just need an earth-frame velocity - it's always been DCM to date, but it could be beacons, Optical flow, ..... so long as airspeed wasn't involved it should all be good. I haven't moved the namespace-changed methods from file to file. At some stage we might want a history-problematic commit which moves all of the AHRS methods into their correct place, there's a fair bit of weirdness now. Pretty sure the shape of the AP_AHRS_ExternalAHRS patch (needing the semaphore for a consistent story from AP_ExternalAHRS is saying we should be looking at making `AP_ExternalAHRS` an `AP_AHRS_Backend`, or perhaps just passing `get_results` through to an `AP_ExternalAHRS::get_results` for the most part. ~Currently draft because it is relying on a MicroStrain bugfix to not introduce a bug.~

Copter: simple mode fix (#33947)

master ← rmackay9:copter-simple-mode-fix

opened 03:35AM - 05 Aug 26 UTC

rmackay9

+87 -125

This resolves issue https://github.com/ArduPilot/ardupilot/issues/33936 Repla…ces **update_simple_mode** with **apply_simple_mode** that takes roll and pitch input arguments. The rotation is now done within the various get-pilot-desired-xxx methods removing the need for each flight mode to call update_simple_mode and also removing the slightly ugly call to overwrite RC_Channels' control inputs from the flight code (e.g. no more calls to set_control_in) This fix also introduces these changes which I think are OK: - Drift mode and Precision Landing's repositioning now support simple mode - Save trim also works in simple mode although the user needs to be careful not to change the vehicle's heading while landing and saving the trim. This has been tested in SITL in Acro, AltHold, Drift, Loiter and Land modes to ensure both simple mode and super simple mode work as expected. Below are the modes I've tested: - [x] Acro (both multicopters and heli) - [x] Drift - [x] Sport - [x] Precision Landing repositioning - [x] Save Trim A new autotest borrowed from PR https://github.com/ArduPilot/ardupilot/pull/33939 ensure the behaviour is correct so that this doesn't happen again Below are some screen shots of testing save trim in SITL. During this test did this: - manually set AHRS_TRIM_X to 0.0872 (e.g. 5 deg) - armed and took off to 20-ish meters - engaged simple mode - rotated the vehicle's yaw to point south - because of the AHRS_TRIM_X the vehicle drifted quite quickly to its right - applied RC roll and pitch input until the vehicle came to a stop - manually landed and used the aux switch to **save trim** - checked the AHRS_TRIM_X, Y values to confirm they were close to zero (much improved from the initial 5deg) <img width="817" height="1279" alt="sitl-testing" src="https://github.com/user-attachments/assets/ffa14d8a-ab1b-4311-af76-820ff9356d46" /> ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [x] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [x] Logs available on request

Plane: re-init wp_nav on AUTO mode entry to pick up WP_SPD changes (#33953)

master ← tinhien11:fix/wp-spd-reboot-required

opened 07:58AM - 05 Aug 26 UTC

tinhien11

+32 -0

## Summary - ArduPlane's `ModeAuto::_enter()` now calls `wp_nav->wp_and_spline_i…nit_m()` when quadplane is available, matching ArduCopter's `mode_auto` init. - This lets `WP_SPD` / `Q_WP_SPD` parameter changes take effect on AUTO mode entry (no reboot required), instead of requiring a reboot. - Reverts the previously added `@RebootRequired: True` annotation on `WP_SPD`, since a reboot is no longer needed. ## Why this is needed On QuadPlane, `WP_SPD` / `Q_WP_SPD` changes had no effect until reboot: 1. `wp_and_spline_init_m(speed_ms)` sets `_check_wp_speed_change = !is_positive(speed_ms)` (AC_WPNav.cpp:227). With a positive `speed_ms`, the flag is locked to `false`. 2. ArduCopter `mode_auto.cpp:42` calls `wp_nav->wp_and_spline_init_m()` (no arg) on mode entry, which sets the flag to `true` and lets `update_wpnav()` pick up the new param. 3. ArduPlane `mode_auto.cpp` `_enter()` did **not** call it. When `QuadPlane::waypoint_controller()` later ran, `set_wp_destination_NED_m()` called `wp_and_spline_init_m(_wp_desired_speed_ne_ms)` with the **old** runtime speed (positive), locking the flag to `false`. The new param value was never applied. 4. Only `quadplane.cpp:856` (boot) called `wp_and_spline_init_m()` with no args, so a reboot was the only way to pick up the change. ## Fix Call `wp_nav->wp_and_spline_init_m()` on AUTO mode entry in ArduPlane when quadplane is available. This sets `_check_wp_speed_change = true`, so `update_wpnav()` (AC_WPNav.cpp:688) detects the param change and applies the new speed on AUTO entry. Behaviour now matches ArduCopter. **Note:** mid-mission param changes (without leaving AUTO) are still not applied on QuadPlane, because `QuadPlane::waypoint_controller()` calls `set_wp_destination_NED_m()` every 500ms, which re-calls `wp_and_spline_init_m(_wp_desired_speed_ne_ms)` and resets `_check_wp_speed_change = false`. This matches what @rmackay9 noted: "it will take effect the next time the vehicle enters Auto mode". A follow-up PR could address mid-mission changes if needed. `SPD_UP` and `SPD_DN` are unaffected — their change detection in `update_wpnav()` is ungated and already worked mid-mission. ## SITL test evidence (QuadPlane, VTOL-only mode Q_ENABLE=2) Test script: set `Q_WP_SPD=12` while disarmed → arm → enter AUTO → wait for cruise → measure ground speed. | Build | Q_WP_SPD | Ground speed | Expected | |---|---|---|---| | **Without fix** (master) | 12 | **4.89 m/s** | ~12 (stuck at old default ~5) | | **With fix** (this PR) | 12 | **10.84 m/s** | ~12 (param applied on AUTO entry) | The fix works: entering AUTO re-syncs `WP_SPD` without a reboot. Without the fix, the param change is ignored and the vehicle flies at the old default speed. ## Forum reports - https://discuss.ardupilot.org/t/q-wp-radius-and-q-wp-speed-quadplane-in-auto-mode/138387 - https://discuss.ardupilot.org/t/change-speed-command-not-working-in-quadplane/82781 ## Refs - Issue: #33952 - Reviewer feedback: @rmackay9 noted "reboot required is not accurate, it will take effect the next time the vehicle enters Auto mode"; @IamPete1 preferred "fix plane so it works the same as copter". This PR implements that fix — WP_SPD now takes effect on AUTO mode entry, matching ArduCopter. #### Test plan - [x] `./waf plane` builds successfully (SITL) - [x] SITL QuadPlane (Q_ENABLE=2): set `Q_WP_SPD=12` disarmed → arm → AUTO → ground speed ~10.8 m/s (param applied, no reboot) - [x] SITL baseline (without fix): same test → ground speed ~4.9 m/s (param ignored, stuck at old default) - [ ] No regression on ArduCopter (unaffected — already called `wp_and_spline_init_m()` on mode entry) This contribution was AI-assisted (Devin helped trace the code path, implement the fix, and run SITL tests). The human author reviewed and understands every line.

Scripted Bendy Ruler based Object Avoidance for Plane (#33955)

master ← timtuxworth:pr-scripted-oa

opened 09:47PM - 05 Aug 26 UTC

timtuxworth

+6117 -21

### Summary Add **planedaa**, a scripted Detect-Alert-Avoid (DAA) capabilit…y for Plane that avoids geofences and ADS-B traffic, together with the supporting library plumbing (`AP_OAScripting`, ADS-B/avoidance queries) and a SITL autotest suite. ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [x] Infrastructure change (e.g. unit tests, helper scripts) - [x] Automated test(s) verify changes (e.g. unit test, autotest) - [x] Tested manually, description below (e.g. SITL) - [x] Tested on hardware - [ ] Logs attached - [x] Logs available on request **Testing** - **Real World:** the applet has had extensive field testing on real quadplanes over many flights, tuning the avoidance margins, loiter-to-altitude descent and trapped-failsafe against live behaviour — including a genuine in-flight encounter with DJI drones and a GA aircraft transmitting ADS-B that the vehicle avoided. Logs available on request. - **Autotest:** 14 new `Plane.PlaneDAA*` SITL tests, all passing. They cover fence avoidance and breach-escape, fence-label scoping, ADS-B drone and GA-aircraft avoidance, the conservative CPA gate (a converging contact engages, a diverging one is suppressed), the loiter-to-altitude descend commit, altitude-fence clamping, wind-scaled margins, trapped-failsafe no-false-fire, and disable-reverts-target. Traffic is injected as `ADSB_VEHICLE` (`ADSB_TYPE=5`). Where a test asserts new behaviour it was validated fail-on-neutralized (e.g. the descend test fails when `DAA_AVD_ALT` is set to cruise so no descent is possible). - **Regression:** `Copter.DataFlashErase` passes — confirming the shared-library changes do not alter non-Plane log volume, and that the FENC dev diagnostic stays disabled. - **Build:** clean SITL build of both ArduPlane and ArduCopter; the new params and methods are compiled only into ArduPlane (`APM_BUILD_TYPE(ArduPlane)`), verified absent from the Copter binary. - **Scripting CI:** `luacheck` and `lua-language-server` clean on the applet. ### Description **What.** `planedaa` is a Lua applet that gives Plane a Detect-Alert-Avoid capability for both static (geofence) and dynamic (ADS-B) hazards, without new C++ flight logic. This code is based extensively on the prior work by @tridge Andrew Tridgell and others as part of Canberra UAV and the Outback Challenge in 2018. This work had also been progressed by @NDevDrone Nate Mailhot and @TeteJK Theresa de Jesus Krings in 2024/5 on #28903. The code implements ASTM3442M-23 for "Well Clear" and "Near Miss" boundaries for GA aircraft and different boundaries for UAV well clear and near miss based on ACAS sXu and real world testing. These values are all parameterized. This codel: - steers around inclusion/exclusion geofences with a bendy-ruler path, using margins that scale with wind (`DAA_WIND_MARG`) and default to the turn radius (`WP_LOITER_RAD`) so the standoff is one loiter circle; - flies a loiter-to-altitude descent (`DAA_AVD_ALT`) for GA aircraft to open a vertical gap; - avoids ADS-B traffic with a type-aware closest-point-of-approach (CPA) gate that ignores clearly-diverging traffic; - clamps to altitude fences (`FENCE_ALT_MIN`/`MAX`) with proactive level-off; and - provides a trapped-failsafe (`DAA_TRAP_ACT`) that fires on a sustained fence breach or aircraft near-miss. **How the code is layered (one subsystem per commit):** 1. `AP_ADSB` — `ADSB_TYPE=5` (MAVLink) to ingest `ADSB_VEHICLE` with no ADS-B hardware, plus emitter-type passthrough. 2. `AP_Avoidance` — the DAA standoff params and the `distance_to_aircraft/obstacle` + emitter-classifier queries used by scripting. 3. `AC_Fence` — signed `distance_line_to_*` fence queries for scripted avoidance. 4. `AC_Avoidance` — `AP_OAScripting`, the singleton that exposes fence and ADS-B avoidance to Lua. 5. `Plane` — QuadPlane holds the `AP_OAScripting` member. 6. `AP_Scripting` — the `planedaa` applet, its bindings, and `planedaa.md`. 7. `waf` — whitelist `AP_OAScripting.h` for the `APM_BUILD_TYPE`-in-header check. 8. `autotest` — the `PlaneDAA*` test suite. **Why.** ADS-B and geofence avoidance policy is easier to iterate and tune per-vehicle in Lua than in C++, and keeping it scripted lets operators adjust standoffs, actions and margins without a firmware rebuild. The C++ additions are minimal, generic library queries; all avoidance policy lives in the applet. Using mostly Lua also allows the easier implementation of different mechanisms for avoidance and failsafes, and limits the flash space impact. **Parameters / migration.** - New (ArduPlane only, gated `APM_BUILD_TYPE(ArduPlane)` — not present on other vehicles): `AVD_WCLR_XY`, `AVD_WCLR_Z`, `AVD_NMAC_XY`, `AVD_NMAC_Z`, `AVD_UAV_XY`, `AVD_UAV_Z` (well-clear / near-miss / UAV standoffs). - `ADSB_TYPE` gains value `5` (MAVLink); existing values are unchanged. - The applet adds its own `DAA_*` scripting parameters at load; these are documented in `libraries/AP_Scripting/applets/planedaa.md`. - No existing parameter changes value, storage, or default — nothing to migrate. **Scope note.** The DAA standoff params and scripted-avoidance methods are gated so they compile only into ArduPlane, and only when --enable-AC_AVOID is used when compiling. The c++ code and bindings not compiled in by default. ArduCopter/Rover/etc. binaries and parameter tables are unaffected (verified by `Copter.DataFlashErase`), --- *This contribution was AI-assisted: the applet, C++ library plumbing, and autotests were developed using ChatGPT and DeepSeek and iterated with Claude (Claude Code) under human direction and review, and validated in SITL and extensive field testing on real vehicles.*

Plane: quadplane: transition: only set TECS throttle min in auto throttle modes (#33972)

master ← IamPete1:TECS_throttle_step

opened 06:21PM - 06 Aug 26 UTC

+64 -2

### Summary Fixes https://github.com/ArduPilot/ardupilot/issues/33871 Thi…s changes to only set TECS throttle min in auto throttle modes where TECS is run. Currently thottle min is set in all cases, if there transition is into a mode which does not use TESC that throttle min does not apply until the next mode change. ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [ ] No-binary change - [ ] Infrastructure change (e.g. unit tests, helper scripts) - [x] Automated test(s) verify changes (e.g. unit test, autotest) - [ ] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description