Attendees (unique) : 10
UTC0702
DFU issue
Andy : If you reinstate the hook, use new bootloader and old firmware, it works.
But not with old firmware.
Not sure why yet. It doesn’t seem to detect the USB.
Testing in Cube Orange, Pixhawk 6X, TBS Lucid.
UTC0707
master ← peterbarker:pr-claude/mount-camera-info-refactor-fix-wire-protocol-stuff
opened 07:45AM - 31 Mar 26 UTC
## Summary
Corrects extraction of data from wire data and creation of mavlink… packets. Avoids some buffer over-reads and what-not
## Testing (more checks increases chance of being merged)
- [x] Checked by a human programmer
- [ ] Tested in SITL
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
- [x] Autotest included *in previous PR*
## Description
Extracted from https://github.com/ArduPilot/ardupilot/pull/32515 which is a larger body of work.
Tests were already merged as part of the simulator work https://github.com/ArduPilot/ardupilot/pull/32613
These patches are expected to be back-portable to 4.7 (with the exception of the ViewPro simulation patch)
(Peter presents his PR. Randy goes over it and comments.)
Approved!
UTC0735
master ← peterbarker:pr/fix-ap-mount-scripting-backend
opened 01:47AM - 31 Mar 26 UTC
## Summary
Replaces https://github.com/ArduPilot/ardupilot/pull/32382 as a fi… x for a regression with scripting backend functionality.
## Testing (more checks increases chance of being merged)
- [x] Checked by a human programmer
- [x] Tested in SITL
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
- [x] Autotest included
## Description
refactoring in the mount backend caused issues with the scripting backend.
This fixes those and adds some tests which Robert crafted.
Future PRs from Robert will include the ability for a script to specify what sorts of targets it accepts.
Peter : Rob Long helped fix the scripting mount backend.
Approved!
UTC0740
master ← IamPete1:plane_fast_logging
opened 09:24PM - 30 Mar 26 UTC
Full rate logging currently includes AHRS logging. This includes all the EKF mes… sages. On quadplane with 300Hz loop rate this results in huge log files and often dropping data. This drops AHRS logging out the full rate. If full rate is selected AHRS logs will still be done at 25Hz as they would with fast attitude. Copter only ever logs AHRS at upto 25Hz, so this is inline with that.
This was tested using `graph 1000000/diff(AHR2.TimeUS,0) 1000000/diff(ATT.TimeUS,1)` to compare the rate of the `AHR2` message logged by the AHRS and `ATT` logged in planes `Log_Write_Attitude` function.
This is the new behavior with full rate attitude selected, `ATT` at loop rate, `AHR2` at 25Hz.
```
LOG_BITMASK 1081279.000000 # Fast Attitude|Medium Attitude|GPS|Performance|Control Tuning|Navigation Tuning|IMU|Mission Commands|Battery Monitor|Compass|TECS|Camera|RC Input-Output|Rangefinder|Fullrate Attitude
```
<img width="1243" height="666" alt="image" src="https://github.com/user-attachments/assets/2f7dbe54-0ebf-4803-bd14-7a7d148c2da5" />
With fast attitude, both at 25Hz:
```
LOG_BITMASK 65535.000000 # Fast Attitude|Medium Attitude|GPS|Performance|Control Tuning|Navigation Tuning|IMU|Mission Commands|Battery Monitor|Compass|TECS|Camera|RC Input-Output|Rangefinder|Uknownbit6|Uknownbit15
```
<img width="1292" height="705" alt="image" src="https://github.com/user-attachments/assets/201324c1-24a4-4fe4-b43f-e1dfb5062820" />
With medium attitude, both at 10Hz:
```
LOG_BITMASK 32702.000000 # Medium Attitude|GPS|Performance|Control Tuning|Navigation Tuning|IMU|Mission Commands|Battery Monitor|Compass|TECS|Camera|RC Input-Output|Rangefinder
```
<img width="1252" height="676" alt="image" src="https://github.com/user-attachments/assets/c5a7235b-1026-466b-8c33-b24e2fb7622e" />
Matt : The logs are too big, due to logging EKF. There’s no point in doing that, and fast rate isn’t on by default anyways.Andrew : The maximum update rate of the EKF is 100Hz. But if we disable full rate logging here, is there a way to get back full EKF rate, instead of 25Hz?
Approved!
UTC0749
master ← zebulon-86:AP_InertialSensor-LSM6DSV-Pixhawk6C
opened 03:18PM - 27 Mar 26 UTC
## Summary
Add support for the ST `LSM6DSV16X` IMU as a new `AP_InertialSenso… r` backend.
This includes `WHO_AM_I` validation during probe and `hwdef` support for a tested `Pixhawk6C` hardware variant that may populate `LSM6DSV16X` in place of `ICM42688`.
## Testing (more checks increases chance of being merged)
- [x] Checked by a human programmer
- [ ] Tested in SITL
- [x] Tested on hardware
- [x] Logs attached
- [ ] Logs available on request
- [ ] Autotest included
## Motivation
`LSM6DSV16X` can be used as a pin-compatible alternative to `ICM42688` on some hardware variants.
Adding this backend allows those variants to use the standard `AP_InertialSensor` framework without requiring board-specific IMU handling outside the normal backend path.
## Implementation Notes
- add a new `AP_InertialSensor_LSM6DSV` backend for `LSM6DSV16X`
- validate device identity through `WHO_AM_I` during probe before applying device-specific initialization
- follow the existing `AP_InertialSensor` backend structure for probe, init, and periodic sample handling
- use FIFO-based sample acquisition
- support `HAODR` mode 1 for `1 kHz` to `8 kHz`
- integrate with `INS_FAST_SAMPLE` / `INS_GYRO_RATE`
- enable accelerometer `LPF2` with bandwidth set to `ODR/10`
- include `Pixhawk6C` `hwdef` support for the tested hardware variant
## Testing
Tested on `Pixhawk6C` hardware with `IMU0=LSM6DSV16X` and `IMU1=BMI088`.
### Validation included
- one Loiter flight log from an earlier development commit, showing stable in-flight operation and EKF3 convergence
- one ground-test log from the final PR commit with batch logging enabled, confirming correct IMU registration and logged sample-rate behavior
### Observed results
- IMU frontend rates near `2 kHz`
- both gyro and accel sample rates near `2 kHz` in batch logs from the final commit
- no obvious initialization failure messages
- no accelerometer clipping seen in the checked logs
### Notes
- the Loiter flight log was recorded before final cleanup and is used mainly to show in-flight operation and EKF behavior
- the ground-test log was recorded on the final PR commit with batch logging enabled and is used to confirm registration and logging/sample-rate behavior
### Test logs
```text name=test-logs.txt
https://drive.google.com/drive/folders/11DIusglKCtMEtZg7tN2s_iLEtycdblSl?usp=drive_link
```
## AI Assistance Disclosure
AI-assisted tools were used during development for initial implementation, refactoring, and review support.
All submitted code, register definitions, initialization, and data paths were manually checked against the `LSM6DSV16X` datasheet and validated on `Pixhawk6C` hardware.
P : If the 6C board is a standard implementation, is it OK to modify it with this new IMU?A : I don’t think it’s going to be a problem.
The PR in an existing 6C works.
Merged!
UTC0803
master ← andyp1per:pr-ekf3-zervel
opened 08:55PM - 08 Mar 26 UTC
## Summary
- Fuse synthetic zero velocity when stationary on the ground to cons… train gyro bias and Z-axis accel bias learning. XY accel biases remain unobservable on the ground and are inhibited by dvelBiasAxisInhibit
- Applies in all aiding modes: AID_NONE uses zero velocity instead of the large _noaidHorizNoise fake velocity, and AID_RELATIVE/AID_ABSOLUTE modes fuse zero velocity when no real velocity sensor data is available (e.g. optical flow configured but stationary)
- Gated on onGroundNotMoving to avoid injecting zero velocity when the vehicle is being moved
- **Inhibit all accel bias learning when on ground and moving** (e.g. carried on a utility belt or on a boat). Previously only the gravity-alignment check was used, which allowed the gravity-aligned axis to learn biases from external motion. Adding onGroundNotMoving to dvelBiasAxisInhibit prevents incorrect biases that could cause velocity drift after takeoff
- Broaden updateMovementCheck() to run unconditionally when on ground (previously gated on yaw source type)
## Test plan
- [x] EK3_AccelBiasInhibitOnGroundMoving - verifies bias NOT learned during ground movement (SIM_SHIP), and IS learned when stationary. **Fails on master, passes with fix**
- [x] EK3_AccelBiasZeroVelOptFlow - verifies Z-bias convergence with optical flow config (no GPS) via zero velocity fusion
- [x] EK3AccelBias - existing test still passes (no regression)
- [x] Verify no regression in normal GPS flight
A : I had reservations when this change goes into an autopilot with a GPS. But Paul mentions that it probably applies to non-GPS situations.Andy : My intention is for this to be used for indoors, without GPS.A : Okay. The condition to get onGrOundNotMoving=True you look only at your IMU. But on a ship, you can be steady (non accelerating), but you might be moving steadily and laterally fast. Then you would fuse zero velocity, which is wrong, while GPS would give you correct velocity.
But Paul says this check was meant to apply only on absense of GPS, so we might be okay.
Andy : Thanks, I’ll double-check.
UTC0814
master ← cclauss:pre-commit-use-repo-local-syntax
opened 05:33AM - 01 Apr 26 UTC
### Summary
### Classification & Testing (check all that apply and add yo… ur 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)
- [ ] Tested manually, description below (e.g,. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
### Description
pre-commit: Use `repo: local` syntax to avoid dynamic loading of dependencies and add shellcheck.
Related to:
* https://github.com/ArduPilot/ardupilot/pull/32621#discussion_r3013534704
Do we not like pre-commits in general?
Peter : Not necessarily, some people use them, not necessarily as hooks.
If we remove flake8 in favour of ruff, it could become much faster, so it would work nicely even on interactive rebases.
Ruff should be equivalent to flake8.
P : Are we vulnerable to supply-chain attacks?George : Do you have a specific part of our repos in mind?P : CI suite and our tooling, pulling repos from the internet to do its work.A : Pinning down versions is going to be a pain to maintainC : We can be running things on virtual environments.P : We should give this a little thought, especially how to trust newer versions of packges.
UTC0829
master ← viewpro-caijie:VUAV-TinyV7
opened 02:15AM - 31 Jan 26 UTC
AP_HAL_ChibiOS:added new hardware VUAV-TinyV7.Has undergone hardware testing.
T… hanks.
Merged!
UTC0834
master ← peterbarker:pr/reject-unknown-command-fields
opened 04:03AM - 25 Feb 26 UTC
# Summary
Changes ArduPilot to reject any command where we don't know exactly… what all of the field values mean
## Testing (more check increases chance of being merged)
- [X] Checked by a human programmer
- [X] Tested in SITL
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
- [X] Autotest included
## Description
PRing because of discussion on https://github.com/ArduPilot/mavlink/pull/480
At the moment ArduPilot just ignores fields (and bits within fields) that we don't understand.
This PR adds code so we just reject things we don't understand.
Does not currently try to handle the unused-by-us-bit-set problem.
Very much a WIP!
P : This is to protect ourselves against fields we do not recognize, where we would serve them, but serve them wrong from the point of view of the sender.A : It is more of a responsibility of the sender to not adopt breaking changes in the MAVLink standard.P : We could version the MAVLink command set itself. But the GCS would have to handle all those multiple versions simultaneously.G : We could add an extension field in messages, which carries version information for this specific message? Then the autopilot could read that and decide if it can support it.
Another thing: we wouldn’t want to halt and not route custom/breaking commands that are not intended for the autopilot but for some custom MAVLink payload.