* 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>
* attitude and rate setpoint message: use 3D array for thrust demand
* FixedWingAttitudeControl: rework airspeed scaling
* move airspeed and scaling calculation into separate method
* if vtol in hover and airspeed disabled use minimum airspeed instead of trim airspeed
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.
Fixes these invalid format strings:
- A `%d` for a pointer (replaced it by `%p`)
- A 0x%08x (and a 0x%0x8!) for a pointer (replaced by %p)
- 2 cases of `%d` for a `ssize_t` (replaced it by `%zi`)
- 1 case of a %u for an `int` (replaced by %i)
- 3 cases of %d for a `long` (replaced by %ld)
- 19 cases of `%d`, `%i`, `%u` or `%lu` for a `size_t` (replaced it by `%zu`)
- An unused formatting argument (removed it)
- A missing `%d` (added it)
- A missing `%s` (added it)
- 2 cases of `%llu` for a `uint64_t` (replaced it by `"%" PRIu64`)
- 6 cases of giving a string directly as format string (replaced it by `("%s", string)`)
- 2 cases of %*-s, which should probably have been %-*s.
(Looks like NuttX accepts (the invalid) %*-s, but other platforms don't.)
- A %04x for a `uint32_t` (replaced by "%04" PRIx32)
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>
bazooka joe