search

hoarfw / air-mouse

Automatically exported from code.google.com/p/air-mouse
0 stars 0 forks source link

Noise Elimination for Position Estimation (single axis) #6

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
There are a lot of errors accumulated when trying to integrate the
acceleration. 

This can be due to the following reasons: 
#1 Coupling of Static and Dynamic Acceleration (possible fix - High Pass
filter)
#2 Incorrect integration algorithm?
#3 Unavoidable Mechanical Noise 

---- 
What steps will reproduce the problem?

Attached is a sample file containing z-axis output. Three bursts of raising
the mouse and bringing it back to rest are recorded. 

What is the expected output? What do you see instead?
The expected output is to have the sum of all values as zero. Its currently
a large positive value.

Original issue reported on code.google.com by manavkataria on 22 Jun 2009 at 6:56

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by manavkataria on 22 Jun 2009 at 6:57

GoogleCodeExporter commented 9 years ago 
Hey, I ran kalman filter on the data provided.
Attached is the result. Check out :)

The filter does not seem to be doing too well.
Will try to improve the model and incorporate 
double integration as well.

Original comment by mahadesh...@gmail.com on 28 Jun 2009 at 9:54

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by mahadesh...@gmail.com on 28 Jun 2009 at 10:02

GoogleCodeExporter commented 9 years ago 
Panju, this looks so sexy! Tho it may not be useful yet. But doin this can 
definitely
take us to a new level. 

just a thought - Can you also run LPC on it and see if that helps?
Let me know wht model u used for Kalman and what parameters do u plan to 
configure
for a better result. 

Cheers!
Manav

Original comment by manavkataria on 28 Jun 2009 at 12:16

GoogleCodeExporter commented 9 years ago 
As I understand LPC cant be used here. Anyway I'll check with some people in 
the lab. 

As for the model is concerned I used [acceleration velocity position] as the 
state
vector, the transition matrix being determined from the kinematic equations. The
problem I have is velocity and position in the state vector does not make sense.
Therefore I plan to use integration equations that link velocity and position to
acceleration instead of the kinematics... 

Will provide an update soon :)

--Panju

Original comment by mahadesh...@gmail.com on 29 Jun 2009 at 10:10

GoogleCodeExporter commented 9 years ago 
We integrated the acceleration Data. The velocity curve in blue does not come to
zero. The reason for this is that the acceleration data has a DC shift. This 
shift
has to be removed but a DC filter will NOT do as it will corrupt the velocity 
and
subsequently the displacement data. What may work is to forcibly zero out 
velocity if
acceleration is zero for a long time. Attached is the m file and the acc/vel 
plot.

Original comment by GautamSh...@gmail.com on 12 Jul 2009 at 10:28

Attachments:

GoogleCodeExporter commented 9 years ago 
Adding Gautam to the list. Gautam confirm if you received the mail.
Updating Type to Enhancement

Original comment by manavkataria on 12 Jul 2009 at 10:56

GoogleCodeExporter commented 9 years ago 
Panju, 

Can you run myinteg.m in comment#6 on the Kalman Filtered data you produced? It 
would 
be interesting to know how much the signal improved after filtering. 

Manav

PS: Please also upload your kalman-filter.m file.

Original comment by manavkataria on 14 Jul 2009 at 5:46

GoogleCodeExporter commented 9 years ago 
*Figuring out the cause of DC in Acceleration Data*
  * I with Krishanan figured out that the reason for the unequal acceleration could be 
a non-linear characteristic of the accelerometer. I think this is a very 
important 
observation and likely to be true. If so, a 2 accelerometer solution could lead 
to a 
fix. Mounting another accelerometer inverted on the old one and using its 
inverted 
signal to couple with the original. 

I'll dig the datasheet

Original comment by manavkataria on 14 Jul 2009 at 5:53

GoogleCodeExporter commented 9 years ago 
In reply to comment#9: 

Datasheet says response is supposedly linear. I am operating at 3.3V :(

Datasheet > page#3 > Operating Characteristics > point#3:
"Within the supply range of 2.2 and 3.6 V, the device operates as a fully 
calibrated 
linear accelerometer. Beyond these supply limits the device may operate as a 
linear 
device but is not guaranteed to be in calibration."

http://www.freescale.com/files/sensors/doc/data_sheet/MMA7260QT.pdf

Original comment by manavkataria on 14 Jul 2009 at 6:26

GoogleCodeExporter commented 9 years ago 
In reply to comment#10:

Anybody understands what does 'Nonlinearity, XOUT, YOUT, ZOUT' mean on the 
datasheet > 
page3 table? 

Need some help with this

Original comment by manavkataria on 14 Jul 2009 at 6:37

GoogleCodeExporter commented 9 years ago 
 I have a comment here. Gautam made a good point about the DC.  
 I was thinking about cancelling the effects of DC by estimating the offset during
the calibration phase. Of course, the user is expected to move the mouse during
calibration. If we have an estimate of th DC offset, we can process the signal 
sample
by sample. I mean, no 'if' condition in the signal processing loop. 

 Forcing the velocity to zero when acceleration is zero for a long time might
not be a good idea. Because, you have already processed the samples before you 
know
acceleration has become zero for a long time. It might work during the offiline
processing, but when we do it in realtime, I am afraid it might lead to trouble.
There is one possibility though, we can use a predictor to predict when the
acceleration goes to zero and take action accordingly. This is where an LPC 
might
come in. But we need a really good model for that. 

I have attached the comparision of integration before and after filtering. 
Red is the acceleration, green is the velocity without filtering and blue is 
after
filtering. 

The reason I think Gautam is right is, if you notice the first and second
acceleration spurts, they are almost equal in length and the jumps in the 
velocity
are almost equal. 

Will provide the code soon. I'm handicapped without my laptop :(

Original comment by mahadesh...@gmail.com on 14 Jul 2009 at 7:53

Attachments:

GoogleCodeExporter commented 9 years ago 
Improving the response of an accelerometer by using optimal filtering

URL: http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6THG-42BSJ47-
2&_user=444230&_rdoc=1&_fmt=&_orig=search&_sort=d&_docanchor=&view=c&_searchStrI
d=95689
2651&_rerunOrigin=google&_acct=C000021138&_version=1&_urlVersion=0&_userid=44423
0&md5=2
997c3e7065d161035729851d35bc19a

Original comment by manavkataria on 14 Jul 2009 at 10:57

GoogleCodeExporter commented 9 years ago 
ITP Sensor Workshop - Article on Typical Behavior of the Freescale Acceleromter 
MMA7260Q:
http://itp.nyu.edu/physcomp/sensors/Reports/MMA7260Q

Original comment by manavkataria on 19 Jul 2009 at 2:09

GoogleCodeExporter commented 9 years ago 
Accelerometer Log and Matlab graphs for accelerometer data for noise 
estimation: 
Z-lift samples (misnomer)
Stable no-touch samples

Original comment by manavkataria on 20 Jul 2009 at 5:13

Attachments:

GoogleCodeExporter commented 9 years ago 
Z-Axis no-touch sample data. Panju, would you please edit the jpegs and type 
the mean 
and variance on them.

Original comment by manavkataria on 20 Jul 2009 at 10:18

Attachments:

GoogleCodeExporter commented 9 years ago 
Sample 1:
   Mean = 328.2
   Covariance = 0.6
Sample 2: 
   Mean = 329.1
   Covariance = 0.4
Sample 3: 
   Mean = 327.5
   Variance = 0.27

Mean is almost constant. I think we can remove the DC and make it zero mean.
But the covariance is changing a lot, this means that it is not stationary...

Original comment by mahadesh...@gmail.com on 20 Jul 2009 at 11:35

Attachments:

GoogleCodeExporter commented 9 years ago 
GOOD NEWS: 
Based on my recent tests, I observe a variation of 5-10 points on output with 
small 
tilts. When accumulated over few hundred samples this would obviously affect 
the mean 
and slope of the velocity curve. 

flat on ground - 303
held up in air - 312 (natural holding position)

In conclusion, if you hold the accelerometer up in the air, you are bound to 
tilt it. 
And it is bound to affect your velocity graph in an undesired way.

Original comment by manavkataria on 20 Jul 2009 at 7:52

GoogleCodeExporter commented 9 years ago 
Attaching the result of yesterday's measurements.
Samples used to evaluate the mean makes a lot of difference in  the integration.
file: effectOfMean.jpg

Also, I have attached the integral of three Idle samples. There is no simple 
pattern
in these that may be used to evaluate the effect of mean. The mean of noise ( 
idle or
no touch samples) also seems to vary. 
file: integralOfIdleSamples.jpg

Original comment by mahadesh...@gmail.com on 21 Jul 2009 at 9:19

Attachments:

GoogleCodeExporter commented 9 years ago 
Also attaching the kalman filter code...

Original comment by mahadesh...@gmail.com on 21 Jul 2009 at 9:21

Attachments:

GoogleCodeExporter commented 9 years ago 
In reply to comment #19, file effectOfMean.jpg:

System Identification: 

Wht properties does it have?
+ DC Component aka Static Acceleration (due to tilt?) 
+ Dynamic Acceleration
+ Noise due to mechanical vibrations (jitter)
+ Anything else?

How do we condition the signal? 
+ Do we need to take the mean (DC component) and subtract from the signal? 

Mean Computation options:
++ Dynamically computed Mean of all values?
++ Mean of initial untouched (noise) values
++ Mean at regular intervals?

Original comment by sagarbho...@gmail.com on 27 Jul 2009 at 5:52

GoogleCodeExporter commented 9 years ago 
Notes from my meeting with Prof Arya:
 * Try using the mean from past few samples. Segment the data into blocks and use the
 mean in each segment/block.
 * Use of a reference measurement ( gyroscope etc...)
 * Possible effects of device stabilization
 * Experiment with increased sampling rate

Along with this we can "detrend" the velocity and position to cancel the 
constant
drift we have after the integration process (More thought needed).

--Panju

Original comment by mahadesh...@gmail.com on 29 Jul 2009 at 9:56

GoogleCodeExporter commented 9 years ago 
Uploading the result of dead-zone definition. basically if the signal within a 
small
range from zone it is clamped to zero. The signal is not changed if the signal 
level
is above outside the dead-zone. ( It is assumed that the mean of all samples 
has been
ale\ready removed from acceleration data. 

As can be seen from the picture, if we force the flat zone to zero there will 
be error.

Original comment by mahadesh...@gmail.com on 4 Aug 2009 at 11:42

Attachments:

GoogleCodeExporter commented 9 years ago 
Panju, I dont understand this very well:

1 How is this different from the Software deadzone filter we had in the VB 
driver? 
2 How good are these results? Do you see any improvements?
3 What happened to Detrending?

-- 
BTW, I met Suresh last night. He is here for convo. He didn't integrate 
acceleration 
for his project, he used a speedomeeter. I briefed him about our project. If 
you have 
specific questions we could talk to him.

Original comment by manavkataria on 6 Aug 2009 at 11:31

GoogleCodeExporter commented 9 years ago 
Exploring Non linear behaviour of acceleromter device (transducer) 
characteristics:

Questions:

NON LINEARITY: 
Does the device behave linearly for all accelerations values (acceleration due 
to 
gravity -vs- voltage)

Within a range (+/-) 1.5g the volatge to acceleration follows the relation: 
(For 1.5 g-select mode and assuming typical values at T =23 degrees Centigrate, 
Vdd = 
3.3 V).

v = .8a+1.65 volts 

The datasheet does mention about a non linearity of +/- 1% of full scale output 
range 
which when calculated with typical values gives (+/-) 0.0305 volts.

NOISE: 
Does the data sheet give any tips to eliminate noise from the accelerometer?
The datasheet doesnt say anything about how to elimate noise. But the typical 
noise 
values are given to be 4.7 mV(RMS) in a frequency range of 0.1 Khz- 1Khz.

(thanks to Vineeth.A and Ani Xavier)

Original comment by manavkataria on 4 Sep 2009 at 3:11

GoogleCodeExporter commented 9 years ago 
== Trend Analysis ==
I read here about a trending filter seems interesting. Panju would you like to 
try 
this on our No-Touch samples?
http://www.mathworks.de/matlabcentral/newsreader/view_thread/244102

"Perhaps you might benefit from looking at the Hodrick-Prescott filter:
http://en.wikipedia.org/wiki/Hodrick-Prescott_filter
It's used in economics to split a signal into a smooth "trend"
component, and a shorter duration "cycle" fluctuation. There is a
lambda parameter that lets you specify how smooth or accurate you want
the filtered signal to be (with respect to your original signal).
Perhaps it could be adapted and work in your situation."

Original comment by manavkataria on 14 Sep 2009 at 3:13

GoogleCodeExporter commented 9 years ago 
The mathworks page above even talks about splitting the signal into *periodic* 
and 
*non-periodic* components. 

Do you guys think that can help us for noise elimination/characterization or 
something?  
I wish I had taken a signal and systems course.

Original comment by manavkataria on 14 Sep 2009 at 3:16

GoogleCodeExporter commented 9 years ago 
Did anybody try Fourier Transform on our data?! Lets look at the spectrum!

Original comment by manavkataria on 15 Sep 2009 at 10:43

GoogleCodeExporter commented 9 years ago 
I am really starting to feel that a concrete analysis of our system is a need 
of the 
hour. Deconvolution is another technique which might be of help:
http://en.wikipedia.org/wiki/Deconvolution

Original comment by manavkataria on 15 Sep 2009 at 2:54

GoogleCodeExporter commented 9 years ago 
Manav, for the deconvolution we need a model of degradation. I think 
accelerometer
signal is corrupted by noise more than being degraded(by a filter)... I mean if 
we
are to try out deconvolution, we should have an idea of how the signal is being
degraded. Maybe a step ahead would be to understand the working of accelerometer
physically and see if can identify a source of degradation...

Panju

Original comment by mahadesh...@gmail.com on 16 Sep 2009 at 5:09

GoogleCodeExporter commented 9 years ago 
Had a wonderful discussion:

Use Moko and Wii

Few ideas and new TODOs:
1. Get new samples
2. Idle Samples Integration to find out a constant mean
3. Dynamic Samples (x-axis) integration to find out if velocity comes back to 
zero!
(Position estimation / velocity estimation successful!)

Original comment by manavkataria on 24 Sep 2009 at 4:57

GoogleCodeExporter commented 9 years ago 
I am uploading the matlab file I am using... 

Accelerometer samples(Z-axis) from Openmoko is in the variable 'acceleration'. 
See comments.

accel.m is the most recent.
accel0.m and accel1..m are the older versions.

Original comment by mahadesh...@gmail.com on 28 Sep 2009 at 5:46

Attachments:

GoogleCodeExporter commented 9 years ago 
Position estimation using mma7260QT FreeScale accelerometer

Application Note AN3397 Implementing Positioning Algorithms Using Accelerometers
http://www.freescale.com/files/sensors/doc/app_note/AN3397.pdf

Displacement Using Acceleromters - Discussion 
http://forums.freescale.com/t5/8-Bit-Microcontrollers/Displacement-using-acceler
ometer/m-p/25185

Original comment by manavkataria on 31 Aug 2010 at 6:10