I am programming an iPhone app in ios 6 where I obtain the heading information and then using simple calculations, I convert that information to words, as "You are facing west". Now my problem is, when I rotate my phone from (say) north to east, phone will point out: 1. You are facing north-east (3-4 times) then at last when the phone settles, it says 2. You are facing east. The problem is I am converting all the commands to speech, and it turns out to be confusing and disturbing.
One way is to increase the value of heading filter, but I can't do that since I need precision of 20 degrees. I tried to use timestamps of headings, but no use. I tried usleep() but no use since the entire program stops. Is there any way I could tell phone to take information at 1.5 seconds interval from location manager, or can the location manager itself be programmed to check for heading after the phone's rotation has stabilized.
Update: How I failed in using timestamps ->
Suppose I move my phone fast my north to east. The difference in stamps look like this:
(all values in seconds, this value can be arbitrarily large or even undefined since I am moving the phone for the first time, in this case, it is 10 seconds which indicates I rotated the phone from west to north 10 seconds before)
10, 0.0012, 0.012, 0.005 (phone settles and the location manager is not called again). I do not know how to detect that I should take the value corresponding to 0.005.
Related
I'm using the CLLocationManager in Swift.
When I display location.coordinate, it provides me with the result:
37.787358900000001, longitude: -122.408227
However, if I display. location.coordinate.latitude, the result is
37.7873589
Do you know how I can get all the decimals?
Thanks,
Thomas
You are seeing 37.787358900000001 instead of 37.7873589 because of the nature of representing floating point numbers in a computer.
That said, it is pointless to worry about decimal places beyond the 6th position because even changing the 9 to an 8 would result in a change of about 1 centimeter. The GPS system is currently accurate to about +/- 5 meters, and with new chips being deployed by Broadcom that can be reduced to about +/- 30 centimeters in the near future.
By the way, do you know why the altitude keeps updating/changing, even
when the device is standing still on a table?
Altitude calculations are done by computing the distance to the visible GPS satellites which orbit the Earth every 12 hours. Since the satellites are constantly moving, and different satellites come into view, these calculations do tend to fluctuate. This article though a bit dated is enlightening.
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've been experimenting with the compass and gyroscope on iPhone 4 and would like some help with an issue I'm having. I want to compensate for the slowness of the compass by using data from the gyroscope.
Using CMMotionManager and its CMDeviceMotion object (motionManager.deviceMotion), I get the CMAttitude object. Correct me if I'm wrong (please), but here is what I've deduced from the CMAttitude object's yaw property (I don't need pitch nor roll for my purposes):
yaw ranges from 0 to PI when the phone is pointing downwards (as indicated by deviceMotion.gravity.z) and swinging counterclockwise and 0 to -PI when swung clockwise
when the device is pointing upwards, yaw ranges from -PI to 0 and PI to 0, respectively
and from the compass data (I'm using locationManager.heading.magneticHeading), I see that the compass gives values from 0 to 360, with the value increasing when swinging clockwise
All right, so using all of this information together, I'm able to get a value I call horizontal that, regardless of whether the device is pointing up or down, will give values from 0 to 360 and increase when the device is swung clockwise (though I am still having trouble when deviceManager.gravity.z is around 0 -- the yaw value freaks out at this gravity.z value).
It seems to me that I could "synchronize" the horizontal and magneticHeading values, using a calculated horizontal value that maps to magneticHeading, and "synchronize" the horizontal value to magneticHeading when I feel the compass has "caught up."
So my questions:
Am I on the right track with this?
Am I using the gyro data from CMDeviceMotion properly and the assumptions I listed above correct?
Why might yaw freak out when gravity.z is around 0?
Thank you very much. I look forward to hearing your answers!
Just trying to answer... correct me if i'm wrong..
1.Yes you are on the right track
2.gravity in CM is already "isolated" from user gravity (gravity value caused by user acceleration) thats why there is two gravity, the "gravity" and "userAcceleration" its on apple CM documentation
// Note : not entirely isolated //
3.
if you have a gravity 0 it mean that the coresponding axis is perpendicular with gravity.
gravity.z is the iPhone screen thats why it -9.82m/s2 if you put on the desk with screen upright, actualy it hard to get 0 or maximum value of the gravity due to the sensor noise (it's normal, all sensor has a noise expecially cheap sensor).
what i do on my apps is I will switch my reference axis to other axis (in your case may be x or y) for certain limits, how the strategy is depend on the purpose or which side is your reference.
the other thing is, gyro is fast but its not stable, you need to re-calibrate the value for several interval. In my case every 5 second. I've experiment with gyro for calculating angle between two plane, i try with exacly 90 degree ruler and it will give an error about 0.5 degree every second try and keep increasing, but thats is mine, maybe others have a better method for avoid the error.
below is my steps "
Init
Read gravity XYZ -> Xg Yg Zg
Check if Xg < 0.25 If TRUE try Yg then Zg // Note 1 = 1g = 9.82 m/s^2
Read the compass and gyro
Configure and calibrate the gyro using the compass and calulate based on which axis i use in point 3.
If 5 second is pass then recalibrate, read the compass
If the the difference with gyro reading is > 5 degree skip recalibartion the gyro.
If the the difference with gyro reading is < 5 degree calibrate the gyro using compass value
Note: for number 7 : is to check if the phone affected with magnetic field or near huge steel such or high voltage electrical line or in noisy and heavy equipment in factory plant.
Thats all... Hope this could help you...
And sorry for my english..
Here is an example of an iPhone app where the compass get compensated with the gyroscope. Code and project can be seen here:
http://www.sundh.com/blog/2011/09/stabalize-compass-of-iphone-with-gyroscope/
The direction of the yaw axis vector is undefined when in zero gravity (or free fall, or close enough).
In order to do synchronization while in motion, you need to create a filter for your "horizontal" value that has the same lag/delay response characteristics as the magnetic compass. Either that, or wait until motion stops long enough for both values to settle before recalculating the offset.
Answer to question 1 is Yes, question 2 you are on the right track but you could use a variable name that is not 'horizontal', question 3 is answered by hotpaw2 and also a yaw in a chopper or helicopter at near zero altitude would alert the pilot with an alarm. There is a time lag because part of the software is local while there are other factors which can slow it down including access to a sensor for detecting magnetic waves, the device position and direction, preparing the graphic output for the compass display, computing and outputting data from the gyro and sensors through a relatively slow interface, using a general purpose handheld device not custom designed for the type of task being asked of it.
Using iPhone's SDK GPS API, how accurate can I get? Is it within a few meters or kilometers? I'm interested in the accuracy when it is indoor. My software will only be used in door.
The best possible accuracy seems to be 9 meters. Common values (outdoor, good coverage) is 17 m, 23 m and 49 meters. With trees covering the sky you'll probably stay under a hundred meters, but hardly accurate enough for GIS or anything like that.
The API has a property or method that returns the current accuracy of the location measurement. If your goal is only to use the location if accuracy is within some limit then you should make sure that you check the returned accuracy, since the location may be only accurate to within a few thousand meters initially as its just using your location from the cell towers, and it will typically get better and better accuracy as the GPS powers up and starts getting a fix.
Most standard GPS chips (and the iphone is that) can get around 10 meters accuracy.
Best results are outside on a clear sky obviously.
The difference between GPS chips is usually how quickly they can reception and how well they can hold it. Accuracy is pretty constant except for those using WAAS sattelite (which the iphone GPS doesn't do)
Based on my own experience it's within meters.
I want to create an application could detect the number of spin when user rotates the iPhone device. Currently, I am using the Compass API to get the angle and try many ways to detect spin. Below is the list of solutions that I've tried:
1/ Create 2 angle traps (piece on the full round) on the full round to detect whether the angle we get from compass passed them or not.
2/ Sum all angle distance between times that the compass is updated (in updateHeading function). Let try to divide the sum angle to 360 => we could get the spin number
The problem is: when the phone is rotated too fast, the compass cannot catch up with the speed of the phone, and it returns to us the angle with latest time (not continuously as in the real rotation).
We also try to use accelerometer to detect spin. However, this way cannot work when you rotate the phone on a flat plane.
If you have any solution or experience on this issue, please help me.
Thanks so much.
The iPhone4 contains a MEMS gyrocompass, so that's the most direct route.
As you've noticed, the magnetometer has sluggish response. This can be reduced by using an anticipatory algorithm that uses the sluggishness to make an educated guess about what the current direction really is.
First, you need to determine the actual performance of the sensor. To do this, you need to rotate it at a precise rate at each of several rotational speeds, and record the compass behavior. The rotational platform should have a way to read the instantaneous position.
At slower speeds, you will see a varying degree of fixed lag. As the speed increases, the lag will grow until it approaches 180 degrees, at which point the compass will suddenly flip. At higher speeds, all you will see is flipping, though it may appear to not flip when the flips repeat at the same value. At some of these higher speeds, the compass may appear to rotate backwards, opposite to the direction of rotation.
Getting a rotational table can be a hassle, and ensuring it doesn't affect the local magnetic field (making the compass useless) is a challenge. The ideal table will be made of aluminum, and if you need to use a steel table (most common), you will need to mount the phone on a non-magnetic platform to get it as far away from the steel as possible.
A local machine shop will be a good place to start: CNC machines are easily capable of doing what is needed.
Once you get the compass performance data, you will need to build a model of the observed readings vs. the actual orientation and rotational rate. Invert the model and apply it to the readings to obtain a guess of the actual readings.
A simple algorithm implementation will be to keep a history of the readings, and keep a list of the difference between sequential readings. Since we know there is compass lag, when a difference value is non-zero, we will know the current value has some degree of inaccuracy due to lag.
The next step is to create a list of 'corrected' readings, where the know lag of the prior actual values is used to generate an updated value that is used to create an updated value that is added to the last value in the 'corrected' list, and is stored as the newest value.
When the cumulative correction (the difference between the latest values in the actual and corrected list exceed 360 degrees, that means we basically don't know where the compass is pointing. Hopefully, that point won't be reached, since most rotational motion should generally be for a fairly short duration.
However, since your goal is only to count rotations, you will be off by less than a full rotation until the accumulated error reaches a substantially higher value. I'm not sure what this value will be, since it depends on both the actual compass lag and the actual rate of rotation. But if you care only about a small number of rotations (5 or so), you should be able to obtain usable results.
You could use the velocity of the acceleration to determine how fast the phone is spinning and use that to fill in the blanks until the phone has stopped, at which point you could query the compass again.
If you're using an iPhone 4, the problem has been solved and you can use Core Motion to get rotational data.
For earlier devices, I think an interesting approach would be to try to detect wobbling as the device rotates, using UIAccelerometer on a very fine reporting interval. You might be able to get some reasonable patterns detected from the motion at right angles to the plane of rotation.