Even after we clear a mission the vehicle's current waypoint number remains intact. This state of affairs can continue indefinitely.
This patch moves us to reboot the vehicle before checking the current sequence number is zero.
top level parameters don't have flags, but we need to fill in the
flags return field as otherwise we can refuse to set a parameter based
on it being internal and the allow_set_via_mavlink() check
this allows multiple groundstations to perform FTP operations at the
same time, making FTP much more useful in multi-GCS environments or
when a companion computer wants to use FTP
we're really only after gross changes here, and that's taken care of by the three cases which are tested.
CI is getting values of 82 or 83 vs what I get on my machine here. Vagaries of race conditions getting into this state, I believe.
it needs to be a constant so that when the user changes TRIM_THROTTLE (eg. via DO_CHANGE_SPEED or via the parameter) that it doesn't change the tuning of their PID loops by changing the speed scaler. The aircraft could either start oscillating badly or could become very sluggish in control
Slope treatment for a flight leg was conditioned to a minimum height of
20m (which was a hardcoded value and only documented in a comment in the
code), below which an immediate altitude change was performed for that
leg. This caused unpredictable results for flight plans with waypoints
at exactly 20m followed by a climb, as the aircraft could, depending on
chance, be above or below the height demand, resulting in very different
trajectories.
This commit addresses that issue with the following changes:
- Added a parameter to control the minimum height at which a gradual
climb slope can be performed. This documents the original feature and
retains the safety aspect of it.
- Changed the behavior when below said minimum height to only
immediately climb up to the safe height, regaining the intended climb
slope afterwards. This leverages existing code for recalculating climb
slopes, provides a good balance between safety and following the
flight plan as intended, and fixes the core issue of different
trajectories being taken based on random external factors.
Fixed a bug where, if the "shake to launch" functionality is configured,
a crash would instantly be detected after the final acceleration event.
The issue occurred because if a minimum acceleration threshold was set,
a crash was detected if the aircraft wasn't flying immediately after
reaching that threshold. This holds for single event acceleration
launches but usually not when "shaking to launch".