cRio external 'co-processor' options
 

What options are there for interfacing other devices with the cRio? From the photos I see two Ethernet ports and a serial port. Obviously there are the Digitial I/O ports, but I'm looking to transfer a significant amount of data.

One of the Ethernet ports has to be used for the access point, so I suspect that the rules will be strict about that configuration.

The other Ethernet port is supposed to be used for an Ethernet camera, but would it be possible to put an Ethernet switch on that port and attach another device to the switch as well? Or, are there restrictions (software, hardware, or rules) in place to prevent this type of configuration?

Is the serial port accessible from user code?


I realize that rules and software may change before the season starts, but I'm working on a project and I'd like to get an idea of the options before I proceed any further. I'm hoping that some of the beta test teams will be able to provide me with some answers.

Re: cRio external 'co-processor' options
 

I can't tell you much about the rules, but I can tell you that the serial port is accessible.

Greg McKaskle

Re: cRio external 'co-processor' options
 

Thanks, that what I needed to know.

Re: cRio external 'co-processor' options
 

I think we are all curious - what is this co-processor you are adding?

Re: cRio external 'co-processor' options
 

There is also an I2C port.

Re: cRio external 'co-processor' options
 

Past rules will not necessarily apply to what will be allowed in 2009, but "co-processors" and other custom circuits were allowed on robots, subject to cost limits ($400). There were other restrictions as well: no custom PWM circuits to Victor inputs, no wireless communications, no connections to radio or tether ports on the RC, etc.

There are some interesting co-processor options out there; just check out the choices at Tern, Inc.

But, before I'd worry about how to interface external processing capability, I'd want to understand what the cRIO system can do itself!

Re: cRio external 'co-processor' options
 

I don't want to talk about the details, yet. I will say I'm not really going to be doing any processing that requires an external processor, but I now have a functional prototype and I'm concerned about the time involved porting and debugging it on another platform.

If I have time once the new system ships I will probably port it over, but I want to plan for the very likely scenario where I don't have that much time.

My current prototype is using a system which is far less than $400, and I'm not concerned that the cRio couldn't handle what I'm doing. I don't believe the time involved to port my current project to the cRio is worth the effort if I can simply interface with my existing hardware using a relativity simple protocol.

Didn't know that, thanks.

Re: cRio external 'co-processor' options
 

How much data do you have to transfer? If it's just motor values (since your co-processor mustn't control motors directly, correct?), then serial should be adequate.

Re: cRio external 'co-processor' options
 

I've been testing with serial between my prototype and a PC, and that seems to be adequate.

Re: cRio external 'co-processor' options
 

From what we saw at the demo (We're not a beta team) the Ethernet hardware is quite capable of networking to another system (co-prossessor). I did not see any DHCP controller software (Greg ... is the cRIO under VxWorks capable of being a DHCP server?) so the addressing may be in the FPGA (in which you wont be able to use the ethernet port for further networking). Since the rules haven't come out, no one can answer that, however if the hardware/software is capable it is unlikely that they will restrict coprossessors. They will, most likely, ban other transmitters (such as 900 MHz cameras) though.

Other data connections:
I2C
Serial
DIO
All are accessable but you'll most likely have to write your own (or modify) driver to interpret the data.

Last year the rules were no single electronics device over $400. There are a number of off the shelf devices that conform to that. Last year we used a $250 ARM gumstix coprossessor through the onboard serial (program?) port to interpret SONAR signals.

Good luck.

Re: cRio external 'co-processor' options
 

I know a DHCP server isn't running, and I don't think one is on the controller that simply needs to be enabled. The enet expandability depends directly on whether or not a switch, hub, or other enet expansion device will be allowed. Currently there are two ports, one for radio, and the other used by the camera, if you use it.

For future years, another expansion bus is CAN.

Greg McKaskle

Re: cRio external 'co-processor' options
 

DHCP is only used with TCP/IP, which can be used over Ethernet, but other Protocols also work over Ethernet.

I like CAN, I use it every day at work....

Re: cRio external 'co-processor' options
 

The FPGA has nothing to do with the Ethernet ports or the serial port. Those are connected directly to the PPC processor that will be running your code. As Greg said, no DHCP.

The FPGA provides access to a dedicated I2C engine for each digital module. It also has a buffered (512 word send and 512 word receive) SPI interface. You can also use the DIO directly.

-Joe

Re: cRio external 'co-processor' options
 

Why are people concerned about not having a DHCP server? DHCP is not an integral part of the TCP/IP stack, and can be bypassed simply by configuring a static IP address. DHCP is only used to allow more flexibility in network topology.

My assumption would be that the cRio's access point NIC would be a DHCP client and the cRio's second NIC and the camera would have static, but configurable, IP addresses. Can any of the beta teams confirm this?

Re: cRio external 'co-processor' options
 

Actually, both NICs are given static IPs. The access-point-facing IP is 10.xx.yy.2 (where xxyy is the team number in base 10 digits), and the camera-facing IP is 192.168.0.3. I imagine there's a way to change these from the cRIO software, but I don't know how, nor can I think of a reason for bothering to do it.

Re: cRio external 'co-processor' options
 

And to elaborate further, (for beta testing at least) the other devices (like driver station and host PC) are also given fixed IP's based on team number.
I put the attached pic together for our team.

The downside to this is that it limits us to only 25499 teams.

Re: cRio external 'co-processor' options
 

Thanks.

Re: cRio external 'co-processor' options
 

Three words: Downloading the Internet.

(Just kidding)

But yeah, this is very nice. One possible tweak that someone might think about is designing a Bluetooth interface, then having the robot connect through someone's laptop and beam streaming video from the new cameras to a video stream server. Make it happen!

EDIT: Anyone know any good whitepapers on the digital stream format the FIRST cameras send out?

Re: cRio external 'co-processor' options
 

It appears from the demo videos that they use a standard Ethernet camera, and that it is possible to stream the data over the Wireless connection.

Usually Ethernet cameras use very simple protocols, often just a stream of JPEGs, but there doesn't seem to be very much standardization in this area.

Coding4Fun did an article about streaming Ethernet camera data, and doing motion detection a while ago.

Re: cRio external 'co-processor' options
 

Here is a neat Linksys Linux robot that uses an ethernet camera. Maybe you can learn something from his project.

http://www.jbprojects.net/projects/wifirobot/

Re: cRio external 'co-processor' options
 

My question with the cRio, are the teams allowed to write code directly for the FPGA? Verilog is nifty, and being able to accomplish certain tasks very fast could be win-win.

Also, where would I be able to find more information? As an Alumni I hear bits and pieces from my team, but not nearly enough and this year it looks like the control board alone is going to be pretty awesome.

Also, if someone is doing motion based stuff, take a look at OpenCV from Intel. That is some cool code :P

Re: cRio external 'co-processor' options
 

First, for more info...http://first.wpi.edu/FRC/csoverview.html

Also, my understanding is that teams will NOT be able to program the FPGA directly, as that is where FIRST is storing their "master code" for the system, similar to the master CPU in the older IFI system that handled the disable codes from the field, etc.