Re: PWM 13-16 Replacement Code Beta Test
 

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

Re: PWM 13-16 Replacement Code Beta Test
 

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...

Re: PWM 13-16 Replacement Code Beta Test
 

Most likely the PWM outputs from the user processor run through a buffer with an enable line, and the master disables the buffers when the robot is to be disabled, which tri-states the buffer outputs.

Re: PWM 13-16 Replacement Code Beta Test
 

He disabled the interrupts when the pwm's transition from low to high

Re: PWM 13-16 Replacement Code Beta Test
 

They aren't connected directly (which is why you can't use them as inputs). There is a switch that is controlled by the master that determines which processor gets to send its output to the pin. The call to Setup_PWM_Output_Type() tells the master processor who's in the driver seat (icky pun intended). When your 'bot is disabled, the switch is flipped to the master, which provides the 1.5 ms neutral pulse.

Edit: Actually, Dave's explanation may be closer to the truth. If the master is capable of generating the PWM output, why do we have the Generate_Pwms() kludge to deal with. Still, the 1.5 ms PWM neutral pulse needs to get generated for safety reasons. If not the master, who?

The pulse doesn't glitch because once software sets up the timer and CCP hardware and says go, everything is done in hardware, which is oblivious to the interrupts firing-off in the background.

-Kevin

Re: PWM 13-16 Replacement Code Beta Test
 

If you're talking about when the robot is disabled, I'm pretty sure the PWM pins are left floating. We noticed a side effect of this last year when we ran some servo wires close to our RS232 for the camera, and when the robot was disabled the RS232 would generate enough noise on the (floating) PWM line to cause our camera servos to twitch. Actually, now that I think about it, if those PWM wires had been connected to a Victor, it could have been a dangerous situation. When the robot was enabled, the PWM output was being driven such that noise was not an issue.

Re: PWM 13-16 Replacement Code Beta Test
 

Ugh, floating the PWM outputs doesn't seem like a good idea. Thanks, I stand corrected.

-Kevin

Re: PWM 13-16 Replacement Code Beta Test
 

I've been seing something similar to this when testing on our robot. I was using some Vex Motor Modules to test some code. When I would put the controller in the program state to download, sometimes the motor would just randomly spin in all kinds of directions, and I would usually have to unplug the backup battery if it didn't stop. Does this pwm code fix that? I would like to know more about these "floating" pwms. When I start testing with our arm mechanism it will be very dangerous if the arm can just start randomly swinging around in the prog state...

Re: PWM 13-16 Replacement Code
 

IMHO, one of the nice things about this software is the ability to define how the PWM range of 0-255 maps to the servo position range. So for fun, I decided that I'd like to wring-out as much pointing accuracy from my camera's tilt mechanism by mapping the entire 0-255 PWM range to the more useful 0 to 90 degree tilt range. These are the steps I took:

1) Moved the tilt PWM from PWM output 2 to 16. This is necessary because PWM() can only contol PWM outputs 13 through 16.

2) The first piece of information I needed was to find the PWM pulse width that caused the servo to rotate the camera to the 90 degree position. Using the camera software's interactive PWM adjustment menu to command the tilt mechanism to rotate the lens up, I found that the default gain of 5.0 us per PWM step wasn't high enough to rotate the camera to the 90 degree position. I opened up pwm.h and increased to gain on PWM output 16 to a value of 70 for a pulse step size of 7.0 us. I re-compiled and downloaded the code to the RC and found that I could command the servo to 90 degrees with a PWM value of 254. Using the inverse of the algorithm from PWM(), I calculated that PWM() was sending a PWM pulse width of 2.389 ms.

3) Using the same technique described above, I determined the pulse width I needed to send for 0 degrees to be 1.479 ms.

4) I then calculated the pulse width range that I needed to cover by subtracting the result of #2 from #3 for a range of 0.910 ms.

5) To calculate the gain, I just divided the pulse range needed by the available PWM range of 256 for a gain of 36 or 3.6 us per PWM step. This is the gain value that is needed to limit the range of servo motion to 90 degrees.

6) I now needed to calculate a new center point for the servo. If I leave it at 1.5 ms, the servo will rotate through a 90 degree range, but it will be -45 degrees to 45 degrees. I needed to change the center point to +45 degrees so the servo will rotate from 0 to 90 degrees. To calculate the new center point, I just divided the range (from #4) by 2 and added that to the 0 degree pulse width (from #3) for a value of 19340 (or 1.934 ms).

7) Plugging the values from #5 and #6 into pwm.h, re-compiling, loading the RC, and then testing, I found the range to be the desired 0 to 90 degree range!

8) I then changed the PWM value to angle code in terminal.c from:

printf("Tilt Angle (degrees) = %d\r\n", (((int)TILT_SERVO - 144) * 25)/50);

to:

printf("Tilt Angle (degrees) = %d\r\n", ((int)TILT_SERVO * 90)/250);

9) The tilt gain was then changed from 8 to 4 for faster tracking.

10) Because I now have better pointing ability, I was also able to change the TILT_ALLOWABLE_ERROR_DEFAULT value to 3 pixels.

11) Finally, I changed the min tilt PWM value to 0, the maximum to 250 (255 is a degree or two past 90), adjusted the mid-point to 50.

This new found pointing accuracy might come in handy if you're using the green tracking light for navigation.

-Kevin

Re: PWM 13-16 Replacement Code
 

Using the Bells & Whistles camera code, PMWs 13-16 twitch for a moment when data is stored to EEPROM. I can work around it easily, but it's definitely undesired operation.

Re: PWM 13-16 Replacement Code
 

Yeah, I noticed it this morning. I suspect the menu drawing code is using too much of the CPU and the servos are trying to return to the center position when they don't see a pulse for a while.

-Kevin

Re: PWM 13-16 Replacement Code
 

Can I now use the alltimers library and PWMs 13-16 at the same time?

Thanks in advance,
Robinson

Re: PWM 13-16 Replacement Code
 

Yes, shouldn't be a problem.

-Kevin

Re: PWM 13-16 Replacement Code
 

Is this feature included in the default 2007 code?

Re: PWM 13-16 Replacement Code
 

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).