- if less than 6 sides are calibrated, keep the existing calibration and
update the offsets and scales
- if 2 sides are calibrated, estimate the offsets only (as this is enough
if a full calibration was done already, and the problem is not
constrained enough to estimate scales and offsets)
So it is independent from the number of configured sides.
Previously, each side would take longer if less than 6 sides were
calibrated.
Also fixes a bug: calibration_sides was used before it was updated, leading
to different behavior on consecutive calibrations with <6 sides.
Fixes a serious bug in combination with the HMC5883 driver (also used for
HMC5983): this driver estimates a scale in MAGIOCCALIBRATE and applies it.
The calibration routine does the calibration with that scale applied, and
then overwrites it, without considering it in any way.
Most other mag drivers only do some measurements and perform some checks
in MAGIOCCALIBRATE (but the result is just ignored).
It's not required to take that many samples, 1 second is enough.
This is confirmed by looking at the standard deviation over 10 calibrations:
it is in the same order as with 20 seconds (the effect of temperature
increase has a bigger effect).
As a convenience we send down the amount of do jumps left to do.
However, we should not send the mission item if happen to be in the
middle of another transfer.
This fixes the warning:
Mission storage: Unable to read from microSD
which appeared on do jump mission items. The reason was that the
_mission_type can be set to rally or geofence if that was the last
transfer which had happened earlier. Therefore, it would then try to
read a certain rally item from dataman when really a mission item was
supposed to be read.
The navigator has a notion of resetting the triplets which means the
triplet setpoints are set to invalid and therefore not to be used by
downstream modules such as flight tasks.
However, before this patch, the triplets were not published if invalid
meaning that a valid triplet would stay the truth until a new valid
triplet would get published.
E.g. this lead to the corner case case where we publish a valid triplet
with an IDLE setpoint on ground in HOLD and then don't update the
triplet while flying in POSCTL mode. Later, when RTL is engaged, the
flight task will use IDLE until navigator (which runs slower) has
published the next triplet.
The fix involves two main changes:
- Publish invalid triplets to avoid stale triplets.
- Avoid publishing the triplet on every iteration in manual modes by not
setting `_pos_sp_triplet_published_invalid_once = false`.
When testing this I realized that a mission upload during RTL would stop
RTL. This is because the mission is updated while the mission navigation
mode is not active and reset_triplets() is called from there. This is
now only done for the case where we are actually in mission navigation
mode. The fact that a mission is updated when not active also seems
wrong and is something to fix another time.
Exclusive open is not required, but we now need to ensure the queue size
is set atomically.
It avoids a race condition between 2 single-instance advertisers,
where one of them would fail to open the node with -EBUSY.
Possible race conditions (they all happen between the check of existence
of a topic and trying to create the node):
- single instance, with multiple advertisers during the first advertise:
both advertisers see the topic as non-existent and try to advertise it.
One of them will fail, leading to an error message.
This is the cause for telemetry_status advert failure seen in SITL in
rare cases.
- multi-instance: subscription to non-existing instance -> px4_open fails,
and the subscriber tries to create the node. If during that time a
publisher publishes that instance, the subscriber will get (instance+1)
(or fails if the max number of instances is exceeded).
This is a race that goes pretty much unnoticed.
- multi-instance: 2 publishers can get the same instance (if is_published()
is false in case both have not published data yet).
This can also go unnoticed.
Therefore the patch changes where _advertised is set: it is now set
directly during the advertisement instead of during publication.
Daniel Agar