End position of movement factoring in deceleration

Question

Ok I am hoping to apply this answer to a piece of software, but it uses physics to work out the result so I require some help in that department.

I will attempt to explain this the best I can.

I need to work out the continual position of a scrolling list. If you were to flick the list it would continue to scroll (without the user touching it) for set amount of time decelerating as it does this.

The information I can gather.

1. The start position of the users touch
2. The end position of the users touch
3. The distance between the touches
4. Believe I can then get the speed of this (speed = distance/time)
5. The continual time the scroll will last after the touch is 2400ms

I have read that the deceleration of the scroller happens every 325ms at a factor of 0.95 targeting a fps of 60. Giving this 325 is -16.7 / ln(0.95). Though I do not know is this is correct.

I really need to know, the point that the scroller will stop after the 2400ms and ideally an update of the current position every 100ms. I just need to know the physics behind this as the programming will be simple from there.

---

Edit

I think that the scroller velocity does reduce at a factor of 0.95 every 325ms. I have found this information from this useful article.

This observation led me to believe that the momentum scrolling is a sort of exponential decay. It is characterized by the speed of the decay. There are two different ways to express it: half-life (remember radioactive decay?) or time constant. For the latter, it is very much related to the step response of a first order system. In other words, the deceleration system is just an overdamped spring-mass system. Turns out, everything is still based on physics.

amplitude = initialVelocity * scaleFactor;
step = 0;

ticker = setInterval(function() {
    var delta = amplitude / timeConstant;
    position += delta;
    amplitude -= delta;
    step += 1;
    if (step > 6 * timeConstant) {
        clearInterval(ticker);
    }
}, updateInterval);

In fact, this is how the deceleration is implemented in Apple’s own PastryKit library (and now part of iAd). It reduces the scrolling speed by a factor of 0.95 for each animation tick (16.7 msec, targeting 60 fps). This corresponds to a time constant of 325 msec. If you are a math geek, then obviously you realize that the exponential nature of the scroll velocity will yield the exponential decay in the position. With a little bit of scriblling, eventually you find out that 325 is -16.7 / ln(0.95).

This Google Doc should show the formulas and hopefully I am doing it correctly. On the left is the standard formula. On the right I have attempted to reduce the velocity by 0.95 (velocity*0.95). I have added real information from my testing to show the problem I am having. If all the equations are correct and it being done the correctly logically way, I must be the data going in.

Answer 1

The distance moved by the list is given by:

$$s = ut - \frac{1}{2}at^2$$

where $u$ is the initial velocity of the list, $a$ is the deceleration and $t$ is the time the list has been moving. You can calculate the speed $u$ as you describe.

The acceleration has to be able to bring the list to a stop in 2.4 seconds. Velocity is equal to acceleration times time, so to change the velocity from $u$ to zero in 2.4 seconds the acceleration is:

$$ a = \frac{u}{2.4}$$

You can combine the two equations to give:

$$s = u\left( t - \frac{1}{4.8}t^2 \right) $$

You can use whatvere units you want for distance and speed as long as they're consistent. We physicists tend to use metres and meters per second, but for a smartphone or computer you could use a physical distance or a virtual distance like number of list elements and number of list elements moved per second.

Response to comment: I've created a Google docs spreadsheet showing the calculation. I only realised after I had posted that the figure of 4.8 in my equation has dimensions of time so for the equation to work you need to give the time in seconds and the velocity in distance/second. I realised this because I initially used milliseconds in my spreadsheet and calculated the scroll distance was several miles!