Ardupilot EU Dev Call 2024-09-04

Development Team
1

Attendees (max): 12

UTC0704
Amilcar: Pylint comprehensive but slow. Ruff fast but more limited, like flake8.
-First run Ruff, then pylint.
Running Ruff against ardupilot/Tools/*.py, caught 2 or 3 valid things. These were supposed to be flake8 clean.
Andrew: We don’t want two tools, that’s too much of a burden.
Am: Then use Ruff only. It’s very fast.
A: Tried bare pylint on Tools/*py, it was a lot slower. Lots of output.
-Let’s stay with Ruff.

UTC0719
Merged!

UTC0721
Andy: Perhaps we could give them their own CubePilot target for the IOMCU code.
A: It consumes flash space. BDShot builds very low on flash space.
-We need testing on the timing.
Sid: I’ve tested that, it’s only a few microseconds.
A: BDShot cares about those microseconds. We need to properly test it.
Andy: I’ll test it, it’s not a problem.
A: CubeOrangePlus with bdshot will run out of flash quite soon.
-We could start building with -Os.
Discussion on the custom build server and potential UI upgrades to handles more features more seamlessly.
Andy: I tried Link-Time-Optimization. Managed to save 50k of flash on the examples, but not build Ardupilot.
A: I haven’t managed to build Ardupilot either.
-It also prevents debugging.

UTC0842
We need to revert the other EKF units revert.
We’re waiting for the PR DFReader: fixed handling of multlipiers from FMTU and MULT by tridge · Pull Request #965 · ArduPilot/pymavlink · GitHub to get fixed.

UTC0850
A: What about this new forced-reset feature?
George: I introduced this to prevent some bad bahaviour when both pitch and throttle are forced.
A: This might hide some underlying bug. Let’s test a bit more on what this actually achieves.
-What happens to the integrators if we don’t?
-I also see a change in the pitch during a rolling takeoff.
-For a rolling takeoff WITH a takeoff, you don’t check for the existence (and reading) of an airspeed sensor.

UTC0827
Merged!

UTC0834
Peter: This is in preparation for the SPA06 sensor.
A: The downside is that it will break any pending PRs with hwdef.dat.
-It also gets us on a losing track, where we are trying to predict all future names and compatibilities.
P: We can have generic driver names and more specific driver names. Or switch to a driver_v1, driver_v2 scheme.
A: We have done this for Invensense, because they were the most volatile in naming. But we haven’t done this as a rule.
-It brings more complications than good. It would be much simpler to add a comment on the driver file to mention the new sensor support. This can then be searched in the codebase.

UTC0853
A: The network issues they had are probably fixed by now.
-We’d better ask them to test again, if I can’t find the board they sent me.
(Shuffling noises while Andrew digs up layers of board heap history)
Dig up attempt was unsuccessful.
Mallikarjun: We haven’t tested recently.
A: Can you send me a photo, so that I can try to find it? Apologies for the long delay on this PR.

UTC0904
Merged!

UTC0907
Peter: I told them we would build the artifact ourselves.
Merged!

UTC0909
A: This puts pressure to keep supporting MAVLink v1.
Merged!

UTC0914
G: Let’s hold off for now, needs the other TECS PR.

UTC0915
MergeOnCIPass

UTC0915
A: Randy has to approve.

UTC0916
P: This does save bytes of flash. Not 100% sure if it’s the elimination of the “=” that does it.
A: I don’t like this pattern.
P: Yes, we had a bug in the past and adopted the current pattern.
-I can do the experiment with only deleting the “=”.
A: We could send a pragma directive to the compiler to use -Os for AP_Arming.cpp.
-Same for other low-speed functionality, e.g. EKF initialization.
P: Filter resets as well.
A: I’ll leave it up to you, Peter.

UTC0925
P: The manufacturer is happy with the change. Currently it doesn’t compile for Plane.
MergeOnCIPass

UTC0928
MergeOnCIPass