Georacer
April 15, 2026, 9:02am
1
Attendees (unique): 12
UTC0711
master ← andyp1per:pr-chibios-upgrade
opened 10:20AM - 10 Jul 25 UTC
Upgrade ChibiOS to the latest stable version with support for hal v9.1 and H5
…
Currently boots on a Pixhawk6X and TBS Lucid H7
Andy : This is ready for testing.
The new version of ChibiOS has quite a few changes.
We have a lot of patches of our own on our custom fork, which won’t necessarily be PRed easilly upstream.
In some specific MCUs (e.g. G441) there are significant driver changes (e.g. DMA), so we need to be careful and test thoroughly.
Will have H5, RP2040 and RP2350 support!
H5 is a modern replacement to the F4.
Peter : Let’s ensure we don’t force-push and drop the existing ArduPilot/ChibiOS branch and pull hash which we use.Andrew : Yes, we didn’t do a good job in preserving the branch.
UTC0727
master ← andyp1per:pr-baro-drift-minimum
opened 07:40PM - 13 Apr 26 UTC
## Summary
Minimum fix for baro temperature drift persisting as altitude erro… r after arming, split out from #32400 at @rmackay9's request on the dev call.
When a copter sits disarmed on the ground, baro drifts from temperature changes (typically several metres after 30s on small copters). Before this change, `resetHeightDatum()` is only called in Copter arming when home is not yet set -- so once home has been established (from a previous GPS fix or from `AHRS_ORIGIN` parameters), the accumulated drift carries into flight. This matters most for indoor / baro-only flight, where baro is the sole height source.
## Changes
**`AP_NavEKF3: do not mutate EKF origin altitude in resetHeightDatum`**
Removes the `EKF_origin.alt += ...` / `copy_alt_from(gps)` writes from `NavEKF3_core::resetHeightDatum()`. The origin is the NED reference frame anchor and must be immutable once set; mutating it on a datum reset corrupts the configured origin when it was deliberately set far from the vehicle's current location (e.g. `AHRS_ORIGIN` params, or `MAV_CMD_DO_SET_GLOBAL_ORIGIN` pre-arm). The baro recalibration + `position.z = 0` are already consistent with an unchanged origin.
**`Copter: reset EKF height datum on arming when home is not locked`**
Adds `ahrs.resetHeightDatum()` to the existing `!home_is_locked()` branch of `AP_Arming_Copter::arm`, mirroring the pattern already used in Plane's `update_home()`. The `home_is_locked()` branch is left alone so that re-arming far from takeoff (e.g. landing at sea level after a cliff-top launch) preserves absolute altitude.
**`autotest: add BaroDriftResetOnArm test`**
Two subtests that both fail on master:
1. GPS sets home, then GPS lost, baro drifts 9m, arm -- altitude must reset to ~0m.
2. No GPS ever, origin from `AHRS_ORIGIN` params, baro drifts 9m, arm -- altitude must reset to ~0m.
**`autotest: add test for Copter descent behaviour far from home`** (@peterbarker)
Cherry-picked from the parent PR -- proves the origin-immutability fix preserves the cliff-top-to-sea-level and back scenario.
**`autotest: relax Clamp altitude lower bound for baro noise`**
With the datum reset, baro reads zero at arming, so zero-mean noise now crosses zero. The Clamp test checks a clamped vehicle does not take off; tightened lower bound from 0 m to -0.2 m (observed excursion ~1 cm; still catches any real liftoff).
## Ancestry
Split out from #32400 as the minimum viable fix.
The original PR remains open with the broader scope; this PR is the narrowest subset that fixes the baro-drift-on-arm bug and keeps all existing tests passing.
## Test plan
Passing on `pr-baro-drift-minimum`:
- [x] `BaroDriftResetOnArm` (new) -- both subtests
- [x] `HomeAltResetTest` (new, Peter's cliff test)
- [x] `FarOrigin` (regression that motivated the origin-immutability commit)
- [x] `AltEstimation`, `EKFSource`, `Clamp`, `TakeoffCheck`, `TakeoffAlt`, `LoiterToAlt`, `Landing`, `ArmFeatures`, `AltTypes`, `AutoRTL`, `Weathervane`, `ThrowMode`, `AutoTune`, `VisionPosition`, `NavDelayAbsTime`
- [x] Helicopter `StabilizeTakeOff`, `PosHoldTakeOff` (passes at original 0.1m threshold -- no heli test changes needed)
`BodyFrameOdom` fails identically on clean `upstream/master` with a pymavlink unpack error; pre-existing, unrelated.
Peter : Is it okay that the origin is now rendered mutable?Randy : Also I think you’re not checking if we’re actually using a barometer, but some other sensor.
(Discussion on how LLMs - Claude in this case - can become too wordy. This costs reviewers’ time.)
UTC0746
master ← andyp1per:pr-ekf-reset
opened 04:39PM - 14 Feb 26 UTC
## 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
Andy : This helps when you move before arming and get your EKF to a bad state. It helps reset it quickly.Randy : We will need to study such cases, having logs will be nice.P : For dangerous features, it’s smart to gate them behind a https://github.com/ArduPilot/ardupilot/pull/define . Some vendors have reported that clients have tried very dumb things and they’d rather those features compiled out.
InitializeFilterBootstrap() will likely be dangerous. Let’s pay some more attention on it.
Andrew : Estimators can’t ask the gyro to re-initialize. It will for sure affect other estimators badly. And it won’t help with log replay either.
Andy : I’ll take it out, that’s okay.
UTC0817
master ← peterbarker:pr/pr-claude/skyviper-v2450-inline-fmuv3
opened 12:48PM - 14 Apr 26 UTC
### Summary
Remove vestiges of IOMCU configuration from skyviper-v2450 - whic… h does not have one of those!
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [ ] No-binary change
- [ ] Infrastructure change (e.g. unit tests, helper scripts)
- [ ] Automated test(s) verify changes (e.g. unit test, autotest)
- [ ] Tested manually, description below (e.g. SITL)
- [x] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
I flashed and flew this on one of my SkyVipers
### Description
SkyViper has no IO MCU. Remove the embedded IOMCU firmware from ROMFS (saves ~29 KB of flash), the USART6 pin definitions that were only present as the IOMCU UART, and the USART6 DMA_NOSHARE/DMA_PRIORITY entries that were carried over from fmuv3.
~ -29kB
Merged!
UTC0818
master ← christianpetri:compass-cal-early-abort
opened 03:02AM - 13 Apr 26 UTC
### Summary
Add early field-magnitude sanity check during compass calibration… to abort immediately when magnetic field is wildly out of range.
### 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
Built and tested on SITL (plane + copter) and MatekF405-TE with external QMC5883L:
- With neodymium magnet near compass (~4800 mGauss): calibration aborts in ~1 sec with `Mag(0) field too high 4778 max 950`
- Without magnet (~425 mGauss): calibration completes normally
- Recovery after abort: subsequent calibration succeeds
### Description
After collecting 10 samples (~1 sec into calibration), check the average field magnitude. If it exceeds 2× `FIELD_RADIUS_MAX` (1900 mGauss) or is below ½ `FIELD_RADIUS_MIN` (75 mGauss), abort immediately with `BAD_RADIUS` status and a GCS message.
Without this, the calibrator collects all ~300 samples over 3+ minutes before `fit_acceptable()` rejects the result. Users get no feedback about why calibration fails.
No new parameters. No behavior change for normal calibrations. Uses existing `BAD_RADIUS` status and `FIELD_RADIUS_MIN`/`FIELD_RADIUS_MAX` defines.
Related discussion: https://discuss.ardupilot.org/t/proposal-early-abort-compass-calibration-when-magnetic-field-is-extreme/143374
This contribution was AI-assisted (code review and PR preparation).
A : This likely needs an autotest to ensure that only one compass will fail, while the rest of the compasses can continue calibrating.
What will happen if there’s a hatch magnet nearby now?
Peter : _OFFS_MAX is there to help with this.
UTC0824
Discussion on the beta3.
UTC0837
master ← cclauss:tools-astyle-cleanliness
opened 09:11AM - 03 Apr 26 UTC
### Summary
Tools: Print the [Artistic Style](https://astyle.sourceforge.net)… version in CI because the local version of `astyle` matters when running:
% `CI_BUILD_TARGET=astyle-cleanliness Tools/scripts/build_ci.sh`
as is done in CI job`test scripts / build (astyle-cleanliness)`.
Printing the `astyle` version helps us understand changes proposed in future pull requests.
macOS: `brew install astyle` delivers Artistic Style Version 3.6.14.
Windows users might get v3.6.2
* https://community.chocolatey.org/packages/astyle
Linux users will get different versions based on their distro.
ubuntu:24.04: Artistic Style Version 3.1
ubuntu:26.04: Artistic Style Version 3.6.12
Related to:
* #32566
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [x] Non-functional change
- [x] No-binary change
- [x] Infrastructure change (e.g., unit tests, helper scripts)
- [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
Modify `Tools/scripts/build_ci.sh` so that `astyle-cleanliness` raises an error in CI if any files need formatting.
Modify `Tools/scripts/run_astyle.py`:
* Change its description because `astyle` is a C and C++ formatter, not a Python formatter.
* Print the `astyle` version but suppress all exceptions.
* Use Python f-strings, which are shorter, faster, and more readable.
The `astyle` version is important to print because Ubuntu 24.04 LTS defaults to Artistic Style 3.1 (January 2018) while this month's Ubuntu 26.04 LTS defaults to Artistic Style 3.6 (August 2024).
* Artistic Style version info: https://astyle.sourceforge.net/news.html
### How was this tested?
1. % `code ArduCopter/AP_ExternalControl_Copter.cpp libraries/AP_DDS/AP_DDS_ExternalControl.cpp`
2. Make similar leading and trailing whitespace changes to both files.
3. % `CI_BUILD_TARGET=astyle-cleanliness Tools/scripts/build_ci.sh`
---
Inside the Docker container, run the command:
```
# cd app && \
apt update && \
DEBIAN_FRONTEND=noninteractive apt install --yes astyle python3 && \
astyle --version && \
Tools/scripts/run_astyle.py --dry-run ; echo $?
```
% `docker run -it -v "$(pwd)":/app ubuntu:24.04`
```
Artistic Style Version 3.1
0
```
% `docker run -it -v "$(pwd)":/app ubuntu:26.04`
```
Artistic Style Version 3.6.12
****** Files needing formatting found.
[ ... ]
1
```
@Ryanf55
Merged!
UTC0839
master ← peterbarker:pr/COMMAND_INT.command_opaque_id
opened 10:23PM - 01 Apr 26 UTC
.... to be filled in from the value passed in via COMMAND_LONG or COMMAND_INT
…
The concept being a GCS can remember commands and always match the command to a command_ack which it has received.
Based on comment in https://github.com/mavlink/mavlink/pull/2452
P : Idempotency is optional, if the opaque ID is ~=0.
There is some (RAM) memory overhead, about 2.5kB.
One linked list for all links.Pull requests · ArduPilot/ardupilot · GitHub
This allows you to send the same command multiple times, assured that it will be actually executed only once.
A : We’ll need a mutex for this, because we run command ints from Lua.
I support this in principle.