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.