Re: Regarding The cRio
 

I don't think putting a computer on teh robot will go well with the teammates... At least for the other boards, it doesnt look anything like a computer, but it is

Re: Regarding The cRio
 

Be very careful. I've heard that the motor in the hard drive is considered a motor, and is therefore not allowed to be used on the robot since it didn't come in the kit. Same goes for the fan inside that computer, if there is one. So, you'd need something with a SSD, and that is fanless.

On a completely separate note, you can use USB to attach another simpler board to do IO, if you are having trouble finding a powerful board to use that has good IO. Food for the thought to get you thinking.

Re: Regarding The cRio
 

yes, I have the cable to connect the board to my computer for terminal IO, The plan was to create a live usb on either an XUbuntu or windows machine with the Debian (or Ubuntu) i386 image on it. then the instructions I have get fuzzy. I either boot my computer with the live usb, configure the SSH for terminal access, and boot the roboard with it and install the kernel package on the roboard, or I do the same thing but install the kernel before I boot the roboard with it, or I just make the live USB, boot the Roboard and some how do every thing from there with the remote terminal interface. My main issue is the person on my team who is attempting to help me thinks that I know more than I do.

Re: Regarding The cRio
 

What I'd do is create a bootable (livecd) image and put it on the USB stick. Your co-processor board would boot up the "livecd" image and start running. You would put a script to run your user code in /etc/rc.local (that script runs after everything is up.) You do have an issue that it takes some time to boot up completely. It "should" be less than the cRio, but your mileage may vary.

Your user code would be the program that runs to do your image processing / sensor processing / etc. The nice thing is that you could write that code in anything (C, Perl, Java, Awk, Cobol, etc.)

You could write on the Host PC and then ssh file transfer down to the coprocessor board. It then becomes the same "code, download, restart, test" cycle you do with the cRio.

Remember Google is your friend. Somebody, someplace at sometime has done something very, very close to what you want to do and has written it up. So don't be afraid to us Google to search it out.

Re: Regarding The cRio
 

My mentor pretty much told me that a second PC will not be needed, since the crio is pretty powerful as it is, but I am still keeping the PC idea in mind, the problem is that the usb idea is "fragile". the USB can pop out mid competition, so thats dead. I was thinking of just using a SS drive (no moving parts) instead of HDD, so it can't get messed up as bad

Re: Regarding The cRio
 

It would not be worth the added power. The cRio has so much power, most teams do not get anywhere near fully utilizing the cRio. Plus, using two cRios would be extremely restrictive on the rest of your robot (cost wise).

Re: Regarding The cRio
 

Baha, image detection algorithms push the Crio to its limits as is. Anything more advanced is simply impossible.
Right now, I notice the severe lag from doing two or more circle detections per cycle, and this only adds up to about 10-15 times per second.
Does anyone think asking FIRST to ease this restriction concerning BIOS batteries for next year would be option?

Re: Regarding The cRio
 

;) They don't have to know what they don't know... Just enclose it in a regular pc case


edit: Or even more bad $@#$@#$@#, use 1 or more ps3's on board, they are like $300 each, so its legal. Just use a enternet hub and boot up linux on it... BAD $@#$@#$@#!!

Re: Regarding The cRio
 

That's a very neat idea, but really, the Cell is just a CPU on steroids. And thus, it's a CPU which can't compare to a GPU's performance, even though it's easier to code. It's like trying to compare anything to infinity.

Unfortunately, a PC case would probably be a big weight and shock-resistance hassle. These components already have to withstand huge Gforce shocks, even with bumpers. Kudos for the idea, though. That'd be interesting, seeing my neon-blue case on a robot.

Re: Regarding The cRio
 

Actually coded right, the Cell processor is way more useful than the PS3 RSX (the gpu), it was the only way that Uncharted 2 looked so good, they took some of the GPU work to the cell

http://www.ibm.com/developerworks/po...pa-linuxps3-1/

Re: Regarding The cRio
 

Don't update your Ps3 then. Linux support just got dropped.

Re: Regarding The cRio
 

;) Im aware, gah no PSN for me now

Re: Regarding The cRio
 

Why do you interpret it this way?

This part does not disallow the use of a second cRIO, it simply says that 1 must be used on the robot. If two are used on the robot then one is being used on the robot. If the rule said 1 and only 1 cRIO must be used then I would agree with this interpretation.

This also does not specifically prohibit using a second cRIO as a co-processor, If one cRIO is connected to all of the sensors and actuators (with the possible exception of the camera) and the other is connected to the cRIO via the second Ethernet port, and used only to interpret data sent through the ethernet port or gathered by the camera or another sensor attached to the second cRIO's second Ethernet port then this set up would not violate the quoted rule.

Obviously the best way to handle this would be to ask Q&A but If I were to read the rule indicated by the check list:

I would see nothing wrong with using a second cRIO (as in this setup it would not be a controller, just a processor).

It worries me some times that inspectors a left with a lot of room to make judgment calls (all though I understand it is necessary). I could easily show up to a competition with the set up I described (assuming it fit all of the cost guidelines) having never asked Q&A because my set up seems to be clearly allowed, only to have atleast two inspectors (Fletch and another one mentioned in this thread) who clearly have a difference in opinion to what the rule means, largely (in my opinion) based on the lack of differentiation by the inspectors between a controller and a co-processor.

Re: Regarding The cRio
 

Oh my goodness! I forgot the fact that the cRIO has a serial port that can be used to do this stuff. If you use an absurdly high baud rate (with a heavy dose of custom code, of course) and hook up a crio to, say, an arduino over serial (hook up the tx and rx to digital ports 0 and 1), you could have a co-processor work. I'm going to experiment with this and i will keep you posted.

Re: Regarding The cRio
 

The max for arduino is 9600 baud rate