Using Vex Brain as FRC Coprocessor

[Gdeaver]

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]

Originally Posted by Gdeaver

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]

Originally Posted by Qbranch

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]

Originally Posted by Gdeaver

If you needed fast floating point math. If you wanted to play with machine vision.

Originally Posted by dlavery

Hmmmmm...

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 )

[Qbranch]

Originally Posted by Donut

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).

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? )

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

[Rickertsen2]

Originally Posted by Qbranch

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).

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

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

[Gdeaver]

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]

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 (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.]

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.

[Qbranch]

Originally Posted by Adam Y.

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.

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)

[Ken Leedle]

Originally Posted by Adam Y.

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.

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.