Quote:
|
Originally Posted by Kevin Sevcik
Anyways, I'm questioning the need of an entire co-processor for simply processing the shooter encoders and PID. Or atleast the PID. Unless you're being fancy, your PWM update rate on the controller is rather limited, so I can't see the the advantage of doing a really fast off-board calculation and then queuing it up to wait to be output in the RC.
|
Actually, no queuing was involved. We simply SWAPPED a 16-bit word every RC loop, bitwise simultaneously on one clocking (one bit in and one bit out per clock bit). IOW every loop the RC
exchanged its currently desired RPM for the Shooter PIC's latest Victor command, which the RC then simply echoed. That's a relatively short driver for the RC.
I already listed the main advantages above. But in addition, I knew in the past a
lot of teams have had encoder driver, sampling/averaging, and PID loop timing problems with the RC. Most of that stemmed from one or more of: filtering on the I/O lines, Die Errata problems, interrupt interactions, library function problems, or because of the RC's internal interprocessor communications overhead. (IOW, random vagrancies of the RC, which we could not control nor modify.)
For that reason alone we simply elected to avoid the whole shebang by taking it
all off the RC.
But IMO the biggest payoff was that (MUCH to our surprise) our shooter control subsystem hardware ended up being built, written
and debugged all in about
one week,
off to the side. ( IOW, it was all
done BEFORE we even had the shooter's
hardware in hand...) IMO this was primarily because we knew EXACTLY what the co-processor circuit was (and could tweak it if need be), and we did NOT have to interleave testing and software integration with our other RC software work. This avoided ALL of the RC's "black box" vagrancies.
Once the shooter hardware was ready we only had to "tune the loop". To do that, we
still didn't require the RC. Instead, the Shooter Team simply used our spare "field swap / repair copy" of the PIC board as an RC "protocol simulator". Add a simple harness, a short test program running on the spare, and Hyperterminal, and we were in business.
That let the Drivetrain and Manip teams keep the real RC to themselves 99% of the time, which sped
THEM up.
<edit>
Now don't get me wrong. The RC works just fine with straight code. But if we wish to do high code, realtime, interrupt driven, high math, or time intensive code, and one
has a working co-processor on hand, why should you even
want to wrestle with the RC's limitations and perhaps even risk delivery?
</edit>
Now that we have a generic RC vs co-processor "swap data" routine running, the big code is already done. Why
not do it again? From now on, making ANY kind of future co-processor to "smarten up our payload widgets" should be fairly straight forward, and an attractive option.
- Keith