Quote:
Originally Posted by ratdude747
my concern is it going all the way around from say 0 to 7pi/4 as opposed to only moving a distance of pi/4.
|
Read the
rest of the post. It explains how to deal with that. Try it with some example values and you'll see.
Quote:
|
my only real knowedge of pid is you give it a setpiont and a process variable and it controls a motor within given range of outputs
|
If you use the WPI library PID and feed it your desired angle as the "setpoint" and the measured angle as the "process variable" without the computations I showed in the post, then you will get the undesirable behavior that you are concerned about. The computations I posted show how to avert this undesirable behavior.
For example, suppose your steering angle encoder ("measured_angle") reads 0 to 360 degrees clockwise, with zero being "straight ahead". Suppose your calculated desired steering angle ("target_angle") also is 0 to 360 degrees, again with 0 being straight ahead.
Then let's do some example calculations:
Example 1:
measured_angle = 359 degrees
target_angle = 2 degrees
angle_error = target_angle - measured_angle = 2 - 359 = -357 degrees
angle_error -= 360*floor(0.5+angle_error/360) = +3 degrees
setpoint = angle_error = 3 degrees
process_variable = 0 degrees
In other words, the PID will try to rotate the steering clockwise 3 degrees, which is what you want.
Example 2:
measured_angle = 4 degrees
target_angle = 354 degrees
angle_error = target_angle - measured_angle = 354 - 4 = 350 degrees
angle_error -= 360*floor(0.5+angle_error/360) = -10 degrees
setpoint = angle_error = -10 degrees
process_variable = 0 degrees
In other words, the PID will try to rotate the steering counter-clockwise 10 degrees, which is what you want.
Notice how, in each of the above examples, the code "
angle_error -= 360*floor(0.5+angle_error/360)" calculates the shortest angle path (and the correct angle direction) from the measured_value to the target_value.