Accelerometers for maritime uses

I have a customer that has an nautical application where yaw, pitch,
roll and heave must be compensate for on the fly.  The sensor we are
looking at is
http://www.km.kongsberg.com/ks/web/nokbg0240.nsf/AllWeb/61118F926CD5A6E5C125700B0033CF55?OpenDocument
See the MRU H and MRU Z.
The problem is that these update slowly, every 10 milliseconds, and
don't have much resolution, only 14 bits.  I am assuming these are
simply accelerometers packaged for maritime use.
You can see that the data sheets are skimpy.  Nothing is said as to
why the updates takes so long.  I would hope to get some filtering for
that but nothing is said about that.  We can filter one our controller
if necessary.

I would like:
1. millisecond updates
2. 16 bit resolution at least
3.  SSI instead of analog feedback.

I see lots of posts here about accelerometers here so I am hoping that
someone can point to something better.

Thanks,

Peter Nachtwey

Before placing constraints on your system that might turn out to be
completely arbitrary and artificial, you might want to investigate the
spectral content of the actual nautical environment that your system
is compensating for.

As an example, your thoughts on a 1 millisecond update rate at least
implicate a Nyquist frequency of 500Hz, and there are doubts in my
mind that a real nautical environment would involve any significant
components with frequencies on that order of magnitude.

And as a counterexample, in control loops that I have been involved
in, for missile systems, we have often found that a 10 millisecond
update rate is sufficient.  Clearly (to me at least), the spectral
content of the environment for a missile system has got to be much
higher than that of a nautical system, so maybe the 10 millisecond
rate is high enough for you too.

On 17 Des, 19:54, pnachtwey <pnacht...@gmail.com> wrote:
> I have a customer that has an nautical application where yaw, pitch,
> roll and heave must be compensate for on the fly. &#4294967295;The sensor we are
> looking at ishttp://www.km.kongsberg.com/ks/web/nokbg0240.nsf/AllWeb/61118F926CD5A...
> See the MRU H and MRU Z.
> The problem is that these update slowly, every 10 milliseconds, and
> don't have much resolution, only 14 bits. &#4294967295;I am assuming these are
> simply accelerometers packaged for maritime use.

Check your assumptions. I don't know the instruments
in question, but I know that a number of MRUs used
in marine applications are based on gyros. It is
common to spend a lot of time stabilizing and calibrating
gyro-based MRUs.

Rune

On Thu, 17 Dec 2009 10:54:14 -0800, pnachtwey wrote:

> I have a customer that has an nautical application where yaw, pitch,
> roll and heave must be compensate for on the fly.  The sensor we are
> looking at is
> http://www.km.kongsberg.com/ks/web/nokbg0240.nsf/
AllWeb/61118F926CD5A6E5C125700B0033CF55?OpenDocument
> See the MRU H and MRU Z.
> The problem is that these update slowly, every 10 milliseconds, and
> don't have much resolution, only 14 bits.  I am assuming these are
> simply accelerometers packaged for maritime use. You can see that the
> data sheets are skimpy.  Nothing is said as to why the updates takes so
> long.  I would hope to get some filtering for that but nothing is said
> about that.  We can filter one our controller if necessary.
> 
> I would like:
> 1. millisecond updates
> 2. 16 bit resolution at least
> 3.  SSI instead of analog feedback.
> 
> I see lots of posts here about accelerometers here so I am hoping that
> someone can point to something better.

For that sort of application a 100Hz update rate isn't out of line; it is 
certainly quite adequate for the ground applications that I'm familiar 
with -- and I would expect a car to generate energy at higher frequency 
than a boat.  They advertise a 400Hz internal update rate; if they're 
doing things right they've got an averaging algorithm in there that also 
takes care of coning and sculling, and they're just delivering angle and 
velocity deltas for you to play with.  That's probably as good as you'd 
ever do with the raw signals from the sensors -- and 400Hz is a pretty 
good clip for that class of sensor.

For sensors like that they want you to call and inquire, partially 
because they want to go to your site to give you some intensive glad-
handing with smiles all around.  (I'm not cynical about this process -- 
really, I'm not).  The other part of it is because the field is somewhat 
specialized; for most people if you don't know what questions to ask 
you're not going to understand the answers.  I suspect that you could get 
there from where you are, but it's not a trivial body of knowledge to 
absorb.  So you have to call them and pull the data out of them one datum 
at a time.

-- 
www.wescottdesign.com

On Dec 17, 6:11&#4294967295;pm, Tim Wescott <t...@seemywebsite.com> wrote:
>&#4294967295;The other part of it is because the field is somewhat
> specialized; for most people if you don't know what questions to ask
> you're not going to understand the answers.
This is my fear.  I know that this will not be easy and I have a
pretty good idea of how to do this but I am not sure that my customer
understands what he is getting into.  The lastest Control Systems
Magaziine has a chapter on Kalman filters applied to a maritime
application.  If have also forwarded pdf articles on similar
applications so that the customer will not be surprised by the
calculations involved.
I am not buying the sensors.  I/we are just, hopefully, selling a
motion controller but I fear that I will need to get involved in far
more.

Peter Nachtwey

On 18 Des, 10:26, pnachtwey <pnacht...@gmail.com> wrote:
> On Dec 17, 6:11&#4294967295;pm, Tim Wescott <t...@seemywebsite.com> wrote:>&#4294967295;The other part of it is because the field is somewhat
> > specialized; for most people if you don't know what questions to ask
> > you're not going to understand the answers.
>
> This is my fear. &#4294967295;I know that this will not be easy and I have a
> pretty good idea of how to do this but I am not sure that my customer
> understands what he is getting into. &#4294967295;The lastest Control Systems
> Magaziine has a chapter on Kalman filters applied to a maritime
> application. &#4294967295;If have also forwarded pdf articles on similar
> applications so that the customer will not be surprised by the
> calculations involved.
> I am not buying the sensors. &#4294967295;I/we are just, hopefully, selling a
> motion controller but I fear that I will need to get involved in far
> more.

If so, you might want to get a copy of Fossen's book
on control of marine vessels,

http://www.amazon.com/Guidance-Control-Ocean-Vehicles-Fossen/dp/0471941131/ref=sr_1_2?ie=UTF8&s=books&qid=1261128590&sr=8-2

It costs an arm and a leg, but it contains a lot of
very useful stuff.

Rune

On Dec 18, 1:30&#4294967295;am, Rune Allnor <all...@tele.ntnu.no> wrote:
> It costs an arm and a leg, but it contains a lot of
> very useful stuff.
Yes, but mistakes cost much more.
Thanks for the link.  I read the book review.  Looks good.

I still would like more feedback resolution and a SSI interface.

Peter Nachtwey

pnachtwey wrote:
> On Dec 18, 1:30 am, Rune Allnor <all...@tele.ntnu.no> wrote:
>> It costs an arm and a leg, but it contains a lot of
>> very useful stuff.
> Yes, but mistakes cost much more.
> Thanks for the link.  I read the book review.  Looks good.
> 
> I still would like more feedback resolution and a SSI interface.
> 
> Peter Nachtwey

It might really help if you told us "why?".... to both.

Wanting an SSI interface implies a rather strongly constrained situation 
- thus the question there.

Wanting higher resolution implies a rather demanding application - what 
is it or why is it so demanding?

Fred

On Dec 22, 8:20&#4294967295;am, Fred Marshall <fmarshallx@remove_the_xacm.org>
wrote:
> pnachtwey wrote:
> > On Dec 18, 1:30 am, Rune Allnor <all...@tele.ntnu.no> wrote:
> >> It costs an arm and a leg, but it contains a lot of
> >> very useful stuff.
> > Yes, but mistakes cost much more.
> > Thanks for the link. &#4294967295;I read the book review. &#4294967295;Looks good.
>
> > I still would like more feedback resolution and a SSI interface.
>
> > Peter Nachtwey
>
> It might really help if you told us "why?".... to both.
>
> Wanting an SSI interface implies a rather strongly constrained situation
> - thus the question there.
>
>
> Fred
The pdf file says it has a serial interface but normal RS232 or RS485
interfaces aren't fast nor efficient.  Transferring 8 bits at a time
isn't efficient.   Our controller doesn't have 4 serial interfaces to
read 4 inputs at the same time.   We can read multiple channels of SSI
though.  We can use the analog inputs without problems but  noise on
top of 12 bit resolution is not good.  This data will need to be
filtered to provide positions, velocities and accelerations to gear
to.  Also, our controller is a general purpose motion controller.  The
closed loop updates are MUCH faster than 10 milliseconds.  I can slow
the controller down to 2 ms but it will not like seeing the same
reading for 5 times in a row.  I have worked out how to filter the 10
millisecond data and estimate positions, velocities and accelerations
for the times the motion controller updates.  It is just another thing
to hassle with.

The quality of motion control is often dependent on the quality of the
feedback.  Sample jitter and quantizing of feedback or reference
signals prohibit high gains that may otherwise work.

In this case we are trying to keep positions stables in possible
rolling waves.
After that there are still question I have for the customer because I
think we can keep our positions stable but how does one compensate for
the motion of there nearby objects?  Obviously there is more I need to
know about the application.

My simulations indicate that the estimated position, velocity and
acceleration should be good enough with the current feedback device.

> Wanting higher resolution implies a rather demanding application - what
> is it or why is it so demanding?
Hydraulic systems like to use the second derivative.  For instance
active damping is done by measuring the the pressure on either side of
the piston and computing a net force.  Likewise it is good to be able
to compare the resulting acceleration with the acceleration of the
reference.  Accelerometers work well for this.  In the past we have
used accelerometers that update as fast as our controller and our
controller has a 16 analog inputs. Estimating the reference
acceleration using a slow update and low resolution feedback is just
another hassle but I have it worked out.

A better MRU would reduce the need for software.

Peter Nachtwey

On 22 Des, 23:13, pnachtwey <pnacht...@gmail.com> wrote:
> but &#4294967295;noise on
> top of 12 bit resolution is not good.

Again, check what data the MRU actually produces. 12 bits is
about 4 significant digits, which ought to be sufficient if the
device produces attitude angles, as it would do if it reads
gyro alignments.

Rune