This is to match a change made to Copter.
It might be relevant to sub in that users may wish to have asymmetrical descent and ascent rates.
New parameters named:
PILOT_SPEED_UP (technically renamed PILOT_VELZ_MAX)
PILOT_SPEED_DN
Removed parameter PILOT_VELZ_MAX (technically renamed to PILOT_SPEED_UP).
Modes impacted:
ALT_HOLD
CIRCLE
POSHOLD
Update a section in GUIDED mode but I don't think it is ever used but update just in case.
It will use the PILOT_SPEED_UP for ascending max velocity. For down it will check if
it is 0, if so then it will PILOT_SPEED_UP instead, if non zero it will use PILOT_SPEED_DN.
This retains current behavior and gives the flexibility to change it if desired.
The above behavior is less of a concern for Sub but to keep it consistent its been implemented it the same way.
See discussion here:
https://github.com/ArduPilot/ardupilot/issues/7331
we were getting some uninitialised variables. While it only showed up in
AP_SbusOut, it means we can't be sure it won't happen on other objects,
so safest to remove the approach
Thanks to assistance from Lucas, Peter and Francisco
AP_AHRS_NavEKF doesn't use the rangefinder, it just delegates the
calls to the right estimator.
For libraries/AP_AHRS/examples/AHRS_Test/AHRS_Test.cpp the initialization
order has also been modified to match the order on vehicles. It's more
correct since it passes a reference when EKF2/EKF3 are already
constructed, while thos constructors use a pointer. Ideally these
should be moved to an init() method though, or use a get_instance().
We should never include version.h or ap_version.h headers directly
on a header since this will trigger a complete rebuild of the
codebase when we commit to the repository. The ap_version.h header
is auto-generated containing information from the current commit.
If we include it in a header, every other file that ends up including
that header (directly or indirectly) will need to be rebuilt. No
ccache's cache beats having to do nothing when the header is just
not included.
version.h contains information that is kept on a struct inside
each vehicle. Rather than using the macros from each vehicle,
the getter should be preferred, which returns an AP_FWVersion
referente.
