This was only handled outside because FlightTaks lived in the
multicopter position controller which produces the data that was
needed but now it doesn't make sense anymore to handle this
subscription separately.
It's better to have it inside the base task to have the data available
on task activation sucht that e.g. Altitude mode can take over smoothly
from Position mode.
For any normal use case where a downwards velocity setpoint is set
this works exactly the same as before.
E.g. autonomous landing, landing in Altitude or Position mode
The advantage is that the very common case where a vehicle tries
to hold a constant altitude but fails to do so e.g. during a hard brake
with too much lift the resulting downwards velocity was interpreted
as descend intent and since the vehicle already struggled to hold altitude
with low thrust and was not moving fast anymore because it was braking
this lead to a lot more false positives on certain vehicle types.
The disadvantage is that not setting a downwards velocity setpoint but
just moving the position setpoint into the ground does not result in
land detection anymore. We do not use this method of landing anymore for
quite a while. It's not recommended and I wonder if there's some rare use
case like offboard where this is done.
We could add an additional case for the specific case to land with a
position setpoint only.
The tree stages used arbitrary 350, 250 300ms totally 900ms
So this changes it to each stage to a third of the parameter.
Default it is 1 second -> 333ms per stage.
to suppress the warning message:
`xargs: warning: options --max-args and --replace/-I/-i are mutually exclusive, ignoring previous --max-args value`
when running make format.
This entire feature only has an impact if the last mode set
a huge acceleration and we have to take over as smooth as possible.
But it's stil lworth fixing.
This was an idea to be able to reinitialize on mode change e.g. from
Holde mode to Land mode which are currently all still handled by
FlightTaskAuto and don't require a task switch.
But I found out it leads to issues because the last setpoint and the
ekf reset counter state from the previous task are lost and as a result
the setpoint transition cannot be handled consistently anymore.
that prevents the vehicle from crashing with invalid setpoints or
states.
This broke with #16869 when the scheduling of the position control module
and the setpoint generation got independent. The failsafe mechanism assumed
the setpoint is overwirtten by the possibly infeasible input on every loop
iteration which is not the case anymore. As a result the failsafe reset its
histeresis based on the failsafe setpoint from the last loop iteration.
Keeping the failsafe_setpoint separate solves this issue. Note that
these setpoints to the bare minimum to keep the vehicle safely in the air
and do not suffer from sideffects ignoring the EKF reset.
The mapping itself was seprated out into a calls because it was reused
for the experimental nudging implementation.
The position resets which were handled correctly before now
change the wrong setpoints and I adjusted.
The nudging has to be before any filtering, then these member setpoints
which are essentially copies are not needed anymore.
The velocity setpoint of the position controller
does a jump when unlocking position with a non-zero position error.
This is solved by using the velocity setpoint feedback to smoothly
take over.
This allows to still fly missions completely without RC
but reacts if RC is lost during the mission because
the safety pilot expects to be able to take over.
Instead of directly doing the link loss reaction which by default is RTL a delay
can be configured such that the drone first switches to hold and waits
for the link to be regained.
in workspace settings. This comes down to user preference
and there's no particular reason to change this based on the workspace.
I found it confusing to have this non-default behavior
just for PX4 editing.
Moving the command handling to a separate function that gets called
whenever a vehicle command is available to always react on commands
and not just when already a task is running.
This solves e.g. commanding an Orbit when in Staibilized.
It is important that setpoints get initialized with NAN and not overwritten
if specifically set by a successful flight task execution. It's then
clear if any setpoints were intentionally and successfully set.
Crucial for the position controller's emergency failsafe and the
seamless setpoint handover to the next flight task.
Matthias Grob