View Full Version : Arm Position Control
DjScribbles
07-02-2014, 08:27
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
notmattlythgoe
07-02-2014, 09:01
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.
JamesCH95
07-02-2014, 09:22
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.
Alchemy99
07-02-2014, 10:04
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.
JamesCH95
07-02-2014, 10:08
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.
Joe Ross
07-02-2014, 13:39
-Third, look at your software. A basic PID control will probably work but not be optimal at all positions (As you said).
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.
In this case a torsion spring would work, but so would latex tubing...
The arm swings from 0 to 180 degrees. How would you mount the latex tubing?
notmattlythgoe
07-02-2014, 15:00
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.
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?
arizonafoxx
07-02-2014, 15:13
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.
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.
notmattlythgoe
07-02-2014, 15:33
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?
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.
Alan Anderson
07-02-2014, 15:36
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?
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.
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.
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.[/QUOTE]
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.
notmattlythgoe
07-02-2014, 15:44
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).
Correct, it would be more optimal between the 45's but past that it would not help as much.
notmattlythgoe
07-02-2014, 15:49
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.
Or even extend the arm through the pivot point and attach the bungee to that point and directly below the pivot point.
-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.
Or you could rely on the derivative control to slow it down properly.
Stacking and switching PID controls is usually a lot more work than it's worth.
I agree Joe, the need for any gain scheduling or other controls is dependent on the arm. Some arms need adjustment, some do not. I have worked with both.
Or even extend the arm through the pivot point and attach the bungee to that point and directly below the pivot point.
Yes, of course; that's a mirror image of the on-top approach... except with much higher forces (due to smaller distances).
notmattlythgoe
07-02-2014, 16:06
Yes, of course; that's a mirror image of the on-top approach... except with much higher forces (due to smaller distances).
Exactly.
notmattlythgoe
07-02-2014, 16:11
You could also use a gas spring to limit the speed that the arm could move. Set up the same as my last suggestion. It would give you hard stops on both ends, it wouldn't help with the torque but it would help with the reaction time of the pid being different in different locations.
[QUOTE=apalrd;1339275]Or you could rely on the derivative control to slow it down properly.
The D term just slows down the response of the system not the overall speed of the system at Steady State.
You are correct though that switching between two controllers needs to be done carefully.
Or you could rely on the derivative control to slow it down properly.
The D term just slows down the response of the system not the overall speed of the system at Steady State.
That depends on how the "D" in your PID is implemented.
In PID:
-P is the error of the position
-I is the accumulated error of position (steady state error)
-D is the velocity and often opposes the other two terms
A proper D gain will compensate for the velocity. With all of the gains set correctly, there will be a point where the error is so great that the sum of P, I, and D is larger than the motor's max output, so the negative D term will have no effect. As the arm slows down, the D term will compensate for the velocity (inertia) as the arm approaches the target.
When I calibrate PID loops by hand, I usually only end up with a PI controller. I have tried to add D manually with little success. When I calibrated automatically (using the ultimate stability method), I found that the D gains were many times what I was getting by hand, but the system worked beautifully.
On a side note, I autotuned a full PID loop on two VRC robots (relatively high intertia, fast gear ratio, more counterforce than gravity long arms) and found that a single PID gain set was adequate. On a cam driven linkage on our 2012 FRC robot, I needed to schedule the gains because the motion ratios changed significantly over the stroke.
In PID:
-P is the error of the position
-I is the accumulated error of position (steady state error)
-D is the velocity and often opposes the other two terms
A proper D gain will compensate for the velocity. With all of the gains set correctly, there will be a point where the error is so great that the sum of P, I, and D is larger than the motor's max output, so the negative D term will have no effect. As the arm slows down, the D term will compensate for the velocity (inertia) as the arm approaches the target.
When I calibrate PID loops by hand, I usually only end up with a PI controller. I have tried to add D manually with little success. When I calibrated automatically (using the ultimate stability method), I found that the D gains were many times what I was getting by hand, but the system worked beautifully.
On a side note, I autotuned a full PID loop on two VRC robots (relatively high intertia, fast gear ratio, more counterforce than gravity long arms) and found that a single PID gain set was adequate. On a cam driven linkage on our 2012 FRC robot, I needed to schedule the gains because the motion ratios changed significantly over the stroke.
It's really tough to get a D term to compensate for the inertia of an arm. In order for the D to really affect the system the way you want it to kD must be fairly large, which requires that kP and kI be pretty much perfect.
You could also adjust your gains based on where the arm is.
The way to tune this is to set up three or four different PID loops, each of which are tuned to make the arm respond nicely when going to a specific place. Then, you can take your kP/kI values that work for each of the locations and find a nice curve that fits them and use that curve to modify the gains based on where your arm is.
As for preventing integral wind-up, I just turn off the I term until we are withing 10 percent of the target.
You could also adjust your gains based on where the arm is.
The way to tune this is to set up three or four different PID loops, each of which are tuned to make the arm respond nicely when going to a specific place. Then, you can take your kP/kI values that work for each of the locations and find a nice curve that fits them and use that curve to modify the gains based on where your arm is.
apalrd posted the same idea earlier in the thread.
-Gain Scheduling. You would have a no-gravity and peak-gravity gainset (kP,kI,kD) and blend them with the angle.
It's really tough to get a D term to compensate for the inertia of an arm. In order for the D to really affect the system the way you want it to kD must be fairly large, which requires that kP and kI be pretty much perfect.
I know. I have never gotten a good cal set with a high enough D gain to be meaningful by hand, it always has stability issues all over the place.
I did, however, autotune two arms. I was surprised at the time, but the D gains were around 5x the P gain. It worked marvously, and happily jittered very slightly to hold position perfectly (even as game pieces were added) and moved to position and stabilized very quickly.
Some links on the methods I used:
http://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method
https://controls.engin.umich.edu/wiki/index.php/PIDTuningClassical#Ziegler-Nichols_Method
I made a spreadsheet which calculated all of the gains, using all of the tables from both the Wikipedia and Umich site, tried all of them, and liked the resulting gains from the Umich tables more.
Note: Time is whatever time unit the control loop uses. If the control loop is time-compensated, use that unit for time. If the control loop is not time-compensated, then use the number of iterations for time, AND the iteration time must be constant and stable.
Edit Note: Even with autotuning, I still had to gain schedule 33's 2012 FRC arm, as the linkage changed the motion ratio quite a bit near the end of stroke, and I needed really fine control in all places. I ended up autotuning at the far end and in the middle, then linearly interpolating them (past the middle, it would just hold the middle gain set).
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.