ArduPilot EU Dev Call 2025-12-10

Development Team
1

Attendees (unique): 7

UTC0700

Merged!

UTC0707

Peter: The reset after use flag now isn’t getting reset after use, it’s used multiple times in the loop.
George: It’s meant to be used “once” per loop, not per use.

  • But now I’m a bit worried because the flag is used now both for the update control loop and the update 50Hz. But I think it’s ok.

Merged.

UTC0718

Merged!

UTC0719

Merged!

UTC0719

Merge on CI Pass.

UTC0723

Andy: I’ll review.
P: You should be able to set BOARD_SAFETY_ENABLE_DEFAULT and save yourself some memory, instead of setting it in the defaults.parm.

Merge on CI Pass.

UTC0729

Andrew: The subname LH is missing an underscore.
Peter: Not acting on NaN on the temperatures, means that the EFI might be powered off and we need to get off STOP and into IDLE, so as to turn the EFI on again.

UTC0748

Randy: There’s really no need for any mode to use GPS, if another position information source is available.

  • It’s not nice UX to have to disable the GPS cheks.

P: Why is GPS special; we could be checking for general location availability, there’s no need to be specific about it.
R: We do extra checks for GPS health, and these should not apply when AHRS doesn’t use GPS as its source.
Matt: This is very specific for the application, we probably need an option to ignore the GPS health during prearm checks.
P: Regarding the GPS checks, why not set HDOP_GOOD to 0 in order to ignore the check?
R: A user doing optical flow, they shoulnd’t be messing with irrelevant parameters.
P: It feels wrong to reach to AHRS and ask for its solution source, in order to decide on whether it’s okay to arm or not.
Andy: For Copter we might not have another way to do it correctly.
P: EKF3 is not the only AHRS source we support. How about external estimators?
R: As a counter argument, we are already doing this with use_compass().
P: Why is this specific to Copter, and not QuadPlane too?
Andy: Fair point.
P: It would be nice if the GPS checks were re-worked from Copter to up higher.

UTC0821

R: I’ll have to test this again.

  • Why are we changing this again?

P: Because this sanity check now triggers true negative in the autotests.

UTC0825

Needs a little more work.

UTC0828

A: I don’t understand what the frame number has to do there.
Andy: We had the IMU based on time, while they need to check whether the simulation is progressing in frames.
A: Wny not have a flag in SITL_State that is set in SIM_FlightAxis, to indicate whether we need to do frame-locking or not.
Andy: What we’re trying to do, is check if we have advanced a frame, not whether we are on lockstep.
A: Okay… but why is frame_num a value that needs to be checked.

UTC0834

P: Why not log it all the time?
G: I agree, but Pete wanted to constrain it.
P: Ah, okay then.