* 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.
This change fixes a bug where hash-aware QGC using the old spec would continuously request the parameter list every time it received a mismatched hash.
The existing orb_advert_t use thoughout the code sometimes tries
to treat it as a file descriptor and there are checks for < 0
and ::close calls on orb_advert_t types which is an invalid use
of an object pointer, which is what orb_advert_t really is.
Initially I had changed the -1 initializations to 0 but it was
suggested that this should be nullptr. That was a good recommendation
but the definition of orb_advert_t had to change to void * because
you cannot initialize a uintptr_t as nullptr.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
The calls to orb_advertise were being mishandled throughout the code.
There were ::close() calls on memory pointers, there were checks
against < 0 when it is a pointer to a object and values larger than
0x7ffffffff are valid. Some places orb_advert_t variables were
being initialized as 0 other places as -1.
The orb_advert_t type was changed to uintptr_t so the pointer value
would not be wrapped as a negative number. This was causing a failure
on ARM.
Tests for < 0 were changed to == 0 since a null pointer is the valid
representation for error, or uninitialized.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
BazookaJoe1900