Conclusions

Using a theoretical path as a "sensor"

In this application, we are specifically modeling for a known track path. When the path is not known, the option to use a theoretical path isn't even an option. The decision to incorporate a theoretical path raises the question of how much this known path should be weighted in any sort of estimation calculation. If it is weighted too heavily, then no sensor data is actually taken into account. For this project, we used this theoretical path as a model for mapping our heading data. As such, we use our heading data (measured from the GPS) to decide where on the theoretical path the runner is. With this application, we don't negate the use of our sensors, while simulatenously using our known track path to the model's advantage.

Data needs LOTS of filtering

We decided to collect our own data for this project, rather than opt for publicly available data online. Not only did this bring in complications with the physical experiment, but this meant that data filtering played a large role in our analysis. There were several areas that were addressed. Firstly, the data for the accelerometer and gyroscope needed to be trimmed such that we only analyzed data from the actual running and inputted into a running average filter to smooth out the data. Secondly, all of our data needed to be time synced. We needed to start and end our data at the same points, and have data points that corresponded to each other in time. Finally, the GPS data needed to be interpolated because there were significantly more data points from the phone sensors that needed to correspond with these GPS data points in time. All of this analysis and filtering is a prerequisite to the actual filter itself.

While the plain EKF did not improve the GPS data, the integration of the known path improved the state estimation immensely

As can be seen from the EKF results, using the GPS data as the sole input to the correction step did not yield a better output than Strava itself. This aligns with our expectations as we are using "bad data" to try to correct our estimation. Of course, if we use the data set that the "bad" Strava estimation uses as its input, we shouldn't expect any better results. However, we do see a better estimation when we incorporate our known theoretical track. Therefore, this project is successful as we can produce a better state estimation of a runner around a track than Strava (i.e. only raw GPS data) can.