I wasn’t saying it was wrong, just that it didn’t need to be integral = integral + area. the form I used was just what I would use in that case.
Didn’t forget about it, was trying to walk before we ran since clearly OP is new to this. Yes, it’s actually nice that they realized the integral was the area of the rectangle formed by the time, 25ms, and the error. If they wanted to continue down this path, which would be great because they can simply change one constant (call it I_MS_DELAY for now) which defines the time delay and the area under the curve, then they could adjust Ki to make up for it or they could use I_MS_DELAY in the wait1Msec() and (I_MS_DELAY * 0.001) in the area = error * (I_MS_DELAY * 0.001) and keep area in the integral addition.
It is just a matter of moving the decimal place around, the gain was way too high at 25.
I like the use of I_MS_DELAY because you can later change your PID loop time without affecting the tuning. Otherwise, the loop time is baked into the Ki gain by default and needs to be adjusted every time you change the timing in the wait loop.
Gonna miss these great questions when V5 takes over. I just get the feeling default PID in the smart motors will take the place of many teams learning about these great control loops.
adds a value to, as noted, the data log, part of the robotc debugger. Google will assist you further.
Back to original thread topic, what do you mean by “shoots off to the side”?
Try just running a P controller to diagnose the issue. Once you’ve done that (and I suspect that will work perfectly fine) tune your integral windup and kI.
Generally speaking the common implementation of integral controller in vex is pretty bad, so I also suggest avoiding integral term completely.