Attendees (unique) : 10
UTC0700
master ← tridge:pr-quadplane-PPP
opened 03:29AM - 18 May 26 UTC
### Summary
added -f quadplane-PPP for sim_vehicle.py
### 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 the first step in working on better PPP support without flow control, I will use quadplane-PPP as a testbed
<img width="372" height="107" alt="image" src="https://github.com/user-attachments/assets/baf08f5e-1792-442d-a239-7fd2ea6374c2" />
Andrew : Hopefully this brings us closer to a further HAL abstraction.
We should have had promoted hwdef higher, so that we can have the same board with different HALs (ChibiOS, Zephyr, etc…).
You can already have one ethernet and ChibiOS network backend too, at the same time.
Next step is PPP with flow control.
Merged!
UTC0708
master ← katzfey:pr-add-voxl3
opened 11:34PM - 01 May 26 UTC
### Summary
Add support for the new ModalAI VOXL3 board.
### Classificatio… n & 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
Tested changes on both VOXL2 and VOXL3 hardware
### Description
Adding support for VOXL3 included a new hwdef.dat file, support for specifying i2c buses in the hwdef.dat file, and adding remote UART support (on apps processor side) for GPS. The remote UART mechanism was built upon SerialManager so that up to 5 external serial ports can be configured.
A : RemoteUARTDrover::write() could possibly lead to a hang if the threading is wrong?
Ah, no, that’s on the host side.
Peter : Found a case of uninitilized port use.
UTC0722
master ← peterbarker:pr/ahrs-correct-state-copying
opened 08:25AM - 19 May 26 UTC
### Summary
Corrects state in the loop that the active backend changes
###… 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
This is a follow-on from https://github.com/ArduPilot/ardupilot/pull/33110 and is based upon it. There are only two commits on top of that PR, and they are both relatively simple.
The first factors out the call to copying the backend estimates from the active EKF type (the PR this is based on made that trivial. This also removes the copying of the estimates from DCM all the time - the code it pretty clear that was pointless now.
The second patch reorders the way we call methods after updating the backends such that we update the currently active backend and *then* copy stuff out of the active backend / make derived cached values!
P : I’ll test this in the weekend.
UTC0723
master ← peterbarker:pr/revert-zero-velocity-fusion
opened 03:37AM - 20 May 26 UTC
### Summary
Reverts PR#32396 which caused regression https://github.com/ArduP… ilot/ardupilot/issues/32980
### 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
The zero-velocity fusion PR introduced the linked regression, and a possible additional regression around quadplane takeoffs (`const bool onGroundNotFlying = onGroundNotMoving || dal.get_takeoff_expected();` does not gel with `When stationary on ground or armed before takeoff` as takeoff-expected can be true mid-air)
This PR simply reverts the original PR.
I would prefer we work through the issue rather than reverting, but there are strong reasons to get a fix into master ASAP (and there was definite agreement from other devs on DevCall that we should do this).
There is a [bunch of discussion on Discord](https://discord.com/channels/674039678562861068/1506212127155949699) as to other options - but (a) I said I would create this PR and (b) [my final question](https://discord.com/channels/674039678562861068/1506212127155949699/1506452262740820109) as to how we can be "taking off" mid-air with a conventional plane remains unanswered.
I had a feeling there must be something else in these patches which is problematic, apart from the onGroundNotMoving determination. However there is a pre-existing bug (present both in master and on top of this branch) - probably the confounding factor for @andyp1per - which is that the "takeoffexpected" flag is being set by Plane when we enter FBWA mid-flight!
<img width="1981" height="921" alt="image" src="https://github.com/user-attachments/assets/e81806b2-5194-4774-8122-541298a91865" />
```
--- a/Tools/autotest/arduplane.py
+++ b/Tools/autotest/arduplane.py
@@ -6783,6 +6783,11 @@ class AutoTestPlane(vehicle_test_suite.TestSuite):
def GuidedAttitudeNoGPS(self):
'''test that guided-attitude still works with no GPS'''
+ self.set_parameters({
+ "LOG_DISARMED": 1,
+ "LOG_REPLAY": 1,
+ })
+ self.reboot_sitl()
self.takeoff(50)
self.change_mode('GUIDED')
self.context_push()
```
```
graph POS.Alt RFRN.Flags&64:2
```
P : We have a regression in Plane dead-reckoning in master.
A : Could it be that we are resetting isFlying on mode change?
P : Yes, isFlying is going to 0 in the autotest GuidedAttitudeNoGPS indeed. This is wrong.George : Could it be that the dead-reckoning things we’re going too slow and flagging a not-flying condition?A : It seems it’s moving fast enough at that point, but maybe it is a case of flying at a very low airspeed, below stall speed. So you’re not actually “flying” in the aerodynamic sense and should not use that assumption for fusion.P : At the same time we’re at 0 throttle and we’re pitching up, losing a lot of airspeed.A : Right. So we’re moving but because isFlying is false, we’re moving 0 velocity and this screws up the dead-reckoning.
We could use the “flies forward” flag of the EKF to block this code from executing.
It will work in Plane likely, but boats drifting at 0 throttle might indeed still get confused.
Randy, do boats handle dead-reckoning nicely? They don’t use the fly_forward flag.
Randy : I’ll check.A : I just checked, it’s bad.R : Okay, I’ll get on it.
P : Let’s merge AP_NavEKF3: do not look at takeoff for zero velocity fusion by andyp1per · Pull Request #33115 · ArduPilot/ardupilot · GitHub as a first mitigation.A : And I’ll follow up.R : Could we improve ‘isFlying’?A : It’s hard, for example one holds a plane in the air against strong wind. Is it flying at this point?R : We can probably gate the transition from not flying to flying and vice versa with different checks.A : In planes it’s harder to tell if you landed than in planes, especially when you glide and almost hover. During a landing in headwind you might actually hover above the ground. We don’t want to think we’ve landed at 1m above the ground.
P : Okay, merging fix on CI pass.
UTC0803
master ← tpwrules:pr/fix-printf-inf-hang
opened 01:03AM - 20 May 26 UTC
### Summary
If any code or a script tried to use the `%f` format specifier (w… ith any parameters) to format an infinity, it would hang and watchdog and result in sadness. This problem was introduced by the fixes in #30758 , sorry!
### 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
There is a very gnarly explanation in the commit message. All of the conclusions in that original PR still hold, namely that this should probably be replaced. This problem exists in 4.6 too.
Fixes #33024 properly.
A : Do we run unit tests for this kind of thing?P : Yes, we do.A : Approved!
UTC0810
master ← peterbarker:pr/ftoa-loop-breaking
opened 02:06AM - 20 May 26 UTC
### Summary
belt-and-bracers approach to a bugfix for an infinite loop
###… 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
### Description
https://github.com/ArduPilot/ardupilot/pull/33124 is a technical fix for bug found as part of https://github.com/ArduPilot/ardupilot/pull/33024
This is a belts-and-braces patch. If it looks like it can infinite-loop then stop that.
P : How about this approach?A : That’s also an okay approach. But let’s let Thomas decide what he wants.
UTC0815
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.
A : You can declare a parameter structure in AP_SurfaceDistance, but instantiate them in Copter, then pass down the structre in the object constructor.George : Ah, nice! I’ll try that.P : The SITL knows to restart after the context is popped, if a reboot has been done in the test.
UTC0824
Khancyr’s idea and draft to find .Lua applets more easily.
P : I’m concerned that this will make it very hard to sunset some old Lua bindings.R : How do users find and upload scripts now? Via Github?Pierre : Yes.G : Would it be possible to have the page connect to the autopilot, check versions and update?P : Would it be possible to insert metadata on the script for the known-workig AP version? Then we could maybe issue a warning if you update AP firmware but keep the old script. And vice versa.R : Very cool!
UTC0831
master ← peterbarker:pr/delay-sim-time-reasons
opened 10:17AM - 19 May 26 UTC
### Summary
Puts reasons on each delay call
### Classification & Testing (… check all that apply and add your own)
- [x] Checked by a human programmer
- [x] Non-functional change
- [ ] No-binary change
- [x] 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
It's useful to be able to disambigaute delays and whatnot in the output.
This should also allow us to eliminate some of these calls when we can instead look for something in the telemetry stream instead.
G : I’m happy with having the justification mandatory as well.
Merged!
UTC0836
master ← tridge:pr-rover-reject-guided
opened 10:36PM - 17 May 26 UTC
### Summary
brings the 3 vehicles into line
### 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
reject DO_REPOSITION if the destination is outside an active fence, add tests for copter/plane/rover
P : Approved!
MergeOnCIPass
UTC0838
master ← peterbarker:pr-claude/move-write-compass-to-AP_Compass_Logging
opened 02:42AM - 15 May 26 UTC
### Summary
Mirror structure used by baro already for logging
### Classifi… cation & 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
Still get log messages in SITL:
```
1970-01-01 10:00:09.03: MAG {TimeUS : 9039716, I : 0, MagX : 224, MagY : 80, MagZ : -528, OfsX : 5, OfsY : 13, OfsZ : -18, MOX : 0, MOY : 0, MOZ : 0, Health : 1, S : 9039716}
1970-01-01 10:00:09.03: MAG {TimeUS : 9039716, I : 1, MagX : 224, MagY : 80, MagZ : -528, OfsX : 5, OfsY : 13, OfsZ : -18, MOX : 0, MOY : 0, MOZ : 0, Health : 1, S : 9039716}
1970-01-01 10:00:09.03: MAG {TimeUS : 9039716, I : 2, MagX : 224, MagY : 80, MagZ : -528, OfsX : 5, OfsY : 13, OfsZ : -18, MOX : 0, MOY : 0, MOZ : 0, Health : 1, S : 9039716}
```
```
Board,plane
MatekF405,-16
```
### Description
Moves the implementation from A to B - same pattern we use for the baro library.
Doing this to simplify a PR moving logging around.
UTC0841
master ← zebulon-86:holybro-v6c-rm3100-support
opened 08:14AM - 30 Apr 26 UTC
### Summary
This adds a board-specific RM3100 compass declaration and a match… ing
AP_Compass probe option so the hwdef rotation is used for the internal
sensor.
### 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
- [x] Logs available on request
### Hardware testing:
- completed compass calibration on the flight controller
- verified heading/orientation after calibration against a phone compass
- confirmed orientation remained consistent when rotating the controller
### Description
This adds support for Pixhawk6C variants with an internal RM3100 compass on I2C bus 0 at address 0x20.
This PR:
- adds an RM3100 compass declaration for Pixhawk6C with the required rotation
- adds a per-driver RM3100 internal probe option in AP_Compass
- disables the generic RM3100 internal probe for Pixhawk6C so the hwdef
rotation is honoured
This keeps the change local to RM3100 and avoids changing the existing
internal probing behaviour for other compass drivers.
AI assistance:
This contribution was AI-assisted (GitHub Copilot). The author reviewed the changes, performed the testing, and takes full responsibility for this PR.
P : Since that’s a Holybro device and the PR is by a Holybro employee, then it’s okay to change the board hwdef.
UTC0846
master ← dakejahl:delete-iis2mdc-driver
opened 10:17PM - 19 May 26 UTC
## Summary
Delete the redundant `AP_Compass_IIS2MDC` driver and switch every bo… ard that referenced it to the `LIS2MDL` driver, which handles the identical silicon. Also gate the LIS2MDL internal-bus auto-probe with `if (all_external)` so it stops shadowing explicit `COMPASS` lines on internal buses.
## Problem
LIS2MDL and IIS2MDC are the same die — same WHO_AM_I (0x40 at reg 0x4F), same register layout, same axis convention, same sensitivity. ST sells them under separate part numbers (consumer vs industrial grade) but they're electrically and software-identical.
LIS2MDL is default-enabled on boards with >1 MB flash and its internal-bus auto-probe in `AP_Compass.cpp` lacks the `if (all_external)` gate that HMC5843/QMC5883L/QMC5883P/IIS2MDC use. So on every board with `AP_COMPASS_PROBING_ENABLED` and an internal IIS2MDC at I2C 0x1E, the LIS2MDL auto-probe registered the chip first with hard-coded `ROTATION_NONE`, and the explicit `COMPASS IIS2MDC ... ROTATION_XYZ` line was blocked by `_i2c_sensor_is_registered()`. The rotation in the hwdef was silently dropped.
On boards that already used `ROTATION_NONE` (ARK_FPV, Morakot, navigator) this was invisible. On boards that needed a real rotation (ARK_PI6X `YAW_180`, CUAV-7-Nano `ROLL_90_YAW_270`, PrincipIoTH7Pi `YAW_270`) mag calibration could not converge because the IMU and the compass were misaligned in yaw. Discovered during ARK FMU V6S board bring-up.
## Solution
Remove all IIS2MDC driver code, config, enum values, and tooling entries. Gate the LIS2MDL internal-bus auto-probe with `if (all_external)`. Switch the six affected boards from `COMPASS IIS2MDC ...` to `COMPASS LIS2MDL ...`, preserving each board's existing rotation: ARK_FPV, ARK_PI6X, CUAV-7-Nano, Morakot, PrincipIoTH7Pi, navigator (Linux).
On boards that enabled `AP_COMPASS_PROBING_ENABLED`, the LIS2MDL auto-probe was already shadowing the IIS2MDC, so stored `COMPASS*_DEV_ID` values already carry `DEVTYPE_LIS2MDL` (0x19). On boards that disabled probing (e.g. PrincipIoTH7Pi), only the explicit `COMPASS IIS2MDC ...` line ran and 0x18 was actually stored. A `PARAMETER_CONVERSION` block in `Compass::init()` rewrites any stored 0x18 to 0x19, preserving bus type/number/address so existing mag calibrations survive the upgrade without forcing users to re-calibrate.
P : We’ve got duplicate compass drivers!
jdahl added the duplicate and he’s now removing it.
UTC0847
master ← UAVcihang:pr-SkyDroid-S3
opened 07:18AM - 27 Apr 26 UTC
add sky-droid-s3 hardware support for ardupilot
P : Andy has raised objections.
UTC0848
master ← peterbarker:pr/check-latlng
opened 05:12AM - 20 Mar 26 UTC
## Summary
The additional check makes sure that the lat/lng have reasonable m… aximum ranges.
## 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
## Description
This will stop bad locations entering the vehicle. The new tests previously died with a MAV_RESULT_FAILED as the AHRS library bounces the bad location, but we can return DENIED from the mavlink layer cheaply.
Merged
UTC0850
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
- [x] L431 (Matek L431 Periph)
- [x] G4xx (Matek G474 Periph) (Hitec-Airspeed?)
- [x] H757 (CubeOrangePlus)
- [x] H743 (Boots!)
- [x] F427 (Cube Black)
- [x] F1xx (iomcu)
- [x] F3xx
- [x] F405 / F407 (SpeedyBee F405 v4)
A : I do have an F3 at hand!
Ah, this one doesn’t boot. I’ll try another one.
P : I have an F103 as well! I’ll try it too.
Hm… it doesn’t seem to accept the firmware.
A : Mine is works and is happy! Now let’s find a GPS to connect.
UTC0906
master ← tatsuy:pr-clear-override-by-rc
opened 01:06AM - 21 Jan 22 UTC
This PR introduces a new option to clear the RC override, allowing the pilot to … regain control by operating roll, pitch, throttle, or yaw during an RC override situation. While this functionality was previously possible using RCx_OPTION(46), the new option provides a more direct and safer method for pilots to cancel overrides using basic RC inputs.
## Required parameters
The following settings are required
`RC_OPTIONS = 16384` (bit 14, `CLEAR_OVERRIDES_BY_RC`) enables the feature
`RCx_OPTION = 46` (`RC_OVERRIDE_ENABLE`) Re-enable RC overrides
## Per-vehicle behavior
Vehicles override `RC_Channels::has_pilot_input_for_override_clear()` to define which axes count as pilot input:
| Vehicle | Axes that clear an active override |
|---|---|
| Copter / Plane / Blimp | roll, pitch, yaw out of trim deadzone, or throttle moved beyond deadzone since the override began |
| Rover | steering (rcmap roll), throttle; plus lateral on omni rovers |
| Sub | forward, lateral, yaw, plus throttle (= vertical) |
## Testing
Tested manually in SITL with Copter, Rover, and Plane.
Added autotest:
`RCOverridesClearByPilotInput` on Copter (all four primary axes each clear) and Rover (steering/throttle clear; pitch/yaw must not), plus held-while-neutral and bit-off regression checks.
P : This PR will detect the sticks moving and abort the overrides.
Let’s test the new changes again in Spring Valley.