Tuning PID Constants Over a Range

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

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

[wesleyac]

Originally Posted by thatprogrammer

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?

The RoboRIO has the power required to calculate motion profiles on-the-fly. In fact, despite not having any changing setpoints last year, we still did trapezoidal motion profiling largely on-the-fly.

Also, with regards to the advantages of motion profiling, we found that one of the main advantages was making the movement smoother - it would slow to a stop, which is much gentler on the mechanism and makes it easier to control, as the loop doesn't need to suddenly stop - instead, the profile is responsible for coming to a slow stop.

[Ether]

Originally Posted by wesleyac

The RoboRIO has the power required to calculate motion profiles on-the-fly. In fact, despite not having any changing setpoints last year, we still did trapezoidal motion profiling largely on-the-fly.

Let's say at some time t_i your setpoint changes to x_s, and your present position, velocity, and acceleration are x_i, v_i, and a_i.

What formulas are you using to compute the new motion profile given these non-zero initial conditions?

[wesleyac]

Originally Posted by Ether

Let's say at some time t_i your setpoint changes to x_s, and your present position, velocity, and acceleration are x_i, v_i, and a_i.

What formulas are you using to compute the new motion profile given these non-zero initial conditions?

As I mentioned, we didn't have changing setpoints last year, so this wasn't a problem that we ran into - we basically solved it by ignoring it

When I said calculating motion profiles, I was simply referring to generating a trapezoidal acceleration profile based on a given distance, acceleration, and velocity. We found that it was unnecessary to precalculate the profiles, as they were fairly simple to calculate.

[thatprogrammer]

Originally Posted by wesleyac

As I mentioned, we didn't have changing setpoints last year, so this wasn't a problem that we ran into - we basically solved it by ignoring it

Where in your code are you calculating the profiles on the fly? I had come up with a method of calculating them by looping for each time stamp (using the formulas to calculate needed P and V for each iteration of the time), but that wouldn't be fast enough to calculate profiles on the fly (at least, I think).

[Ether]

Originally Posted by wesleyac

When I said calculating motion profiles, I was simply referring to generating a trapezoidal acceleration profile based on a given distance, acceleration, and velocity.

I think you mean generating a trapezoidal acceleration profile based on a given distance, max acceleration, and max velocity, starting with zero velocity and acceleration.

We found that it was unnecessary to precalculate the profiles, as they were fairly simple to calculate.

Yes, but that didn't seem to be the question being asked in post50:

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

.

[Ether]

Jared Russell's online adaptation of Paul Copioli's motion profile generator


Sinusoidal acceleration motion profile equations

.

[AustinSchuh]

Dang it, I'll bite. I wasn't doing anything tonight anyways...

Originally Posted by thatprogrammer

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?

I'm a tiny bit confused on what you are asking, so let me know if I missed.

I like to build the motion profile in as a "block" in the list of blocks that a signal flows through. It then works as follows. button presses -> goal -> profile -> instantaneous goal -> PIDF -> voltage.

The driver doesn't always want to wait until a motion finishes. If he tells the intake to go down, but realizes that was a bad idea and lets go of the button to lift it back up, I don't want the motion to violate the acceleration and velocity limits as it turns back around and profiles back up. By dynamically computing the profile required to move from the current profiled position/velocity to the final position, this is not a special case anymore. Sure, the math is harder, but it is more robust.

Nobody here has talked about adjusting your profile when your actuator saturates. Being able to dynamically recompute your profile in this case helps enormously. Unfortunately, once you start trying to handle saturation, you can get in some nasty loops where you then move your profile in such a way which causes the controller to over-compensate, causing the whole mess to go unstable. In other words, warning: there be dragons here. We've tried various things over the years, and I'm not super thrilled with any of our solutions.

The math ends up being pretty straight forwards. We end up computing every cycle of the control loop the amount of time that we need to accelerate, hold max velocity, and decelerate given the current state. We then execute 1 time-step worth of that plan, and use the resulting location as the next state. There are a couple square roots, and a couple multiplies, which is cheap on current hardware.

Ether linked to some previous implementations from an awesome thread a couple years ago. That thread was a lot of fun, and I'd highly recommend reading it carefully. 971 has an implementation available in our open source release as well if you are interested.

Originally Posted by thatprogrammer

2. Points 2 and 3 (assuming you DID need to calculate induced dynamics)
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.

I read Kevin's point, which is a really good one, to be that you can model more and more, but there will always be un-modeled disturbances. That's why we have feedback controllers. Compensating for gravity may help most of the time, but won't magically fix issues.

We on 971 have not modeled gravity in our loops in a long time. We would rather design controllers which are robust enough that an un-modeled disturbance as consistent as gravity will be compensated for quickly. I actually like to use gravity as a test case to see how well my disturbance rejection is working

[fargus111111111]

It certainly appears that you have received a multitude of helpful answers to your problem. I would say that it is important that you understand why a PID performs how it does as far as why it overshoots or undershoots, and why, if you nudge it off with out slipping the wheels, it should correct itself. Understanding this will help you understand why it is very helpful to do as many others have mentioned, that is to use a motion profile in your code. The PID with out profiling is detecting a large error at the start that error is drawn out through the turn and so, to tune it for a large turn, the error correction needs to be much different from a small turn. A motion profile breaks down a move into many much smaller movements and a trapezoid shape to this movement runs much smoother because the PID does not build up the error like it would otherwise. I hope you are successful in running PID, it can greatly improve your performance, especially in autonomous.