Limiting max speed while tuning PID?

Technical Programming
1

We started tuning our PIDs for our drivetrain, but with the Falcons, if the controller saturates (even though it is clamped), we leave skid marks on the school’s carpet. If we change the clamp from positive and negative 1 (to say positive and negative .5), will it affect the constant values?

In other words, if we tune that way, once we have the tuning set and we open the limits back up to +,- 1, will they still be accurate and effective?

It seems they will be, but I just want to make sure.

I guess a follow-up (or perhaps, a better question) is, do you all just use sysid and not spend time trying to figure out PID constants on your drivetrain even if you are not yet ready for trajectories?

2

Depends on what kind of PID you’re implementing I guess.

If it is a positional PID, how will you know if your kP is high enough if you’re traveling toward your set point at double the speed from your tuned value?

1 Like
3

You should be probably be using SysId even if you’re not going to follow trajectories. There’s nothing about it that’s particular to trajectories; it’s just a motor characterizer.

You can use SysId in theoretical mode on the recent versions with gains from ReCalc to get pretty decent estimates even without running a test routine. For drivetrains, you can use the linear mechanism calculator and ignore the kG term.

4 Likes
4

That is an incredible point and why I asked the question.

Thank you. This is an excellent idea. I think we are going to attempt to use SysId this evening. Then, we will take it from there.

5

What do you mean by this? Note that one of the SysID tests will do a step function to the “Dynamic Step Voltage” that’s configured in the tool.

1 Like
6

Our lead programmer pulled this line from the Navx example…

MathUtil.clamp(turnController.calculate(ahrs.getAngle()), -1.0, 1.0);

So, I should have said that we are clamping the output so the controller does not oversaturate the motors. Sorry about the confusion.

TBH I do not know at what point the skid marks begin to show, but it definitely does happen. These motors are powerful, and currently, our robot is light (We are aware that when we add the mechanisms we are currently building, we will need to retune our constants), so it does not take much to burn out.

We were using shuffleboard to tune (we should change to glass), and one hypothesis is that since shuffleboard only shows hundredths, the number is just too big (kP=0.01 is too high). Whether it truncates the number or not, the second he begins to change it, it becomes too high.

I think SysId and Glass will help immensely and allow me to teach the team about PID a bit better. We were focussed on mechanical today so we did not actually run SysId, but we will.

7

We did run SysId last night. There were no burnouts to speak of. We have not had a chance to implement the findings, but I am thinking the KP came out quite high (~2.6). Has anyone else seen this?

8

That is usually pretty close to what I get for kP. Kit bot around 100 lbs with 6" wheels and 8.45:1 gear ratio. 26" wide (22 trackwidth) and 32" long. All done in meters. NEO internal encoders.

1 Like
9

Make sure you specify your sensor delay correctly, along with the rest of the params in the feedback analysis pane (the presets match default motor controller settings, and can be helpful).

You can share your data file (CD supports JSON uploads!) if you want, and I can give feedback based on what I see.

1 Like
10

Thank you. That helps a lot. I will look into that. We just scratched the surface last night. I will post the data if it is looking like it is not accurate as we dig.

Currently, our robot is about 50 lbs kit gearing and wheels and is running four falcons (It is extremely fast being so light and powerful).

11

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.