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.
and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
This avoids casting errors. An alternative to `std::round` would be to
add 0.5 before casting for positive values and subtract 0.5 before
casting for negative values.
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.
* 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.
Instead of using a timeout to resend a mission item, we should directly
send the mission request again. This is needed because we removed the
automatic resending which lead to troubles.
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)
Julian Oes