From: pnachtwey on
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
From: Malachy Moses on
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.
From: Rune Allnor on
On 17 Des, 19:54, pnachtwey <pnacht...(a)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.  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.  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
From: Tim Wescott on
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
From: pnachtwey on
On Dec 17, 6:11 pm, Tim Wescott <t...(a)seemywebsite.com> wrote:
> 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