PDA

View Full Version : Using Vex Brain as FRC Coprocessor


Tom Bottiglieri
04-17-2006, 01:37 PM
Vex Controller: $150

Co-processor anyone? I'm sure you all know how to program for it!

Richard Wallace
04-17-2006, 01:54 PM
Vex Controller: $150

Co-processor anyone? I'm sure you all know how to program for it!IFI is a VENDOR => VEX Controller is a COTS electronic component => compliant(<R45>)=.TRUE.

$150 < $200 => compliant(<R49>)=.TRUE.

Don't know about compliance with <R51>. Can you run a VEX controller from a 12V battery? Specs say 7.2V, and draw is 62mA for the controller and receiver. Since the receiver can't be used, maybe the draw is a little less.

lukevanoort
04-17-2006, 01:59 PM
$150 < $200 => compliant(<R49>)=.TRUE.

Don't know about compliance with <R51>. Can you run a VEX controller from a 12V battery? Specs say 7.2V, and draw is 62mA for the controller and receiver. Since the receiver can't be used, maybe the draw is a little less.
Could you power it through the pwm outputs on the RC like the servos?

Tom Bottiglieri
04-17-2006, 02:16 PM
Woah, my post got merged into a new thread. (I guess someone was expecting this topic to come up?)

Interfacing to the Vex controller shouldn't be hard at all. I haven't been able to play with my kit much since I bought it, but I have been able to interface the cmucam with the vex programming module and a male to male 9 pin serial cable. This setup could probably be become less bulky, as I'm pretty sure the only thing in the programming module box is an TTL->RSR232 converter chip like the one we get in the FRC kop.

Anyway, code to run this coproccesor shouldn't be hard at all. If theres enough support, and Mr. Watson permits me to use his serial driver (what a beautiful piece of software that is..), I should be able to get something released soon.

UlTiMaTeP
04-17-2006, 02:42 PM
You need to build a 12v to 7.2 psu's which is fairly easy, the instructions are on IFI's white papers. Also nothing stops you from pulling a tap off of the backup battery supply.

wsansewjs
04-17-2006, 02:45 PM
Oh man, imagine the 'dual core' processing in our robots everywhere. Maybe this robot can do the game procedures while other can do a smiley or noise making part during the game at the audience. Only time will tell!

-WJS

UlTiMaTeP
04-17-2006, 02:48 PM
I really like this idea of using Vex controllers :)

Richard Wallace
04-17-2006, 02:49 PM
You need to build a 12v to 7.2 psu's which is fairly easy, the instructions are on IFI's white papers. Also nothing stops you from pulling a tap off of the backup battery supply.Thanks for referencing the IFI white paper on powering the controller. [I think you mean this circuit (http://www.ifirobotics.com/docs/first-backup-charger.pdf) which uses an LM317T regulator?]

Actually, as written for 2006, <R51> would stop you from pulling a tap off of the backup battery supply.

UlTiMaTeP
04-17-2006, 03:13 PM
I was actually planning on building a few of these for purchase next season. It took me quite a long time to track down all the parts and most companies required me to spend 50$ min order.

Rickertsen2
04-17-2006, 05:04 PM
Cheaper to build your own coprocessor

Gdeaver
04-17-2006, 06:35 PM
Why do you need a coprocessor. Why would you want to spend 150$ just for a PIC coprocessor. What are you trying to do that the FRC can't handle. I could see a coprocessor if you wanted to use a sensor that was I2C or SPI. If you needed fast floating point math. If you wanted to play with machine vision. The Vex Modula would not be a good fit for these purposes. Either it's way to much $ or not powerful enough. There are several chip and carrier solutions on the market that would be easier and more cost effective.

DonRotolo
04-17-2006, 07:09 PM
Thanks for referencing the IFI white paper on powering the controller. [I think you mean this circuit (http://www.ifirobotics.com/docs/first-backup-charger.pdf) which uses an LM317T regulator?]

Actually, as written for 2006, <R51> would stop you from pulling a tap off of the backup battery supply.
I would not use that circuit to power a 7.2 volt Vex controller. You'd be far better off using the standard LM317T power circuit (like this (http://www.national.com/an/AN/AN-181.pdf)), since the quoted circuit is designed to charge a 7.2 volt battery, not replace it. All of the parts are available from Radio Shack, or Jameco, DigiKey, Mouser, etc. You definitely need a heat sink, and it should be powered from a 12 volt tap off the fuse panel.

This is a good circuit to play with in the off season. The LM-317T is a very versatile circuit and everyone would be well-served to gain some familiarity with it - including it's disadvantages (such as heat generated and relative inefficiency with high voltage drops).

Don

Qbranch
04-17-2006, 08:02 PM
My question is, why on earth do you need more processing power?

The PIC18F8722 processor runs at 40MHz, which is way faster and has way more flash than any of us could ever want. That is, of course, as long as you don't use any polling loops. (hopefully you aren't polling :ahh: ). I'm running about 9 parallel processes this year, and no signs of lag...

The processor has 8 external interrupts and several internal interrupts along with four timers, four banks flash memory, 16 channels analog to digital converter, ... :D

Just curious does anyone had any ideas what they would do with a co processor if they had one?

-Q

Donut
04-17-2006, 08:21 PM
Just curious does anyone had any ideas what they would do with a co processor if they had one?

Originally I thought of a co processor to handle 6+ sonar sensors all requiring interrupts (because then we'd have no room for encoders). Since we've found ones that wouldn't require interrupts now though, I don't think we'd really have much use for it anymore.

If you had a sensor requiring a specific interface I could still see it.

dlavery
04-17-2006, 08:43 PM
If you needed fast floating point math. If you wanted to play with machine vision.

Hmmmmm... :rolleyes:

Gdeaver
04-17-2006, 08:44 PM
6 sonar sensors? What are you going to do about all the reflections from them ? 1 sonar and a couple Sharp IR's on servos would be better. What about if other robots have sonar? Yes there is a serial sonar on the market now and it has a narrow cone of detection. The problem with the FRC is that it wasn't designed with a communications bus for coprocs or multiple intelligent sensors. The spi and i2c are not available. If in the future the complexity of First robots gets to the point where coprocs are needed then The controller is going to need a major over haul. From what I've seen most teams barely tap the power of the controller we have now.

Qbranch
04-17-2006, 08:47 PM
From what I've seen most teams barely tap the power of the controller we have now.

I agree. This year's robot is the most mathmatically complicated yet, but even now we only use a fraction of what the processor can do.

Donut
04-17-2006, 09:03 PM
I agree. This year's robot is the most mathmatically complicated yet, but even now we only use a fraction of what the processor can do.

I don't know of anyone ever having a problem with the processors. I know we ran out of code space last year (code, not variable), but with the quadrupling of the space this year we were fine (all our tracking code and everything took up about 1/3 the code space).

6 sonars was just a funny idea I was throwing around before, they'd be spaced out at 60 degree intervals on a full circle so as to allow an updated complete view of the field every half second or so.

A few sonars and Sharp sensors might be better, but I know we'd need more than 1 sonar (all the Sharp sensors have too limited a range for what I was thinking of).

I think Dave's going to give us all 3 cameras next year from that statement.

Qbranch
04-18-2006, 09:42 AM
If you needed fast floating point math. If you wanted to play with machine vision.

Hmmmmm... :rolleyes:

Machine vision is in the land of DSP processors... I don't think you could pull it off with a standard embedded processor... just capturing the pixels would probably take too long, let alone processing them. ( Taking too long to capture pixels = blurry image :ahh: )

Qbranch
04-18-2006, 09:51 AM
I don't know of anyone ever having a problem with the processors. I know we ran out of code space last year (code, not variable), but with the quadrupling of the space this year we were fine (all our tracking code and everything took up about 1/3 the code space).

6 sonars was just a funny idea I was throwing around before, they'd be spaced out at 60 degree intervals on a full circle so as to allow an updated complete view of the field every half second or so.

A few sonars and Sharp sensors might be better, but I know we'd need more than 1 sonar (all the Sharp sensors have too limited a range for what I was thinking of).

I think Dave's going to give us all 3 cameras next year from that statement.

This year's processor could most definitely handle 2 CMUcams, I think you would run out of UARTs if you had 3 cameras. Although, you could overcome this with using the ever-famous bit banging (this can be done up to around 9600 baud, yes I know its slower, but it would still give you a few updates per second). :rolleyes:

I would really like it if we did have 2 CMUcams, we could find our absolute position on the field (X,Y coords) using stereoscopic vision off the target.

It'd be nice if maybe Cognix or NI would donate their packaged vision systems and put them in the KOP... that'd be sweet to have geometric pattern matching, great image processing, and don't forget the high frame rates... (and yes I know this is extrememly expensive, but I can dream can't I? :yikes: )

So, if we were to have a co processor unit for machine vision in the KOP, I'd like it to be DSP based ...hint hint to IFI... but it would be better yet to get one of the vision systems i listed above :D

Rickertsen2
04-18-2006, 03:13 PM
This year's processor could most definitely handle 2 CMUcams, I think you would run out of UARTs if you had 3 cameras. Although, you could overcome this with using the ever-famous bit banging (this can be done up to around 9600 baud, yes I know its slower, but it would still give you a few updates per second). :rolleyes:

I would really like it if we did have 2 CMUcams, we could find our absolute position on the field (X,Y coords) using stereoscopic vision off the target.

It'd be nice if maybe Cognix or NI would donate their packaged vision systems and put them in the KOP... that'd be sweet to have geometric pattern matching, great image processing, and don't forget the high frame rates...

So, if we were to have a co processor unit for machine vision in the KOP, I'd like it to be DSP based ...hint hint to IFI... but it would be better yet to get one of the vision systems i listed above :D

That would be awesome but also the most expensive item in the entire KOP. Far more expensive than even the RC

Gdeaver
04-18-2006, 05:21 PM
Most machine vision systems rquire a very controled setting to work. I dobt we would have any meaningful data by placing these systems on a robot. However 2 cmu's might work.

Mike
04-18-2006, 08:26 PM
I know using a Vex as a co-proc would be cool and all, but I think it's wayyy overkill. You can get a top of the line AVR ATMega2561 (http://atmel.com/dyn/resources/prod_documents/doc2549.pdf) (pdf warning) for a mere 10% of the price of a vex controller ($16.99 at Digikey). Lets compare the specs.

Vex:

Chip: Microchip PICmicroŽ PIC18F8520
Speed: 10 MIPS
I/O: 16 10 bit ADC
Program space: 32Kb
Programming language: PIC C (Not totally ANSI)
AVR:

Chip: AVR ATMega2561
Speed: 16 MIPS at 16MHz
I/O: 16 channel 10 bit ADC, total of 86 programmable IO lines
Program space: 256Kb
Programming language: avr-gcc (AFAIK ANSI)
AVRs have the advantage in every category. Spending an extra $130 to get a fraction of the benefits... nah.

Adam Y.
04-18-2006, 09:02 PM
AVR:

* Chip: AVR ATMega2561
* Speed: 16 MIPS at 16MHz
* I/O: 16 channel 10 bit ADC, total of 86 programmable IO lines
* Program space: 256Kb
* Programming language: avr-gcc (AFAIK ANSI)

AVRs have the advantage in every category. Spending an extra $130 to get a fraction of the benefits... nah.
No they don't. In fact by introducing a microcontroller like the AVR you open about 50 other cans of worms which would probably make the price point about even with vex. The most annoying of which would have to be soldering it to something. Look at the PICs that are controlling your robot this year. Now imagine trying to solder it. :ahh:

Qbranch
04-18-2006, 09:21 PM
No they don't. In fact by introducing a microcontroller like the AVR you open about 50 other cans of worms which would probably make the price point about even with vex. The most annoying of which would have to be soldering it to something. Look at the PICs that are controlling your robot this year. Now imagine trying to solder it. :ahh:

If you REALLY REALLY still want a co-processor and you REALLY REALLY wont used a pre-packaged micro (i.e. VEX controller):

Just use the PIC18F8722 development board. Or better yet, go for a dsPIC or a Freescale Coldfire processor development board if you really want a serious co processor.

The dev. boards have the processors pre soldered, have a power supply, crystal, and have the pins brought out to an array of plated through holes. Also, most include the plugs for connecting your ICD or ICE, your power connection, as well as a ready-to-go DB9 connector to one of the uarts on the processor.

Just make sure you heed Adam Y.'s warning: you are opening a whole other can of worms. You'll have to make driver circuits all the output lines that you want to use. You'll also probably want to protect your input lines from ESD in some fashion, and you'll need to write a communications protocol to talk between the two processors, and ... (list continues) :ahh:

Ken Leedle
04-18-2006, 09:36 PM
The most annoying of which would have to be soldering it to something. Look at the PICs that are controlling your robot this year. Now imagine trying to solder it. :ahh:

Not so fast. http://www.infidigm.net/articles/solder/
This is a very effective means of hand soldering 80 pin TQFP chips like the 18F8520. I have used it successfully on 3 boards so far. Check it out with a microscope before you power the board on though.

I made a IR interrupter for the ball sucker upper on our robot using a PIC18F88. It only produced a square wave, but my mentors wanted to see how to make a PCB using toner from a laser printer. It worked very well, but this could easily have been done using a COTS sensor and the RC. (I also needed to brush up on my assembly).

I agree that it would be difficult to communicate with a coprocessor because you do not have access to the RC's SPI or I^2C and you need the USART for the video camera.