How Can I aim at the Vision Target Faster but without overshooting?

[NextPerception]

We are using the camera so that the robot goes into a loop and moves the drive wheels until the camera tells us that it is centered. this lets us aim the robot at the light. I can get it to work but I can't get it to do it very fast. this is what i have so far right know.

  if  (aiming == 1 | p1_sw_trig == 1)
  {
    aiming = 1;
    Switch1_LED = 1;        // aiming light turns on when aiming
	if (p4_sw_trig == 1)
	{
      Switch1_LED = 0;
	  printf("override button pressed");
      aiming = 0;
    }
	else if (T_Packet_Data.confidence < 5)
    {
      Switch1_LED = 0;
	  printf("lost light lock");
      aiming = 0;
    }
    if (PAN_SERVO > PAN_CENTER_PWM_DEFAULT + 20)
    {
      pwm03 = 127 - aim_gain;
      pwm04 = 127 + aim_gain;
    } 
    else if (PAN_SERVO < PAN_CENTER_PWM_DEFAULT - 20)
    {
      pwm03 = 127 + aim_gain;
      pwm04 = 127 - aim_gain;
    } 
    else if (PAN_SERVO < PAN_CENTER_PWM_DEFAULT + 21 & PAN_SERVO > PAN_CENTER_PWM_DEFAULT)
    {
      pwm03 = 127 + aim_soft_gain;
      pwm04 = 127 - aim_soft_gain;
    }
    else if (PAN_SERVO > PAN_CENTER_PWM_DEFAULT - 21 & PAN_SERVO < PAN_CENTER_PWM_DEFAULT)
    {
      pwm03 = 127 - aim_soft_gain;
      pwm04 = 127 + aim_soft_gain;
    } 
    else 
    {
      Switch1_LED = 0;
	  printf("TARGET ACQUIRED");
      aiming = 0;
    }
  }

note that
aim_gain = 22 and aim_soft_gain = 15

The code makes the robot overshoot and oscillate back and forth. it takes ten or more seconds to get it to center and this is not very good.

I know there is a way to use a linear or even quadratic formula to increase the speed and to reduce the amount of overshoot instead of what i have i just don't know how to go about programming it. Any help would be vary much appreciated.

[KenWittlief]

you have discovered the world of PID control loops.

When your system overshoots that means the gain on your Proportional (the P part) is too high

you can fix this by lowering the gain, or adding the D part (differential) to the feedback algorithm.

If you think of it in terms of distance, velocity and acceleration (of your robot to point towards the target) then the P is like distance (how far off are we from where we want to be)

the D is like velocity (how fast are we moving towards the place we want to be)

and the I is something you use to make fine adjustments to the P (how far off we are times how long we have been 'off').

This is a whole semister in college - a very deep subject. To be honest the best approach is to keep turning your gain down until you stop overshooting, or you overshoot just a little and then center on one 'bounce'.

Adding the I and D to the loop is more complex, and it will only make your response time slightly better than the slight-overshoot response time.

[kaszeta]

Originally Posted by KenWittlief

you have discovered the world of PID control loops.

Indeed. If you search around, you can even find some sample code that people have posted (Kevin's PID.C/H last year, and I posted a Proportional-only version of our teams gyro feedback code, amongst others).

[KenWittlief]

something else that might help. When using feedback control (PID) loops, your system will respond better if it is way overpowered.

This means your bot needs to be able to turn very quickly. Another way of saying this is it needs to be able to turn very easily.

If you are using tank/skid steering and it take nearly full power to turn the robot, then the PID control system wont have any room to do its stuff (any headroom to make strong adjustments).

you might need to loosen up your steering by making the front wheels turn easier.

Another thing that causes overshoot is a slow response time. Make sure you code is as efficient as possible. Comment out all printF statements, and any other code that doesn't need to be there.

Think of it this way, the control loop functions by telling the motors to do something, then looking to see what effect that had on the aim of the camera

if it takes a long time for the control loop to 'look and see' then the response will be too slow for a tight (fast) lock on target.

[Mike]

My two cents about PID loops.

Today I tried implementing a PI loop. I've never done one before and was relying on non-proven code. I spent about three hours and called it quits. My new code that works great:

PAN_MOTOR	=	NEUTRAL + (pan_error / 5) + 11;

Adjust 5 and 11 to your needs.

Quote from my mentor: "Keep things as complex as necessary, and not a bit more."

[phrontist]

Originally Posted by Mike

My two cents about PID loops.

Today I tried implementing a PI loop. I've never done one before and was relying on non-proven code. I spent about three hours and called it quits. My new code that works great:

PAN_MOTOR	=	NEUTRAL + (pan_error / 5) + 11;

Adjust 5 and 11 to your needs.

Quote from my mentor: "Keep things as complex as necessary, and not a bit more."

For future refrence, for an application like a turret one would typically start with just P, and D to damp, and if it's too sluggish after damping (or you have steady state error) and I. In that order.

[KenWittlief]

Originally Posted by Mike

My two cents about PID loops.

Today I tried implementing a PI loop. I've never done one before and was relying on non-proven code. I spent about three hours and called it quits. My new code that works great:

PAN_MOTOR	=	NEUTRAL + (pan_error / 5) + 11;

Adjust 5 and 11 to your needs.

Quote from my mentor: "Keep things as complex as necessary, and not a bit more."

an excellent example! Pan error is the error signal (distance) from where you want to be. Pan error / 5 means your feedback gain is 0.2

Im not sure why you need the +11. That seems to be a zero point error, or maybe there is a zero point error in your feedback signal?

[Salik Syed]

yes usually a simple proportional loop is pretty effective...
i don't get the point of the +11 (recentering perhaps?)

But for us it wasn't smooth/good enough (our robot is very rocky at turning...looking into omni wheels but thats another story)
if you go to kevin.org there is a nice PID code you can use...

[Kevin Watson]

Originally Posted by NextPerception

The code makes the robot overshoot and oscillate back and forth. it takes ten or more seconds to get it to center and this is not very good.

I know there is a way to use a linear or even quadratic formula to increase the speed and to reduce the amount of overshoot instead of what i have i just don't know how to go about programming it. Any help would be vary much appreciated.

Here's a piece of code from the camera software (tracking.c) that implements a simple proportional controller:

-Kevin

static unsigned char pan_servo_position;
int temp_pan_servo;
int servo_step;
int pan_error;
 
// save the current pan servo PWM value into a local
// integer variable so that we can detect and correct 
// underflow and overflow conditions before we update 
// the pan servo PWM value with a new value
temp_pan_servo = (int)pan_servo_position;
 
// calculate how many image pixels we're away from the
// vertical center line.
pan_error = (int)T_Packet_Data.mx - (int)Tracking_Config_Data.Pan_Target_Pixel;
 
// Are we too far to the left or right of the vertical 
// center line? If so, calculate how far we should step
// the pan servo to reduce the error.
if(pan_error > (int)Tracking_Config_Data.Pan_Allowable_Error)
{
	// calculate how far we need to step the pan servo
	servo_step = pan_error / (int)Tracking_Config_Data.Pan_Gain;
 
	// Due to rounding error in the division calculation above,
	// the step may be calculated as zero, which will make it
	// impossible to converge on the target when x_error is
	// smaller than X_GAIN. To get around this problem, we just 
	// test for the zero case and set the step size to one. 
	if(servo_step == 0)
	{
	 servo_step = 1;
	}
}
else if(pan_error < -1 * (int)Tracking_Config_Data.Pan_Allowable_Error)
{
	// calculate how far we need to step the pan servo
	servo_step = pan_error / (int)Tracking_Config_Data.Pan_Gain;
 
	// Due to rounding error in the division calculation above,
	// the step may be calculated as zero, which will make it
	// impossible to converge on the target when x_error is
	// smaller than X_GAIN. To get around this problem, we just 
	// test for the zero case and set the step size to one. 
	if(servo_step == 0)
	{
	 servo_step = -1;
	}
}
else
{
	// if we've fallen through to here, it means that we're
	// neither too far to the left or too far to the right
	// of the vertical center line of the image and don't 
	// need to move the servo
	servo_step = 0;
}
 
// add the step to the current servo position, taking into
// account the direction set by the user in tracking.h
temp_pan_servo += ((int)Tracking_Config_Data.Pan_Rotation_Sign * servo_step);
 
// check the pan servo PWM value for under/overflow
if(temp_pan_servo < (int)Tracking_Config_Data.Pan_Min_PWM)
{
	temp_pan_servo = (int)Tracking_Config_Data.Pan_Min_PWM;
}
else if(temp_pan_servo > (int)Tracking_Config_Data.Pan_Max_PWM)
{
	temp_pan_servo = (int)Tracking_Config_Data.Pan_Max_PWM;
}
pan_servo_position = (unsigned char)temp_pan_servo;
// update pan servo PWM value
Set_Pan_Servo_Position(pan_servo_position);

[Mike]

Originally Posted by KenWittlief

an excellent example! Pan error is the error signal (distance) from where you want to be. Pan error / 5 means your feedback gain is 0.2

Im not sure why you need the +11. That seems to be a zero point error, or maybe there is a zero point error in your feedback signal?

Not sure what you mean by "zero point error" but the reasoning for the +11 is that eventually the motor would get to a point (say 133) where it was attempting to move the turret but did not have enough power too. So the +11 turns that into 144 and it moves the turret fine.

[NextPerception]

wow thanks this cut the time in half. this works great.

[Rick TYler]

Originally Posted by Mike

Not sure what you mean by "zero point error" but the reasoning for the +11 is that eventually the motor would get to a point (say 133) where it was attempting to move the turret but did not have enough power too. So the +11 turns that into 144 and it moves the turret fine.

After putting Victors on a meter, we've found that they center at about 132 instead of 127. Move your center-logic to 132 and your PD solution may work better. It sure helped ours. (Kevin Watson's PID code from 2005 uses 132 as its center point, by the way.) I'm assuming that your NEUTRAL is currently set to 127. If it isn't, you can just forget I said anything.

[phrontist]

Originally Posted by Rick TYler

After putting Victors on a meter, we've found that they center at about 132 instead of 127. Move your center-logic to 132 and your PD solution may work better. It sure helped ours. (Kevin Watson's PID code from 2005 uses 132 as its center point, by the way.) I'm assuming that your NEUTRAL is currently set to 127. If it isn't, you can just forget I said anything.

You shouldn't do that. You should calibrate the victors. See IFI documentation.

[Rick TYler]

Originally Posted by phrontist

You shouldn't do that. You should calibrate the victors. See IFI documentation.

Been there. Done that. All four Victors used for the drive system had identical outputs after calibration, and their zero value was 132. I can't speak for every Victor in the world, but our gyro autonomous code and our manual PID program both drive straight now.

Just my opinion. Professional driver on closed course. Do not try this at home. Read the manual. Your mileage may vary.

[Alan Anderson]

Originally Posted by Rick TYler

After putting Victors on a meter, we've found that they center at about 132 instead of 127. Move your center-logic to 132 and your PD solution may work better. It sure helped ours. (Kevin Watson's PID code from 2005 uses 132 as its center point, by the way.) I'm assuming that your NEUTRAL is currently set to 127. If it isn't, you can just forget I said anything.

Wow. I've been going from the official IFI documentation which says the Victor deadband is 117-137. I never gave it a second thought. But that would perfectly explain the asymmetric PID response I wrestled with a week ago.

I will take a few minutes on Monday to characterize our Victors and see if they show the same center as yours. It'll definitely make a difference if the true neutral really is 132.