Gravity Vector Tracking

Am 02.05.2013 19:42, schrieb Vladimir Vassilevsky:
> blah

Simpletons tell me things I already know.

On Thu, 02 May 2013 12:06:28 -0500, Vladimir Vassilevsky
<nospam@nowhere.com> wrote:

>On 5/2/2013 11:54 AM, Spehro Pefhany wrote:
>> On Thu, 02 May 2013 10:46:18 -0500, Tim Wescott
>> <tim@seemywebsite.please> wrote:
>>
>>> On Thu, 02 May 2013 09:08:38 -0400, Randy Yates wrote:
>>>
>>>> Tim Wescott <tim@seemywebsite.please> writes:
>>>>
>>>>> On Wed, 01 May 2013 16:22:31 -0400, Randy Yates wrote:
>>>>>
>>>>>> Vladimir Vassilevsky <nospam@nowhere.com> writes:
>>>>>>
>>>>>>> On 5/1/2013 2:54 PM, Randy Yates wrote:
>>>>>>>> Looking for suggestions or pointers on how to track the gravity
>>>>>>>> vector in 6D data.
>>>>>>>>
>>>>>>>>
>>>>>>> http://en.wikipedia.org/wiki/Equivalence_principle
>>>>>>
>>>>>> Hi Vlad,
>>>>>>
>>>>>> Thanks for that. Are you saying it's impossible? How does a
>>>>>> navigational system account for gravity, e.g.?
>>>>>
>>>>> Track how, and how accurately?  If the motion you're dealing with isn't
>>>>> too severe you can get a pretty good estimate of "down" with a
>>>>> gyroscopically-stabilized average acceleration vector.  Folks have been
>>>>> doing it since WW-II with mechanical gyros being servoed around by
>>>>> input from mercury tilt switches.
>>>>
>>>> Is 200G too severe?
>>>
>>> That depends on the capabilities of your sensors, how much rotation
>>> you're trying to ignore, whether that 200G is from vibration, and if so
>>> what the vibrational frequencies are compared to your sampling rate and
>>> sensor bandwidths.
>>>
>>> And, of course, your accuracy requirements.
>>>
>>> If you are experiencing strong vibration then you're almost certainly
>>> going to have rotation as well as linear vibration going on (not to
>>> mention relative motion between your sensors -- hoo boy!).  Simultaneous
>>> rotation and acceleration opens the door to an effect called "sculling"
>>> that causes apparent bias in accelerometer readings.  Rotational
>>> vibration opens the door to an effect called "coning" ("cone-ing") which
>>> causes apparent bias in gyro readings.  This apparent bias, in turn,
>>> causes inaccuracies.
>>
>> Just shaking an accelerometer will cause a bias shift. This is called
>> "vibration rectification".
>
>Precision accelerometers use feedback that keeps them at zero state. The 
>output is compensation signal from the feedback loop. That cancels 
>non-linear effects such as mechanical rectification.

Nope. The effect is quite measurable in the most precise
force-feedback accelerometers, and it gets larger around the open-loop
mechanical resonance. 

On 5/2/2013 9:08 AM, Randy Yates wrote:

> Right. As I read, it seems the main use of Kalman filters is in Aided
> INS, in which there is some other information input to the filter
> besides the usual 6.

Randy, do you have a model for how you think the gravity vector 
influences the 6D measurements you have?

If you can model the influences you're after, you might be able to use 
the Kalman filter to get an estimate of them.

There is an (overly simplistic) write-up of how to use the Kalman filter 
to estimate velocity when all you are measuring is position here:

http://dsp.stackexchange.com/a/8869/80

There is a (far from complete) write up of how to choose the system 
state for a 3D system here:

http://dsp.stackexchange.com/a/321/80

Ciao,

Peter K.

Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> writes:

> On Thu, 02 May 2013 10:46:18 -0500, Tim Wescott
> <tim@seemywebsite.please> wrote:
>
>>On Thu, 02 May 2013 09:08:38 -0400, Randy Yates wrote:
>>
>>> Tim Wescott <tim@seemywebsite.please> writes:
>>> 
>>>> On Wed, 01 May 2013 16:22:31 -0400, Randy Yates wrote:
>>>>
>>>>> Vladimir Vassilevsky <nospam@nowhere.com> writes:
>>>>> 
>>>>>> On 5/1/2013 2:54 PM, Randy Yates wrote:
>>>>>>> Looking for suggestions or pointers on how to track the gravity
>>>>>>> vector in 6D data.
>>>>>>>
>>>>>>>
>>>>>> http://en.wikipedia.org/wiki/Equivalence_principle
>>>>> 
>>>>> Hi Vlad,
>>>>> 
>>>>> Thanks for that. Are you saying it's impossible? How does a
>>>>> navigational system account for gravity, e.g.?
>>>>
>>>> Track how, and how accurately?  If the motion you're dealing with isn't
>>>> too severe you can get a pretty good estimate of "down" with a
>>>> gyroscopically-stabilized average acceleration vector.  Folks have been
>>>> doing it since WW-II with mechanical gyros being servoed around by
>>>> input from mercury tilt switches.
>>> 
>>> Is 200G too severe?
>>
>>That depends on the capabilities of your sensors, how much rotation 
>>you're trying to ignore, whether that 200G is from vibration, and if so 
>>what the vibrational frequencies are compared to your sampling rate and 
>>sensor bandwidths.
>>
>>And, of course, your accuracy requirements.
>>
>>If you are experiencing strong vibration then you're almost certainly 
>>going to have rotation as well as linear vibration going on (not to 
>>mention relative motion between your sensors -- hoo boy!).  Simultaneous 
>>rotation and acceleration opens the door to an effect called "sculling" 
>>that causes apparent bias in accelerometer readings.  Rotational 
>>vibration opens the door to an effect called "coning" ("cone-ing") which 
>>causes apparent bias in gyro readings.  This apparent bias, in turn, 
>>causes inaccuracies.
>
> Just shaking an accelerometer will cause a bias shift. This is called
> "vibration rectification". 

Is that because it produces accelerations that exceed the
accelerometers' maximum?

By the way, in the system I'm working with, the high Gs come from
impacts, not vibration.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Randy Yates <yates@digitalsignallabs.com> writes:

> Looking for suggestions or pointers on how to track the gravity vector
> in 6D data.

Tim, Vlad, Peter, Spehro, and SG: Thank you for all the input you've
provided so far. 

By the way, we're using the ST LSM330 as the gyro and low-G
accelerometer, and an Analog Devices ADXL377 for the high-G
accelerometer.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On 5/2/2013 11:01 PM, Randy Yates wrote:
> Randy Yates <yates@digitalsignallabs.com> writes:

> By the way, we're using the ST LSM330 as the gyro and low-G
> accelerometer, and an Analog Devices ADXL377 for the high-G
> accelerometer.

ST MEMS are noted for being inacurate and unreliable.
Best in the MEMS class are VTI devices (now division of Murata).

Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com

On 5/3/2013 12:01 AM, Randy Yates wrote:

> Tim, Vlad, Peter, Spehro, and SG: Thank you for all the input you've
> provided so far.
>
> By the way, we're using the ST LSM330 as the gyro and low-G
> accelerometer, and an Analog Devices ADXL377 for the high-G
> accelerometer.

You're more than welcome!

Sounds like a fun project. New toys! :-)

Ciao,

Peter K.

On Thu, 02 May 2013 21:29:54 -0400, Randy Yates wrote:

> Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> writes:
> 
>> On Thu, 02 May 2013 10:46:18 -0500, Tim Wescott
>> <tim@seemywebsite.please> wrote:
>>
>>>On Thu, 02 May 2013 09:08:38 -0400, Randy Yates wrote:
>>>
>>>> Tim Wescott <tim@seemywebsite.please> writes:
>>>> 
>>>>> On Wed, 01 May 2013 16:22:31 -0400, Randy Yates wrote:
>>>>>
>>>>>> Vladimir Vassilevsky <nospam@nowhere.com> writes:
>>>>>> 
>>>>>>> On 5/1/2013 2:54 PM, Randy Yates wrote:
>>>>>>>> Looking for suggestions or pointers on how to track the gravity
>>>>>>>> vector in 6D data.
>>>>>>>>
>>>>>>>>
>>>>>>> http://en.wikipedia.org/wiki/Equivalence_principle
>>>>>> 
>>>>>> Hi Vlad,
>>>>>> 
>>>>>> Thanks for that. Are you saying it's impossible? How does a
>>>>>> navigational system account for gravity, e.g.?
>>>>>
>>>>> Track how, and how accurately?  If the motion you're dealing with
>>>>> isn't too severe you can get a pretty good estimate of "down" with a
>>>>> gyroscopically-stabilized average acceleration vector.  Folks have
>>>>> been doing it since WW-II with mechanical gyros being servoed around
>>>>> by input from mercury tilt switches.
>>>> 
>>>> Is 200G too severe?
>>>
>>>That depends on the capabilities of your sensors, how much rotation
>>>you're trying to ignore, whether that 200G is from vibration, and if so
>>>what the vibrational frequencies are compared to your sampling rate and
>>>sensor bandwidths.
>>>
>>>And, of course, your accuracy requirements.
>>>
>>>If you are experiencing strong vibration then you're almost certainly
>>>going to have rotation as well as linear vibration going on (not to
>>>mention relative motion between your sensors -- hoo boy!). 
>>>Simultaneous rotation and acceleration opens the door to an effect
>>>called "sculling" that causes apparent bias in accelerometer readings. 
>>>Rotational vibration opens the door to an effect called "coning"
>>>("cone-ing") which causes apparent bias in gyro readings.  This
>>>apparent bias, in turn, causes inaccuracies.
>>
>> Just shaking an accelerometer will cause a bias shift. This is called
>> "vibration rectification".
> 
> Is that because it produces accelerations that exceed the
> accelerometers' maximum?
> 
> By the way, in the system I'm working with, the high Gs come from
> impacts, not vibration.

It is because no sensor is perfectly linear, and because inertial 
measurement problems are generally far more sensitive to bias than a lot 
of other errors, so all of the second-order nonlinearities tend to get 
lumped into "gravity sensitive bias".

The high G coming from impact is probably not going to change the problem 
much, unless you're lucky.  If by chance you could blank out the 
measurements for the duration of the impact and re-initialize afterwards 
you could maybe relax the sensor requirements.  This would only be valid 
if the orientation of your platform does not change to a great extent as 
a consequence of the impact, if you don't need to know the orientation of 
your platform right after the impact, or if you don't need to know the 
orientation of the sensor right after the impact until some time after 
(which would let you calculate, then backtrack).

If you must track through the impact then all of the G-sensitive effects, 
as well as coning and sculling, still mean something and must be 
accounted for.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

On Thu, 02 May 2013 21:29:54 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>
>> Just shaking an accelerometer will cause a bias shift. This is called
>> "vibration rectification". 
>
>Is that because it produces accelerations that exceed the
>accelerometers' maximum?

Due to nonlinearities while operating well within the maximums. 

Of course if you rail the thing you'll see gross errors. 

>By the way, in the system I'm working with, the high Gs come from
>impacts, not vibration.
>-- 

On Fri, 03 May 2013 00:01:36 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>Randy Yates <yates@digitalsignallabs.com> writes:
>
>> Looking for suggestions or pointers on how to track the gravity vector
>> in 6D data.
>
>Tim, Vlad, Peter, Spehro, and SG: Thank you for all the input you've
>provided so far. 
>
>By the way, we're using the ST LSM330 as the gyro and low-G
>accelerometer, and an Analog Devices ADXL377 for the high-G
>accelerometer.

Do you have any sensors other than the gyros and accelerometers to
maintain alignment?   We use various devices that use the MEMS gyros
and accelerometers to instrument cars on track to get lateral
g-loading, acceleration/deceleration, estimate hp, etc., etc.   They
work really well for that, but most also use gps to remove drift/bias.
GPS by itself doesn't get enough resolution to get detailed info, but
together you can get very repeatable, reliable info even with the
cheapie MEMS sensors.

Back in my radar days we used IMUs with periodic GPS realignment
updates (with a Kalman predictive filter) to estimate the aircraft
position in order to keep the antenna accurately aimed at a ground
target.   That was in the late 80s, so it's not like it's new
methodology or technology.

I don't know how your application compares, but if there's any way to
get additional alignment data, even just once in a while, it can go a
long way toward keeping the drift/bias under control.



Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com