Dang it, I'll bite. I wasn't doing anything tonight anyways...
Quote:
Originally Posted by thatprogrammer
This post raises some interesting points on controlling robots under
game conditions rather. I had a few questions based on your points.
1. Is there an advantage to using a motion profile with a constantly changing set-point? Obviously, the advantage of a motion profile is that you can travel over a pre-calculated path in a fairly efficient manner. How does this translate if you are dynamically adjusting your set point, resulting in the roboRIO being required to generate a new set point dynamically?
|
I'm a tiny bit confused on what you are asking, so let me know if I missed.
I like to build the motion profile in as a "block" in the list of blocks that a signal flows through. It then works as follows. button presses -> goal -> profile -> instantaneous goal -> PIDF -> voltage.
The driver doesn't always want to wait until a motion finishes. If he tells the intake to go down, but realizes that was a bad idea and lets go of the button to lift it back up, I don't want the motion to violate the acceleration and velocity limits as it turns back around and profiles back up. By dynamically computing the profile required to move from the current profiled position/velocity to the final position, this is not a special case anymore. Sure, the math is harder, but it is more robust.
Nobody here has talked about adjusting your profile when your actuator saturates. Being able to dynamically recompute your profile in this case helps enormously. Unfortunately, once you start trying to handle saturation, you can get in some nasty loops where you then move your profile in such a way which causes the controller to over-compensate, causing the whole mess to go unstable. In other words, warning: there be dragons here. We've tried various things over the years, and I'm not super thrilled with any of our solutions.
The math ends up being pretty straight forwards. We end up computing every cycle of the control loop the amount of time that we need to accelerate, hold max velocity, and decelerate given the current state. We then execute 1 time-step worth of that plan, and use the resulting location as the next state. There are a couple square roots, and a couple multiplies, which is cheap on current hardware.
Ether linked to some previous implementations from an awesome thread a couple years ago. That thread was a lot of fun, and I'd highly recommend reading it carefully. 971 has an implementation available in our open source release as well if you are interested.
Quote:
Originally Posted by thatprogrammer
2. Points 2 and 3 (assuming you DID need to calculate induced dynamics)
Require model based controls, do they not?
Thanks for all the help in this thread! It's been really fascinating to get an understanding of how a PIDF loop can be used to linearize the PID portion of a controls loop.
|
I read Kevin's point, which is a really good one, to be that you can model more and more, but there will always be un-modeled disturbances. That's why we have feedback controllers. Compensating for gravity may help most of the time, but won't magically fix issues.
We on 971 have not modeled gravity in our loops in a long time. We would rather design controllers which are robust enough that an un-modeled disturbance as consistent as gravity will be compensated for quickly. I actually like to use gravity as a test case to see how well my disturbance rejection is working
