Attendees (unique) : 7
UTC0700
master ← Juergen-Fahlbusch:Juergen-Fahlbusch-patch-1
opened 11:40AM - 03 Jul 26 UTC
### Summary
AP_FlashStorage: set current_sector during init
Related discus… sion https://discuss.ardupilot.org/t/potential-incomplete-initialization-on-ap-flashstorage/144440
Perhaps resolves: https://github.com/ArduPilot/ardupilot/issues/33538
### 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)
- [x] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
### Description
While troubleshooting aninternal error 0x200000 I noticed that parameters could no longer be saved permanently. Notably, the parameters STAT_BOOTCNT and STAT_RUNTIME—which usually increment automatically—kept reverting to their previous values after a restart. Further analysis revealed that:
Sector 0 was marked with status [SECTOR_STATE_AVAILABLE] Sector 1 was marked with status [SECTOR_STATE_IN_USE] Consequently, the current parameters were being loaded from Sector 1. However, when writing new parameters, the system attempted to write to Sector 0. In my opinion, the cause of this is that the variable current_sector is not set to the active sector during initialization.
I was able to resolve the issue—at least for testing purposes—by inserting the initialization of the current_sector variable after the following code block:
// work out the first sector to read from using sector states
enum SectorState states[2] {header[0].get_state(), header[1].get_state()};
uint8_t first_sector;
if (states[0] == states[1]) {
if (states[0] != SECTOR_STATE_AVAILABLE) {
return erase_all();
}
first_sector = 0;
} else if (states[0] == SECTOR_STATE_FULL) {
first_sector = 0;
} else if (states[1] == SECTOR_STATE_FULL) {
first_sector = 1;
} else if (states[0] == SECTOR_STATE_IN_USE) {
first_sector = 0;
} else if (states[1] == SECTOR_STATE_IN_USE) {
first_sector = 1;
} else {
// doesn't matter which is first
first_sector = 0;
}
//added initialization current_sector
current_sector = first_sector;
UTC0700
master ← davidbitton:local/cdc-ecm-spike
opened 08:52PM - 01 Jul 26 UTC
## Summary
Experimental **opt-in** USB **CDC-ACM + CDC-ECM** composite and an *… *AP_Networking** USB-ECM lwIP netif for static IPv4 over USB, exposed as a separate board target **`MatekH743-ECM`**.
- Stock **`MatekH743`** remains **dual CDC-ACM** (OTG2 in `SERIAL_ORDER`); ECM is **not** enabled by default.
- Lab board: `HAL_WITH_USB_CDC_ECM`, USB PID **`0x574E`**, product string `MatekH743-ECM`, shared **ACM-only** bootloader (`USE_BOOTLOADER_FROM_BOARD MatekH743`).
- Backend: `AP_NETWORKING_BACKEND_USB_ECM` (default off unless board defines it).
- Defaults (`defaults.parm`): `NET_ENABLE`, static-friendly DHCP off, **`NET_P1` UDP server / MAVLink2 / port 14550** so the FC does **not** need the GCS IP (GCS uses `udpout:FC_IP:14550` / QGC target host).
### HIL (author)
- Matek H743-Mini, macOS host NIC on ECM, static `192.168.144.14` (FC) / host peer on same `/24`.
- ICMP ping, MAVProxy `udpout:192.168.144.14:14550`, QGroundControl to same (UDP client → FC server).
- ACM MAVLink still works on the composite.
### Non-goals / notes for reviewers
- Not enabled in bootloader.
- F4 / insufficient EP budget out of scope (compile guards).
- macOS may show the USB iMACAddress as the interface MAC; host may need a **distinct** `lladdr` for reliable ARP (lab note).
- Frame reassembly accounts for hosts that pad to MPS without ZLP (ethertype / IP length heuristics).
- Local design notes under `local/cdc-ecm/` are **not** in this PR (gitignored author docs).
## Test plan
- [ ] `./waf configure --board MatekH743 && ./waf copter` (regression, no ECM)
- [ ] `./waf configure --board MatekH743-ECM && ./waf copter`
- [ ] Flash MatekH743-ECM; USB identity PID `0x574E`; single ACM + ECM NIC on host
- [ ] MAVProxy on ACM
- [ ] Host static IP on ECM iface; ping FC `NET_IPADDR` (default `192.168.144.14`)
- [ ] GCS via UDP client to `FC_IP:14550` with `NET_P1_TYPE=2` / protocol MAVLink2 (defaults)
- [ ] Confirm stock MatekH743 image still dual-ACM / no ECM symbols when ECM off
Draft for early review / direction; happy to split USB descriptors vs networking backend if preferred.
Addes a secondary network, ethernet connection when the Flight Controller gets plugged in.Randy : Interesting!Peter : We should be mindful that the USB transaction time is unlimited.
UTC0702
master ← peterbarker:pr-claude2/deadreckoning-wind
opened 05:00AM - 30 Jun 26 UTC
### Summary
Prevents fusing a probably-bad airspeed estimate.
Closes https… ://github.com/ArduPilot/ardupilot/issues/33451
### 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
```
┌────────────────────┬───────────────────────────────────┬─────────────────────┬───────┐
│ Commit │ Role │ DeadReckoningInWind │ Error │
├────────────────────┼───────────────────────────────────┼─────────────────────┼───────┤
│ e53416e77b │ parent (just before the series) │ PASS │ 1.7° │
├────────────────────┼───────────────────────────────────┼─────────────────────┼───────┤
│ 324d5da811 │ first commit of the rework series │ FAIL │ 18.6° │
├────────────────────┼───────────────────────────────────┼─────────────────────┼───────┤
│ 61874da020 │ tip of the rework series │ FAIL │ 14.4° │
├────────────────────┼───────────────────────────────────┼─────────────────────┼───────┤
│ … master (current) │ post-rework + 2 yrs │ FAIL │ 16.7° │
├────────────────────┼───────────────────────────────────┼─────────────────────┼───────┤
│ master + fix │ — │ PASS │ 2.0° │
└────────────────────┴───────────────────────────────────┴─────────────────────┴───────┘
So the answer to your question: yes, it fails immediately after the regression — and more than that, the bisect lands on the exact commit. 324d5da811 ("AP_NavEKF3: Use last observed wind
states to enable dead reckoning", 2024-06-09) is the first commit where the test fails; its direct parent e53416e77b passes. That commit added the windStateLastObs synthetic-airspeed
branch in readAirSpdData() with no assume_zero_sideslip() gate, so multicopters began fusing a synthetic airspeed. 61874da020 later reworked that same branch (to the lastAspdEstIsValid
form on current master), but the regression was already live as of 324d5da811.
Each failure was confirmed genuine (clean takeoff → wind-learning → GPS-off → divergence during dead-reckoning, no pre-divergence crash), and the parent pass was verified airborne in the
dataflash log.
```
### Description
@pavloblindnology 's patch does seem to fix the Copter problem.... can it create others?
Randy : Fixes the dead reckoning code in copter.
Synthetic airspeed did more bad than good in the end.
SITL tests well.
Merged!
UTC0705
master ← Georacer:pr/ac_custom_control_build_option
opened 09:29AM - 26 Jun 26 UTC
### Summary
This is a precursor to https://github.com/ArduPilot/ardupilot/pul… l/33240, in order to be able to use hwdef define directives.
### 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)
- [ ] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
### Description
Previously you could enable the custom controller only via `boards.py` with `--enable-custom-control`. It was also automatically enabled in SITL.
We want to bring in similar functionality for Plane, but if we use the same name there are redefinition conflicts.
Also, it's impossible as-is to have a board hwdef which automatically enables it.
This PR addresses those two issues.
Size compare for the case of the feature turned off. The `size_compare_branches.py` script won't work with the feature enabled case, because the invocation mechanism has changed.
```
❯ ./Tools/scripts/size_compare_branches.py --board=Durandal --vehicle=copter,plane --no-merge-base --master=ap_master
SCB: Running (git symbolic-ref --short HEAD) in (.)
SCB-GIT: pr/ac_custom_control_build_option
SCB: Building Task(Durandal, ap_master, /tmp/tmp6i1ftdpc/out-master-Durandal, ['copter', 'plane'], [] arm-none-eabi)
SCB: Running (git checkout ap_master) in (.)
SCB: Running (git submodule update --recursive) in (.)
SCB: Running (./waf configure --board Durandal --consistent-builds) in (.)
SCB: Running (./waf copter) in (.)
SCB: Running (./waf plane) in (.)
SCB: Running (rsync -ap build/ /tmp/tmp6i1ftdpc/out-master-Durandal) in (.)
SCB: Building Task(Durandal, pr/ac_custom_control_build_option, /tmp/tmp6i1ftdpc/out-branch-Durandal, ['copter', 'plane'], [] arm-none-eabi)
SCB: Running (git checkout pr/ac_custom_control_build_option) in (.)
SCB: Running (git submodule update --recursive) in (.)
SCB: Running (./waf configure --board Durandal --consistent-builds) in (.)
SCB: Running (./waf copter) in (.)
SCB: Running (./waf plane) in (.)
SCB: Running (rsync -ap build/ /tmp/tmp6i1ftdpc/out-branch-Durandal) in (.)
Board,copter,plane
Durandal,*,*
```
Peter : The code seems to compile nicely.
But the extract features doesn’t find it.
George : I’ll look again at it.
UTC0713
master ← hunt0r:issue10050-sim-rover-uses-internal-battery
opened 07:35PM - 22 Jun 26 UTC
### Summary
Simulated rover uses the internal SITL::Battery. This means it re… sponds to SIM_BATT_VOLTAGE and SIM_BATT_CAP_AH parameters as-documented.
This mostly accomplishes https://github.com/ArduPilot/ardupilot/issues/10050 for Rover.
### 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
- [ ] Logs available on request
In SITL, I manipulated SIM_BATT_CAP_AH and SIM_BATT_VOLTAGE parameters and observed them having the documented & expected effects. (Including losing thrust and coming to a stop when battery capacity is exhausted.)
### Description
The battery consumption model proposed is extremely simple, happy to improve it slightly or OK to land as-is and let a future PR do that.
Randy : What happens if the battery is empty? They are initialized to 0, OK.Peter : Setting 0 battery capacity means the feature is disabled.Randy : It’s failling a Rover test. Probably a real failure.
Approved it, so MergeOnCIPass.
UTC0719
master ← peterbarker:pr-claude2/fix-flakey-rtl-tests
opened 09:12AM - 01 Jul 26 UTC
### Summary
Fix two tests which were very rarely flakey in CI, but very flake… y when pushed
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [x] 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
Two similar tests, two different failure causes.
One wasn't waiting until the vehicle had settled and was ready to arm, meaning the recorded yaw didn't match the RTL yaw.
The second was failing if the vehicle swung past 0 back into 360, so do proper heading maths to see if we have the correct yaw.
Randy : Approved!
UTC0723
master ← peterbarker:pr-claude2/started-becomes-attitude-valid
opened 05:41AM - 05 Jul 26 UTC
### Summary
Avoids using an EKF-backend-specific state variable when deciding… on which backends to use for primary/secondary etc
### 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,antennatracker,blimp,bootloader,copter,heli,plane,rover,sub
CubeOrangePlus,0,0,*,0,0,0,0,0
```
### Description
Since the EKFs set attitude_valid *from* the started boolean, this is a no-op.
Only the EKF AHRS backends have this started concept, but all of the backends have attitude_valid.
Switching to using attitude_valid will allow us to generalise the selection of which AHRS backend to use - I don't think there's ever a reason to prefer a backend if it can't provide a vehicle attitude, so it makes sense in both places it is used in here.
Randy : How come you did’t go for initialized()?Peter : It doesn’t necessarily spit out data during initialized().R : Can attitude_valid become false?P : Only when started goes false.R : attitude_valid might not be the same in the future.P : Correct, this is intentional.R : But what if I don’t want to change when I don’t have lost attitude?P : When would you ever want that?R : When I don’t know if the other filters are good. It might have knock-on effects if someone changes lost_attitude in the future.P : The intention is to hide started away, it shouldn’t be exposed to the outside world, it’s EKF internals.
In general I want to streamline how data is extracted from EKF and AHRS.
UTC0748
master ← peterbarker:pr-claude/blimp-manual-heading-tolerance
opened 08:37AM - 04 Jul 26 UTC
### Summary
Widen error margin in Blimp test
### 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)
- [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
This didn't fail in 1000 runs... so I ran it some more.
### Description
The per-stop heading check in FlyManualFinned is born-marginal. MANUAL mode does not hold heading (ModeManual::run is open-loop), so the finned blimp's translation-into-yaw coupling lets the heading settle several degrees off after a stop, and the old +-10 degree limit was right at the top of that distribution - which is why the test occasionally trips in CI (e.g. 349 deg / 11 deg off on an unrelated PR).
A 1000-run campaign measuring the true settled drift (worst offset over a settle window, not the closest approach the lenient wait_heading check happens to catch) found the drift reaches 12 deg, with 5.8% of runs settling past 10 deg. 15 degrees clears the whole observed distribution with ~3 degrees of headroom while remaining a meaningful check that MANUAL translation does not spin the blimp.
Michelle : The test keeps failling, perhaps it’s not worth running it anymore? Widening it even further seems counter-productiive.
But put the 15degs in, and we’ll see in 6 months if we need to widen it to 20degs.
Approved!
UTC0750
master ← hunt0r:issue10050-sim-blimp-uses-internal-battery
opened 02:46PM - 23 Jun 26 UTC
### Summary
Simulated blimp uses the internal SITL::Battery. This means it re… sponds to SIM_BATT_VOLTAGE and SIM_BATT_CAP_AH parameters as-documented.
This accomplishes https://github.com/ArduPilot/ardupilot/issues/10050 for Blimp.
### 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
- [ ] Logs available on request
In SITL, I manipulated SIM_BATT_CAP_AH and SIM_BATT_VOLTAGE parameters and observed them having the documented & expected effects. (Including losing thrust and coming to a stop when battery capacity is exhausted.)
Merged!
UTC0751
master ← peterbarker:pr-claude/configuredToUseGPSForPosXY-fix
opened 12:19AM - 02 Jul 26 UTC
### Summary
Makes EKF3 consistent with EKF2 in terms of setting Estimates sta… te
### 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
The configured_to_use_gps_for_pos_XY estimate is documented as, and named for, "GPS is configured as the horizontal position source for this estimator". EKF3 was populating it from
configuredToUseGPSForPos(), which is also true when GPS is configured only as the vertical (height) position source - unlike EKF2, which uses configuredToUseGPSForPosXY().
The sole consumer, use_recorded_origin_maybe(), uses this flag to decide whether to fall back to a recorded origin: when GPS is only the height source it will not set the horizontal origin, so the recorded origin should be used. Align EKF3 with the field name and documentation, and with EKF2's population of the same field.
This was noted as a deferred change during review of the move of these source methods into the backend estimates structure.
Problem was missed in review of https://github.com/ArduPilot/ardupilot/commit/55a6b081ce6062f724eb784f399093e3f17c1a49
Problem was noticed in https://github.com/ArduPilot/ardupilot/pull/33292#pullrequestreview-4409530957 and I suggested I would fix it as a separate PR. Which is what this is.
P : This makes EKF3 match EKF2.
configuredToUseGPSForPos() will return true even if we only use EKF for altitude, not XY.
Randy : I’m being paranoid that this will have inadvertent effects.
< after some code lookup >
R : Okay, I’m happy now, approved!P : But now I’m doubting whether this would work nicely for other sources of location.
Merged!
P : My goal is to prepare for a seamless introduction of the CINS estimator, but we have so many corner cases in estimator selection, which is even vehicle specific!
I want to have an ordered list of estimators ordered by preference, which the codebase will abstractly go over and pick the primary and fallback estimators.
And have some Lua bindings to select the estimator directly. Perhaps an AUX switch too.
Randy : I’m in favour of breaking the mould and re-writing the logic. It might take a few months to build back confidence in the system, but I’m for it.P : I’ve been trying to avoid this very hard.