FlightTaskManualAcceleration and FlightTaskOrbit both inherit from
FlightTaskManualAltitudeSmoothVel but were calling FlightTask and
FlightTaskManualAltitude respectively, skipping the intermediate
parent's overrides (smoothing velocity init, parameter chain).
Fix the DEFINE_PARAMETERS_CUSTOM_PARENT macro argument and the
activate() call to use FlightTaskManualAltitudeSmoothVel.
Fixes bugprone-parent-virtual-call clang-tidy diagnostic.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Fixes a regression from 8bae4e5c0e29f70d5d1d2427ffdef97092be939c, where
the orbit flight task wasn't an extra task (flight_tasks_to_add) anymore
and therefore the command handling wasn't generated.
There was a race condition that could cause several outcomes. The most severe
was that flight_mode_manager gets the command, switches to orbit and then
in the next iteration switches back because commander did not change
nav_state yet. When commander then switches, flight_mode_manager would still
be in the old mode.
This is prevented by storing the command (allowing it to arrive before or
after mode switch), and then apply it after the switch happens.
This is done by inheriting from FlightTaskManualAltitudeSmoothVel again.
The altitude change by command is taken care of by switching
to the apporach when the altitude difference is big enough and
switching back once the altitude is close enough.
The altitude of the command is not perfectly reached but this can
only be done smoothly when the Orbit has full control over the
altitude smoothing. The independent altitude smoothing is not kept
because it was lacking stick handling like altitude lock and smooth
transitions when opening and closing the vertical position loop.
I think they were forgotten and it leads to side effects:
- The acceleration feed-forward does not get executed
- The acceleration setpoint is NAN when initializing the altitude
smoothing when arriving at the circle
