Tuning PID Constants Over a Range
 

Our team is trying to impliment PID for autonomous driving/turning, however we are struggling on tuning the constants. We have been using 1114's suggested method of tuning kP, kD, then kI, and we have been successful for tuning a single value.

For example we can tune gyroTurn(5) to turn 5 degrees, but those constants don't work for gyroTurn(25). Are we doing something wrong? or are we supposed to create different sets of constants for ranges of the angle?

I am by no means an expert with PIDs, but in this I would suggest turn down the I constant. I ramps up over time, so with the greater degree of movement, it takes longer for the PID controller to get to the target value. Therefore, the I constant may get too high.

Sent from my SM-N920G using Tapatalk

Re: Tuning PID Constants Over a Range
 

Could you clarify what you mean by "didn't work"?

Was the response not fast enough or did it never reach the intended goal value?

Re: Tuning PID Constants Over a Range
 

Do you have a maximum velocity (or throttle) limitation in your code? If not, the constants used for 5 degree turns will likely cause substantial overshoot for 25 degree turns.

Re: Tuning PID Constants Over a Range
 

If we tuned the turn for 5 degrees, then the robot would be too slow and never make it to 25 degrees. If we tune the turn for 25 degrees, the robot would overshoot the 5 degrees.

Re: Tuning PID Constants Over a Range
 

We clip our motor power at 0.7, but this would not be slow enough for smaller angles and if we clip the power lower, the larger turns would be slower than desired.

Re: Tuning PID Constants Over a Range
 

You aren't doing something wrong, its physics at work. Due to static friction small angle are hard while larger angles are easy. Somewhere between 5 and 10 degrees you change between the two. Basically, in order to start turning, your drive motors need to be above a certain value in order to overcome static friction. At that point, you're then only subject to dynamic friction. We typically tune our PIDs for large turning values and then if we need to make a small turn, turn away and then towards the desired angle.

This year, we ended up having different turning/yaw control PID values based on if we were moving forward or not.

Re: Tuning PID Constants Over a Range
 

How fast are you trying to go on the large turns? What are you trying to accomplish that requires such a quick response? If you are doing something extremely difficult like a 2-ball auto, PID will likely not be sufficient on its own, and you will need to create better control loops using things like motion profiling.

While we're at it, the following information would be helpful:
What type of drivetrain do you have?
How many/which drive motors power the drivetrain?
What is the minimum throttle value which allows the robot to turn in place?
What is the maximum achievable angular velocity of the robot?

Re: Tuning PID Constants Over a Range
 

This is likely a static friction problem, and the easiest solution I've found to deal with it is to implement a "minimum output" parameter that roughly corresponds to the smallest motor voltage which will result in actual movement. Then, you change your PID response so that the magnitude of the output is never less than that value, e.g. you can just add the value (with the proper sign) to any output, or you can simply set any output that is too small to the minimum value (again, with the proper sign). I think the former behaves somewhat better, but both work.

You can also implement cascading control, where the output of your angle PID is fed to a velocity PID for the wheels instead of directly to the motors. Thus, the internal PID loop will account for the problem automatically (provided it is tuned correctly).

You also really should not need an I or D term for a turn-to-angle loop.

Re: Tuning PID Constants Over a Range
 

Something that also helps in making small turns is to move forward slightly while turning to the set degree.

Re: Tuning PID Constants Over a Range
 

I've found the opposite. I and D are quite important for pneumatic tires on carpet. We added the equivalent of I this year, and have found that D has been crucial for years to get smooth fast performance.

I don't think you need to go to cascading control here. That sounds more complicated than needed. We run statespace controllers, but the only real difference between a SS controller and a PID loop is the improved filtering on the velocity term. Our heading controller works very well.


The first thing I tell people who ask me about tuning controllers like this is to start plotting things. With time as the X axis, plot left power, right power, right - left position, and gyro heading. You'll learn a lot from those plots. Feel free to post them as well if you want some more feedback.

Backlash in your drivetrain is also important. If you have too much backlash, you will hunt around the goal. A small move will stabilize because you don't get moving fast enough to need to flip to the other side of the backlash in order to slow down.

What frequency are you running your control loops at? Are you using the WPILib PID loop or your own? Too slow a loop time, or running the controller in the joystick code can cause a lot of problems.

Consider also adding in a motion profile. You can do a constant velocity profile, or try a trapezoidal profile. This will give your controller a bunch of small moves in a (more) feasible path which will be a lot easier to follow. We do trapezoidal motion profiles for all of our movements.

OP: From your profile, it looks like you are in the Bay Area. If the timing works out, 971 would be happy to chat in person with you guys, and take a look.

Re: Tuning PID Constants Over a Range
 

We ran a cascading P loop last year, and it worked beautifully. It's really not any extra work (or complexity) to run cascading control if you're already using velocity control for your drive - you just output to the existing PID controller instead of to the motors.

Re: Tuning PID Constants Over a Range
 

Eli,

While your statement is true, we have found that simply putting a motion profile on your input will eliminate the need for cascading control.

To me, the motion profile (whichever you choose .. we use trapezoidal acceleration) is a more pure way to do it. We all know that if you give a step input to a motor it really doesn't behave that way so why not give it an input it really can perform.

We have found that motion profile + feedforward gain + PID work for all of our telemetry navigation needs, whether it be for driving or moving a ridiculously complicated arm.

Austin and his crew use state space, but I am too simplistic for all that awesomeness so I stick with profile + FF + PID.

Paul

Re: Tuning PID Constants Over a Range
 

I would agree that motion profiling + feed forward will help a lot. 254 and 971 did a great video on this at champs in 2015 (https://www.youtube.com/watch?v=8319J1BEHwM).

The process that we used for tuning our turning went something like this:

1.) Write and test motion profile code (graph it to make sure that it is actually doing what it is supposed to).
2.) Find motion profile parameters. We used trapezoidal motion.
2a.) You can find the maximum velocity by sending 12v to both motors and looking at the maximum slope of the line.
2b.) From the same plot of the velocity, you can run a regression to get the acceleration.
2c.) You should set you FF parameters to something slightly lower than the actual values - as the season wears on, your robot will get less efficient, and you don't want to ask your robot to follow a profile that it's incapable of following.
3.) Find FF parameters
3a.) You can use the dynamics of the system to calculate what these should be, but we found that for turning, they ended up being fairly inaccurate (probably wheel scrub + static friction were a lot of that. pneumatic wheels can be a pain :P) We started with calculated values, and tuned them by hand until they largely matched the motion profile. 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.
4.) Start tuning PID. There are many different strategies for this. The one that you are using looks fine. Test every change for a range of values (90deg, 25deg, 10deg, 5deg, 2deg, etc. This also applies to tuning the FF values.) Again, graph everything. You can very easily see the effects of changing PID parameters from the graphs.

Another thing to consider it when you want to terminate the loop. If you don't need to be very accurate (for example, in an initial turn before starting vision), then don't have strict termination conditions. Also, if you have problems with the robot continuing to turn after the profile is over, consider adding a minimum derivative as a termination condition.

If you have any questions, feel free to ask.

Re: Tuning PID Constants Over a Range
 

We're working on motion profiling this preseason - I entirely agree that it's a conceptually better way to do it.

Re: Tuning PID Constants Over a Range
 

Agreed! profiles + Feed Forward + PID is good enough for FRC. Everything in FRC can be worked down to a second order system, which means that PID is a good control strategy.

I love playing with control systems, and like pushing the limits. That being said, I don't recommend using the controllers we use unless you have a strong math background and time to learn what is going on.

The Talon SRXs have good support for all of this as well.

Re: Tuning PID Constants Over a Range
 

Wesley did a great job of summarizing our process for tuning, but I'd like to add a few things, especially with respect to the trapezoidal motion component:
(emphasis mine)

2b) The regression that Wesley is referring to is an exponential regression against the solution to the second-order differential equation that the drivetrain (theoretically) should follow: x'' = ax' + bu where x is distance (or angle - we controlled angle and distance with two separate controllers) and u is voltage, assumed to be constant at 12V. You basically just collect a bunch of data and then do a regression on that to find the constants a and b. You can also not bother with this part for acceleration and just try to manually tune constants, which can work just as well or better in some cases but can require more time.

2c) You definitely need to set the motion profile's acceleration and velocity parameters to lower than the maximum, but not only because of wear/tear/battery voltage/other pesky things that happen in the real world. If you set the velocity to the maximum the robot can possibly go, you will not be able to actually control it when it is going that speed - to properly control a system, you should not be saturating its inputs or the system and controller will respond in a pretty strange manner (nonlinearities are unlikely to play well with PID controllers), being "less responsive" when moving at full speed than when accelerating or decelerating. In addition, the end of the acceleration period will get cut off and will not act nicely (the middle plot is velocity and the bottom plot is voltage):
Attachment 21083

3a) I don't have anything to add on this point, but I just wanted to emphasize how important it is to have some way to visualize everything that's happening on your robot. Not only for tuning purposes, but for debugging as well - log everything you can in some way; it will serve you well when you are tearing your hair out over some strange bug.

Re: Tuning PID Constants Over a Range
 

One more idea is to use PID alone for small movements (like < 5 deg) and motion profile (w/ PID position control) for larger turns. If you tune your controller for using motion profile the gains will be relatively high and should work well for small angle corrections.

Re: Tuning PID Constants Over a Range
 

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)

Re: Tuning PID Constants Over a Range
 

Are you saying for heading changes, let's assume turn in place, you'd suggest figuring out how far the wheels need to turn and then just position PID them (with or without motion profile) ?

Re: Tuning PID Constants Over a Range
 

Yes, but he's proposing that the output of the position PID and (maybe) profile would be a velocity to feed to the velocity PID running on the talon.

Re: Tuning PID Constants Over a Range
 

So run a traditional PID control loop with the Gyro as the input and a fake output that sends a target velocity to the velocity PID on the talons?

Re: Tuning PID Constants Over a Range
 

Yeah, use one controller with gyro angle as the process variable to track a desired heading profile. The output of this loop is a desired angular velocity. You can then use an inverse kinematics equation* to map angular velocity to drive motor velocities, and use these as velocity setpoints for the Talon SRX.

* For differentially steered robots, this equation looks something like:
(you can also multiply the right side of the equation above by a corrective factor that you tune to account for losses due to skidding; ours was ~2 with 8 low pressure pneumatic wheels this year. You don't have to be super precise on this, as the gyro PID controller will correct for error, but better to be more accurate than not)

To tune this, start with the Talon SRX velocity loop and work backwards. Make sure you can accurately track a variety of speeds (both fast and slow) in straight line, turn in place, and arcing motions. We were able to find that one set of gains did a good job in all of these cases, but YMMV. Once you can accurately track your velocity commands, tune your kinematics by adjusting the equation's corrective factor while turning in place (ex. command each side of the drive to go +/- a couple feet per second and measure the actual turning rate with the gyro...repeat and find the best fit for your model). Finally, you can then tune the gyro PID loop (which will be really easy, likely P-only, because of the fast velocity loop underneath).

Re: Tuning PID Constants Over a Range
 

For a robot with center of mass located at center of rectangle formed by the 4 wheels, I think that should be:

S = (1+f²)(W/2)ω

S is drive wheel linear speed
W is trackwidth
ω is desired turning rate in radians per second
f the the ratio L/W, where L is wheelbase

Re: Tuning PID Constants Over a Range
 

And by L (wheelbase) you mean contact patch (I think that's the terminology Hibner used)? So, for most teams it would be either the distance between the inner 2 sets of wheels (4/8wd) or the distance between the sets of wheels that the CoM is between (6/10wd). I'm going to ignore the option of a moving CoM because it's going to make my head hurt.

Re: Tuning PID Constants Over a Range
 

Re: Tuning PID Constants Over a Range
 

Yes, I know the traditional definitions. Perhaps a better question would be, do I measure wheel base as the distance from the front wheel to the back wheel or do I measure it from the front wheel that touches to the back wheel that touches for drop center drive systems?

Re: Tuning PID Constants Over a Range
 

for 6WD drop-center skidsteer with most of the weight over the center wheels "f" is essentially zero so it reduces to Jared's formula.

Re: Tuning PID Constants Over a Range
 

Yep, and this is the equation we actually used as our starting point (using the track width and wheelbase length of our inner four wheels). Our CoG was within an inch or two of the geometric center (ignoring dynamics). We found that even with this correction, we were ~50% off of the true value (a bit unsurprising since even though our outside wheels were raised, they still bore some weight because of deflection of our 15-20 PSI inner wheels).

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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!

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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!

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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 :P 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.

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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

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 :D )

Re: Tuning PID Constants Over a Range
 

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?

Re: Tuning PID Constants Over a Range
 

Yep, that's usually how gravity works ::safety::

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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

Re: Tuning PID Constants Over a Range
 

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.

Re: Tuning PID Constants Over a Range
 

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?

Re: Tuning PID Constants Over a Range
 

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 :P

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.

Re: Tuning PID Constants Over a Range
 

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). :]

Re: Tuning PID Constants Over a Range
 

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.

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


.

Re: Tuning PID Constants Over a Range
 

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


Sinusoidal acceleration motion profile equations

.

Re: Tuning PID Constants Over a Range
 

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

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.

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

Re: Tuning PID Constants Over a Range
 

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.