Before (introduced in 7b16c3482d), there was no colon after
the `R` argument in the options specification string (ab:R).
The R should be followed by a colon, because in indicates that
the R option requires an argument, which it does.
So I added a colon.
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.
- gencpp in PX4/Firmware (d5fb89ee02): 7e446a9976
- gencpp current upstream: ff6c9f3e8e
- Changes: 7e446a9976...ff6c9f3e8e
ff6c9f3 2019-11-11 Jochen Sprickerhof - Two patches to make the generated headers reproducible (#42)
e12443e 2019-03-18 Dirk Thomas - 0.6.2
d227d17 2019-03-18 Dirk Thomas - update changelog
e233144 2019-03-15 Martin Pecka - Added plugins the ability to also generate free functions. (#40)
40559af 2019-03-04 Dirk Thomas - 0.6.1
96ec7f1 2019-03-04 Dirk Thomas - update changelog
1. Move Pixhawk Mini to FMUv3, due to it's using Rev.3 chip, has 2MB flash, and fmuv3 bootloader.
2. Add CUAV V5+ to FMUv5
3. Add CUAV v5 nano
4. Add CUAV Pixhack v3 to FMUv3
Make sure is the hardware URL only on user guide master branch or not
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.