Networking on the Robot

[JML]

Hello,

How does everyone do networking on their robot. Specifically for Java and/or C++, but Lab View is applicable as well. Does everyone tend to use the Network tables libraries and program, and on top of that, how efficient are network tables, Would using just a socket work better or more efficiently? I was leaning towards using sockets for any custom communication with our co-processor this year, but I wanted to check what others thought about this, and since I don't have access to a robo-RIO right now, i cant do research on my own.

Thanks

[billbo911]

For the last couple of years, and now this year, we use a socket. The RoboRio requests a socket connection to our coprocessor. The coprocessor accepts the socket then responds with a string of target information, then closes the socket.
It's simple and fast.

[JML]

Originally Posted by billbo911

The RoboRio requests a socket connection to our coprocessor. The coprocessor accepts the socket then responds with a string of target information, then closes the socket.

Does this mean you are connecting and disconnecting a new socket every time you wish to transmit information, or are you doing it at the start and end of the match or in teleop/auto/robot init and disabled init for disconnect

[billbo911]

Originally Posted by JML

Does this mean you are connecting and disconnecting a new socket every time you wish to transmit information, or are you doing it at the start and end of the match or in teleop/auto/robot init and disabled init for disconnect

We are connecting, transferring the data, and disconnecting every time the controller wants it, and only when the controller wants it.
No WiFi bandwidth is used as this stays local to the Robot's network.

[nickbrickmaster]

That seems inefficient if you are accessing the data more than a few times every match.

[virtuald]

NetworkTables is really good for key-value types of transfers of data, and it's very simple to use from robot code, and let's you ignore network-related complexity. You can expect up to 100ms of latency in Java/C++ as the sender (not sure about LabVIEW), and up to 50ms of latency when using python as the sender. But, for most control systems in FRC, this is good enough.

[billbo911]

Originally Posted by nickbrickmaster

That seems inefficient if you are accessing the data more than a few times every match.

Are you saying it is more efficient to continuously stream data to the robot controller that is not needed? Prior to this year, that was a really good way to lock up the cRio.

We have chosen to only evaluate target data when it is needed. Otherwise, the transfer of data is wasted CPU cycles. Call it inefficient if you will, but it's still way more efficient to transfer 24 bytes of data only two to three times in autonomous, then it is to continuously use processor cycles to process a stream.

[magnets]

Originally Posted by nickbrickmaster

That seems inefficient if you are accessing the data more than a few times every match.

You really don't want to run the risk of filling the network buffer on the cRIO. Ever. It's really bad.

[Greg McKaskle]

The LabVIEW network tables defaults to an update rate of 100ms as well, but there is a parameter, Update Time, that lets you determine how often each client and server will transmit modified values. There is also a flush so that you can keep the rate as is, but you can send important value updates immediately. Additionally, value writes with the same value do not cause updates.

For the various infrastructure protocols that run on the cRIO and roboRIO, we use a combination of TCP and UDP. You will not run into the buffer full issues on the roboRIO, and on the cRIO, they occur only when the incoming data isn't being read.

So the use of sockets opens you up to additional power and additional consequences if you do it incorrectly. For most teams, I'd think that Network Tables is sufficient for set points and status, and a TCP stream is appropriate for a camera.

Greg McKaskle

[codes02]

Originally Posted by billbo911

Are you saying it is more efficient to continuously stream data to the robot controller that is not needed? Prior to this year, that was a really good way to lock up the cRio.

We have chosen to only evaluate target data when it is needed. Otherwise, the transfer of data is wasted CPU cycles. Call it inefficient if you will, but it's still way more efficient to transfer 24 bytes of data only two to three times in autonomous, then it is to continuously use processor cycles to process a stream.

Originally Posted by magnets

You really don't want to run the risk of filling the network buffer on the cRIO. Ever. It's really bad.

You can keep an established TCP connection open without sending data, and only send data on request. This allows one to avoid the overhead of establishing and tearing down a TCP connection for every request, and is a common optimization in network protocol design.

[chsahit]

Take a look at this little thing I cooked up:
https://github.com/chsahit/UDPTable

It uses UDP instead of TCP for less networking sadness/latency. I designed it to be a simple alternative to Network tables.

[JML]

Thanks for all of the responses

Originally Posted by chsahit

Take a look at this little thing I cooked up:
https://github.com/chsahit/UDPTable

It uses UDP instead of TCP for less networking sadness/latency. I designed it to be a simple alternative to Network tables.

Thanks! I will be sure to check this out.

From my understanding, UDP has no packet delivery confirmation unless you implement it yourself, I haven't had a chance to look at this project yet, but would that be an issue for robot applications, have you tested this on a robot application.

For custom driver station outputs, I could see this being an option, but what about for sending processed image data back to the robo-RIO?

[chsahit]

I did not implement any checking to see if the packets got across. This is best used for when you are streaming data. If you are sending a continous stream of data over to the roboRIO or are constantly polling that network device than a few lost packets isn't a problem. In your instance, you might want to do some testing to see if this is right for you.