to get rid of derivative spikes when navigator is
continuously updating the yaw setpoint in the
triplet for a POI but is running at a lower rate.
The proper solution is to generate that yaw setpoint
with high rate in the flight task and have the triplet
just guid to the next waypoint at low rate.
to allow descending by stick for reliable land detection.
Issue:
Stick smoothing gets completely reset to state when not taken off
-> downwards velocity setpoint is gone when not taken off
-> in_descend flag of land detection is never true when not taken off
-> when landing but falling out of landing it landing detection fails
bafore taking off and landing again
I usually called it using `source arch.sh`
but if it's executable it could also be called using `./arch.sh`
and that's also what's done for the ubuntu setup script.
Because based on the numerous complaints it was disabled by default
(only velocities above 10m/s were limited)
and since then no one intentionally used it anymore. But
there were some minor investigations of drones not reaching
their maximum speed which always showed 10m/s.
The same way like in loiter. This should be further unified in the code
but at least we can increase safety in the case the takeoff altitude is
very high and the vehicle never reaches it but looses links.
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.
Matthias Grob