Hello! In the past days, i’ve been playing with my phone accelerometer to try to translate it motion to in game motion but i’m having troubles doing so. When moving the device and stopping abruptly, the velocity will go down/up (depending on the direction) and then drop down before going up a bit with the acceleration.
local UserInputService = game:GetService("UserInputService")
local OldST = os.clock()
local Vel = 0
function AccelerationToVelocity(InitalVelocity, Acceleration, Time)
return InitalVelocity + Acceleration * Time
end
UserInputService.DeviceAccelerationChanged:Connect(function(Acceleration)
local TT = os.clock() - OldST
OldST = os.clock()
Vel = AccelerationToVelocity(Vel, Acceleration.X, TT)
end)
This is the approximate code ( whitout math to rotate the acceleration ). What am I doing wrong?
I’m not quite certain what you are actually trying to achieve, as I’d need a pre-existing or visual example to work with. You seem to understand what velocity is (Initial velocity + acceleration over time), so that’s not the problem either.
However, I would like the point out, os.clock shouldn’t be used as a timer. At least not like this. It is useful for benchmarking, as it gives the processor has been using lua. However, for actually getting the time you can use either the user’s device time or the in-game time, using tick() or time() respectively.
Around part A you’re holding your phone still- ish. At B you’ve begun accelerating it, but of course acceleration is never instant so it’s still building up speed. Just before C you’re decelerating it, but you don’t go to a stand still instantly because that’s impossible. At C you’re going the other way because you’re overcompensating a bit to make it stop faster. Around the other part A (derp) you’re holding the phone still- ish again.
It’s really impossible to say anything about the data without correlating it to your actual movements though.
Your math is correct though, AFAICT. You might want to try smoothing out the velocity by integrating over more than just 1 time step. I.e. store the last 2 or more acceleration values, and use the average of those to compute the change in velocity each time step.
It looks about right to me. Remember that acceleration is simply the rate of change of the velocity, so with no acceleration, the velocity remains unchanged. Negative acceleration decreased velocity while positive acceleration increases it.
This requires actual calculus mathematics if you want an exact answer.
Think about how function f represents position, then df(x)/dx is velocity, and df(x)^2/d^2f(x) is velocity.
To find the velocity, you need to find the anti-derivative of acceleration.
If you want to approximate this, then you can think about how acceleration is the CHANGE in velocity, in the same way that velocity is the CHANGE in position. To get this approximation, take the acceleration and divide by time.
Ho crap, thats my error! The lines threw me off. So your right, the graph match how the velocity should evolve but the acceleration received from the accelerometer doesn’t reflect the real one. This is the issue i’m having right now. Even when I “imobilise” the device after moving, the velocity will not totally go down.
I’ve read things about accelerometer noise and drift but i’m not even sure if this is the cause to all of this.
From my experience with accelerometers and gyroscopes, they are pretty bad at calculating odometry (as in they have lots of drift) after about 30 seconds of calibrating. Now that’s for these cheap ones used on high school robots but a way to combat that is to put a fast fourier transform filter such as total-variation denoising. Totally depends on your end goal, if you have a way to get feedback in your system then kalman filters are better. Total variation denoising - Wikipedia Kalman filter - Wikipedia
Thanks! I won’t be able to use Kalman filter because the data will be translated in real time but the other one can be used.
Another thing, if you look at the graph, when the acceleration becomes 36 the velocity also go up but then, it stops making sense because it deccelerates but the matching dot shows that it did the opposite. Also, if you sum up all the deccelerating forces/values it will give ~-36 which should make the velocity go down to what it was before but result in ~1.5 of diminution.
Currently, the behaviour that I described is the major preocupation.
