| Commit message (Collapse) | Author | Age |
|
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
Stores 32-bits for all of the flight parameters. Uses 64-bit
intermediates for kalman computation.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
|
| |
This has some known flight data and generates kalman filter
information for them to test
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Finally found a couple of decent references on how to set the model
(process) error covariance matrix. The current process matrix turns
out to be correct for a continuous kalman filter (which isn't
realizable, of course). For a discrete filter, the error in modeled
acceleration (we model it as a constant) needs to be propogated to the
speed and position portions of the matrix.
The correct matrix is seen in this paper:
On Reduced-Order Kalman Filters For GPS Position Filtering
J. Shima
6/2/2001
This references an older paper which is supposed to describe the
derivation of the matrix:
Singer, R.A., “Estimating Optimal Tracking Filter Performance for Manned Maneuvering Targets,”
IEEE Transactions of Aerospace and Electronic Systems, AES-5, July 1970, pp. 473-483.
This change has a minor effect on the computed correction
coefficients; it should respond more reasonably to acceleration
changes now.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
Because speed and acceleration are scaled by 16, it's fairly common
for the kalman terms to end up larger than 1. Instead of trying to
fuss with 16-bit values and shifts, just use 32-bit values.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This generates the constants needed to implement Kalman filtering in
the flight firmware.
Signed-off-by: Keith Packard <keithp@keithp.com>
|