ArduPilot EU Dev Call 2026-05-06

Rp2350 port WIP for feedback

master ← davidbuzz:rp2350-v5-squashed-and-cleaned-and-rebased

opened 06:56AM - 06 May 26 UTC

davidbuzz

+12652 -807

### Summary AP_HAL_ChibiOS: introduce RP2350 port — Raspberry Pi Pico 2 and L…aurel boards ### 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 - [x ] Logs available on request ### Description RP2350 is NEW HARDWARE support! Question - AP_HAL_ChibiOS has traditionally been stm32-only, and this PR breaks this barrier by using #defines for STM32_HW ( any stm32 board gets this) , and RP2350_HW ( 2x new boards getting this target ). Is this concerpt acceptable, or would tridge rather a totally separate AP_HAL_RP2350 port that doesnt overlap the existign one at all.? Where a HAL can be made to run on multiple hardware/manufacturer .. do we..? option 1 - we keep them in the same HAL separated by manufacturer-specific #defines.? option 2 - make an "overlay hal" that uses most of the current HAL, but pushes the non-stm32-isms to a separaate "overlay" hal that only implements the extras option3 - give it its own totallly unique HAL , eg AP_HAL_RP2350 or AP_HAL_Pico or something, that is hard-forked-from the current chibios port, never to return ? This PR is an initial attempt at option 1. We have an initial attempt at option 2 - here: https://github.com/andyp1per/ardupilot/tree/rp2350-v5

Buzz: It’s been a difficult port, working on it for weeks.

The ChibiOS RP2350 port is very new.
There isn’t a lot of RAM to work with.
The 2nd CPU is handling the rate thread.
The 2nd CPU can’t handle semaphores for some reason. Hence we don’t run a scheduler on that yet.
The 1st CPU sends tasks to the 2nd one to execute.
RAMFUNC makes a lot of difference in execution speed.

Andrew: There are a lot of =0 variable initializations, these should eventually go.
Buzz: I’ve benchtested a lot, soon to fly.

The CPU is stressed, so I tried to get as many savings as I could. One of these were to delay file open until file read.

A: I would prefer the linker method, have different function implementations for different HALs. Instead of using RAMFUNC.

Linker scripts are autogenerated.

Buzz: We’re overclockig this unit at 375MHz.
A: Then why aren’t you getting the required performance? We’re running F405 at 168MHz.

Perhaps you could try disabling the 2nd core and re-compile ChibiOS telling it that it’s a single-core system. The scheduler is likely to become a lot more efficient, as ChibiOS isn’t very capable yet in multi-core systems.
There’s the Tools/cpuinfo program that will produce benchmark output. Might be useful to compare the RP2350 in terms of performance with our current boards, and inform your multicore approach.
Pay special attention to memory access functions, they are crucial for scheduling.
Do the cpuinfo run, it’s crucial for making architectural decisions.

UTC0739

AP_NavEKF3: gate stationary zero-velocity fusion on !inFlight

master ← andyp1per:fix-ekf3-zerovel-takeoff-expected-inflight

opened 03:32PM - 04 May 26 UTC

+19 -12

### Summary Fixes #32980. PR #32396's stationary zero-velocity fusion was gated… on `onGroundNotMoving || dal.get_takeoff_expected()`. The second half of that gate is unsafe for Plane: `Plane::set_takeoff_expected()` asserts the flag whenever `!is_flying() && armed && (throw_detected || throttle > throttle_cruise)`, and `Plane::is_flying()` is probabilistic — during aggressive maneuvers it can briefly drop below 0.1, producing a transient `takeoff_expected` pulse on a vehicle that is actually flying. With no GPS/flow/body-vel aiding (e.g. dead reckoning) the new fusion then injects `velPosObs=(0,0,0)` at 1 m/s noise, the EKF velocity state is pulled toward zero, FuseAirspeed produces a large innovation absorbed by the wind state, and DR position drifts at the corrupt wind. Gate on `!inFlight` instead. That flag stays false through the armed-on-ground period (preserving the Copter pre-liftoff case the original fusion was designed for) and only goes true once `detectFlight()` has high certainty the vehicle is flying. `onGround` would have been too tight — it goes false the moment motors arm. ### Classification & Testing - [x] Checked by a human programmer - [x] Tested manually, description below (e.g. SITL) - [x] Automated test(s) verify changes (e.g. unit test, autotest) `test.Plane.GuidedAttitudeNoGPS` reproduces the regression on master and recovers pre-PR-32396 behavior with this fix: | Build | Wind VWN @ t=120s | Wind VWE @ t=120s | DR position PN @ t=125s | |---|---|---|---| | Pre-PR-32396 | 0.72 | -0.09 | -481.3 | | Master (broken) | 20.08 | 12.47 | -589.7 | | With this fix | 0.71 | -0.09 | -481.9 | The four autotests added in PR #32396 still pass: `EK3_AccelBiasInhibitOnGroundMoving`, `EK3_AccelBiasZeroVelOptFlow`, `EK3_ZeroVelFusionNotUsedWithGPS`, `EK3AccelBias`. ### Description Two-line behavior change in `SelectVelPosFusion()`: both `onGroundNotFlying` constructions now AND with `!inFlight`. Comments above each construction document why `!inFlight` rather than `onGround`. No other state, parameters, or fusion paths touched.

A: EKF currently doesn’t have a problem when running on AUTO.
P: Perhaps Plane: regression in non-GPS navigation · Issue #32980 · ArduPilot/ardupilot · GitHub is what is referred to.

UTC0745

Minor test suite reliability improvements

master ← peterbarker:pr/minor-test-fixes

opened 02:36AM - 04 May 26 UTC

+10 -10

### Summary Several test fixes extracted from a larger PR which brings out al…l of the race conditions.... ### 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) - [ ] Tested manually, description below (e.g. SITL) - [ ] Tested on hardware - [ ] Logs attached - [ ] Logs available on request ### Description Random autotest suite fixes - several because we're just right on the edge of failing. ``` 4488fdf70b5 autotest: loosen constraint on altitude after GPS glitch 845fbe2af67 autotest: allow more time for quadplane landing da6aa81a1f4 autotest: TakeoffTakeoff4 increase TKOFF_LVL_ALT 4882860b788 autotest: Rover: loosen get-home constraint d1d7d8003a4 autotest: remove race condition from TakeoffTakeoff5 ```

Merged!

UTC0746

Add compilation gates for MAV_CMD_GET_HOME_POSITION

master ← peterbarker:pr/AP_MAVLINK_MAV_CMD_GET_HOME_POSITION_ENABLED

opened 10:54AM - 01 May 26 UTC

+17 -4

### Summary Allows GET_HOME_POSITION to be compiled out and adds a schedule f…or it to be removed from the code ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] Non-functional change - [x] 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 No compiler change: ``` Board AP_Periph antennatracker blimp bootloader copter heli iofirmware plane rover sub Durandal * * * * * * * * Hitec-Airspeed * * KakuteH7-bdshot * * * * * * * * MatekF405 * * * * * * * * MatekH7A3 * * * * * * * * Pixhawk1-1M-bdshot * * * * * * * SITL_x86_64_linux_gnu * * * * * * * YJUAV_A6SE * * * * * * * * f103-QiotekPeriph * * f303-MatekGPS * * f303-Universal * * iomcu * mindpx-v2 * * * * * * * * revo-mini * * * * * * * * skyviper-v2450 * speedybeef4 * * * * * * * * ``` Compiles when the option is disabled: ``` Board,plane CubeOrangePlus,-80 ``` ### Description This message has been superseded by using `MAV_CMD_REQUEST_MESSAGE`. Doesn't save a lot of bytes, but codepaths can be cleaner on the GCS side.

Merged!

UTC0747

Add sanity check that normal-board hwdefs do not contain AP_PERIPH_ defines

master ← peterbarker:pr-claude/hwdef-no-AP_PERIP-defines

opened 09:09AM - 01 May 26 UTC

+37 -7

### Summary Removes bad defines from hwdefs, adds sanity checks that more do …not appear. ### Classification & Testing (check all that apply and add your own) - [x] Checked by a human programmer - [ ] 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 ### Description Several normal boards included these, and we've bounced several before, too.

A: Did we accidentally change binary sizes now?
P: No, it doesn’t.

UTC0749

AP_NavEKF3: clear baro temperature drift on arming

master ← andyp1per:pr-baro-drift-minimum

opened 07:40PM - 13 Apr 26 UTC

+473 -87

## Summary Clears accumulated baro temperature drift at arm time so it does not… carry into flight as a persistent altitude error. This matters most for indoor / baro-only flight where baro is the sole height source. Before this change, Copter only called `resetHeightDatum()` when home was unset. Once home had been established (from a previous GPS fix, or `AHRS_ORIGIN` parameters), several metres of disarmed-period drift would survive into the flight and corrupt altitude tracking. ## Why arm-time, not periodic An earlier iteration ran `resetHeightDatum()` every 5 s while disarmed, mirroring Plane's `update_home()`. That broke the EKF's on-ground accel-bias learning — four autotests on master failed: `EK3AccelBias`, `EK3_AccelBiasInhibitOnGroundMoving`, `EK3_AccelBiasZeroVelOptFlow`, `EK3_ZeroVelFusionNotUsedWithGPS`. `resetHeightDatum()` warps `position.z` and `velocity.z` outside the Kalman update path. Bias learning relies on cumulative prediction error being observable through baro / zero-velocity innovations — a periodic state warp discards that error before it can drive the bias estimate. The bias state itself is preserved across the reset, but the observation pathway that converges it is severed. Arm-time reset avoids this entirely: bias learning runs uninterrupted while disarmed, then drift is cleared at the one moment accuracy starts to matter. (Plane has the same latent conflict in `update_home()` but it is operationally hidden by GPS-velocity driving bias learning whenever the periodic reset fires.) ## Changes - **AP_NavEKF3** — shift `ekfGpsRefHgt` instead of mutating `EKF_origin.alt`. Origin must be immutable; user-configured origins (`AHRS_ORIGIN`, `MAV_CMD_DO_SET_GLOBAL_ORIGIN`) get corrupted otherwise. - **Copter** — add `resetHeightDatum()` to the `!home_is_locked()` re-arm branch, with new `HGT_RESET_ALT` parameter to suppress the reset on a real elevation change between flights. - **Plane** — align `update_home()`'s safety guard with the new origin-immutability behaviour (altitude-above-origin instead of baro altitude). - **autotest** — add `BaroDriftClearedAtArm` (drift cleared at arm), `AmslAltPreservedOnRearmAtDifferentElevation` (cliff scenario), `AmslAltPreservedAfterUpdateHomeAtDifferentElevation` (QuadPlane equivalent); relax `Clamp` lower bound for the new baro-zero-mean noise. ## Stacking On top of #32770 (buffer-flush fix). `resetHeightDatum()` must clear the `storedBaro` and output observer buffers cleanly or the post-arm altitude shows a ~0.4 m transient. When #32770 merges, this branch will rebase to master cleanly. ## Test plan - [x] All 4 previously-failing accel-bias tests now pass - [x] `BaroDriftClearedAtArm` passes both subtests (peak excursion < 0.1 m post-arm) - [x] `AmslAltPreservedOnRearmAtDifferentElevation` passes (cliff scenario) - [x] `EK3HeightDatumResetFlushesBuffers` (#32770) passes - [x] No regression in `FarOrigin`, `HomeAltResetTest`, `Clamp`

A: This looks like a significant behaviour change in Plane. It’s not acceptable.

We should create an autotest for Plane, to ensure this behaviour is well-defined.
Randy was open to making the Copter arming behaviour the same as Plane’s.

UTC0758

Copter: add ground effect altitude and timeout parameters

master ← andyp1per:pr-ground-effect

opened 02:25PM - 17 Mar 26 UTC

+120 -5

## Summary - Add TKOFF_GNDEFF_ALT parameter to control altitude threshold for gr…ound effect compensation - Add TKOFF_GNDEFF_TMO parameter requiring both timeout AND altitude before disabling ground effect - Ground effect re-enabled on descent below threshold; touchdown detection limited to below threshold ## Details On vehicles with severe baro ground effect, the EKF altitude can falsely cross the default 0.5m threshold due to baro noise, prematurely disabling ground effect protection. TKOFF_GNDEFF_ALT allows tuning this threshold. TKOFF_GNDEFF_TMO adds a time gate so ground effect is only disabled after both the timeout has elapsed AND the altitude threshold is exceeded, preventing premature disabling from noisy baro readings. ## Test plan - [x] SITL builds clean - [x] TakeoffGroundEffectAlt autotest passes - [x] Test on vehicle with known baro ground effect issues

A: I don’t think we model ground effect in our SITL models.
P: The proposed autotest suggests there is?

UTC0809

AP_InertialSensor: add IMU low drift support low drift IMUs

master ← andyp1per:pr-ins-low-noise

opened 08:57PM - 08 Mar 26 UTC

+78 -7

## Summary - Add `AP_INERTIALSENSOR_LOW_NOISE` define that boards can set in …their hwdef to indicate a low-noise IMU configuration - When enabled, reduce EKF3 gyro bias learning limits (`GYRO_BIAS_LIMIT` from 0.5 to `radians(2.0)` and `InitialGyroBiasUncertainty` from 2.5 to 1.0) since low-noise IMUs don't need as wide bias estimation range This allows boards with known low-noise IMUs (e.g. ICM-42688-P with good vibration isolation) to get tighter EKF tuning automatically, improving convergence speed and reducing false bias estimates. ## Test plan - [x] Build with `AP_INERTIALSENSOR_LOW_NOISE0` (default) - verify unchanged behavior - [x] Build with `AP_INERTIALSENSOR_LOW_NOISE1` in hwdef - verify tighter bias limits - [x] SITL test comparing EKF3 gyro bias convergence with and without the flag - [x] Verify no build warnings or errors on common boards

A: The RISI is a log message crucial to EKF replay. Changing it will break log replay.

Better to create a new, low rate message to log the new quantiies.
We should consider the following (edge) case: Someone has disabled the gyro calibration upon startup and he’s got a bad calibration. With this change the EKF won’t give as much of a leeway to wind up the bias state to account for all of that offset.

UTC0820

Add EKF bootstrap reset aux function

master ← andyp1per:pr-ekf-reset

opened 04:39PM - 14 Feb 26 UTC

+167 -3

## Summary In certain circumstances - particularly moving platforms or in the… case of a crash - the EKF can wedge itself in an unrecoverable state. For instance in a small copter, crash, turtle and try and re-arm - the EKF can be permanently failed. In these circumstances doing a soft reset of the EKF is far preferable to a hard reset of the flight controller which can easily involve hardware resets of peripherals that take a while to come up. An EKF reset can complete in <1s. - Add `NavEKF3::InitialiseFilterBootstrap()` public method that clears `statesInitialised` and re-runs bootstrap alignment on all cores - Add `AP_AHRS::reset_ekf_bootstrap()` to expose the reset through the AHRS interface - Add `RCx_OPTION=187` (EKF_RESET) aux function that triggers a full EKF bootstrap reset on HIGH, gated to fire only on state transition (not continuously) - Add SITL autotest `EKFBootstrapReset` that verifies the reset triggers in flight and the vehicle remains stable ## Test plan - [x] `test.Copter.EKFBootstrapReset` passes on SITL - [X] Review that EKF recovers to full navigation after reset in flight - [X] Test on hardware with magnetic disturbance scenario

A: There’s bug that will allow EKF reset when armed.
P: And the test actually tests that we CAN do it!

UTC0828

P: I’ll fix the DEVTYPEs myself.
A: The IMU output seems to be only 1468Hz. I was expected it to be faster. Not that it’s unusable.

It’s trying to do 1475Hz, so it looks deliberate.

MergedOnCIPass!

UTC0843

Tools: Script to sort PRs by time

master ← Georacer:pr/pr_sorter

opened 02:07PM - 29 Apr 26 UTC

Georacer

+135 -0

### Summary This Python script sorts a list of PRs by time. Useful for cherry…-picking and backporting multiple commits from master onto a release branch. ### 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 ### Description Usage: ```bash python sort_prs_by_merge_time.py pr_urls.txt > sorted_pr_list.txt ``` or if you're one of the cool kids: ```bash uv run sort_prs_by_merge_time.py pr_urls.txt > sorted_pr_list.txt ``` which will automatically install the dependencies on an isolated environment. You will probably need to generate a (free) Github API token for this to be useful, and export it to your environment. The input ``` https://github.com/ArduPilot/ardupilot/pull/32408 https://github.com/ArduPilot/ardupilot/pull/31619 https://github.com/ArduPilot/ardupilot/pull/32488 https://github.com/ArduPilot/ardupilot/pull/32128 https://github.com/ArduPilot/ardupilot/pull/32248 ``` will produce an output of the form: ``` PRs in chronological order in which they were merged: https://github.com/ArduPilot/ardupilot/pull/32574 AP_InertialSensor: add LSM6DSV16X backend support by zebulon-86 at 2026-04-01 08:03:47+00:00 4 commit(s) ending in: b6fb10b91c310e23a064720b609cad13b1119e20 https://github.com/ArduPilot/ardupilot/pull/32058 AP_HAL_ChibiOS:add VUAV-TinyV7 by viewpro-caijie at 2026-04-01 08:35:46+00:00 3 commit(s) ending in: 4f1e86bf41eda77f1946cd432396551683224170 https://github.com/ArduPilot/ardupilot/pull/32171 AP_Baro: read data from BMP581 twice, reject if not identical by peterbarker at 2026-04-13 10:40:30+00:00 2 commit(s) ending in: 40529b9dfdd451832f0d145310b64a301a754743 ``` This is useful because it tells you which commit hash you have to look on master and how many commits below it, which came with this PR, you need to cherry pick. Used DeepSeek to code it.

P: CI doesn’t have the git module. How about using what’s there in build_script_base.py?

Also, please create a class for those functions.

UTC0850

Fixes for embedded-JSON-and-parms

master ← peterbarker:pr/json-key-names

opened 01:48PM - 04 May 26 UTC