Attendees (unique) : 11
UTC0700
master ← zebulon-86:pr/lsm6dsv-driver-support
opened 05:51AM - 02 Jun 26 UTC
### 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.
Peter : We had a few people ask for a driver for this IMU. The ZeroOne immediately came up with one.
There seems to be inconsistent number of identifiers vs new sensors.
Oh, they have the same identifier.
Andrew : There’s a variant bit, which seems to be used correctly in this driver.
UTC0716
master ← peterbarker:pr/AP_AHRS-using_gps
opened 05:07AM - 02 Jun 26 UTC
### Summary
Renames methods to be more representative of what they return and… move the storage into the estimates object.
### 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 48 48 * -24 -24 48 48 48
Hitec-Airspeed * *
KakuteH7-bdshot 48 48 * -24 -24 48 48 48
MatekF405 48 48 * -24 -24 48 48 48
MatekH7A3 48 48 * -24 -24 48 48 48
Pixhawk1-1M-bdshot 48 48 -24 -24 48 48 48
SITL_x86_64_linux_gnu 4248 152 -48 -56 152 152 152
YJUAV_A6SE 48 48 * -24 -24 64 48 64
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
mindpx-v2 48 48 * -24 -24 48 48 48
revo-mini 48 48 * -24 -24 48 48 48
skyviper-v2450 -24
speedybeef4 48 48 * -24 -24 48 48 48
```
### Description
Contrary to the old method names, these return whether the backend would use GPS data if it was good to use, *not* whether it is currently using the data. There are identically named variables floating around which contain the latter information!
@tpwrules has expressed skepticism at the rather chunky comments I'm adding in each `get_results` method. I'm happy to pare that stuff down.
@andyp1per I'm removing comments in here (as a side-effect of the changes) which are in opposition to the code they are annotating. They state "configure EKF type" where the code is actually using the active EKF type. At the moment I think that's probably OK, but if the intent was to look at the preferred estimator - rather than the active estimator - then there's a bit of work to do. If we do want to fix that we'd best do it *before* this PR goes in as this one will definitely obfuscate the history. This probably makes zero difference on a Copter, but on a Plane/Rover we might use DCM estimates at boot.
A : There seems to be a change from using_gps() to “requiring GPS”.
This is a change of behaviour, but probably a correct change of behaviour.
P : No, the original method is a misnomer. There’s no behaviour change here.R : Do we really need to differentiate between configuration and actual usage?P : Yes, there are cases where the difference is important.Andy : In the arming checks, for example.
UTC0730
master ← peterbarker:pr/AP_AHRS-fix-_getCorrectedDeltaVelocityNED
opened 02:08AM - 02 Jun 26 UTC
### Summary
Corrects rotation of delta-velocity-ned for non-EKF backends
#… ## 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 -48 -64 * -88 -48 104 0 56
Hitec-Airspeed * *
KakuteH7-bdshot -64 -72 * 360 -160 -72 -56 -136
MatekF405 -72 -80 * -72 -64 -96 -96 -48
MatekH7A3 -64 -56 * -48 -56 -56 -48 -64
Pixhawk1-1M-bdshot -64 -56 -56 -56 -48 -48 -56
SITL_x86_64_linux_gnu -80 -80 -80 -80 -80 -88 -88
YJUAV_A6SE -64 -64 * -56 -56 -56 -56 -64
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
mindpx-v2 -56 -40 * -136 -40 8 -32 -40
revo-mini -64 -64 * -64 -64 -64 -64 -64
skyviper-v2450 -16
speedybeef4 -64 -64 * -56 -72 -56 -72 -64
```
### Description
These results are supposed to be NED - the ins results are autopilot body sensor frame.
It's also a bit of a simplification, one might say!
A : The only usage of the changed variable seems to be in Precision Landing.
What happens when the variable evaluates to false and the PrecLand method returns early? This seems to be unwanted.
P : The bug was that the corrected velocities were reported in body frame, not in the NED frame.
This would affect the corner case of SITL running something other than EKF.
UTC0740
master ← Georacer:feature/custom_plane_controller
opened 03:02PM - 29 May 26 UTC
### Summary
This PR adds support for custom Plane controllers, as `AC_CustomC… ontrol` [does for Copter](https://ardupilot.org/dev/docs/copter-adding-custom-controller.html).
### Description
A new library `AP_CustomControl` has been created, which roughly operates the same as the existing Copter counterpart.
Things that are the same:
- The overall flag is `AP_CUSTOMCONTROL_ENABLED`. The library is not part of the features list. It is meant to be explicitly, locally compiled in. SITL will compile it by default.
- Multiple custom controllers can be compiled-in and selected via `CC_TYPE`.
- An AUX switch enables or disables the controller (109).
- A basic PID example is given, which can fly a plane successfully.
Things that are different:
- The Copter custom controller is designed to return a strict control API, in the form of `Vector3f` for roll/pitch/yaw pre-mixer inputs. However this is not very useful for Plane. See below for the new API.
- Copter uses `CC_AXIS` to quickly enable/disable custom roll/pitch/yaw controllers. Since AP_CustomController now recommends unconstrained access to output functions and servos alike, The parameter has been replaced by `CC_MASK`. This is meant to be used by the developer to fence whatever function within the custom controller he pleases.
#### Recommended API
The developer has complete freedom to shape the custom controller code to his liking.
However, the following methods of `AP_CustomControl` are the recommended way to interact with the outputs:
```c++
// Write a scaled value to all channels with a function.
void set_output_scaled(SRV_Channel::Function function, float value);
// Write a pwm value to all channels with a function. Not min/max constrained. servos.cpp may overwrite it.
void set_output_pwm(SRV_Channel::Function function, uint16_t value);
// Write pwm values on a channel. Not min/max constrained. servos.cpp may overwrite it.
void set_output_pwm_chan(uint8_t chan, uint16_t value);
// Override pwm values on a channel for one loop. servos.cpp will not overwrite it.
void set_output_pwm_chan_override(uint8_t chan, uint16_t value);
```
These will reach into `SRV_Channels` and write the passed values.
This also means that **any** servo channel can be written to, even unconfigured ones. This is very useful for experimental control allocation schemes.
Typical input channels are also given quick-access and updated on every loop:
```c++
void AP_CustomControl_Backend::update_rcin_channels() {
channel_roll = &rc().get_roll_channel();
channel_pitch = &rc().get_pitch_channel();
channel_throttle = &rc().get_throttle_channel();
channel_rudder = &rc().get_yaw_channel();
channel_flap = rc().find_channel_for_option(RC_Channel::AUX_FUNC::FLAP);
channel_airbrake = rc().find_channel_for_option(RC_Channel::AUX_FUNC::AIRBRAKE);
}
```
The euler angle targets are exposed to
```c++
float get_roll_target_deg() { return _frontend.roll_target_deg; }
float get_nav_pitch_target_deg() { return _frontend.pitch_target_deg; }
float get_pitch_target_deg() { return _frontend.pitch_target_deg + _frontend.pitch_trim_deg; }
```
which are filled with
```c++
custom_control.roll_target_deg = nav_roll_cd * 0.01f;
custom_control.pitch_target_deg = nav_pitch_cd * 0.01f;
custom_control.pitch_trim_deg = g.pitch_trim;
```
#### Servo overrides
The custom controller task will run after the `stabilize` task and before the `set_servos` task.
This means that by default the safety checks mixing which happens in `servos.cpp` will still apply and may override the custom controller.
However, a method `set_output_pwm_chan_override(uint8_t chan, uint16_t value)` is given, in order to block `set_servos` from modifying this channel. This can be useful for implementing experimental/custom mixers.
#### Known drawbacks
- The parameter namespace is also `CC`. I think this might cause conflicts in the wiki?
- Due to the implementation details, output functions of GPIO (-1 enum value) cannot be addressed. Not sure how to fix that.
- AFAIK, the Plane codebase doesn't do rate controller and/or control surface bumpless transfer upon mode switches (e.g. FBWA->MANUAL). That means that there will be a step in servo output upon switching out of the custom controller and into a rate-controlling mode. The integrators are being actively reset, but this is a perfect solution. Perhaps the upcoming #32743 will fix this.
- Upon exiting the custom controller, all the main controllers are reset. Since these controllers are individually, constantly reset while the custom controller is running, there might be no reason to reset them all anew, including controllers which might not have been overriden.
#### Known unknowns
- I suspect the current RC inputs API doesn't allow accessing channels >8. I have to verify this.
- If the custom controller writes onto unused output channels, their PWM value will go from 0 whatever is requested. However, when the custom controller is suspended, the servo value will not return to 0. I do not yet know how to restore this state.
<img width="1368" height="919" alt="image" src="https://github.com/user-attachments/assets/ae199adb-25e8-4e05-9302-a11d03f59833" />
### 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
- [X] Logs attached
- [X] Logs available on request
Testing has been carried out in autotests as well as RealFlight.
The new autotest attempts to explore as much of the new functionality as possible. You need to read the PID example controller that is used in order to fully understand the test.
In RF, the test have been done with the FT3DXL aircraft. It is very clear when the controller banks are switched, the Custom Controller isn't tuned for this aircraft and it produces angle overshoots. Other than that, no bugs or side-effects have been observed.
Parameters and logs: [Dropbox](https://www.dropbox.com/scl/fo/i9wncuajxgpdtiocgg9p1/ACuCPd5g3Vrdy4cHC1xioi4?rlkey=ay0d4q8ha7o4haa9r8xxsjclt&st=5onxxaek&dl=0)
P : The output functions array is VERY large.G : I know, but I couldn’t think of an alternative.A : You can have an array of, say 10 items (you can define that length), which will populate with a structure of output function and value.
Traverse it and if you don’t find your function, fill in a new spot.
Lupus : rate controller?
A : Autotest complains about parameter names.G : Yes, they conflict with their counterparts in AC_CustomControl.A : We can use CP_ or something.
UTC0804
master ← peterbarker:pr-claude/asan-fixes
opened 08:40AM - 29 May 26 UTC
### Summary
Fixes three bugs found by ASAN, and allows autotests to be run un… der `--asan`
### 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
Allows someone to run the autotest suite under ASAN.
I did so today and some fixes are included here:
- off-by-one problem in the TSYS01 (trying to be too clever)
- problem when packing motor values (missing checks that there was actually still valid motor data to pack!)
- harmonic notch filter buffer overread (there's [an issue](https://github.com/ArduPilot/ardupilot/issues/33230) and a [pre-existing PR](https://github.com/ArduPilot/ardupilot/pull/33232) for this one
... the i2c addr deconfliction is a bonus extra that fixes a race condition in the Sub parameters test
A : Approved!
UTC0809
master ← andyp1per:pr-baro-drift-minimum
opened 07:40PM - 13 Apr 26 UTC
## 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 : Why can’t these improvements be common among vehicles?Andy : I didn’t want to modify Plane. There’s the issue that accelerometer biases can’t be learned properly through the resets, I couldn’t fix that.A : I would expect the bias estimate and the EKF innovation to gradually climb together and be observable.
(Discussion on when update_home() should be called and whether the accelerometer bias estimation can indeed be observed.)
A : I just simulated it in and it seems to learn the acceleration bias properly.
Checked with gdb that it is still resetting home.
But yes, it is much slower in Plane in learing the accelerometer biases.
The question is, is it fast enough?
Andy : I bet it’s not fast enough.
P : In any case, it would be the best if the behaviour was common across vehicles.
UTC0845
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.
A : I’ve never seen the need to control the vehicle in ground effect in quadplane.
But I guess planes run on bigger time constants.
Andy : We need Randy to review it.
UTC0855
master ← hamishwillee:move_mav_guided_change_x
opened 01:44AM - 03 Jun 26 UTC
We moved `MAV_CMD_GUIDED_CHANGE_HEADING` from ardupilotmega.xml to common.xml la… st week. IN https://github.com/mavlink/mavlink/pull/2493#issuecomment-4528154628 @davidbuzz pointed out that this is normally used with `MAV_CMD_GUIDED_CHANGE_SPEED` and `MAV_CMD_GUIDED_CHANGE_ALTITUDE`.
This PR is to explore the appetite of ArduPilot for moving the commands - which makes sense as it groups like with like.
Note, 2 commits - the first is a direct copy, and the second is minor modifications for mavlink/mavlink.
@davidbuzz @rmackay9 @peterbarker This was discussed in the MAV call. We're not opposed, but we wanted to make sure this seems reasonable to you. If so, I will create a companion PR in mavlink/mavlink and get buy-in there too.
FYI Under the way we are running common.xml at the moment something can go into common.xml if it is supported in two stakeholder stacks, or by one stakeholder stack and the other either plans to take it, or accepts that it is "good" but doesn't need it right now. We don't accept things otherwise - such as "not considered a good design that can be standardised". We're slowing moving things that are truly standard to standard.xml.
Buzz : Agreed.
Merged!