1

I am trying to predict the projectile motion of a basketball. Please not that I am not considering any effect of air drag, just the effect of g.I am using euler's method for this purpose.

I am able to track the ball quite accurately. However the issue is with the prediction part. Here is the code of euler's method which I am using:

def euler(euler_center, euler_velocity):
euler_center[0] = euler_center[0] + euler_velocity[0] * timeStepSize *gTimesteps *0.707
euler_center[1] = euler_center[1]  + euler_velocity[1] * timeStepSize

euler_velocity[0] = euler_velocity[0]  * timeStepSize
euler_velocity[1] = euler_velocity[1] + gTimesteps * timeStepSize

return (euler_center, euler_velocity)

The euler_center calculated by it after 20 iterations is:

[[331.3899068333333, 162.3366666666667]
[331.39290372777776, 167.5727277777778]
[331.3930036242592, 172.80818333333335]
[331.3930069541419, 178.04303333333334]
[331.393007065138, 183.27727777777778]
[331.3930070688379, 188.51091666666667]
[331.39300706896125, 193.74395]
[331.39300706896535, 198.9763777777778]
[331.39300706896546, 204.20820000000003]
[331.39300706896546, 209.4394166666667]
[331.39300706896546, 214.6700277777778]
[331.39300706896546, 219.90003333333334]

And something like that.

However, the centers tracked by my tracking algorithms are:

(339, 167)
(332, 158)
(325, 151)
(319, 146)
(312, 140)
(306, 135)
(299, 130)
(293, 126)
(286, 122)
(280, 118)
(277, 117)
(269, 112)
(254, 111)
(248, 112)

Needless to say, thats pretty bad prediction. It seems that the first prediction is bit accurate.

By the way, this function is in a loop of 20 steps so the predicted value is again used to predict the next value. When the function is first called, [331.3, 157.10000000000002] is passed to it.

timeStepSize is inverse of video FPS and $$gTimesteps=−9.81∗500(pixelsPerMeter)$$

pixels per meter are just guessed.

So what is the issue here? Is this the wrong way to do prediction by euler's method? Or do I need to use some different method altogether? Please help.

Thanks.

Parth
  • 39
  • 10

2 Answers2

1

First of all every single book on numerical methods will tell you NEVER EVER use the Euler method. This is a nice easy to follow into into the concept of numerical integration of an ODE but is doomed to drift off course given enough steps.

Since you didn't cite how you derived the equations I can't really critique them but even if they are correct Euler will eventually fail. For example, what is the equation for center? Is this a discrete version of dx/dt = v, and is the equation for v dv/dt = -g? What are the gTimeSteps and why the 0.707?

I would guess that you are testing an ODE solver rather than just modeling data. If all you want to do is predict where the ball in the video will be and don't care about air resistance you could use the exact solution, y = y0 + vy0*t - 0.5*|g|*t^2, etc. Then get initial conditions from two points in the video. However if you are trying to do an ODE look at Numerical Recipes in C/C++/FORTRAN/ or any other language it is published in and learn the ODE integration method. A second or fourth order Runge Kutta would do better.

Once you have the equations correct the severity of drift will depend on the step size. If the step size is too big that could send the estimates way off in left field (or somewhere). The error needs to be estimated and step size corrected. If you are picking points off a video or pic, and you know for sure that the equations are correct, try a finer sampling. Smaller steps usually lead to better accuracy but this is not guaranteed.

1

This looks like a programming error, not an error with the Euler method per se.
Notice that your x-coordinate is not changing. Check to make sure "gTimesteps" is not zero.

NuclearFission
  • 251
  • 2
  • 5