ArduPilot EU Dev Call 2025-04-02

Attendees (unique): 16

UTC0704

Merged!


UTC0705

Andrew: A better pattern on the ifdefs to gate parameters would be welcome.


UTC0709

Sid: We notice this on CubeRed and CubeNode mainly. About 0.1% chacne of happening, e.g. on an untimely power cycle.
A: We don’t maintain two copies in two sectors, so you can’t rely on a backup. What we do is copy and compact a second parameter sector when the first is full. So this PR will end up wiping your paramaeters.

  • But this looks like an improvement in general.

S: I did some testing. And I’ll do more for what you said about the parameters erasing.
A: I think this might break boards that have uneven sector sizes, such as the F4s.


UTC0723

Andy: I’ve flown the change this week.
A: It would be nice in the future to consolidate the fence checks across vehicles, they’re quite common.

Randy: We used to have issues with a client when we ran some custom SmartRTL code. Its priority was one above the UART reads, that it killed the GPS driver.
A: Understood. But this is very unlikely to happen in this case we have here. Perhaps still possible, though? You mean that the fence check won’t run if it doesn’t have enough cycles?
R: No, the other way around.

  • How about the numerous millis() calls at the entry of run_checks() at 1000Hz?

A: The calls are on a low priority thread, so if the CPU time isn’t available, they won’t run.
Andy: I tested this on a 4kHz copter and didn’t see any such issues.
A: We should schedule this for testing in Canberra.
R: A better name for the entry function would be welcome.


UTC0855

A: Would be nice to have it a custom build.
Tools scripts → Build options → Add a line for Loweheiser.
Also for extract features.
Then set the define to >2048.

A: Let’s ask for Peter’s review.


UTC0805

Andy: This tries to prevent setting the speed to 0.


UTC0808

Andy: I’ll do a review too.


UTC0812

Andy: I’ll review that too.


UTC0813

Merged!


UTC0814

A: Creating separate drivers would probably mean that if a board vendor swaps for a sensor of the same family, it won’t work anymore.


UTC0817

A: Needs testing.


UTC0822

Merged!


UTC0823

Merged!


UTC0825

A: Left some comments, unsure how this PR helps.


UTC0829

A, Peter: We’re unsure what the purpose of this PR is.


UTC0832

P: Did you test on a CubeBlack? It’s very low on CPU and you just withdrew its -02 into -0s.
A: Okay, I’ll do that.


UTC0837

Andy: This is a very recent board.
A: We can enable the software pullups, but they’re the wrong value, thus we could get wrong data sometimes.

  • But since that board is only in Beta, I guess it’s fine?

Merged!


UTC0845

Merged!


UTC0846

Merged!


UTC0847

Merged!


Discussionon airspeed sensor redundancy.
P: Right now, if a sensor fails high, the whole AP_Airspeed library will be rejected by the EKF.
A: Indeed. We could be doing a median filter across 2 sensor and the DCM synthetic airspeed.
P: With affinity we would still have redundancy, right?
A: Indeed, yes.

  • Another thought is that a blocked Pitot might produce more agreeable airspeed innovations in a lane than a working one. We should keep this in mind.

Tested Cube Black with -Os. Was performing ~10Hz slower and 10% more CPU load. So reverted back to -O2.