* 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.
Ubuntu 20.04 comes with no Python 2 and no link from python to python3.
To not mess with the system we just use cmake's detection for seamless
python3 support.
The PX4/libuavcan "px4" branch is tracked to DSDL commit 192295c. This commit is not present in the "master" branch for DSDL, but is present in the "legacy-v0" branch.
rc.io is called from 2 places in rc.interface:
- if [ $OUTPUT_MODE = io -o $OUTPUT_MODE = uavcan_esc ]:
- 'set OUTPUT_MODE io' is only set within USE_IO=yes, so removing
the check in rc.io has no effect.
- in case of UAVCAN, we also want the IO for RC, now covered in the next
case.
- Further down ('Start IO for RC input if needed.').
This is intended to start IO for RC only, when fmu is already started.
However the previous check '$USE_IO = yes' in rc.io prevented that.
In addition we don't start rc_input in case of $USE_IO = no.
Fixes no RC on Pixhawk 2 with SYS_USE_IO=0.
When not building for testing, test_mixer_multirotor is not available
and causes a waraning with cmake 3.17:
This project specifies custom command DEPENDS on files in the build tree
that are not specified as the OUTPUT or BYPRODUCTS of any
add_custom_command or add_custom_target:
test_mixer_multirotor
TSC21