Fixes case where a UAVCAN SensorBridge has callback channels available,
but NuttX / uORB does not have an additional driver / topic instance
available.
* EKF: Enable GPS flight without magnetometer
Enables takeoff in a non-GPS flight mode with mag fusion type set to MAG_FUSE_TYPE_NONE. After sufficient movement the EKF will reset the yaw tot he EKF-GSF estimate. After that GPS fusion will commence.
* EKF: Fix unconstrained yaw and yaw variance growth when on ground
* EKF: Ensure first yaw alignment can't be blocked
* EKF: Increase yaw variance limit allowed for alignment
Flight test data indicates that an uncertainty value of 15 deg still provides a reliable yaw estimate and enables an earlier alignment/reset if required.
* EKF: Remove unexecutable code
* EKF: Restructure heading fusion
* EKF: parameterise quarter variance check and retune default value
* EKF: Pass by reference instead of pointer
* EKF: Clarify reset logic
* EKF: Remove incorrect setting of mag field alignment flag
* EKF: Non-functional tidy up
* EKF: Fix non-use of function argument
The updateQuaternion function was using the _heading_innovation class variable instead of setting it using the innovation argument.
* EKF: Fix undefined variable
* EKF: Use single precision atan2
* EKF: remove unnecessary timer reset and unwanted execution of reset function
* EKF: Don't declare a mag fault when non-use is user selected
Doing so produces unnecessary user alerts.
@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.
Julian Oes