Skip to content
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

Draft
wants to merge 29 commits into
base: main
Choose a base branch
from
Draft

Conversation

CoryNessCTR
Copy link
Contributor

No description provided.

source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved
source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved
source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved
source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved
source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved
source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved
source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved
source/docs/application-notes/manual-pid-tuning.rst Outdated Show resolved Hide resolved

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@gcschmit gcschmit left a 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).

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.

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.

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.

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.

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:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants