This is done to allow proper initialization of the new FlightTask and
give it a chance to continue the setpoints without discontinuity. The
function checkSetpoints replaces the setpoints containing NANs with an
estimate of the state. The estimate is usually the current estimate of
the EKF or zero.
The transition FlightTask also provides an estimate of the current
acceleration to properly initialize the next FlightTask after
back-transition. This avoid having to initialize the accelerations to
zero knowing that the actual acceleration is usually far from zero.
the vehicle yaws towards the next waypoint before accelerating. This is
required for drones with front vision and aerodynamic multicopters such
as standard vtol planes or highspeed multirotors.
The linear mapping from position error to cruise velocity is changed by
a combination of that linear mapping and a nonlinear function containing
the maximum acceleration and jerk to avoid overshoots at waypoints due to
overoptimistic breaking distance.
This is done to avoid generating large yaw changes when the velocity
vector is small; for example when switching into loiter or reaching the
last waypoint.
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.
* match max vel in col-prev to regular pos ctrl
* change warning criterium to avoid float error
* disable push back from obstacles
* use floats consistently
It wasn't possible to fly faster than cruise speed even if planned
in the mission.
Limiting the planned cruise speed is necessary because
the smoothed trajectory mission plans to the _mc_cruise_speed and
if that's higher than the maximum it gets capped for safety by the
position controller and the result is a jerky flight.
Daniel Agar