From: pnachtwey on 17 Dec 2009 13:54 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 17 Dec 2009 17:54 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 17 Dec 2009 18:08 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 17 Dec 2009 21:11 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 18 Dec 2009 04:26 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
|
Next
|
Last
Pages: 1 2 3 Prev: UGG、Nike dunk high shoes wholesale\retail Next: Christmas Greetings from Lyons |