Ardupilot EU Dev Call 2024-07-24

AP_Scripting: reduce flash usage
#27630 opened Jul 24, 2024 by tpwrules
Tridge: Pete or Thomas know about this, but are not here.
Needs review from Pete.

AP_Bootloader: fix build for STM32H7 without heap
#27627 opened Jul 24, 2024 by bugobliterator • Approved
T: What board does it affect?
Sid: Andy said an H783 was affected.
T: We could automatically enable heap on all H7s.
S: What about the flash? Some have smaller sectors.
T: Oh, right. OK.

Copter: SmartRTL restores last waypoint if users switches to another mode
#27619 opened Jul 23, 2024 by rmackay9 • Approved
T: Andy had a review round.
Randy: I’d like Peter Barker to take a look.
T: Merged.

AP_Mount: Topotek safely parses version packet
#27616 opened Jul 23, 2024 by rmackay9
Break before end of version variable.
Approved.

AP_Bootloader: fix stuck in bl on reboot from firmware with network and CAN bootlaoders
#27605 opened Jul 22, 2024 by bugobliterator
T: Approved.
BotBlox binaries need an update too.

SIH glider improvements
#27589 opened Jul 18, 2024 by Georacer
G: Fix to add HWDEF and balloon going underground.
T,Peter: OK, unusual use of hwdefwrite.

Added MFT-SEMA100 Board
#27588 opened Jul 18, 2024 by EternAlmox • Changes requested
P: Too many commits.
Moving to the other call.

AP_InertialSensor: Check the gyro/accel id has not been previously registered
#27584 opened Jul 17, 2024 by joshanne • Changes requested
T: OK, backport candidate.
One failing test, probably flaky, merge on CI pass.

Do PPP networking between Primary and Secondary MCU
#27577 opened Jul 17, 2024 by bugobliterator • Changes requested
T: Where’s the default #define for that?
S: It’s an existing one.
Tested on CubeRed.
MergeOnCIPass

Double Data Rate on Cube Red with W25 DDR capable External Flash
#27574 opened Jul 17, 2024 by bugobliterator • Changes requested
S: Flags to disable small hw modules in the future.
T: Renaming to HAL_ENABLE_QSPI_DTR would be clearer.
S: Ambivalent, doesn’t give CPU improvements.
T: Better to check CPU usage via --enable-stats, and look CPU usage %.
S: That’s what I did.
T: Also, install SIM on HW and fly on CIRCLE. See how much speedup it can systain. But doesn’t run EKF.
Also the streaming debugging adaptors.
S: I have one, but Cube doesn’t have the right pins (SWO) exposed. Can try on a Nucleo.
T: Yeah, try to see the hotspots in the code and find places for improvement.
S: JLink supports it.
T: We need a pro license.
S: We have one.
T: DelayMerge tag because it might destabilize performance. Pending testing that witnesses actual improvememnt.
Could help to improve memory contention and bring allocations closer to the bus.

Do not Read FIFO faster than requested rate for ICM45686
#27573 opened Jul 17, 2024 by bugobliterator • Changes requested @andyp1per
S: Hoping for Andy to review it.
Trying to reduce CPU load.
T: Andy will most likely want to test-fly it.
Pray for rain in France!

SITL: add simulated slung payload
#27536 opened Jul 12, 2024 by rmackay9
Peter: didn’t review physics yet.
Lacks an autotest.
Randy: Still working on it.
T: Approved.
Randy: Thinking of doing a bulls-eye view as a MAVProxy module.
Using GNSS RX on module.
Active controls on the payload are too much for this specific application.

Filter: add “source” to option 5
#27535 opened Jul 11, 2024 by Hwurzburg • Approved
T: NFC, approved.

TECS: Fix airspeed control during takeoff
#27174 opened May 27, 2024 by Georacer • Changes requested
G: Rework of this PR, updated PR text.
Introduced two new parameters, TKOFF_MODE and TKOFF_THR_MIN.
T: Introduce TKOFF_OPTIONS under Plane as a bitfield. Make it an AP_int32.

Copter: choose RC channel for Transmitter Based Tuning
R: It’s failing autotests because of changed functionality.
T: Eventually I’d like to see Plane RC tuning on Copter.
PB: That’s our oldest PR!
Some small “best-practices” issues.
T: @author to change the failing autotest, then it can be merged.

Quicktune C++ conversion (WIP)
#27578 opened Jul 17, 2024 by MichelleRos • Changes requested
T: Leonard do you want to talk about your alternative issue?
Leonard: The limitation of QuickTune (QT) is that the Lua script is copy-pasted into C++.
Doesn’t embed nicely into other copter modules. It’s a bit bloated.
We could be reusing parameters.
QT can excite specifically the 180deg crossing, AT could benefit from such methods.
QT “done right” can be much better.
But we need to not lose the desired benefits of QT.
T: All that sounds like a research project.
L: Autotune (AT) could benefit from taking UX features from QT and improve (e.g. the enable/disable switch).
T: We wanted that exact QT behaviour deliberately because we only wanted to do away with the scripting dependency.
L: It’s a very compromised tune.
Michelle: That is its purpose.
T: Leonard, what you ask is a very major feature increment.
L: I think we should scrap that PR and do it properly.
The problem is that it is very standalone. It has had negative feedback and there has been no willingness to change direction.
T: Has there been negative feedback from people who run QT? All negative feedback comes from people who used Autotune.
L: The criticism is based on the implementation and architecture, not the functionality.
I would prefer to have the QT being pulled in the C++ code in a way that benefits Autotune.
T: The request was to port the Lua feature, nothing more.
R: It’s not fair to scope-creep the feature like that.
If you suggest that you and Andy will take it and reform it, that’s cool.
But it’s not fair to have Michelle work on it for the next 6 months.
L: The PR puts a very low bar on itself.
R: QT works great on many many vehicles. AT has crashed many vehicles.
T: Applets are supposed to be production-ready code.
R: Granted, putting it into C++ is a higher bar than an Applet.
T: I want QT in because it helps users tune all around the world.
L: All concerns raised were dismissed bluntly.
QT has safety holes in it. It is not ready to fulfill the role of a basic (not high performance), stable tuning solution.
If we put it in, it’s there forever.
T: No, it’s a tuning system. We can update it without breaking people’s crafts.
I want to start with something that we know works. We can work on it later.
We shouldn’t hold off using that functionality in view of future perfection.
T: Leonard, what is the scenario that can lead to a crash?
L: Hovers fine, but a disturbance throws it into an oscillation.
T: Is that because the rate gains are low?
L: No, because they run out of power, the UA doesn’t have the authority to enact the acceleration request.
T: QT is a rate tuning algorithm right? It does its job.
L: Yes, but in that sense it can’t replace AT.
T: Sure, and from there they can go to AT. Or stay there if they are happy with the tune.
R: Is it a reasonable request to ask QT to handle angle_p and accel?
What more would be needed in this PR?
T: I don’t want to roll that in in the first version, it requires a lot more infrastructure.
L: I’d like to see the feature request on porting QT and start there. Not from the Lua script PR.
AT did have an easier UX in the past.
M: We don’t want to add features like excitation, because that’s what causes quadplanes to crash.
L: AT is a time-domain tool.
QT is a freq-domain tool and requires lower inputs.
In a craft with optimal tune, QT can result in too high excitation and result to a crash.
R: Adding twitches to QT is a step too far, because it has been an issue in the past.
L: I’m looking to add controlled noise in this feature.
T: Why can’t that be added in a future PR?
R: Is there a list of additional requests that you have Leonard?
L: There is an open ticket to gather feedback for tuning aircraft.
I’d like to find out what the real requirements are for this kind of tuning. The real requirements have really changed.
R: So you want to have a moment to pause and consider the place of AT and QT in our system.
L: Yes
(Discussion on AT-QT mechanisms)
George: Is there a way to decouple this PR from Michelle, if she so wishes? There’s such a thing of working on something for too long.
T: It can, if Michelle wants it, but I’d rather not steal her thunder.
(Discussion on AT-QT mechanisms)
(Discussion on P-I ratio on QT)
L: I want a justification on the P-I ratio and a discussion on it.
R: We don’t have any more time this week. We’ll have to let it go.
Continue the discussion on the issue page.
Please write answers in nice, concrete sentences.