There were accidents because when missions lead through an obstacle
and it should be avoided but the setpoints from the external obstacle
avoidance module are suddenly missing the mission is continued into the
obstacle which results in a crash.
PositionControl: update comment about the order of thrust and position
mc_pos_control: reset setpoints to NAN if required
MulticopterLandDetector: consider to be landed if vehicle is not armed
mc_pos_control: initialize landing struct with landed
mc-pos-ctrl: adjust thrust-setpoint and yaw during ground-contact/maybe-landed without capturing
that information within vehicle-local-position-setpoint topic because that information
does not belong to user intention
PositionControl: set local position/velocity setpoint to NAN if not used in the control pipeline
mc-pos-ctrl: Fill vehicle_local_position_setpoint_s structure as follow:
The message contains setpoints where each type of setpoint is either the input to the PositionController
or was generated by the PositionController and therefore corresponds to the PositioControl internal states (states that were generated by P-PID).
Example:
If the desired setpoint is position-setpoint, _local_pos_sp will contain
position-, velocity- and thrust-setpoint where the velocity- and thrust-setpoint were generated by the PositionControlller.
If the desired setpoint has a velocity-setpoint only, then _local_pos_sp will contain valid velocity- and thrust-setpoint, but the position-setpoint
will remain NAN. Given that the PositionController cannot generate a position-setpoint, this type of setpoint is always equal to the input to the
PositionController.
mc_pos_control: switch to designated initializer for landed
It's less error prone because it produces an error on every discrepancy.
- landing_gear: refactor state name
- Add the keep state to the landing gear message
- Adapt FlightTaskManual, FlightTaskAutoMapper, mc_pos_control,
to review message definition
Necessary because NuttX defines pollfd differend from
the POSIX standard. The difference of field order makes
use of C++ designated initializers to compile for both
platforms impossible.
If the landed state was set before the position controller starts it
would get updated with the first poll_subscriptions() anyways. But it's
not on all posix and nuttx platforms I tested and the deleted statement
just copies the zero message into the struct which is already zero.
* attitude and rate setpoint message: use 3D array for thrust demand
* FixedWingAttitudeControl: rework airspeed scaling
* move airspeed and scaling calculation into separate method
* if vtol in hover and airspeed disabled use minimum airspeed instead of trim airspeed
- better in terms of dependencies:
- the position controller code depended on position topics for yaw
- mc_pos_control does not have to be run for Stabilized mode
- the code path is much simpler, and thus less error prone. This is
especially important since Stabilized is often used as a fail-safe flight
mode.
Previously when switching e.g. from stabilized from acro, the stabilized
flight task kept running and publishing setpoints.
Luckily it caused no problems, but the log showed arbitrary attitude
setpoints.
- move the update after the integration: a new computed jerk has an impact at the next epoch only
- add jerk reduction in case of too large integration time: when a jerk of "min_jerk" during dt is too much
- add jerk reduction if the integration time is larger than the predicted one and that integrating that jerk would lead to an acceleration overshoot
- rename some variables
* Add attitude sub to mc_pos_control for yaw usage.
* Initialize pos control _states struct.
* Remove unnecessary init for struct in mc pos ctrl.
* Only use att topic for yaw setting in FlightTask.
Matthias Grob