Attendees (max) : 12
UTC0703
master ← TompsonTan:pr_ap-h743r1_baro
opened 05:48AM - 18 Mar 26 UTC
The DPS310 and SPL06 barometers share identical register addresses and ID values… , making it impossible to reliably distinguish between the two at runtime. To resolve this ambiguity, we have decided to support only the SPL06 moving forward.
This change is being made during final testing and prior to mass production, so it should have no impact on existing deployments or users.
Peter : The OP says the two barometers are register identical.
But he also mentions that trying to talk to one but it’s the other, can lead to bad things.
Andrew : We could do some hacks to distinguish between the two.
But we don’t probe all the baros on the list, right?
If there’s a list in hwdef, we use that. But yes, we also probe I2C for them.
The SPL06 is higher in the list and gets probed first.
We could try to find a register that isn’t common between the two.
Merged!
UTC0714
master ← peterbarker:pr/factor-sending-position-target
opened 07:27AM - 17 Mar 26 UTC
## Summary
Factor common code up into GCS_MAVLink base class
## Testing (m… ore 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
- [ ] Autotest included
## Description
These methods have all converged over time, near-enough. Only minor differences:
```
● Yes, two differences worth noting:
1. Copter: change_alt_frame vs get_alt_m
Old Copter code converted in-place then read target.alt * 0.01f:
if (!target.change_alt_frame(Location::AltFrame::ABSOLUTE)) { return; }
// ...
target.alt * 0.01f
New base code uses get_alt_m(ABSOLUTE) which does the same conversion
read-only. These are functionally equivalent — same numerical result, same
failure condition — so nothing is lost.
2. Plane: altitude conversion failure behaviour (intentional change)
Old Plane code used UNUSED_RESULT and always sent the message, falling back to
alt=0 if conversion failed:
int32_t alt = 0;
if (!next_WP_loc.is_zero()) {
UNUSED_RESULT(next_WP_loc.get_alt_cm(Location::AltFrame::ABSOLUTE, alt));
}
// message always sent
New code suppresses the message when get_alt_m(ABSOLUTE) fails. This was
called out in the plan's behaviour table as an improvement (sending a wrong
altitude is worse than not sending at all). The is_zero() case is handled
correctly because a zero-initialised Location has frame ABSOLUTE and alt=0, so
get_alt_m(ABSOLUTE) succeeds returning 0.0f — same output as before.
3. Blimp: no conversion → conversion (intentional fix)
Old Blimp sent target.alt * 0.01f with no frame conversion. New code converts
to AMSL. Explicitly called out as a bug fix.
So nothing is unintentionally lost — the only real semantic change is the
Plane suppression-vs-alt=0 case, which is deliberate.
```
This is in preparation for allowing the return of the altitude in frames other than global-int.
Randy : When we don’t have a target (e.g. FBWA) how about we send this message, but with all zeros?P : I’ll think about it and come back next week.A : Let’s not stream this message without a request during MANUAL, STABLIZE etc. It’s quite a bit of additional bandwidth.P : Then again there are cases where you could fill in velocity targets.
UTC0725
master ← peterbarker:pr/fix-external-compasses
opened 04:22AM - 17 Mar 26 UTC
## Summary
I broke external probing on fmuv3 boards for the IST8310 as part o… f https://github.com/ArduPilot/ardupilot/pull/31831 - this fixes that.
## 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
- [ ] Autotest included
## Description
fmuv3 doesn't do compass probing as such as it does the probing as part of being a feature-detect board.
Tested by dropping a #error into the relevant bit:
```
[ 212/1254] Compiling libraries/AP_EFI/AP_EFI_Serial_Lutan.cpp
../../libraries/AP_Compass/AP_Compass.cpp:1290:2: error: #error hi
1290 | #error hi
| ^~~~~
compilation terminated due to -Wfatal-errors.
Waf: Leaving directory `/home/pbarker/rc/ardupilot/build/mindpx-v2'
Build failed
-> task in 'objs/AP_Compass' failed (exit status 1):
{task 139967551969040: cxx AP_Compass.cpp -> AP_Compass.cpp.0.o}
(run with -v to display more information)
pbarker@crun:~/rc/ardupilot(master)$ git diff
diff --git a/libraries/AP_Compass/AP_Compass.cpp b/libraries/AP_Compass/AP_Compass.cpp
index 127afd6dbda..de81914071e 100644
--- a/libraries/AP_Compass/AP_Compass.cpp
+++ b/libraries/AP_Compass/AP_Compass.cpp
@@ -1287,6 +1287,7 @@ void Compass::_probe_external_i2c_compasses(void)
for (uint8_t a=0; a<ARRAY_SIZE(ist8310_addr); a++) {
#if AP_COMPASS_IST8310_EXTERNAL_BUS_PROBING_ENABLED
+#error hi
FOREACH_I2C_EXTERNAL(i) {
probe_i2c_dev(DRIVER_IST8310, AP_Compass_IST8310::probe, i, ist8310_addr[a], true, default_rotation);
RETURN_IF_NO_SPACE;
```
Merged!
UTC0731
master ← rmackay9:copter-ch6-wp-speed-overshoot
opened 05:21AM - 11 Mar 26 UTC
## Summary
This resolves issue https://github.com/ArduPilot/ardupilot/issues/… 31584 in which if a user setup the "ch6" tuning of Waypoint speed the vehicle would overshoot the speed slightly before returning to the correct speed.
shashwatvoa (see PR https://github.com/ArduPilot/ardupilot/pull/32373) discovered the issue which was that we were directly setting the AC_WPNav library's speed but were neglecting to set Auto mode's desired_speed_override_ms.xy variable.
The solution is to not call AC_WPNav directly but instead call flightmode->set_speed_NE_ms() which is an existing function and calls both AC_WPNav and also set the desired_speed_override variable.
The TUNE and TUNE2 enum values have been changed from 10 to 61 as part of the move from cm/s to m/s. If the user had TUNE = 10 and flies the vehicle they will find the Ch6 tuning doesn't work and the vehicle flies at the WP_SPD value (in m/s). I've also updated the TUNE parameter docs - I've removed "10:WP Speed" and added "61:WP Speed (m/s)".
There are two impacts of this change that we should think about:
1. the set_speed_NE_ms() function is implemented for Auto, Guided, RTL (and probably SmartRTL) meaning the tuning will only work for these flight modes. Previously it may have affected other modes that used the AC_WPNav controller (e.g. Avoidance_ADSB, circle?, follow, land?, RTL, SmartRTL, SystemId, Throw, ZigZag)
Below are screen shots of the vehicle's ground speed before vs after when flying a square mission in Auto mode and CH6 set so that the desired speed is 5.5m/s
<img width="755" height="612" alt="image" src="https://github.com/user-attachments/assets/4dc14dae-06d1-481f-974b-6c62923d5454" />
<img width="606" height="383" alt="image" src="https://github.com/user-attachments/assets/0d9b3c3d-96c7-455e-ada3-0cf0d7cef5a8" />
<img width="604" height="382" alt="image" src="https://github.com/user-attachments/assets/34f47de0-7aed-473d-a058-b574f019fd23" />
## 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
- [ ] Autotest included
P : This will break people’s workflows.
Merged!
UTC0736
master ← andyp1per:pr-copter-arm-delay
opened 08:57PM - 08 Mar 26 UTC
## Summary
- Allow `ARM_DELAY` to be overridden via hwdef `define`, defaultin… g to existing 500ms
- When `ARMING_DELAY_MSEC` evaluates to zero, skip the arming delay flag processing entirely to avoid unnecessary state machine overhead
- This enables boards that need faster arming response (e.g. small racing drones with rapid arm/disarm cycles) to reduce or eliminate the delay
## Test plan
- [x] Verify default behavior unchanged (500ms delay)
- [x] Test with `ARM_DELAY_MS 0` in hwdef - verify instant arming
- [x] Test with custom values (e.g. 250ms)
- [x] Verify disarm behavior unaffected
(Some discussion on how to improve this slightly.)
UTC0743
master ← andyp1per:pr-lpf-baro-scale
opened 03:59PM - 08 Mar 26 UTC
## Summary
- Add `BARO1_THST_FILT` parameter (default 1 Hz) to low-pass filter … the throttle input before applying thrust-based pressure compensation
- Prevents rapid baro altitude changes during throttle transients that can cause altitude controller runaways, particularly during indoor flight near surfaces that reflect pressure waves
- Set to 0 to disable filtering and restore original behavior
## Test plan
- [x] Build ArduCopter and ArduPlane for SITL and verify compilation
- [x] Verify that with `BARO1_THST_FILT` at default (1 Hz), rapid throttle changes produce smoother baro altitude readings
- [x] Verify that setting `BARO1_THST_FILT` to 0 restores original unfiltered behavior
- [x] Test indoor flight near surfaces to confirm reduced altitude controller transients
- [x] Verify steady-state throttle tracking is not significantly delayed
Andy : Let’s wait for Leonard’s review.
UTC0745
master ← andyp1per:pr-imu-leaning
opened 03:58PM - 08 Mar 26 UTC
## Summary
- Add a new `LEVEL` bit (bit 21) to `ARMING_SKIPCHK` so the lean-angl… e check can be disabled independently from the INS check, allowing arming while inverted
- Document the previously-undocumented `OSD` check (bit 20) in the bitmask descriptions for all vehicles
- Copter's leaning pre-arm check now uses `Check::LEVEL` instead of `Check::INS`
## Test plan
- [x] Build ArduCopter for SITL and verify compilation
- [x] Verify that with `ARMING_SKIPCHK` bit 21 set, Copter can arm while leaning beyond `ANGLE_MAX`
- [x] Verify that with bit 21 unset, the "Leaning" pre-arm check still triggers normally
- [x] Verify that disabling INS check (bit 4) no longer bypasses the lean angle check
Andy : This allows arming upside-down.A : Do we actually care if we arm upside down?R : We generally don’t want to arm while not level, because in most modes this will result in an immediate abrupt reaction after arming.P : We could offload the INS checks to the INS library. And then decide what to do with the results.R : We could use an https://github.com/ArduPilot/ardupilot/pull/ifdef , since this such a rare request.Andy : That is actually a better way.
UTC0756
master ← kebni-dev:sensaition-ins-pr
opened 01:44PM - 23 Dec 25 UTC
This PR replaces our earlier #31305.
We have now added support for using the… SensAItion sensor in the INS mode, where it replaces EKF3 and performs onboard sensor fusion between its IMU and GPS receiver(s). It can also run in the previous IMU mode, where it acts as an external sensor that feeds data to EKF3.
We attach a Markdown file with suggested user instructions, to be added to the wiki if the PR is accepted:
[SensAItion_description_for_Ardupilot_wiki.md](https://github.com/user-attachments/files/24311449/SensAItion_description_for_Ardupilot_wiki.md)
Tests performed:
- Unit tests for the parser pass.
- SITL tests pass:
- IMU test: SensAItion is set to be Primary IMU
- INS test: Similar to vectornav, microstrain and inertiallabs
- Flight tests on a Holybro Quadcopter X650:
- IMU mode: SensAItion IMU as Primary IMU and lane switching disabled. Flying was smooth and innovations were small. Tested loitering, light and aggressive maneuvering.
- INS mode: SensAItion as ExternalAHRS, ArduPilot EKF disabled. Tested loitering, light and aggressive maneuvering and autonomous following of a waypoint path.
To discuss:
- The SensAItion sensor reports altitude relative to the WGS84 geoid, but we noticed that `AP_ExternalAHRS::gps_data_message_t.msl_altitude` seems to expect the altitude above Mean Sea Level. We expect that it won't matter, since users will reset the altitude to 0 before takeoff - do you agree?
Best regards,
The Kebni Inertial Sensing R&D Team
A : Needs a small API modification to pass autotests.
MergeOnCIPass
UTC0802
master ← andyp1per:pr-fence-AGL-update
opened 05:59PM - 29 Nov 25 UTC
this allows for fence altitudes to be above ground level, absolute, origin or ab… ove home (the default and current behaviour)
This is a rebase of https://github.com/ArduPilot/ardupilot/pull/29761 which I could not push to
P : If someone changes fence parameters, old scripts which don’t take the frame into account will return wrong data which can lead to a crash.Andrew : I think this scenario is too unlikely to happen to matter.A : Let’s wait to hear from Pete.
UTC0808
master ← andyp1per:pr-coding-standards
opened 02:02PM - 16 Mar 26 UTC
## Summary
- Adds a single-reference `CODING_STANDARDS.md` document consolidati… ng all C++ formatting rules (astyle), naming conventions, type/literal rules, comment/parameter documentation requirements, memory constraints, commit conventions, Python standards, and common review feedback
- Sources: `Tools/CodeStyle/astylerc`, `.editorconfig`, `.pre-commit-config.yaml`, `check_branch_conventions.py`, `run_astyle.py`, the wiki style guide, and patterns from repeated PR review comments
- Goal: reduce recurring style comments on PRs by making all conventions explicit and discoverable in one place
## Test plan
- [ ] Review document for accuracy against current project conventions
- [ ] Verify all astylerc directives are correctly documented
- [ ] Verify commit convention rules match `check_branch_conventions.py` enforcement
- [ ] Get feedback from core reviewers on completeness
🤖 Generated with [Claude Code](https://claude.com/claude-code)
George : Is this meant to override the style guide wiki page?A : We could edit the wiki to point to this. It’s probably better that these standards are in-tree.
UTC0819
master ← andyp1per:pr-crsf-out-refactor
opened 06:15PM - 14 Nov 25 UTC
This allows CRSF to act in a similar way to SBUS Out, but bi-directional, full-d… uplex at 2Mbaud.
This can be used to drive one flight controller from another flight controller using existing rate output support.
The new protocol is 51 and so can be used by setting:
```SERIALx_PROTOCOL = 51```
This PR has been tested on Raspberry Pi's new drone, codename "Wolverine" and the work has been kindly sponsored by Raspberry Pi.
The follow-up PR relies on https://github.com/betaflight/betaflight/pull/14870 which has now been merged
Andy : CRSF is meant to be point to point. But it also has simple routing rules, where if you don’t consume a packet, you forward it to other nodes.
We could also do some MAVLink tunnelling through CRSF.
Peter : I’ll go through the PR this week.
G : I’ve found GPS*_CAN_OVRIDE doesn’t work well when there are 3 GPSs mounted.A : Yes, that’s a known issue. You can try to disable the GPS in a Here3.P : I’m working on a branch to support more GPS instances.
**Lupus the Canine: I had issues with TECS_PITCH_MIN, where its behaviour changed in recent releases, when its value is positive. See here A : Yes, that is an intentional change. If we didn’t let people know about this change, then we apologize.