Only have it higher for VTOL and fixed wing.
Multicopter position controlled flight is in our experience always <1g.
Acrobatic flying definitely exceeds the acceleration but if control
doesn't rely on the GPS velocity and position there shouldn't be any
problem.
@fury1895 reported very valuable feedback from testing
the acceleration feed-forward on VTOL:
> MPC_JERK_MAX 4.5 (from 5 on it felt too aggressive)
> MPC_JERK_AUTO 4
> some hovering, some transitions, and a mission. Everything good.
> I'd say you feel the difference in position mode and you see it in
> Auto modes. Great improvement!
Previously acceleration setpoints were not executed and just used
to pass a possible rough initialization value for the next task. Now
they get executed by the multicopter controller and hence
overwriting them with rough estimates doesn't work anymore.
This mode was just kept as an example after
its usage in a single case. It's basically untested
and doesn't make much sense anymore since it's
incompatible with the jerk limited trajectory
implementations. It's implementation only switched
hte configuration parameter of the velocity resulting
from maximum stick deflection to be
MPC_XY_VEL_MAX instead of MPC_VEL_MANUAL.
This is according to todays understanding undesired
because when hitting that limit the position
controller has no room for corrections anymore.
Also it saves some flash space on omnibus to remove
the task at this point and makes romm for the
acceleration feed-forward.
Ubuntu 20.04 and latest Cygwin come with no Python 2 and no link
from python to python3. To not mess with the system we detect
python3 for seamless support.
The landing thrust limit was after the position controller and
could be inconsistent with what the takeoff limit did. This
resulted in different thrust values sequentially getting applied
during landing.
This was only necessary for stabilized mode before #10805.
The unit length thrust setpoint will anyways not be available
anymore soon because it gets replaced with the acceleration
setpoint in m/s².
These assignments were temporary for correct logging of the input
setpoint which now properly also comes out of the controller again.
This is reverting the hotfix from:
dee8d200d8
Removing the skip_controller and interfaceMapping
concept and replacing it with a single method checking
if the position control update was successful and
return the result in the PositionControl.update().
This restores original horizontal thrust setpoint execution
that I intentionally broke three commits ago. It's necessary
for correct stick to tilt mapping of FlightTaskManualAltitude.
This commit temporarily breaks direct horizontal thrust setpoint execution
which is used by FlightTaskManualAltitude. This is necessary to allow for
PositionControl cleanup namely calculating the whole velocity PID in one
Vector3f formula.
Having this in a separate commit is useful since it reduces indentation
of a bigger code block.
When having no velocity estimate the derivative was updated with zero.
When losing the velocity estimate this is fine since the resulting
derivative spike doesn't get used and acceleration is set to NAN.
But when regaining the velocity estimate the spike from zero to
the first estimated velocity gets used as acceleration in the position
controller and results in a twitch.
To solve this I use the derivative reset I introduced in pr #13522
commit b64abf48b2
This caused bad altitude control performance when enabling
terrain following. It even leads to complete vertical control
instability in case dist_bottom is inaccurate.
Relying on the estimator states is the way to go instead of
silently using one altitude source as state.
This issue was found by @khabir and reported over slack.
It resulted from the split up of the big pr #12072 into #13262.
I took over the interface while the internal states still stayed the
hard to understand internal ones. One of the follow up refactors will
fix this completely and the entire legacy setpoint restore block can
be removed.
* PreFlightCheck: remove unused reportFailures flag
* Commander: pull all pre flight checks together on the PreFlightCheck class
* PreFlightCheck: separate checks into their own files
The plot of the attitude setpoint in the log did not show any values
because the message timestamp that the position control module sets
was overwritten by the PositionControl attitude generation.
by applying it directly to the attitude setpoint which is the output of
the position controller.
The problem was that before the input to the attitude setpoint generation
was adjusted to generate a level attitude with zero thrust keeping the
heading. I refactored the PositionControl class in #13262 to directly
generate the attitude setpoint output. So here I'm adjusting the attitude
setpoint to do the exact same thing as before but without interleaving
with the PositionControl logic.
Matthias Grob