My question is about the iPhone accelerometer. Does the accelerometer measure acceleration or movement of the iPhone? What I mean is if I hold the iPhone and go from 0mph to 60mph, I would expect the measure of acceleration to increase in value from 0 to 60, but once I reach 60, I expect the value to return to 0 since I am "no longer accelerating" but am moving at a constant speed. Now if the accelerometer measure motion, I would expect it to register 0 to 60 and continue to provide a change in value as I move forward at 60mph. Sorry, I looked at a few books, programmed some code (values seemed to small to give a recognizable result over short distances or speeds), and a lot of web searches, and I am trying to get an answer to this question.
Thanx!
A couple of points:
The accelerometer never reads zero because gravity is always with us and is an acceleration (and a good thing too). If it ever reads 0 you are in deep doo-doo - you have been cast adrift in space, or else you are in free-fall plunging towards the ground.
When you go from 0 to 60, acceleration does not "register 0 to 60". That isn't what acceleration is. It isn't speed; it's the rate of change in speed. Is this a Lamborghini or a VW Bug? They both go 0 to 60 but the acceleration might be very, very different.
You might need to read a little physics textbook here, but to make it simple, think of it as how hard you are being pressed back against the car seat! If you are not being pressed back, thrown from side to side, etc., then your horizontal acceleration is zero even you are going 100 miles per hour.
I think that the following links can clarify what the accelerometer of the iPhone does, and does not:
http://electronics.howstuffworks.com/iphone-accelerometer.htm
http://www.engadget.com/2012/05/22/the-engineer-guy-shows-how-a-smartphone-accelerometer-works/
Related
Seeing an odd issue surrounding changing a scroll view's content offset property.
I have a CADisplayLink that calls a method every frame. This method calculates how much to adjust the content offset by to produce an auto scroll type effect.
#objc private func tick() {
let fps = 1 / (displayLink.targetTimestamp - displayLink.timestamp)
let relativeAutoscrollAmount = autoscrollAmount / CGFloat(fps)
scrollView.contentOffset.x += relativeAutoscrollAmount
}
autoscrollAmount is a CGFloat property that represents how many pixels to move each second. On a 60Hz screen like an iPhone, this would mean a shift of 5/60 per invocation of that method, if this property is 5. However, the content offset never actually changes! Either visually or in memory, I can break and inspect it at any time and it's always 0!
Note that if I adjust it by 1 or greater each time, it works just fine. The animation is far to quick doing this, though.
Any thoughts?
EDIT: Obviously you can't actually adjust by less than a pixel at a time, but when I was doing this previously with a constraint constant, the system just calculated how to deal with this. (I assume by only moving every few ticks).
I believe I have the answer, or at the very least, an explanation based on a theory backed by some pretty good evidence. Here we go...
In the question, I provided an example of 5/60, where 5 is the amount of pixels to move per second, and 60 is the refresh rate of my screen. This comes out at approximately 0.083, which, as I said, caused no updates to contentOffset to take place.
At this point, I assumed that the minimum value was 1 (as you can't make changes to half a pixel) but this is in fact not the case. I began experimenting with different decimal values, in the hope of finding the threshold at which the updates to contentOffset stop taking place.
After a lot of trial and error, I found that value. It is 0.167. In my head, this had absolutely no significance whatsoever; but there obviously had to be something so I set about manipulating it in various ways to try to observe a pattern of some kind.
It soon became clear that 0.167 * 6 == 1, which although an interesting observation, again seemed to have little significance. That is until you note that the refresh rate of the display on my iPhone X that I was testing with is 60Hz, 10 times 6. At this point, I'm still stabbing blindly in the dark but this was at least a lead that I could explore a bit.
From this, I speculated that the system evaluates changes in layer's positions either every 6ms, or, perhaps more realistically, 10 times per display cycle. This supports the behaviour I am seeing in so far as if the movement value passes is too small (IE it cannot be represented in this 10 times per display cycle theorm), it is simply ignored.
This is quite a bold speculation so I decided to see if I could gather evidence to support the theory. I fired up my iPad pro which has a 120Hz display (as opposed to the 60Hz display on my iPhone X) to see if there was a trend. Sure enough, there was. The minimum value to see movement was now half what it was on the 60Hz screen. Given the greater refresh rate (double, in fact), and the original assumption of 10 updates per screen cycle, I am now seeing 20 updates per screen cycle, every 6ms, as before. There's definitely a relationship here.
Now I'd like to stress that this is all purely speculation, but at least I can sleep tonight having a good idea as to why this is happening! I'd love to hear other's thoughts, too.
I'm working on a leaderboard system for Garry's Mod and I have run into a slight problem to do with one of the statistics I'm tracking.
I am tracking a lot of statistics including the number of bullet's shot and the number of bullets that actually hit, and am using that information to work out the accuracy of the player like so:
(gunHits / gunShots) * 100
The problem with the way I'm doing it is that people can go to the top of the leaderboards by just logging on and shooting one bullet and hitting someone with it, therefore having an accuracy of 100%.
Is there any way I can get around this?
You could set a minimum amount of shots fired required to be ranked. I think 100 would be a good number.
On a side note you don't need to put any parenthesis on the operation since divide and multiply are operators with the same priority and they are already in the right order. It would've been necessary if you were doing it this way.
100 * (gunHits / gunShots)
Im programming an iOS game and I use the method update for a lot of things, which is called at the game speed refresh (for the moment 60 times per second) but the problem is if the frame rate drops down (for example a notification, or any behavior in the game that, when called, it makes drop down a little bit the fps...) then the bugs comes....
A fast example is if I have an animation of 80 pictures, 40 for jump up and 40 for fall, I would need 1,2 second to run the animation, so if the jump takes 1,2 second it would be ok, the animation would run. But if my fps drop down to 30 then the animation would cut because it would need 2,4 seconds to run the animation but the jump remains 1,2 second. This is only a fast example, there is a lot of unexpected behaviors in the game if the frame rate drops, so my question is, are games developers depending so much on frame rate or there is a way to avoid those fps-bugs? (another way to program or any trick?)
Base your timing on the time, rather than the frame count. So, save a time stamp on each frame, and on the next frame, calculate how much time has elapsed, and based on your ideal frame rate, figure out how many frames of animation to advance. At full speed, you shouldn’t notice a difference, and when the frame rate drops, your animations may get jerky but the motion will never get more than 1 frame behind where it should be.
Edit: as uliwitness points out, be careful what time function you use, so you don’t encounter issues when, for example, the computer goes to sleep or the game pauses.
Always use the delta value in your update method. This is platform and engine independent. Multiply any speed or change value by the delta value (the time interval between the current and the last frames).
In case of the animation, one way to fix the issue could be to multiply the animation counter by delta (and an inverse of the expected interval). Then round this value to get the correct image for the animation.
// currentFrame is a float ivar set to 0 at the beginning of the animation.
currentFrame = currentFrame + delta * 60.0;
int imageIndex = roundf(currentFrame);
However, with Sprite Kit there is a better way to do this kind of animation, as there is a premade SKAction dealing with sprite animation.
[SKAction animateWithTextures:theTextures timePerFrame:someInterval];
With this solution you don't have to deal with timing the images at all. The engine will do that for you.
There's a great discussion about FPS-based and Time-based techniques here:
Why You Should be Using Time-based Animation and How to Implement it
It's the best on my opinion, very complete, easy to follow and provides JsFiddle examples. I translated those examples to C++/Qt.
Click here to watch a video of my app running:
I am making an ios application in which it is to be determined that wether the person is sitting or standing.I wanted to know that if there is any method to find automatically that the person is sitting or standing like we can get the height from sea level with the help of CLLocation Manager.So like this can we get the height of iPhone from the ground level in any way?
This is not possible for the following reasons:
The phone can tell you its height above sea level, the accuracy of which has a larger margin of error than the difference between a sitting and a standing person
Even if 1. did not apply, and you knew the precise height of the ground at your current location and the additional height of the phone, this would still be meaningless, as it doesn't take into account buildings, the height of the person, their posture and so forth.
You may have more luck using the motion coprocessor on newer models, you could assume that a standing person moves about more than a sitting person, or something. Or accelerometer readings to detect changes of position. But altitude is definitely not the way to go.
You cannot find out by altitude if a person is standing or sitting.
Accuracy of GPS is much to low. Which is at best 6m for altitude.
But if you are really clever you could try other approaches:
-Use the acceleratoin sensor: A standing person might move a bit more than a sitting one, or moves different. [Sorry, I did not saw that user jrturton has written the same, bit this indicates that this might work]
Sitting persons often type on the keyboard. You can measure that with the accelerometer, by frequence analysis after doing a FFT.
Walking persons: A person that walks does not sit: Detect typical walking steps, with aclerometer or even with an ios API that is new in ios7. (I remeber there is a step counter)
These all are no accurate detections, but may raise the probability to detect a sitting person-.
If you get that to work, I will have major respect. Post an update if you succeed.
Expect 2,5 to 3,5 fulltime working month to get that to work (in some cases)
Can I detect the force or pressure exerted by a user (musician's) finger?
Not yet.
There's a technical demo showing how to do it. See http://tenonedesign.com/blog/pressure-sensitive-drawing-on-ipad/ . Hopefully something comes out of that. :)
Yes you can detect finger area, which is similar. Really! You just don't get point-pressure which requires a different sensor technology.
You can get a number that's the major radius of your finger in millimeters from every finger individually. It's essentially a processed number related to the number of pixels you are covering with the finger. Unfortunately, I haven't been able to get a straight answer on whether this is a problem to ship this way, so I have to ship with it disabled. But it works. It returns a value from 7.0 to about 11.0, it varies wildly, and you might want to low-pass filter changes to this value.
float vf = 10.0;
id valFloat = [thisTouch valueForKey:"pathMajorRadius"];
if(valFloat != nil)
{
vf = [valFloat floatValue];
}
As an iPad developer, it drives me COMPLETELY insane that this has worked since the iPad shipped, works now in iOS4.2, and still doesn't appear to be sanctioned. This feature is a basic requirement for many classes of application if you want something that's more than a $2 toy.
You cannot detect pressure but you can detect velocity of movement (distance/time) and you could establish a linear relationship between velocity and force -> volume. You could make a bell ring louder, for example, by swiping your finger vigorously, rapidly across the bell, and quietly by a gentle, short, slow stroke. Probably would work OK with harp strings.
Done. See my answer in Tap pressure strength detection using accelerometer