Networking on the Robot

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