Filtering Algorithms

This project contains three different altitude estimation algorithms: AltitudeFilter implemented in altitude_filter.py, AltitudeRateFilter implemented in altitude_rate_filter.py and AltitudeRateSmoother implemented in altitude_rate_smoother.py.

The first two ale linear Kalman filter implementations, i.e., they predict a priori altitude estimate using a current state and smooth them by calculating a posteriori altitude estimate using GPS altitude measurements together with barometric pressure measurements. The AltitudeRateSmoother algorithm is actually an AltitudeRateFilter algorithm that is first run forward in time and then backward in time on the same data. It gives results of much better quality but it is an off-line algorithm, it uses all the knowledge from the past and from the future at every point in time of filtering.

The algorithms were designed to work with measurements available on Android phones. They use GPS data obtained from Android Location objects and pressure measurements obtained from Sensor objects. These measurements are combined by the Barometric formula of the Standard Atmosphere model approximated in the troposphere range. All the constants used in that formula are taken from the Standard Atmosphere model except for the 0-altitude (mean sea level) pressure value. The mean sea level pressure is estimated by the filtering algorithms in order to obtain precise altitude values. This equation is appropriately linearized and included in the Kalman filter algorithms.

The above filters differs in the state representation. The AltitudeFilter algorithm represents the estimated state as a pair [z, p_msl], where z is an altitude and p_msl is a pressure at the mean sea level (geoid surface). This kind of representation has a very trivial Kalman update operation (which is just a propagation of a constant). The AltitudeRateFilter and AltitudeRateSmoother wokrs on a state [z, dz, p_msl] where dz is an altitude rate. i.e., a time derivative of z. In this case the Kalman update operation is not so trivial and tries to trace the current altitude change. This introduces a possibility of additional smoothing for the the estimated altitude values. The AltitudeFilter actually includes a heuristic weight that is used for smoothing purposes since the pressure measurements are very noisy and lead to noisy results otherwise.

There is a number of issues related with the above methodology that must be bear in mind:

• The first problems is what kind pressure is actually measured? The Barometric formula works by assumption that a measured pressure is a static pressure of a surrounding air, i.e., a pressure without dynamical component (dynamic pressure) which is related to the air velocity v as v^2. However, it depends on many factors if that is the case. The phone is quite often covered from the wind so that it does not measure large dynamic pressure and the barometric sensor itself is hidden deep inside the phone cover. However the shape of a surrounding object (like the user of the phone itself) can lead to many local overpressure and underpressure regions which influence the actual value of static pressure around a body. Those effects often depend strongly on the air velocity but for recreational activities, where freestream velocity is small, should not be significant.
• The similar question is related with the GPS measurement errors. This issue is quite complicated but for linear Kalman filters considered here it is important to note the violations of Kalman filter assumptions. The ideal, linear Kalman filter estimates correct values only under assumption of a measurements characterized by a white noise, i.e., with a Gaussian distribution of a zero mean value. This certainly is not a case for realistic GPS measurements. Various atmosphere effects and other errors lead to error components which do not necessarily give Gaussian distribution with zero mean value. Those effects (especially non-zero mean value) are reflected in the last case scenario of Case Studies document and are hard to eliminate.
• The barometric formula works good within troposphere regime, i.e., up to the altitude of approximately 10000m and this is a limit for those filters.
• There is one technical shortcut that was used. The Location object gives only altitudes with reference to the WGS84 ellipsoid and this altitude is actually estimated during filters operation. However this is wrong, the barometric formula requires mean sea level pressure which is not a pressure at the WGS84 ellipsoid but pressure at the geoid surface. This can potentially lead to noticeable errors when large distances are traversed (geoid changes) or large altitude amplitudes are analyzed (scaling problems). For realistic recordings the measurement operations should compensate for that. It is actually possible to use altitudes above geoid surface since $GPGGA frame of raw NMEA data contains that information but that would use less reliable Android API which is actually device-dependent. Ideally it should be provided in the Location API but right now it is missing there.
• Ideally when designing the Kalman filter all the noise amplitudes should be calculated or taken from the laboratory experiments. Because of the large variety of a target devices and large unpredictability of the working conditions it is almost impossible to do so in this case. The currently used values were matched heuristically to work with relatively large number of use cases.
• Because of that (heuristically matched noise amplitudes) the variance estimates given by the filtering algorithms are rather some kind of heuristic quality measures, not a variance in a strict probabilistic sense.