Velocity isn't working through computational integration

91 views Asked by At

Disclaimer: I'm a total noob and not much of a coder.
I have a 10DOF IMU. I'm trying to get the velocity of a the sensor. I understand on a surface level the limitation of sensors with drift etc... I will walk you through my train of thought.

This double array holds the XYZ values of my accelerometer. This is linear-acceleration numbers, an algorithm has accounted and taken out the gravity factor.

accelCompoDoub[0] = parseDouble(accelCompoString[0]);
accelCompoDoub[1] = parseDouble(accelCompoString[1]);
accelCompoDoub[2] = parseDouble(accelCompoString[2]);

My app will track elapsed time and will also need deltaT. DeltaT will be used to computationally integrate acceleration.

currentTime = System.nanoTime();
if (startTime == 0.0 && previousTime == 0.0){
      startTime = currentTime;
      previousTime = currentTime;
    }else{
    deltaT = currentTime - previousTime;
     }


runningTime = currentTime - startTime;

runningTime = TimeUnit.NANOSECONDS.toMillis(runningTime);
runningTimeDouble = runningTime/1000.0;

Converted from nano to micro and not to milli. The reason being was that my data encountered a lot of 0.0's.

deltaT = TimeUnit.NANOSECONDS.toMicros(deltaT);
deltaTDoub = deltaT/1000000.0;
previousTime = currentTime;

This is where velocity = velocity + (accel) * (change in time)

velocityComp[0] += accelCompoDoub[0]*deltaTDoub;
velocityComp[1] += accelCompoDoub[1]*deltaTDoub;
velocityComp[2] += accelCompoDoub[2]*deltaTDoub;
Log.i("Velocity", Arrays.toString(velocityComp));

My results as I'm moving the sensor up at a rapid speed on the z axis. This isn't right and I've tried to correct it. Thanks for helping me out. Let me know if additional info is needed.

Results from calculations.

I/Velocity: [-0.063722465, -0.132597938, 0.06367645599999999]
I/Velocity: [-7.25024E-4, -0.0018097799999999998, 5.87136E-4]
I/Velocity: [-8.90561E-4, -0.0026836670000000003, 3.80492E-4]
I/Velocity: [-7.223840000000001E-4, -0.002324192, -8.8788E-5]
I/Velocity: [-0.0014603620000000002, -0.0046326660000000006, -0.0013441560000000002]
I/Velocity: [-0.056317518, -0.161929746, -0.10376649000000002]
I/Velocity: [-5.45706E-4, -0.001396428, -0.001515708]
I/Velocity: [-0.00108585, -0.00286045, -0.0047196]
I/Velocity: [-0.001350592, -0.00551372, -0.010952008000000001]
I/Velocity: [-0.027746648999999998, -0.12593060399999997, -0.285394104]
I/Velocity: [-3.4505000000000007E-4, -9.82105E-4, -0.003035925]
I/Velocity: [-3.19982E-4, -0.00120291, -0.004499598]
I/Velocity: [1.67466E-4, -0.001290081, -0.004254081]
I/Velocity: [7.457259999999999E-4, -0.0025310280000000003, -0.007799432000000001]
I/Velocity: [0.016570047999999997, -0.099231992, -0.27039305599999996]
I/Velocity: [-1.6146000000000002E-4, -0.0014244750000000001, -0.00291915]
I/Velocity: [-8.8816E-4, -0.002367105, -0.003107767]
I/Velocity: [-0.001062369, -0.001895124, -0.001395471]
I/Velocity: [-0.0028341610000000004, -0.004603984, -0.001379862]
I/Velocity: [-0.130232, -0.2220188, 0.0293022]
I/Velocity: [-0.00333146, -0.00568062, 0.003315785]
I/Velocity: [-0.00167499, -0.0026628819999999997, 0.002802716]
I/Velocity: [-0.0020831459999999997, -0.0031751069999999995, 0.005024214]
I/Velocity: [-0.001439764, -0.002181253, 0.004799388999999999]
I/Velocity: [-0.12709468599999998, -0.134937772, 0.47205287199999996]
I/Velocity: [-8.29008E-4, -4.7601299999999996E-4, 0.0031751369999999998]
I/Velocity: [-9.500479999999999E-4, -1.14048E-4, 0.0034474880000000003]
I/Velocity: [-0.001443932, 2.46308E-4, 0.00481496]
I/Velocity: [-0.0042386279999999995, 0.001372604, 0.012284638]
I/Velocity: [-0.10745787999999999, 0.025316348, 0.27256053799999996]
I/Velocity: [-9.26115E-4, -5.916E-5, 0.00209409]
I/Velocity: [-0.0018333919999999999, -6.785679999999999E-4, 0.003609672]
I/Velocity: [-5.516159999999999E-4, -3.88362E-4, 9.315279999999998E-4]
I/Velocity: [-0.001341424, -0.001413168, 0.0021391039999999997]

P.S: I also tried to limit the sample so that the deltaT is approximately .01 seconds.

1

There are 1 answers

0
Ru3di On

Your acceleration values on the x and y axis appear to be small, which is a good point if you moved in the z axis. Keep in mind that, unless your movement is guided, the velocity on these axis will never be zero.

Considering the values on the z axis, I would check the deltaT you are multiplying the samples with. It should be equal to the inverse of your sensor's sampling frequency. For example, if f_s = 100 Hz, deltaT = 0.01 s. If you are using a descent sensor, this value should be almost constant in time. Also, why use the system time and not the timestamp which is probably provided with every sample?

Finally, but maybe the most important:

This is where velocity = velocity + (accel) * (change in time)

Your reasoning is correct... in theory. Apart from the bias of the gravity, which you said is removed, the problem is that your signal contains noise. As you mentionned, the integration will drift over time because you integrate the noise included in your signal. The numerical integration of an acceleration signal will not give you a proper velocity unless you have a way to remove noise before doing it. If you really need to integrate this signal, try to filter it. The best option being to fuse it with another type of sensor (optical?) to use the acceleration instead of the velocity, but I doubt it is possible if you are developping an app for a mobile device...