I believe its a common misconception in the offshore industry that an ROV mounted INS system improves the absolute accuracy of the position it is actually being aided with (USBL, LBL, GNSS etc).
Sales marketing of INS’s often quote that an INS improves accuracy by up to x3 times.
How can ANY sensor improve / reduce the errors found in a position the INS is receiving from external sources?
Thoughts?
Hi Hydro,
I like to think of an INS as an information processor rather than an additional source of positional information. An INS will take data from various sources, such as an AHRS or USBL etc. Each of these information sources have their own drawbacks and strengths. For example, a USBL is less prone to producing any long-term inaccuracies in your positional data. However, the positional data it provides might jump around due to noise and spatial resolution of the USBL system. If you just had an INS with nothing buts its own AHRS as a data input, it would provide much higher spatial and temporal positioning precision than the USBL system, but it would drift over time as it would be using dead-reckoning. This would mean it’s long-term accuracy might be limited when compared to the USBL system.
The key thing about the INS is that it is able to combine lots of inputs from aiding sensors, such as a USBL system or a DVL. It then uses a Kalman filter to dynamically change the weightings it gives to its various inputs. The result of this is that when you plug the USBL in, its able to take advantage of the lack of long-term drift that the USBL provides, but is able to filter out any erroneous positioning data the USBL provides due to noise or its low spatial/temporal resolution. The more sources of information you add to the INS, such as a DVL input, even if these individually have their own limitations, the better precision and accuracy of the positional information it will output.
To the extent that the positioning information from the USBL is inaccurate, and the INS is able to successfully filter this out in favor of other inputs, it will improve your accuracy. It doesn’t do anything to improve the USBL data, it just intelligently filters out any bad information it provides, whilst still taking advantage of its excellent long-term accuracy.
Thanks Nils. Appreciate this reply. My stance remains the same - The INS / IMU sensor cannot improve the absolute positioning accuracy (or inaccuracy) of the geographical positional data it is supplied with (USBL or LBL). It is misleading in my opinion for the manufacturers sales marketing of INS products to suggest the system offers an improvement of up x3 the ‘accuracy’ of ROV position to when not used. I would agree that it improves the precision by up to x3 but not the accuracy
Hi @Hydro -
I agree with Nils, and while quantifying the benefit may be difficult / misleading, an INS is critical when using other forms of acoustic positioning.
With only a USBL, you may have high accuracy but low precision, as the occasional jumps of position are not filtered out. With an INS processing AHRS data, when the USBL says the vehicle has moved it can be verified and rejected if not true. This results in higher accuracy and precision!
Thanks Tony.
My head still tells me that the Kalman filter only rejects poor positional aiding data depending on what weighting / standard deviation is applied to that input. Does removing nosiy USBL data skew the postion and make it more closer to ‘true’ - im not so sure and especially so when considering a single fix as appose to an accumulation fix.
Whilst i agree its difficult to quantify accuracy improvements we must try harder since there is a big cost increase whether mobilising a subsea INS
Sure thing @Hydro -
If using only INS, and trying to hold position, this would quickly drift away as the MEMs motion sensors aren’t terribly accurate. A USBL fix, especially at a high rate, can prevent this drift - but when a multipath causes the USBL fix to report a position that is off by a few meters, for only a few messages, the INS can eliminate those faulty readings as no large acceleration was felt!
As with most things, it all depends on what you’re trying to do. If holding a position relative to the bottom is your application, a DVL is best suited - and again here the INS helps reject erroneous velocity readings from the DVL. If you require the true GPS location of your vehicle, a USBL is the better solution. The best possible performance may come from fusing all 3 - and this, depending on the hardware being used, is possible - and becoming more possible all the time! I would definitely consider it pushing the limits of what is possible with ArduSub, but users seeking to achieve this advanced functionality is always a great motivation to continuously improve!
Thinking about how one would quantify / test this is a fun thought experiment…
Hi Hydro,
If the positioning USBL/DVL data is inaccurate to begin with, then no aiding device (Kalman filter) will make it ACCURATE. The INS will help filter it, and it will clearly improve precision.
If now and then you get an accurate position (say from an RTK GPS), then the Kalman filter will successfully “hold” a better accuracy for a longer time, but not forever, it will eventually slowly drift (decrease the accuracy).
So, the aiding device cannot “improve” the initial accuracy of the positioning source, it will just try to “hold” a good accuracy for a longer time, then it will need another adjustment (from an accurate positioning source).
Sadly not many users get the distinction between “accuracy” and “precision”. Many times a better accuracy for a somewhat longer time may be enough (if the user understands its strengths/limitations), and most of the times the increased precision is enough.
You are right. The aiding device cannot IMPROVE the position ACCURACY, it will only improve PRECISION.
If I need the best position accuracy (say for a survey), I usually put most of my money in the position source accuracy first (I will not buy a cheap GPS/DVL/USBL/whatever and an expensive INS).
My two cents,
Dan
Hi Dan. I’m glad we’re aligned. The INS can only remove the random errors associated with the raw USBL input but not the systematic error.
