Tuning PID Constants Over a Range

[wireties]

Don't forget that you are tuning an electro-mechanical system.

For example if it is too hard to (begin) a turn then tuning the servo, by any means, is very difficult. This past year things like proper inflation of the pneumatic tires made all the difference (we were running Austin's state-space code).

An arm-like mechanism that takes much more power to move up than down is also very difficult to tune - so balance the motion against gravity with a gas shock or surgical tubing.

Set yourself up for success with good mechanical design, software can only do so much!

[Bo8_87]

Originally Posted by wesleyac

Again, having plots of angle over time as well as target angle over time on the same axes helps hugely here. If you don't have some system to graph variables over time, make one! it will save time in the long run. Test every change with multiple values.

What software do people use to graph and plot data? I found some, such as mathplotlib, but I am wondering what other teams use.

[MichaelBick]

Originally Posted by Jared Russell

I agree that a motion profile + feedforward to overcome static friction can solve this problem adequately for FRC purposes. However, the Talon SRX makes precise 1KHz velocity control stupidly easy to achieve; hiding the stiction nonlinearity behind a Talon and using plain old position PID is just as workable a solution these days. (But is still improved by using a motion profile of course)

We found success using a velocity PID loop on the roboRio, and in retrospect we should have run the velocity PID loop on the talon. The main issue we were trying to solve was left/right sides moving at different speeds when given the same input, which a motion profile would not solve alone.

[AustinSchuh]

Originally Posted by Bo8_87

What software do people use to graph and plot data? I found some, such as mathplotlib, but I am wondering what other teams use.

We use matplotlib and some python scripts to parse and plot our data. We've also used gnuplot.

The trickier part is how to log data real-time. Most/all IO is not real-time. You can get away with writing data to a file from your control loop thread for quick tests, but that's risky for longer tests. (Sometimes when I'm really lazy, I'll stick the file IO operations in the main code, time them and abort if they take too long. This lets me least know if I'm getting bad data.) We queue up the data we want to write into a queue, and write it to disk in a separate thread. This unfortunately adds significant complexity.

[Jared Russell]

Originally Posted by Oblarg

If all you're doing is tuning a turn-to-angle loop, though, do you really need to take the extra step to figure out the proper scaling factor for turning rate? You could just "absorb" that constant (whatever it is) into the value of p.

Absolutely, P can compensate for that. But we also were using the same equation for path following so we wanted it to be in the ballpark.

[wesleyac]

Originally Posted by Bo8_87

What software do people use to graph and plot data? I found some, such as mathplotlib, but I am wondering what other teams use.

We logged everything to csv and used gnuplot to view it.

[wesleyac]

Originally Posted by wireties

An arm-like mechanism that takes much more power to move up than down is also very difficult to tune - so balance the motion against gravity with a gas shock or surgical tubing.

Just want to point out that this is probably easier than you think to control - you can do feed forward by applying voltage proportional to the cosine of the angle of the arm to cancel out gravity, at which point it becomes a (approximately) linear system, that is fairly easy to control (Although there are still some considerations to be taken with the difference between going up and down). A FF + PID arm is much easier to control than one with surgical tubing or a gas shock, imo.

The point that programming can only do so much is definitely valid, I just wanted to point out that arms aren't too difficult, as that's what we spent our season doing

[AustinSchuh]

Originally Posted by wesleyac

Just want to point out that this is probably easier than you think to control - you can do feed forward by applying voltage proportional to the cosine of the angle of the arm to cancel out gravity, at which point it becomes a (approximately) linear system, that is fairly easy to control (Although there are still some considerations to be taken with the difference between going up and down). A FF + PID arm is much easier to control than one with surgical tubing or a gas shock, imo.

The point that programming can only do so much is definitely valid, I just wanted to point out that arms aren't too difficult, as that's what we spent our season doing

There's another compounding factor that isn't apparent here. The efficiency of a gearbox removes power regardless of if you are accelerating the arm or decelerating it. So, if you apply a torque at the motor to accelerate the arm, you will see a reduction in torque. If you apply torque at the motor to decelerate the arm, you will see an amplification of the motor torque. (Look at what conservation of energy says to verify) This year, for our shoulder joint, we had to gain schedule based on whether or not we were accelerating or decelerating to compensate for this. It took a couple weeks of hard work to figure that out.

In the end, yes, you can compensate for a lot of nonlinear junk in software, but the more you do in hardware, the better you are off. 971 robots move like they do both because the software lets them do that, but also because we go to great depths to do things like reduce backlash, reduce friction, increase stiffness, etc, to make it easier to write the software.

/end tangent...

[Basel A]

Originally Posted by wesleyac

Just want to point out that this is probably easier than you think to control - you can do feed forward by applying voltage proportional to the cosine of the angle of the arm to cancel out gravity, at which point it becomes a (approximately) linear system, that is fairly easy to control (Although there are still some considerations to be taken with the difference between going up and down). A FF + PID arm is much easier to control than one with surgical tubing or a gas shock, imo.

The point that programming can only do so much is definitely valid, I just wanted to point out that arms aren't too difficult, as that's what we spent our season doing

Unfortunately, unlike motion profiling or simple PID, there isn't a nice way to do this on a Talon (right?).

[Jared Russell]

Talon SRX closed loop control implements PIDF. The "F" stands for feedforward - and this works in all of the available closed-loop control modes (current, velocity, position, profile).

However, the feedforward gain is constant until you change it, so compensating for an arm by using a cosine function would require some form of gain scheduling. The Talon SRX Software Reference Manual talks at length about a couple of ways you could do this.

I also believe that you can hack the motion profile control mode to do what you want. This control mode is fundamentally position control plus a feedforward velocity (voltage) command for each trajectory point. There is no requirement that the integral of the feedforward velocities be equal to the subsequent position command. So you could calculate a profile to move your arm from any angle to any other angle, and account for gravity, spring assistance, or up/down asymmetry by manipulating the feedforward part of each trajectory point to provide a voltage disturbance in the desired direction.

[thatprogrammer]

Originally Posted by wesleyac

Just want to point out that this is probably easier than you think to control - you can do feed forward by applying voltage proportional to the cosine of the angle of the arm to cancel out gravity, at which point it becomes a (approximately) linear system, that is fairly easy to control (Although there are still some considerations to be taken with the difference between going up and down). A FF + PID arm is much easier to control than one with surgical tubing or a gas shock, imo.

The point that programming can only do so much is definitely valid, I just wanted to point out that arms aren't too difficult, as that's what we spent our season doing

A few questions (just started taking physics this year, apologizes if any of these questions have obvious answers that I haven't learned yet).

1. How did you determine the multiplier required to allow the arm to cancel out gravity?
2. How does multiplying by the cosine of the angle of the arm result in a linear system? Isn't cosine non-linear by definition?
3. Why do you not simple scale your voltage multiplier in proportion to the angle of the arm?

Thanks for all your help!

[AustinSchuh]

Originally Posted by thatprogrammer

A few questions (just started taking physics this year, apologizes if any of these questions have obvious answers that I haven't learned yet).

1. How did you determine the multiplier required to allow the arm to cancel out gravity?
2. How does multiplying by the cosine of the angle of the arm result in a linear system? Isn't cosine non-linear by definition?
3. Why do you not simple scale your voltage multiplier in proportion to the angle of the arm?

Thanks for all your help!

If you work out the physics, you'll get the following:

torque = J * angular_acceleration + r cross F_gravity

F_gravity cross r -> F_gravity * r * cos(theta)

So, you get

torque = J * d^2 (theta) /dt^2 + F_gravity * r * cos(theta)


When linearizing, you want to convert your system to be linear. The only nonlinear term above (assuming that torque is your input, which is a reasonable assumption for now) is the F_gravity * r * cos(theta). So, if we define

torque = torque_linear + F_gravity * r * cos(theta)

And then do a variable substitution, we get a linear system back. i.e.

torque_linear = J * d^2 (theta) /dt^2

Yay! (I think this answers 2 and 3).

As long as you aren't too far off, your system will work just fine with the wrong gain. One way to do it would be to measure the voltage required to hold your arm horizontal, and use that as the coefficient. We've traditionally ignored this term and let the rest of the loop take up the slack.

[wesleyac]

Originally Posted by thatprogrammer

A few questions (just started taking physics this year, apologizes if any of these questions have obvious answers that I haven't learned yet).

1. How did you determine the multiplier required to allow the arm to cancel out gravity?
2. How does multiplying by the cosine of the angle of the arm result in a linear system? Isn't cosine non-linear by definition?
3. Why do you not simple scale your voltage multiplier in proportion to the angle of the arm?

Thanks for all your help!

Austin is completely correct with his math AFAIK, but there's also an intuitive way to think about it: When your arm is at 90deg (straight up), you don't want to be applying any force to counter gravity - it can balance like that. However, when it's at 0 deg (flat on the robot), you want to be applying the maximum counter gravity force. cosine is 1 at 0deg and 0 at 90deg, so this makes sense.

The reason that cosine makes sense (to me) is that you can imagine the arm as a line on a circle, going from the centre to the edge. You can get the x position of the arm (which is what will determine the amount of force due to gravity) with the cosine of the angle of the pivot. This, I think, answers your 3rd question - it's because force of gravity doesn't scale linearly with the angle, it scales with the linear position of the centre of gravity of the arm.

Cosine is nonlinear, but because of the reasons above, (and what Austin mentioned, which is basically the same thing but with actual math behind it) it's in the system already - what we're applying just counteracts that, allowing us to ignore gravity (which makes the entire thing a linear system).

For your 1st question, we just did guess and check, IIRC You can also find it from the system dynamics (Weight/MOI of arm, force of gravity, and torque applied by motor), but you'll usually need to tune it anyways. It's also not a huge deal if you get it a bit wrong - the control loop can absorb a lot of it if needed.

[adciv]

We covered this in non-linear control theory. Take a model of your system, in this case angle vs. the force required to hold the arm in place and then invert it.

Mathematically, we describe it as this (provided I remember it correctly):
You have some system for which y = f(x) where x is you control signal.
There is another system for which g(f(x)) = x.
You can treat your system as a linear system if you use g(x) as your control signal.

[thatprogrammer]

Originally Posted by AustinSchuh

If you work out the physics, you'll get the following:

torque = J * angular_acceleration + r cross F_gravity

F_gravity cross r -> F_gravity * r * cos(theta)

So, you get

torque = J * d^2/dt^2 + F_gravity * r * cos(theta)


When linearizing, you want to convert your system to be linear. The only nonlinear term above (assuming that torque is your input, which is a reasonable assumption for now) is the F_gravity * r * cos(theta). So, if we define

torque = torque_linear + F_gravity * r * cos(theta)

And then do a variable substitution, we get a linear system back. i.e.

torque_linear = J * d^2/dt^2

For your 1st question, we just did guess and check, IIRC You can also find it from the system dynamics (Weight/MOI of arm, force of gravity, and torque applied by motor), but you'll usually need to tune it anyways. It's also not a huge deal if you get it a bit wrong - the control loop can absorb a lot of it if needed.

Thanks for the advice! I spent my study period learning about how cross vectors worked and then went over a few of the concepts with my Physics teacher. I now have a good understanding of what's going on with the feedforward.
Two questions:
1. Shouldn't torque_linear = J* d^2(theta)/dt^2? *
2. Is the goal of the voltage scalar to be as close as possible to

F_gravity * r

so that it becomes the non-linear part of the equation when multiplied by cosine(theta)?

*I start calculus next semester and have learned only the very basics from the edX class I have started taking to prepare for it (only 1 week in). Apologies if I am missing something obvious.