2 robot controllers legal?

is it possible to use two robot controllers on the robot, where one is the main controller and the other is used as a math sub-processor? havent found anything in the rules saying it isn’t.

thx ahead

It’s possible…and legal…but I wouldn’t do it; I’d use a different processor. If you DO use two, *clearly *mark which one is the co-processor. And I mean clearly.

As I said, I would use something else as a co-processor. It’s a little safer rules-wise.

Wouldn’t doing that add 450 dollars to your BOM too? And no individual item is supposed to cost over 400.

<R23> The total cost of all non-Kit Of Parts items shall not exceed $3,500.00 USD. No individual
item shall have a value of over $400.00. The total cost of COMPONENTS purchased in bulk
may exceed $400.00 USD as long as the cost of an individual COMPONENT does not
exceed $400.00.

Would it count as a KOP item even though it is being used in addition to the one included in the KOP? I believe it would be tallied at $450 (cost new from IFI) and illegal due to R23.

<R23> The total cost of all non-Kit Of Parts items shall not exceed $3,500.00 USD. No individual
item shall have a value of over $400.00. The total cost of COMPONENTS purchased in bulk
may exceed $400.00 USD as long as the cost of an individual COMPONENT does not
exceed $400.00.

It seems like it would still be tallied at 450 dollars. If you buy another kitbot frame to use on your robot then you still add that to your bom.

IMHO the second one is a non-KOP item, because the KOP came with only one. And, as a co-processor you can do a lot better for far less money - a Basic Stamp comes to mind…

I’ll agree that is doesn’t pass the $400 limit. I can understand the desire to use it since you’re familiar with the language already etc. So you might want to remember that VEX controllers are very similar and a rather lot cheaper…

The RC’s we get from IFI aren’t great for doing a lot of math… an RC is just 2 small PIC18F8722’s, one of which you program and the other just handshakes and trades data with the other and shuts it down when it gets irritated. Both of these processors and 10MIPS (million instructions per second) with no floating-point units or 16-bit (or greater) math bing done per instruction cycle. On top of that, you lose a lot of efficiency because of constant comms with the master processor, and RC-RC communication is tough to do quickly.

Depending on your amount of free time, knowledge, and general nerdiness, you might be able to get much, much faster math done on either a custom built processor board (really really hard). Or, you can do what a couple of teams are doing and buy one of those shuttle computers with a 1.6Ghz or slower processor and run a little VB app that uses the serial or parallel port to communicate with your RC. With one of those, you can get many many orders of magnitude faster, and you’ll be able to do floating point ops and trig functions without getting bitten by the watchdog or using lookup tables.

You should be able to get one of those small computers for less than $250. I believe there are a few threads on this topic.

A VEX RC, however, would be legal.

Jason

I’ve seen teams use Vex controllers before that were just pre-processors for the sensors. I did it once before with two vex controllers and it’s not that hard but then again it was kinda useless.

i’ll probably look into it after this season (unless i have more time, which i doubt), but you could buy a PIC processor, and just wire it up to unused digital i/o ports and do simple serial or parallel communication. you could probably do it with $10 of parts, including the PIC.

For the last few years, we have had at least one student designed PIC based processor on each robot. We still have not found a good way to communicate complex data back to the RC.

We use the external processors to do things faster (or in more quantity) than would be practical in the RC. For example, in Aim High, we had a pic that monitored our shooter wheel speeds. It could precisely calulate rpm once a revolution for both motors. The original plan was to feed back a speed value to the RC to let it adjust the power. As it turned out, that didn’t work, so we limited the feedback to two digital I/Os for each motor that the PIC was monitoring. The digital I/Os were interpreted as:
00 - too slow
01 - just right
10 - too fast

The RC then ran a control loop to keep the speed in the just right/too fast area.

This sort of a project is not too dificult and provides an excelent opportunity for students to learn more about programming and the hardware software interaction at the microprocessor interface level.