Removed negative sign from _takeoff_ramp_vz_init

[roangel]

Describe problem solved by the proposed pull request
If the initial _takeoff_ramp_vz_init value is negative, as it is now in master, the takeoff ramp will go from that negative value to the parameter 'MPC_Z_VEL_MAX_UP', which is positive:
https://github.com/PX4/Firmware/blob/e0f3fc8d00850292a8309416574b34f6fbabaaa3/src/lib/FlightTasks/tasks/FlightTask/FlightTask.cpp#L141

In mc_pos_control.cpp we assign the output of this ramp to constraint.ramp_up:
https://github.com/PX4/Firmware/blob/e0f3fc8d00850292a8309416574b34f6fbabaaa3/src/modules/mc_pos_control/mc_pos_control_main.cpp#L579

Which is then used in PositionControl.cpp:
https://github.com/PX4/Firmware/blob/e0f3fc8d00850292a8309416574b34f6fbabaaa3/src/modules/mc_pos_control/PositionControl.cpp#L229

Negative values in constraints.speed_up make no sense, that's why I think that this negative sign might be a bug.

[bresch]

@roangel Thanks for reporting this. I checked the code and in fact, the negative sign makes sense. The logic is the following:
The velocity PID controller has a feedforward of "hover thrust" in order to operate in a 0g environment. If we directly activate the controller during takeoff with a velocity setpoint of zero, the thrust would suddenly jump to hover thrust. To prevent that behavior, we compute the velocity setpoint that would lead to zero thrust. Since the output of the controller (ignoring I and D) is (vel_sp - vel) * P + hover_thrust, assuming zero velocity (vel = 0), vel_sp = - hover_thrust / P is the setpoint that generates a 0 thrust.