Welcome
Welcome to wifilapper

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

App: Calibrate Accelerometer

good idea/medium idea/not worth it idea

good idea
3
100%
medium idea
0
No votes
not worth it idea
0
No votes
 
Total votes : 3

App: Calibrate Accelerometer

Postby EnduroRacer » Fri Jul 20, 2012 7:48 pm

Option to set current orientation of phone to static 0g,0g,1g.

As it is now, if the phone is tilted slightly when mounted in the car, the base Accelerometer readings are not accurate.
EnduroRacer
 
Posts: 337
Joined: Thu Jul 12, 2012 3:49 pm

 

Re: App: Calibrate Accelerometer

Postby WifiLapperDev » Fri Jul 20, 2012 7:52 pm

This is a good idea, but it's so complicated to implement properly. Figuring out the "down" vector isn't enough - you also have to figure out which direction is forward in order to get truly accurate lat/long readings. Basically, you need a way for the user to figure out and input the heading difference between their phone and their car. You could maybe do this automatically by using GPS, but then it calls the accuracy of the data into question, since you can't be sure the automatic process got it right.

The accelerometer on/off activity actually has (or had) a ton of commented-out code that did the down-vector determination, but I could never get the code figured out to actually use the down-vector, so I got rid of it.

If someone wants to help with the math (it shouldn't be that hard, I'm just rusty), it would be appreciated.

The math should involve projecting the sensed acceleration around the down vector (now its on a 2d plane that we know is parallel to the ground), and then rotating the resulting vector so that real forward-back accelerations result in longitudinal readings recorded.
WifiLapperDev
Site Admin
 
Posts: 546
Joined: Wed Jun 06, 2012 12:09 pm

Re: App: Calibrate Accelerometer

Postby EnduroRacer » Fri Jul 20, 2012 8:48 pm

It shouldn't really matter which way the phone is facing because the recorded g forces are just relative to how the phone was when at rest.

Right now the App expects the phone to be at-rest in the ideal orientation at values of x,y,z (10,0,0) m/s^2. If instead the phone is at-rest at (9.5, -0.2, 0.5) then correction values of (+0.5, +0.2, -0.5) should be introduced. If they are (-0.2, 9.5, 0.5) then the correction values are (+10.2, -9.5, 0.5). Please tell me I'm wrong because it seems too simple to work.

There are a couple apps on the Play Store that use at-rest calibration. One of them is a bubble level, the other is a Racing Data Acquisition app. I forget which one, probably Torque.

The bubble level app actually does differential calibration by having the user flip the phone end-to-end and averaging the 2 values to find true level just like purpose built digital levels. Great for setting camber values with a phone. Most bubble levels only calibrate to a "known level surface" whatever that is.
EnduroRacer
 
Posts: 337
Joined: Thu Jul 12, 2012 3:49 pm

Re: App: Calibrate Accelerometer

Postby WifiLapperDev » Fri Jul 20, 2012 10:02 pm

EnduroRacer wrote:It shouldn't really matter which way the phone is facing because the recorded g forces are just relative to how the phone was when at rest.

Right now the App expects the phone to be at-rest in the ideal orientation at values of x,y,z (10,0,0) m/s^2. If instead the phone is at-rest at (9.5, -0.2, 0.5) then correction values of (+0.5, +0.2, -0.5) should be introduced. If they are (-0.2, 9.5, 0.5) then the correction values are (+10.2, -9.5, 0.5). Please tell me I'm wrong because it seems too simple to work.

There are a couple apps on the Play Store that use at-rest calibration. One of them is a bubble level, the other is a Racing Data Acquisition app. I forget which one, probably Torque.

The bubble level app actually does differential calibration by having the user flip the phone end-to-end and averaging the 2 values to find true level just like purpose built digital levels. Great for setting camber values with a phone. Most bubble levels only calibrate to a "known level surface" whatever that is.

It's not just a matter of adding. Consider the extreme of if we have the phone mounted sideways, with the screen pointed at the driver door. The calibration would actually be the same at (10,0,0), but obviously the recorded values would need to be swapped. Same if the phone is 45 degrees with the screen pointed at the rear-left corner of the car.

The problem is that the gravity calibration doesn't give you all the data you need. In order to take a (x,y,z) acceleration in the phone coordinate system and convert it to an (x,y,z) vector in the car coordinate system, we need to apply a translation matrix. The gravity vector is just one part we need in order to do that. Unfortunately, I've forgotten all my linear algebra, so I'm not sure how to do the transformation. And even if I knew how, how do you make a user-friendly and accurate way to input the phone's exact orientation?

My whining aside, this is certainly something WifiLapper needs, but first it needs someone who has forgotten less math than I have.

Edit: Actually, this is something quite commonly done in graphics, so I can probably look up the math quite easily. Then the only problem becomes how to specify it from the user's perspective.
WifiLapperDev
Site Admin
 
Posts: 546
Joined: Wed Jun 06, 2012 12:09 pm

Re: App: Calibrate Accelerometer

Postby EnduroRacer » Sat Jul 21, 2012 1:12 am

I understand you now. The Accel data alone can not decipher the phone's angle in relation to the front of the car.

The trouble comes because if the phone is angled any amount from ideal (10,0,0), when the user drives in a perfectly straight line at 0.5g, it will be showing accel values on 2, probably 3 axes, not just the "correct" one, even with my at-rest correction values. You have to use the equation:

speed = SQRT(x*x + y*y + z*z) - 9.81

to get the actual Accel value in one direction, regarless of the phone's orientation, minus gravity.

WifiLapperDev wrote:And even if I knew how, how do you make a user-friendly and accurate way to input the phone's exact orientation?


How about if we calibrated the Accels in a 2 step process:
1. At-rest correction numbers from (10,0,0) to correct for vert/horz viewing angles (tilt & rotation)
2. Once the at-rest orientation numbers are taken, have the user drive in a straight line to set the relative Y axis. (actually the Z axis on the hardware)

I'm ready to admit defeat on this one. I see why you gave up. It seems really simple at first glance. Until you actually get down to writing the code and implementing an interface.
EnduroRacer
 
Posts: 337
Joined: Thu Jul 12, 2012 3:49 pm

Re: App: Calibrate Accelerometer

Postby WifiLapperDev » Sat Jul 21, 2012 1:27 am

The best idea I've heard or had for determining forward/back is pretty much what you suggest: either have the user drive in a straight line to do calibration once the phone it mounted, or have it do it on-the-fly based on compass and GPS data. If GPS says you're acceleration at (x,y,z) but your sensed acceleration is (a,b,c), then all you have to do is make a transformation from (x,y,z) to (a,b,c) that also works with the gravity vector and you're done. However, it bumps up against my linAlg shortcomings again.
WifiLapperDev
Site Admin
 
Posts: 546
Joined: Wed Jun 06, 2012 12:09 pm

Re: App: Calibrate Accelerometer

Postby rbeam » Wed Sep 12, 2012 8:54 pm

EnduroRacer wrote: Please tell me I'm wrong because it seems too simple to work.

You're wrong. :-) (not really.)

Imagine a cube moving within a cube. If the x-y-z axis of the inner and outer cubes aren't parallel, "forward" is not a single axis vector; moving forward will cause a force reading on more than one axis. If all three values are recorded, and there's a "resting" point for calibration, it can all be corrected in PitSide. (you don't need to waste time doing these calculations in the phone.)

[one more vote for keeping x-y-z for accelerometer and GPS; even if the GPS altitude number is 90% junk, I can decide if it's junk later. Sometimes, even the X and Y are junk.]

I'll have to hack something together to test this. [correction: AcMeter will record this junk for me. :mrgreen:)
rbeam
 
Posts: 11
Joined: Mon Sep 10, 2012 7:09 pm

Re: App: Calibrate Accelerometer

Postby EnduroRacer » Wed Sep 12, 2012 11:58 pm

Hey Art, looks like we found our math guy. Great to have you aboard rbeam.

rbeam wrote:even if the GPS altitude number is 90% junk, I can decide if it's junk later


I like the way you think.

Does anyone have any numbers for the accuracy of the accel in various phones? I tried making a calibrated level meter (swap ends and average) but couldn't make it work reliably on the Droid1 because of its floating screen hinge. Too much play. Maybe a slate phone would work better.
EnduroRacer
 
Posts: 337
Joined: Thu Jul 12, 2012 3:49 pm

Re: App: Calibrate Accelerometer

Postby jawillis » Thu Sep 13, 2012 8:58 am

Just to throw my 2 cents in...
I think a straight gravity-based XYZ calibration will work as well as anything.
My thinking is thus:
Providing the method and functionality to create a basic calibration is the responsibility of the application.
Making sure the phone is properly calibrated and mounted is the responsibility of the user.
If the mounting orientation is angled 12* in the fore-aft axis, then it's the user's responsibility to calibrate that axis with a -12* offset.
Don't know the orientation of your mounting location? Measure it!
The suggested method of measurement is open for discussion, but it seems to me that the users who actually care about accuracy will do what it takes to properly mount and calibrate the measurement tool.
If a user has a flimsy suction-cup mount attached to his windshield, the idea of accuracy is kind of out the window anyways, right?

However, I also think that there is a limit to how much accuracy we can reasonably expect from a (most likely) used or secondhand cell phone in a (hopefully) moving vehicle subject to roll pitch and yaw.
Who wants to start talking about gyroscopes and kalman filters?

-Jason
jawillis
 
Posts: 55
Joined: Fri Jul 13, 2012 10:44 am
Location: Pflugerville, TX


Return to Feature Requests/Development

Who is online

Users browsing this forum: No registered users and 0 guests

cron
suspicion-preferred