Determining Future Position of Uniform Circular Motion

[Cato11]

TL;DR Summary

Determining the future position of an object undergoing uniform circular motion

Hello,

Apologies if this is in the wrong section, it's related to circles so I figured Geometry was the best place. I found a very good example online that explains how to determine a future position of an object undergoing uniform circular motion:

(Note that they made a mistake by writing 0.095j as 0.95j on the diagram).

However I am confused as to how a different starting position would affect the calculations above? The example has a start point of (0.175i + 0j). However, what if the particle started at 0.147i + 0.095j (first pink dot above the positive x-axis)? Can anyone please explain how this would alter the calculation? Clearly A, omega and t are the same, so how is the calculation different?

 

[Arjan82]

The formula $r = A \cos(\omega t)\hat i + A \sin(\omega t) \hat j$ now gives $r(0) = 0.175 \hat i + 0 \hat j$, the formula needs to be manipulated such that you get $r(0) = 0.147 \hat i + 0.095 \hat j$.

 

[Cato11]

The formula $r = A \cos(\omega t)\hat i + A \sin(\omega t) \hat j$ now gives $r(0) = 0.175 \hat i + 0 \hat j$, the formula needs to be manipulated such that you get $r(0) = 0.147 \hat i + 0.095 \hat j$.

I'm afraid I don't understand what you mean. I don't see how the equation factors in the start position. In my own use case, I know the start position, A, omega and t, and I need to find the position after t.

 

[Arjan82]

The startposition is whatever the formula gives for $t = 0$. Do you know how to shift a graph along the x axis? So if you have a function $f = f(x)$ with $f(x_0) = 0$, do you know how to change the function to get $f(x_1) = 0$ for $x_1 \neq x_0$?

 

[Cato11]

The startposition is whatever the formula gives for $t = 0$. Do you know how to shift a graph along the x axis? So if you have a function $f = f(x)$ with $f(x_0) = 0$, do you know how to change the function to get $f(x_1) = 0$ for $x_1 \neq x_0$?

Ahh okay I see what you mean. But no I'm afraid I do not know how to change the function, can you please explain?

I need to be able to find the position after a variable time t.

 

[Arjan82]

The more general form of the formula is $r(t) = A \cos⁡(\omega(t-t_0))\hat i + A \sin⁡(\omega(t-t_0))\hat j$. Now you need to find a $t_0$ for which $r(0) = 0.147 \hat i +0.095 \hat j$

 

[Cato11]

The more general form of the formula is $r(t) = A \cos⁡(\omega(t-t_0))\hat i + A \sin⁡(\omega(t-t_0))\hat j$. Now you need to find a $t_0$ for which $r(0) = 0.147 \hat i +0.095 \hat j$

Okay, thank you for explaining this one step at a time. Once I have the t0 that you specify, how is that used to find the new position?

 

[Arjan82]

If you have the correct $t_0$, then you have the evolution of the electron in time for the starting position you specified. And you can see how it evolves over time. So after a similar time as in the original problem, this time the electron will be at a different place.

 

[Cato11]

If you have the correct $t_0$, then you have the evolution of the electron in time for the starting position you specified. And you can see how it evolves over time. So after a similar time as in the original problem, this time the electron will be at a different place.

Thank you for the help Arjan. I'm probably being very dim but I have found t0 (in the example above I get t0 as (2.0081x10^-8).

Are you saying to then plug this value into the equation you specified in #6, where t = (2x10^-7) and t0 is the new value I just found? This doesn't seem to be giving me the right answer.

 

[Arjan82]

What answer did you get, and why is it wrong you think?

So, just to be clear on what we are trying to do here: the problem you quoted said, correctly, that they've chosen that at the initial condition (i.e. t = 0) the electron started at the positive x-axis, which is indeed completely arbitrary. They also stated correctly that if a different starting position was given, a different final position (after 200ns) would be the result.

You've asked the question how a different starting position would affect the calculations. The answer is the equation from #6. So, using t0 you can change the initial position of the electron (the initial position is the position at t=0), and as a result the final position after 200ns will also be different.

 

[Arjan82]

By the way, when I use $t_0 = 2.0081\cdot 10^{-8}$ I get $r(0) = 0.147 \hat i - 0.095 \hat j$. Which is not what you wanted. You wanted $r(0) = 0.147 \hat i + 0.095 \hat j$.

So in that sense it is wrong :)

 

[Cato11]

Thanks Arjen, yes I agree with your last post but think I am still fundamentally missing something in my understanding.

When I use t₀ = -2.0081 x 10^-8, my r(0) = 0.147i + 0.095j. I understand what has happened here, I set the new start position and solved for t(0).

But the whole point is for me to find a future position. Say I now want to find r(200ns) with a start position of 0.147i + 0.095j. When I use Equation #6, I set t = 200ns and t₀ = 2.0081 x 10^-8. I expect this to give me 0.175i + 0j but it does not.

Instead I get 0.072i - 0.159j, which is plainly wrong.

 

[Cato11]

Oh no! I think I was using the t₀ with the wrong polarity! When I repeat the calculation with t₀ = -2.0081 x 10^-8, I get r(200ns) = 0.175i + 0.0004j, which is correct!

Thank you so much for persisting with me

 

[Arjan82]

No problem :)

 

[Fred Wright]

Another approach to the problem is to use a rotation operator on the system. That is, you can represent the system in rotated coordinates. To rotate the system counter clockwise the operator is:
$$
\begin{pmatrix}
x' \\
y'
\end{pmatrix}
=
\begin{pmatrix}
\cos(\theta) & -\sin(\theta) \\
\sin(\theta) & \cos(\theta)
\end{pmatrix}
\begin{pmatrix}
x \\
y
\end{pmatrix}
$$
With $x=\cos(\omega t)$ and $y=\sin(\omega t)$ we get for the rotated system
$$
x'=\cos(\omega t)\cos(\theta)-\sin(\omega t)\sin(\theta)=\cos(\omega t + \theta)
$$
$$
y'=\cos(\omega t)\sin(\theta)+\sin(\omega t)\cos(\theta)=\sin(\omega t + \theta)
$$
$$
\vec r(t)=\cos(\omega t + \theta)\hat i + \sin(\omega t + \theta)\hat j
$$

Since your initial position is $0.147\hat i + 0.95\hat j$ we have $\theta = \tan^{-1}(\frac{0.095}{0.147})$ where $\theta =\omega t_0$

 

[Cato11]

The more general form of the formula is $r(t) = A \cos⁡(\omega(t-t_0))\hat i + A \sin⁡(\omega(t-t_0))\hat j$. Now you need to find a $t_0$ for which $r(0) = 0.147 \hat i +0.095 \hat j$

Hi Arjan,

I've been solving more of these problems and I had another question if that's alright. Is it correct to say that the equation you specified here is only valid for the upper right quadrant of the circle?

It seems when the start point is in the upper left quadrant, the formula changes to:

$r(t) = -A \sin(\omega(t-t_0))\hat i + A \cos(\omega(t-t_0))\hat j$

So I would need to solve r(0) according to this equation instead. Is this correct?

Similarly, for the lower left quadrant the formula becomes:

$r(t) = -A \cos(\omega(t-t_0))\hat i - A \sin(\omega(t-t_0))\hat j$

And for the lower right quadrant:

$r(t) = A \sin(\omega(t-t_0))\hat i - A \cos(\omega(t-t_0))\hat j$

Can you please advise if this is correct?

 

[Arjan82]

I don't see why this would be the case. Can you explain your reasoning?

Did you check continuity? What happens at the boundary? So if the electron is on the x or y axis? I don't think the formula I gave you and the one you say is for the upper left quadrant are continuous there. So the electron would jump from one place to the next.

 

[Cato11]

I don't see why this would be the case. Can you explain your reasoning?

Did you check continuity? What happens at the boundary? So if the electron is on the x or y axis? I don't think the formula I gave you and the one you say is for the upper left quadrant are continuous there. So the electron would jump from one place to the next.

I believe it must be the case because the i and j components are both positive only in the upper right quadrant.

For example, in the upper left quadrant, the i component (x-axis co-ordinate) is clearly negative and is given by $r(t) = -A \sin(\omega(t-t_0))\hat i$.

I discovered this by writing a program to calculate the future positions from a given start point. If I use only the first equation ($r(t) = A \cos(\omega(t-t_0))\hat i + A \sin(\omega(t-t_0))\hat j$), the future positions turn out incorrect when the start point is in any of the other three quadrants. However, by updating the equations (as listed above) based on the quadrant, the future position always comes out correct.

What happens at the boundary is an interesting question - I don't know actually know the answer. I cannot get a point to lie on the boundary since I am dealing with floating point numbers and the position is always shifted either side by a tiny order of magnitude.

 

[Arjan82]

But the sine becomes negative at $\pi/2$ right? So the $x$ component becomes negative if $\pi /2 < \omega(t-t_0) < 3\pi / 2$. So the the $x$ coordinate indeed becomes negative as it should. I don't see why you should alter the equations for that. Can you show me the program?

 

[Cato11]

Here is the function that I am describing:

public static Vector3 UniformMotionFuturePosition(Vector3 startPosition, Vector3 orbitCentre, float orbitRadius, float orbitPeriod, float t)
{
    /* This function takes a start position and uses the equations of uniform circular motion to
           calculate the future position at a specified time 't'  */    // Get the start co-ordinates (x,y) relative to the orbit circle (cannot exceed radius)
    float startPositionX = startPosition.x - orbitCentre.x;
    float startPositionY = startPosition.z - orbitCentre.z;

    // Determine the quadrant occupied by the start point
    string entryQuadrant = "";
    if (startPositionX >= 0 && startPositionY > 0) entryQuadrant = "TopRight";
    else if (startPositionX <= 0 && startPositionY > 0) entryQuadrant = "TopLeft";
    else if (startPositionX < 0 && startPositionY <= 0) entryQuadrant = "BottomLeft";
    else if (startPositionX >= 0 && startPositionY < 0) entryQuadrant = "BottomRight";
    else Debug.LogError("Could not locate the start quadrant!");    // Get the ratio of the start point to the radius and correct if necessary to prevent to prevent sin or cos out of range errors
    float ratioX = startPositionX / orbitRadius;
    if (ratioX > 1) ratioX = 1;
    else if (ratioX < -1) ratioX = -1;

    float ratioY = startPositionY / orbitRadius;
    if (ratioY > 1) ratioY = 1;
    else if (ratioY < -1) ratioY = -1;

    // Solve equations for t0 and then find future position after specified time 't'
    float t0X = 0, t0Y = 0;
    float futurePosX = 0, futurePosY = 0;
    switch (entryQuadrant)
    {
        case "TopRight":
            t0X = (Mathf.Acos(ratioX) * orbitPeriod) / (Mathf.PI * -2);
            t0Y = (Mathf.Asin(ratioY) * orbitPeriod) / (Mathf.PI * -2);
            futurePosX = orbitRadius * Mathf.Cos(((Mathf.PI * 2) * (t - t0X)) / orbitPeriod);
            futurePosY = orbitRadius * Mathf.Sin(((Mathf.PI * 2) * (t - t0Y)) / orbitPeriod);
            break;

        case "TopLeft":
            t0X = (Mathf.Asin(-ratioX) * orbitPeriod) / (Mathf.PI * -2);
            t0Y = (Mathf.Acos(ratioY) * orbitPeriod) / (Mathf.PI * -2);
            futurePosX = -orbitRadius * Mathf.Sin(((Mathf.PI * 2) * (t - t0X)) / orbitPeriod);
            futurePosY = orbitRadius * Mathf.Cos(((Mathf.PI * 2) * (t - t0Y)) / orbitPeriod);
            break;

        case "BottomLeft":
            t0X = (Mathf.Acos(-ratioX) * orbitPeriod) / (Mathf.PI * -2);
            t0Y = (Mathf.Asin(-ratioY) * orbitPeriod) / (Mathf.PI * -2);
            futurePosX = -orbitRadius * Mathf.Cos(((Mathf.PI * 2) * (t - t0X)) / orbitPeriod);
            futurePosY = -orbitRadius * Mathf.Sin(((Mathf.PI * 2) * (t - t0Y)) / orbitPeriod);
            break;

        case "BottomRight":
            t0X = (Mathf.Asin(ratioX) * orbitPeriod) / (Mathf.PI * -2);
            t0Y = (Mathf.Acos(-ratioY) * orbitPeriod) / (Mathf.PI * -2);
            futurePosX = orbitRadius * Mathf.Sin(((Mathf.PI * 2) * (t - t0X)) / orbitPeriod);
            futurePosY = -orbitRadius * Mathf.Cos(((Mathf.PI * 2) * (t - t0Y)) / orbitPeriod);
            break;

        default:
            Debug.LogError("Could not locate the start quadrant!");
            break;
    }

    // Scale the co-ordinates to lie on the orbit radius
    futurePosX += orbitCentre.x;
    futurePosY += orbitCentre.z;

    // Return the future position as a Vector3
    return new Vector3(futurePosX, 0, futurePosY);
}

It's worth noting that this code appears to produce exactly the right results. If anything is unclear, let me know?

Edit: There was initially a "direction" variable present which served no purpose, thus I removed it. It does not affect the functionality of the code.

 

[Arjan82]

what defines the variable 'direction' ?

 

[Cato11]

what defines the variable 'direction' ?

I thought you might ask that, please see the edit above.

 

[Arjan82]

If I do the simplest of testcases:

startposition = (1,0)
orbitCentre = (0,0)
orbitRadius = 1
orbitPeriod = 2*pi
t = 0..1

Then I expect a circle (agree?). What I actually get is this:

 

[Arjan82]

So there are a couple of issues:

In your calls to sin, asin, cos and acos you put the ratioX|Y = startPostitionX|Y / orbitRadius. Instead of, as the formula prescribes orbitPeriod*(t - t0)

Also, you make a distiction between t0X and t0Y, which makes no sense to me. There is only one t0, this is a scalar (the time), not a vector.

 

[Cato11]

I'm pretty sure there is no mistake with the ratio. Say for example I have:

0.147i = 0.175 cos (w (t - t0))i. The ratio is simply 0.147/0.175. I do this before computing the inverse cosine so that I can check for floating point inaccuracy and amend if necessary. Without this, sometimes it may return 1.0000001 which would return a NaN math error.

Okay I see your point regarding t0. Let me give you an example of the issue I am experiencing:

Here is an object entering a circular motion. It has an orbital speed of 180°/s and thus a period of 2s. I have set the function to predict the future position at t = 0.5s as soon as it enters the green circle. We can expect it to predict the top of the circle, i.e. 90° of travel (ccw motion).

Lo and behold, it works as expected using your original formula in #6. (The pink dot is the prediction).

However, if I now enter from a different quadrant, with the exact same parameters, here is what happens:

It should predict the right hand side of the circle, but you can see it has got the sides wrong. I have tinkered around with this significantly, and the only solution I could find was the tweaking the equations as I outlined in #16 (as reflected in the code block). That appears to always result in correct predictions.

Unless I am computing the original formula wrong, but then surely it wouldn't work correctly in the first case?

 

[Arjan82]

Ok, my bad about the ratio, you are right.

So, you also interpret the orbitPeriod in Hz, not in rad/s as I did.

Then, first of all, t0X and t0Y are exactly equal, so no need for the distinction.

Second of all, for the futurePosX|Y, inside the cos|sin, you divide by the orbitPeriod. You should multiply!

So if I multiply by orbitPeriod, and set entryQuadrant to be always 'TopRight' (overruling your branching of the formula), then it works fine for me.

 

[Cato11]

Ok, my bad about the ratio, you are right.

So, you also interpret the orbitPeriod in Hz, not in rad/s as I did.

Then, first of all, t0X and t0Y are exactly equal, so no need for the distinction.

Second of all, for the futurePosX|Y, inside the cos|sin, you divide by the orbitPeriod. You should multiply!

So if I multiply by orbitPeriod, and set entryQuadrant to be always 'TopRight' (overruling your branching of the formula), then it works fine for me.

The Period is simply expressed in seconds so it shouldn't really matter right? I just said 180°/s as it's easier for me to conceptualise that way.

I am baffled as to how you can multiply by the orbit period?! I substituted omega for (2pi/T) hence why it's divided by the orbit period. Can you show the formula you are using please.

 

[Arjan82]

Ok, my brain is seriously malfunctioning today... sorry for the confusion. You use a period, not a frequency, so you should indeed divide... my word... my brain went on holiday apparently...

Let me get back to you once I've figured it out, for real...

 

[Cato11]

No worries and thanks for your efforts, I appreciate the help.

Interestingly, I have apparently found another way of generating correct predictions using a much simpler method. Rather than altering the formulas, I simply alter the sign of the 2pi during the t0 calculation, by making it positive when the object arrives from the bottom side of the circle (a negative Y co-ordinate).

The revised function is as follows:

public static Vector3 UniformMotionFuturePosition(Vector3 startPosition, Vector3 orbitCentre, float orbitRadius, float orbitPeriod, float t)
{
    /* This function takes a start position and uses the equations of uniform circular motion to
       calculate the future position at a specified time 't'. */

    // Get the start co-ordinates (x,y) relative to the orbit circle (cannot exceed radius)
    float startPositionX = startPosition.x - orbitCentre.x;
    float startPositionY = startPosition.z - orbitCentre.z;

    // Get the ratio of the start point to the radius and correct if necessary to prevent sin or cos errors
    float ratio = startPositionX / orbitRadius; // could use either X or Y position
    if (ratio > 1) ratio = 1;
    else if (ratio < -1) ratio = -1;

    // Solve for t0 and calculate the future position co-ordinates
    float polarity = 1;
    if (startPositionY < 0) polarity *= -1;

    float t0 = (Mathf.Acos(ratio) * orbitPeriod) / (Mathf.PI * -2 * polarity);
    float futurePosX = orbitRadius * Mathf.Cos((((Mathf.PI * 2) * (t - t0)) / orbitPeriod));
    float futurePosY = orbitRadius * Mathf.Sin((((Mathf.PI * 2) * (t - t0)) / orbitPeriod));

    // Scale the co-ordinates to lie on the orbit radius
    futurePosX += orbitCentre.x;
    futurePosY += orbitCentre.z;

    // Return the future position as a Vector3
    return new Vector3(futurePosX, 0, futurePosY);
}

This appears to always generate accurate predictions. I'm not sure why it works, but I have tested it at various positions around the circle using a range of t values, and I have yet to see a mistake.

 

[Arjan82]

Ok, the branching is not necessary for the general formula:
$$
r(t) = A\cos(\omega(t-t_0)) \hat i + A\sin(\omega(t-t_0)) \hat j
$$
But it ís a possible solution for the way you compute $t_0$. So say you want to compute for a starting position:
$$
r(0) = -0.17365 \hat i + 0.98481 \hat j
$$
(this is at 100º with A = 1). Then you set
$$
-0.17365 = A \cos(\omega(0 - t_0)) = A \cos(- \omega t_0) = A \cos(\omega t_0)
$$
The last step because the cosine is symmetric, i.e. $\cos(x) = \cos(-x)$. And
$$
0.98481 = A \sin(\omega(0 - t_0)) = A \sin(- \omega t_0) = -A \sin(\omega t_0)
$$
Again, the last step utilizes the point symmetry of the sine (i.e. $\sin(-x) = -\sin(x)$). The point is that they both need to be true simultaneously. If you invert these formulas you get:
$$
t_0 = \arccos(-0.17365 / A) / \omega = 0.27778s
$$
$$
t_0 = -\arcsin(0.98481 / A) / \omega = -0.22222s
$$
With $A = 1m$ and $\omega = 2\pi \ rad/s$. The first result equals 100/360, which seems to make sense, but the second is negative which seems to make no sense at all. But this is because the range of $\arcsin$ is from $-\pi/2$ to $\pi/2$, instead of $0$ to $2\pi$ which you may have expected. What you therefore have computed is the time you have to go back to get to -80º in the circle. This is exactly half a period off (i.e. there is 180º between 100º and -80º). You need to correct for this. This can be done using branching.

So, your code basically corrects for your computation of $t_0$. Also, t0X and t0Y are not always equal because of this, then you correct with adjusting the general formula. But I'm curious if all is still correct if you do not use neat angles like 0º or -90º, but 20º, 100º, -30º or whatever. It could still be correct, but there may still be some strange things going on.

So what I would do in your code is separate out the computation of a single $t_0$. This can be done using branching. But then you should just be able to use the general formula without a problem.

 

[Arjan82]

So you've found a solution not using branching, but indeed adapting t0. That seems to be correct indeed.

 

[Cato11]

Thank you very much for the in-depth explanation, I think most of it made sense and it reflects what I was seeing as I attempted the branching method.

I definitely prefer the second method of adapting t0 as it's a lot simpler. I've also tried it with neat and messy angles like 74° and it always seems to produce the correct results. Phew!

So I take it this second method can be reliably trusted?

Also, any idea how to adapt this for clockwise motion? Is it simply a case of flipping the "polarity" variable?

 

[Arjan82]

Also, any idea how to adapt this for clockwise motion?

I'll leave that as an exercise to the reader ;)

 

[Cato11]

I'll leave that as an exercise to the reader ;)

Ah.. fair enough!

But regarding the second method of adapting t0. Do you believe this to be a reliable one? You mentioned with the first method of branching that messy things could be going on.

 

[Arjan82]

I mentioned that because I could not oversee the consequences of the combination of the two t0's you've computed and all variations of the general formula you've used in the first solution (maybe one quadrant ran backwards for all I knew) I didn't check that.

But you can check that yourself. If the starting points in all quadrants give correct results, if small additions in the starting position (1 degree, say) give the same difference in the future point, and if the connections are continuous (so at both sides of the point when Y of the startingpoint flips sign) then your solution works.

You can also try to reason why using the polarity works by writing down examples for all quadrants and see what the computation of t0 yields, looking at the range of acos(). Then it should be easy to see why the polarity works (if indeed it does, I didn't check it).