PWM 13-16 Replacement Code

[bear24rw]

So how exactly would this effect the servos controlling the camera? Would it make them move smoother, more accurate?

Looks cool

[Noah Kleinberg]

Is there any reason that you couldn't use "int"s to store your motor speeds and have a greater range of values with the higher precision obtained by using the CCP (that is, instead of using the gain and center #defines)? I looked through the code and don't see why this wouldn't work, what i mean is something like this as a change to the PWM() function:

void PWM(unsigned int pwm_13, unsigned int pwm_14, unsigned int pwm_15, unsigned int pwm_16)
{
//	int temp_pwm_13;
//	int temp_pwm_14;
//	int temp_pwm_15;
//	int temp_pwm_16;

// .........
	// calculate the number of 100 ns timer ticks 
	// needed to match the desired PWM pulse width 
	temp_pwm_13 = (PWM_13_GAIN * ((int)pwm_13 - 127)) + PWM_13_CENTER;
	temp_pwm_14 = (PWM_14_GAIN * ((int)pwm_14 - 127)) + PWM_14_CENTER;
	temp_pwm_15 = (PWM_15_GAIN * ((int)pwm_15 - 127)) + PWM_15_CENTER;
	temp_pwm_16 = (PWM_16_GAIN * ((int)pwm_16 - 127)) + PWM_16_CENTER;

	// load the CCP compare registers
	CCPR2L = LOBYTE(pwm_13);
	CCPR2H = HIBYTE(pwm_13);

	CCPR3L = LOBYTE(pwm_14);
	CCPR3H = HIBYTE(pwm_14);

	CCPR4L = LOBYTE(pwm_15);
	CCPR4H = HIBYTE(pwm_15);

	CCPR5L = LOBYTE(pwm_16);
	CCPR5H = HIBYTE(pwm_16);

//..............

Also, could CCPR1L and CCPR1H (or 2-5) each be 255? I ask this because with the default GAIN and CENTER values, the maximum I believe is 21400 (that is for the two combined as one word), as opposed to 65535.

[Kevin Watson]

Originally Posted by Noah Kleinberg

Is there any reason that you couldn't use "int"s to store your motor speeds and have a greater range of values with the higher precision obtained by using the CCP (that is, instead of using the gain and center #defines)? I looked through the code and don't see why this wouldn't work, what i mean is something like this as a change to the PWM() function...

Yes, certainly! I didn't do it that way because I wanted backward compatibility with Generate_Pwms(). You could have any units you want, even degrees. Cool, eh?

Originally Posted by Noah Kleinberg

Also, could CCPR1L and CCPR1H (or 2-5) each be 255? I ask this because with the default GAIN and CENTER values, the maximum I believe is 21400 (that is for the two combined as one word), as opposed to 65535.

Sure, but having pulses as long as 6.5535 ms doesn't do you much good when controlling servos and victors, which want to see inputs ranging from about 1ms to 2ms.

-Kevin

[robind]

Looks great. I'll use it tomorrow and post back with results.

[Mike Copioli]

Hey Kevin? Does your code leave a pause between pulses sent from the CCP module? After looking at your code I did not see anything to indicate this. The reason I ask is because I have noticed that when continuous pulses are sent to a servo using the CCP module, the servo exhibits jitter. I have found that a 2ms delay or greater between pulses will stop this behavior. Have you encountered similar behavior?

[Kevin Watson]

Originally Posted by Mike Copioli

Hey Kevin? Does your code leave a pause between pulses sent from the CCP module? After looking at your code I did not see anything to indicate this. The reason I ask is because I have noticed that when continuous pulses are sent to a servo using the CCP module, the servo exhibits jitter. I have found that a 2ms delay or greater between pulses will stop this behavior. Have you encountered similar behavior?

Like Generate_Pwms(), my code only generates one pulse on each of the four outputs each time it's called. If called from Process_Data_From_Master_uP(), the update rate is ~38 Hz. Typical servos won't handle a rate much higher than this, but the Victors are okay to at least 100 Hz.

-Kevin

[Mike Copioli]

Originally Posted by Kevin Watson

Like Generate_Pwms(), my code only generates one pulse on each of the four outputs each time it's called. If called from Process_Data_From_Master_uP(), the update rate is ~38 Hz. Typical servos won't handle a rate much higher than this, but the Victors are okay to at least 100 Hz.

-Kevin

Ok, so does that mean you can not call it in the fast loop? If this is the case, is there an advantage to using PWM's 13-16? If the outputs can only be updated every 26.2 ms (38Hz) For example if I wanted to use 13 and 14 for camera servo control, to move 200 steps would take over 5 seconds if it moved in one step increments (200 * .0262s). I really would like to see the camera "snap" to a position. It seems that nasty little 26.2ms loop time keeps getting in the way.

[Kevin Watson]

Originally Posted by Mike Copioli

Ok, so does that mean you can not call it in the fast loop? If this is the case, is there an advantage to using PWM's 13-16?

Yes, you could call it in the fast loop to control your Victors at a higher rate for applications like position control (which generally works better at rates greater than 38 Hz). You'll need to synchronize the updates to a timer or some sensor like a gyro.

I've already enumerated some other advantages above.

Originally Posted by Mike Copioli

If the outputs can only be updated every 26.2 ms (38Hz) For example if I wanted to use 13 and 14 for camera servo control, to move 200 steps would take over 5 seconds if it moved in one step increments (200 * .0262s). I really would like to see the camera "snap" to a position. It seems that nasty little 26.2ms loop time keeps getting in the way.

Your searching algorithm needs tuning. The camera has a fairly wide field of view, so I think you could use a much larger step. I would step in 30 degree increments, wait a bit for the camera to send a t-packet (or two) and then either start tracking, or step another 30 degrees... If you're using my code, these are built-in parameters you can tweak.

For grins, I used digital servos (not FRC legal) with my code and after modifying tracking.c a bit, I can find a green light and start tracking in somewhere between one and two seconds, without the software having any a priori knowledge of where the light is located. I suspect nearly the same level of performance can be had with the HS322HD servos.

-Kevin

[Mike Bortfeldt]

Kevin,

I would expect that the code should work fine. We (1126) used my version throughout the 2006 season without any issues. Your increase in gain from 40 to 50 is probably a good idea, as we found one of the Victors did not quite go to maximum at the high end (2 msec) without recalibration. The additional 25% on range should easily eliminate this potential problem. You may want to think about modifying your "temp_pwm_xx" calculation so it doesn't require the signed int multiplication. This adds a fair amount of execution time to the routine (relative to how quick it could execute, not to overall processor usage which is extremely minor). It also requires the use of the MATH_DATA section so if someone ever wanted to use the routine from within an interrupt (why? I don't know, but I never rule anything out), they would need to save that data section. I do like the addition of the CENTER & GAIN options it allows for much more flexibility.

Mike

[AdamHeard]

So... is the legality of this confirmed?

-Adam

[Kevin Watson]

Originally Posted by AdamHeard

So... is the legality of this confirmed?

-Adam

There are no rules preventing teams from using this code, so there is nothing to confirm. If you're thinking that this somehow gets around the ability to safe motors, it doesn't because IFI's mechanism for doing that is under the master microcontrollers control.

-Kevin

[Matt Krass]

Originally Posted by Kevin Watson

There are no rules preventing teams from using this code, so there is nothing to confirm. If you're thinking that this somehow gets around the ability to safe motors, it doesn't because IFI's mechanism for doing that is under the master microcontrollers control.

-Kevin

I'm curious how that works, since the pins are supposedly connected straight to the user processor, how would the master processor disable that?

Also, how did you get around the interrupt-glitch thing? I'm missing something obvious when I look at the code...

[Kevin Watson]

Originally Posted by Mike Bortfeldt

Kevin,

I would expect that the code should work fine. We (1126) used my version throughout the 2006 season without any issues. Your increase in gain from 40 to 50 is probably a good idea, as we found one of the Victors did not quite go to maximum at the high end (2 msec) without recalibration. The additional 25% on range should easily eliminate this potential problem. You may want to think about modifying your "temp_pwm_xx" calculation so it doesn't require the signed int multiplication. This adds a fair amount of execution time to the routine (relative to how quick it could execute, not to overall processor usage which is extremely minor). It also requires the use of the MATH_DATA section so if someone ever wanted to use the routine from within an interrupt (why? I don't know, but I never rule anything out), they would need to save that data section. I do like the addition of the CENTER & GAIN options it allows for much more flexibility.

Mike

Thanks. To be compatible with Generate_Pwms() and the Victors, I needed to use a 5 us step. Servos seem to like a narrower range of about 1.1 ms to 1.9 ms (gain = 32).

I used the signed int so that I don't have to worry about underflow when the subtraction takes place. I'll have another look to see if I can move the terms around to get rid of the int.

-Kevin

[pheadxdll]

Is this feature included in the default 2007 code?

[ace123]

It's included in Kevin's camera codes at http://kevin.org/frc/
But it's not in the one you download at IFI (that still uses the old Generate_Pwms() function).