Vertical Load PID Tuning for a LIFT

[Chris Elston 78]

So as many of you know, I mentor a FIRST Robotics team. Without going too much into details of the robot, (team secret for now) I was wondering if I could pick your brains...this might be a simple reply for some (like Peter comes to mind) but at any rate, I would like your input. So we have a lift on our team's robot this year. Picture if you will a fork-truck type lift. The lift is connected via a chain to a gearbox, which is turned by an electrical 12 volt motor. The gear box is 12:1 ratio. The motor has plenty of power to lift the lift up and down. The load is about 5 lbs plus the weight of the lift which is 10 lbs. So about 15 lbs total on a 12:1 ratio gear box. When we energize the motor full speed (+12 volts applied) to raise the load, the speed of the lift is about 30 inches per second going UPWARD. There is no strain on the motor and the motor is rated for the load. When we energize the motor full speed (-12 volts applied) to lower the load, the speed of the lift is about 60 inches per second going DOWNWARD, because it's got gravity helping it... When the motor is not energize, no voltage and the lift is raised to the top, the lift will "creep" slowly downward. So it's not a "free fall" lift with no power. But the weight of the lift is back feeding the chain, to the gear box and the motor. The 12:1 ratio isn't enough to keep the lift still when the motor has no power. This is not a big deal to us in our design and not a safety concern. So it doesn't take much motor power to make the lift come down.... 5-7 volts? We have a 1000 PPR encoder on the output shaft of the gear box (12:1) and a speed controller controlling a 12 VOLT motor. We are using a National Instruments cRIO controller running a Lab view app with a PID. Now that you have all that mechanical details. I've done a few PID tunes, most have been horizontal loads. I assume and we are expecting to have a different tune for the UP direction of the lift, verses the DOWN direction of the lift. While helping the programming team last night, we were able to tune the UP DIRECTION of the PID with no problems. It actually looks pretty sweet. But we struggled with the downward direction. P = 0.8 I = .03 D = .002 (values I remember) Up direction looks nice… The lift is position based. We send a command of 30 inches while the lift is at 0 inches, and the lift moves up to position and hold 30 inches. When we are up at 30 inches and command a downward direction of 0 inches, the lift drops violently, no matter what kind of a tune we place in the PID. Either P only, PD or PI tune... Again, we expect the up direction will have a different tune that the down direction because of the free fall load. How can we slow down the lowering? So it does not reach 60 inches per second free fall with motor assist? One thing on the speed controller command output works like this: -1 = -12 volts to the motor 0 = 0 volts to the motor 1 = +12 volts to the motor The motor has no brake. We did not try and "limit" the downward output of the speed controller, we may try this tonight. Will this HELP in keep the lift from dropping like a dead weight to limit our output of the speed controller to say something like -0.4 (5 volts)? Or do you have any other suggestions we can use for a dead weight PID tune for our downward direction?

[OkiePC 14]

Is there any way you can counterbalance the load? If you could offset the weight of the empty lift, I would expect that it would help a great deal. Does your system generate a target position profile that varies over time and have the PID try to follow that motion profile? Or do you just instantly change the setpoint of the PID loop directly to the desired target position? I would expect that if you plot a motion profile over time and have the PID loop try to follow it, you'd need different gains, but you should then be able to use the motion profile generator to regulate velocity...this is where Peter would surely have some good input. How fast is the update time of the PID loop? How fast is the scan time of the controller reading the inputs and updating the output? I would try to apply separate limits in both directions for the commanded velocity, and make them variables that can be adjusted if possible to see what kind of performance that yields. Now if you are just changing the setpoint from 0 to 30 instantly, and back again, and then you limit the signal going to the drive, your PID integral may "wind-up" and cause an ugly overshoot, so limiting the outputs may be a bad idea unless you ramp the setpoint so the PID can follow it. Edited 16 Feb 2011 by OkiePC

[Leitmotif 0]

One little key thing here What kind of motor are you using series shunt or permanent magnet. Look at torque vs RPM curve for series motor. With little torque speed is high - exactly what you are seeing when going down ie overhauling load. You willl have to cut line voltage quite severly to control speed in down direction. If you have varying load I think you are going to have difficulty controlling a series motor in both directions. IF you can have separate field control a shunt may be better choice. IF not I think I would look at perm magnet. Dan Bentler

[Chris Elston 78]

No counter balance is tough, and we don't have the weight. We have to weigh in at 120 lbs. And the robot is 115 lbs now. There is no ramp function from set -point to set - point...that's a good thought..... The update rate is 100 HZ for the loop. We got this to work by having the same PID tune, but different motor limits. So the output limit on the up direction is +1 on the speed controller and -0.3 on the speed controller going down. This ended up working really well. We are quite pleased with the results. Thanks for all your suggestions. I'll post a video of the robot when we release it to the public very soon.

[paulengr 44]

This requires a trajectory control system to do it safely/sanely. Don't just try to stab a set point into the position control loop because the position control loop does not attempt to control acceleration or velocity. Instead, you have to feed it a series of positions from a trajectory calculation. The usual method is to use a trapezoid (accelerate linearly to a maximum velocity, run at max velocity, then decelerate uniformly to stop position). If you are really fancy, you can "S-curve" it at the ends because the acceleration goes through an asymptote at the corners of the trapezoid which causes the motion to jerk. Then you simply feed these set points to your position control loop. It is also possible to use multiple control loops in a cascaded arrangement to simultaneously control the acceleration and velocity without a trajectory calculator but trajectory calculation is the easiest way to solve this. Note also that pure PID control in motion controls is usually a bad idea. Taking the trajectory information and calculating velocity commands as a feedforward control will result in much faster and smoother response. Simply use constant1*(new position-old position)+constant2. Adjusting this simple formula and adding the result to the PID output provides a true feed forward/backward loop. The feedforward loop rpovides quick response. Then the PID loop requirements are drastically reduced because it is simply providing fine tuning to account for errors in the feedforward loop. This is what motion controllers actually do. Since you might not have the budget to afford a Galil unit or something like that, you can still do a decent job or writing your own if time isn't a big constraint. Edited 20 Feb 2011 by paulengr

[Peter Nachtwey 15]

I just saw this thread and it is early Sunday morning. Chris has gotten some good advice. A more sophisticated motion controller would make this easy but I think Chris must make do with what he has. If this doesn't need to be a work of art I would simply move the set point up and down at whatever speed you wish to move at. Implementing s-curves or trapezoidal ramps would be an improvement but it doesn't sound like extreme accuracy is required. The simple moving of the set point is crude but it will work. Chris, can controller you are using do math? Can it solve do something like this? f=t/T s(f)=30*(3-2*f)*f^2 T is the total desired time to move. t is the time since the start of the move as t goes from 0 to T f will go from 0 to 1 and s(f) will go from 0 to 30. The velocity will start and stop at 0. When going down decrement t from T down to 0. The time to move up will need to be longer than the time to move down. T will need to be different in both locations. Now you will have a move gental curve without too much math and more importantly it dodges the ramp up, constant velocity and ramp down parts of the code. One polynomial does it all.

[Chris Elston 78]

I wanted to follow up with this thread. Back when this was posted, because of my "teams" trade secret rules, I wasn't able to explain what we where doing much. Now I can. And again, those that don't know me, I mentor a high school robotics team, Team THRUST 1501. http://huntingtonrobotics.org/. So I teach / mentor kids in high school about electrical, software, and control systems. Even pneumatics. So here is a video of the robot we made this year that pertains to the above questions. Thanks everyone for your help. It turned out great. Here are the kids explaining what they learned this year: Here was the 2011 GAME, we played this year: http://www.youtube.com/watch?v=nYBUKZ6r5Hc&feature=player_embedded Pictures of the robot being built: http://www.flickr.co...57626193445801/ Mini-bot Proto-types: (we didn't have much success with this....) http://www.flickr.co...57626363065382/ Competition Pictures at Purdue: http://www.flickr.com/photos/teamthrust1501/sets/72157626260996318/

[Peter Nachtwey 15]

I forwarded links to your videos and pictures to others here that are involved in FIRST. I saw a robot with a purple Delta sign on it. We/Delta contributed about $600-$700 to the local team here.

[Chris Elston 78]

That's great Peter. Now next, you'll need to help mentor them. That's when it really starts to get fun. Glad you support a FIRST team!

[Peter Nachtwey 15]

Our local team competitions. This was provided to me by my business partner. Here are some videos featuring team 2471—the Camas/Washougal team that won in Seattle. There is one Hockinson student on the team, as well. http://www.youtube.com/watch?v=-hTyFODcNSQ (we are the far robot in the beginning). http://www.youtube.com/watch?v=UBu37Usc9fY (one of our matches in Portland) http://www.youtube.com/user/fgvusgrfuy?feature=mhum#p/a/u/0/zG4yyxBCsxQ (our final match in Seattle)

[Chris Elston 78]

That's excellent. Our team is still trying to win a regional. We've gotten SILVER three times now. Hope to get a GOLD medal one of these days. Glad Delta is helping out the youth and shaping them into Scientist or Engineers.

[lostcontrol 23]

Peter, All those links took me to a Web based windoze exchange interface.... :shrug:

[Chris Elston 78]

I saw that too, I am the ADMIN, I could have fixed it...duh... Here you go: