Recently, I have implemented (embedded) a GPS-INS system in the native environment of my Android phone (a 2.5 years old HTC Hero). The embedded navigation code is capable of processing external inertial sensor and GPS outputs sent to the device via WIFI (using a tcp socket). After the native program computes the PVA results, it sends its outputs to the mapping application in the framework using another udp socket.
Here is a video showing a sample output with some real data:
In this video, the embedded navigation code processed the sensor data at 100HZ. The Kalman filter covariance update was also set to 100Hz. The GPS outputs at 1HZ and some occasional heading information was processed by the 21 state Kalman filter to stabilize the INS outputs during the navigation.
As can be seen from the left-upper corner (the time tag information), the real duration of the sensor data used in this video was only 320 seconds. However, it took 15 minutes for the phone to process the data (this can be verified from the phone’s clock seen on the upper-right corner).
One reason for this huge execution duration was the screen capture application that was run together with the navigation code. When I ran the navigation code by itself without any screen capture the total execution duration dropped to 440 seconds which was again 120s longer than the real navigation duration.
In my desktop PC, it takes less than 10 seconds for the same navigation code to process the entire data. It is clear from these time results that the processors in the smartphones, which do not have a math-coprocessor, are not fast enough for real time navigation with the single speed INS implementations.
This simple experiment shows that a gps/ins system for the smartphones must have 3-speed structure with the following components:
- High speed INS update (for inertial sensors)
- Low speed INS update (for navigation frame updates)
- Low speed KF covariance updates.
Furthermore, it would be quite wise if “item 3″ is implemented as an additional thread. However, in this case the asynchronous KF updates should be well synchronized with the covariance update thread in order to prevent disastrous mistakes.