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!

[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.

[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.

[AustinSchuh]

Originally Posted by thatprogrammer

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? *

Yea, yea, yea, that's what I get for going fast late at night. I updated my post. Thanks for catching that!

Originally Posted by thatprogrammer

2. Is the goal of the voltage scalar to be as close as possible to 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.

Linearizing systems ends up being in control systems classes, which you won't see for a while. It takes a while to wrap your mind around control systems properly.

By voltage scalar, do you mean F_gravity * r, which is then scaled by the gear ratio, the torque constant of the motor, and the resistance of the motor (motor constants not included here)? If so, yes. Your goal is for the term which you add to your motor command to cancel out as much of the problems created by gravity as possible. This leaves you with a small disturbance, and effectively a linear system. A linear system in this case means that applying a voltage at any angle should result in the same amount of angular acceleration. (To make your head hurt more, look at my previous post about efficiency and try to think about how you'd deal with that here )

[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 wesleyac

(Although there are still some considerations to be taken with the difference between going up and down).

Am I correct in my assumption that, given that the equation of the arm's torque (thanks to Austin Schuh for providing this equation!) is: torque = J * d^2 (theta) /dt^2 + F_gravity * r * cos(theta), that

F_gravity * r * cos(theta)

can be subtracted when going down to account for that fact that your motors are not fighting the force of gravity being applied on the arm? In other words, when going up, you need to add

F_gravity * r * cos(theta)

to account for gravity pushing down on your arm, but you can rely on this force to assist in pushing your arm down when your motors are working to lower the arm?

[Jared Russell]

Originally Posted by thatprogrammer

Am I correct in my assumption that, given that the equation of the arm's torque (thanks to Austin Schuh for providing this equation!) is: torque = J * d^2 (theta) /dt^2 + F_gravity * r * cos(theta), that can be subtracted when going down to account for that fact that your motors are not fighting the force of gravity being applied on the arm? In other words, when going up, you need to add to account for gravity pushing down on your arm, but you can rely on this force to assist in pushing your arm down when your motors are working to lower the arm?

Yep, that's usually how gravity works

[NotInControl]

A lot of good information here in this thread, and compensating for gravity to hold a static position by having a proportional gain relative to the angle will work, but I did want to mention a caveat to be aware of when developing your control system using that assumption, and also provide a bit more background on gravity compensation.

Background:
Gravity compensation is very popular in industrial manipulator control development (like a 6DOF arm), because the load of the arm and its motion is something which needs to be accounted for in the control. However, the development of these control systems account for 3 things which allow it to be more accurately controlled:

1. Uses Motion profiles so it can control the acceleration, jerk, and velocity of each joint through out the motion
2. Calculates the inverse dynamics (Toque required per time considering the dynamics of the motion)
3. Does not need to account for induced dynamics due to a moving base

Here is why I bring this point up.

Using the proportional method above is a good linear approximation if your drive train is stationary, and your manipulator is not subjected to other outside dynamic forces (defense by another robot, on uneven terrain, etc, induced acceleration while the driving). As you can imagine, if you are trying to hold position while driving, or while being hit, or going over an uneven terrain, there will be additional dynamic acceleration acting on the manipulator other than gravity, and the position of your manipulator will move off its set point during those acceleration, because those forces will not be counteracted in the gravity compensation.

Now your gravity compensated control loop, will act to counteract those forces, and if tuned well enough, , with enough finite control, it will be able to regain its position, once those forces stop acting on the manipulator, or become constant. However the point I am trying to make is to understand the limitations of the approach to know when it will work, when it may not, and to have more educated conversations based on the requirements of your strategy.

If you desire to only maintain position with the drive train is in a stationary position. The above approach is good.*
If you desire to maintain position accurately while in motion, or in the presents of other dynamics forces which you may or may not be aware of**, you may need to consider the above approach will not hold position during the motion, and either more detailed assessment of the scenario dynamics is needed (i.e understanding the dynamics of motion for all cases, or considering adding a mechanical brake to keep position, in which case the control system is not responsible for holding the load, and can be off).

*Also, you also want to be mindful of the current draw required to hold position, and the length of time you need to do so. This requires attention to gearbox design to ensure that the efficiency of the gearbox is as high as possible in the operating window where the load is being held. While you are holding position, you will be using power, and if you require to hold that position for long durations of time, or have an inefficient gearbox a power assessment would need to be done to ensure you are not depleting your battery unnecessarily. Obviously, adding another mechanical break adds complexity to the system, and that is why control development is a marriage between mechanical, electrical, and software. Each discipline needs to be involved, and understand the limitations and compromises so the end system can behave as expected.

** Many times in control development the final system doesn't behave as expected because there were forces acting on the actual system not understood or captured in the development model, and then the system needs to be redesigned, or modified live on the hardware in the presents of the unmodeled dynamics.

Just wanted to throw these points out there so that this discussion can be more complete for future use, and highlight some of the pros and cons of different approaches to maintaining position control

Good luck and have fun. Off season is the best time to build your control toolbox

[thatprogrammer]

Originally Posted by NotInControl

1. Uses Motion profiles so it can control the acceleration, jerk, and velocity of each joint through out the motion
2. Calculates the inverse dynamics (Toque required per time considering the dynamics of the motion)
3. Does not need to account for induced dynamics due to a moving base



Now your gravity compensated control loop, will act to counteract those forces, and if tuned well enough, , with enough finite control, it will be able to regain its position, once those forces stop acting on the manipulator, or become constant. However the point I am trying to make is to understand the limitations of the approach to know when it will work, when it may not, and to have more educated conversations based on the requirements of your strategy.

*Also, you also want to be mindful of the current draw required to hold position, and the length of time you need to do so. This requires attention to gearbox design to ensure that the efficiency of the gearbox is as high as possible in the operating window where the load is being held. While you are holding position, you will be using power, and if you require to hold that position for long durations of time, or have an inefficient gearbox a power assessment would need to be done to ensure you are not depleting your battery unnecessarily. Obviously, adding another mechanical break adds complexity to the system, and that is why control development is a marriage between mechanical, electrical, and software. Each discipline needs to be involved, and understand the limitations and compromises so the end system can behave as expected.

** Many times in control development the final system doesn't behave as expected because there were forces acting on the actual system not understood or captured in the development model, and then the system needs to be redesigned, or modified live on the hardware in the presents of the unmodeled dynamics.

This post raises some interesting points on controlling robots under
game conditions rather. I had a few questions based on your points.
1. Is there an advantage to using a motion profile with a constantly changing set-point? Obviously, the advantage of a motion profile is that you can travel over a pre-calculated path in a fairly efficient manner. How does this translate if you are dynamically adjusting your set point, resulting in the roboRIO being required to generate a new set point dynamically?

2. Points 2 and 3 (assuming you DID need to calculate induced dynamics)

2. Calculates the inverse dynamics (Toque required per time considering the dynamics of the motion)
3. Does not need to account for induced dynamics due to a moving base

Require model based controls, do they not?

Thanks for all the help in this thread! It's been really fascinating to get an understanding of how a PIDF loop can be used to linearize the PID portion of a controls loop.