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>
These leaks are not critical but the address-sanitizer complains.
And it's better programming practice anyway.
Signed-off-by: Lukas Woodtli <woodtli.lukas@gmail.com>
- the timestamp is only used for logging and log analysis. For that it's
important to have the timestamp when a setpoint becomes active.
- there was a consistent problem with the position_setpoint_triplet
timestamp, where the timestamp was just bogus. Timesync seems to work
correctly though. Might be a problem on the sender side?
For example here:
https://logs.px4.io/plot_app?log=41918a7d-4c1d-464d-9abe-aef2c0818d92
- Allow to use the 4 groups from Mavlink
- Allow an Offboard control of the Gimball, Gripper or servoes.
- Fixes issue #7440
Signed-off-by: Alexis Paques <alexis.paques@gmail.com>
- the uorb behavior got recently changed so that we now need to clear
any potential existing messages when we start log streaming.
- ulog_stream_ack should also not use a queue, since the ack is done
synchonous between mavlink and the logger.
Otherwise the conversion from mavlink_mission_item to mission_item
will cause the latitude and longitude of the ROI to be off by a factor of 1e7
in the case of INT mode.
Julian Oes