Hi, 

Does anyone know where to input the raw data from
the MARG sensor(3D) into Kalman filter equation as
to find the position and orientation?

		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

"ester" <estelle_ang@pacific.net.sg> writes:

> 
> Hi, can anyone tell me where should the raw data input?
> 

At the input?

You really need to tell us much more about what data you're
collecting, and what signal model you're using before we can answer
the question sensibly.

Ciao,

Peter K.

>I only have an 2d accelerometer availabe but it is noisy, so I want to do
>better than just doing low pass filtering. I am wondering if it is
>possible to do kalman filtering with just an accelerometer. Let's say I
am
>just concerning in position and velocitly in 1d space for now.
>
>I am a little confused what ithe input u in x(t+1) = Ax(t) + Bu(t) + w
>equation and what the output y in y(x) = Cx(t) + n should be.
>
>People said y is supposed to be the measurement, so is it the
>accelerometer reading? If my x(t) is [pos vel], then what is u(t)?
>
>Would be nice if someone can tell me what is A, B, C, x and y be
>Your reply is greatly appreciated
>
>
>
>
>
>
>
>
>		
>This message was sent using the Comp.DSP web interface on
>www.DSPRelated.com
>

Hi, can anyone tell me where should the raw data input?


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

"blackmangoes" <blackmangoes@excite.com> wrote in message
news:ePKdnW8F5u_ibQHfRVn-vQ@giganews.com...
> Okay
> Somehow I thought wk is the noise with mean equal to 0
>
> Are we comparing the the old estimated acceleration and the measured
> acceleation from accelerometer? If so, the state will just be acceleration
> then.
>
> Is B in my Kalman Gain equation? where B is
>
> x_{k+1} = A x_{k} + B u_{k} + w_{k}
>
> then the next estimation is
> \hat x_{k+1} = A \hat x_{k} +B \hat u_{k} + K (y - C \hat x_{k})
>
> So if u_{k} is the noise, what do I put there?
> If w_{k} is the noise, what is u_{k} and B?
>
>
> This message was sent using the Comp.DSP web interface on
> www.DSPRelated.com

You only need U if you have a control problem.If it is purely random signal
+ noise then U is zero.(so is B)

Rimmer

steve wrote:
> Agree with everything you said, but this is not what you said in your
> previous post
> "averaging may not be enough bandwidth reduction to avoid aliasing."
> where you implied that averaging is related to avoiding aliasing, which
> it is not.

Whatever you thought I wrote, and however badly I worded it, it's now 
clear that you LPF well enough for 64x sampling but not much slower. In 
that case, averaging can reduce the sampled noise. How much the noise is 
reduced compared to a simple LPF at the 1x rate depends on the noise 
spectrum. After all, with uniform noise density, the 64x filter lets 
through 64 times as much noise.

There's no need to suffer aliasing if you LPF the digital signal before 
or while you decimate it.

As to correlation of the noise in the samples, the 64x filter introduces 
very little. If the noise is broadband, averaging should reduce it to on 
the order of what (but maybe a little better than) a LPF might do. If 
the noise is inherently narrow band, then it is correlated at the high 
end before it's filtered. There are good ways and poor ways, but there's 
no free lunch.

Analog LPF at Nx, admitting N times as much noise.
   Excess noise to be eliminated later.
Average, reducing noise at all frequencies.
   Use a boxcar or other averager that gives as many samples out as in.
LPF the averaged signal, probably as part of decimation.
   Eliminate all high-frequency noise that a 1x filter pass, and aliases.

I think that's about as good as can be had. N=16 may reach diminishing 
return. As always, LPF cutoff is less than half the sample rate.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Ok, disregard the above post, I read Jon's clarification of your
response and now understand what you were talking about, you were
refering to aliasing after decimation, I misunderstood

Agree with everything you said, but this is not what you said in your
previous post
"averaging may not be enough bandwidth reduction to avoid aliasing."
where you implied that averaging is related to avoiding aliasing, which
it is not.

Jon Harris wrote:

>  ...  If you are going from analog to digital (analog-to-digital conversion)
> then aliasing must be prevented with an analog filter.  However, if you are
> going from digital to digital at a lower sample rate (sample rate conversion, or
> downsampling), then aliasing can be prevented with a digital filter (before the
> sample rate conversion is done).

I wish I had said that!

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"Jerry Avins" <jya@ieee.org> wrote in message
news:F5qdnR80FOxvdQDfRVn-3A@rcn.net...
> steve wrote:
> > As I stated, I bandlimit the 64x rate.
> >
> > You can't "avoid aliasing" with software averaging  (or any other
> > software filter for that matter), aliasing is only prevented via
> > appropriate hardware filtering matched to a given sample rate.
>
> No. If you bandlimit properly for 64x sampling, there will be no
> aliasing in the high-speed data stream. It can then be reduced to 1x by
> the usual decimation techniques, also without aliasing. You can average
> before you filter-decimate and still have no aliasing. Taking the
> average will reduce the high-frequency content, but in general, not enough.

Right.  If you are going from analog to digital (analog-to-digital conversion)
then aliasing must be prevented with an analog filter.  However, if you are
going from digital to digital at a lower sample rate (sample rate conversion, or
downsampling), then aliasing can be prevented with a digital filter (before the
sample rate conversion is done).

steve wrote:
> As I stated, I bandlimit the 64x rate.
> 
> You can't "avoid aliasing" with software averaging  (or any other
> software filter for that matter), aliasing is only prevented via
> appropriate hardware filtering matched to a given sample rate.

No. If you bandlimit properly for 64x sampling, there will be no 
aliasing in the high-speed data stream. It can then be reduced to 1x by 
the usual decimation techniques, also without aliasing. You can average 
before you filter-decimate and still have no aliasing. Taking the 
average will reduce the high-frequency content, but in general, not enough.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������