Queues using NetworkTables

[fovea1959]

has anyone seen an implementation of queueing data from robot to DS using NetworkTables? I'm looking for a way to get logging data from the robot to the DS; can't use a single value, because I don't want to overwrite the value on the robot until I know the DS has grabbed the previous value and logged it.

[Alan Anderson]

It might be simpler for you to open your own TCP connection and send the logging data that way.

[fovea1959]

I agree with that (the DS side becomes 'netcat'), but I keep coming back to according to the FMS White Paper:

The ports that the teams are able to access on the playing field are as follows:

• TCP 1180: This port is typically used for camera data from the robot to the DS when the camera is connected to port 2 on the 8-slot 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

What ports on the DS would be accessible from the robot?

[Alan Anderson]

I suggest TCP on port 1180. It's not likely that you'll want to plug the camera directly into the cRIO and forward packets to the Driver Station through it, so that port is available for other purposes.

[fovea1959]

so we'd have to have the cRIO do the TCP listen/accept...

udp would be easier....

[Alan Anderson]

UDP would certainly be easier, and it's what I would use myself. But it sounded like you were concerned about possibly missing information, and UDP gives you no guarantee that transmitted data actually gets received. If you don't want the possibility of lost data, you'd need to implement your own buffered acknowledge/timeout/retry scheme.

[fovea1959]

I'm not worried so much about dropped UDP packets as I would be about designing something using NetworkTables that definitely will drop data. If you write to a NetworkTable variable with two values quickly, someone else watching that variable is not really likely to the first update unless they are polling the variable really really fast.

Two UDP writes quickly shouldn't be a big deal.

But it still comes back to what UDP port can I listen on on the DS? None available!

[Alan Anderson]

Originally Posted by fovea1959

But it still comes back to what UDP port can I listen on on the DS? None available!

Port 1140 is defined for exactly the purpose you are looking for.

[fovea1959]

oh! I was misinterpreting that document! I thought it meant that the WPI provided Dashboard framework listened on UDP 1140; I didn't realize that was reserved for team's custom code... I take it that we can have code on the bot listening on UDP 1130, also, then.

Logging gets *real* easy, then. Robot UDP send to a netcat running on DS. Done.

where does the WPI provided dashboard receive it's information? Is that TCP/1735?

I need to fire up Wireshark

[Greg McKaskle]

Yes, Network Tables was done over TCP using port 1735 I think.

Greg McKaskle

[Joe Ross]

Originally Posted by fovea1959

Logging gets *real* easy, then. Robot UDP send to a netcat running on DS. Done.

If that's all you wanted, netcat does the same thing for TCP.

[fovea1959]

ok, but what what TCP port can I listen on on the DS then?