Georacer
November 20, 2024, 8:55am
1
Attendees (max): 9
ArduPilot:ArduPilot-4.6 ← tridge:pr-lua-malloc-expand-4.6
opened 08:35PM - 19 Nov 24 UTC
this is a backport of this PR:
https://github.com/ArduPilot/ardupilot/pull/2651… 7
I think this is important for 4.6 as users are more commonly relying on scripting now, and we have a vulnerability where an allocation in one heap cannot be expanded if that heap is exhausted even if there is plenty of memory in the other heap. The user has no way of knowing how the scripting allocation is spread across heaps, so they have no way of knowing if their script could fail with an out of memory condition in flight
UTC0703
Andrew : This is a serious issue.Randy : I think Pete wants us to wait a week or two.A : But it will get less testing that way.
We’ve had this issue since we’ve supported multi-heap. Likely around 4.4.
But it has gotten more severe in 4.6, because users are using more memory (ethernet, CAN and similar features).
Increasing the heap size won’t help. Fragmented memory will cause a failure to allocate the requested amount of contiguous memory.- Reminder : Scripting starts late, after the memory
R : Pete is probably saying “this should bake in master a bit, before it goes to beta”.A : We spent a lot of time reviewing this with Thomas.
ArduPilot:master ← Georacer:pr/tecs_frame_change
opened 11:53AM - 19 Nov 24 UTC
## Summary
In case where the Home altitude is changed, TECS will now not rese… t, but offset the relevant attributes instead.
## Background
Recently one of our partners flying a quadplane reported that while doing a ship landing, their plane would continuously lose altitude.
## Details
The reason is that the most minute home altitude changes [trigger a TECS reset](https://github.com/ArduPilot/ardupilot/blob/master/ArduPlane/altitude.cpp#L47). This behaviour is about 1 year old.
In the meantime, the ship landing lua script continuously [updates the home location](https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Scripting/applets/plane_ship_landing.lua#L432).
This code is ~2years old.
The combination results in the TECS constantly switching into a state of rest and becoming effectively paralyzed.
## Solution
I added a new method `AP_TECS::offset_altitude(const float alt_offset)` where TECS is made aware of the change in home altitude and offsets all internal attributes accordingly.
This is a pretty wide-reaching change, so all comments and test proposals are welcome.
## Alternatives
An alternative would be to just not reset TECS as often in case of home altitude change. But what is a "good" interval? Are we happy with TECS resetting every 10s? 20s?
Another alternative would be to just not allow the user to update home while TECS is running, but that sounds a bit silly to me.
## TODO
I need to write an autotest that emulates home altitude change and checks that the plane still flies straight.
UTC0724
A : Let’s make tests for 4.4 and 4.5 too.
Doesn’t need to have LUA script.
ArduPilot:master ← bugobliterator:pr-sched-rate-prearm-check
opened 12:22AM - 19 Nov 24 UTC
This PR adds a prearm check that ensures that we are reading gyro data atleast a… s fast as we are running our main loop, where all controllers run at. We do this for all the INS sensors that are enabled.
This avoids a situation where user might have set SCHED LOOP RATE faster than gyro poll rate or primary gyro with appropriate backend rate but forgot to do so for the rest.
UTC0732
R : What can the user do about this problem? After they get this warning.A : They can still change their IMU read rate.
It would be beneficial for the other CPU issues we have with IMUs to reduce the IMU read rate.
But racing quad users might fall into the case where the main loop is faster than the IMU read rate, hence this PR.
Andy should review this again.
ArduPilot:master ← katzfey:pr-remove-extra-initializers
opened 05:47PM - 15 Nov 24 UTC
Extraneous zero initializers for global / static variables were removed to get r… id of the following Qurt compiler warnings:
../../libraries/AP_RCProtocol/spm_srxl.cpp:78:36: warning: suggest braces around initialization of subobject [-Wmissing-braces]
SrxlTelemetryData srxlTelemData = {0};
^
{}
../../libraries/AP_RCProtocol/spm_srxl.cpp:83:34: warning: suggest braces around initialization of subobject [-Wmissing-braces]
static SrxlDevice srxlThisDev = {0};
^
{}
../../libraries/AP_RCProtocol/spm_srxl.cpp:91:36: warning: suggest braces around initialization of subobject [-Wmissing-braces]
static SrxlReceiverStats srxlRx = {0};
^
{}
../../libraries/AP_RCProtocol/spm_srxl.cpp:91:36: warning: suggest braces around initialization of subobject [-Wmissing-braces]
static SrxlReceiverStats srxlRx = {0};
^
{}
Since this data will end up in .bss and be zeroed out it does not need explicit zero initializers.
UTC0755
A : For variables at the top level the compiler is most likely smart enough to leave out the initializations.
ArduPilot:master ← Georacer:pr/vspeak_fuel_meter
opened 09:17AM - 15 Nov 24 UTC
This PR as support for the [VSPeak Modell flow meter](https://www.vspeak-modell.… de/en/flow-meter), in the form of a Lua script.
## Hardware
The manufacturer has sent me a sensor with developmental software, able to speak a plain binary packet that the script can easily receive and interpret.
It is unknown to me currently when this software will hit production.
## Implementation
I have used a Scripting EFI sensor to fill in only the volume/time and volume consumed fields in the EFI state.
Then, I advise using a battery monitor with an EFI backend to display the information and potentially act upon it.
See the attached instructions.
A : It’s best to read all at once and use the string unpack structure.Peter : Are the unit conversions correct?George : I’m pretty sure they are.
But sure, let’s wait for the user to test as well.
ArduPilot:master ← bugobliterator:pr-iomcu-profiled
opened 05:25AM - 02 Aug 24 UTC
* CPU time cost is minimal, only upto 7us per call is consumed.
* Flash and Dat… a Cost is as follows:
Before:
```
BUILD SUMMARY
Build directory: /home/sidbh/Programming/ardupilot-chibios/build/iomcu-f103-dshot
Target Text (B) Data (B) BSS (B) Total Flash Used (B) Free Flash (B) External Flash Used (B)
-------------------------------------------------------------------------------------------------------------------
bin/iofirmware_lowpolh 52404 1196 19300 53600 7836 Not Applicable
bin/iofirmware_highpolh 52404 1196 19300 53600 7836 Not Applicable
```
After
```
BUILD SUMMARY
Build directory: /home/sidbh/Programming/ardupilot-chibios/build/iomcu-f103-dshot
Target Text (B) Data (B) BSS (B) Total Flash Used (B) Free Flash (B) External Flash Used (B)
-------------------------------------------------------------------------------------------------------------------
bin/iofirmware_lowpolh 52160 1196 19296 53356 8084 Not Applicable
bin/iofirmware_highpolh 52160 1196 19296 53356 8084 Not Applicable
```
UTC0810
Merged!
ArduPilot:master ← bugobliterator:pr-reduce-loopback-test-prio
opened 10:10AM - 15 Oct 24 UTC
UTC0813
A : We can widen the pitch limits and let TECS gradually take over.G : I actually like that.
ArduPilot:master ← MichelleRos:pr/quicktunecpp
opened 07:08AM - 17 Jul 24 UTC
Add Quicktune to C++ code (conversion from the VTOL-quicktune lua script).
Te… sted in SITL, multiple multcopters and quadplanes
Edit: Tridge has added support for quadplanes and an autotest for it and made it not run for helis. I plan to add an autotest for the copter version shortly.
I have also updated the PR to limit quicktune to only alt_hold and loiter in copter, and Tridge did something similar for quadplanes.
Edit 2: Tridge updated it to make it always allocate, to be more in line with the pattern in copter, and moved it to its own thread. He also added a max attitude error, so it auto-aborts if the vehicle starts oscillating badly during the tune and made it abort the tune if the pilot changes to a mode that doesn't support quicktune. Note that it does not abort if the pilot changes between modes that do support quicktune, allowing people to, for example, do the tuning in loiter mode, then switch to alt_hold to test the tune before saving the gains.
Now tested on a quadplane as well.
As for the flash concerns, yes, it uses around 5k of flash, but autotune uses around 15k of flash, so for a tuner, quicktune is actually rather light.
UTC0823
P : Randy has a request, but he’s happy for it to go in for Plane.
Peter asked for some flash size difference results, I posted them.A : I’d prefer not split the PR in 3. But if Pete wants it to approve, I guess I’ll do it.
By the way, it makes a lot of sense to use the -Os flag for all non-time-critical libraries.
ArduPilot:master ← peterbarker:pr/reset-rtc-when-disarmed
opened 12:13AM - 10 Jun 23 UTC
UTC0841
A : It’s unfortunate that we have to change existing field names, but oh well.
MergeOnCIPass