# Centrifuge Motion Equations

1. Jul 22, 2008

### KLoux

Hello. A few of us at my company have been trying to solve this problem for a few weeks now, without success, and so now I turn to the brilliant minds of the people who frequent this forum for help :-)

We operate a centrifuge that spins between 1.4 G and 9 G. The command that we send to our motion control algorithm is a G command, so our algorithm takes the G command and computes the required speed of the arm to reach that desired G level. For steady-state, this is easy and we use the following equation:

$$\omega = \sqrt{ \frac{ g }{ R } \sqrt{ G_c_m_d^2 - 1 } }$$

which is derived from

$$G_a_c_t^2 = \left( \frac{ \omega^2 R }{ g } \right)^2 + 1$$

where $$g$$ is the acceleration due to gravity, $$R$$ is the arm length, and $$G$$ is the commanded or actual G level.

We are often required to follow an arbitrary G profile, however, and the arm's tangential acceleration comes into play. The new equation that describes the machine's G level is this:

$$G_a_c_t^2 = \left( \frac{ \omega^2 R }{ g } \right)^2 + \left( \frac{ \alpha R }{ g } \right)^2 + 1$$

This is of course quartic in $$\omega$$ instead of quadratic, as is true when tangential acceleration is neglected. We have tried making the substitution $$\omega = \omega_0 + \alpha \triangle t$$ and solving for alpha as well as the substitution $$\alpha = \frac{ \omega - \omega_0 }{ \triangle t }$$, where $$\omega_0$$ is the arm speed calculated at the previous frame and $$\triangle t$$ is the time elapsed between frames. In both cases, we can solve the resulting quartic equation, and we get two real roots and two complex roots. Ignoring the complex roots leaves us with two choices. In case of an increasing G command, we can choose either of the remaining roots, and it gives us a satisfactory solution, where as the G command reaches a plateau, the tangential term is reduced to zero and the solution of this equation matches the solution of the simpler equation above.

The problem is in the case of a decreasing G command. There are still only two real solutions. Depending on the shape of the curve we are trying to follow, we must choose one root or the other, and sometimes it is necessary to switch between the two to avoid reaching a point where all four roots are complex. Unfortunately, while we are capable of doing this, in most cases we can even decide when to switch roots, and the magnitude of the G forces that are generated match the command exactly, the machine motion is unacceptable. For example, the centrifuge will start deccelerating rapidly, so that the arm actually stops and changes direction and all of the acceleration is a result of the tangential acceleration of the arm. There would then be a step change the speed or acceleration (or both) to correct the speed and give a more reasonable number. This, of course, is a solution that we cannot implement. There is no case in which the arm speed should be less than the speed required to generate 1.4 G.

1. If a solution exists for the onset, a solution must exist for the offset, right? I know I can take the desired curve, flip it around in time, find the time history of the rotation rate that generates the correct curve, and flip that around again to get a solution that works. It will work every time. Why can't I do this in real-time?

2. Is there a way that I can impose my additional constraints on the arm speed and acceleration (no step changes in speed, no speed less than the 1.4 G speed, etc.) and solve the problem such that these constraints are met?

-Kerry

2. Jul 23, 2008

### uart

Kerry I don’t think the problem is so much the maths as it is the type of controller you’re trying to implement. From what you post I think you're essentially trying to implement a "one step" controller. This is where you compute the required input to get some desired output and try to get there in one step. You know it might not really get you exactly there in one step but you figure that after that step you can re-measure the relevant variables and calculate another step and so one.

There are other control methods that are inherently more stable. The simplest of course being a basic proportional feed back controller. For example something as simple as this:

$$w^{*} = w + k (G^{*} - G)$$

Where w* is the speed command you send to your centrifuge and w is the measured present speed. Similarly G* is the "G_command" sent to (that is, the input to) your controller and G is the computed present G (based on your measured present variables, omega and alpha etc).

In a way this is like the opposite extreme of the one step control but in practice it often works quite well. Typically you would adjust the parameter "k" to get it as fast and accurate as possible without the controller getting too close to unstable. Obviously lots of other enhancements are possible to that most basic feedback controller; I'm just suggesting you try some sort of control algorithm along these lines.

3. Jul 23, 2008

### KLoux

uart, thanks for the reply. I assure you this is not a control problem. Our control laws only come into play only after the desired arm speed has been calculated, in fact, the output of the algorithm that I am asking for help with becomes the input to our controller. We implement multiple rate and acceleration limiters and filters to ensure that the command to the machine is smooth and within our equipment's capabilities.

Taking tangential acceleration into account is something that we don't currently do. We use the simpler version of the equation without tangential acceleration to drive our machine. This results in a slightly higher acceleration level during the transients, since the arm speed alone is generating the desired accelerations.

Thanks for the suggestion!

-Kerry

4. Jul 24, 2008

### uart

Yes I understand that you already have a speed control loop, what I'm suggesting is that you try implementing a G control loop outside of this. This is a common situation in control systems where the output of the "outer" control loop provides the input to the second (the inner) control loop. In this case the G-controller is the outer loop, and it's output (w*) provides the input (target speed) to the inner loop of the speed controller.

Anyway if you don't want to try this method then I suggest that you simply limit the slew-rate more for the negative speed ramp (that is, reduce the maximum deceleration).

5. Jul 24, 2008

### uart

BTW. I still don't really see what the problem is regarding choosing the correct root. You're just solving the following equation right?

$$\left( \frac{ \omega^2 R }{ g } \right)^2 = G_{act}^2 - \left( \frac{ \alpha R }{ g } \right)^2 - 1$$

So the solution can be expressed as two nested square-roots (the square-root of a square root) if I'm following correctly. So the choice of roots seems trivial to me, the root of the inner square-root should always be chosen as positive and the root of the outer square-root should always be chosen such that the sign of w remains unchanged. I don't see any real reason for ever changing the direction of rotation so that means just choosing the positive square-root in each case.

Anyway it's becasue I can't see any real problem with the current mathematical calculations that makes me think that the real problem is somewhere else. I believe that the real problem is the coupling of variables that is occuring between the calculated speed reference (w) and the tangential acceleration. My suggestions above are really aimed at addressing this issue.

6. Jul 24, 2008

### KLoux

I am solving that equation, but I need to know $$\alpha$$ and $$\omega$$ at the same instant in time. I need to make a substitution for either $$\alpha$$ in terms of $$\omega$$ or $$\omega$$ in terms of $$\alpha$$ to do this. This introduces quartic and cubic terms to the equation, thus making choosing the roots non-trivial.

I now see what you mean about the controller solution. I might consider this if it turns out that there is no closed form solution the this problem, but my belief is that there is a closed-form solution. Perhaps it was confusing to add the "act" and "cmd" subscripts to the equations in my OP, but all of these calculations are done without any feedback from the machine - I only meant to show how the equations were derived. Yes, I could add another loop to the controller, but I would like to consider this solution only as a last resort.

Thanks!

-Kerry

7. Jul 24, 2008

### jamesrc

Maybe I just worked this out too quickly but, check my math here:

Assuming you're comfortable with approximating instantaneous acceleration with
$$\dot{\omega}=\frac{\omega - \omega_o}{\Delta t}$$

then:

$$G^2 = 1 + \left( \frac{\omega^2 R}{g}\right)^2 + \left( \frac{\dot{\omega R}}{g}\right)^2$$
$$\omega^2 + \dot{\omega} = \frac{g}{R}\sqrt{G^2-1}$$

The term on the RHS is just a number computed from your known command profile. (I'll call the RHS K from now on so I don't have to type so much.)

$$\omega^2 + \frac{1}{\Delta t}\omega - \left( \frac{\omega_o}{\Delta t} + K \right) = 0$$

which is just quadratic in speed and solvable (you know your sample rate and your using the last measurement of speed as omega_o). You should get two real roots, right? And you would always choose the positive root.

As you have discussed above, it may be a problem to use a speed controller to control G; hopefully your speed measurement is not too noisy and that approximation of acceleration works out.

8. Jul 24, 2008

### KLoux

Hmm, jamesrc, I think your algebra is wrong...

$$\sqrt{A^2 + B^2} \neq A^2 + B^2$$

I made the same approximation for acceleration. It is necessary to make an approximation (although, not necessarily that one) because we are using a digital control system and only know the acceleration instantaneously.