# Matching PID Loops for both sides

We have essentially two separate climbers, one on either side of our robot. They are not mechanically linked in any way. Our climber consists of two single stage ThriftyBot elevators, each with their own encoder, to reach up for the rung and a pair of rotating arms, each with their own encoder, with a hook to latch onto the bar. If we get far enough, we will use a combination of rotating the arms and extending the elevators to get to the next rung.
Here’s the question: we want to keep the robot level (left to right) while lifting the robot. This requires the two elevators to move at the same speed, especially under load, and end up at the same place. Are we better off using two independent PID loops or just have one PID on one side and make the other side’s Neo a follower?

1 Like

Two independent PID loops is better. This way they will both reach the correct height, regardless of differences in friction. If you only have one, the lower friction side will go up faster and will result in slightly different heights. The closer the two lifters are mechanically, and the more margin of error in the climb system, the better the single loop version will be, but the two loop one will definitely be better.

1 Like

Do you expect that there might be some unexpected load which might apply more to one side than the other? If so, you’ll want independent control of both sides. This also leads to:

If there’s extra load on one side (say, a little more friction, or rubbing on your neighbor robot), your speed will be a little off. Closed loop control won’t make that perfect. The error in the speed will accumulate over time, leading to a position error.

At a minimum, I would control to a desired position which ramps smoothly between the extended and retracted heights.

Said another way: You generally care less about the velocity of one side at any given time than you do its position.

A general rule of thumb in control theory - if at all possible, measure what you want to control. If this is what you technically care about, you actually don’t really care about the arm position directly. You might want to measure how far the robot is tilted, and use that to offset the arm position to keep the whole thing level. This could help correct if the bar isn’t even, or one claw grabs slightly askew, or if the climber isn’t mounted perfectly.

If the probability of these is low, you could assume the clamping position and infer robot levelness from arm position.

All that being said… this is very much a case of “fixing hardware with software”. Software will never be able to keep things perfectly in sync, or re-distribute shock loads when an alliance member bumps you. I definitely won’t say your configuration is flawed and won’t work, but also be careful not to expect too much out of the system.

2 Likes

I would look into using motion profiles for this, rather than a speed PID. That way, each would be at least aiming at the same spot at any given time.

Mostly sniped by @gerthworm.

Added: The good news is that there is some natural corrective feedback in the system. If one arm gets ahead of the other, it will carry more load, which will slow it down relative to the other.

2 Likes

I don’t think anyone here was proposing using PID

to control the speed of the climbers, instead controlling the position. Using two loops for this is certainly one way to go.

The challenge is mostly that you have to do more work to not only control the end position, but to also ensure that the intermediate positions of the climber are in relative sync with one another. A number of different ways to do this, that people smarter than me will elaborate on, but it’s not really about targeting a specific speed of movement directly (though capping velocity could be potentially useful)

1 Like

While it’s not 100% clear, I think OP at least contemplated this solution. Agreed though, it would likely not result in the intended behavior.

One approach would be to use a single motion profile for both sides, but separate PID controllers. The motion profile would move the setpoints at the same rate, but the PID controllers will provide the feedback control separately to handle any differences between the two sides.

7 Likes

Wow! You people are fast! Thanks for all the feedback.
To be clear, I was planning to use position as the set point in my PID loop (now it will be plural). I am expecting the by using the Smart Motion profile in the Spark Max to limit acceleration and velocity I can keep the speeds close enough that both side of the robot go up together thus keeping it reasonably level.

We had a similar problem with our 2019 climber. It had 2 independent legs that lifted the robot to climb the hab. One side of the robot was heavier, so it would lift slower than the other side. We solved this by using a Motion Magic motion profile on the heavy side and a PID on the light side that had a setpoint of the heavy side’s current position. You can see it in action here (we are the center blue bot). This is a less elegant way of doing what Peter_Johnson suggested above, but it worked.

1 Like

If you’re using Talons, it may be interesting to try out CTRE’s Aux PID feature, where a secondary PID loop is run on the difference between the positions of the mechanisms in order to try to drive them to the same position as motion occurs.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.