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.
- publish continuously in position control mode when there's a valid
setpoint
- optionally fill in the velocity and acceleration setpoints when
available
- fixes#9841
- reorders operations, such that the most expensive one (orb_copy) is done
only when really needed.
- corner case: when the topic was not advertised yet, orb_stat() would fail
and then update() was called, which succeeds for the first advertisement.
In that case the timestamp was incorrectly set to 0 and true was
returned.
The next call would again return true, because the timestamp was updated,
but the topic data was still the same.
Reduces CPU load by ~2% on a Pixracer.
This is a more generic solution for 532a97041, and also enables it for
vehicle_command_ack's.
In addition it avoids using a timestamp for subscription update checking,
because it does not work well together with orb queuing.
Lukas Woodtli