In a deterministic way with clear states to go through.

The velocity ramp had problems with:
- different vehicle tunings resulted in the start value of the resulting
thrust ramp staring either higher and lower than zero thrust.
lower -> delay of beginning
higher -> small jump at beginning
- when a task set position and velocity at the same time during takeoff
(which AutoSmoothVel does) it resulted in a velocity setpoint
jump at the end of the ramp because the additional velocity
setpoint correction from the position controller was not considered.

The thrust ramp should now be very deterministic:
- always start at zero
- always end at the curreant thrust setpoint output
of the complete position controller

AutoSmoothVel - Override checkTakeoff with task-specific logic and reactivate z axis with downward velocity to takeoff smoothly

The initial idea of the flight task architecture was that
a task can freely set it's setpoints and doesn't have to
worry about takeoff and landing. It would just takeoff
when it's landed and there's a setpoint to go up and
land when it puts a setpoint that pushes into the ground.
With the takeoff logic there are some significant interface
problems depending on the way a task is implemented:
From the setpoint is not high enough to trigger to
an unexpected takeoff because of some estimator
fluctuation affecting the setpoint. It's easiest to solve this
by allowing the task to determine when a takeoff is triggered.
If no condition is implemented by default a task is not
allowing a takeoff  and cannot be used to get the vehicle
off the ground.

After boot the user is in manual mode and if he has an RC
but doesn't switch out the thrust gets set to the throttle stick
position. When he then starts a takeoff from tablet the thrust is still
high while arming and the land detector immediately sees a takeoff
skiping smooth takeoff from the position controller.

according to @dagar's review comment.

- start from a velocity setpoint pushing into the ground
to ramp from idle thrust up.
- start with a bit higher velocity setpoint threshold to make
sure the vehicle has a chance to really get off the ground.
- calculate ramp slope from initialization setpoint to the desired one
instead from zero to the desired. this ramps up quicker when you demand
a very small upwards velocity like the AutoLineSmoothVel and
ManualPositionSmoothVel tasks do at the beginning.
- don't stay in the takeoff ramp depending on the land detector, this
is unnecessary.

The comments and variable names were partly misleading.
I grouped all members, hopefully gave them more
understandable names and adjusted the comments.

There were two rather confusing function calls one to check
if smooth takeoff needs to be ran and one that updates it.
I combined them and documented the interface correctly
making the parameters non-reference const floats.

This tries to make the visibility.h header clearer and better
structured. We don't actually need the ifdef for lockstep enabled or
disabled because that's now handled elsewhere.

Co-Authored-By: Matthias Grob <maetugr@gmail.com>

Add jerk parameter for auto mode MPC_JERK_AUTO. Specify when a parameter is only used in a certain manual or auto mode

timeout is an int, so it wraps when the poll timeout is >2147ms.
This happened in logger, resulting in poll never returning.

For now we need to ignore this warning which GCC 9 shows for the MAVLink
headers.

GCC 9 complained about stringop-truncation which is a cautionary message
to prevent using strncpy with non-null terminated strings.

We can fix this by copying one byte less than the destination size and
then manually adding the null termination, as we already do.

visibility.h is included globally in PX4 via cmake compile flags.
It contains poisoning the exit() command which is used by gtest
to close the test application. Removing the flag for gtest compilation
fixes the compile error:
gtest.cc:4757:7: error: attempt to use poisoned "exit"

* VTOL trans: changed that now in transition for both MC and FW the corresponding (correct) attitude controller is running
* attitude setpoint for stabilized mode is generated by tailsitter.cpp
* reset yaw setpoint during transition to avoid big yaw errors after
transition back to hover
* VT_TYPE parameter: added "reboot required" metadata

    - ecl in PX4/Firmware (fa1fbed24633aef7985a128ebd4d19a7f6a4d108): https://github.com/PX4/ecl/commit/c4492b17c1d7bb9b74011efa9890452b091421e8
    - ecl current upstream: https://github.com/PX4/ecl/commit/a27a43eafa8f4dd514e89984f5394260a36ea4f6
    - Changes: https://github.com/PX4/ecl/compare/c4492b17c1d7bb9b74011efa9890452b091421e8...a27a43eafa8f4dd514e89984f5394260a36ea4f6

a27a43e 2019-05-01 Hamish Willee - Fix up link to EKF docs
3f69189 2019-04-04 Mohammed Kabir - EKF: control: stop vision yaw fusion on timeout

Commander initially publishes a tune_control topic set to 0, which can
interfere with the startup tone (as happening on the Pixhawk Cube).

To be able to still infer the direction of the thrust vector we
limit it to a minimal length even if MPC_THR_MIN is set to zero.

Note: This is a hotfix for certain specific applications.
The direction of the thrust vector in this corner case is very
likely to get into the tilt limit which is generally undesired.

A low gyro cutoff is needed for most medium/large size drones as the structural natural and blade-pass frequencies are low.
A higher value is still desirable for small platforms surch as racers
or well isolated autopilots and should be tuned by the user.
Specific values for config files are untouched.
The cutoff filter for the D term is disabled here as the required
cutoff frequency for the default D term of the rate controller is higher
than the gyro cutoff. In that case, enabling the D term cutoff would
just add some undesired phase lag to the derivative.

It looks like the atomic builtins are not available using QuRT and the
Hexagon toolchain, so our best bet is to use `volatile` for the atomics.