* Revert "mavlink_mission: don't retransmit automatically"
This reverts commit 4e008fe89120e24e321e93fb551753242797f022.
* mavlink_mission: don't retry to send mission item
The mission items need to be requested one by one by a ground station.
This is a "pull" protocol and we should not retry to "push" the mission
items down.
If we do this we can trigger the situation where the autopilot keeps
retrying and the ground station does not time out because it keeps
receiving items (even though the items are the wrong ones).
* mavlink_mission: reduce retry timeout
When actively re-requesting lost mission items, we can be more agressive
and therefore lose less time when a mission item is lost on the way.
This is an attempt to fix mission upload and download with QGC on a
lossy link. The way it should work according to the protocol on
https://mavlink.io/en/protocol/mission.html is that in general
the ground station should be concerned about timeouts and
retransmission. This means the autopilot does not need to retransmit by
itself but just answer requests.
This seems like it would make the transfer less robust, however, it
actually resolves an edge case where QGC fails to make requests because
it gets spammed by the autopilot and keeps resetting the timeout.
The debug messages are too verbose to be run in a production vehicle and inherently were something that should only be run in SITL / debug sessions on hardware. Switching the flag to the PX4_DEBUG() macro does not only make this more explicit, but also saves a lot of flash space that otherwise was consumed by the strings.
- avoids race conditions when geofence data is updated in flight. During
a transfer, the geofence module will not check for violations, which
is done with the new dm_trylock method.
- there is an update counter stored in dataman, and for each write
transaction this is increased, so that the geofence module can reload
the data upon data change (after it's unlocked).
- single dm item updates are atomic already, so resetting the polygons
to 0 does not need locking.
- retrieve & store the geofence & rally point data from/to dataman
- interleaved transmissions (of different types) are not possible. trying
to do so will NACK the new transmission
- only one storage backend for polygons & rally points (not alternating
between 2 as the mission does)
* navigator/mavlink: always send last reached item
Since we can't rely on mavlink that every message arrives, it makes
sense to continuously send the last reached waypoint.
* navigator: don't report reached for takeoff
If a takeoff waypoint has been inserted, we should not report that we
reached a mavlink mission item because we actually have not.
Daniel Agar