Reply by pnachtwey December 29, 20092009-12-29
On Dec 26, 10:30&#2013266080;am, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 22 Des, 23:13, pnachtwey <pnacht...@gmail.com> wrote: > > > but &#2013266080;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
The platform that is being controlled must respond to the wave action and compensate for the relative motion. This is essentially gearing in 3D. When gearing to an reference it is always better to use more than just the reference's position. I like to estimate a velocity and acceleration too. This way the slave object can use feed forwards to estimate the control signal directly instead of waiting for error to be corrected by the closed loop control. As I said above, it have it worked out now. A simple alpha-beta-gamma filter does the trick. I have a simple simulation program. The feedback is 14 bits but I simulated it with 12. It just takes some math that the customer will have to see. I prefer not to scare them too much. I think I scared them too much as it is but I rather they go into this with their eyes wide open than be blindsided by the math. Peter Nachtwey
Reply by Rune Allnor December 26, 20092009-12-26
On 22 Des, 23:13, pnachtwey <pnacht...@gmail.com> wrote:
> but &#2013266080;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
Reply by pnachtwey December 22, 20092009-12-22
On Dec 22, 8:20&#2013266080;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. &#2013266080;I read the book review. &#2013266080;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
Reply by Fred Marshall December 22, 20092009-12-22
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
Reply by pnachtwey December 18, 20092009-12-18
On Dec 18, 1:30&#2013266080;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
Reply by Rune Allnor December 18, 20092009-12-18
On 18 Des, 10:26, pnachtwey <pnacht...@gmail.com> wrote:
> On Dec 17, 6:11&#2013266080;pm, Tim Wescott <t...@seemywebsite.com> wrote:>&#2013266080;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. &#2013266080;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. &#2013266080;The lastest Control Systems > Magaziine has a chapter on Kalman filters applied to a maritime > application. &#2013266080;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. &#2013266080;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
Reply by pnachtwey December 18, 20092009-12-18
On Dec 17, 6:11&#2013266080;pm, Tim Wescott <t...@seemywebsite.com> wrote:
>&#2013266080;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
Reply by Tim Wescott December 17, 20092009-12-17
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
Reply by Rune Allnor December 17, 20092009-12-17
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. &#2013266080;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. &#2013266080;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
Reply by Malachy Moses December 17, 20092009-12-17
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.