All of my reading (not direct work with, I haven’t gotten to tune any NEOs or Falcons yet) leads me to believe teams need more math and better tuning to be able to control these motors.
In my opinion, with all the additional low end torque available, better control strategies have to be implemented, not worse.
This is exactly how it should have been said, this is a wonderful response.
As for who should be teaching it… I’m not sure. It’s seems plenty of mentors have found how to teach it within their team, but not anywhere near as successfully to the general public.
These readings are quite advanced. My goal was to address the audience of people who are just on the cusp of using PID’s. We have found multiple cases that we would normally want to use PID’s that it just needed a P control.
We have introductory documentation on control theory, feedforward, feedback, and motion profiles. The problem is teams never read it. The basic information is there; it just needs fleshing out with more figures and better organization for discoverability.
Any suggestions on how to better publicize WPILIB so that more teams can access it? (Sorry, this is far from the actual topic)
Gotcha. One thing I’ve been using at work is a “choose your own adventure” style series of links. Things like “click here if you’re an end user” or “click here if you’re a developer”, with more similar links underneath.
Ultimately, the hope is to lead a user who doesn’t know how to start to a small set of useful links - customized to the level they’re actually starting at.
Full disclosure: I’ve spent very little time going through the online-documented portions. I blame Oblarg for planting the seed in my head 
. Not 100% sure how successful it will be - a lot of it hinges on being able to inject lots of custom javascript to do pretty animated graphs.
I would think this is a fundamental gap to address. Vocabulary is important. In this context, there’s a two-level mental model I believe is useful:
One level involves deciding “use closed loop control” - that is, calculate a motor command using a sensor value. This is one choice to make - there’s a lot to be said about when this is necessary (or not), and when it’s a good idea (or not).
The second involves determining how that sensor value will be used. This is where specific algorithms come into play. Bang-bang, P, PF, PI, PD, PID, PIDF, State Space, etc. are all options. There’s lots of discussion that could be had as to what’s needed in each situation, as well as the finer details of implementing the chosen algorithm.
Of key importance: You want your development process for selecting a control algorithm to be overdamped: Start with minimum viable product. Increase the complexity if and only if the previous iteration wasn’t “good enough”. Don’t overshoot on adding complexity - only add it as you know for sure that you need it.
People tend to interchange “PID” and “closed loop control” in FRC land, blurring the line between the two levels in the mental model. This, I believe, is where a lot of the confusion comes from.
I do prefer to have the conversation in two steps. First - does it make sense to do closed loop control? Do you really need it? What are the goals you’re trying to accomplish with it? Second - what sort of algorithms make sense, given your physical mechanism, and its goals?
The message to take away is that none of this closed-loop stuff is a panacea or a magical sauce you sprinkle on your robot to make it “better”. It’s a targeted, precision tool you can use in very specific contexts to make some stuff work more as intended.
Quite the opposite in my experience. A Falcon 500 with a simple P loop can do an incredibly effective job of controlling most mechanisms. There’s so much power available and the feedback is so high-resolution and low-latency that unmodeled dynamics are a smaller problem than they used to be.
254’s robot has 12 PID loops this year (none of which are using I, btw), and they work great.
Does industry assume P loops to be PID loops? I’ve been taught in the past these should be considered different since they are relatively different in complexity.
I mean, the D term in a position PID controller is just proportional control on velocity. There’s nothing magical about it. (The rate at which you change the position setpoint is implicitly the velocity setpoint.)
Yes. Drop a PIDE block (or P_PIDE if you’re using PlantPAx) in your ControlLogix PLC, set the I and D coefficients to 0 and call it a day.
Edit - and if you’re fancy, use the Autotune feature.
Typically when people say “use PID loops” here, they’re not also implying that I and D are non-zero. The large majority of loops we use are just P + feedforward, with a few being PD + feedforward.
This is the key to a lot of the confusion I think - “PID” frequently refers to the particular software libraries which implement the controller, which almost always contain support for all the most-common terms in the controller.
However, just because a software library contains support for a certain feature, doesn’t mean you can’t “tune it out of the way” to simplify the behavior.
It’s a confusing overlap with using “PID” to refer to the actual post-tune math executed by the controller at runtime.
This is (or should be) my intent. Any or all of the gains might be zero. Depends.
Dang, we’re only at 6. Time to up our game 
.
Ah, I see that I have introduced a lot of confusion based upon some of my quick assumption while writing the post. I will remove the part that misused terminology.
No prob. I should have been more clear too: This is the mental model & terminology I use while talking about these things. Though I do find it useful, it’s not a universal truth 
.
No, PID controls aren’t one size fits all. But usually they’re good enough.
That’s basically why lazy automation engineers use PID controllers - They assume they can fit that particular control to be “good enough” for their system. Even if once tuned it’s not critically damped, or if the system has features that make PID not a “perfect” fit, it can still be “good enough”. And once they get it “good enough”, they basically leave it alone.
Thanks for your reply. I’m all about re-use, so if you have some base software like that that can be re-used in >1 year, that sounds amazing. I’d love to follow up with you sometime about all that, the software and your process. I don’t suppose it’s available on github?
Yes, https://github.com/errorcodexero/newarch
You can look at our wiki https://www.xerosw.org/ under the software section.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.