# Arm Position Control

Our team has a motor driven arm mechanism that rotates around an axis and has a potentiometer for feedback.

The arm is fairly heavy and unbalanced, and it’s range of motion is significant (180deg, give or take a bit). Since the torque required to counteract gravity varies with the angle of the arm, it seems like the simplest form of PID control is not appropriate (ie: directly driving the motor from the PID constants and potentiometer input).

I’ve kicked around a few different ideas, but I’m not experienced enough with controls to know a good solution when I see one. All of my ideas hinge on the idea that the torque needed to counter-act gravity at a given angle is the cosine of the angle multiplied by the torque required at 0deg (please correct me if this is wrong :] )

So here are the different approaches I have considered:

1. Multiplying the output of a PID loop tuned for the 0deg position before it is sent to the motor. Either
motor_output = PID_output * cos(theta) //working against gravity
motor_output = PID_output - (PID_output * cos(theta)) //when assisted by gravity
(We will likely have special cases to handle angles close to 90deg when the setpoint is not 90deg, these can be ignored)

2. Using the feed-forward (F) term of the PID loop, where the reference F(0deg) is the force required to maintain a position of 0deg, and constantly updating the F term based on the current position (or possibly target position):
F = F(0deg) * cos(theta) //Different PID values would remain unchanged with angle

3. Use discrete sets of PID constants at different angles, each tuned for operating within a particular range of the full swing of the arm, for each direction, and each load requirement.

Which of these approaches makes the most sense? Is there a better method that I haven’t thought of?

I’ve implemented case 1 (but cannot test yet), although I’m beginning to consider case 2 after learning how the F term is used.

I’m also a little curious what the best method for minimizing I-term wind-up, my plan is to simply disable the I term until we’ve approached the set-point, but I’m curious how others typically handle this.

Have you considered using a velocity control PID. This will attempt to keep a constant velocity of your arms

Is there a way that you could counter balance your arm? If it is possible that will make the tuning of the PID that much easier since the motor will only need to move the arm and not the weight of it. We’ve used surgical tubing to counter balance arms in previous years, including this year.

I would strongly encourage you to count-balance your arm with springs of some sort.

I’ll bet there’s an easy way to have the spring force vary with angle such that it almost always directly counter-acts gravity.

There are a couple ways you could do this:

-First off, look at how much friction there is in the arm. For a low-range-of-motion thing like a 180deg arm, I actually recommend a bit of friction. Our 2013 arm had an aluminum shaft pressed into a delrin block as the final bearing. We could have done ball bearings or needle bearings, but the added friction helped the control loops stabilize (and they had more than enough torque to do it, since we also hung with it).

-Second, look at your counterforce. Always counterforce. There are a lot of ways to do it.

-Third, look at your software. A basic PID control will probably work but not be optimal at all positions (As you said). There are a few ways to get around this:

-Gain Scheduling. You would have a no-gravity and peak-gravity gainset (kP,kI,kD) and blend them with the angle. This should work fairly well

-Feed Forward Gravity - You find the motor power to hold the arm at peak gravity (and assume it’s 0 at no-gravity) and multiply it by sin or cos of theta, then add it in.

-In general, if you know exactly what you want from a control-loop steady state, you should add it in as a feed forward term. Then the PID only has to handle the slop.

-In the context of an arm, velocity PID is useless. It would not provide the desired response at all.

My team is having this same issue, i think.

I am trying to tune a PID loop to control angular position of the arms. It should have been simple.

We are using an Encoder on the shaft for Angular measurement.

It should have been simple feed the input of the PID loop the encoder, set max and min outputs to 1, -1. and it should have worked. but the gains are extreamly low, 0.015 for P. for it not to overshoot. than when any load is applied it slows way down.

My experience with pid loops is limited. but no mater the load it will do its best to get to the setpoint repeatedly, same speed, time etc. within the capabilities of the motor.

I’ll add (how did I forget this!?) that the last time we used PID control for an arm we counter-balanced it with a pneumatic cylinder using flow control to dampen the arm’s motion and a secondary regulator to fine-tune the cylinders force and easily bleed off pressure when the arm was compressing the cylinder. The PID loop then became a P-only loop with very good control, no I or D to tune or deal with at all, and thus no wind-up issues.

Use a torsion spring around the arm’s pivot point to provide counter-balance. Set it up so that there’s no force at 90 degrees.

We’ve done a lot of single jointed arms that are not counter-balanced, and have always been happy with simple PID

control. This does depend significantly on the mechanical design of your arm. Always start with the easiest solution and then decide if it needs more work rather then jumping to a more complicated solution based on theory.

We’ve used trigonometry in the past (essentially sin of the angle - with zero degrees being vertical) with some success, but that was mainly for steady state offset.

In this case a torsion spring would work, but so would latex tubing (which we’ve also used with success… way more often than I’d admit). The nice thing about bungee is that you can always add more if it isnt pulling enough.

The arm swings from 0 to 180 degrees. How would you mount the latex tubing?

I’d have to see the layout of the arm, but there are ways it could be done.

If there were a stationary attachment point located vertically above the pivot, and of sufficient height, one could secure the tubing to that point and to the arm. That would provide minimum torque at noon and maximum torque (of opposite signs) at 3 and 9 o’clock.

Barring such an arrangement, what other options do you have in mind?

How are you driving the arm? Have you thought about using a Worm Gear so that once the arm is at the set point motor power can be removed and the Worm will maintain the angle.

I guess the problem of getting to the setpoint without overshooting/oscillating still remains… unless accuracy and/or dynamic response are not important, in which case just gear the speed way down.

Instead of 1 right above it 2 on either side level with the rotation point. It wouldn’t be as optimal as a point right above it but it would help a bit. As you move those points higher they help more and more.

I think we can assume a suitable attachment point vertically below the pivot. A short extension on the opposite side from the arm would provide a way to use a downward force to counterbalance it.

A sprocket-and-chain scheme can put a “virtual pivot point” anywhere convenient.

If they are level with the rotation point (by this I assume you mean the arm pivot), they provide zero torque at the extremes (where it is most needed).

-In the context of an arm, velocity PID is useless. It would not provide the desired response at all.

Maybe i read his question wrong but if you are wanting to move the arms from 0 deg to 180 deg and have your controller take into account the increased torque a velocity PID controller would be perfect for this.

This would allow the arms to move at a constant angular rate regardless of the torque needed.

However this would not allow the arm to stop right at 0 and 180 deg. To do this you would need to transition from the velocity control to a position control when you got close to your desired position.

Correct, it would be more optimal between the 45’s but past that it would not help as much.