- this makes sure that all motors are idling in mc mode. having this too
low can lead to a motor stopping in flight which is critical for
attitude control
- experienced loss of attitude control in RTL during descent prior to this
change

Signed-off-by: Roman <bapstroman@gmail.com>

 - vehicle_status_flags condition_global_velocity_valid is also unnecessary

If the GPS driver was used on another port (e.g. TELEM2), it would get
stuck in a `write` call and not return anymore. Disabling flow control
fixes that.

CPU usage is unchanged.

 - these are redundant with listener differential_pressure

 - move to ModuleBase
 - strip down to PWM 8 and 16 modes only
 - remove all dead code
 - implement missing pwm ioctls (current value, rates, etc)
 - default rate 50Hz -> 400Hz

air_gnd_angle is from acos(), and never return a value that bigger than
M_PI_F

To account for the parameter definition.
My tests if quadratic is actually better in practise were anyways not conclusive.

Signed-off-by: Roman <bapstroman@gmail.com>

if the vehicle doesn't land and disarm at the end of the mission, the current sequence doesn't reset to 0

the mc pos controller handle it for now

Signed-off-by: Roman <bapstroman@gmail.com>

Signed-off-by: Roman <bapstroman@gmail.com>

Signed-off-by: Roman <bapstroman@gmail.com>

When the timer callback is called at a higher rate than the logger can
execute the main loop (which is never the case under normal conditions),
the semaphore counter will increase unbounded, and eventually lead to
an assertion failure in NuttX.
The maximum semaphore counter is 0x7FFF, and when the logger runs at
default rate (3.5ms), the logger task must be blocked for 0x7FFF*3.5/1000
= 114 seconds continuously for an overflow to happen.

I see 2 cases where that could happen:
- the logger execution blocks somehow, or busy-loops in an inner loop
- a higher-prio task runs busy and hogs the CPU over a long period of time

Signed-off-by: Roman <bapstroman@gmail.com>

This gets rid of a printf.