Lift PID?

I was wondering how different teams used PID to make lifts more stable? Would error be a target angle for the lift or something else? How would PID be implemented to prevent sudden stops and make everything a lot smoother going up, down, and staying in the same place?

1 Like

I am not sure exactly what your asking, but the best way for lift consistency in autonomous is using a potentiometer.

1 Like

Outside of auton though, there are several uses for pid in driver. You can have your target at pretty much whatever you would like, an angle, a velocity that you want to keep consistent. Plus you can use slew rate to control the acceleration of a lift as well. You can also make your target the current position of the lift in order to hold a lift in place. There are many more but those are a couple uses.


What you can do (what I attempted to do) is have macros that set your lift to a certain angle using the pid

1 Like

To be completely honest, I don’t think PID or any code-based solution is required now that V5 is a thing. Just make sure your lift has very low friction (using bearings in all the right places, screw joints where you can, etc.) and then use rubber bands. Depending on the type of lift you make, you’re going to have different force requirements as a function of lift angle. For example, a standard 2 bar lift will need something near a sinusoidal shape for force vs angle, but for a scissor lift or DR4B you would be able to get away with linear or even constant force curves. Anyway, there’s a great program someone made on the forum to get force curves based on what geometry you use for the rubber banding. Just search up rubber banding the lift. We used this on our DR4B this year, and with okapi API’s built in brake modes, PID or any other control loop was completely unnecessary.


PID is almost always useful, or has a use. It doesn’t matter how strong your motors are. The accuracy, speed, and consistency of a PID and other programming solutions like it cannot be obtained through mechanical solutions or driver practice.


It really boils down to a question of what you are trying to achieve. If you want to make your lift stable, then the problem you need to solve is that the motors are under different loads depending on direction of motion. The best way to solve this problem is with rubber bands. Any amount of motor power used to compensate for improper rubber banding is wasteful.

On the other hand, if the problem you are trying to solve is to get extremely precise control of your lift, then you are correct, you need some sort of control loop to fix that. PID is not the only option for a control loop, but it is a reasonably good option. However, this is only necessary for if you want precise control of your lift. This is a different issue than stability. A PID loop may help with stability, but the fundamental forces causing instability are not resolved by using PID.


Be careful with your wording. I understand what you mean, but it comes off as “coding is useless” What you should say is that custom coding isn’t entirely necessary. For a lift, you can just use the integrated PID functions for the lift such as .rotateTo() or .moveRelative() (depending on whether you use pros or VexCode.

Coding should always supplement your hardware. There are always ways to optimize hardware through code, and you should work to make the driver experience as easy as possible. As for the main topic of the thread.

PID stabilizes the lift by constantly applying motor power to maintain a position. Think about what happens to the lift when the robot is physically turned off, the robot naturally falls down because the friction in the motors is not significant enough to hold the lift. You add rubber bands and then the lift naturally maintains its position, but how about when there is a load? Rubber bands are only there to cancel the force of gravity of the lift, so you need motor power to maintain the load at a certain position (granted you have enough torque to do so).

Error depends on what you need the lift to do, and the sensor you’re using. For most (vex) purposes, PID is used to keep the lift balanced at a proper angle. But PID can be used to move the lift at a constant speed, or pretty much anything that you can think of that is measureable through a sensor and responsive through a motor. I hope that clarifies it. PID really isn’t as complex as people make it seem to be, you should read up on this.


Knowing Gael Scouts, that is pretty much common sense for them (and for most teams as well) no offense, but OP talks about lift PID, not what device to use. Also, if you do not know what the OP is asking, it would be best suggested to ask or private message asking for more clarification on what the OP means. PID is a control algorithm used to increase redundancy with items within auton (and sometimes driver control for macros). Basically, PID is not necessary, but is pretty much a requirement once at worlds level due to the massive increase in competitiveness.

So, after building many many lifts, I am fully aware of the difficulty of lifts and programming PID for them. Lifts are meant to lift things up and down, which means that weight will change throughout the competition, which also means that PID’s tuning becomes on and off. So, there are generally solutions for this programming-wise, but what my lazy self does is I get the kP, kI, and kD values of the lift with all the weight that will be added on it, and I get the kP, kI, and kD values of the lift with all the weight removed. Then I would average the two kP values, average the kI values, and average the kD values. So it’ll be a bit off for both weights, but it’s not as bad.
Note: I forgot about doing this for the Tower Takeover Robot as a part of 3674R which means the arms ended up being wonky at times.
Note2: This solution is a solution I’d recommend if you’re on a rush, but if you have a lot of time on your sleeves I would recommend a more reliable method

It is not required early season, but as things become more and more competitive it’s more definitely a requirement to be remotely competitive with other teams.

In my opinion, I think the more low friction the more importance to have PID. If you have little to no friction, with merely a P control loop it’ll be really imprecise and may overshoot.

About what you said, even though you said “completely unnecessary”, you still utilized a built-in PID control loop for the brake. But anyways, I’m not really saying built in PID is bad, but the built-in PID is very restricted and not really elastic for more complex users (I will garuntee you pilons uses custom-made PID in almost everything).

I need to be honest here, none of the posts above answered the question within the OP.

OP is asking if there’s any modifications teams make to a default PID control loop to increase its convenience for lifts. First of all, it is very very necessary to have windup prevention on the integral. You should clamp integral to prevent it from having a value so high that the lift overshoots and the motor continues spinning when the lift is at its max, breaking the gears. Your integral should also have a pass-through set zero. I.e. if integral passes the desired position, immediately set integral to zero (I find this better than a mere deadzone as it always ensures to detect that integral does not pass the desired position at a blazing speed.

//Note, this is pseudocode
double kI = 0.3;
double integral = 0;

bool errorPositive = false

if (positivechanged){
integral = 0;

if (error > 0) errorPositive = true;
else errorPositive = false;

integral = error+=kI;

  1. Clamp integral
  2. Integral set-zero switch

Now, there’s another issue that I did not talk about with a valid solution, momentum.
Lifts carry momentum, and just telling a motor from 0 to 12 in voltage will damage the motor as well as the lift’s integrity over time. One thing to consider is motion profiling:

It is where you apply a graphical formula into your PID control loop to emulate smoother transitions between speeds. I have not been exposed much to motion profiling, but I am assuming it is not as hard as you would believe it to be (according to my peers).
But, one issue still lies, lifts are built to carry varying amounts of weight, so how do I reliably make my lift carry these different types of weights?
In my opinion, if you are wanting an algorithm that adapts to different weights, I would personally like to tell you that you may be doing a bit of overkill for these simple and imprecise electronics. In my opinion, you should just have a sensor that detects when a specific object/game element enters the intake on a lift, and re-assign different kP, kI, and kD values based upon these different numbers of elements.

So, as an addition:

  1. Apply motion profiling to improve integrity of the motor and the lift
  2. Apply different kP, kI, and kD constants based upon how many elements are on the lift.

I think I did not make my original post clear enough to convey what I was trying to say. I do of course understand that there is a time and a place for using control loops or motion profiling to carry out positioning. I am not trying to say that there is not plenty of benefit in developing custom control loops rather than using the built in functions in the PROS API or the Okapi API. I am definitely not saying that code that properly complements hardware function is useless, because it is very helpful.

I would, however, like to emphasize one point because I see a lot of teams go wrong here: coding is not a substitute for not taking into account the physical constraints of a system. When approaching any problem, the cause of the problem must be properly identified. The problem of instability in a lift has multiple components. On the largest level, instability in lift systems is caused by varying forces on two sides or different portions of the lift. This is most often poor friction management on one side or non-symmetrical construction. Once a lift is properly mechanically balanced, theoretically there should be no differences in position on the sides when controlled by individual motors. But now you will find that the lift will have some degree of instability in the motion of it, caused by changing torque needs at various positions along the track of the lift. This is where rubber banding comes in as I mentioned earlier. Rubber banding should be optimized for the specific type of lift built and the specific constraints of one lift to provide the right upwards force to counteract the weight of the lift itself. At this point, as other people have mentioned, the lift should work considerably better after all this mechanical tuning than a freshly built lift. Using some built in hold control or built in motion profiles, this alone can be more than good enough for driver control and, depending on the allowable tolerances for your manipulator, possible even for autonomous routines.

Only at this point should you start looking at more intensive custom control loops for your lift mechanisms. Only once the theoretical physical constraints of your situation have been solved should you look to optimize it through code. Depending on the degree of precision that you require for autonomous motion of your lift and the degree of change in required power going from holding no game elements to a couple to max capacity, you can start thinking about the proper types of control loops to add and if you need more functionality than the standard built in ones can offer. Sometimes you may, sometimes you may not.

Essentially, custom control loops and motion profiling are pretty beneficial, and in certain cases, required to get precision out of your lift. However, these are not substitutes for improperly built mechanisms. They compensate for momentarily unbalanced forces and random type errors in your system. If your lift is not balanced in theory, fancy coding is not the correct route to take. Only once your lift is balanced in physical theory should you improve and fine tune it with code.


What? PID is a feedback-based algorithm used to achieve or maintain a certain state in a system (At least this is the most general definition I could think of)


In writing, redndancy is:

So, in robotics, by making an algorithm that applies redundancy, it more or less implies that when the code is ran the arm or lift is able to go to the same desired position regardless if it’s the 2nd, 5th, or 10th time. More or less implying a near-perfect form of consistency.
So we basically said the same thing, except in different words.

1 Like
  • Make an array for each constant
  • Store different experimental values for different loads
  • Use a sensor to detect how much load you have
  • Based on the sensor feedback, swap constant values through the array
1 Like

I think those in this thread might find our videos on feedback loops useful. We use drive PID on an X-drive as the example, but the same principles apply (just with only 1 axis/degree of freedom instead of 3).