Is it possible to determine the speed at which someone is shaking their iPhone? This would be the time they start moving to the ending point where they are now going back to the origin. Basically it is one swipe that I'd like to measure the speed of. This discussion comments on initial speed: http://discussions.apple.com/message.jspa?messageID=8297689#8297689. It seems that the important component of distance is lacking in the iPhone to get a good measure of speed.
Sure, it sounds like all you'd need to do would be to numerically integrate the acceleration twice to get the distance traveled. For instance, look at
Calculate the position of an accelerating body after a certain time
Note that you'll have to subtract gravity from the measured acceleration to get the kinetic acceleration, which is what you should integrate. As for how to do that, re: GoatRider's comment: I might try storing the last measured acceleration whose magnitude was equal to gravity (I think that's 1 in iPhone units?). Then for each acceleration measurement you make whose magnitude is greater than 1, subtract the last known acceleration of gravity - this will need to be a vector subtraction - and use that as the kinetic acceleration. Of course, this assumes that the user keeps the phone in the same orientation throughout the swipe, which I think would be approximately true.
Unfortunately, there's no technique you can use to distinguish between gravitational acceleration and kinetic acceleration in general - that is, a determined user could always find a way to fool whatever algorithm you might come up with. (Trivia: that's called the equivalence principle, and it's the foundation of Einstein's theory of general relativity)
You'll have to do the calculations yourself. Each acceleration event you receive will tell you the relative G-forces registering on the accelerometer and the time at which the event was recorded. You'll have to sample over several events and interpolate. Here's more info on the acceleration event itself:
UIAcceleration Class Reference
Related
Description of the situation
I want to use the BOSCH BMI160 sensor to check the speed of the vehicle on the go.
GPS is not available in the current situation.
Question
What is the formula for getting velocity from a 3-axis acceleration sensor?
Is there an error of more than 10% when an error occurs in an uneven area of the hill or the ground?
Resources
BOSCH BMI160 DataSheet : https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMI160-DS000.pdf
Thank you
What you want to do is called "inertial navigation", which is an error prone technique, by nature.
The operation you need is 3 axis accelerometer integration and 3 rotation integration, to get the heading and speed of your system. Moreover you need your initial state (speed and orientation) from which your integration should start. It is not at all a simple operation, and errors accumulate with time, and depend from many factors (starting from the accuracy of the sensor).
If you don't need the heading and you just care about linear speed in the direction of the car, you can reduce to single axis integration in the car direction, which is simpler, and may work well for a short period of time. Due to gravitational acceleration, you could have problems when going up-or-down-hill, because you will have to get rid of the average acceleration
I need to create an app that Calculates the moving car velocity/speed, with x/y/z speed.
My idea is using device's accelerometer.
I am using Sensor.TYPE_ACCELEROMETER and getting ax,ay,az (acceleration in x,y,z direction). how to get sped of device. Lots of physics formulas suggested by people to get speed but any one of then not giving correct speed compared to GPS. Please tell me code or good link which solve my problem.
That would be very difficult. To calculate the speed of the device, you need to calculate the integral of the acceleration. But to do so, you need to very accurately know for very dense points in time both the device's rotation and its acceleration. Assuming you do have those things, you simply need to take the device's initial speed, and for each point in time add to it (rotation matrix * acceleration vector * time to next measurement). That's probably the most accurate thing you can that is simple enough.
The apple documentation for UIAcceleration class says,
"When a device is laying still with its back on a horizontal surface, each acceleration event has approximately the following values:
x: 0
y: 0
z: -1"
Now, I am confused! How can the acceleration be non-zero, when you clearly say the "device is laying still"?
UPDATE
Judging by the responses, I think this should be called something like 'forceometer' or 'gravitometer' and not accelerometer!
You get a -1 on the Z axis because gravity is acting on the device, applying a constant acceleration of 1G. I assume you want user acceleration, which you can get from the DeviceMotion object using a device motion handler as opposed to an acceleration handler. The userAcceleration property filters out the effects of gravity on the device and only gives you how much the user is accelerating it.
I found the answer [in the CoreMotion Reference guide, thanks to bensnider:
The accelerometer measures the sum of two acceleration vectors: gravity and user acceleration. User acceleration is the acceleration that the user imparts to the device.
You'll find the best answers in datasheet of the accelerometer used (LIS302DL).
It measures the gravity. The unit is chosen so that the gravity, 9.81 m/s^2, equals 1 unit. The sign tells how the phone axis is directed. In other words, what the phone considers downwards.
The phone measures 0 as acceleration in free fall. I don't know how much you want to throw your phone up and down to test it :)
When you're sitting, gravity is pulling you down to your chair. If it weren't for the chair or ground for that matter, you'd be falling down with acceleration of about 9.8m/s^2. In order for the chair to prevent you from falling down, it has to act with a force in the opposite direction with at least the same value.
The accelometer shows the value of the pulling force and it's a three-dimensional vector. In this case it's directed straight down. And the value given is expressed in G, units of gravity acceleration multiplied by that value.
Answerers keep missing the right wording that should set it straight for you... The device is "laying still" only relatively to you. It is actually not laying still at all. The http://en.wikipedia.org/wiki/Centripetal_force of gravity gives it (and you) centripetal acceleration. It is real, it is what keeps you from flying off Earth on a tangent, and it is what the accelerometer dutifully shows. (Earth is nothing special - we rotate about the Sun also etc etc, whose centripetal accelerations are way smaller, but they would be all shown by an accelerometer sensitive enough.)
I don't yet have sufficient reputation to reply directly to the comment by #gigahari above, but as an addendum, folks should be aware that some apps (such as the physics apps phyphox and PhysicsToolbox Sensor Suite) do not report (a+g) -- both phyphox's "with g" option and PhysicsToolbox report the vector sum (a-g), which is sometimes referred to as the "Operational Definition of Weight." A brief discussion of this version of the operational definition of weight is on WikiPedia, at https://en.wikipedia.org/wiki/Weight#Operational_definition
I'm concepting an iPhone app that will require precise calibration to the iPhones accelerometer and gyro data. I will have to simulate specific movements that I would eventually like to execute code. (Think shake-to-shuffle, or undo).
Is there a good way of doing this already? or something you can come up with? Perhaps some way to generate a time/value graph of the movement data as it is being captured?
Movement data being captured - see the accelerometer graph sample app, which shows the data in real time: http://developer.apple.com/library/ios/#samplecode/AccelerometerGraph/Introduction/Intro.html
The data is pretty noisy - the gyro and accelerometer aren't good enough right now to be able to track where the phone is in local 3d space, for example. The rotation, however, is very solid, and the orientation of the device can be pretty accurately tracked. You may have the best results making gestures out of rotation data instead of movement along an axis. Or, basic direction like shakes along an axis will work as Jacob Jennings said.
A good starting point for accelerometer gesture recognition is this tutorial by Kevin Bomberry at AblePear:
http://blog.ablepear.com/2010/02/iphone-sdk-shake-rattle-roll.html
He sets a blanket threshold for the absolute value of acceleration on any axis. I would generate an 'event' for the axis that had the highest acceleration during the break of the threshold (Z POSITIVE, X NEGATIVE, etc), and push these on an 'event history' queue. At the end of each didAccelerate call, evaluate the queue for patterns that match a gesture, for example:
X POSITIVE, X NEGATIVE, X POSITIVE, X NEGATIVE might be considered a 'shake' along that axis. This should provide a couple different gesture commands.
See the following for a simple queue category addition to NSMutableArray:
How do I make and use a Queue in Objective-C?
I'd like to build a game to learn cocos2d. Lunar lander is the first exercise coming in my mind. Any pointer/source code/tutorial of the physics calculations required will be appreciated. Thanks!
You'll need stuff like this:
Newton's laws of motion in 2D.
Ability to change effect of gravity. 9.8 m/s^2 is the right acceleration on earth, but you should be able to change this to the appropriate value for Mars, moon, Jupiter, etc.
Ability to turn thrusters off and on to counteract the effect of gravity. Not a very interesting game if you don't, because every one ends in a crash.
Way to relate duration of thruster fire with fuel consumption. If you don't manage fuel well you crash.
Initial conditions (e.g., height above surface, initial velocity, initial fuel, etc.)
You'll start with initial conditions and loop over a number of time steps. At the end of each step you'll check the position and velocity. If the y-position above the surface is zero or negative you'll have landed. If the velocity is greater than a critical y-value you'll have a crash; less than the critical value means a safe, soft landing.
You'll solve Newton's equations of motion numerically. In your case it's four coupled, first order ordinary differential equations: rate of change of velocity in x- and y-directions and rate of change of position in x- and y-directions. If you have the thrusters in place you'll add another equation for conservation of mass for the fuel.
You can eliminate two equations if you assume that there are no x-components: the lunar lander moves perpendicular to the surface, the thruster force only has a non-zero component in the vertical direction. If that's true, you're down to three equations.
You'll do time stepping, so it'll be good to read up integration techniques like explicit Euler or implicit 5th order Runge-Kutta.
A challenging problem - not trivial. Good luck.
The math you need for a lunar lander game is pretty straightforward. Newton's Laws of Motion are all you really need - just pick up a basic physics textbook. You should be set after the first chapter. There are only two force inputs in the system - gravity and thrust from the engines. Just calculate the vertical & horizontal components of the motion, and animate your spaceship accordingly.
The physics are very simple: http://csep10.phys.utk.edu/astr161/lect/history/newtongrav.html
I assume you won't be worrying about drag or wind, so depending on your angles of inclination (user input), you'll be implementing:
Sourced from: http://en.wikipedia.org/wiki/Trajectory. You can even probably get away with simplifying it. If you don't want to be super-accurate, you can just do something like F=ma where is is whatever you decide the gravitational acceleration to be (9.8 m/s² on Earth).
If your game is in 2D, You don't need much math, you need physics, Specifically basic Newtonian motion. Probably intro college or late high school. The math is some grade school algebra with early high school calculus.
If you look at up-down motion, then your ship is essentially an object that is exposed to a force of gravity (the constant depends on your "moon") negated by the force emitted by its engines. You can use that to determine acceleration and from there velocity. Using the velocity, you can do your collision-outcome. The left-and-right motion is easier, since if your moon has no atmosphere, you are merely applying a constant force.
If you want something more realistic, you can modify the gravity constant based on distance from the surface, and can add an atmospheric friction force (though it wouldn't really be our moon).
If your game is in 3D, and your ship has side thrusters in addition to bottom thrusters, then you would not only have motion in location but also rotation. That has to do with rigid body physics. AFAIK that involves college level calculus.
This may be overkill, but I recommend looking at Numerical Recipes -- read the chapter on ordinary differential equations. You don't even need to study the entire chapter; just the first couple of sections.
In two dimensions, on every time tick you want to add the ship's rotational thrust to its rotational velocity, add its rotational velocity to its current heading, compute a thrust vector by multiplying the sine and cosine of its heading by its main thruster output, add that vector and a gravity vector (a straight downward vector of some magnitude) to its current velocity, and add its current velocity to its position. If the timer ticks are small enough, that's pretty much all you have to do, other than check to see if the craft is in contact with the ground. Experiment with the magnitude of your thrust and gravity values until you have a playable game.