|
A few years ago I experimented with an inertial navigation system I
created using a 3DM-GX1 sensor from Microstrain. I think the newest
model is the 3DM-GX3 now - would have to experiment to see what
accuracy gain there is in the new model. In any case, this is a
three axis accelerometer which incorporates 3 magnetometers and 3
rate gyros. The magnetometers are supposed to be used to measure
the ambient magnetic field and use this as a quasi-constant input to
correct the gyro bias. Unfortunately, the magnetometers are
affected by external magnetic influences, such as large steel
shipwrecks, so the instrument is least accurate when you tend to
need it. The instrument measures acceleration directly.
Integrating this signal over time gives you your present velocity,
and integrating over time once again gives you your displacement
(position) in xyz space. In my experiment (conducted on a surface
vessel), I started with a known position obtained from GPS, then
shut off the GPS signal and simply added the position variations as
calculated from the 3DM-GX1 to determine my current position. This
is, in fact, exactly how military submarines do it, only their
inertial navigation units comprise extremely accurate (and
consequently, extremely expensive) hardware to minimize the
integration error. This is the crux of the inertial navigation
problem - you are essentially determining your position through
dead-reckoning, using the last known good position, and applying
corrections from your IMU instrument. The problem is that error
creeps into the integration, and since you have to integrate twice,
the error starts to get significant. In my experiment, as soon as
the GPS was shut down, the error started to accumulate, so that the
uncertainty in the calculated position grew with time. Eventually,
you reach a point at which the error in your calculated position
renders the position useless for the purpose of navigation. The
solution? Either spend big bucks on a more accurate IMU, or
periodically correct the calculated deviations with another input.
There are several possibilities for this: 1) Doppler sonar - limited to low speeds at which the sonar reading is accurate, but this is more accurate than inertial navigation when it is implemented. Doing this would limit the inertial navigation error to that accumulated during the descent from the surface to a range from the bottom at which the doppler sonar becomes effective. 2) Depth transducer - It occurred to me that since you do know with reasonable accuracy your depth in the water column (and thus your velocity in the Z direction), you could use this as a correction input (i.e. do not allow integrated velocity values in Z direction to exceed this measured velocity, and rein in the X and Y velocities accordingly). I have no idea what effect this might have on accuracy without trying it. 3) Acoustic methods - widely used in industry, but require surface or seafloor based transmitters. (reference LBL & SBL navigation). If you have no need to operate independently of surface support, then acoustic navigation alone may meet your requirements, but this does require some hardware and so may end up being more expensive than an IMU for small submersible navigation at your required accuracy - depends on what you need. I would be inclined to try and find a low-cost doppler sonar for bottom navigation, supplemented by an inertial unit that isn't hugely expensive. One advantage of the IMU is that it will output pitch, roll and yaw angles, so you could use the output to control, for example, a trim tank system to keep a level keel. As I recall, the 3DM-GX1 cost somewhere in the neighborhood of $1400.00. I would be happy to look into developing a turnkey PSub inertial navigation solution, but I'd need a 3DM-GX3 (or similar) IMU to play with, as well as data acquisition hardware that runs at an appropriate frequency to capture the IMU output with minimal error. At present, I can't afford to buy these things for a hobby R&D project, although I might reexamine this at a later date when my situation changes. -Sean On 12/02/2011 10:43 AM, Recon1st@aol.com wrote:
|