Is TCP communication allowed in-game?

[Lalaland1125]

Our team is planning to process images on the Classmate. Our plan is to simply open a socket on the classmate on a high number port and simply push data back and forth using TCP. This obviously works right now in testing.

My question is: Can we do this during competition? Are teams allowed to communicate with their robot from a background task on the Classmate over TCP on a high number port?

(I know there will be speed issues due to network congestion etc, during the competition).

[bdbayes]

See the rule below.

[R53]
Connections to the cRIO Ethernet ports must be compliant with the following parameters:
The DAP-1522 wireless bridge is connected to the cRIO Ethernet port 1 (either directly or via a CAT5 Ethernet pigtail).
Ethernet-connected COTS devices or custom circuits may connect to any remaining Ethernet ports; however, these devices may not transmit or receive UDP packets using ports 1100-1200 except for ports 1130 and 1140.

[~Cory~]

We are also persuing this method. However, one must be VERY careful as to not cause excessive bandwidth/other bottleneck issues because the fms people will complain.

In previous years they had a screen that shows network data for each robot and a log so no funny business::ouch::

[Lalaland1125]

So, it seems like there are two main rules:

1. Do not use those port numbers in the range 1100-1200.

2. Try not to act like you are running a Denial of Service attack on the network.

[ratdude747]

you could use the camera direct to the classmate/laptop last year via a special labview .vi for the dashboard (I have a copy if anybody wants it to play with). Last I checked they still are using the 4 port AP's on the bot (only way to use them with the 4 slot crio), so if you connect the camera there, you can view the camera from the dash via the special VI.

I think that is legal... that looks to be the same rule as used in 2011.

edit- attached the .vi

[Joe Ross]

you could use the camera direct to the classmate/laptop last year via a special labview .vi for the dashboard (I have a copy if anybody wants it to play with).
edit- attached the .vi

This is included by default this year.

[shuhao]

How are you getting the TCP comm link to work?

I'm currently unable to find the networking API from java..

[ratdude747]

This is included by default this year.

cool... since I am no longer actively involved with a team this year, I didn't know. Sorry about that.

[Lalaland1125]

How are you getting the TCP comm link to work?

I'm currently unable to find the networking API from java..



http://ideone.com/9dM5E
That's our code as of roughly now(I think the only change was that the robot does not support UTF, so we just switched that to ASCII or something).

javax.microedition.io is where the magic is.

If you want I can give you our server-side code, but it's just standard socket opening and accepting a connection(in C++ that is).

[shuhao]

http://ideone.com/9dM5E
That's our code as of roughly now(I think the only change was that the robot does not support UTF, so we just switched that to ASCII or something).

javax.microedition.io is where the magic is.

If you want I can give you our server-side code, but it's just standard socket opening and accepting a connection(in C++ that is).


Why can't you just go with message = m_inputStream.readUTF(); instead of all that, which should do the same thing? and same for outputStream with writeUTF

[pspeer]

Has anyone been able to get TCP communication from the DriverStation to the cRIO using C++?

Does WPILIB support the use of TCP/UDP sockets?

[MohammadAdib]

How are you getting the TCP comm link to work?

I'm currently unable to find the networking API from java..

In normal Java there are easy ways to implement a client server solution. From what i have seen/learned/experienced, it is always noteworthy that a client and server should talk with each other as little as possible while still maintaining communication. If your program requires sending a large amount of small data (such as coordinates) back and forth, then i suggest that you disable Nagle's algorithm, otherwise all of your small TCP packets will be made into one big packet and get sent, and that can mess things up quite a bit if you have some sort of command parser on the other side waiting to read the packets u send. Now that being said, in my opinion the ideal solution is to have the classmate running a server application listening on an open ServerSocket. A client will be on whatever you decide to send data to the classmate with which will try to connect to the classmate via some method of network communication. Then you can let the data flow. But if you are sending small amounts of data (< 1kb) then i recommend using a DatagramPacket (UDP). Regardless how you do it, Here is a useful site on making server and client solutions in Java: http://systembash.com/content/a-simple-java-tcp-server-and-tcp-client/

If you have any technical questions about ANYTHING feel free to email me or something.

EDIT: I forgot to mention an extremely critical thing. Always make your servers threaded! That means for every client that connects to the ServerSocket on your server application, start a new designated thread for handling communication. If your server talks back, then also start another thread for sending info on the socket. Without threading, performance will TANK.

[MohammadAdib]

I just wrote and tested this very simple code for a threaded TCP server template using Java. The server is fully threaded and can read input from incoming clients. There is no limit to how many clients can connect. It uses a thread to search for new clients and once a client connects another thread is started for reading input from that client's socket.

Feel free to use the code as it is a template, but please do not remove the credit comment on the top ;)

Download the file from below:

[pavanetti]

I did so:
http://www.chiefdelphi.com/forums/showthread.php?t=100558
(Post 5)

[shuhao]

What do you guys think about a restful server so it will be easier to develop and test for?

I feel like a constant connection is not necessary. Also, how are you guys structuring rthe network? Server on laptop or server on crio. The formal seems simpler

[sjspry]

As has been answered, yes it is. What has not been mentioned however is that TCP communications are restricted (or were restricted, as of last year) to specific ports, both of which were used up by the dashboard and/or the camera, iirc. In practice, this might not be the case, but I wouldn't rely on it.

[Lalaland1125]

What do you guys think about a restful server so it will be easier to develop and test for?

I feel like a constant connection is not necessary. Also, how are you guys structuring rthe network? Server on laptop or server on crio. The formal seems simpler

Our team is sticking the server on the laptop.

We are not sticking the server on the crio for two reasons:

1. Having a server on the robot increases complexity. I trust neither myself nor the crio to do threads correctly and well, and those threads would be needed to create a "good" server. Having a server on the robot would also complicate code which should be kept as simple as possible(because if the crio crashes, all your other electronics do nothing).

2. If the crio is a client, it can immediately tell when the server is offline(it will fail at the initialization of the robot when it tries to connect). This allows us to simply set a "serverFail" boolean to true, and skip over the network code so that the robot can continue to function even when the server is offline.

For easier development our team is simply using a text protocol JSON, which should make many things simpler(and is a heck of alot easier to debug as well).

[shuhao]

I feel like rest would be the easiest as it's json that you can use your browser to debug and use the HTTPclient class aand a HTTP server

Though there will be no constant connection

[linuxboy]

As has been answered, yes it is. What has not been mentioned however is that TCP communications are restricted (or were restricted, as of last year) to specific ports, both of which were used up by the dashboard and/or the camera, iirc. In practice, this might not be the case, but I wouldn't rely on it.

In order to ensure smooth operation of the robots, the Access Point on the field only allows communication between the robot and the driver station over certain ports, so while you will be able to communicate on all ports at your shop, those communications would be blocked on the field. However, if my knowledge of networks is correct, if you have another device on the robot itself (plugged into the bridge) you will be able to talk to the cRIO on all ports.

[dellagd]

In order to ensure smooth operation of the robots, the Access Point on the field only allows communication between the robot and the driver station over certain ports, so while you will be able to communicate on all ports at your shop, those communications would be blocked on the field. However, if my knowledge of networks is correct, if you have another device on the robot itself (plugged into the bridge) you will be able to talk to the cRIO on all ports.

Correct. The data would just go out the Crio, through your on-robot router, then on to the on-robot laptop. This will be the case if the robot is in Access point mode, like the way we run it in testing at the shop, but since it connects to the field at competitions, it is not in access point mode, and is acting like gateway from the crio to the field. I dont know if you can communicate across the Ethernet ports on the router in this mode, so that will have to be investigated.

[linuxboy]

Correct. The data would just go out the Crio, through your on-robot router, then on to the on-robot laptop. This will be the case if the robot is in Access point mode, like the way we run it in testing at the shop, but since it connects to the field at competitions, it is not in access point mode, and is acting like gateway from the crio to the field. I dont know if you can communicate across the Ethernet ports on the router in this mode, so that will have to be investigated.

I'll see if I can simulate a field environment using custom iptables rules on a wireless router, but here is why I think it would work. Since the cRIO and an onboard computer would both be attached to the switch (robot radio) the switch will have both devices in its ARP table, and, instead of sending packets to the access point for further switching, it would do the communication locally, with the access point never seeing the data. The only way that I think this would be prevented, is if the access point performed an ARP attack on all the devices on the network, however, I doubt this is the case.

[shuhao]

Correct. The data would just go out the Crio, through your on-robot router, then on to the on-robot laptop. This will be the case if the robot is in Access point mode, like the way we run it in testing at the shop, but since it connects to the field at competitions, it is not in access point mode, and is acting like gateway from the crio to the field. I dont know if you can communicate across the Ethernet ports on the router in this mode, so that will have to be investigated.

That is a legitimate concern. There are more than one team who will rely on opencv and freenect, including ours

[dellagd]

The only reason I see this working across the router is from experience, since when we test our bot in the pits we plug into a Ethernet port in the router without changing its settings. Then again, we arnt connected to the field at that point.