The case where the airframe maintainer wants to enforce a reset to airframe is
not covered anymore with the `param set-default` mechanism. For products based
on PX4 this is still required to ensure proper functionality after a major update.
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
* a request for setting the '_HASH_CHECK' parameter is handled differently
than the same request for a standard parameter. Make sure we don't actually
try to set the parameter.
Signed-off-by: Roman <bapstroman@gmail.com>
This change has two effects:
1. We always acknowledge a param write no matter if the value was
actually changed or not. This is according to the spec:
https://mavlink.io/en/services/parameter.html#write-parameters
2. This fixes the bug where int32 parameters were not actually acked
because the memory of the param value was casted directly to float
and then compared. In the case of a int32 parameter set from 0 to 1
it would mean that the cast to float of the memory representation
was still 0 and therefore it was assumed to be "no change" and the
ack was omitted.
hash check and heartbeat forwarding
- hash check disabling: for systems where a companion link forwards messages
to QGC (e.g. via LTE) parameter streaming will be stopped as soon as QGC
sends the request to stop the stream. If the companion side for some reason
still requires the stream to be active we need to disable QGC from stopping
the stream. Normally dronekit should be responsible for filtering out the
request from QGC but apparently this is not possible.
- disable heartbeat forwarding: dronekit does seem to get confused if
heartbeats from another system other than the autopilot get forwarded to it.
Example: Sending messages from QGC via the autopilot to dronekit running on
companion computer.
Signed-off-by: Roman <bapstroman@gmail.com>
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.
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 further speeds up param loading.
On Pixracer via USB, it's possible to send up to 11 at once before the TX
buffer gets full, so there is still enough free bandwidth left.
We buffer the mavlink messages and don't forward them directly
via uORB. This solves an issue where many requests are dropped and
QGC does not start properly in combination with UAVCAN devices.
