AP_NavEKF: Allow EK3 cores to run different sources

[rishabsingh3003]

By setting EK3_SRC_OPTIONS, this PR allows different EK3 cores to have different sensor sources. As an example, when the correct bit is set, First core will use the sensor set corresponding to EK3_SRC1 Second core will use sensor set corresponding to EK3_SRC2 And so on..

[tridge]

@rmackay9 please review

[rmackay9]

This looks great, but what happens when a Lua script attempts to change the source set? we could just ignore these requests or we could change the lane

[tridge]

@rmackay9 will review alignment code

[rmackay9]

Let's test that the existing functionality works in SITL (e.g. without the new option being set)

1. SITL test switching between GPS and Vicon and ensure the existing bit leads to a jump when switching from Vicon->GPS but not GPS->Vicon. See dev wiki here.
2. Confirm there is no jump when switching from Opticalflow->Vicon

BTW, this enhancement means that if the new bit is set and one EKF core/lane is using GPS and the other is using visual odometry, visual odometry will never be reset to match GPS even if the core using visual odometry is not the active core. I suspect we will get requests from users to align the visual odometry to GPS if the core using visual odometry is not the active core.

[rmackay9]

Hi @rishabsingh3003, looks like we need to rebase this on master now that your other PR https://github.com/ArduPilot/ardupilot/pull/29213 has gone in

[rmackay9]

I've created a rebased version here with a small fix to the alignment logic when using optical flow https://github.com/rmackay9/rmackay9-ardupilot/tree/rishabh-ek3-src-mix

[rishabsingh3003]

@rmackay9, could you force push on top of my branch? I'll give it a test. Thanks a lot for the help.

[rmackay9]

Hi @rishabsingh3003, ok, pushed over top of this PR. I'm also testing to see if I can find any issues

[rmackay9]

I've squashed the commits and rebased on master