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.
To avoid that multiple SITL instances have the same UUID we add the
mavlink system ID to the UUID which is sent via mavlink.
This should resolve the case where multiple vehicles show up with the
same UUID in simulation.
Note that the UUID show in `ver` will still be the same for all
instances.
garfieldG