what is a good way to tune a PID for auto park? (we are using a PID to have a Auto park system for docking engaged on the charge station in autonomous) we are using a pigeon IMU gyro for the pitch angle for the auto park
Drive very slowly; that’s how we do it.
So we do drive pretty slow to autobalence currently but we are wanting to add some more things like scoring and getting out of community then autobalence or just scoring and we wouldn’t have enough time to do that because currently it takes about 13 seconds to balance what it does is drives up then goes over the tipping point and goes back untill it gets it which takes about 3 to 4 times
The ramp is much closer to a three-state discrete system than to a linear system, so PID isn’t a great control strategy. A lot of teams have had success with some form of bang-bang control instead.
We have a simple P gain controller with feedforward that reads the roll from the pigeon IMU.
We do drive the robot to as close to center of the bridge first as possible before starting the auto balance function. We use a P gain of like 0.03 or 0.04 I think and a Feedforward term of around 50.
m_balancePID.setTolerance(0.001); double pidOutput; pidOutput = MathUtil.clamp(m_balancePID.calculate(getRoll(), 0), -1.0, 1.0); drive(new Translation2d(-pidOutput, 0), 0.0, false, true); //swerve robot relative, open loop
If you can localize tightly on the balance point it becomes approximately linear; this requires a fairly good/accurate approach strategy, though. A bang-bang controller has a lot more leeway and can handle the entire process with simple logic that doesn’t require much tuning.
We usually perform those 3 scoring opportunities. The drive very slowly was with the PID controller but we drive fast a fixed distance to almost the balance point. We usually use all 18 seconds.
Red Match 8 - FIM District St. Joseph Event presented by Whirlpool Corporation 2023 - The Blue Alliance
what do you use to tell the robot to stop at a certain degree after you backup on to the station?
The ramp takes time to drop down to level. If you keep driving until it is level, or drive to fast, you will have driven too far and it will tip the other direction. We didn’t use PID at all. We drive fast onto the ramp and then drive a constant slow speed until the ramp is between -10 and 10 degrees, then stop and just let if fall into place. Most times, that’s all it took until we encountered a charging station that didn’t pivot as easily and stuck somewhere between 5 and 10 degrees (unbalanced). To remedy that, we waited one second then executed our same auto balance command but this time targeted 5 degrees as the stopping point. Most times this second execution of the command did nothing because it was already balanced.
For logic, its like this using a SequentialCommand:
- Score game piece
- Drive fast over ramp and out of community
- Drive fast back onto ramp
- Execute Auto Balance command which drives slowly until 10 degree target is hit
- Wait 1 second for ramp to level out which it normally does
- Execute Auto Balance command which drives slowly until 5 degree target is hit (this usually doesn’t move the robot unless you encounter a sticky charging station)
This is exactly what we did. The charging station on the field is definitely different than the one we used for practice, but we were able to dial in kP during our practice matches.
We didn’t adjust our tuning at all between our home small charge station and the real large one. Never had an issue.
We don’t use PID for the reasons put forward by Oblarg. Our auto-balance has been supremely reliable.
We use two separate BangBangControllers, each with a corresponding speed. We drive forward up the ramp, so our forward speed is one value, and the reverse (correction speed) is about 75% of that speed.
This is untested but just me thinking out loud-
Would you be able to use the rate of change from your gyro to sense if you’re currently in the process of tipping, and if you are, stop driving? And if the rate of change is 0, check which direction you’re leaning to decide which way to drive or if its flat don’t drive.
Anyone know of anyone using similar logic to this? Id assume you’d be able to drive up the station at a decent speed with this instead of crawling
Your thinking is correct, and I know of at least 2 teams that are doing this successfully.
I have to hand it to the GDC - this is a great game element from a technical perspective.
We did a very simple approach, we just drive fairly slowly towards the charge station to get it to lower. Then the autobalance command kicks in, which is just a simple p * error that is applied to the drivetrain until the angle is at a certain tolerance. We found that its better to have a high tolerance, as an angle of 1 or 2 will mean that the robot will stop moving when the charge station is pretty much leveled, but the robot might keep moving as it lowers, so the charge station would lower to the other side, and an occilating robot would happen. So for us, as soon as the charge station reaches 10 degrees, our robot stops. We have gone through 3 regionals and this works perfectly
This sounds like a really effective solution, which can have a high success rate
It pleases the audience more than I first thought it would when seen only as game rules. There is enough movement and drama that the audience can tell what is happening, if it’s a successful accomplishment, and if there is a valuable game-winning score or not. You are right, a great game element.
plus or minus 3 degrees
To compare methodologies you lower the ramp and then run a full routine of crawling up the ramp with the forward direction of the bang bang controller and then engaging the other direction.
We path directly to the center of the ramp and then engage a P loop.
As you can see the dead reckoning + P loop approach stops as the bridge as it tips to balanced, where your controller overdrives it and then tips it back balanced in reverse. I’m not sure how this proves the method you are using is more correct. This could have more to do with robot weight dynamics or tuning than control approaches but I checked multiple matches and your controller consistently does the overdrive step.
I don’t think I ever made a statement of being more correct.
But, I would say that you linked to qual 72, and if you look at the other matches we played, save for the time our alliance partner got stuck under the charging station so we couldn’t pull the ramp down, we’re pretty reliably balancing that charging station at T=14.
So, our approach may not be more correct but I’ll put dollars to donuts it’s correct enough.
And I’m certain it’s more reliable than other people’s dead reckoning + P approaches that I watched at our event.
It’s also stupid simple to implement, understand, and works under all possible charging station dynamics that we’ve used it on (wood, practice fields, events, etc) without needing to re-tune in any circumstance. I agree there are probably better ways to model it that may be equally (or even more) effective…but our scouting data suggests that ours is more than good enough.