-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft PR for manual PID tuning page #161
base: main
Are you sure you want to change the base?
Conversation
|
||
Profiled Tuning | ||
^^^^^^^^^^^^^^^ | ||
Profiled tuning can be treated much the same way as normal tuning, but the introduction of a profile the system should follow means much of the response can be calculated in advance with feed-forwards. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Profiled tuning can be treated much the same way as normal tuning, but the introduction of a profile the system should follow means much of the response can be calculated in advance with feed-forwards. | |
Profiled tuning follows a similar process as normal tuning, but with the introduction of a motion profile, this means much of the response can be calculated in advance with feed-forwards. |
You don't have to use my recommendation, but the sentence is stiff. The latter half is particularly stiff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a fantastic resource for teams to learn about and explore tuning mechanisms. The interactive simulations, examples, and "why" sections combine in a very effective manner. I left a few comments focused on further improving clarity.
1. Zero all PID gains. | ||
2. Set a high setpoint (typically 8/10th the maximum velocity). | ||
3. Increase kS until the wheel starts moving, then back off to just before that movement. | ||
4. Set kP to a very low number (typically 10 / setpoint is a good starting point). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I understand the importance of setting kP is a very low number, how to calculate the recommended starting point isn't clear to me. Assuming the set point referred to on this line is the high set point, an initial value for kP would be 10/80 or 0.125. However, in the following example, a starting value of 10/10 or 1 is used. I'm not sure where the second 10 comes from; perhaps it is the low set point?
6. Repeat steps 4 and 5 until increasing kD results in more oscillation, or until the system oscillates on its way to the setpoint. If oscillation on the way to setpoint is seen, decrease kD until it stops. If overshoot in general is happening and kD is already at max, reduce kP until it stops. | ||
7. Verify gains work for other setpoints as well. Tune kP/kD as appropriate for most general cases. | ||
|
||
.. note:: Values of kP=200, kD=15 demonstrate the "oscillates on its way to the setpoint" case for setpoints within 1 rotation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This note is extremely helpful. Without experience, it is hard to know what is meant by "oscillates on its way to the set point" or "significant overshoot" means. Having example values to enter and observe the result is a great teaching tool.
|
||
Reduce kD even more to 9, and the system response looks relatively good at this point. Now it's time to play with different setpoint. Any setpoint within 1 rotation looks good, which is appropriate for a turret. However, let's say I'm not tuning a turret anymore, but some other position controller where a setpoint of, say, 20 is appropriate. When I set a setpoint of 20, I notice significant overshoot that I should correct in PID. | ||
|
||
At this point, I know that my kD can't go much higher otherwise I have oscillation on my way to the setpoint at smaller setpoints. So I try to stop the oscillation only with kP. Reducing it to 120, 110, 100, then finally 90 before the overshoot stops. I check back with my 0.1 setpoint to make sure it's still good, but now it looks overdamped. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I ran the simulation, I still had significant overshoot with a kP value of 90. (I ended up with kP = 72 and kD = 10, which is perhaps a bit overdamped but doesn't overshoot.)
|
||
Arm Tuning with TorqueCurrentFOC | ||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
Tuning an Arm is very similar to tuning a turret, just with the addition of needing to account for gravity. As such, the process is nearly identical, except for a small section dedicated to dialing in the kG term. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend stating what each color in the graph represents like was done for the previous two examples. People may jump to this section and not read the previous two.
Red is the setpoint in rotations, purple is the current position, green is the stator current in amps.
6. The kS gain is meant to reduce the effect of friction, so the largest possible value that still prevents the system from moving will reduce the effect of friction in general. | ||
7. The kP gain will control how quickly the system gets to the setpoint, however in TorqueCurrentFOC modes there is no natural dampening force, so overshoot is expected at the beginning. Once that happens kD should be tuned. | ||
8. The kD gain will effectively slow down the system as it reaches the setpoint, increasing it will increase the force slowing it down, so it should be increased until the system no longer overshoots. | ||
9. In general, the system wants as high a kP gain as possible to decrease the time taken to get to the setpoint. This also requires a high kD gain to properly dampen the system. The limit of how high the kP/kD term can be is determined by the system latency, at which point the oscillation is impossible to avoid. The goal of repeating steps 7 and 8 is to find that limit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this explanation that the goal is to have as high a kP gain as possible, limited by oscillation, is very important. Perhaps this should be stated above outside of the mechanism specific sections or at least not "hidden" in the "why" section.
|
||
In Phoenix 6, you can either generate your own profile and feed in the position and velocity setpoints, or use MotionMagic® and let the Talon generate the profile for you. In either case the Talon will have Velocity and/or Acceleration setpoints that it can use the kV and kA feedforward terms on, for more accurate profile following. | ||
|
||
The example below uses a pre-generated profile for the system to follow, and the general steps to tune it are below: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend stating what each color in the graph represents like was done for the first two examples.
Red is the position setpoint in rotations, purple is the current position, blue is the velocity setpoint in rotations/sec, brown is the current velocity, yellow is the acceleration setpoint in rotations/sec/sec, orange is the current acceleration, and green is the stator current in amps
No description provided.