Is there a way to calibrate accelerometer on C-boards?

mikesv

Hi,

I have two identical C-boards programmed to calculate and log average RMS every 10 minutes on ZTE Android phone that Eric helped me to set up.

I've noticed that the boards are showing different averages. To test how different they are I've placed them both next to each other on the  table with brand new batteries installed for about 8 hours. After I retrieved logs the numbers fluctuated from 571.777- 574.402 on the first and 519.714 -522.156 on the seconf. Also the first one was missing one data point. It is almost 10% difference. Hence the question: is it possible to calibrate boards so they  show same range of numbers?

Thank you,
Michael

Eric

How fast are you running the accelerometer again?  Also, if you are looking at the raw accelerometer data, do you also see these differences in values?

I imagine this could be a firmware performance issue where the data processor has a ton of transformations to perform given the frequency as which accelerometer data is fed in.

mikesv

the rate is 12.5.  

here is my code:

accModule.setOutputDataRate(12.5f);
accModule.setAxisSamplingRange(2); Log.i("tutorial", "programmed"); final float tot=0; mwBoard.removeRoutes();
accModule.routeData()
.fromAxes()
.process(new Rms())
.process("accum_proc", new Accumulator((byte) 8))
.process(new Time(Time.OutputMode.ABSOLUTE, TIMER)) // 600000-10 min debug 5000
.process(new Maths(Maths.Operation.DIVIDE, DIVIDER)) //7500 - 30*12.5=375 debug 62.5
.monitor(new DataSignal.ActivityHandler() {
@Override
public void onSignalActive(Map<String, DataProcessor> processors,
DataSignal.DataToken token) {
processors.get("accum_proc").setState(new Accumulator.State(0));　
}
})
.log("acc_stream")
.commit()

mikesv

Our testers are wearing both sensors now, when I get them back I will post raw numbers.

Could it be related to the board orientation? They weren't flat on the table.
Also do you think I should use  High Pass Filter to get a better accuracy by removing gravity?

Eric

RMS doesn't change in relation to orientation provided the vector magnitude is the same.  Hrhm, perhaps trying this alternative method for averaging might be better since it would be based on sample count.

.process(new Rms())
.process("avg", new Average((byte) 8)).monitor(new DataSignal.ActivityHandler() {
    @Override
    public void onSignalActive(Map processors, DataSignal.DataToken token) {
        processors.get("avg").setState(new Average.State());
    }
})

High pass filter is a good idea.  Unfortunately, only the R accelerometer has a HPF built into their chip so you will have to write your own in your app.

mikesv

Thank you Eric, I will try this code and the scheduling piece next week when I get boards back.
Even with these issues we are getting great results supporting our idea and planning to buy few more boards to expand our testing base. Do you know if "Meta Health" will be more accurate and appropriate for our case? Will I have to rewrite my Android app for it? If we decide to buy R-boards instead is there an wristband enclosure? It looks big and power hungry.

Also we discussed this in the different thread but I am still losing log entries, very random and happens on both boards.  Hopefully the next firmware update will solve this.

 Thank you!
Michael

Eric

MetaHealth uses the same Bosch IMU as the RPro.  Unless you need heart rate and GSR, the R series is fine for what you need.

R and RPro have the same dimensions; the wristband will work for all R series.

Yes I have filed a bug on this issue for the firmware developer.  I can't promise it will be in the next release as there are already plenty of changes piled up for the next build.

mikesv

Hi Eric,

I finally got the boards back and used your code but the results are better but still different . One sensor is showing .571  and another is .591  although both are lying still on the table for several hours.

I guess I have to live with this. I've added accumulator and timer. My previous setup was giving me averages at certain times that were even below when the boards were still. Very strange. I am collecting data every 10 minutes from June 26th.  I will be using the code below from now on:

mwBoard.removeRoutes();

accModule.routeData()
        .fromAxes()
        .process(new Rms())
        .process("avg", new Average((byte) 8))
        .process("accum_proc", new Accumulator((byte) 8))
        .process(new Time(Time.OutputMode.ABSOLUTE, TIMER))
        .monitor(new DataSignal.ActivityHandler() {
            @Override
            public void onSignalActive(Map<String, DataProcessor> processors,
                                       DataSignal.DataToken token) {
                processors.get("avg").setState(new Average.State());
                processors.get("accum_proc").setState(new Accumulator.State(0));
    }
})

Thank you VERY much,

Michael 

mikesv

Hi Eric,

Thank you for all your help.  Here is an example how xyz values look like  when I flipped the board:  

 http://imgur.com/a/UtJIY

I am trying to identify the "energy" of the movement. When a sensor turns I don't want to see 20% spike. I thought RMS is taking care of it.  When you said I should use offset from the base numbers did you mean 0 and 0.7 or deltas between values?
Thank again,
Michael

Eric

RMS for a 3 value vector is equivalent to computing the vector magnitude and divding by sqrt(3). Given that the xyz values have different magnitudes, it is expected the RMS values will differ hence the suggestion that you should treat the at rest RMS values as a reference point not as an absolute value.

Since you are accelerating the board to turn it, the RMS values during the rotation will change.

mikesv

Thank you Eric for the quick response.

"you should treat the at rest RMS values as a reference point not as an absolute value" - how do I exactly do that if I want to compare two boxers for example. Horizontal punches will be 20% different from vertical ones for same force. The numbers also will change when they flip sensors on their arms.
I was following your blogs http://projects.mbientlab.com/data-processing-with-metawear/ , YouTube videos and other white papers and they all are using absolute values.
I do understand that the gravity vector will distort results when directed between axis but I didn't expect this to be that significant for the 6 axis accelerometer. I guess I need to use Gyro to compensate. Do you have any code samples? 

Thanks again,
Michael

Guarneri

Hi Michael,

First I would recommend using a high pass filter to get rid of gravity in your data. This will likely reduce the variance in RMS by a lot. I also wouldn't worry too much about the % variance of RMS in a stationary position. In almost all cases, a punch will generate such high amounts of acceleration relative to a stationary object that the stationary RMS is basically irrelevant when comparing the energy of punches.

If you're interested in further technical support, we do offer algorithmic consulting at an hourly rate. You can contact me directly at yu@mbientlab.com.

Thanks,

Yu