Robot Communication and External CPUs during Competitions

[arushshah1]

Our team is doing vision processing for the first time, using an Nvidia Jetson TX1 to do our vision processing. Currently, we are connecting the camera and the Jetson to the network that we're setting up using the radio in our lab. To run the Python OpenCV script on the Jetson, I simply SSH into the Jetson terminal from the driver station and run it before starting the robot program.

I'm a little unsure of how the network is set up at the field during competitions, and I know that radios cannot setup their home network on the field. I was wondering if I will still be able to SSH into the Jetson using its static IP and if I can use the same IP of the camera as I did when it was connected to the radio's network. Also, is it legal to run a separate process such as SSH on the driver station or does the robot code need to start the Python script on the Jetson automatically?

[cad321]

Why wouldn't you want to either start the program on startup (whenever power is on) or to start when a command is sent over network tables?

[rich2202]

Originally Posted by arushshah1

I was wondering if I will still be able to SSH into the Jetson using its static IP and

You should be able to.

if I can use the same IP of the camera as I did when it was connected to the radio's network.

Assuming the IP Address is 10.XX.YY.xx, where XX.YY is your team number, then yes.

Also, is it legal to run a separate process such as SSH on the driver station

You can run whatever you want on the Driver Station. However ...

If you have problems with your DS on the field, they may give you the Stock driver station to use. That will not have your other programs loaded onto it.

If you are planning for all contingencies, don't assume you can run SSH from the Driver Station. Have the Jetson automatically start running the program upon bootup.

[Kevin Sevcik]

Originally Posted by R65

Communication between the ROBOT and the OPERATOR CONSOLE is restricted as follows:
A. Network Ports:
UDP/TCP 1180-1190: Camera data from the roboRIO to the Driver Station (DS) when the camera is connected the roboRIO via USB, bi-directional.
TCP 1735: SmartDashboard, bi-directional
UDP 1130: Dashboard-to-ROBOT control data, uni-directional
UDP 1140: ROBOT-to-Dashboard status data, uni-directional
HTTP 80: Camera connected via switch on the ROBOT, bi-directional
HTTP 443: Camera connected via switch on the ROBOT, bi-directional
UDP/TCP 554: Real-Time Streaming Protocol for h.264 camera streaming, bi-directional
UDP/TCP 5800-5810: Team Use, bi-directional
Teams may use these ports as they wish if they do not employ them as outlined above (i.e. TCP 1180 can be used to pass data back and forth between the ROBOT and the DS if the Team chooses not to use the camera on USB).
B. Bandwidth: no more than 7 Mbits/second.

SSH isn't listed as one of the allowed ports, so you'd have to move your SSH port to one of the above listed, at the least. Granted, the restriction is listed as to the robot, but I'm assuming it's a filter on the access point to robot bridge connection.

[arushshah1]

How can I run a program on startup?

[Justin Buist]

Originally Posted by arushshah1

How can I run a program on startup?

Well, the Jetson eLinux (which I've never used) is basically Ubuntu 14.04 (which I do use) so I'd guess add it to the /etc/rc.local script before it reaches the "exit 0" line.

/path/to/program.py &

The ampersand disconnects it from the terminal and lets it run the background.

[bobbysq]

Originally Posted by Kevin Sevcik

SSH isn't listed as one of the allowed ports, so you'd have to move your SSH port to one of the above listed, at the least. Granted, the restriction is listed as to the robot, but I'm assuming it's a filter on the access point to robot bridge connection.

Unless he's using SSH while connected to the FMS, he should be fine since you have to plug in with Ethernet to connect to the robot at events anyway.

[rich2202]

Originally Posted by bobbysq

Unless he's using SSH while connected to the FMS, he should be fine since you have to plug in with Ethernet to connect to the robot at events anyway.

Most teams place their robot on the field in a powered off state. Needing to tether while powering on is not advisable.

[bobbysq]

Originally Posted by rich2202

Most teams place their robot on the field in a powered off state. Needing to tether while powering on is not advisable.

I didn't even notice this was on the field. I thought this was just for general maintenance. In that case, I would go with everyone else and recommend an autorun script and a static IP.

[scca229]

Originally Posted by Kevin Sevcik

SSH isn't listed as one of the allowed ports, so you'd have to move your SSH port to one of the above listed, at the least. Granted, the restriction is listed as to the robot, but I'm assuming it's a filter on the access point to robot bridge connection.

That filter is on any traffic that is going from the radio's wifi to the driver station ethernet port and is policed by the FMS. The radio's ethernet ports do not have this restriction, so communication internally to the robot is not affected, nor anything internally to the driver station.

Originally Posted by rich2202

Most teams place their robot on the field in a powered off state. Needing to tether while powering on is not advisable.

Definitely not advisable as it won't be allowed once the robot is on the field excepting an official Field Timeout if the robot is in back-to-back matches (immediate replay or in Playoffs).