cRio external 'co-processor' options

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

[PhilBot]

Originally Posted by Pat Fairbank

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

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.

[EHaskins]

Originally Posted by Pat Fairbank

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.

Originally Posted by PhilBot

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.

Thanks.

[ShotgunNinja]

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?

[EHaskins]

Originally Posted by ShotgunNinja

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?

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.

[keen101]

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/

[X-Istence]

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

[Nate Smith]

Originally Posted by X-Istence

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

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.