hanley6
commented
7 years ago Hello:
(1) First, this INS is agnostic to the choice of initial position and velocity. However, since a gravity vector must be assumed in an INS (IMUs do not measure gravity) one must choose a frame in which the gravity vector must be placed. So, to answer your question, choosing an initial position, velocity, and orientation is all on you. How you estimating your trajectory in terms of a "NED" frame is actually application specific. For a ground robot, for example, you could use quasi-stationary initialization (see [1]). For something like visual-inertial odometry, you could actually estimate a transformation to the NED frame online (see [2]). Now for these two examples, you still end up with a degree of freedom about the "down" vector. In these cases, it doesn't even matter if you correctly estimate the NED frame, just the direction of the gravity vector. Note though that I do account for the "plumb-bob" gravity effect, which uses the rotation of the Earth. This makes my model more accurate if you do have an application where you can estimate a real NED frame. As a side note, it would be pretty easy to change the model into an ENU frame model as well. The gravity model class already computes it. All that would need to change is the ins_ode class.
(2) I provide a general model of some of the most common deterministic errors used in the context of inertial navigation. Yes, one could use expensive equipment to compute these errors. However, that is not necessary to use the code. There are default options for these parameters, and you can use these for many applications if you don't believe it is necessary to compute all these errors.
(3) I try to make a distinction in my code between fixed biases (which you can compute using a calibration process) and a turn-on/turn-off bias or bias changing due to a rate random walk, which you would estimate with some aiding sensor like a GPS receiver along with a Kalman Filter. If you don't wish to calibrate your system for a fixed bias, you can set it to zero or use the default value (which is also zero). Likewise, having a bias that can be updated online will allow the INS to be integrated nicely in a GPS/INS code or Visual-inertial odometry (or whatever other IMU+aiding sensor you choose).
I hope that helps! Let me know if you would like me to clarify or answer anymore questions!
References: [1] P. G. Savage, Strapdown Analytics: Part 1 and 2 2nd Ed., Maple Plain, MN: Strapdown Associates, Inc., 2007. [2] A. Martinelli, "Vision and IMU Data Fusion: Closed-Form Solutions for Attitude, Speed, Absolute Scale, and Bias Determination." IEEE Transactions on Robotics vol. 28, no. 1, pp. 44-60. 2012.
FlyAlCode
Dear David Hanley @hanley6 , I find your code is really clear and useful. But I have some questions on this project, could you please give me a hand? 1 How do you get the initial state of the INS, since you use the NED coordination? 2 How do you get these error parameters: scale_g, scale_a, cross_c_g, cross_c_a, bf_g, bf_a? Do you use some expensive equipments to calibrate them? 3 What do you mean by 'accelerometer/gyroscope biases estimated online'? what method do you use to achieve that?