If mavlink_log calls follow close after each other a later one will
replace the previous one. Therefore do a quick usleep to get the
calibration status out the door.
This moves the mavlink_log interface from ioctl to uORB and enables the
mavlink statusmessage output for Snapdragon. The API changes will lead
to changes in all modules that are using it.
Instead of using a uORB topic with the calibration values published in
sensors and consumed by the DriverFramework driver wrappers, let's just
use the the params directly. This is quite a rough change and needs
definitely some cleanup and refactoring.
This adds uORB messages to publish calibration data by sensors which is
then consumed by the sensors. Currently this is only used on Snapdragon
and guarded by QURT ifdefs.
This reverts commit 213cdf1a91.
Raising the stream rate of param values had the nice effect that
receiving the params became really quick. However, on the downside it
set all other streams pretty slow. This needs to be fixed differently.
The recent workaround to flag all params as used did not include
param_for_used_index(). However, this function got used in the case if
one param had not been received by QGC and was requested by its index.
This avoids the need to modify the source code to hard-code the IP when
broadcast doesn't work.
Initializing the sockaddr_in structs with memset is unnecessary because
they are value-initialized by the Mavlink constructor.
If the ekf has not completed alignment or encounters a serious error that produces NaN's on the attitude states, then the control, attitude and position topics are not published
The control topic is published first to reduce latency
On Snapdragon we can't yet use the "used" mask for parameters and
therefore need to send all of them down to the ground station. All
params were set to used in an earlier commit but the count and index
function didn't reflect this change. This is fixed now, therefore we can
successfully receive all params in QGC.
Julian Oes