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.
- rename flight tasks to use camelCase
- add core tasks to flight tasks cmake
- add additional tasks in targets (TODO)
- add templates
- generate hpp and cpp which contain all specified tasks
The handling for vehicle commands inside the FlightTasks library
was already there but commented out because the previously used
MAVLink messages were tied to the specific application we used and
there was no clean common message definition. Because there is now
a well defined message for the orbit task I'm uncommenting and using
the working message handling again here.
FlightTaskAuto: add type that corresponds to triplet type
FligthTaskAuto: set all setpoints if invalid in xy
FlightTaskAuto: cast triplet type to WaypointType
FlightTaskAutoLine: class for px4 legacy auto
FlightTaskAutoLine: methods prototype
FlightTaskAuto: change sp to wp (=Waypoint)
add params
FlightTaskAutoLine: follow waypoints along line based on flight state
I realized that instead of using the setpoint setters inline
in real world tasks everyone started to have its own setpoint
member variable and only call the setter in the end for all the
privatly generate setpoints. This makes the setter useless and
therefore I switched to member setpoints in the architecture.
They bring more felxibility which is obviously needed but also
less structure which is the price to pay.
