Off board processor?

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

You are allowed a processor on the robot other than the FIRST one, as long as it acts as a “slave” to the robot controller. Off the robot, not under this year’s rules. This may change next year.

It always could change, but this has been in the rulebook for as long as I can remember. I don’t think it will be changing any time soon.

Maybe I’m not thinking clearly, but where else would you put a pre-processor but on the robot? The OI? Even there I think it’s legal, since you can plug in a computer as a dashboard.

I am a big proponent of pre-processing and I think some teams have been using it very effectively to operate vision systems and keep track of interrupts. It takes a lot of the burden off the main controller and I think it is the next step for teams who are already experienced with programming the RC.

From my understanding you cannot have a computer control system through the OI. A computer may only be used as a display (dashboard). I don’t know the rule to back that up, but I remember it being the case. We had wanted to use a computer about 4 years ago when I first proposed building the PlayStation controller interface (which team 862 has implemented recently in hardrware), but were unable to due to this rule. I didn’t have the technical background back then to design a hardware interface, so that was as far as the project got with our team unfortunately.

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.

Soo basically the slave processor can handle processing info and receiving inputs but can’t give any out puts to motors?

I think that sounds about right. The additional circuitry can do any calculations you need it to, but it must then relay that info back to the RC. This circuitry must also (I believe) be located on the robot, and cannot be sent from the OI as it would fall under the category of using a computer to control the robot.

All of that is of course assuming the rules stay the same for next year.

This is always important to keep in mind. That being said, the rules don’t usually change that much, and FIRST’s trend has been to liberalize the rules, not make them more restrictive. So, if you were to design and prototype a custom circuit using this year’s rules, chances are your design would still be legal next year (or require only minor modifications).

Yeah, FIRST tends to stick the same with most rules like this, but I just wanted to make sure everyone keeps this in the back of their minds.

Out of curiosity, is it currently legal to attach a seperate processor to the OI to create additional outputs (using the dashboard as a serial output to it)? I mean this processor would just display extra data from the dashboard port (yes I know you can do this with computers being allowed this year too), it would not have any joysticks or any inputs hooked up to it as the dashboard port is a one way street.

From everything I have read, it looks like the OI dashboard port is fair game for whatever you want to connect to it.