Can GPS on a phone, such as iPhone or Android determine your Z coordinates ?
I know it certainly has to be able to determine X and Y, well longitude, latitude that is, but what about the Z coordinates ? Can it determine your height, and can I obtain height relative to ground ?
Height, as measured by a gps, is relative to the WGS84 ellipsoid. The WGS84 is representative of the field where the gravity is the same, the geoid. Not quite the same as the ground.
You can determine altitude with iPhone using CoreLocation
http://developer.apple.com/iphone/library/documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html
Android surely can ... have a look at the features of e.g. MyTracks which include even evaluation profiles.
Altitude, however, is usually measured in "above sealevel", which means, that you could determine the distance from the ground by substracting the ground evaluation from your actual evaluation: ev(ground) - alt = distance(fromGround).
Related
Since acceleration is calculated relative to the phone, how can I convert this relative to the earth?
I believe I need to know what angle the phone is at (pitch) and then use trig to normalise the acceleration directions.
Gyroscopic data isn't helpful since it actually provides a rate of change, rather than the actual pitch.
I have tried using the aeyrium package as that should provide pitch and roll, but I believe the calculations to be wrong - having the phone vertically up or vertically down gives the same pitch but a different roll value, which is totally wrong.
Should I be using the magnetometer to get the pitch - would it even do that?
i am developing an app which is particularly dependent upon the distance between two iOS devices. I am using GPS location of devices to calculate the distance between them.
To calculate distance, i am using cllocation -distanceFromLocation method but the values generated by method is fluctuating and differs from actual distance between devices and cannot be considered even as an approximate result.
For example, if the actual distance between devices is 2 to 3 meters, it gives me the result around 14 meters at some point and 43 meters at another point. Is the the function -distanceFromLocation: is not so precise and accurate????
Is there any better alternative for calculating distance using GPS latitude and longitude of devices???
Please help me out.
Thanx in advance.
The accuracy of CoreLocation GPS varies greatly depending on your surroundings.
At it's most accurate it can go down to a couple of metres resolution (I'm not sure exactly) but if you're indoors it will be more like 20-50 metres.
I'm guessing that you're developing and testing the app indoors and so the fluctuations would be about normal.
Even outdoors in perfect weather CoreLocation will struggle to accurately tell you the distance between two devices over a short distance. (i.e. a couple metres).
For short range you might be better using wifi signal strength instead. Although this can also change from room to room.
Essentially, it's difficult to accurately detect the distance between two devices.
I made a simple app which displays the altitude according to the GPS position on iPhone.
How is the altitude obtained?
Does it get the altitude of the land at the coordinates I am or does it get the actual altitude? (I tried the same application in the same building; once at ground floor and once on the third floor but the same altitude is displayed)
Is it possible to obtain a different altitude on different floors? (Like my android phone has a barometer sensor and I calculate the elevation by the atmospheric pressure; but none of the iPhones has a barometer sensor)
The altitude as read by the gps receiver depends on the positions of the satellites over the horizon, relative to each other. It is possible then for the altitude reading to be unreliable when either there are not enough satellites in the sky or they are too close together. This then depends on the time of day, or date.
The signals from the satellites are very weak once they have reached the Earth's surface, and may not be received correctly inside buildings, or where there are other tall buildings nearby, such as a city centre like Manhattan.
Barometer readings will vary according to the weather and so an absolute reading can't be applied to a specific floor. However relative readings may be reliable enough for floor to floor changes, e.g. a lower value means going up.
Like any other device that uses GPS to calculate altitude, it's measuring the user's distance from the center of the satellites' orbits.
Your smartphone uses GPS technology to calculate your altitude depending on where you are. It measures how far away you are from the satilites which is calculating this information.
Note that newer IPhones (>= 6) have a barometer sensor which in my experience is significantly more accurate than GPS. With a barometers the accuracy appears to be within a foot whereas with GPS it would bounce around by 3-4 meters even when standing still.
http://www.iphonetricks.org/iphone-6-barometer-sensor-features/
I'm building an augmented reality game, and working with CLLocation is rather cumbersome.
Is there some way to locally approximate CLLocation as XYZ coordinate, expressed in meters with the origin starting at some arbitrary point (for example the initial position when the game was started)?
Lets say I'm working with a 1 mile radius and do not really care about the curvature of the earth. Is it possible to approximate or somehow simplify the location based calculations for local position tracking?
Alternatively, is there a coordinate system that can be used with CLLocation that also incorporates the roll, pitch, yaw of the CMAttitude as well as compass orientation?
Clarification: As far as I understand, the problem with latitude and longitude is that their units vary in size, depending on the position on the globe. I should've specified that X,Y,Z should be in standard units, like meters or feet.
Thank you!
The Haversine formula may be useful.
I found a good article on it at http://www.jaimerios.com/?p=39 with code examples.
You could get the initial point at the app's launch and calculate the relative points based on the user coordinates as he or she moves. Admittedly, this is not super elegant, but if you are just trying to do some simple comparisons based on the user's location relative to an arbitrary origin, this should work. For the Z, Alex Stone's suggestion of calculating it based on the altitude should be fine.
I have a xyz accelerometer and magnetometer. Now I want to determine the orientation of the device using both. The problem I see is that depending on the device orientation, I'd need to use the sensors in different order.
Let me give an example. If I have the device facing me then changes in both the roll and pitch can be determined with the accelerometer. For yaw I use the magnetometer.
But if I put the device horizontally (ie. turn it 90ยบ, facing the ceiling) then any change in the up vector (now horizontal) isn't notice, as the accelerometer doesn't detect any change. This can now be detected with the magnetometer.
So the question is, how to determine when to use one or the other. Is this enough with both sensors or do I need something else?
Thanks
The key is to use the cross product of the two vectors, gravity and magnetometer. The cross product gives a new vector perpendicular to them both. That means it is horizontal (perpendicular to down) and 90 degrees away from north. Now you have three orthogonal vectors which define orientation. It is a little ugly because they are not all perpendicular but that is easy to fix. If you then cross this new vector back with the gravity vector that gives a third vector perpendicular to the gravity vector and the magnet plane vector. Now you have three perpendicular vectors which defines your 3D orientation coordinate system. The original accelerometer (gravity) vector defines Z (up/down) and the two cross product vectors define the east/west and north/south components of the orientation.
Here is some documentation that walks through this project. As is clear from other answers, the math can be tricky.
http://www.freescale.com/files/sensors/doc/app_note/AN4248.pdf
I think the question "how to determine when to use one or the other" is misguided. You should always use both sensors for orientation. There are cases where one of them is useless. However, these are edge cases.
If I understand you correctly, you'll need something to detect pitch (tilting) and orientation according to the cardinal points (North, East, South and West).
The pitch can be read from the accelerometer.
The orientation according to the cardinal points can be read from a compass.
Combining the output from these two sensors correctly with the right math in your software will most likely give you the absolute orientation.
I think it's doable that way.
Good luck.
In the event you still need absolute orientation you can check this break out board from Adafruit: https://www.adafruit.com/products/2472. The nice thing about this is board is that it has an ARM Cortex-M0 processor to do all of the calculations for you.