Attendees (unique) : 9
UTC0700
master ← ZeroOne-Aero:pr-FPGA_CODE-260302
opened 06:50AM - 03 Mar 26 UTC
This is the FPGA code for the SCH16T sensor, implementing FIFO functionality thr… ough the FPGA.
Please refer to the readme for detailed usage instructions.
Peter : The FPGA code comes with a license that requires a license to build the code.Andrew : That’s common in FPGAs.
We’ll probably never build it an offer it built ourselves, but it’s nice to have it around.
UTC0705
master ← peterbarker:pr/deprecation-warning-VERSION_REQEST_and_REQUEST_AUTOPILOT_CAPA
opened 01:45AM - 29 Apr 26 UTC
### Summary
Stops compiling support for these two messages in by default, wit… h an eye to removing them in 4.9
### 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
Fired up MissionPlanner against this and there weren't any issues.
Likewise QGC
### Description
MissionPlanner currently sends in both; if we add a warning then many users will start to get messages.
We can now serve individual message streams upon request from the GCS.
Good to merge after tests pass!
UTC0711
master ← rmackay9:ekf3-log-baro-offset
opened 01:38AM - 29 Apr 26 UTC
### Summary
This adds logging of the EKF's baroHgtOffset variable which essen… tially resolves issue https://github.com/ArduPilot/ardupilot/issues/32612 because the EKF is actually acting as it should, it is just difficult for users reviewing the log to understand why the EKF's altitude doesn't exactly match the barometer.
This variable is updated by [NavEKF3_core::calcFiltBaroOffset](https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3_Measurements.cpp#L806) whenever the barometer is **not** the active altitude source ([see code here](https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3_PosVelFusion.cpp#L1379)). This ensures that there is no jump when falling back to baro from another altitude source (e.g. rangefinder or GPS). This fall back may occur if the user actively [changes the EKF source](https://ardupilot.org/copter/docs/common-ekf-sources.html) or if the other source becomes unavailable for some reason (e.g. GPS failure, rangefinder out-of-range).
The alternative behaviour would be for the EKF's altitude estimate to be reset to the barometer's altitude during fall back but I suspect this could cause the vehicle to dramatically climb or descend especially when falling back from GPS to baro during long distance flights.
For the moment I think simply logging the offset removes confusion.
Below is a screen shot from MP's log review tool showing Copter's CTUN's message's Alt (aka EKF altitude estimate), BAlt (barometer altitude) and the new XKF5.B message (barometer offset).
<img width="2053" height="795" alt="image" src="https://github.com/user-attachments/assets/9ac5fec9-eb97-4bc8-8e9e-232d8e8018f3" />
### 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
- [x] Logs available on request
Randy : I need to shorten another field to save characters for the new field.A : VOT (Vertical Offset for Terrain) would be fine too. We’ll leave it up to you.R : I’ll probably do BOF.A : Good to merge after this change.
UTC0718
master ← peterbarker:pr/remove-fencepoint-protocols
opened 05:31AM - 28 Apr 26 UTC
### Summary
Removes support entirely for these features
### 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)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
```
Board AP_Periph antennatracker blimp bootloader copter heli iofirmware plane rover sub
CubeOrange-periph-heavy * *
Durandal * * * * * * * *
Hitec-Airspeed * *
KakuteH7-bdshot * * * * * * * *
MatekF405 * * * * * * * *
MatekH7A3 * * * * * * * *
Pixhawk1-1M-bdshot * * * * * * *
SITL_x86_64_linux_gnu -4496 -4488 -9096 -9096 -4912 -9096 -5000
YJUAV_A6SE 0 0 * 0 0 0 0 0
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
mindpx-v2 * * * * * * * *
revo-mini * * * * * * * *
skyviper-v2450 *
speedybeef4 * * * * * * * *
```
Had a bit of a deep-dive with the YJUAV_A6SE delta. We're apparently leaving debug symbols in external sections (split-sections vs objcopy). I have patches for that. But the compiler also doesn't seem to completely elide the `handle_msg` method on YJUAV_A6SE where it does on MatekF405. There's no symbol, but leaves byte vestiges.
### Description
Removes these old protocols which we've had replacements for for years. Removing according to schedule.
P : Removing the old Rally and Fence protocols from building by default.
We had scheduled this for 4.7.
If we remove them from ardupilot.xml too, AP will not forward them when it receives them.
MAVProxy might also be using it for older systems.
Merge on CI pass.
UTC0723
master ← Georacer:pr/surftrack_threshold
opened 09:49PM - 26 Apr 26 UTC
### Summary
This PR fixes the buggy behaviour of AP_SurfaceDistance (Surface … Tracking) when flying with tethers and over vertical walls.
It introduces `SURFDSTD/U_` parameters to do so.
### 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
There are new autotests available. You can run them to observe the behaviour change before/after the fix.
### Description
#### Problem description
The surface tracking behaviour would be buggy in the following corner cases:
1. You fly over a building that is >2m high. The rangefinder readings usually do a step-change that is detected as a glitch. As a result the surface offset is reset and the vehicle does not climb to match the height of the building.
You then fly off the building, the rangefinder beam scanning its vertical wall. There is no step change and no glitch is detected. as a result, the vehicle descends even more and it's not in the initial altitude anymore.
Note: the 2m threshold is currently hardcoded. The glitch will cause a reset after 3 consecutive samples that exceed the threshold.
2. You fly with a tethered vehicle. Depending on how the tether flops around, abruptly getting into the FOV of the rangefinder and causing step changes in the measurements, it might:
- Cause the vehicle to temporarily ascend or descend, if the step change is below the 2m step threshold.
- Cause the vehicle to permanently ascend or descend, if the step change is above the 2m step threshold, through the same mechanism explained above.
I have had personal reports of both of these incidents from clients and partners.
You can see how these bugs play out in the 2nd commit, where autotests have been introduced.
#### Fix
The proposed solution is to add a glitch threshold parameter `GLDST` and a number of samples to trigger a reset parameter `GLSAM`. Setting either to 0 disables the respective feature.
Each is hosted in duplicate in the groups `SURFDSTU_` and `SURFDSTD_` groups, for the up-facing and down-facing rangefinder.
To address the building use-case, you increase `GLDST` to be higher than the highest building you plan to fly over, so that the step change will not be considered a glitch.
To address the tether use-case, you disable the `GLSAM` parameter, so that it never allows the reference altitude reset. It will ignore measurement step changes, but will not reset altitude because of them.
#### Testing
I have created an initial autotest that highlights the problem and intentionally fails. Then it is amended with the new parameters and passes.
#### Unknowns
I notice that not just `SURF[0].D` freezes and not updates when glitching, but also `RFND.Dist` (Arrow 2). I wasn't expecting that and I don't know why this happens.
Also, `XKF5.HAGL` seems to temporarily go bad and then recover (example in arrow 1). I don't know if this is expected or not, nor if this has other bad consequences.
<img width="689" height="305" alt="image" src="https://github.com/user-attachments/assets/6413e1f0-c2bc-49c6-a733-275f607706ff" />
---
I wanted to have shared parameters for both the up and down rangefinder, but I couldn't figure out how to do it without assigning them on top-level Copter and then passing their reference inside the `AP_SurfaceDistance` library, which seems wasteful.
My PR on surface distance.
???
UTC0748
master ← andyp1per:pr-ekf3-resetheightdatum-flush
opened 08:39PM - 13 Apr 26 UTC
## Summary
`NavEKF3_core::resetHeightDatum()` recalibrates the baro and zeroes … `position.z`, but on master it leaves three pieces of stale state behind: the `storedBaro` observation buffer, `velocity.z`, and the output-observer chain. After the reset those stale values are still fused as delayed observations, producing a ~0.3–0.5 m altitude transient for several hundred milliseconds. The same mechanism produced the observed −0.44 m at arming on a real copter (log15, small-fast-drone v4.6 build).
This PR clears the remaining state so the reset is clean, and adds a Plane autotest that catches the bug.
## The buggy state `resetHeightDatum` was leaving behind
1. **`storedBaro` observation buffer** — ~200 ms of baro samples taken *before* `update_calibration()` zeroed the baro. After the reset they are popped and fused as if current, pulling `state.position.z` away from zero.
2. **`stateStruct.velocity.z`** — not reset, carries whatever small value accumulated from IMU integration while disarmed.
3. **Output observer chain** (`storedOutput[].position.z`, `outputDataNew/Delayed.position.z/velocity.z`, `vertCompFiltState.vel`) — the complementary filter between delayed EKF state and reported output. Without resetting, reported altitude briefly continues at the pre-reset value before catching up.
## Fix
Cherry-picked from #32400, authored by @priseborough (commit `f2a8bcda1a`):
- `storedBaro.reset()` clears the observation buffer
- `stateStruct.velocity.z = 0` zeros the vertical velocity state
- Zero all entries of `storedOutput[]`, `outputDataNew/Delayed`, `vertCompFiltState.vel`
## Test
`EK3HeightDatumResetFlushesBuffers` (Plane). Plane's existing `update_home()` is the only on-master trigger for `resetHeightDatum()` we can drive on demand; the test temporarily suspends the periodic reset (`HOME_RESET_ALT=-1`), injects 4 s of `SIM_BARO_DRIFT=0.5` (~2 m offset in the buffer), then re-enables the reset and watches the next `update_home` cycle in the dataflash log.
| | Peak \|XKF1.PD\| in 2 s post-reset window |
|---|---|
| Without this fix | 0.372 m |
| With this fix | < 0.05 m |
The 0.1 m assertion sits comfortably in the gap.
## Stacking
This PR is the base for #32768 (arm-time drift reset). #32768 needs this fix because the arm-time `resetHeightDatum()` would otherwise produce the same post-arm transient.
## Ancestry
- Paul's EKF fix: cherry-pick of `f2a8bcda1a` from `pr-ekf3-height-datum` branch (PR #32400). Authorship preserved.
- Plane test: new work here.
## Test plan
- [x] `EK3HeightDatumResetFlushesBuffers` passes with peak excursion < 0.05 m
- [x] `EK3HeightDatumResetFlushesBuffers` fails with peak excursion = 0.372 m when Paul's fix reverted
- [x] No regression on `FarOrigin`, `HomeAltResetTest`, `AltEstimation`, `EKFSource`, `Clamp`
Andy : I discovered that when you don’t have GPS and you also don’t fuse in Barometer often, then the EKF has no reference to calculate the accelerometer Z-bias.P : Are those delays in autotest necessary?Andy : I’m accumulating data and looking at them in the .bin log.
Approved!
UTC0759
master ← ZeroOne-Aero:pr-FPGA_CODE-260302
opened 06:50AM - 03 Mar 26 UTC
This is the FPGA code for the SCH16T sensor, implementing FIFO functionality thr… ough the FPGA.
Please refer to the readme for detailed usage instructions.
A : Another idea, how about we put the FPGA code into the Datasheets or Schematics AP repo? It will be even more harmless, when it comes to licensing issues.P : Okay, let’s put it in the Schematics repo then.
Merged!
UTC0805
master ← ZeroOne-Aero:pr-Fifo_SCH16T-251120
opened 03:22AM - 20 Nov 25 UTC
This is an improved Murata SCH16T-K10 IMU, which integrates FIFO functionality t… hrough an FPGA and reads sensor data via callback
Buzz : Most of these IMUs I find for around 200-300USD.A : Claude says that the gyro scaling is wrong. The flight log link is stale, let’s have the log anew, just to check.
UTC0814
master ← bjubes:mag-cal-reboot-check
opened 04:14AM - 19 Feb 26 UTC
Implements #31948
Patches MAV_CMD_DO_START_MAG_CAL param5 (autoreboot) so th… at setting it only causes a reboot when the calibration succeeds. Previously it would reboot upon any final state of calibration such as failure or user cancellation.
I've also removed the `_auto_reboot()` getter since the variable it protects is only used within the class. This matches how the autosave param is already handled.
Because compass cal requires moving the autopilot, I'm unable to test in SITL. I'll add a comment when I'm able to confirm on a real autopilot.
A : Approved!
MergeOnCIPass
UTC0817
master ← Georacer:pr/loweheiser_disable_autostart
opened 04:17PM - 22 Oct 25 UTC
# Summary
This PR removes support for auto-starting the Loweheiser generator.…
Now the user has to assign a starter switch channel and start the engine during IDLE state.
# Details
The reason is that, according to the manufacturer and a commercial user, it's not 100% reliable to use the starter (which is optional, as an alternative to a ripcord) so it's preferable for the user to trigger it intentionally.
Note: This PR has been re-written and re-coded from scratch.
This is a follow-up to https://github.com/ArduPilot/ardupilot/pull/29587.
# Known issues
After this PR, the engine won't auto-start any longer if the engine stalls mid-flight.
Also the user can't re-start it in-flight either, as starting is allowed only in IDLE state, and state changes are not allowed while armed.
George : I talked with Loweheiser and they don’t want any automatic actions upon receiving NaNs from the EFI.
I’m still waiting for a successful test from them.
UTC0822
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
Want to try this on a large variety of different MCUs
- [ ] L431
- [ ] G4xx (Hitec-Airspeed?)
- [ ] H757
- [ ] H743 (Boots!)
- [ ] F427
- [ ] F1xx
- [ ] F3xx
- [ ] F405 / F407
A : Let’s try to test one of each processor family. We can split the effort between me and Andy.
UTC0830
master ← peterbarker:pr/from-mav-mav-master
opened 11:37PM - 27 Apr 26 UTC
Patches brought in from mavlink/mavlink/master
When ArduPilot uses this as it… s reference commit it is a no-compiler-output change:
```
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 *
```
Approved!
UTC0834
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 : I would still like to keep the specialized name on the method. Because Copter is the only vehicle that would care about resetting the EKF, Plane has DCM to fall back to.P : Okay, then reset_configured_backend() is still a good naming option. Even if you are flying on DCM it will reset the EKF.Andy : Okay, I can do that.Randy : It should also not be in by defeault, unless it’s less than 200 bytes.P : And not be able to trigger when armed.Andy : I have even reset the gyro and EKF in-flight. In hover it’s fine. At any angle, that angle is going to be wound up as bias and stay there forever.
How about we do this enabled by default on Copters only?
P : No, that’s not possible with our current framework.
UTC0856
master ← andyp1per:pr-crsf-out-refactor
opened 06:15PM - 14 Nov 25 UTC
This allows CRSF to act in a similar way to SBUS Out, but bi-directional, full-d… uplex at 2Mbaud.
The primary use-case is dual flight controller setups where one flight controller is the "rate controller" (i.e. operating at speed in real-time) and the other flight controller is the "EKF / position controller" (i.e. can operate with fewer real-time constraints). It allows both of these controllers to be the same software stack or different stacks. So I have proved that an ardupilot<->ardupilot setup works and an ardupilot<->betaflight setup works.
Use cases:
- clean multi-core implementations (e.g. one core running rate controller the other running the EKF controller)
- heterogenous CPU implementations, e.g. rate controller on M7 (better realtime but less compute/memory/flash) EKF controller on A9 (worse realtime but better compute/memory/flash)
- heterogenous FC implementations where ArduPilot is not supported on the full stack (e.g. RP3250B for betaflight, PiZero2W for ArduPilot)
- Testing - provides full end-to-end testing of the CRSF stack which we did not have before.
This can be used to drive one flight controller from another flight controller using existing rate output support.
The new protocol is 51 and so can be used by setting:
```SERIALx_PROTOCOL = 51```
This PR has been tested on Raspberry Pi's new drone, codename "Wolverine" and the work has been kindly sponsored by Raspberry Pi.
The follow-up PR relies on https://github.com/betaflight/betaflight/pull/14870 which has now been merged
P : I have a question, why go through the servo channels library? I don’t think this is the right place for this feature to exist.Andy : I’m doing a similar thing to what we have done in the past with big helicopters. Use the servo outputs to write them to another controller.P : You have the servo channel targets before they go in the mixer, you don’t need to intercept them from within servo channels. You could do that in the mixer, surely.
Why are we using BetaFlight as a rate controller again?
Andy : In order to be able to run AP on an RPi, e.g. a Zero. Then you delegate the rate control to another controller.A : It could also help as a fallback mechanism if AP crashes.P : I see downsides too, namely the flash cost (even when it’s defined out), as well as the more complex restructuring.Andy : I also lose the ability to mix and match input/output channels freely.A : Going through Motors would also make it impossible to control a Plane in this configuration. Not that it would necesarilly be a good idea.
(George’s internet dropped)
A : I don’t mind going through the servos channel. And it would probably be a quick patch to go over the Motors singleton.P : Are you supposed to run the complete Betaflight configurator on the rate controller?Andy : Yes, I’ve done that, even on passthrough.
By the way, the way to do it via CRSF is that it’s understood by Betaflight, it’s flexible and fast.
P : It would be nice if the rate output API woulde be fleshed out to cover planes and rovers.A : Then we could support vehicles that come with nice rate control out of the box. Then you add in AP on top, without the need to retune rate control.P : Okay, I’ll think about it a little more.