A note on the strapdown algorithms

Probably you have noticed that the strapdown implementations in the toolkit directly use the sensor outputs to compute the body updates. For instance, accelerometer outputs (a) are multiplied by the DCM (C) and then added to the velocity state.

Those of you who have some experience on the INSs may find this a little bit disturbing. Basically, both “C” and the “a” changes in an update interval. Therefore, such a first order approximation should not be theoretically valid.

Basically you are right. A decent INS implementation must consider this effect. In general, such integral compensations are performed as a part of the coning and sculling algorithms (which are now part of the toolkit). Although these algorithms are meant to remove the algorithmic bias effects generated by the so-called coning and sculling motions, the intra-minor steps of these algorithms also take care of the integral compensation terms. After compensated by these algorithms, the IMU outputs can be directly used in the INS without requiring any special integration considerations in the strapdown implementation.

The beautiful part of this approach is that the IMU and the INS algorithms can be distinctively separated. The coning and sculling algorithms are black-box type algorithms for IMU sections (or boards). They operate only on the sensor outputs in a user defined interval and provide compensated outputs which are later processed by the strapdown algorithms like the ones in the toolkit. That is why, despite the simple integration approximation, the strapdown implementations in the toolkit are theoretically correct.

Most MEMS producers are not aware of this very simple fact. They only provide inertial measurements (i.e. acceleration and rotation rate) at the highest possible sensor rate and force to INS designers to read all the data separately. But INS designers don’t need such high rates. Even the missiles cruising in the subsonic region executes the INS algoithms at 100-200Hz rates. Only the compensated senor outputs at a moderate rate is sufficient for most commercial applications. As explained above, thanks to the IMU compensation algorithms, no integral error is induced in the strapdown algorithms even with the fairly slow updates rates.

It will take probably 10 more years for MEMS producers to think of providing low-rate compensated sensor outputs rather than very high rate raw measurements. They are really too stupid to understand even the simplest things about inertial navigation. Meanwhile, it is us (the INS designers) who is going to suffer from their stupidity.

As an example consider the inertial sensors in the smart phones. If you want to design a navigation system based on these sensors you have to make the OS (i.e android) read data at least 200Hz. Just trying to read data at such high rates costs tremendous processing power for nothing. Furhtermore, at such high rates synchronization becomes impossible. (As a matter of fact the time tags in the sensor data for the android is completely useless either.) It will be more than sufficient to read inertial sensor outputs at rates lower than 25Hz (even much lower for most human tracking applications) if the sensors provide compensated outputs. Also in this case, the unknown time jitter problem would also be less severe (or perhaps completely removed).

I am really disgusted by the overall ignorance in the inertial sensor industry. They don’t know and they don’t try to learn.

Posted in Android, IMU, INS | Leave a comment

Implementing a GPS/INS without a math-coprocessor

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:

  1. High speed INS update (for inertial sensors)
  2. Low speed INS update (for navigation frame updates)
  3. 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.

Posted in Android, INS | Leave a comment

Hello world!

Imaginations on the imaginary axis cause cyclo-stationary responses.

Posted in Uncategorized | Leave a comment