instead of the derivative of the vertical position which is
not the same value when using the ekf2 estimation.
Using the position derivative resulted in delayed landing because
the value for some reason often bumped over the theshold before
slowly converging towards zero while the velocity was within expected
accuary in all these cases.
system_state.fmu_data_received_time can be set from an IRQ handler, thus
we need to ensure every read access to it in mixer_tick is atomic.
So we read it once and copy it into a local variable.
This avoids casting errors. An alternative to `std::round` would be to
add 0.5 before casting for positive values and subtract 0.5 before
casting for negative values.
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.
In 5bb9babc20 I made MAVLink send a
rounded up integer instead of rounded down. This makes sense in practice
because the low battery reactions happen exactly when the reported number
switches in the UI. But here we want to provoke an exact 50% in the UI so
we stop counting at 49.9%, it get's rounded up and we see the expected
result.
In 3e6e1f5c2b the simulated battery
percentage was reversed. I'm assuming because of the possibly
missleading variable name. Now I'm fixing it by switching the
maximum and minimum voltage such that the name is not misleading anymore
but it still works as expected.
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.
Daniel Agar