Been searching for days, and can't wrap my head around the findings.
Has anyone here been able to parse the <acceleration.x, acceleration.y, acceleration.z> over the update (time) interval, and been able to measure the velocity (magnitude only) of the iPhone as you "wave" it through space?
I am trying to accomplish the effect of the Wii remote in the game "Boom Blox":
Once locked on a target (direction component) by holding the trigger, you swing the remote back and then FORWARD and let go (an iPhone "event") in order to "RELEASE" the bowling ball or baseball at a variable VELOCITY.
I'm curious to know any (inexpensive) approach to calculating a magnitude based on the "speed" you WAVE the wand through space (using acceleration data)...
I was just wondering if you ever came up with a solution to your post? I'm wondering how to calculate the speed that the iphone is moved for a certain amount of time. Thanks!
I was never great at calculus, but I think you want to integrate the acceleration data to arrive at velocity.
I wouldn't know how to do that though. Why don't you fudge it, and sum all the acceleration vectors together (minus gravity), and then take the magnitude of that vector.
I was never great at calculus, but I think you want to integrate the acceleration data to arrive at velocity.
I wouldn't know how to do that though. Why don't you fudge it, and sum all the acceleration vectors together (minus gravity), and then take the magnitude of that vector.
I tried to do something close to what you suggest; but it boiled down to the fact that the iPhone accelerometer is not that accurate and has many phantom spikes on axis that shouldn't have them (see my other post where I created a nigh-frictionless environment to prove this). When you integrate faulty values the errors magnify hugely = mess. I actually wanted displacement = double mess.
I tried to do something close to what you suggest; but it boiled down to the fact that the iPhone accelerometer is not that accurate and has many phantom spikes on axis that shouldn't have them (see my other post where I created a nigh-frictionless environment to prove this). When you integrate faulty values the errors magnify hugely = mess. I actually wanted displacement = double mess.
Well, if that's the case you'll need to filter out these phantom spikes no matter what method is used to interpret the data.
Well, if that's the case you'll need to filter out these phantom spikes no matter what method is used to interpret the data.
What I am saying is that the accelerometer data is too inaccurate and seemingly random to filter it in a logical way. I am physics professor and know how to do these things; it just doesn't work right with the iPhone's accelerometer. Perhaps if I wanted to spend months dedicated to create algorithms that factor in the iPhone's wonky readings (not even to mention that every iPhone is miscalibrated differently!) I'd be able to get something halfway terrible; but I'm not currently willing to spend that time.
As far as I understand any attempt to do this in a small scale way (not calculating avg velocity driving in your car etc) has failed; if you can do it that would be amazing and I wish you luck!
What I am saying is that the accelerometer data is too inaccurate and seemingly random to filter it in a logical way. I am physics professor and know how to do these things; it just doesn't work right with the iPhone's accelerometer. Perhaps if I wanted to spend months dedicated to create algorithms that factor in the iPhone's wonky readings (not even to mention that every iPhone is miscalibrated differently!) I'd be able to get something halfway terrible; but I'm not currently willing to spend that time.
As far as I understand any attempt to do this in a small scale way (not calculating avg velocity driving in your car etc) has failed; if you can do it that would be amazing and I wish you luck!
I think this depends on your goals. If you're trying to calculate displacement/position accurately, the accumulated error is probably too great. The OP simply wants magnitude of velocity though, and I think that is achievable.
I think this depends on your goals. If you're trying to calculate displacement/position accurately, the accumulated error is probably too great. The OP simply wants magnitude of velocity though, and I think that is achievable.
True, you could probably get it roughly; but if you want to detect just "waving through space" can't you do that with the raw accel data just fine?
Yeah, all things considered you essentially want velocity = distance / time. If I was going to approach it, I would say getting the samples from the accelerometer with a threshold ( ie +- 0.4 or more ) and getting the average of those would be a decent indicator of force - you could use those to fudge in for "distance". On your backswing, start counting time when they pass that threshold in the one direction and throwing the values into an array on each reading. Once it passes the threshold in the other direction, count that as a forward stroke, stop the first time, start the second timer and start putting values onto the other array.
When they release the button, do your averages and use the total time on each to get an effective velocity. For something like bowling or golf you could even discount the backwards velocity, as you only need to know that they _had_ a windup.
Wouldn't be perfect, but probably enough of an approximation for most game applications - and with the averaging those spikes shouldn't have such a negative effect, especially if you up your sample rate.
Yeah, all things considered you essentially want velocity = distance / time. If I was going to approach it, I would say getting the samples from the accelerometer with a threshold ( ie +- 0.4 or more ) and getting the average of those would be a decent indicator of force - you could use those to fudge in for "distance". On your backswing, start counting time when they pass that threshold in the one direction and throwing the values into an array on each reading. Once it passes the threshold in the other direction, count that as a forward stroke, stop the first time, start the second timer and start putting values onto the other array.
When they release the button, do your averages and use the total time on each to get an effective velocity. For something like bowling or golf you could even discount the backwards velocity, as you only need to know that they _had_ a windup.
Wouldn't be perfect, but probably enough of an approximation for most game applications - and with the averaging those spikes shouldn't have such a negative effect, especially if you up your sample rate.
Ex you nailed it; this is exactly what I have done in a previous app
Did anyone found a solution ?
I'm quite interested in creating a positioning system with accelerometer, gyroscope and compass and i'm having the same problem...
Accelerometer and iPhone Velocity?
Linear Mode
