# How many stages necessary to stabilize position while controlling torque?

I'm assuming that since torque translates into acceleration, the basic transfer function from torque to position becomes

$1/s ^ 3$

Does this mean that 3 pid controllers are required to properly control the process? ie acceleration, velocity and finally position? Perhaps a two stage position+velocity controller can decently aproximate the solution, but from mathematical standpoint, how many stages are actually needed for optimal control?

I would say the transferfunction becomes $\frac{1}{s^2}$ iff you assume you have a perfect drive without any dynamics.

Since this system is unstable you have to be careful choosing your controllers. The best way in my opinion is to use a standard state feedback controller (LQR, Ackermann). The huge advantage using state feedback is that you can chose the pole location (in case of Ackermann) resp. the weight (in case of LQR) for each state separately.

Loop shaping in the frequency domain will work as well, see e.g. Loop Shaping, (Department of Automatic Control LTH, Lund University).

• Can you elaborate on why transfer function becomes $1/s^2$ solely in absence of disturbances? Don't we have to integrate twice to go from acceleration which we can control to position which we want to stabilize and therefore end up with $1/s * 1/s * 1/s$? – Martin Jan 4 '18 at 10:38
• In Ackermanns formula it is necessary to pick a "desired" transfer function to which one wants to transform the process transfer function. How would one go about determining the desired transfer function? – Martin Jan 4 '18 at 10:49
• The transfer function is just a (rational) relation between input and output of your system. If your input is a torque $\tau$ and you assume an ideal drive the equation $\tau = k a$ where $a$ is the acceleration $a=\dot{v}, v=\dot{x} \rightarrow a=\ddot{x}$ Or in laplace domain: $\tau= k {s^2 x}$. Now $x$ is your output, $\tau$ is your input and the transfer function is defined as TF=out/inp $\rightarrow$ $G(s) = \frac{x}{\tau} = \frac{x}{k s^2 x} = \frac{1}{k s^2}$ – madn Jan 4 '18 at 13:11
• about the Ackermann thing... you need to choose the desired location of the closed-loop poles, this is in fact not too straight forward. First of all, the desired cloesd-loop should be stable, therefore all poles must have a real part smaller than 0. How "far left" / "much negative" you want to choose your poles depends on your actuators. Think about the poles drawn in a pole-zero plot the further left you go, the "faster" this pole is, therefore the more power your actuators need to apply. – madn Jan 4 '18 at 13:15

If you are trying to implement torque control, you only need a control loop around torque. The challenge isn't in trying to integrate the torque (or acceleration) controller, and passing it to a velocity control loop, then finally passing it to a position control loop. The challenge is in finding the torque setpoints for your torque control loop so that the manipulator achieves the desired performance. For this you need a model of your robot + environment if you want to use torque control to follow position profiles. That model will be where you incorporate $s^2$ differentiation to get to desired accelerations.

But I have to ask - why are you implementing torque control to achieve positional stability? This gets very complicated if the impedance of your robot's environment changes. For example, of the system is lifting a box, controlling the torque can result in the desired positional profile. But what if the robot encounters an immovable object - then you will never get the commanded positional changes. Or, what if you have multiple heavy and light boxes? The position-to-torque model must account for these things.

See @MarkBooth's answer to this SE question about position, velocity, and torque control.

• I solved it quite easily actually using just a PD control loop with high gains around torque together with acceleration feedforward. This worked wonderfully for controlling all three (position, velocity, acceleration). However I have also used a full state observer to implement it which was a bit more complex but that is not part of the controller - it just predicts actual position, velocity and acceleration based solely on precise position information. (two observers actually - one for velocity and one for acceleration - this seemed to work best. Kalman filter based) – Martin Apr 4 '18 at 18:29
• Thanks, @Martin. That acceleration feedforward computation is one example of the model I was trying to describe... – SteveO Apr 4 '18 at 19:02
• I have extended my solution with automatic model identification. While in my case the mass remains roughly the same, if mass changes drastically it can be easily made one of the parameters of the model state. It is then necessary to identify the overall model using measured mass (with a mass sensor) and then to build controller around that. It is possible also to estimate mass based on work done (since I can measure consumed current I can also compute work done) however this assumes that used current is always linearly dependent on mass (if not then mass sensor is needed). – Martin Jun 6 '18 at 13:56