Quote:
|
Originally Posted by Joohoo
I Had this cool idea durring the build season when trying to get a timer working
To have a processor that could control some of the more of the cumbersome tasks. Making it another set of in/outputs.
Has there been any rules specifically prohibiting this. Or has any one done this before
Just throwing this out to see what every one thinks
|
This year, my team did use an off-board processor. We used another pic to handle reading the speed of the wheels on our shooter.
We had an optical sensor pointing at the bottom of each wheel which would detect when a painted section would went by. By measuring the time between the different pulses that occurred when the segments, we could determine whether the wheels were turning too fast, too slow, or ok.
To talk to the main processor, we went with the KISS solution: one-way communication on the same number of lines as bits of information. In other words, each line was one of the following:
-Right wheel is too fast
-Right wheel is too slow
-Left wheel is too fast
-Left wheel is too slow
The controller's end took a little tuning to get it to settle down correctly, but that's to be expected.
The advantage of this was that we didn't need to take any extra interrupts.
If you wanted to do something where it gave you the ability to do a bunch more IO, you could do something more complicated. For example, I believe I read something about a team that decided to develop a box in the off-season that would do telemetry, and then just tell the main controller its results.
The main restriction that you'll face is that you can't have the extra controller control a motor, pneumatic valve, etc. If this were allowed, we would have done things differently, with the main controller telling the off-board controller to make the shooting wheels go at some speed, and then only taking an input for whether or not they were up to speed.