Dev Call Aug 3, 2026

ArduPilot 4.7 issues list

opened 12:30AM - 07 Mar 26 UTC

rmackay9

DevCallTopic ReleaseAdmin

This is a list of issues discovered during ArduPilot 4.7 testing. [Issues for 4….6 are here](https://github.com/ArduPilot/ardupilot/issues/28612) ### Reports requiring investigation - [ ] https://github.com/ArduPilot/ardupilot/issues/33892 - [ ] https://github.com/ArduPilot/ardupilot/issues/33926 - [ ] https://github.com/ArduPilot/ardupilot/pull/33890 - [ ] https://github.com/ArduPilot/ardupilot/issues/33871 - [ ] https://github.com/ArduPilot/ardupilot/issues/33859 - [ ] https://github.com/ArduPilot/ardupilot/issues/33722 - [ ] Rover throttle failsafe interferes with GCS failsafe? ([discussion](https://discuss.ardupilot.org/t/rover-gcs-failsafe/144533/6)) - [ ] https://github.com/ArduPilot/ardupilot/pull/33136 - [ ] https://github.com/ArduPilot/ardupilot/issues/28876 (4.6 issue) ### Confirmed issues - [ ] https://github.com/ArduPilot/ardupilot/issues/33895 ([PR](https://github.com/ArduPilot/ardupilot/pull/33908)) - [ ] https://github.com/ArduPilot/ardupilot/pull/33878 - [ ] https://github.com/ArduPilot/ardupilot/issues/33826 ([PR](https://github.com/ArduPilot/ardupilot/pull/31355)) - [ ] https://github.com/ArduPilot/ardupilot/issues/33783 - [ ] QuikTune Lua script should restrict which modes it operates in ([PR](https://github.com/ArduPilot/ardupilot/pull/33025)) ### Copter Specific Issues - [ ] https://github.com/ArduPilot/ardupilot/issues/31021 ([issue2](https://github.com/ArduPilot/ardupilot/issues/21534), [PR1](https://github.com/ArduPilot/ardupilot/pull/31038), [PR2](https://github.com/ArduPilot/ardupilot/pull/32029), [PR3](https://github.com/ArduPilot/ardupilot/pull/33863)) - [ ] Mount POI sometimes not working? ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/64), [PR](https://github.com/ArduPilot/ardupilot/pull/33396)) - [ ] Copter crash while using AutoTune with fast rates ([discussion](https://discuss.ardupilot.org/t/crash-during-autotune-uncommanded-pitch-movement-during-roll-tuning-arducopter-4-7-0-beta3/143598), [PR](https://github.com/ArduPilot/ardupilot/pull/32404)) - [ ] https://github.com/ArduPilot/ardupilot/issues/31968 ### Tradheli Specifc Issues - None ### Plane Specific Issues - [ ] https://github.com/ArduPilot/ardupilot/issues/33720 ([PR](https://github.com/ArduPilot/ardupilot/pull/33736)) - [ ] https://github.com/ArduPilot/ardupilot/issues/32606 - [ ] https://github.com/ArduPilot/ardupilot/issues/32518 -- @IamPete1 or @samuelctabor to resolve ### Rover Specific Issues - [ ] Rover jump after 8+ hours with RTK GPS ([discussion](https://discuss.ardupilot.org/t/large-position-jumps-after-sitting-indoors-for-several-hours/144094), [issue](https://github.com/ArduPilot/ardupilot/issues/33388), [PR](https://github.com/ArduPilot/ardupilot/pull/33392), also 4.6) ### Sub Specific Issues - [ ] https://github.com/ArduPilot/ardupilot/issues/33810 (also in 4.6) ### Mission Planner Issues - [ ] https://github.com/ArduPilot/MissionPlanner/issues/3751 ### QGC Issues - None ### Wiki Issues - QuadPlane tuning process instructions need updating (reported in "documentation" channel by Ep, Bob Long) ### Enhancements or Issues that may not be resolved before the stable release - [ ] Copter PosHold/Loiter/PosControl not handling yaw resets completely? ([discussion](https://discuss.ardupilot.org/t/new-beta-fly-away/144128)) - [ ] Rover home position saved to storage at 1hz ([discussion](https://discuss.ardupilot.org/t/learning-ardupilot-starting-with-esp32/115834/36), [issue](https://github.com/ArduPilot/ardupilot/issues/33602)) - [ ] https://github.com/ArduPilot/ardupilot/issues/33125 (4.6 issue as well) - [ ] SpeedyBeeF405AIO not detecting Adafruit MMC56x3 compass ([discussion](https://discuss.ardupilot.org/t/adafruit-mmc56x3-with-speedybeef405aio/143395), also not working with 4.6) - [ ] https://github.com/ArduPilot/ardupilot/issues/32444 (also present in 4.6 and earlier) - [ ] https://github.com/ArduPilot/ardupilot/issues/32862 - [ ] https://github.com/ArduPilot/ardupilot/issues/32689 (4.6.3, not 4.7 yet) - [ ] Circle point-mount-at-ROI should only apply when circle radius > 0 (e.g. do not apply during panorama) ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/71), [issue](https://github.com/ArduPilot/ardupilot/issues/32641)) - [ ] Copter's SmartRTL always rises 2m before landing ([discussion](https://discuss.ardupilot.org/t/smartrtl-rises-to-2m-after-reaching-home-before-landing/143126/2)) -- present in 4.6 so not a blocker ### Resolved issues - [x] https://github.com/ArduPilot/ardupilot/pull/33904 -- resolved ahead of 4.7.1-beta1 - [x] Copter PSC_JERK_NE/D should be PSC_NE/D_JERK? ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-released/144650/9), [PR](https://github.com/ArduPilot/ardupilot/pull/33843)) -- resolved ahead of 4.7.1-beta1 - [x] https://github.com/ArduPilot/ardupilot/pull/33803 (also in 4.6) -- resolved ahead of 4.7.1-beta1 - [x] https://github.com/ArduPilot/ardupilot/issues/33327 ([PR](https://github.com/ArduPilot/ardupilot/pull/33362)) fix https://github.com/ArduPilot/terraingen/pull/29 -- resolved shortly after 4.7.0 was released - [x] Copter yaw oscillation using Spline waypoints ([discussion](https://discuss.ardupilot.org/t/yaw-oscillations-in-auto-spline-waypoints/144688)) -- user error, should have set WP_YAW_BEHAVIOR = 2 (the default) - [x] FlywooF405HD-AIOv2 - Onboard barometer not detected ([discussion](https://discuss.ardupilot.org/t/flywoof405hd-aiov2-onboard-barometer-not-detected-baro1-devid-0-on-two-different-boards/144589), [PR](https://github.com/ArduPilot/ardupilot/pull/33779)) -- resolved ahead of 4.7.1-beta1 - [x] https://github.com/ArduPilot/ardupilot/issues/33538 ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta7-is-available-for-beta-testing/144197/25), [discussion2](https://discuss.ardupilot.org/t/potential-incomplete-initialization-on-ap-flashstorage/144440), [PR](https://github.com/ArduPilot/ardupilot/pull/33640)) -- resolved (we think) ahead of 4.7.1-beta1 - [x] https://github.com/ArduPilot/ardupilot/pull/32381 -- resolved for 4.7.0-beta2 - [x] Custom Build Server compile error when AP_COMPASS_IST8310 disabled ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta8-released-for-beta-testing/144555/7), [PR](https://github.com/ArduPilot/ardupilot/pull/32696)) -- resolved ahead of 4.7.1-beta1 - [x] Skyviper-v2450 build broken ([issue](https://github.com/ArduPilot/ardupilot/issues/33725), [PR](https://github.com/ArduPilot/ardupilot/pull/32696)) -- resolved ahead of 4.7.1-beta1 - [x] https://github.com/ArduPilot/ardupilot/pull/33715 -- resolved ahead of 4.7.1 - [x] set-target-angle-and-climbrate used by scripting has climbrate scaling issue ([PR](https://github.com/ArduPilot/ardupilot/pull/33692)) -- resolved ahead of 4.7.0-beta8 - [x] follow init bug affecting yaw ([PR](https://github.com/ArduPilot/ardupilot/pull/33652)) -- resolved ahead of 4.7.0-beta8 - [x] https://github.com/ArduPilot/ardupilot/issues/33451 ([PR](https://github.com/ArduPilot/ardupilot/pull/33607), also in 4.6) -- resolved ahead of 4.7.0-beta8 - [x] https://github.com/ArduPilot/ardupilot/issues/33612 ([PR](https://github.com/ArduPilot/ardupilot/pull/33613)) -- resolved ahead of 4.7.0-beta8 - [x] Copter PosHold start-stop during acceleration ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0b7-strange-behaviour-in-poshold-mode/144301), [issue](https://github.com/ArduPilot/ardupilot/issues/33588), [PR](https://github.com/ArduPilot/ardupilot/pull/33590), [related PR](https://github.com/ArduPilot/ardupilot/pull/30358)) -- resolved ahead of 4.7.0-beta8 - [x] GPS-for-yaw fails to fuse if delay set too long ([PR](https://github.com/ArduPilot/ardupilot/pull/33643), also in 4.6) -- resolved ahead of 4.7.0-beta8 - [x] https://github.com/ArduPilot/MissionPlanner/issues/3743 -- fixed with MP beta release on 03Jul2026 - [x] Loiter braking essentially disabled by coordinated turns ([PR](https://github.com/ArduPilot/ardupilot/pull/33631)) -- resolved for -beta8 - [x] broken COMPASS_DISBLMSΚ for hwdef-ed compasses ([master PR](https://github.com/ArduPilot/ardupilot/pull/33562), [AP4.7 PR](https://github.com/ArduPilot/ardupilot/pull/33553), [related PR](https://github.com/ArduPilot/ardupilot/pull/31591)) -- resolved ahead of 4.7.0-beta8 - [x] crash with harmonic notch logging showing NaN ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta7-is-available-for-beta-testing/144197/3)) -- assumed AIO ESC hardware issue - [x] Loiter mode drifts agressively ([discussion](https://discuss.ardupilot.org/t/loiter-mode-drone-drifts-aggressively-after-releasing-sticks-to-neutral-regression-in-4-8-0dev-works-fine-on-4-6/144203), [issue](https://github.com/ArduPilot/ardupilot/issues/33454)) -- user was not expecting coordinated turns - [x] plane transitions worse? ([discussion](https://discuss.ardupilot.org/t/arduplane-4-7-0-beta-4-vtol-attitude-problem/144037)) -- no response to request for logs - [x] EKF using GPS-for-yaw loses attitude estimate after 2 hours ([discussion](https://discuss.ardupilot.org/t/large-position-jumps-after-sitting-indoors-for-several-hours/144094/15)) - [x] https://github.com/ArduPilot/ardupilot/issues/33403 -- fixed before 4.7.0-beta8 (or official release) - [x] Pre-arm stick arming issues ([issue](https://github.com/ArduPilot/ardupilot/issues/33386), [PR](https://github.com/ArduPilot/ardupilot/pull/33402)) -- resolved for 4.7.0-beta7 - [x] Mount POI lock not included in default firmware ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/43), [PR](https://github.com/ArduPilot/ardupilot/pull/33372)) -- resolved ahead of 4.7.0-beta7 - [x] Quadplane QLand over speed ([discussion](https://discuss.ardupilot.org/t/qland-vertical-speed/143366/2)) -- no response from user - [x] still GCC 10? ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta6-is-available-for-beta-testing/144106/3)) -- yes - [x] https://github.com/ArduPilot/MissionPlanner/issues/3731 ([PR](https://github.com/ArduPilot/MissionPlanner/pull/3732)) -- resolved ahead of 4.7.0-beta6 but not a flight code issue - [x] https://github.com/ArduPilot/ardupilot/issues/33230 ([PR](https://github.com/ArduPilot/ardupilot/pull/33232), also in 4.6) -- resolved ahead of 4.7.0-beta6 - [x] https://github.com/ArduPilot/ardupilot/issues/33161 ([PR](https://github.com/ArduPilot/ardupilot/pull/33275) also in 4.6) - [x] LIS2MDL / IIS2MDC found to be duplicate parts, consolidation required ([PR](https://github.com/ArduPilot/ardupilot/pull/33140)) -- **blocker** - [x] https://github.com/ArduPilot/ardupilot/issues/32624 ([PR](https://github.com/ArduPilot/MissionPlanner/pull/3697)) -- resolved ahead of 4.7.0-beta6 (but not an AP flight code issue anyway) - [x] Extended Tuning needs updating ([discussion](https://discuss.ardupilot.org/t/speedybee-f405-v4-parameter-not-shown-in-mission-planner/142797/3), [issue](https://github.com/ArduPilot/MissionPlanner/issues/3678), [PR](https://github.com/ArduPilot/MissionPlanner/pull/3685)) -- resolved ahead of 4.7.0-beta6 (but not an AP flight code issue anyway) - [x] https://github.com/ArduPilot/ardupilot/pull/33156 -- resolved ahead of 4.7.0-beta6 - [x] https://github.com/ArduPilot/ardupilot/issues/33168 ([PR](https://github.com/ArduPilot/ardupilot/pull/33169), also in 4.6) -- resolved ahead 4.7.0-beta6 - [x] https://github.com/ArduPilot/ardupilot/issues/33083 ([PR](https://github.com/ArduPilot/ardupilot/pull/33093), also exists in 4.6) -- resolved ahead of 4.7.0-beta6 - [x] https://github.com/ArduPilot/ardupilot/issues/33165 ([discussion](https://github.com/ArduPilot/ardupilot/issues/33165)) -- user error - [x] https://github.com/ArduPilot/ardupilot/issues/32977 ([PR](https://github.com/ArduPilot/ardupilot/pull/33016), also exists in 4.6) -- resolved ahead of 4.7.0-beta6 - [x] Copter follow mode alt overshoot bug ([PR](https://github.com/ArduPilot/ardupilot/pull/33109)) -- resolved ahead of 4.7.0-beta6 - [x] https://github.com/ArduPilot/ardupilot/issues/32491 ([PR](https://github.com/ArduPilot/ardupilot/pull/33005), 4.6 issue) -- resolved ahead of 4.7.0-beta6 - [x] Spool up changes causing spurious errors (reported by AndyP, [PR](https://github.com/ArduPilot/ardupilot/pull/32955)) -- resolved ahead of 4.7.0-beta6 - [x] buffer overflow related to CAN logging (reported by PeterB, [PR](https://github.com/ArduPilot/ardupilot/pull/33031)) -- resolved ahead of 4.7.0-beta6 - [x] https://github.com/ArduPilot/ardupilot/issues/32811 ([PR1](https://github.com/ArduPilot/ardupilot/pull/33020)) -- resolved ahead of 4.7.0-beta6 - [x] Copter follow mode bug ([PR](https://github.com/ArduPilot/ardupilot/pull/33038)) -- resolved ahead of 4.7.0-beta6 - [x] https://github.com/ArduPilot/ardupilot/issues/32942 ([PR](https://github.com/ArduPilot/ardupilot/pull/32943), also present in 4.6) -- resolved ahead of 4.7.0-beta6 - [x] plane when enabling safety surfaces to to full deflection on tridge's hero, need to look with saleae, fixed in https://github.com/ArduPilot/ardupilot/pull/32979 -- included in 4.7.0-beta5 - [x] Payload place may get stuck based on alt field ([PR](https://github.com/ArduPilot/ardupilot/pull/32634)) -- resoled ahead of -4.7.0-beta5 - [x] copter-circle-speed script not working correctly ([issue](https://github.com/ArduPilot/ardupilot/issues/32799)) -- could not reproduce, appears to work fine - [x] Terrain downloaded to SD card unnecessarily reloaded in flight? ([issue](https://github.com/ArduPilot/ardupilot/issues/32773), [wiki PR](https://github.com/ArduPilot/ardupilot_wiki/pull/7690)) - [x] Altitude estimate offset when switching between baro and rangefinder source ([discussion1](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/28), [discussion2](https://discuss.ardupilot.org/t/re-baro-alt-reset/143333), [issue](https://github.com/ArduPilot/ardupilot/issues/32612), [PR](https://github.com/ArduPilot/ardupilot/pull/32931)) -- resolved for 4.7.0-beta4 - [x] ELRS RC related crash ([issue1](https://github.com/ArduPilot/ardupilot/issues/32653), [issue2](https://github.com/ArduPilot/ardupilot/issues/32862), [Wiki PR](https://github.com/ArduPilot/ardupilot_wiki/pull/7701)) -- existing issue, workaround added to wiki, covered by [issue 32862](https://github.com/ArduPilot/ardupilot/issues/32862) - [x] TradHeli PID gain multiplier reset issue ([PR](https://github.com/ArduPilot/ardupilot/pull/32725)) -- resolved ahead of 4.7.0-beta4 - [x] https://github.com/ArduPilot/ardupilot/pull/32892 -- resolved ahead of 4.7.0-beta4 - [x] Copter surface tracking altitude error not limited? ([discussion](https://discuss.ardupilot.org/t/surface-tracking-issues/142851/3), [issue](https://github.com/ArduPilot/ardupilot/issues/32740), [PR](https://github.com/ArduPilot/ardupilot/pull/32789), 4.6 issue as well) -- resolved in 4.8, not immediately planning to backport unless there is demand for it - [x] Rover watt limiter not working correctly ([relevant PR](https://github.com/ArduPilot/ardupilot/pull/31285), [discussion](https://discuss.ardupilot.org/t/rover-4-7-0-beta2-available-for-beta-testing/143065/10), [PR](https://github.com/ArduPilot/ardupilot/pull/32788)) -- resolved for 4.7.0-beta4 - [x] https://github.com/ArduPilot/ardupilot/issues/32741 - [x] crash dump on custom FC ([discussion](https://discuss.ardupilot.org/t/watchdog-crash-dump-bin-arducopter-4-7-0-dev-on-custom-flight-controller/143475)) -- unsupported board, can't help - [x] https://github.com/ArduPilot/ardupilot/issues/32688 -- user error - [x] Mission Planner SITL gets 4.6.2-beta1 binary ([SITL firmware](https://firmware.ardupilot.org/Tools/MissionPlanner/sitl/Beta/), [should be fixed by this job](https://github.com/ArduPilot/ardupilot/actions/runs/24375398698/job/71187757542), reported by @tridge) -- fixed ahead of 4.7.0-beta3 - [x] SBF GPS driver issue ([issue](https://github.com/ArduPilot/ardupilot/issues/32631), [PR1](https://github.com/ArduPilot/ardupilot/pull/32633/changes), [PR2](https://github.com/ArduPilot/ardupilot/pull/32642)) -- resolved for 4.7.0-beta4 - [x] https://github.com/ArduPilot/ardupilot/issues/32724 ([PR](https://github.com/ArduPilot/ardupilot/pull/32730), 4.6 issue as well?) -- resolved ahead of 4.7.0-beta4 - [x] Rover custom build server issue ([issue](https://github.com/ArduPilot/ardupilot/issues/32666?reload=1), [relevant PR](https://github.com/ArduPilot/ardupilot/pull/31285), [discussion](https://discuss.ardupilot.org/t/rover-4-7-0-beta2-available-for-beta-testing/143065/10), [PR](https://github.com/ArduPilot/ardupilot/pull/32687)) -- resolved for 4.7.0-beta3 - [x] Loiter/QLoiter feels slower, looks like inaccurate position hold. Likely due to consider how we can make it feel closer to 4.6 automatically. Or provide instructions on parameter changes ([relevant PR](https://github.com/ArduPilot/ardupilot/pull/31848), [PR](https://github.com/ArduPilot/ardupilot/pull/32643), [discussion](https://discuss.ardupilot.org/t/how-do-althold-and-loiter-feel-in-4-7-vs-4-6/143300)) -- resolved for 4.7.0-beta3 - [x] Realflight quadplanes not working? ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/72)) -- could not reproduce the problem, RF evolution seems to work OK - [x] ArcWaypoints listed as WIP (reported by lthall, [PR](https://github.com/ArduPilot/mavlink/pull/497)) -- resolved for 4.7.0-beta3 - [x] https://github.com/ArduPilot/ardupilot_wiki/issues/7604 -- wiki updated ahead of 4.7.0-beta3 - [x] ARMING_SKIPCHK of 10 not skipping gyro and accel checks? ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/86)) -- misunderstanding - [x] https://github.com/ArduPilot/ardupilot/pull/32382 ([PR](https://github.com/ArduPilot/ardupilot/pull/32626)) -- resolved for 4.7.0-beta3 - [x] Circle mode points mount straight down when doing panorama ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/64)) -- user misunderstanding - [x] https://github.com/ArduPilot/MissionPlanner/issues/3693 -- resolved in MP ahead of 4.7.0-beta3 release - [x] RC_OPTIONS = 1 (Ignore RC Receiver) is not being respected ([discussion](https://discuss.ardupilot.org/t/rc-options-to-1-make-copter-yaw-spinning/142948), [PR](https://github.com/ArduPilot/ardupilot/pull/32488)) -- resolved for 4.7.0-beta3 - [x] BRD_SAFETY_DFLT = 0 should force BRD_SAFETYOPTION = 0? should update param desc? ([discussion](https://discuss.ardupilot.org/t/rover-4-6-3-arming-issues-when-trying-to-arm-second-time/142747/12)) -- working as expected, not new to 4.7 - [x] https://github.com/ArduPilot/ardupilot/issues/32511 -- could not reproduce, no response from user, created [security wiki page](https://ardupilot.org/dev/docs/security-landing-page.html) and improved [secure firmware instructions](https://github.com/ArduPilot/ardupilot/tree/master/Tools/scripts/signing) - [x] CUAV Pixhawk V3C not detecting IST8310 compass ([discussion](https://discuss.ardupilot.org/t/cuav-pixhawk-v3-ist8310-not-detected-with-4-7beta1/142785), [PR](https://github.com/ArduPilot/ardupilot/pull/32462)) -- resolved for 4.7.0-beta3 - [x] https://github.com/ArduPilot/ardupilot/issues/32506 ([PR](https://github.com/ArduPilot/ardupilot/pull/32508)) -- resolved ahead of 4.7.0-beta3 - [x] https://github.com/ArduPilot/ardupilot/pull/29087 missing from release notes ([discussion](https://discuss.ardupilot.org/t/plane-4-7-0-beta1-available-for-beta-testing/142742/9)) -- @IamPete1 updated the plane 4.7.0-beta1 release notes - [x] Plane Follow's FOLLP_SIM_TlF_FN should have upper case L ([PR](https://github.com/ArduPilot/ardupilot/pull/32456)) -- resolved for 4.7.0-beta2 - [x] UM982 GPS-for-yaw on CUAV V6X not working ([discussion](https://discuss.ardupilot.org/t/ardurover-4-7-0-new-issues-with-um982-moving-baseline/142916)) -- resolved by updating the UM982 firmware - [x] https://github.com/ArduPilot/ardupilot/issues/31584 -- resolved for 4.7.0-beta2 - [x] QGC altitude slider not working ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/15)) -- fixed for daily build on 18Mar2026 - [x] QGC takeoff slider not working ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/15)) -- fixed in QGC 14148 - [x] QGC Parameters need updating (@rmackay9 and @DonLakeFlyer discussed if dev-team channel, [PR](https://github.com/mavlink/qgroundcontrol/pull/14148)) -- fixed in QGC daily on 17-Mar-2026 - [x] EKF's use of rangefinder and baro never switches back to rangefinder after switching to baro ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/15)) -- user error - [x] update PSC_ACCZ_I and PSC_ACCZ_P tuning advice https://ardupilot.org/copter/docs/initial-tuning-flight.html#test-althold ([PR](https://github.com/ArduPilot/ardupilot_wiki/pull/7482)) -- wiki updated ahead of 4.7.0-beta2 - [x] ATC_ACC conversion didn't work ([discussion](https://discuss.ardupilot.org/t/copter-4-7-0-beta1-available-for-beta-testing/142738/8)). Should we remove the "configured" checks ([code](https://github.com/ArduPilot/ardupilot/blob/master/libraries/AC_AttitudeControl/AC_AttitudeControl.cpp#L1161)). Caused by installing 4.7.0-dev prior to release of beta1 - [x] https://github.com/ArduPilot/ardupilot/pull/32428 -- resolved for 4.7.0-beta2

Issues & Pull Requests

github.com/ArduPilot/pymavlink

mavgen_c.py: make MAVLINK_*_XML_HASH deterministic (#1240)

master ← peterbarker:pr/mavgen-deterministic-xml-hash

opened 03:09AM - 01 Aug 26 UTC

+9 -1

xml_hash was computed with Python's builtin hash(), which is salted per interpre…ter run since Python 3.3 (PYTHONHASHSEED), so each generator run emits different MAVLINK_*_XML_HASH values for identical XML. The hash only needs to be distinct per dialect name (see PR #537, which replaced the order-dependent iterating index); it does not need to be random. Nondeterministic values churn every dialect header in checked-in generated libraries (e.g. mavlink/c_library_v2) and defeat ccache's direct mode for any source file that includes a generated header: an ArduPilot SITL clean rebuild goes from 42% to 100% direct hits with this change, dropping warm-cache rebuild time from 19s to 5.6s. Replace it with the first 8 bytes of sha256 of the dialect name, which is stable across runs, Python versions and platforms.

AP_ExternalAHRS: Add Aeron Systems PLX3 INS Driver (#33041)

master ← aeron-systems:plx3-eahrs-driver

opened 11:09AM - 13 May 26 UTC

VinayakPundhir

+2137 -4

### Summary This adds support for Aeron Systems PLX3-N INS to be integrated i…n Ardupilot's Ecosystem. ### 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) - [ X] Tested on hardware - [ X] Logs attached - [ X] Logs available on request The Driver has been thoroughly tested in simulation as well as on real hardware. Details below. 1. Tested in AutoTest (Passed Successfully). 2. Tested in sim_vehicle.py on all major platforms (Copter, Plane etc). 3. Ran simulation continuous for more than 36 hours. 4. Tested on real hardware (CubeOrange, CubeOrangePlus, etc). 5. Real platforms included Quadcopter and Dual rotor push type Fixed Wing. 6. Very Strict checking of input data to catch even single byte drop. 7. Primary Style Check was done. 8. Real Flights Conducted in GNSS Denied scenario as well. 9. Hardware fail and logical check cross verified. 10. Fallback to internal EKF verified in case of ExternalAHRS failure (Fixed Wing only). 11. Raised PR for ardupilot wiki - https://github.com/ArduPilot/ardupilot_wiki/pull/7750 12. Checked onboard logs of EAHRS if logging is enabled. Here's a flight video of the gnss denied test. https://www.aeronsystems.com/articles/plx3-autopilot-for-autonomous-uav-gnss-denied-operations/ Will also attach logs if requested : ) Special Thanks to @Ryanf55 for introducing and helping me in this Initially and @peterbarker for clarifying all my silly doubts : )

Copter: Remove superseded ALLOW_ARM_NO_COMPASS (#32737)

master ← peterbarker:pr-claude/remove-redundant-compass-stuff

opened 08:15AM - 11 Apr 26 UTC

+24 -133

### Summary Remove `ALLOW_ARM_NO_COMPASS`, defeated for its intended purpose …since 2019, along with the Copter arm-time compass-health check it guarded; add an autotest pinning the corrected arming behaviour. ### 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 The new `Copter.CompassHealthArming` autotest verifies: 1. with compass checking enabled, all compasses failed (`SIM_MAGx_FAIL`) produces the shared pre-arm failure "Compass 1 not healthy"; 2. an actual arm attempt in that state is refused; 3. with the `ARMING_CHECK` compass bit skipped (`ARMING_SKIPCHK`), the vehicle arms despite the unhealthy compass. As a negative control, the test was run against master *without* the removal commits: it fails there (the arm command in step 3 is rejected with `MAV_RESULT_FAILED` by the block this PR removes), demonstrating the test distinguishes the old and new behaviour rather than passing vacuously. ### Description `ALLOW_ARM_NO_COMPASS` let a board's hwdef compile out a Copter-only arm-time compass-health check so compass-less builds could arm. It stopped achieving that in November 2019: commit 653fad44d4b5 changed `AP_Arming::compass_checks()` to call `use_for_yaw(0)` instead of `use_for_yaw(void)`. The void form implicitly called `healthy()`, so an absent/unhealthy compass previously made the *shared* pre-arm check pass via its compass-use-disabled path — the Copter-local block was the only real gate, and the define meaningfully disabled it. Since that change the shared check calls `healthy()` directly and fails pre-arm regardless of this define, so for ordinary arming with compass checks enabled the define has done nothing for over five years. 114 hwdefs still define it; none get what the name promises. This PR removes the define from all hwdefs, the betaflight conversion script, and the Copter arm-time block itself. **One intentional behavioural change**: the removed block ran unconditionally in `arm_checks()` — before `should_skip_all_checks()` and ungated by any `ARMING_CHECK` bit (it used the `check_failed(true, ...)` form) — while the equivalent shared check is gated on the COMPASS bit of `ARMING_CHECK`. A user with compass arming checks disabled (or all checks disabled), an unhealthy compass and a compass-based yaw source was therefore still refused arming by this block. That configuration is reachable: EKF source pre-arm validation deliberately skips compass availability for `SourceYaw::COMPASS` to ease compass-less setup (`AP_NavEKF_Source.cpp`). After this PR such users may arm, as their `ARMING_CHECK` setting requests; this also aligns Copter with the other vehicles, none of which carried this extra arm-time check. Firmware impact on boards defining the macro is limited to the ROMFS-embedded hwdef.dat shrinking by one line; the Copter code change is −72 bytes on all copter builds. There was previously no autotest coverage of compass-health arm refusal in either direction; the new test provides it. AI assistance was used in preparing this PR (Claude); all changes have been reviewed and verified by the human author, including independent cross-verification of the historical analysis against 653fad44d4b5 and the current arming code.

AP_ExternalAHRS: Add Aeron Systems PLX3 INS Driver (#33041)

master ← aeron-systems:plx3-eahrs-driver

opened 11:09AM - 13 May 26 UTC

VinayakPundhir

+2137 -4

### Summary This adds support for Aeron Systems PLX3-N INS to be integrated i…n Ardupilot's Ecosystem. ### 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) - [ X] Tested on hardware - [ X] Logs attached - [ X] Logs available on request The Driver has been thoroughly tested in simulation as well as on real hardware. Details below. 1. Tested in AutoTest (Passed Successfully). 2. Tested in sim_vehicle.py on all major platforms (Copter, Plane etc). 3. Ran simulation continuous for more than 36 hours. 4. Tested on real hardware (CubeOrange, CubeOrangePlus, etc). 5. Real platforms included Quadcopter and Dual rotor push type Fixed Wing. 6. Very Strict checking of input data to catch even single byte drop. 7. Primary Style Check was done. 8. Real Flights Conducted in GNSS Denied scenario as well. 9. Hardware fail and logical check cross verified. 10. Fallback to internal EKF verified in case of ExternalAHRS failure (Fixed Wing only). 11. Raised PR for ardupilot wiki - https://github.com/ArduPilot/ardupilot_wiki/pull/7750 12. Checked onboard logs of EAHRS if logging is enabled. Here's a flight video of the gnss denied test. https://www.aeronsystems.com/articles/plx3-autopilot-for-autonomous-uav-gnss-denied-operations/ Will also attach logs if requested : ) Special Thanks to @Ryanf55 for introducing and helping me in this Initially and @peterbarker for clarifying all my silly doubts : )

AP_Param: avoid variable-length arrays in parameter conversion (#33243)

master ← peterbarker:pr-claude/clang-scan-ratchet-param

opened 02:37AM - 30 May 26 UTC

+283 -15

### Summary Removes a clang-scan-build warning of a zero-length VLA. ### C…lassification & 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 ``` Board AP_Periph antennatracker blimp bootloader copter heli iofirmware plane rover sub CubeOrange-periph-heavy -40 * Durandal -64 -64 * -72 -72 -64 -72 -72 Hitec-Airspeed -48 * KakuteH7-bdshot -72 -72 * -64 -72 -64 -64 -72 MatekF405 -64 -64 * -72 -72 -72 -64 -72 Pixhawk1-1M-bdshot -72 -72 -72 -64 -72 -64 -72 SITL_x86_64_linux_gnu 0 0 0 0 0 0 0 YJUAV_A6SE -72 -72 * -64 -64 -72 -72 -72 f103-QiotekPeriph -32 * f303-MatekGPS -48 * f303-Universal -64 * iomcu * revo-mini -72 -72 * -72 -64 -64 -64 -72 skyviper-v2450 -64 speedybeef4 -72 -64 * -64 -64 -72 -64 -72 ``` (freshened 2027-731) ### Description Code flow actually means a zero-length VLA can't happen at the moment. convert_old_parameter(), convert_class() and _convert_parameter_width() each declared a stack buffer sized by type_size() of a runtime parameter type. type_size() can return zero (AP_PARAM_NONE/GROUP, or an unknown type), which makes the array a zero-length VLA - undefined behaviour - and VLAs are non-standard C++ in any case. Replace the VLAs with a fixed buffer sized via a union of every storable parameter type, so it is always large enough without assuming which type is largest. In _convert_parameter_width() the buffer size had been used as the EEPROM read length, so read type_size(old_ptype) bytes explicitly now that the buffer is no longer exactly that size. This clears two clang-scan-build core.VLASize findings There is an alternative fix which is for callers to these methods to pass in the length of the type e.g. ``` g.terrain_follow.convert_parameter_width(AP_PARAM_INT8); ``` becomes ``` g.terrain_follow.convert_parameter_width(AP_PARAM_INT8, 1); ``` There is another alternative fix which is to suppress the clang-scan-build warning entirely and trust that we will never return 0 from the get-size-of-this-ap_var_type method. If we ever did then bad things will happen. FWIW the `union` here was my idea, don't blame claude for that bit :-)

hwdef:Add Svehicle-E2-mini flight controllers (#33328)

master ← yannis-zhi:add_svehicle-e2-mini_board

opened 08:37AM - 05 Jun 26 UTC

yannis-zhi

+3100 -0

### Summary ### Classification & Testing (check all that apply and add yo…ur own) - [ ] 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) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description

AP_InertialSensor: add LSM6DSV32X and LSM6DSK320X support (#33293)

master ← zebulon-86:pr/lsm6dsv-driver-support

opened 05:51AM - 02 Jun 26 UTC

zebulon-86

+97 -18

### Summary Add support for `LSM6DSV32X` and `LSM6DSK320X` sub-variants in th…e shared LSM6DSV-family inertial sensor driver. ### Classification & Testing - [x] Checked by a human programmer - [x] Tested on hardware - [x] Logs attached ### Description Add `LSM6DSV32X` and `LSM6DSK320X` support to the shared LSM6DSV-family path. `LSM6DSK320X` is detected by `WHO_AM_I`, while `LSM6DSV32X` is split from `LSM6DSV16X` by reading `CTRL8[2]` after reset, as both parts report `WHO_AM_I=0x70`. Both variants are registered with dedicated INS device types, use the correct accel/gyro scale encodings, and are supported by `decode_devid.py`. ### Testing **Ground identification** - Pixhawk6C with `LSM6DSK320X + BMI088`: GCS banner reported `IMU0: LSM6DSK320X fast sampling 2.0kHz`; `decode_devid.py` reported `DEVTYPE_INS_LSM6DSK320X`. - Pixhawk6C with `LSM6DSV16X + BMI088`: GCS banner reported `IMU0: LSM6DSV16X fast sampling 2.0kHz`; `decode_devid.py` reported `DEVTYPE_INS_LSM6DSV16X`. - Pixhawk6X with three onboard `LSM6DSV32X` IMUs: GCS banner reported `LSM6DSV32X fast sampling 2.0kHz` on `IMU0/1/2`; `decode_devid.py` reported `DEVTYPE_INS_LSM6DSV32X`. **Flight test** - Platform: Pixhawk6C with `BMI088 + LSM6DSK320X` - Indoor optical-flow flight, `220.7 s`, covering `STABILIZE`, `ALT_HOLD`, and `LOITER` The `LSM6DSK320X` maintained stable `2.0 kHz` fast sampling throughout the log. `IMU.EG` / `IMU.EA`, `VIBE.Clip`, `XKF4.FS`, and `XKFS.AI` all stayed at `0`. The `LSM6DSK320X` accel/gyro traces closely matched the onboard `BMI088` reference over the selected flight window, with matching trend, phase, and peak timing. `XKF1/#0` and `XKF1/#1` attitude solutions also tracked closely in `Roll`, `Pitch`, and `Yaw`, with no sustained divergence. Vibration remained normal throughout the flight. `VibeX/Y/Z` showed only brief mid-flight increases, with no sustained high-vibration region or progressive degradation; peak values stayed around the `10-12` range. **Logs / evidence** - [Pixhawk6C_BMI088-LSM6DSK320X_IndoorLoiter](https://drive.google.com/file/d/1iM1qrRqJg9o8bBxtl55GNdDxXOw_SNOS/view?usp=sharing) - IMU: `LSM6DSK320X` maintained stable `2.0 kHz` fast sampling; accel/gyro traces closely match the onboard `BMI088` reference. <img width="2259" height="1336" alt="Pasted image 20260602121021" src="https://github.com/user-attachments/assets/d643229f-1f76-4bed-8102-fb4f70669e50" /> <img width="2244" height="1277" alt="Pasted image 20260602100109" src="https://github.com/user-attachments/assets/0338e87a-740d-4683-a46b-a7b26bad31cc" /> <img width="2237" height="1236" alt="Pasted image 20260602100031" src="https://github.com/user-attachments/assets/7171a24b-2d63-4f8a-84c7-eec25ec3eba2" /> - XKF1: `XKF1/#0` and `XKF1/#1` attitude solutions track closely in `Roll`, `Pitch`, and `Yaw`, with no sustained divergence. <img width="2248" height="626" alt="Pasted image 20260602100547" src="https://github.com/user-attachments/assets/ef8c95ea-62de-4752-908a-9ca2aafb4228" /> <img width="2227" height="612" alt="Pasted image 20260602100620" src="https://github.com/user-attachments/assets/379840bc-46bd-4eb5-bb86-2e293f3425c8" /> - VIBE: overall vibration remained normal, with only brief mid-flight increases and no sustained high-vibration region. <img width="2235" height="616" alt="Pasted image 20260602100736" src="https://github.com/user-attachments/assets/077151d8-5f17-4c37-999d-5681c65e0498" /> ### Notes - Register configuration was validated indirectly through correct identification, stable sample rate, zero IMU error counters, consistent flight data, and normal EKF behavior. - Flight evidence covers the `LSM6DSK320X` path on Pixhawk6C hardware. - This contribution was developed with AI assistance; all changes were reviewed and validated by the human author.

HAL_ChibiOS: Add Lectron Pi5 Autopilot board definitions (#33423)

master ← lectronuser:development

opened 11:46AM - 12 Jun 26 UTC

lectronuser

+1913 -0

### Summary New board (Lectron Pi5-H7 Autopilot) has been added to the system…. - Onboard sensors have been enabled. - Sensor orientations have been adjusted. ### 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 - [X] Logs available on request ### Description New flight controller board featuring Raspberry Pi CM5 + Hailo AI module. - Triple IMU: 2x ICM-42670-P + BMI270 - BMM350 magnetometer, BMP390 barometer - 10/100 Ethernet with MAVLink on UDP 14550 - USB-C device mode <img width="671" height="592" alt="Screenshot from 2026-06-09 11-13-17" src="https://github.com/user-attachments/assets/7f8f399d-a5af-415c-8de9-e737b80d42da" /> ### Context - Main Page: https://lectrontech.com/ - Technical Documentation Page: https://lectronuser.github.io/Lectron-Doc-Center/md/raspberry/

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

master ← timtuxworth:pr-planefollow-autotest-dual

opened 03:46PM - 13 Jun 26 UTC

timtuxworth

+1069 -204

### 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. To get this to work in CI with two parallel SITL instances I had to slow it down. There is a parameter FOLLOW_SPEEDUP which overrides the default speedup to run this test at 2x which is the fastest I've been able to get it to work on CI, although I have been able to run it at 5x on my local.

Add board support for CUAV-X25-MEGA (#33475)

master ← cuav-chen2:pr_cuav_x25_mega

opened 10:37AM - 17 Jun 26 UTC

cuav-chen2

+5701 -0

### Summary Add board support for CUAV-X25-MEGA flight controller. ### Cla…ssification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [x] 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 ### Description This PR add board support for CUAV-X25-MEGA flight controller. We have verified that the sensors and interfaces are functioning properly and conducted flight tests.

Move control limits into estimates structure (#33606)

master ← peterbarker:pr/control-limits-to-estimates

opened 03:27AM - 30 Jun 26 UTC

+67 -100

### Summary Moves the limits being imposed by the estimator into the estimate…s structure ### 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 the limits from being various method callbacks (pure-virtual on the backends, method with explicit DCM check in the frontends) to being entries in the results structure. I took the opportunity here to adjust the naming, and to split the method which previously had two return parameters for the different control limits into 2 parts, one for the gain scaling and one for the XY velocity limit (there was already a method to return the Z-scaler)

AP_NavEKF3: correct moving baseline GPS yaw for vehicle attitude (#33706)

master ← lthall:20260704_GPS_Yaw_EKF_2

opened 11:35AM - 13 Jul 26 UTC

+510 -27

Summary Moving-baseline GPS yaw assumes the vehicle is level; for antenna basel…ines with a vertical component the recovered yaw is biased when the vehicle rolls or pitches. This PR exports the antenna offset the yaw was calculated from and applies the exact attitude correction inside EKF3, per lane, at the fusion time horizon (gated behind EK3_FEATURE_MOVING_BASELINE, on 2 MB+ boards), with Replay support via a new RGPK DAL message. ### 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 - [x] Logs available on request Three new autotests, each verified to fail against the code without its fix (negative control) before being confirmed to pass with it: - GPSForYawAttitudeCorrection: flies a circle with a large-Z antenna baseline; EKF yaw must track SIMSTATE truth while banked AND the yaw innovation test ratio must stay below 1 (a wrong measurement that is merely gate-rejected leaves the EKF coasting accurately on the gyro, so yaw-vs-truth alone can false-pass). - GPSForYawVerticalBaseline: a baseline with no horizontal separation carries no yaw information; the driver must reject it rather than publish receiver noise as yaw. - GPSForYawCompassFallback: with EK3_SRC1_YAW=3, a measurement the EKF rejects geometrically must count as "no usable yaw" so the magnetometer fallback engages after 10 s, even though the GPS is still publishing. Existing GPSForYaw autotest still passes. Description The GPS driver recovers vehicle yaw from the reported baseline heading by subtracting the bearing of the body-frame antenna offset, which is only exact when the vehicle is level. An earlier attempt (#33380) corrected this in AP_GPS using AP::ahrs() attitude, but that creates an EKF->sensor->EKF loop (a bad lane contaminates every lane) and breaks Replay. Instead: - AP_GPS records the body-frame offset used to calculate each moving-baseline yaw in GPS_State::mb_yaw_offset, exposed via AP_GPS::get_mb_yaw_offset(). The offset is zeroed whenever the published yaw does not come from a moving baseline (solution rejected, AGRICA lost, or a device-reported heading takes over: DroneCAN Heading, NMEA HDT/THS, KSXT) so a stale offset can never be paired with a heading it does not belong to. A shared yaw_source_instance() helper keeps the base->rover redirect identical between the yaw and the offset it accompanies. - AP_GPS also rejects moving-baseline solutions whose receiver-reported baseline has insufficient horizontal separation (sqrt(dist^2 - D^2) < AP_GPS_MB_MIN_ANTENNA_SEPARATION_M): a baseline close to vertical carries no usable yaw regardless of antenna separation. - AP_DAL carries the offset in a new low-rate RGPK message (written when changed), so Replay reproduces the fusion bit-exactly. Replaying older logs applies a zero offset, i.e. no correction. - AP_NavEKF3 buffers the offset with each yaw measurement and correctGPSYawForAntennaOffset() applies the residual correction after storedYawAng.recall(), using this core's own roll/pitch at the fusion horizon (lane-independent, Replay-exact). yawAngErr is inflated by the tilt sensitivity |z|/|xy| of the levelled baseline. A measurement whose baseline is too close to vertical at the estimated attitude is treated exactly like no measurement: not fused, not used for the (innovation-ungated) yaw alignment, and it does not refresh last_gps_yaw_ms — so GPS_COMPASS_FALLBACK still engages and yaw-source health reporting stays truthful while the GPS keeps publishing unusable yaw. The correction is gated behind EK3_FEATURE_MOVING_BASELINE (enabled on 2 MB+ boards and Replay/DAL builds, and only where GPS_MOVING_BASELINE is compiled in); 1 MB boards keep the existing level-assumption behaviour and pay none of the flash. Split into their own PRs (both found while working on this): - AP_GPS (Unicore NMEA): UNIHEADINGA reports the 3D baseline length and its elevation angle, so the vertical component is length*sin(pitch); using tan overstated it (11% at 26 deg) and exceeded the baseline length itself beyond 45 deg, which made steep antenna installations unable to ever provide yaw on this backend. → <link PR> - Replay: MSG_CREATE copied sizeof(msg) from a buffer that only holds the logged offsetof(_end) bytes, reading up to 4 bytes past the record (stack-buffer-overflow under AddressSanitizer for RGPI/RGPJ/RGPK). → <link PR>. This PR adds RGPK, which has tail padding like RGPI/RGPJ, so that Replay fix should land with or before this one for AddressSanitizer-clean replay of RGPK. Known limitation (pre-existing, unchanged): yaw forwarded over the DroneCAN gnss_Heading message (AP_Periph Heading fallback, FC-as-CAN-GPS) cannot carry the antenna offset, so it remains uncorrected on the consumer; the receiving driver zeroes the offset to make that explicit.

AP_Arming: Mission: check for zero takeoff alt (#33792)

master ← IamPete1:mission_zero_takeoff_pre_arm

opened 08:55PM - 22 Jul 26 UTC

IamPete1

+25 -6

### Summary A exactly zero takeoff alt is most likely a user error. ##…# 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 <img width="615" height="482" alt="image" src="https://github.com/user-attachments/assets/cee58d31-a13c-4ce8-a2ff-0a07c1de8ff9" /> Note that this does not check for negative takeoff altitudes.

CIRCLE (LOITER_TURNS) mission item using S-curves (#33837)

master ← lthall:20260726_CircleModeSCurve

opened 02:27PM - 26 Jul 26 UTC

+715 -150

### Summary Flies Copter's CIRCLE mission item (MAV_CMD_NAV_LOITER_TURNS) as …a single jerk-limited S-curve orbit leg on the waypoint engine, instead of the separate AC_Circle controller, so a circle accelerates, cruises and decelerates with the same S-curve profile as straight, arc and spline waypoints. ### Classification & Testing (check all that apply and add your own) - [ ] 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 SITL: mission_NAV_LOITER_TURNS and mission_NAV_LOITER_TURNS_off_center pass (fly-to-edge and start-on-edge entry). Standalone Circle mode is unchanged and regression-clean: ModeCircle, SuperSimpleCircle, CircleSpeed. Straight/arc/spline waypoint regression also clean: CopterMission, WPArcs, SplineLastWaypoint. New AP_Math gtest SCurveCircle.geometry checks the orbit holds radius, respects the centripetal speed limit, closes, and sweeps the correct direction across full/fractional/multi-turn/climbing/CW/CCW cases. ### Description Replaces AC_Circle for the Auto CIRCLE mission item with a single S-curve waypoint leg, in three layers: - AP_Math (SCurve): calculate_circle_track() builds one closed arc leg about a center for a signed number of turns (may exceed 2*pi) with an optional net climb, reusing the existing arc projection (a circle is just an arc that sweeps >= 360 deg). Also factors the shared setup into set_arc_geometry/set_straight_geometry/generate_path/finalise_path, used by both the chord-derived (calculate_track) and center-derived (calculate_circle_track) paths. - AC_WPNav: set_circle_destination_NED_m()/_loc() set up the orbit leg (origin taken as the current destination, which lies on the circle) and expose the orbit center for yaw. - ArduCopter (ModeAuto/AutoYaw): after the existing move-to-edge step, the orbit runs through wp_run() and verify_circle() completes on reached_wp_destination(). Yaw faces the circle center via an AutoYaw::Mode::CIRCLE fallback that reads the wp_nav orbit center, honoring CIRCLE_OPTIONS FACE_DIRECTION_OF_TRAVEL. AC_Circle and the standalone CIRCLE flight mode are unchanged; Auto still uses circle_nav only as the move-to-edge geometry/parameter store. move_vehicle_on_ekf_reset() now groups CIRCLE with WP (MoveVehicle) since the orbit is a wp_nav leg. Builds on the S-curve climbing-arc fixes (submitted separately): arc kinematic limits from arc length not chord, the velocity/acceleration projection fix, and removal of the unreachable arc degeneracy guard.

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

master ← IamPete1:quadplane_qtl_loiter

opened 09:01PM - 26 Jul 26 UTC

IamPete1

+103 -15

### 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 Param name matches copters [RTL_LOIT_TIME](https://ardupilot.org/copter/docs/parameters.html#rtl-loit-time) although its in seconds rather than the milliseconds which copter uses. 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_Math: SCurve: remove redundant arc path_unit normalization (#33860)

master ← lthall:20260728_SCurve_normalise_no-op

opened 04:14AM - 28 Jul 26 UTC

+2 -2

### Summary Remove a redundant normalize() of the arc-projection path unit ve…ctor in SCurve. The vector is unit length by construction, so the call only redid work already guaranteed by the geometry setup. - [x] Checked by a human programmer - [x] Non-functional change - [x] Tested manually, description below (e.g. SITL) ### Description In project_scurve_onto_track() the arc branch builds path_unit from the arc tangent and the vertical gradient, then normalizes it. The normalization is redundant. The magnitude of arc.center_ne equals radius_ne exactly. Its chord-midpoint and perpendicular-offset components are orthogonal, and the offset is defined as sqrt(radius^2 - (chord/2)^2). Rotation preserves magnitude, so arc_tangent_ne is unit length after dividing by radius_ne. The 3D combination is also unit length. seg_length is defined as sqrt(length_ne^2 + dz^2), so horiz_ds^2 + dz_ds^2 = 1. The normalize() therefore only corrected single-precision rounding on the order of 1 ulp, comparable to the rounding its own sqrt and division reintroduced. This change removes the call, documents the invariant with a comment, and makes path_unit const. Output velocity and acceleration can differ from master only at the last-bit level.

AP_Mission: fix get_next_nav_cmd (#33863)

master ← robertlong13:pr/fix-get-next-nav-cmd

opened 06:52AM - 28 Jul 26 UTC

robertlong13

+275 -94

### Summary - Fixes the broken DO_JUMP_TAG in copter (#31021). - Fixes an is…sue with tangent exit from loiters in plane when followed by a DO_JUMP_TAG (#21534, #32029) - This also contains a drive-by fix of an existing bug where loading a mission with an infinite loop of do commands would lock up the autopilot. ### Classification & Testing - [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 This supersedes PRs #32029 and #31038 On Copter, the next nav command is fetched before it is executed: `get_next_nav_cmd` supplies the target the S-curve calculations are shaped through, and `advance_current_nav_cmd` later loads what actually runs. Nothing guaranteed the two resolved the mission the same way, and around jumps they did not (as reported in #21534), causing Copter to claim it was flying to one waypoint (after it advances it) while flying to a different one (the one it fetched before). On Plane, we don't pre-fetch the next waypoint, so this bug has less dramatic impact. They disagreed because `get_next_nav_cmd` never actually followed a jump. The scan handed `get_next_cmd` a linearly incremented index each pass, so a jump's target was only glanced at (accepted if it happened to be a nav command directly, discarded otherwise) until the index walked past the jump and the scan continued in the linear sequence beyond it, reporting a nav command the vehicle may not fly next (and in fact, may *never* fly if that was an infinite jump). A jump tag is never a nav command, so `DO_JUMP_TAG` missions tripped this every time, but tags are just the common case of jumping to a non-nav command; a `DO_JUMP` which targets any non-nav command fails the same way. The fix builds on a small mechanism: the jump-resolving look-ups (`get_next_cmd`, `get_jump_times_run`, `increment_jump_times_run`) gain an optional jump cursor, a private copy of the do-jump counters, so a caller can scan ahead following jumps exactly as execution would, without spending the running mission's counters. **Fetch and execute now walk the same resolution path, differing only in whose counters they spend, so they cannot disagree.** That cursor replaces the two workarounds that existed for the same problem: the backup/restore-through-goto dance in the distance scans, and the `send_gcs_msg` flag (a jump is now reported to the GCS exactly when the live counters are the ones being advanced). `get_next_cmd` also takes over advancing the caller's scan position, so the resume-from-the-resolved-index rule is written once instead of six times: previously two of those six were wrong, including `distance_to_landing`'s inner scan (couldn't find anyone reporting any bugs from that, but that could have in theory messed with the logic for finding the closest landing on Plane). While bounding these searches, `set_current_cmd` turned out to have an unbounded one: a jump loop containing no nav command (a forever `DO_JUMP` over do commands) never terminates the search and hangs the main loop. It's now bounded the same way `advance_current_nav_cmd` bounds its own, failing the command instead. New autotests cover the four jump shapes (`DO_JUMP` and `DO_JUMP_TAG`, each landing on a nav and on a do command) by checking the vehicle's actual position rather than the reported waypoint, plus the set-current hang on Rover.

QuadPlane: fix QLoiter backtransitions (#33874)

master ← robertlong13:pr/qloiter-backtransition-fix

opened 08:00AM - 29 Jul 26 UTC

robertlong13

+224 -3

### Summary Fix a bug that can cause excessive position hunting when switchin…g to QLoiter/QLand from fixed-wing. ### 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 Currently, the stopping behavior when switching to QLoiter depends on state that accumulated during your transition to fixed-wing flight. This bug is long-standing (tested back to 4.5). Below are two screenshots from a test on master. <img width="1026" height="795" alt="image" src="https://github.com/user-attachments/assets/b48041a0-e86b-43db-9be2-1006d916d6b2" /> <img width="892" height="855" alt="image" src="https://github.com/user-attachments/assets/c0cbecad-1dad-4bb7-b96b-8b025be68864" /> If you don't do your outbound transition perfectly straight with wings level, you get this weird hard bank when you switch into QLoiter/QLand. The fix I'm proposing in this PR is to initialize the loiter at the current position, re-seeding the velocity PID integrator for a pure brake (only when initializing from a period of position controller inactivity). The vehicle now rolls wings level and pitches back to a stop from any entry attitude, regardless of the state of the forwar-transition, stopping in ~6s from 25m/s and remaining within 2m of the final landing point, where it previously wallowed for 13s and wandered around more than 10m. Screenshot of ground tracks before/after my fix: <img width="1080" height="810" alt="image" src="https://github.com/user-attachments/assets/a68f9f7d-52cb-411d-a0db-a25325a1d236" /> My only issue is that the code for my fix *looks* a tad hacky with the `vel_pid` stuff I'm doing, but I think the idea is sound, and I believe this is the cleanest way to achieve it. @lthall (or anyone else) if you have any opinions on a better shape of this, I'd be happy to hear them. Or if you just wanna swipe my autotest and fix this a different way in a superseding PR, I'm totally fine with that. The new autotest reliably fails, on all 4 criteria, before the fix, and reliably passes after. Plenty of headroom. ### Turning transition (transition tail freezes a banked attitude target) | criterion | bound | master (3 runs) | with fix (3 runs) | | --------- | ----- | --------------- | ----------------- | | retreat from closest approach to stopping point | < 5 m | **10.03 / 9.37 / 11.98** | 1.89 / 1.90 / 1.88 | | settle from 20 m out to within 2 m | < 8 s | **11.60 / 11.30 / 12.60** | 2.10 / 2.10 / 2.10 | | ground-course winding above 3 m/s | < 60° | **318 / 314 / 338** | 18.0 / 18.0 / 17.9 | | N/S displacement of stopping point from entry | < 25 m | **43.3 / 44.8 / 42.5** | 16.9 / 17.0 / 17.0 | Every master run fails all four criteria; every fixed run passes all four. ### Straight transition (control: transition tail freezes a level attitude target) | criterion | bound | master (3 runs) | with fix (3 runs) | | --------- | ----- | --------------- | ----------------- | | retreat from closest approach to stopping point | < 5 m | 1.86 / 1.84 / 1.84 | 1.89 / 1.89 / 1.88 | | settle from 20 m out to within 2 m | < 8 s | 2.10 / 2.10 / 2.10 | 2.10 / 2.10 / 2.10 | | ground-course winding above 3 m/s | < 60° | 14.4 / 14.4 / 14.4 | 9.4 / 17.5 / 17.7 | | N/S displacement of stopping point from entry | < 25 m | 13.2 / 13.2 / 13.2 | 17.5 / 17.4 / 14.9 | Master already passes when its stale attitude target happens to be level, the same code and thresholds, demonstrating the expectation is realistic and the fix simply makes the happy case the only case.

Allow for stabilization at zero throttle and zero rp demand when armed with airmode switch (#33890)

master ← peterbarker:pr-claude2/copter-airmode-arm-switch

opened 01:30PM - 30 Jul 26 UTC

+242 -3

### Summary Fixes a few bugs around airmode stabilization at zero throttle in… stabilize. ### Classification & Testing (check all that apply and add your own) - [ ] 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 From report on Discord: ``` Hello, I've got a question. What can cause airmode not to work in stabilize mode? I've setup arming with airmode on channel 5 (rc5_option = 154) but when the quad is in the air (in stabilize mode) and I cut the throttle it doesn't stabilize and tumbles. for acro mode I've set airmode in acro_options and in acro mode it now works. But it seems that arm with air mode doesn't enable airmode. Arming_rudder is set to 2 (arm or disarm) but I'm not arming with the rudder. I'm arming with channel 5. Any idea's? [8:13 PM]Andy Piper: interesting, it should work if you have airmode on a switch, not sure why it would not [8:30 PM]Flyiarius: And from the logs I can see that if you have throttle at 0 but give a little bit of roll or pitch, then it does stabilize and rcou does change. But when throttle is at zero and no pitch/roll input, it doesn't stabilize [10:48 PM]Peter Barker: What are your values for ATC_THR_MIX_MAN and THR_MIX_MIN? [11:03 PM]Flyiarius: Mix_man is 0.5. the other i have to verify, but i have to review the logs when I'm home again to see the value. [11:13 PM]Peter Barker: So there does appear to be a bug here, but it does require those two parameters to have different values. ```

AP_Follow: discard target state when FOLL_SYSID changes (#33891)

master ← lthall:20260731_bug_when_FOLL_SYSID_changes

opened 03:05PM - 30 Jul 26 UTC

+67 -39

### Summary FOLL_SYSID only filters incoming messages; it does not invalidate… the target data already held, so after a change the library keeps reporting the previous vehicle's position, velocity and heading as valid. This makes the held target state belong to the system named by FOLL_SYSID. ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [x] Tested manually, description below (e.g. SITL) Found in a Copter flight log where a Lua script switched FOLL_SYSID between two beacons roughly 5 m apart. The vehicle continued to be positioned relative to the previous beacon, and the mode consuming the follow estimate advanced its state machine against the old beacon's geometry. SITL Copter ModeFollow_with_FOLLOW_TARGET and three ship-landing tests exercising GLOBAL_POSITION_INT follow pass with this change on a downstream branch. No existing autotest changes FOLL_SYSID in flight, so the retarget path itself is not covered by automated testing. ### Description _sysid is used only as an inbound filter in should_handle_message(). The cached target state carries no record of which system supplied it, and have_target() checks only the age of _last_location_update_ms. So for up to FOLL_TIMEOUT after FOLL_SYSID changes, get_target_sysid() reports the new vehicle while every getter returns the previous one. update_estimates() noticed the change but only cleared _estimate_valid, and the re-init branch immediately re-seeded the estimate from the previous target's last position and marked it valid again. Two other pieces of state also survived a retarget. _using_follow_target latches when a FOLLOW_TARGET message arrives and causes every GLOBAL_POSITION_INT to be rejected, so retargeting from a FOLLOW_TARGET vehicle to one that only sends GLOBAL_POSITION_INT stalled until the 10 second sysid timeout. _automatic_sysid was set on adoption and never cleared, so a later explicit FOLL_SYSID write could be discarded by that same timeout and the parameter reset to 0. The change gives _sysid_used a single meaning, the system that supplied the data currently held, updated wherever an update is accepted. have_target() rejects a mismatch, so the estimate and every getter report no target until the new system transmits. On a mismatch the FOLLOW_TARGET preference is dropped and _automatic_sysid is cleared, since a parameter write has superseded an adoption. The estimate is reset when an accepted update comes from a different system, so it snaps to the new target rather than shaping across the gap. Sysid adoption for FOLL_SYSID = 0 was duplicated in both message decoders and is now done once in handle_msg(), along with the _using_follow_target gate on GLOBAL_POSITION_INT. No parameter changes, and no behaviour change while FOLL_SYSID is fixed.

Tools: ros2: tear down rclpy cleanly in the AP_DDS tests (#33894)

master ← peterbarker:pr-claude2/dds-test-teardown

opened 10:25PM - 30 Jul 26 UTC

+100 -154

### Summary Fixes segfault recently starting in colcon tests ### Classific…ation & 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) - [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 Every test in ardupilot_dds_tests tore down with nothing but rclpy.shutdown(), which shuts the context down while that context's node, subscriptions and DDS participant are all still alive, and left its rclpy.spin() thread unjoined. colcon runs the whole package in one interpreter, so those zombie endpoints accumulated from test to test. They race with Fast-DDS intra-process delivery, and the process intermittently died with SIGSEGV on an internal DDS thread: History::get_change_nts StatefulReader::NotifyChanges StatefulReader::change_received StatefulReader::processDataMsg StatefulWriter::deliver_sample_to_intraprocesses FlowControllerImpl<...>::run Both CI occurrences were in the 22nd of the 23 tests, i.e. at maximum accumulation, and killed the whole pytest run with exit code -11. rclpy.spin() cannot be torn down cleanly: it uses a process-wide global executor bound to whichever context was current when the first test span, and the only way to make it return is to shut the context down. So spin on a private SingleThreadedExecutor via a ros_node() context manager, which shuts the executor down, joins the spin thread and destroys the node while the context is still valid. Reproduced by repeating the time tests in one pytest process (pytest --count=40). Over 6 shards x 4 loops, with identical harness and only this change differing: 4 of 24 loops segfaulted before, 0 of 24 after, with all 80 tests passing in every loop.

Fix ending comments where the `#endif // COMMENT` didn't match the opening if (#33920)

master ← peterbarker:pr-claude2/ending-comment-fixes

opened 03:28AM - 03 Aug 26 UTC

+44 -44

### Summary Corrects 44 trailing comments on `#endif` lines which named the w…rong macro (or a long-gone one), across 41 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 - [ ] 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 Verified comment-only by stripping everything after `//` from each changed line: all 44 old/new pairs are byte-identical up to the comment, so no preprocessing or object code can change. `git diff --check` is clean. Found via a script tracking the preprocessor-conditional stack and flagging `#endif` comments whose macro-like identifiers don't appear in the matching opening condition; the tree was re-scanned after the fixes. Also cross-checked by an independent automated review (OpenAI Codex), which confirmed all 44 edits match their openers and that each commit touches only its named subsystem. ``` Board AP_Periph antennatracker blimp bootloader copter heli iofirmware plane rover sub CubeOrange-periph-heavy * * Durandal * * * * * * * * Hitec-Airspeed * * KakuteH7-bdshot * * * * * * * * MatekF405 * * * * * * * * Pixhawk1-1M-bdshot * * * * * * * f103-QiotekPeriph * * f303-Universal * * iomcu * revo-mini * * * * * * * * skyviper-v2450 * ``` ### Description Wrong comments worse than no comments..... These are stale or copy-pasted `#endif // MACRO` comments that mislead when reading the bottom of a conditional block. They fall into a few buckets: - **renamed macros, stale comments**: e.g. `// DISABLE_DSHOT` → `HAL_DSHOT_ENABLED`, `// VTX_TRAMP` → `AP_TRAMP_ENABLED`, `// CAMERA == ENABLED` → `AP_CAMERA_ENABLED`, `// HAL_NUM_CAN_IFACES` → `HAL_ENABLE_DRONECAN_DRIVERS` (3 files), an old `__..._H__` include-guard comment left on a board gate - **copy-paste from a neighbouring driver**: `SIM_GPIO_LED_1.h` ended with `LED_2`, TOFSenseP ended with `USD1`, HMC5843 probing closed as `KMC5843`, IIS2MDC closed as `QMC5883P`, MS4525 closed as `MSP` - **plain typos**: `HAL_LOGING_ENABLED`, `AP_RCPROTCOL_ENABLED`, `AP_RADIO_CYRPRESS_ENABLED`, `Ac_WPNAV_OA_ENABLED` - **wrong-but-plausible**: e.g. `AP_FENCE_ENABLED` where the condition is `HAL_LOGGER_FENCE_ENABLED`, `AP_SIM_ENABLED` for `AP_SIM_PARAM_ENABLED` Every case was a wrong comment on a correctly-placed `#endif` — no mismatched nesting was found. #### Scope: what was deliberately *not* changed The rule applied here is narrow: fix comments that name the **wrong** macro. A second-opinion review suggested also normalising several looser-but-not-wrong patterns in the touched files; these were intentionally left alone to keep the PR trivially reviewable and free of style churn: - **Partial comments on compound conditions** (e.g. `Tools/AP_Periph/can.cpp`, `AP_DroneCAN.cpp`, `SRV_Channels.cpp` naming one clause of an `A && B` / `A || B` condition): the named macro is correct as far as it goes, and naming the dominant clause is an established convention in the tree. - **`#endif //#if FOO` style** (literal `#if` inside the comment, e.g. `AP_Compass.cpp`, `AP_GPS.cpp`, `RCOutput.cpp`, `stm32_util.c`): the macro named is correct in every instance; this pattern appears throughout the codebase and changing it is cosmetic churn, not a correctness fix. - **Descriptive prose comments** (`// HAL_SITL or HAL_LINUX`, `// I2C or SPI`, `// STM32xx`, `// F7, H7, F4`, `// MCU`): accurate shorthand for long conditions, not macro references. - **Negated-condition comments on `#else` arms** (e.g. `LoggerMessageWriter.cpp` `// !APM_BUILD_TYPE(APM_BUILD_Replay)`): documenting which arm is ending is a legitimate competing convention, not an error. - **Vendored code** (`AP_GyroFFT/CMSIS_5`): third-party, not ours to restyle. One judgement call in the same spirit: `AP_HAL_Linux/RCInput_RCProtocol.cpp` closed an eight-way board-subtype comparison with `// HAL`; it now says `// CONFIG_HAL_BOARD_SUBTYPE`, naming what is tested rather than reproducing the 8-line condition.

Make takeoff() in Copter test suites more reliable (#33822)

master ← peterbarker:pr-claude2/takeoff-altitude-max

opened 05:17AM - 24 Jul 26 UTC