Quote:
Originally Posted by Cal578
We're getting closer. 
1. The "int" term needs to be defined. I think you want:
Int = error * dt * IntGain
2. I don't think we usually want Feed_Forward for positional control, and if we did, it wouldn't just be the last output. This implementation looks like another integration (it keeps adding the output to the last output). Feed Forward is where you have a predicted function of what input is needed to achieve the desired setting. The great thing about Feed Forward is that the rest of the PID algorithm only needs to account for the non-idealness of the prediction function and the other errors introduced in the system. |
The thread is about velocity PID (at least that's what the title is).
For velocity PID, a feed forward algorithm would calculate the steady-state motor power required and would add it to the end.
Algorithm implementations I've thought of for velocity control feed-forward:
-Equation to solve for motor power given RPM assuming 12v battery. I takes care of battery differences.
-Equation to sovle for motor power given RPM and vBatt.
-2d curve table (interpolated lookup table w/ 1 input x 1 output) from RPM to find motor power
-3d map table (interpolated lookup table w/ 2 inputs x 1 output) from RPM and vBatt to find motor power
I'm sure there are others.
As for CPU loads:
-The standard LabVIEW loop runs at default priority and is timed by a Wait call at the end. At the end of a task, LV will do a context switch somewhere else for the time of the wait and come back when it's done. So, you actual loop time equals the wait time plus the actual execution time, so this really sucks for timing determinism but is really easy to implement
-An alternative LV loop is timed to the UDP packets. A wait on occurrance is set (basically a synchronous blocking wait that waits for an event or times out) and called when a control packet is received and parsed. This removes the actual execution time from the timing equation but introduces timing non-determinism from the driver station laptop, network overhead and latency variations, and network load. This is generally not good either.
-LV can also use an 'RT Timed Task', which basically guarantees perfect timing if the CPU is not overloaded with tasks of the same or higher priority (which I would expect of any task, but this is the only way to implement a highly deterministic task in LV).
-Our normal loops generally run at 22ms or so but we have many of them (so they still manage to run up to ~90% CPU under worst-case timing conditions).
With a lot of architecture discussions and efficiency improvements, we are currently running all code in a single 10ms RT task with no worries (yet). If we have issue then we can step down to 12ms or 16ms or 20ms.
In all honesty, I have no idea how we can be so inefficient that we're running up to the limits of a 400mhz PowerPC with what we're doing, at the relatively slow speeds we run at, with the relatively small amount of code, without thinking about running vision on that processor as well.