This is also from the older version of the generator.
Note that as documented, some of the equations have been removed and
rearranged slightly as it is assumed their terms are zero. Additionally,
the result is taken as the sum of the diagonal entries of the matrix.
It's from the older version of the generator as well.
Update variable names in the real code to be the same as the generated
code. Skip generation of the unused alternate form of the equations.
Delete `acc_bf_generated.cpp` as we know exactly how to generate it now.
Requires digging up old versions of the generator script.
The equations have been rearranged somewhat after generation to choose
the appropriate method but they do match overall. The auto-substitution
of the power functions caused slight changes to the generated syntax so
we make those to the real code as well.
Delete `yaw_generated.cpp` as we know exactly how to generate it now.
Validated that the generated code matches exactly the code in AP_NavEKF3
(except for the early exits).
Delete `covariance_generated.cpp` as we know exactly how to generate it
now (and it was out of date anyway).
Document exactly which versions were used when generating the code.
Sympy is the most important so it is explicitly checked.
Also add an alternate generate script which uses `nix-shell` to make it
convenient to automatically use these versions.
Add a shell script to run the generate_1.py file. Foresight tells us
that we will need multiple such files.
Also ignore the generated code files as they are already out of date and
we are aiming to document provenance and make them unnecessary anyway.
this is only used in one place, and that place is called from the same routine setting the persistent state. The only other place which calls readIMUData shouldn't be running the prediction step, but mmay, depending on the previous setting of the prediction step.
We are not initialising this state on filter reset, so it's possible that the state will be set when we do an InitialiseFilterBootstrap, which is probably not desired
The previous method resulted in data incest and fusion of predicted airspeed on every EKF internal time step.
This was not apparent during flight where the vehicle was turning, but during long straight legs did not constrain along track drift.
Make it user selectable.
Remove potential for a race condition between decisions based on latest data and the EKF fusion processing which operates on a delayed time horizon. This is achieved by preventing data entering the buffer if awaiting checks to pass ensuring that no EKF fusion time horizon processes can use data that hasn't passed checks.
Log the waitingForGpsChecks class variable
These changes enable the EKF to use the last observable wind velocity vector estimate to synthesise an airspeed measurement if operating without an airspeed sensor and when all other measurement types that can constrain velocoty drift are lost. This enables the EKF to use dead reckoning to continue after loss of GPS when there is no air speed sensor fitted and without the need to set a default airspeed value.
The logic used to fuse a default airspeed value has also been cleaned up and the call to FuseAirSpeed() from inside SelectBetaDragFusion() has been removed.
AP_NavEKF3: Fix error in default airspeed observation variance
AP_NavEKF3: Enable shadow fusion of airspeed when sensor is disabled
The offset generated by the EK3_OGN_HGT_MASK parameter bit 2 option is applied to the baro or range finder sensor so it does not have to be applied to the local position height.