I believe this is a fairly simple question but I have no idea where to start.
I'm trying to implement a feature where an entity (such as an image) can be flicked across the screen such that it decelerates over time based on an initial speed (non-zero) and coefficient of friction.
In other words, given an initial velocity and constant friction, how can I programmtically determine where an object will be at time t??
Feel free reply using pseudo-code or any programming language you're comfortable with.
Thanks guys
The equation is
s = u*t + 0.5*a*t*t
where,
s is displacement (i.e. position)
u is the initial speed (can be zero too actually)
a is the acceleration (if you want deceleration use a negative value instead)
t is the time elapsed
To account for friction your a will be (on a horizontal surface)
a = -μg
where,
μ is the coefficient of friction
g is gravitational acceleration
Related
I am trying to control a Industrial AC Servo motor using my XE166 device.
The controller interfaces with the servo controller using the PULSE and DIRECTION control.
To achieve a jerk-free motion I have been trying to create a S Curve motion profile (motor speed v/s time).
Calculating instantaneous speed is no problem as I know the distance moved by the motor per pulse, and the pulse duration.
I need to understand how to arrive at a mathematical equation that I could use, that would tell me what should be the nth pulses duration to have the speed profile as an S-Curve.
Since these must be a common requirement in any domain requiring motion control (Robotics, CNC, industrial) there must be some standard reference to do it
Step period is the time difference between two positions one step apart on the motion curve. If the position is defined by X(T), then the step time requires the inverse function T(X), and any given step period is P = T(X+1) - T(X). On a microcontroller with limited processing power, this is usually solved with an approximation - for 2nd order constant acceleration motion, Atmel has a fantastic example using a Taylor series approximation for inter-step time (Application note AVR446).
Another solution which works for higher order curves involves root solving. To solve T(x0), let U(T) = X(T) - x0 and solve for U(T) = 0.
For a constant acceleration curve, the quadratic formula woks great (but requires a square root operation - usually expensive on microcontrollers). For jerk-limited motion (a 3rd degree polynomial minimum) the roots can be found with an iterative root solving algorithm.
I have implemented gravity in my game using RK4, and have a function that calculates the new acceleration. I will also be implemented collision using impulse , so should i change the acceleration too impulse in my RK4 ?
If you're wondering what property to use as the primary one, I suggest velocity.
If you choose momentum, then RK4 must deal with mass; if you choose acceleration, collisions must deal with very small time intervals and huge accelerations; RK4 has velocity already, and since collisions are discrete events that must deal with specific objects and their masses, it's very easy to convert final momentum to final velocity.
I'm writing an application for iphone4 and I'm taking values from the accelerometer to compute the current movement from a known initial position.
I've noticed a very strange behavior: often times when I walk holding the cellphone for a few meters and then I stop, I register a negative peak of overall velocity when the handset decelarates. How is that possible if I keep moving in the same direction?
To compute the variation in velocity I just do this:
delta_v = (acc_previous + acc_now)/2 * (1/(updating_frequency))
Say you are moving at a constant 10 m/s. Your acceleration is zero. Let's say, for the sake of simplicity, you sample every 1 second.
If you decelerate smoothly over a period of 0.1 seconds, you might get a reading of 100 m/s/s or you might not get a reading at all since the deceleration might fall between two windows. Your formula most likely will not detect any deceleration or if it does, you'll get two values of -50 m/s/s: (0 - 100) / 2 and then (-100 + 0) / 2. Either way you'll get the wrong final velocity.
Something similar could happen at almost any scale, All you need is a short period of high acceleration or deceleration that you happen to sample and your figures are screwed.
Numerical integration is hard. Naive numerical integration of a noisy signal will essentially always produce significant errors and drift (like what you're seeing). People have come up with all sorts of clever ways to deal with this problem, most of which require having some source of reference information other than the accelerometer (think of a Wii controller, which has not only an accelerometer, but also the thingy on top of the TV).
Note that any MEMS accelerometer is necessarily limited to reporting only a certain band of accelerations; if acceleration goes outside of that band, then you will absolutely get significant drift unless you have some way to compensate for it. On top of that, there is the fact that the acceleration is reported as a discrete quantity, so there is necessarily some approximation error as well as noise even if you do not go outside of the window. When you add all of those factors together, some amount of drift is inevitable.
Well if you move any object in one direction, there's a force involved which accelerates the object.
To make the object come to a halt again, the same force is needed in the exact opposite direction - or to be more precise, the vector of the acceleration event that happened before needs to be multiplied with -1. That's your negative peak.
Not strictly a programming answer, but then again, your question is not strictly a programming question :)
If it's going a thousand miles per hour, its acceleration is 0. If it's speeding, the acceleration is positive. If it's slowing down, the acceleration is negative.
You can use the absolute number of the velocity to invert any negative acceleration, if that's needed:
fabs(delta_v); // use abs for ints
I am trying to write a simple game, but I'm stuck on what I think is simple physics. I have an object that at point 0,0,0 and is travelling at say 1 unit per second. If I give an instruction, that the object must turn 15 degrees per second , for 6 seconds (so it ends up 90 degrees right of it's starting position), and accelerate at 1 unit per second for 4 seconds (so it's final speed is 5 units per second), how do I calculate it's end point?
I think I know how to answer this for an object that isn't accelerating, because it's just a circle. In the example above, I know that the circumference of the circle is 4 * distance (because it is traversing 1/4 of a circle), and from that I can calculate the radius and angles and use simple trig to solve the answer.
However, because at any given moment in time the object is travelling slightly faster than it was in the previous moment, my end result wouldn't be a circle, it would be some sort of arc. I suppose I could estimate the end point by looping through each step (say 60 steps per second), but this sounds error prone and inefficient.
Could anybody point me in the right direction?
Your notion of stepping through is exactly what you do.
Almost all games operate under what's known as a "game tick". There are actually a number of different ticks that could be going on.
"Game tick" - each game tick, a set of requests are fired, AI is re-evaluated, and overall the game state has changed.
"physics tick" - each physics tick, each physical object is subject to a state change based on its current physical state.
"graphics tick" - also known as a rendering loop, this is simply drawing the game state to the screen.
The game tick and physics tick often, but do not need to, coincide with each other. You could have a physics tick that moves objects at their current speed along their current movement vector, and also applied gravity to it if necessary (altering its speed,) while adding additional acceleration (perhaps via rocket boosters?) in a completely separate loop. With proper multi-threading care, it would fit together nicely. The more de-coupled they are, the easier it will be to swap them out with better implementations later anyway.
Simulating via a time-step is how almost all physics are done in real-time gaming. I even used to do thermal modeling for the department of defense, and that's how we did our physics modelling there too (we just got to use bigger computers :-) )
Also, this allows you to implement complex rotations in your physics engine. The less special cases you have in your physics engine, the less things will break.
What you're asking is actually a Mathematical Rate of change question. Every object that is in motion has position locations of (x,y,z). If you are able to break down the component velocity and accelerations into their individual planes, your final end point would be (x1, y1, z1) which is the respective outcome of your equations in that plane.
Hope it helps (:
In a soccer game, I am computing a steering force using steering behaviors. This part is ok.
However, I am looking for the best way to implement simple 2d human locomotion.
For instance, the players should not "steer" (or simply add acceleration computed from steering force) to its current velocity when the cos(angle) between the steering force and the current velocity or heading vectors is lower than 0.5 because it looks as if the player is a vehicule. A human, when there is an important change of direction, slows down and when it has slowed enough, it starts accelerating in the new direction.
Does anyone have any advice, ideas on how to achieve this behavior? Thanks in advance.
Make it change direction very quickly but without perfect friction. EG super mario
Edit: but feet should not slide - use procedural animation for feet
This is already researched and developed in an initiative called "Robocup". They have a simulation 2D league that should be really similar to what you are trying to accomplish.
Here's a link that should point you to the right direction:
http://wiki.robocup.org/wiki/Main_Page
Maybe you could compute the curvature. If the curvature value is to big, the speed slows down.
http://en.wikipedia.org/wiki/Curvature
At low speed a human can turn on a dime. At high speed only very slight turns require no slowing. The speed and radius of the turn are thus strongly correlated.
How much a human slows down when aiming toward a target is actually a judgment call, not an automatic computation. One human might come to almost a complete stop, turn sharply, and run directly toward the target. Another human might slow only a little and make a wide curving arc—even if this increases the total length to the target. The only caveat is that if the desired target is inside the radius of the curve at the current speed, the only reasonable path is to slow since it would take a wide loop far from the target in order to reach it (rather than circling it endlessly).
Here's how I would go about doing it. I apologize for the Imperial units if you prefer metric.
The fastest human ever recorded traveled just under 28 mph. Each of your human units should be given a personal top speed between 1 and 28 mph.
Create a 29-element table of the maximum acceleration and deceleration rates of a human traveling at each whole mph in a straight line. It doesn't have to be exact--just approximate accel and decel values for each value. Create fast, medium, slow versions of the 29-element table and assign each human to one of these tables. The table chosen may be mapped to the unit's top speed, so a unit with a max of 10mph would be a slow accelerator.
Create a 29-element table of the sharpest radius a human can turn at that mph (0-28).
Now, when animating each human unit, if you have target information and must choose an acceleration from that, the task is harder. If instead you just have a force vector, it is easier. Let's start with the force vector.
If the force vector's net acceleration and resultant angle would exceed the limit of the unit's ability, restrict the unit's new vector to the maximum angle allowed, and also decelerate the unit at its maximum rate for its current linear speed.
During the next clock tick, being slower, it will be able to turn more sharply.
If the force vector can be entirely accommodated, but the unit is traveling slower than its maximum speed for that curvature, apply the maximum acceleration the unit has at that speed.
I know the details are going to be quite difficult, but I think this is a good start.
For the pathing version where you have a target and need to choose a force to apply, the problem is a bit different, and even harder. I'm out of ideas for now--but suffice it to say that, given the example condition of the human already running away from the target at top stpeed, there will be a best-time path that is between on the one hand, slowing enough while turning to complete a perfect arc to the target, and on the other hand stopping completely, rotating completely and running straight to the target.