cRio external 'co-processor' options

[EHaskins]

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.

[Greg McKaskle]

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

Greg McKaskle

[EHaskins]

Originally Posted by Greg McKaskle

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

Greg McKaskle

Thanks, that what I needed to know.

[EricVanWyk]

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

[Joe Ross]

There is also an I2C port.

[David Brinza]

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!

[EHaskins]

Originally Posted by EricVanWyk

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

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.

Originally Posted by David Brinza

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).
...
But, before I'd worry about how to interface external processing capability, I'd want to understand what the cRIO system can do itself!

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.

Originally Posted by Joe Ross

There is also an I2C port.

Didn't know that, thanks.

[tdlrali]

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.

[EHaskins]

Originally Posted by tdlrali

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.

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

[Daniel_LaFleur]

Originally Posted by EHaskins

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.

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.

[Greg McKaskle]

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

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

[MarkO]

Originally Posted by Greg McKaskle

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

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

[Joe Hershberger]

Originally Posted by Daniel_LaFleur

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.

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.

Originally Posted by Daniel_LaFleur

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.

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

[EHaskins]

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?

[Pat Fairbank]

Originally Posted by EHaskins

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?

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.