VICTOR RESPONSE DELAY? - AGAIN

[Jared Russell]

The Victor updates at 120Hz. Worst case performance (assuming you have to wait the entire 26.2 ms to send the command to the master uP and you have to wait 8.3 ms for the Victor update) should be about 34.5 ms.

Note that the status lights and the movement of the motor are NOT good ways to confirm this. The status lights have some buffering in them, and motors take awhile to spin up or down (especially with gearing or loads attached). If you measure the lag between motor command setting and sensor output, then you are taking into account:

1. User to master uP communication
2. Actual Victor lag
3. Motor lag
4. Sensor lag

Try hooking the outputs of the Victor to an oscilloscope to verify. You can pulse a square wave on the Victor (i.e. output 127, 254, 127 at a certain frequency) while also pulsing a digital output pin. Look at both outputs to find the actual values for #1 and #2 above.

[Qbranch]

Remember this... the victor CHOPS at 120Hz on its output (which is dang slow, hence the angry buzzing all first robots seem to make).

The victor can only take input at a rate of about 100Hz (98Hz if your cautious). I wrote myself a two channel pwm driver using CCP's to make a high update rate traction motor servo for our robot and found that there was a control output delay of just microseconds from control input to output when you use an output hardwired in the processor and use an oscilloscope triggering on the control input and measureing the shift on the output by having channel 2 on your scope hooked on to M+.

Mechanics do add some latency, but the thing you really have to watch is that most people are running their pwm's on the default ifi 26.2ms basis, not on a timebase of your own.

My suggestion is just to set up a freerun timer, use eccp1 as a timebase, then eccp2 and eccp3 as duty cycle triggers (set them in hardware to initialize pin high then clear + interrupt on compare match). not only do you get a nice high update rate, but you get 16x the resolution on your motor drives. VERY nice for pid's, made a world of difference with the resolution and the update rate increase.

any ?'s just hit me up. I can dig up my research notes on the victor period times n such if anybody wants it, i'll scan the pages in and hopefully somebody reads bad handwriting....

-q

[Jared Russell]

Every official IFI post I've read about the Victor says that there are 94 discrete speed steps in both the forward and backward directions. While using custom PWM programming could increase update rate, I am skeptical of the claim that you gain any resolution improvements.

[Al Skierkiewicz]

To add some explanation...
The output frequency of the Victor was reduced in this model vs the previous model. With the type of motors we use, the 120 Hz rate works better when considering the brush design and rep rate of brush and commutator. This allows better average current control for the motors.
From IFI FAQ for Victors...:The Victor will turn ‘On’ at a value of 138 and it will be at Full Forward condition at a value of 232, which is 94 steps. The output will vary linearly from 3% to 100% over these 94 steps." This compensates for the poor performance of the pots in standard joysticks.

[Mike Bortfeldt]

This thread got me wondering what the exact delay is for generating PWMs 1-12. Last year, based on some crude testing, I noticed that there seemed to be about a 50 millisecond delay between setting a PWM value and seeing a response (as Greg references in his first post). This observation came from monitoring the dashboard data and was therefore, not very accurate. Yesterday, I did some additional testing and here are the results.

- PWMs 1-12 are generated by the master processor in groups of 3 (1-3, 4-6, 7-9, 10-12). Within each group the pulses are generated simultaneously with only the pulse width varying. Each group follows the start of the previous group by approximately 2 milliseconds. Therefore the previous group pulses are completed (no matter what the pulse width) before the next group is started. This ensures a constant frequency independent of the pulse width of previous groups.

- The delay between setting the PWM variable and seeing the start of the pulse on the output pin can be up to the following:
Group 1 (PWMs 1-3) - 43 milliseconds
Group 2 (PWMs 4-6) - 45 milliseconds
Group 3 (PWMs 7-9) - 47 milliseconds
Group 4 (PWMs 10-12) - 49 milliseconds

- The minimum delay before the Victor can respond will be at least 1 millisecond and up to 2 milliseconds more depending on the pulse width. The Victor output frequency and mechanical delays will increase the time before you see a response as well.

- The delay is dependant on when the PWM variable is set in the code. The delays shown above are based on setting the PWM variable at the start of the routine "Process_Data_From_Master_uP" (and are therefore maximum values). If your user code takes 10 milliseconds to execute and you set a PWM value at the end of this time, then the delay before the "new" pulse is generated will be 10 milliseconds less. From what I can see, executing the routine PUTDATA does not immediately send the updated data to the master processor. This only occurs once every 26 milliseconds, probably at nearly the same time that new OI data is being received. Either that, or the Master processor doesn't act on the new data until the end of the 26 millisecond period.

Test Setup - The entire test was performed using only the RC. The PWM output to be tested was connected to Digital Input #3 (interrupt enabled). Each pulse width was timed to an accuracy of 1/4 millisecond. The PWM to be tested was normally set at "254" (2 milliseconds). Roughly once a second (every 40 calls to Process_Data_From_Master_uP) the PWM was changed to a value of "0" and the elapsed time between setting the PWM and observing the first 1 millisecond pulse (actually 1.25 milliseconds or less) was timed to an accuracy of 1/4 millisecond. Once the pulse was seen, the PWM value was reset to 254 in preparation for the next test, 1 second later. Data was very consistent. (OI & RC were tethered)

A second test was performed by delaying the setting of the PWM to "0" from the start of the Process_Data_From_Master_uP by putting in a 10 millisecond delay at the beginning of the routine. This resulted in delay values exactly 10 milliseconds less than the first test.

Mike