Open ounsworth opened 7 years ago
More info:
this link may make it more clear.
It's an abstraction of how data gets from A to B (RoboRio to Pi, Driver Station, and vice versa). It's a bit like signals and slots, publish/subscribe, durable topics, whichever analogy you find most useful.
I could picture the robot writing values to a bling table that indicates what we'd like bling to be displaying. The bling code reads the table and does what it needs to. Could also provide status back to the robot.
Similarly, our vision system could be writing targeting data to a vision table, which the code on the robot reads and uses.
It looks like it would save us from dealing with socket connections, reader threads, timeouts, ports, IP addresses, packing and unpacking TCP messages.
Do you how bandwidth is treated when sent to a local device on the robot like the Pi? Would NetworkTables send updates to every client? If data that's sent through the FMS is capped, how will sending local data over NetworkTables affect our bandwidth usage?
Great questions!
My understanding is that NetorkTables pushes everything to all clients. That would mean that yes, anything put on NetworkTables will cut into the 7 MBPS.
We haven't finished building it yet, but vision will want to send some data about each cube it sees. So rough ballpark: 8 doubles (64 bits each) per cube in view (say 4 cubes in view?) per frame (aiming for 30 fps) = 61440 bits / s = 0.06 MBPS (?). I've added this to the Vision ticket for NetworkTables: https://github.com/FRC2706/TrackerboxReloaded/issues/5. If Vision is generating too much chatter and we need to keep it contained to the robot's wired LAN, then that would mean we need to drop NetworkTables and go back to using bare sockets.
@greyingjay Comment?
From Kevin:
https://github.com/robotpy/pynetworktables