![]() |
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 |
Re: 2 robot controllers legal?
Quote:
As I said, I would use something else as a co-processor. It's a little safer rules-wise. |
Re: 2 robot controllers legal?
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. |
Re: 2 robot controllers legal?
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.
Quote:
|
Re: 2 robot controllers legal?
Quote:
|
Re: 2 robot controllers legal?
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...
|
Re: 2 robot controllers legal?
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....
|
Re: 2 robot controllers legal?
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. |
Re: 2 robot controllers legal?
A VEX RC, however, would be legal.
Jason |
Re: 2 robot controllers legal?
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.
|
Re: 2 robot controllers legal?
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.
|
Re: 2 robot controllers legal?
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. |
| All times are GMT -5. The time now is 07:42. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi