* Revert "EKF: Release flow speed limit with altitude gained"
This reverts commit e70206f74b.
* Revert "fix code style"
This reverts commit 76bf70121c.
* Revert "Reverse the linked list of data_validator_group and maintain a first node"
This reverts commit 32482e7644.
* fix typo
* EKF: use baro if it was reset to baro from ev
* EKF: set vert_pos_reset if resetting to ev hgt
otherwise the position controller will not reset the setpoint -> leading to unwanted altitude changes
Gate size class variables should not be initialised to zero, because it will cause a /0 error if fuseVelPosHeight() is called before they are set to their respective parameter values.
When GPS use is gained whilst flying using optical flow data, the sudden release of the speed limit is unannounced to the operator and can cause unexpected acceleration.
This patch releases the speed limit as height is gained, but does not reduce it when the vehicle descends, unless GPS use is lost.
This enables the EKF to use an additional NE velocity measurement. This can be used to improve position hold stability when landing using a beacon system for positioning by fusing the beacon velocity estimates.
Apply a dead-zone to the vertical position innovation if using baro for height and if in the ground effect region during and just after takeoff.
Method needs to be activated externally.
Turns off automatically after 10 seconds or if specified height gained.
When magnetic field states have been reset in-flight using a single sample, the magnetic field states are not used to constrain heading drift for a period after the reset. This period has been shortened from 10 to 5 seconds which is enough time to average out the effects of measurement noise (the original concern). The shorter time has enabled the previous practice for RW vehicles of using magnetic heading in that time period to constrain yaw drift to be discontinued. This is necessary becasue while magnetic heading is being used, it fights the yaw corrections obtained from GPs observations and lengthens the time required to recover from a bad mag calibration.
If state errors were large before the reset, then failure to reset the covariance matrix terms can result in incorrect fusion of position and velocity measurements after the reset due to inconsistencies in the covariance matrix.
When performing the initial in-flight mag yaw reset for RW vehicle, do not reset the quaternion states and corresponding variances unless there has been a change in yaw angle large enough to cause problems with navigation.
This is because the state estimates after a reset are more vulnerable to transient sensor errors, so a reset should be avoided if possible.
When performing the initial in-flight magnetic field reset for fixed wing vehicles, resetting the quaternion states and their corresponding covariances should be avoided unless yaw errors are large, because state estimates are vulnerable to transient sensor errors immediately following a reset.
Ensures that a complete reset of velocity and position states will always be performed if yaw has had to be reset using GPS velocity.
Ensures that the yaw_align status cannot be set to false once the filter has aligned.
Reduces susceptibility to incorrect estimation of acceleration bias during sustained yaw rate.
Requires an increase in RAM allocation of 837 Bytes to allow for the longer IMU and output predictor buffers that can be created.
Use of air data to navigate should be classified as dead-reckoning because neither ground relative velocity or position is observed directly and errors grow faster.
* Unfortunately, due to the SWIG dependency, we need sudo to install on
Travis (conflicts when adding with debian-sid source prevent using addons)
which means we cannot use the container-based infrastructure anymore.
* Building the Python bindings requires g++5 (at least with -Werr set).
* When building the Python bindings on Travis, the numpy includes are not found
by cmake, so they have to be added separately by running a Python process with
`numpy.get_include()`
* The build script now (somewhat clumsily) depends on the RUN_PYTEST environment
variable. If it is set to anything other than "", it will make the tests and
run tests and benchmarks
* Add requirements.txt file with required Python packages
* Read requirements.txt from CMakeLists.txt to check dependencies and alert the
user if necessary.
* Add SWIG interface definition (and external numpy interface) to ecl classes
* Add section in CMakeLists.txt to build Python bindings and execute
Python-based tests
* Write (property-based) tests that show the basic functionality of the Python
bindings and the EKF (using pytest and hypothesis libraries)
* Write minimal benchmark for the EKF update (using benchmark plugin for pytest)
* Add plotting utilities to analyze tests
* Add lint script to keep the Python scripts clean
* This is a sane choice (and should arguably always be done for classes with
virtual methods to avoid undefined behavior)
* It is required for wrapping the EstimatorInterface with SWIG (without virtual
destructor, deriving from the EstimatorInterface leads to
-Werror=delete-non-virtual-dtor).
When starting aiding using EV only and commencing GPS aiding later, this change means that the GPS origin is set to the local position 0,0 point rather than the current vehicle position. This avoids large changes in local position when GPs aiding starts.
Fuse external vision data using a relative position odometry method when GPS data is also being used and enable both GPOS and EV data to be fused on the same time step.
Moves calculation only required for mag heading fusion into the if (_control_status.flags.mag_hdg) branch
When using EV yaw, the observed yaw angle is calculated directly from the EV quaternions using derived expressions from references in code comments.
This enables the initial uncertainty to be set based on application and also ensures that the max allowed growth in wind state variance is consistent with the initial uncertainty specified.
- when switching to range finder use the current terrain estimate as
height sensor offset, otherwise spikes in the range measurements could lead
to a wrong offset
Signed-off-by: Roman <bapstroman@gmail.com>
- do not subtract the height sensor offset variable when computing the
baro offset from the local origin. The baro height offset is calculated
when baro is not fused and so the height sensor offset used in that case
is associated to another sensor and has nothing to do with the baro.
Signed-off-by: Roman <bapstroman@gmail.com>
the primary height source
- moved height control into single function in order to decide which sensor
should be used for estimating height
- under certain conditions allow to use the range finder to estimate height
even if it's not the primary height source
- fixed a bug where the delta time for the baro offset calculation was always
zero
- use methods to set height control flags to reduce code duplication and
to prevent bugs
Signed-off-by: Roman <bapstroman@gmail.com>
Paul Riseborough
ChristophTobler
Paul Riseborough
ChristophTobler
Daniel Agar
CarlOlsson
Peter Dürr
Isaac
Roman