10
votes

I'm implementing the scrolling behaviour of a touch screen UI but I'm too tired in the moment to wrap my mind around some supposedly trivial piece of math:

y (distance/velocity)
|********
|        ******
|              ****
|                  ***
|                     ***
|                        **
|                          **
|                            *
|                             *
-------------------------------- x (time)

f(x)->?

The UI is supposed to allow the user to drag and "throw" a view in any direction and to keep it scrolling for a while even after he releases the finger from the screen. It's sort of having a momentum that depends on how fast the user was dragging before he took off the finger.

So I have a starting velocity (v0) and every 20ms I scroll by a amount relative to the current velocity. With every scrolling iteration I lower the velocity a bit until it falls below a threshold when I stop it. It just doesn't look right when I decrement it by a fixed amount (linear), so I need to model a negative acceleration but fail to come up with a decent simple formula how to calculate the amount by which I have to lower the velocity in every iteration.

Update:

Thank you for your responses so far but I still didn't manage to derive a satisfying function from the feedback yet. I probably didn't describe the desired solution good enough, so I'll try to give a real world example that should illustrate what kind of calculation I would like to do:

Assume there is a certain car driving on a certain street and the driver hits the brakes to a max until the car comes to a halt. The driver does this with the same car on the same street multiple times but begins to brake at varying velocities. While the car is slowing down I want to be able to calculate the velocity it will have exactly one second later solely based on it's current velocity. For this calculation it should not matter at which speed the car was driving when the driver began to break since all environmential factors remain the same. Of course there will be some constants in the formula but when the car is down to i.e. 30 m/s it will go the same distance in the next second, regardless whether it was driving 100 or 50 m/s when the driver began to break. So the time since hitting the breaks would also not be a parameter of the function. The deceleration at a certain velocity would always be the same.

How do you calculate the velocity one second later in such a situation assuming some arbitrary constants for deceleration, mass, friction or whatever and ignoring complicating influences like air resistance? I'm only after the kinetic energy and the it's dissipation due to the friction from breaking the car.

Update 2 I see now that the acceleration of the car would be liniear and this is actually not what I was looking for. I'll clean this up and try out the new suggestions tomorrow. Thank you for your input so far.

15
I think the wikipedia article on drag might be a good resource: en.wikipedia.org/wiki/Drag_(physics). The "low Reynolds number" section seems appropriate, and relatively simple.Chris Farmer
"With every scrolling iteration I lower the velocity a bit until it falls below a threshold when I stop it. It just doesn't look right when I decrement it by a fixed amount (linear), so I need to model a negative acceleration" -- it IS a negative acceleration, just a constant one.mlvljr
Yes, you are right mlvljr. I noticed that in the meantime already. So it's obviously not really the model I was looking for, but I played a bit more with my implementation and it seems I found something that looks pretty neat and has the characteristics I was looking for (i.e. not depending on time).x4u
Just a suggestion: you may want to try constant time solutions, which are better from a UI point of view. E.g. you may want the scrolling to always stop after one and a half seconds, one second of which is linear slowdown (to lets say 90% of initial velocity) and only the last half second is exponential. This gives a nice "gliding" feel.Timo

15 Answers

8
votes

[Short answer (assuming C syntax)]

double v(double old_v, double dt) {
    t = t_for(old_v); 
    new_t = t - dt; 
    return (new_t <= 0)?0:v_for(t);
} 

double t_for(double v) and double v_for(double t) are return values from a v-to-t bidirectional mapping (function in mathematical sence), which is arbitrary with the constraint that it is monothonic and defined for v >=0 (and hence has a point where v=0). An example is:

double v_for(double t) { return pow(t, k); }
double t_for(double v) { return pow(v, 1.0/k); }

where having:

  1. k>1 gives deceleration decreasing by modulo as time passes.
  2. k<1 gives deceleration increasing by modulo as time passes.
  3. k=1 gives constant deceleration.

[A longer one (with rationale and plots)]

So the goal essentialy is:

  1. To find a function v(t+dt)=f(v(t),dt) which takes current velocity value v and time delta dt and returns the velocity at the moment t+dt (it does not require actually specifying t since v(t) is already known and supplied as a parameter and dt is just time delta). In other words, the task is to implement a routine double next_v(curr_v, dt); with specific properties (see below).

  2. [Please Note] The function in question has a useful (and desired) property of returning the same result regardless of the "history" of previous velocity changes. That means, that, for example, if the series of consecutive velocities is [100, 50, 10, 0] (for the starting velocity v0=100), any other sequence larger than this will have the same "tail": [150, 100, 50, 10, 0] (for the starting velocity v0=150), etc. In other words, regardless of the starting velocity, all velocity-to-time plots will effectively be copies of each other just offset along the time axis each by its own value (see the graph below, note the plots' parts between the lines t=0.0 and t=2.0 are identical) .

  3. Besides, acceleration w(t)=dv(t)/dt must be a descending function of time t (for the purpose of visually pleasing and "intuitive" behaviour of the moving GUI object which we model here).

The proposed idea is:

  1. First you choose a monothonic velocity function with desired properties (in your case it is gradually decreasing acceleration, though, as the example below shows, it is easier to use "accelerated" ones). This function must not also have an upper boundary, so that you could use it for whatever large velocity values. Also, it must have a point where velocity is zero. Some examples are: v(t) = k*t (not exactly your case, since deceleration k is constant here), v=sqrt(-t) (this one is ok, being defined on the interval t <= 0).

  2. Then, for any given velocity, you find the point with this velocity value on the above function's plot (there will be a point, since the function is not bound, and only one since it is monothonic), advance by time delta towards smaller velocity values, thus acquiring the next one. Iteration will gradually (and inevitably) bring you to the point where velocity is zero.

  3. That's basically all, there is even no need to produce some "final" formula, dependencies on time value or initial (not current) velocities go away, and the programming becomes really simple.

For two simple cases this small python script produces the plots below (initial velocities given were 1.0 to 10.0), and, as you can see, from any given velocity "level" and "downwards" the plots "behave" the same which is of couse because no matter at what velocity you start to slow down (decelerate), you are "moving" along the same curve RELATIVE to the point where velocity is (becomes) zero:

import numpy
import pylab

import math


class VelocityCurve(object):
    """
    An interface for the velocity 'curve'.
    Must represent a _monotonically_ _growing_
        (i.e. with one-to-one correspondence
        between argument and value) function
        (think of a deceleration reverse-played)
    Must be defined for all larger-than-zero 'v' and 't'
    """
    def v(self, t):
        raise NotImplementedError

    def t(self, v):
        raise NotImplementedError



class VelocityValues(object):

    def __init__(self, v0, velocity_curve):
        assert v0 >= 0
        assert velocity_curve

        self._v = v0
        self._vc = velocity_curve

    def next_v(self, dt):
        t = self._vc.t(self._v)
        new_t = t - dt

        if new_t <= 0:
            self._v = 0
        else:
            self._v = self._vc.v(new_t)

        return self._v


class LinearVelocityCurve(VelocityCurve):

    def __init__(self, k):
        """k is for 'v(t)=k*t'"""
        super(LinearVelocityCurve, self).__init__()

        self._k = k

    def v(self, t):
        assert t >= 0
        return self._k*t

    def t(self, v):
        assert v >= 0
        return v/self._k


class RootVelocityCurve(VelocityCurve):

    def __init__(self, k):
        """k is for 'v(t)=t^(1/k)'"""
        super(RootVelocityCurve, self).__init__()

        self._k = k

    def v(self, t):
        assert t >= 0
        return math.pow(t, 1.0/self._k)

    def t(self, v):
        assert v >= 0
        return math.pow(v, self._k)


def plot_v_arr(v0, velocity_curve, dt):
    vel = VelocityValues(v0, velocity_curve)
    v_list = [v0]

    while True:
        v = vel.next_v(dt)
        v_list.append(v)

        if v <= 0:
            break

    v_arr = numpy.array(list(v_list))
    t_arr = numpy.array(xrange(len(v_list)))*dt

    pylab.plot(t_arr, v_arr)


dt = 0.1

for v0 in range(1, 11):
    plot_v_arr(v0, LinearVelocityCurve(1), dt)

for v0 in range(1, 11):
    plot_v_arr(v0, RootVelocityCurve(2), dt)


pylab.xlabel('Time ')
pylab.ylabel('Velocity')

pylab.grid(True)

pylab.show()

This gives the following plots (linear ones for the linear decelerating (i.e. constant deceleration), "curvy" -- for the case of the "square root" one (see the code above)):

Also please beware that to run the above script one needs pylab, numpy and friends installed (but only for the plotting part, the "core" classes depend on nothing and can be of course used on their own).

P.S. With this approach, one can really "construct" (for example, augmenting different functions for different t intervals or even smoothing a hand-drawn (recorded) "ergonomic" curve) a "drag" he likes:)

5
votes

After reading the comments, I'd like to change my answer: Multiply the velocity by k < 1, like k = 0.955, to make it decay exponentially.

Explanation (with graphs, and a tuneable equation!) follows...

I interpret the graph in your original question as showing velocity staying near the starting value, then decreasing increasingly rapidly. But if you imagine sliding a book across a table, it moves away from you quickly, then slows down, then coasts to a stop. I agree with @Chris Farmer that the right model to use is a drag force that is proportional to speed. I'm going to take this model and derive the answer I suggested above. I apologize in advance for the length of this. I'm sure someone better at math could simplify this considerably. Also, I put links to the graphs in directly, there are some characters in the links that the SO parser doesn't like. URLs fixed now.

I'm going to use the following definitions:

x -> time
a(x) -> acceleration as a function of time
v(x) -> velocity as a function of time
y(x) -> position as a function of time
u -> constant coefficient of drag
colon : denotes proportionality

We know that the force due to drag is proportional to speed. We also know that force is proportional to acceleration.

a(x) : -u v(x)        (Eqn. 1)

The minus sign ensures that the acceleration is opposite the current direction of travel.

We know that velocity is the integrated acceleration.

v(x) : integral( -u v(x) dx )        (Eqn. 2)

This means the velocity is proportional to its own integral. We know that e^x satisfies this condition. So we suppose that

v(x) : e^(-u x)        (Eqn. 3)

The drag coefficient in the exponent is so that when we solve the integral in Eqn. 2 the u cancels to get back to Eqn. 3.

Now we need to figure out the value of u. As @BlueRaja pointed out, e^x never equals zero, regardless of x. But it approaches zero for sufficiently negative x. Let's consider 1% of our original speed to be 'stopped' (your idea of a threshold), and let's say we want to stop within x = 2 seconds (you can tune this later). Then we need to solve

e^(-2u) = 0.01        (Eqn. 4)

which leads us to calculate

u = -ln(0.01)/2 ~= 2.3        (Eqn. 5)

Let's graph v(x).

Looks like it exponentially decays to a small value in 2 seconds. So far, so good.

We don't necessarily want to calculate exponentials in our GUI. We know that we can convert exponential bases easily,

e^(-u x) = (e^-u)^x        (Eqn. 6)

We also don't want to keep track of time in seconds. We know we have an update rate of 20 ms, so let's define a timetick n with a tick rate of 50 ticks/sec.

n = 50 x        (Eqn. 7)

Substituting the value of u from Eqn. 5 into Eqn. 6, combining with Eqn. 7, and substituting into Eqn. 3, we get

v(n) : k^n, k = e^(ln(0.01)/2/50) ~= 0.955        (Eqn. 8)

Let's plot this with our new x-axis in timeticks.

Again, our velocity function is proportional to something that decays to 1% in the desired number of iterations, and follows a 'coasting under the influence of friction' model. We can now multiply our initial velocity v0 by Eqn. 8 to get the actual velocity at any timestep n:

v(n) = v0 k^n        (Eqn. 9)

Note that in implementation, it is not necessary to keep track of v0! We can convert the closed form v0 * k^n to a recursion to get the final answer

v(n+1) = v(n)*k        (Eqn. 10)

This answer satisfies your constraint of not caring what the initial velocity is - the next velocity can always be calculated using just the current velocity.

It's worth checking to make sure the position behavior makes sense. The position following such a velocity model is

y(n) = y0 + sum(0..n)(v(n))        (Eqn. 11)

The sum in Eqn. 11 is easily solved using the form of Eqn 9. Using an index variable p:

sum(p = 0..n-1)(v0 k^p) = v0 (1-k^n)/(1-k)        (Eqn. 12)

So we have

y(n) = y0 + v0 (1-k^n)/(1-k)        (Eqn. 13)

Let's plot this with y0 = 0 and v0 = 1.

So we see a rapid move away from the origin, followed a graceful coast to a stop. I believe this graph is a more faithful depiction of sliding than your original graph.

In general, you can tune k by using the equation

k = e^(ln(Threshold)/Time/Tickrate)        (Eqn. 14)
where:
Threshold is the fraction of starting velocity at which static friction kicks in
Time is the time in seconds at which the speed should drop to Threshold
Tickrate is your discrete sampling interval

(THANKS to @poke for demonstrating the use of Wolfram Alpha for plots - that's pretty sweet.)

OLD ANSWER

Multiply the velocity by k < 1, like k = 0.98, to make it decay exponentially.

4
votes

While the car is slowing down I want to be able to calculate the velocity it will have exactly one second later solely based on it's current velocity.

That would be the definition of acceleration. For instance, if the acceleration was a = -9 meters/sec/sec, and the velocity right now is 20 meters/sec, then 1 second from now the velocity will be 11 meters/sec.

In otherwords, the change in velocity Δv between now and t seconds from now (assuming constant acceleration) would be

Δv = a*t

meaning that the (classic physics) equation for the velocity at any time t, given the initial velocity at t=0 (this velocity is called v0) is

v(t) = v0+ a*t


Using what you'll learn in the first two weeks of calculus class, you can also get the equation for x(t) (the distance of the car at time t) from the above equation; this would give you

x(t) = x0+ v0*t + 0.5*a*t2

(it is also possible to derive this without calculus, see here)


Finally, if you are doing this for a game, and not a physics simulation (meaning you don't need exactly precise results), you will want to simply change the position and velocity every frame, rather than recalculate the position every frame. To do this, you will want to do the following every frame, assuming velocity (and acceleration) is measured in pixels-per-second(-per-second):

velocity_new = velocity_old + acceleration/frames_per_second
position_new = position_old + velocity_old/frames_per_second
2
votes

Seems like you are looking for deceleration which increases over time.

Try computing

Delta_v = -(A*t + B) , selecting reasonable constants A and B, which suit you.

t is the total time till that point.

Change your velocity by adding Delta_v.

This basically corresponds to linear negative acceleration.

You can basically select any function which increases over time (say f(t))

and compute

Delta_v = -f(t)

An appropriate choice for f(t) would give you the effect you desire.

Some examples you could use:

f(t) = At + B.
f(t) = A*exp(Bt)

Of course, you will have to play around a bit and try to figure out the right constants.

2
votes

You can just reduce velocity by a constant amount each iteration. Example: you start with a velocity of 50, next iteration it is 40, then 30, 20, 10, stop. This would represent a constant "friction", independent of velocity, and this is actually quite close to reality (see friction on Wikipedia).

If you do not like the appearance of this, you need to make friction dependent on velocity. I would assume that a linear relationship friction = base-friction + (coefficient * velocity), with a rather small coefficient, would be enough.

2
votes

If you want increasing deceleration as you say in your comment at mtrw's answer, and you are NOT very picky about physical realism, the equation below may be what you're looking for:

V(t+dt) = V(t) - K1 + K2 x V(t)

V(t)= current speed V(t+dt)= speed at next time increment K1 and K2 are constants you calibrate. Just make sure (K2 x Vmax) < K1, or you'll accelerate at high speeds.

If it still doesn't feel right, try V(t+dt) = V(t) - K1 + K2 x f(V(t))

where f(x) is a monotonically increasing function you pick, maybe square or square root depending of where you want to take the feeling. Just make sure (K2 x f(V(t))) < K1 for every possible V(t).

(monotonically increasing function means f(x) always increases when x increases)

2
votes

I will add a thought as well. Looks like you don't want a constant (negative) acceleration. That would result in an equation like:

v(t) = v(0) + a*t,

where a is the negative acceleration, t is the time, and v(t) is velocity at time t. This gives you:

v(t2) - v(t1) = a(t2-t1),

and that means that for a given Δt the velocity difference is equal to aΔt, a constant.

What you may be looking for is for a "friction" term, that depends upon the current velocity. Under that assumption, the rate of change of velocity is proportional to the current velocity:

d v(t) / d t = -b*v(t).

Solving the above is easy, and you get: v(t) = v(0) e−b t.

Integrating this equation, we get x(t) = v(0)(1−e−b t) / b, where x is the position. The position plot1 for v(0) = 1, b = 0.1 looks like something you could use. Playing with the values of b, and adding a scale factor to the equation might be what you want to do.


1http://www.wolframalpha.com/input/?i=plot+%281+-+1+e^%28-0.1+x%29+%29+%2F+0.1+for+x+%3D+0+to+100

1
votes

A non-linear change in velocity means that acceleration is not constant. A non-constant acceleration means that the system is under the influence of jerk. Take all your acceleration equations and add "(1/6)jt3". Fix a, and give j a small negative value until v hits 0.

0
votes

You could keep track of the velocity and cut that down by a fraction of the velocity each time. That would simulate friction quite well I believe.

0
votes

I would cut down velocity as something like v=v*0.9 Then i would have a velocity which is considered the stopped velocity. This way the object would come to rest eventually and not continue consuming resources as moving. so something like for(v=startingVelocity;v<1.0;v*=0.9) { x+=v; }

0
votes

Acceleration is the first order derivative of velocity and second order derivative of distance. Your graph looks like a second order parabola something like C-k*x^2 for some constants C and k. If y is really distance you need a=-2k, if y is velocity you need a=-2kx. In either case velocity v(x) = V0 + a(x)*x. (Where x is actually time. I am following your convention and not using t.)

0
votes

I have tried this, which works (in Ruby). Not sure if the math is sound but the output looks right, meaning that you get faster as you get towards the center:

velocity=100;
(100.downto(0)).each { |distance_from_black_hole |  velocity=velocity+9.8/distance_from_black_hole; puts velocity; }
0
votes

A bit of non programming discussion about the car example.

First, I'll assume that the driver cannot cause the brakes to lock at speed.

The first thing (or maybe the second or third thing) most new drivers learn is that the natural tendency when braking is to hold the brake pedal at a fixed position. The result is a sudden lurch forward as the car goes from moving slowly to stopping. This happens because the brakes are transitioning from dynamic friction, where braking force is proportional to brake pressure, to static friction, where braking force is restoring the forward momentum of the car. this sudden jump in acceleration is unpleasant, and the new driver learns to feather the pedal at the very end of deceleration to stop.

This behavior masks another pecularity, but this can be noticed during normal acceleration in a manual transmission car. when accelerating (or decelerating), if the driver suddenly pops the transmission out of gear, all of the passengers will suddenly lurch forward. What is actually happening, is the accelerating force that was pressing them into the backs of their seats is suddenly removed, and they spring back to a neutral sitting position. A more comfortable way to drive is to gradually feather the clutch so the motive force of the engine is removed gradually.

In both cases, the more aesthetic driving style involves smoothing the acceleration, removing sudden jumps. This is basically another way of talking about continious second derivative. Almost any motion with this property will seem natural.

0
votes
y(x) = y0 - a * e ^ ( k * x )

where y0 is the start constant, and a and k are factors.

Example plot.

0
votes
acceleration = (force / mass) 
velocity = (acceleration * time)
(force from user's finger) = acceleration / mass = velocity / time
  1. give the view a mass (tweak it until things seem reasonable, and let the user tweak it)
  2. identify some new force (drag)
  3. give the new force (drag) a magnitude (tweak until reasonable, let the user tweak it)
  4. apply the new force to the object and watch it slow down