it's a lot more readable and battery draining stops exactly at the empty battery voltage which makes debuging easier because it's directly predicatable
In rare circumstances, the buffer size was too small by 1 byte, leading
to a param export failure. And leading to a reset of all params!
This could only happen when the last saved param was a float.
Also the realloc_ok initialization is not needed.
Some modules call this (and maybe in rare circumstances), which could lead
to stack overflows. With our current headroom of >= 300bytes, 256 should
be ok.
This increases the export time from ~28ms to ~34ms in my case (on a
Pixracer)
- SYS_FMU_TASK is now enabled for PX4FMU_V4 PX4FMU_V4PRO PX4FMU_V5, but
it's only set on autoconf
- v5 companion is now TELEM2 (same as all other boards)
No functional change, but this avoids numerical issues in the check routine. Since the routine will tend to false positives, we will tend to send more param updates than required in case of numerical noise of the float representation. This is desired, as we prefer to send two updates rather than not sending one.
Volatile parameters are ones that do not represent a fundamental configuration change but rather than incrementally changing settings. These include logged flight hours or sensor offsets. Marking them as volatile avoids these parameters forcing time-consuming telemetry updates.
Parameters can change not just based on GCS request, but also due to internal code or requests by a different valid connected control authority such a cloud service. This change ensures that all connected systems get updated via MAVLink asynchronously.
This helps subscribers to understand if they should update their parameters or not. We will extend this with other flags such as the current save status and alike.
This marks the learned bias parameters as volatile (as they change in flight without external configuration) and marks them as system level, which should hide them by default from the UI
Matthias Grob