Image processing on the driver station laptop

[cbf]

Is there anything in the rules preventing us from doing our rectangle recognition on the driver station laptop rather the cRIO? Even in Hybrid mode?

Just want to make sure..

[Alan Anderson]

I don't see anything in the rules that prevents processing the camera image on the computer running the Driver Station.

[AndyB871]

I think it's legal as long as you keep in mind the ports that are available on the field.

If you look at one of the more recent team updates:

The Arena
The Player Stations

Once plugged in to the Field Management System via the Ethernet cable provided, the ports that the teams will be able to access on the playing field are as follows:

– TCP 1180: This port is typically used for camera data from the cRIO to the DS when the camera is connected to port 2 on the cRIO. This port is bidirectional on the field.

– TCP 1735: SmartDashboard, bidirectional

– UDP 1130: Dashboard-to-Robot control data, directional

– UDP 1140: Robot-to-Dashboard status data, directional

– HTTP 80: Camera connected via switch on the robot, bidirectional

– HTTP 443: Camera connected via switch on the robot, bidirectional



All these ports are open on the playing field, so a team can use them 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 port 2).

We took this to mean that we could freely use ports 1130 and 1140 to communicate data via UDP from our Dashboard to our robot and back.

In fact, this is how we're implementing our vision tracking algorithms right now. Our PC receives the Image, processes it and generates a list of targets, then that list of targets is prioritized and sent back to the robot for tracking.

-Andy

[moc601]

I've been looking for a definitive rule in the manual and other docs without success.

Are the Driver Station and Dashboard permitted to be separate laptops?
Are two laptops permitted to be used during the contest?

I'm wondering how a team would make use of the web services interface otherwise.

[moc601]

Quick followup to refine my question.

I've read about the $400 component limit that COTS laptops appear to be subject to.
The location of the laptop would be in the pit, next to the provided netbook drivers station. I seem to remember some teams having two laptops in the pit with them in our rookie year 2011.

[AndyB871]

a definitive rule

|-> See my post above about port #'s I think that's pretty definitive at least on the network level.

Are the Driver Station and Dashboard permitted to be separate laptops?
Are two laptops permitted to be used during the contest

?
|-> That's a good question. Maybe you should make a post at a higher level in the forum about this. I'd guess that it's okay, because you're still restricted as to what ports you can use and how the robot must be controlled, etc.

At the same time however, It's possible that the Field system is designed to disallow traffic from any IP address not 10.xx.yy.6 , in which case the second laptop (whichever one does not have the *.6) wouldn't be able to communicate, that's just me throwing a possibility out there. I've got no way to back that one up.

Edit:
You're not restricted to any number of laptops in the pit. You're only restricted on the playing field, anyone please correct me if I'm wrong there. I sure hope not.... we bought ourselves a ~$350 laptop with a nice big display to use for our DS/Dashboard

[moc601]

Edit:
You're not restricted to any number of laptops in the pit. You're only restricted on the playing field, anyone please correct me if I'm wrong there. I sure hope not.... we bought ourselves a ~$350 laptop with a nice big display to use for our DS/Dashboard[/quote]

Just to be painfully clear
So if we're in the pit with the KOP netbook and also a COTS $350 laptop we are not going to commit a foul on that basis alone.

[AndyB871]

No. You're fine in the pit; I don't know if that is OK on the field though.

[moc601]

Thanks!

[sjspry]

The rule about the usable ports should be last years. This year, there seems to be no restrictions.

Also note that last year's enumerated ports weren't necessarily the only ones open on the field in practice, but I wouldn't've relied on it.

[WizenedEE]

Originally Posted by sjspry

The rule about the usable ports should be last years. This year, there seems to be no restrictions.

oh? http://frc-manual.usfirst.org/viewSingleItemMap/694

Make sure to update your manual for the team updates.

[AndyB871]

cbf -
Yep, we're using labView.

The robot code doesn't have to distinguish anything here. The Driver station packets are being transmitted over a different port (1165 I believe). I'm not sure how familiar you are with networking but since they're different ports you can think of them as disjoint channels. A UDP receive on port 1130 will never see a packet from port 1165 and vice versa (sp? I never get that one right)

So in a nutshell, we just open a new socket on 1130 on the Dashboard, and pack the data and ship it out to the robot IP address; and in the Robot code We create a new socket to listen for data on 1130, and do a UDP receive followed by some error checking and an unflatten.

-Andy

[Chris Hibner]

I ran a test using UDP two days ago and I wasn't very happy with the results - perhaps one of the NI guys could say if what I saw is typical or not.

I set up a test program to communicate via UDP from a laptop to the cRIO. The laptop was set up to countinuously count up and the value of the counter was passed to the cRIO via UDP. I read the received counter value while in debugging mode in LabVIEW.

The issue is this: if the data wasn't immediately received on the cRIO, the data was queued and was then read eventually in the original order that it was sent. For example, the counter on the laptop would be counting through 200 and the received packet on the cRIO would be paused at 180 for a second. Then, when the cRIO started receiving packets again, it would start counting up again from 181 even though the laptop was now on 220. For a real-time system, I would expect that all missed/delayed packets would be ignored and the most recent packet would be read.

This is a real problem if I'm trying to receive target aim and distance data from the image processing on a remote computer. I have no idea how much delay there is from what I'm receiving to when it was sent. If some delay occurs, I could be off by X seconds for the remainder of the match.

I ran the same experiment with TCP and did not see this issue.

[cbf]

AndyB871 --

Yes, I'm very familiar with networking. (I'm a mentor, not a student.) I had assumed since the rules said port 1130 was the only one available for Operator station to Robot communication that they meant it and therefore the driver station must use that port. (I tried reading the DrvrStn COM vi, but the important stuff all seems to be buried in the opaque NETCOM library.)

Having that port available for our own purpose will make this much easier. I was getting ready to Wireshark this to see what was going on, so thanks for saving me the trouble!

Chris --

Yes, you cannot assume that subsequent UDP packets will simply replace earlier UDP packets that have not yet been read. Most operating system network stacks (and I presume that would include VxWorks) helpfully provide a certain amount of buffering to held several packets. If your packets are really short, then the network stack will hold more of them for you!

I wouldn't switch to TCP -- that just adds more overhead. The answer is either to throttle (would require back traffic), or have your code on the cRIO flush packets to catch up.

[cbf]

In fact, this is how we're implementing our vision tracking algorithms right now. Our PC receives the Image, processes it and generates a list of targets, then that list of targets is prioritized and sent back to the robot for tracking

Andy --

Are you using Labview? It looks to me like UDP Port 1130 is the only UDP port one can definitely depend on being open from the Driver Station to the robot. If that's the case and you're sending your own custom packet with the list of targets, how do you get the robot code to distinguish it from the normal driver station control packet?

If you're not using UDP Port 1130, how can we be sure that any other port will actually be open at the competition?