View Single Post
  #4   Spotlight this post!  
Unread 11-12-2007, 19:46
Qbranch Qbranch is offline
wow college goes fast.
AKA: Alex
FRC #1024 (Kil-A-Bytes)
Team Role: Alumni
 
Join Date: Apr 2006
Rookie Year: 2006
Location: Indianapolis
Posts: 1,174
Qbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond reputeQbranch has a reputation beyond repute
Re: PID vs Normal loops

Quote:
Originally Posted by Adam Y. View Post
Sorry. I was a little vague on the question. I meant has anyone tried other feedback loops. Theoretically anything is possible.
After the 2007 season ended, I had a heart->heart with PID on our '07 chassis. I was sick and tired of watching PID "get from one place to another as fast as possible". Call me a control freak, but I want to be able to call the shots for not only where something sits, but also how fast things accelerate, what the top run speed is, as well as how fast they decelerate.

Hence, an augmentation of the PID controller. I don't have the code with me, but let me explain to you how it works. First, I tuned up a really nice, very touchy PID. Touchy being it really goes nuts with a little bit of error (in the order of an inch). Then, here's where things get cool: I feed a stream of interim coordinates into the PID to generate trapezoidal velocity control while still arriving at the target. This is very useful for extreme long travels with large masses (like driving a robot from its starting position and arriving (smoothly) at the rack).

I think you can kind of understand how this works: if a stream of coordinates is fed into a pid loop at a constant interval (each time the PID updates, in my case @100Hz) you feed a new, short range target into the PID. These targets are no more than a fraction of an inch apart in my case, remember they get fed in at a rate of 100Hz. That occurs during the acceleration phase: these ramps can be precalculated or calculated at acceleration execution time... all you need is a little 1/2*A*T^2 action. When acceleration or deceleration is complete, you switch to a constant position delta so as to keep the speed constant. Deceleration functions the same way as acceleration.

Now, you may be thinking "hey, that's best suited for autonomous runs where distances can be pre calculated. what if my final target changes dynamically?"

Well, I'm working on that one. My goal is to have a fully mathematical (no precalculation) formula set that handles acceleration, constant run speed, and deceleration. v2 that I'm working on now isn't ready yet, but it operates on a summation of three PID loops, one watches acceleration, one watches velocity, and one watches position simultaneously. To decide which should be listened to, a selection structure is set up which lets whatever PID routine has the lowest power output solution access to the motor. Everything but one part works beautifully in simulation: i'm still trying to figure out how to hande deceleration without the interim-position method explained above.

Next on the list to be explored is state-space control which allows feedback from multiple sensors to factor into a single control loop and plant (motor or otherwise) action... but I might have to wait to have my curiosity satisfied till i'm in college a little while... I'm not sure how to do a Laplace Transform...

Questions? Post!

-q
__________________
Electrical Engineer Illini
1024 | Programmer '06, '07, '08 | Driver '08