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]

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]

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?

[Alan Anderson]

Unless you're already using it explicitly for something else, TCP port 1180 is available.

[RufflesRidge]

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

1180 is open unless you plan to plug a camera into Port 2 of an 8-slot cRIO.

[fovea1959]

That doc is pretty taciturn, it doesn't say whose ports (Robot or DS) it's talking about, and whether or not they are in use by the FIRST/WPI/NI framework.

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.


FMS will pass traffic to and from the robots TCP/1180 port. Correct?
That port is free for my robot code to listen on if I have a 4-slot cRIO (or an 8 slot with no camera)?



TCP 1735: SmartDashboard, bidirectional

FMS will pass traffic to and from the robot's TCP/1735 port. Correct?
That port is not free for my robot code to listen on, it already in use by the FIRST framework. Correct?


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

FMS will pass traffic to the robots UDP/1180 port, correct?
FMS will not pass traffic to the DS UDP/1180, correct?
That port is free for my robot code to listen on. Correct?


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

FMS will pass traffic to the DS UDP/1140 port, correct?
FMS will not pass traffic to the robot UDP/1180, correct?
That port is free for my driver station code to listen on. Correct?


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

FMS will pass traffic to and from the camera's TCP/80 port [10.xx.yy.11]. Correct?
If I don't have a camera, I can put another device on the robot at 10.xx.yy.11 listening on port 80, and can pass traffic to and from it.
If I do have a camera, then I obviously cannot use it for my own code. Correct?


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

FMS will pass traffic to and from the camera's TCP/443 port [10.xx.yy.11]. Correct?
If I don't have a camera, I can put another device on the robot at 10.xx.yy.11 listening on port 443, and can pass traffic to and from it.
If I do have a camera, then I obviously cannot use the port for my own code. Correct?