View Single Post
  #8   Spotlight this post!  
Unread 28-09-2016, 00:33
kylestach1678's Avatar
kylestach1678 kylestach1678 is offline
Registered User
AKA: Kyle Stachowicz
FRC #1678 (Citrus Circuits)
Team Role: Programmer
 
Join Date: Dec 2014
Rookie Year: 2015
Location: Davis, CA
Posts: 21
kylestach1678 is a glorious beacon of lightkylestach1678 is a glorious beacon of lightkylestach1678 is a glorious beacon of lightkylestach1678 is a glorious beacon of lightkylestach1678 is a glorious beacon of light
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:
Quote:
Originally Posted by wesleyac View Post
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 ) 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.
(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):
Click image for larger version

Name:	cutoff_tmp.png
Views:	81
Size:	38.7 KB
ID:	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.
__________________

Reply With Quote