Attendees (unique) : 6
UTC0704
master ← peterbarker:pr-claude/ahrs-wind-driving
opened 06:51AM - 17 Jun 26 UTC
### Summary
Drive wind-estimation-via-triangle from within DCM rather than fr… om Plane
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [x] 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
Previously ArduPlane called AP_AHRS::estimate_wind from its 10Hz GPS
update loop. Drive it from AP_AHRS_DCM::update instead: when a new
GPS sample arrives with a 3D fix - the same gate ArduPlane applied -
DCM feeds its GPS velocity and attitude into the wind triangle.
Because estimation is now triggered per new GPS sample rather than by
a fixed-rate vehicle task, rate-limit estimate_wind to 10Hz internally
so the wind-triangle filter time constant stays sane regardless of GPS
rate.
This puts the wind-estimation trigger next to the data that feeds it,
in preparation for other backends driving their own wind estimates
from their own velocity/attitude samples.
I'm pretty sure we should adjust this to remove the 10Hz limit and instead process for every GPS sample received. But for now we keep existingis behaviour.
Peter : This is preparation to let other estimators to have other (new) estimators to wind-triangle estimation.
Approved!
UTC0712
master ← peterbarker:pr/ahrs-move-ekf-start-code
opened 03:16AM - 16 Jun 26 UTC
### Summary
Move "start the EKF, but on a timeline" code into the relevant AP… _AHRS_NavEKFx backend.
### 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 16 16 * 16 16 16 16 16
Hitec-Airspeed * *
KakuteH7-bdshot 16 16 * 16 16 16 16 16
MatekF405 16 16 * 16 16 16 16 16
Pixhawk1-1M-bdshot 16 16 16 16 16 16 16
SITL_x86_64_linux_gnu 0 -4096 0 0 0 0 0
YJUAV_A6SE 16 16 * 16 16 16 16 16
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
revo-mini 16 16 * 16 16 16 16 16
skyviper-v2450 16
speedybeef4 16 16 * 16 16 16 16 16
```
### Description
Moves the EKF startup code out of the update function in the EKF into the update function on the individual backend.
This helps to make the `update_EKF2` and `update_EKF3` methods look much more similar to the identical `update_SITL`, `update_DCM` and more similar to `update_exernal`. All of these AP_AHRS methods will go away and we'll be using iteration in the future, but this bespoke code has to go first.
I've broken out a boolean `start` function to hold the start logic. I'm not convinced that we need to a bunch of this stuff, and @rishabsingh3003 has been trying to reduce startup times. At least it's a bit more broken out now so perhaps we can actively sense what the EKF is up to and decide to `InitialiseFilter` depending on the EKF's state rather than a fixed timeout. IIUC some of the delay was due to weird sensor data coming in early in the boot process, so perhaps that's no longer an issue.
The one major structural change is that we will populate the backend results regardless of EKF start. Our flows for determining an active EKF type are very strict about not letting the backend become active when its EKF has not started, so the notify call will never be made. The results will similarly be unused at the moment, but we should probably set attitude-valid etc to one of `results.healthy`, `results.started` or `results.initialised` before we restructure the backend selection code (this may become very important when DCM can be entirely compiled out so there *is* no fallback estimator!)
P : EKF1 was using DCM to initialize the filter. From 3 and forwards they bootstrap themselves. Apparently we wait for a couple of seconds to let the sensors warm up.
Merged!
UTC0716
master ← CSmith1539:can-bounds-check
opened 06:34PM - 08 Jun 26 UTC
### Summary
AP_MAVLinkCAN converts the requested CAN bus to a signed inte… ger in some functions, which can cause an out of bounds access before the `hal.can` array, more details blow. This change adds a lower bounds check where it is treated as a signed index.
### 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
- [X] Logs available on request
Tested with the reproducible script below with ardupilot running in SITL with gdb to verify that the change now blocks the under-read from happening.
### Description
Currently, `AP_MAVLinkCAN::_handle_can_forward` translates the requested CAN bus to a signed index:
`const int8_t bus = int8_t(packet.param1)-1;`
However, there is no lower bounds check before accessing `hal.can[bus]`. There is an upper bounds check for `bus` and a NULL check for `hal.can[bus]`, however certain negative values for `bus` pass the NULL check and cause a segmentation fault on the later call to `!hal.can[bus]->register_frame_callback(...)`
The change rejects a `bus < 0` after the existing case of `bus == -1` to prevent this error.
`AP_MAVLinkCAN::_handle_can_filter_modify` contains the same signed index translation, but doesn't actually use it to access any memory apart from the NULL check, so I decided to leave it out of this change.
To verify this issue, I created this script, which reproduces the fault running SITL on master. I tested all of the main vehicles which all produce the same error.
```
from pymavlink import mavutil
import time
mav = mavutil.mavlink_connection(
"tcp:127.0.0.1:5760",
dialect="ardupilotmega",
)
mav.mav.command_int_send(
0, # target_system
0, # target_component
0, # frame
32000, # command, MAV_CMD_CAN_FORWARD
0, # current
0, # autocontinue
244, # param1, bus == -13 after int8_t conversion
0, # param2
0, # param3
0, # param4
0, # x
0, # y
0, # z
)
time.sleep(10)
```
I decided to make a pull request instead of an issue since it is a very minor change, however if this was the wrong call let me know and I can close the pull request and open an issue instead.
Approved!
UTC0719
master ← peterbarker:pr-claude/can-filter-modify-negative-bus
opened 09:20AM - 16 Jun 26 UTC
### Summary
### Classification & Testing (check all that apply and add yo… ur 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
In the same vein as https://github.com/ArduPilot/ardupilot/pull/33376
A malformed CAN_FILTER_MODIFY message with a bus value of zero produces bus == -1 after the off-by-one adjustment. The existing bounds check only tested the upper bound, so hal.can[-1] was dereferenced before validation. Add a lower-bound check, matching the fix applied to MAV_CMD_CAN_FORWARD.
P : Similar to the one above.
UTC0721
master ← peterbarker:pr-claude/pr/dds-races
opened 01:50AM - 05 Jun 26 UTC
### Summary
Several fixes to the DDS test suite to avoid the flapping we've h… ad for years
### 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
- be more careful about when we treat connections as open
- retry opening connections on startup (rather than just at runtime)
- adjust the sitl binary process to exit immediately when ros2 wants it to to prevent socket binding port reuse race condition
Merged!
UTC0722
master ← AI-ZCG:feature/board-siyi-unifc-6-pico
opened 07:08AM - 02 Jun 26 UTC
### Summary
### Classification & Testing (check all that apply and add yo… ur own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [x] 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
- [x] Logs attached
- [x] Logs available on request
### Description
#### 1. Ran ardupilot\Tools\scripts\build_all.sh, and the compilation was successful, as shown in the image below:
<img width="1851" height="1007" alt="build_all" src="https://github.com/user-attachments/assets/7d31701f-fd6b-4d18-9784-b2de360308b9" />
<img width="1851" height="1007" alt="build_all2" src="https://github.com/user-attachments/assets/418e3449-25e5-4239-80a4-bf6ee11fcef8" />
#### 2. Performed a SITI simulation, and the runtime log is as follows:
[sitl_log.zip](https://github.com/user-attachments/files/28496865/sitl_log.zip)
#### 3. Flashed firmware onto the flight controller hardware for testing, and the ground station uses MissionPlanner.
##### 3.1 All onboard sensors were detected normally.
<img width="875" height="556" alt="HW_ID" src="https://github.com/user-attachments/assets/dd7cacae-b91c-4ee1-a13c-13c4c724a478" />
##### 3.2 IMU Calibration
<img width="800" height="547" alt="IMU_Calibration" src="https://github.com/user-attachments/assets/43ac203a-1fa0-4f44-93b7-e1615c787403" />
##### 3.3 Compass Calibration
<img width="895" height="583" alt="Compass_Calibration" src="https://github.com/user-attachments/assets/990096fa-429f-447e-8156-be61b2e99dd9" />
##### 3.4、HUD,Battery,GPS,IMU0 and IMU1 are all functioning normally
<img width="946" height="809" alt="HUD_BATT_GPS_IMU" src="https://github.com/user-attachments/assets/6fd2aa6a-59b9-40bd-82f9-aadde2a88bfa" />
##### 3.5 UART test
Set all other UART protocols to NONE, set the UART to be tested to GPS, and then move GPS to the output of each UART. All UARTs work normally.
<img width="981" height="551" alt="Serial" src="https://github.com/user-attachments/assets/30f1f4af-74a1-4893-9733-04f13cef664c" />
3.6、Servo test
Connect each output terminal to the test servo and set the output settings to RCIN function in turn. Then operate them one by one using the remote control. All 14 channels work normally.
<img width="797" height="563" alt="RCIN" src="https://github.com/user-attachments/assets/39fe075c-5672-4b70-a499-d420a1a00d60" />
Andy : I think 8 channels will work, but it’s his board.Andrew : Claude says compass orientation is wrong and baro masks are wrong.
Merged due to an itchy trigger finger.
UTC0727
master ← peterbarker:pr-claude/clang-scan-ratchet-param
opened 02:37AM - 30 May 26 UTC
### Summary
Removes a clang-scan-build warning of a zero-length VLA.
### C… lassification & 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 -48 *
Durandal -64 -56 * -56 -64 -56 -64 -56
Hitec-Airspeed -48 *
KakuteH7-bdshot -56 -56 * -64 -56 -64 -64 -56
MatekF405 -56 -56 * -56 -56 -56 -56 -56
MatekH7A3 -64 -64 * -64 -56 -56 -64 -56
Pixhawk1-1M-bdshot -56 -56 -56 -56 -56 -56 -56
SITL_x86_64_linux_gnu 0 0 0 -4096 0 0 0
YJUAV_A6SE -64 -56 * -56 -64 -64 -56 -64
f103-QiotekPeriph -40 *
f303-MatekGPS -48 *
f303-Universal -56 *
iomcu *
mindpx-v2 -56 -56 * -56 -56 -56 -56 -56
revo-mini -56 -56 * -56 -56 -56 -56 -56
skyviper-v2450 -56
speedybeef4 -56 -56 * -56 -56 -56 -56 -56
```
### Description
Code flow actually means a zero-length VLA can't happen at the moment.
convert_old_parameter(), convert_class() and _convert_parameter_width() each declared a stack buffer sized by type_size() of a runtime parameter type. type_size() can return zero (AP_PARAM_NONE/GROUP, or an unknown type), which makes the array a zero-length VLA - undefined behaviour - and VLAs are non-standard C++ in any case.
Replace the VLAs with a fixed buffer sized via a union of every storable parameter type, so it is always large enough without assuming which type is largest. In _convert_parameter_width() the buffer size had been used as the EEPROM read length, so read type_size(old_ptype) bytes explicitly now that the buffer is no longer exactly that size.
This clears two clang-scan-build core.VLASize findings
There is an alternative fix which is for callers to these methods to pass in the length of the type e.g.
```
g.terrain_follow.convert_parameter_width(AP_PARAM_INT8);
```
becomes
```
g.terrain_follow.convert_parameter_width(AP_PARAM_INT8, 1);
```
There is another alternative fix which is to suppress the clang-scan-build warning entirely and trust that we will never return 0 from the get-size-of-this-ap_var_type method. If we ever did then bad things will happen.
FWIW the `union` here was my idea, don't blame claude for that bit :-)
A : Claude says there might be a buffer write overflow.P : I’ll look at it again.
A : Should I start posting my LLM-generated reviews on the PRs?Michelle : As long as it’s not very long and there aren’t lots of false postiives.George : Given that some comments are on the noise margin, please make it clear that these review points aren’t all required to be addressed. I’m happy for it to be there as an advisory.P : Please only for DevCallEU.
UTC0751
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)
George : Fixed the recommendations.P : Still has a few CI failures.
UTC0757
master ← gokhan-iha:Check-1.0.1
opened 06:16AM - 15 May 26 UTC
### Summary
- Added new GPilot P1 Autopilot.
- 100hr+ Real-Time fly tests do… ne succesfully. (Plane & Copter)
- -40C ~ +105C Ambient Temperature tests done succesfully.
- Rough vibration tests done succesfully.
### Classification & Testing
- [X] Checked by a human programmer
- [X] Non-functional change
- [X] 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
- [X] Logs available on request
### Description
- Added hwdef.dat, hwdef-bl.dat and default.parm files of GPilot P1
- Added bootloaders of GPilot P1
- Added README.md
- Added Photos and Pinout Diagrams
P : The LLM comment re. a DSHot firmware without a DSHot bootloader seems correct.A : I think it’s a blocking bug.
UTC0803
master ← andyp1per:pr-msp-power
opened 07:15PM - 12 Apr 25 UTC
### Summary
Control an MSP video transmitter (HDZero, ~~Walksnail~~, ELRS bac… kpack) from the flight controller — band/channel/frequency, power and pitmode — and report status to HD goggles.
### Classification & Testing
- [x] Checked by a human programmer
- [x] Automated test(s) verify changes (autotest `MSPVTXConfig`, `MSPDisplayPortVTXConfig`)
- [x] Tested manually, description below (SITL)
- [x] Tested on HDZero hardware (also tested on Walksnail and DJI but these appear not to support control)
Tested on an HDZero air unit + goggles on a TBS_LUCID_H7: band/channel, power and pitmode are all settable from the FC and confirmed by retuning the VRX; goggle-side channel changes coexist (push-on-change).
### Description
Adds MSP as a VTX control transport alongside CRSF/SmartAudio/Tramp, selected per-transport via the new `VTX_TYPES` parameter.
Two MSP VTX models are handled:
- **ELRS-backpack style** — the FC sends `MSP_SET_VTX_CONFIG` to the VTX.
- **HDZero/betaflight style** — the VTX is the MSP master. It polls the FC and, on finding a `"BTFL"` FC reporting `deviceIsReady=0`, uploads its own config and power table, then stops polling and expects the FC to push `MSP_VTX_CONFIG` on change. The FC reports not-ready until that handshake completes, then pushes changes (repeated for delivery, as the air unit doesn't report state back to confirm).
The FC identifier now matches the selected OSD symbol set (`BTFL`/`INAV`/`ARDU`); selecting `DISPLAYPORT_BTFL_SYMBOLS` is what enables HDZero VTX control. `MSP_OSD_CANVAS` is answered so HD goggles size their grid, and an `MSP_OPTIONS` bit holds the VTX at high power when disarmed.
Andy : You wouldn’t want this feature in all 2MB boards. It’s an additional 1500bytes.
But perhaps we can auto-enable it for boards that define the VTX protocol in a port.
P : We can probably do that, yes.Andy : Shall we add it to the hwdef parser?P : No, let’s avoid such magic and change all hwdef files.
UTC0819
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.
Andy : We need Randy for this one.P : We’ll test it in the weekend.
Please ensure that the new ground effect simulation is off by default. It can break other tests subtly.
UTC0833
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`
Andy : I tried periodically resetting the baro offset in Copter and it doesn’t work nicely.
With the reset, learning of the accelerometer bias is far too slow.
A : I like periodically resetting to avoid the sudden alt. jump during arming.P : I would also like it if we adopt the Plane behaviour and reset Home continuously while we are disarmed.Andy : This PR has been open for far too long. If Randy agrees, I’d like to stop making changes here.
A : Please try plotbeta.ardupilot.org .
Ceasium is now asking for a lot of money to continue using Ceasium-Ion, so I removed it and rolled out a custom terrain DEM server.