# Movement & arriving using forces

3D. Given a point mass m, inital position p0 initial velocity v0, and a desired location d, how do I apply forces (with magnitude no greater then fMax) to move m to d and stop. I know how to apply forces, it's the strategy for determining what force to apply each frame.

You would think this would be easy - but it's turned out to be difficult.

A solution that only converges at the limit is not acceptable (i.e. having the mass oscillate back/forth over the destination by smaller and smaller distance)

Edit: This is not the same as this question. Finding the stopping distance is trivial, but is (maybe) only part of the solution.

Edit: Also not the same as this question, because the highest answer is incorrect (as stated by my constraints)

• Does m move in frictionless and gravityless space? Should m reach max speed in between, ie. travel in shortest time, or should m maintain v0 until it's time to start slowing down? If you use a physics engine to handle the mass calculation (do you?), it is unlike that you hit d at nth decimal, since physics engines have internal behaviour that affect (cease) the most tiny movements. This probably doesn't matter? Also the physics solver may have an internal damping that consumes energy and scrambles the calculation a bit. Is this a simulation of real-world objects and movement? – Stormwind Jun 3 '16 at 0:19
• Are you familiar with the kinematics equations (for movement under constant acceleration) as outlined in my answer here: gamedev.stackexchange.com/questions/54732/… – Pieter Geerkens Jun 3 '16 at 2:23
• @PieterGeerkens yes, I'm fine with the physics. Finding the braking distance is easy - but is only part of an overall strategy. – user78331 Jun 3 '16 at 14:02
• @Stormwind Doing the physics simulation myself. For now, can assume frictionless and gravityless. Yes, real-world objects and movement - but for now, assuming idealized. Will iterate after. – user78331 Jun 3 '16 at 14:06
• I assume you also want to minimize the time to reach the target (and/or the total force over time applied)? Otherwise, a trivial solution is to first decelerate the object until it stops at some arbitrary location x, then apply constant force towards d until you reach the halfway point between d and x, and then reverse the force. – Ilmari Karonen Jun 14 '16 at 10:11

What you're describing is a classical controls problem. An old subject and widely studied by most engineering students.

There are two approaches you can take, one that involves tweaking (PID controller) and one that's based on math & control theory.

1. PID controller: proportional-integral-derivative controller (more on Wikipedia) relies on the difference in your position and the destination (proportional), your total error distance (integral), and the speed (derivative). This video explains it very well. It works by multiplying each input value by a constant factor (called the gains) to obtain a force to apply. So you'd have a function, getControl(), which provides how much force to apply.

def getControl(gains, dist2dest, totalError, speed):
P, I, D = gains
control = P*dist2dest + I*totalError + D*speed


Picking values for the gains is called 'tuning' and can be done interactively with your physics model. Once you're satisfied with the behavior, save the values.

Info on how you move (i.e. what is the position as a function of force?) is required to solve this with maths.

1. Root Locus (more on Wikipedia). Once you have a transfer function, G (function that describes your system dynamics --> pos/force = G(s), in Laplace-space), you can plot the root locus (matlab fxn 'rlocus') to visualize the dynamics and add controller zeros/poles automatically (matlab fxn 'place') or by hand to place the closed-loop poles where you want in order to obtain desired behavior (no overshoots, short transient time, etc.)

Force can be constrained by simply setting any force greater than fMax to fMax.

• Yes. Use a PID controller, it will handle the initial velocity, and even overcome varying friction. I wrote a primer ps3computing.blogspot.ca/2013/03/… – Bram Jan 22 '18 at 20:53