## good idea/medium idea/not worth it idea

good idea
3
100%
medium idea
0
not worth it idea
0

EnduroRacer
Joined: 12 Jul 2012, 15:49
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.

WifiLapperDev
Joined: 06 Jun 2012, 12:09
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.

EnduroRacer
Joined: 12 Jul 2012, 15:49
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.

WifiLapperDev
Joined: 06 Jun 2012, 12:09
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.

EnduroRacer
Joined: 12 Jul 2012, 15:49
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.

WifiLapperDev
Joined: 06 Jun 2012, 12:09
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.

rbeam
Joined: 10 Sep 2012, 19:09
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. )

EnduroRacer
Joined: 12 Jul 2012, 15:49
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.

jawillis
Joined: 13 Jul 2012, 10:44
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

wonder99
Joined: 15 Jul 2013, 01:20
These and other improvements have been made to the accelerometer in version 1.38:
1. the sensor can now be calibrated. Press calibrate while the phone is laying perfectly flat (e.g. on a table). Sensors normally have some slight offset, which will then be eliminated
2. the angle of the car mount can be compensated. Instructions are given within the app. The result is that the X-accel channel is turning force, Y-accel is braking/acceleration, and Z-accel is 'floating'.
3. the samples are pre-smoothed, and submitted/stored at 4Hz max