Quote:
|
Originally Posted by Kevin Sevcik
Keith,
Great post. I suppose I can't argue with being able to troubleshoot the entirety of the shooter loop sans RC. That's definitely sweet. I was just noting that the PWM update rate for the RC is 26.2ms, unless you're doing fancy things with interrupts and PWM13-16. If you can't do your PID calc in the RC that quickly, you've got serious problems in your code.
Now, you can relatively easily make your own code for PWM13-16 so they update at the 120Hz that's the max the Victors can handle. In which case you might need a quicker calc for your PID.
Come to think of it, I'm curious about the exact signaling and timing of all that data passing back and forth between your processors. If I'm thinking about it right, you'd get at least a 1 cycle delay from your commanded RPM change to the new command being sent to the motors. Maybe more.... Which probably doesn't matter in the rather stable systems in FIRST, but could still be a concern.
|
Thanks! (Feel free to send positive Rep if you actually found my babbling useful... )
You are correct in that with a single conversation per loop you
normally have one loop delay between command and reply. (Send the problem in one loop, pick up results in the next one.) But there is absolutely
no technical reason prohibiting you from talking
more than once to the co-processor in any one RC main loop or interrupt. After all, you have DIRECT user program control of many of the Digital I/O lines, which can babble to your heart's content at multiple MHz within your driver call...
However, once your loop is done (and due to reentrancy concerns with calling things from interrupt drivers) you normally end up waiting for the next loop to get control again. So for all intents and purposes you're
always somewhat limited to roughly the loop time for updating Victors. (Attempting to refresh a Victor multiple times within one loop won't do much good. There's that darn frame time delay between calling the RC's realtime PIC and it "getting around to sending it out"...)
Now WRT Victors and delays, don't forget to add in
another 17ms or so of delay, for the Victor to hear and
interpret the PWM command. Remember, the data first has to be sent from the user code PIC to the RC's realtime PIC, then encoded and sent again as PWM
after the current PWM frame is sent, and then
decoded back by the Victor's PIC. I was also told by IFI that the time between the output call to the realtime PIC and the updated PWM appearing is
asynchronous.
Therefore, even with a fresh PWM value in your hot little hand, you
may end up with up to 40ms or so of delay between your code loop's output call and the Victor's response. Right away, that seriously limits
any PID's bandwidth.
That's yet another reason why sweating the vagrancies, delays (and Errata) of the RC was something we wanted to minimize. Going with a co-processor, its
basic job is tuning the PID loop, and "accommodating" the "RC and Victor chain's" variable delay.
WRT communications, we should probably take the general discussion of Co-Processing nitty gritty to another thread. But briefly, for this project we used just
five signal lines. Four were for the basic bidirectional "co-processor board #1" communications that runs at blazing rates. One additional line was used as a dedicated "The Shooter Is At Requested Speed" signal to the RC, to simplify our FullAuto firing routine (which guaranteed
all balls left with the right KE). FYI, bidirectional talking to
more co-processor boards only requires TWO additional RC digital I/O lines per board. The RC runs the exchange, so it can go as mental as it wishes without data corruption or overrun. No analog or serial ports (nor their handshake wires) are required. Message length is arbitrary, yet message sync can't be lost. Co-processor power comes from a raw breaker panel fuse, not the RC.
(Thought Exercise: Even without starting a new thread, that spec
should allow one to determine what all the signals are, and what their timing needs to be...)
The Bottom Line (and back to Errata!): Though the OI/RC set is cool, IFI won't allow any of us access to their schematic nor firmware listings. Now that's OK, but that'll always make the RC somewhat of a Black Box, which at times
may exhibit "exotic behaviors", especially due to Errata, firmware bugs, etc....
We simply got tired of dealing with Errata and other random timing problems for doing complex things, especially when it could possibly "risk the farm" during the build. So though we'll still have the RC do a lot of work, IMHO developing co-processing technology for "any BIG thing" that
might stress the RC (or our Programming Team) was
well worth the initial development effort spent last year. This gives
US more design control, and greatly reduces the possibility of Errata interactions should we ever need to "do/make something complicated" again.
Does that all make sense?
- Keith