Attendees (max) : 9
UTC0702
master ← peterbarker:pr/AP_AHRS-hagl-in-results
opened 05:40AM - 26 May 26 UTC
### Summary
Moves HAGL into the backend results object rather than calling a … virtual method to get result
### 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
```
Board AP_Periph antennatracker blimp bootloader copter heli iofirmware plane rover sub
CubeOrange-periph-heavy * *
Durandal -40 0 * -48 -32 -32 -40 -40
Hitec-Airspeed * *
KakuteH7-bdshot -32 -24 * 184 -24 144 -32 -16
MatekF405 -8 -16 * 16 -24 -16 0 0
MatekH7A3 -24 -32 * -40 -40 -32 16 -56
Pixhawk1-1M-bdshot -32 -32 -152 -136 -72 -16 -24
SITL_x86_64_linux_gnu -280 -272 -280 -280 -272 -272 -272
YJUAV_A6SE -48 -40 * -120 0 -184 -48 -16
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
mindpx-v2 -32 72 * -32 -8 -368 -16 -16
revo-mini -48 -48 * -32 -40 -16 -56 -128
skyviper-v2450 16
speedybeef4 -32 -32 * 24 56 80 -64 -56
```
### Description
Move HAGL into the backend results structure next to other position estimates.
Adds comments to start sectioning the results object better in some backends.
Peter : get_hagl() is used only for MAVLink reporting. Not for navigation.
This HAGL will be stored in the AHRS results object.
Andrew : Approved!
UTC0706
master ← peterbarker:pr/get-location-use-estimates
opened 04:08AM - 26 May 26 UTC
### Summary
Uses new infrastructure in place of a switch statement on active … EKF type to get a locaiton
### 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
```
Board AP_Periph antennatracker blimp bootloader copter heli iofirmware plane rover sub
CubeOrange-periph-heavy * *
Durandal -8 -16 * -16 -8 -16 -16 -16
Hitec-Airspeed * *
KakuteH7-bdshot -16 -8 * -16 -16 -16 -16 -16
MatekF405 -16 -16 * -8 -16 -16 -16 -16
MatekH7A3 -16 -16 * -16 -8 -8 -8 -16
Pixhawk1-1M-bdshot -8 -16 -8 -8 -16 -8 -8
SITL_x86_64_linux_gnu 0 0 0 0 0 0 0
YJUAV_A6SE -32 -32 * -32 -32 -32 -32 -32
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
mindpx-v2 -16 -16 * -16 -16 -8 -8 -16
revo-mini -16 -8 * -8 -16 -16 -16 -16
skyviper-v2450 -8
speedybeef4 -8 -8 * -16 -16 -16 -8 -8
```
### Description
Fairly major change in behaviour when using ExternalAHRS for your primary source in that if the external source fails then we will now start to fall back to DCM (and into the future hopefully a configured secondary estimator). Only applicable on vehicles that `always_use_EKF()` returns false (e.g. Plane); Copter will still not fall back to DCM even when using an external estimator.
P : This will return DCM is get location is not available (and DCM is active).A : Merged!
UTC0708
master ← dakejahl:remove-lis2mdl-driver
opened 12:31AM - 21 May 26 UTC
## Summary
LIS2MDL and IIS2MDC are the same ST silicon — identical WHO_AM_I, re… gister map, I2C address and sensitivity. They differ only by part-number grade (consumer vs industrial). Remove the separate LIS2MDL driver entirely and switch boards that referenced it to IIS2MDC.
- Delete `AP_Compass_LIS2MDL.h` / `.cpp`
- Remove `AP_COMPASS_LIS2MDL_ENABLED`, `AP_COMPASS_LIS2MDL_EXTERNAL_BUS_PROBING_ENABLED`, `DEVTYPE_LIS2MDL`, `DRIVER_LIS2MDL`, and the LIS2MDL auto-probe block
- AIRBRAINH743: `COMPASS LIS2MDL` → `COMPASS IIS2MDC`
- Clean up LIS2MDL references in `decode_devid.py`, `build_options.py`, PrincipIoTH7Pi hwdef comment, and AIRBRAINH743 README
## Testing
Builds cleanly. Needs flight test on an AIRBRAINH743 or equivalent board with this magnetometer.
P : The two drivers are identical.
Jake Dahl at first would delete the old driver. But lots of bugs were discovered in the new one, which was also not tested on a stable version.
So we’ll keep the old one and delete the new.
Andy : Can we make both names work in the hwdef?P : Why? There is only one instance and I changed it manually.Andy : In order to let people know that we still support the device with the other name.
I also think the external probing will change behaviour now.
A : What we could do is change Python code in waf and declare aliases.
UTC0719
master ← andyp1per:pr-dr-fix
opened 08:26AM - 19 May 26 UTC
### Summary
Fixes the plane dead reckoning tests, by not considering takeoff … as a potential time to not fuse.
### 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
This is a simpler fix than https://github.com/ArduPilot/ardupilot/pull/32986 - it fixes the dead reckoning tests in an obvious way. It does mean that zero velocity fusion occurs when armed and on the ground, but t hat was true before anyway
A : Looks good to me.P : A comment is wrong and needs fixing.
Merged!
UTC0725
master ← andyp1per:vtx-actual-power
opened 04:51PM - 29 Apr 26 UTC
### Summary
Three independent issues affecting Tramp VTX users, found while deb… ugging a 2500mW analog setup:
1. The OSD power panel always showed the configured request, never the power the VTX reports it is actually transmitting. Tramp's 'v' reply carries both, but only the configured value was plumbed through AP_VideoTX.
2. update_power() rejected any mW not in the SmartAudio-derived power table. Tramp carries arbitrary 16-bit mW values, so common settings like 2500mW were silently dropped, with no protocol traffic and no GCS feedback.
3. A VTX that silently refuses a value drove an unbounded retry loop, because AP_Tramp::update() re-armed retry_count on every parameter mismatch.
### Classification & Testing
- [x] Checked by a human programmer
- [x] Tested manually
- [x] Tested on hardware
MicoAir 743 v2 with a 2500mW analog Tramp VTX:
- VTX_POWER 2500 was previously silent (update_power() returned false, AP_Tramp sent nothing). Now the 'P' 2500 command goes out and the VTX echoes 2500 back.
- VTX_POWER 400 (advertised as max but rejected by this VTX): retries stop after 20, one "VTX: rejected power 400mW" warning is sent, then quiet until the value changes.
- The OSD VTX_PWR panel now shows the VTX's self-reported actual power.
- SmartAudio is unchanged: the table check is retained for non-Tramp providers.
### Description
AP_VideoTX gains set/get_actual_power_mw() (-1 = provider doesn't report, 0 is valid for pit mode). AP_Tramp writes both the configured power (drives the state machine) and the actual power (display only); the OSD reads actual when available and falls back to configured.
update_power() accepts off-table mW when a Tramp provider is active, and set_power_mw() populates the custom power slot for those values so the equality short-circuit works on later calls.
update() re-arms retry_count only when the configured value changed since the last attempt, matching Betaflight's vtxTrampSetPowerByIndex(). rf_power_max from the Tramp 'r' reply is deliberately not used to gate requests: Betaflight tried that in 6560f80da and reverted it because the value is unreliable across firmware variants.
Andy : VTXs say they have 4 states of power, but the last, higher one is not available.
Now we’ll try a few times to set it and we’ll give up.
P : Approved and MergeOnCIPass!
UTC0736
master ← ES-Alexander:ci-add-vehicle-labels
opened 02:28PM - 27 Apr 26 UTC
### Summary
Automatically adds vehicle tags when relevant files have been cha… nged.
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [x] Non-functional change
- [x] No-binary change
- [x] Infrastructure change (e.g. unit tests, helper scripts)
- [ ] Automated test(s) verify changes (e.g. unit test, autotest)
- [x] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
### Description
There are likely some files I've missed for the niche/specific checks, but this is at least a start to automatically applying relevant vehicle labels when a PR changes corresponding code files.
Checks for core vehicle code changes, as well as SITL and autotest changes.
P : Approved and MergeOnCIPass!
UTC0738
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.
P : Some improvements were skipped in the autotests.Randy : Please update the display names according to suggestions.
UTC0745
master ← andyp1per:pr-ground-effect
opened 02:25PM - 17 Mar 26 UTC
### Summary
Adds Copter parameters to delay release of baro ground-effect compe… nsation and to gate touchdown ground effect on altitude, plus a SITL parameter that injects a simulated baro error so the autotest has something to compensate against. Defaults preserve the pre-PR behaviour (0.5m release, no minimum hold).
### Classification & Testing
- [x] Checked by a human programmer
- [x] Automated test(s) verify changes (e.g. unit test, autotest)
- [x] Tested manually, description below (e.g. SITL)
### Description
On airframes with strong baro ground effect, the EKF altitude estimate can cross the hard-coded 0.5m exit threshold within a few hundred ms of liftoff and release compensation before the vehicle is clear of the disturbance.
New parameters:
- `TKOFF_GNDEFF_ALT` (Copter, default 0.5m): altitude above which takeoff ground-effect compensation is cleared. Touchdown ground-effect compensation is only signalled to the EKF when the vehicle is below this altitude. Set to zero to disable the touchdown altitude gate.
- `TKOFF_GNDEFF_TMO` (Copter, default 0s): minimum hold time after liftoff before the altitude check is allowed to release. The 5s hard timeout still applies unconditionally.
- `SIM_BARO_GEFF` (SITL, default 0): amplitude in metres of a simulated rotor-downwash baro error. Decays linearly to zero at 2m AGL and is gated on motor throttle, so a disarmed vehicle still reads truth.
An earlier revision also re-set `takeoff_expected` on descent below the threshold. That overloaded a flag whose contract is "we are about to leave the ground"; the EKF's landing-side response lives on `touchdown_expected`, which is now what `TKOFF_GNDEFF_ALT` gates. Tightening the EKF's response to `touchdown_expected` is left as a follow-up.
Autotest `TakeoffGroundEffectAlt` covers three configurations (large altitude, small altitude, small altitude with timeout) and asserts comparative durations so it survives SITL jitter.
P : We probably want to disentangle takeoff expected and ground effect expected flags.R : What’s the benefit of that?P : We use takeoff expected for other, unrelated things. Plane uses it too, so placing it under Copter won’t work.R : How about a Q_ prefix?P : Having them in Baro would make them common. But Q_ would also work.R : Yes, we probably need a small class in AP_Vehicle, so that it can be commonly referred to.P : We could declare them in AHRS, since that’s what it’s used for.R : I don’t want to pass vehicle parameters down to AHRS, it should lie on a layer that is below the vehicle, independent of it.A : We could do away with that timer too? We can be flying indefinitely in ground effect.R : No, we don’t fuse barometer when we’re in ground effect. So at some point we’ll need to fuse an altitude source.
Regarding the parameters, yes, let’s move them in an AP_Vehicle class, along with some functionality. so that it can be used by Plane too.
Andy : Sorry, I don’t have the time to test plane.
UTC0839
Andy : We need to force-push the ChibiOS branch.A : Done!
It would be nice if you tagged the upstream ChibiOS base, so that we don’t go searching for our own commits to rebase next time.
UTC0844
https://github.com/ArduPilot/mavlink/pull/2500
A : We need to test it a little.