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.
This issue was found by @khabir and reported over slack.
It resulted from the split up of the big pr #12072 into #13262.
I took over the interface while the internal states still stayed the
hard to understand internal ones. One of the follow up refactors will
fix this completely and the entire legacy setpoint restore block can
be removed.
* FW attitude controller, FW position controller and VTOL attitude controller subscribe to airspeed_validated topic
* add possibility to switch off the airspeed valid checks
* remove airspeed valid checks from commander
* clean up of VTOL transition logic
* Airspeed Selector: remove dynamic allocation of airspeed validators (depending on number of connected sensors) but do it statically for the maximum number allowed. Check for number of connected sensors not only during start up, but always when vehicle is disarmed.
* Airspeed Selector: change work queue from lp to att_pos_ctrl as this module is safety-critical
* add airspeed selector to px4_fmu-v2 defaults
RomanBapst