Thanks so much for the reply! and the WPILib in general lol. Do you have any estimates latency wise as to how quickly a client would get reupdated?
Last time I tested, it was about 1ms from when flush was called to when the server received the data. You only really want fast data in 1 direction (from a coprocessor to the roborio), trying to get fast data the other direction can cause other issues. But from flush to data received on the rio and just as fast as any other networking, since its TCP over a wired connection.
-
By flushing do you mean remove all items from the queue?
-
How long should getting a value from the server into the roborio should take by default? (Let’s say we’re talking a float).
In NetworkTables, flush causes all data currently in the queue to be written to the network.
By default, NetworkTables updates at a 10hz refresh rate. This means any values you update in your code or in a coprocessor gets queued, and that queue gets written out every 100ms. So by default, new values will take anywhere from 0.001ms to 99.999ms, depending on when the new value is written in relation to the refresh timer.
By calling flush manually, you can cause this write to happen instantaneously, bypassing the built in refresh timer. This is what we recommend you do on a coprocessor to get data as fast as possible. Then, you’re basically just at how long it takes to send a TCP packet over the wired network. Which really isn’t that long.
-
“flush” is a function call: NetworkTables.flush(). That pushes any queued updates out immediately.
-
The Python implementation has changed the default flush period to 50ms (if I remember correctly). You don’t want to lower the default much below that (so I am told). However, we called flush() on our vision coprocessor after every frame (33ms) and saw no issues.
After flushing the queue, will the data that is saved on the network is only the newest data, or the whole queue?
What is the default size of the queue?
This one wasn’t about flushing, my question here is how long should take to acquire available data from the network to the roborio?
The queue only holds the latest data written. If you write 5 values between updates, it only writes the latest one. And the queue isn’t really bounded, since its max length is the amount of keys. It’s not exactly a queue, but its the closest representation.
I’m not sure what you’re asking by your 2nd question. As soon as you flush, you will have new data on the rio within however long it takes a TCP packet to sent and be received. This depends on a ton of factors, but ethernet connected on the robot itself is likely less then 1ms.
So basically for each key it’s kind of a queue with one element?
That helped me figure out what I was trying to understand, thanks.
It’s more of a list.
That’s the function that gets called when you update an entry. Then on flush, or the refresh timer occuring, PostOutgoing is called. NetworkTables is definitely not ordered in any way, shape or form.
Got it.
And if we’re sending also camera/multiple cameras stream via NT, is it still recommended flushing? (We only care of getting target data on time, not the stream itself).
Definitely do not be sending the actual camera video stream over NetworkTables, it’s not designed for that at all. But your tracking data sure, call flush whenever each camera has written its data.
Can you recommend what’s the appropriate way to stream from a RPI to dashboard?
CameraServer, some type of custom MJPEG server, or literally anything designed for sending video. NetworkTables is not designed for it, and it will destroy all network traffic.
The FRC Pi Image already has everything set up to easily stream cameras, and examples to to add custom processing and network tables for tracking data as well.
The programmer I’ve talked with misunderstood, we use cscore for streaming, so we’re fine.
We’ll try flushing after updating values.
Is the scope of the flush method a single network table, or all of the network tables on a client? For instance, if I’ve got a custom vision coprocessor, and I want to send vision tracking data quickly to the Rio, but debugging info slower to the SmartDashboard, would it be a good idea to store this on separate network tables and then only call the flush method on the tracking data table frequently?
The scope of flush is all the network tables on a client. However, NetworkTables is a multiple client/one server (star) architecture with the Rio robot program as the server. The server (the Rio) is running its own periodic transmit loop that sends data updates to all clients from both local changes (e.g. the robot program) and updates received from other clients (e.g. the coprocessor). What this means in your example is that while both the tracking data and the debugging info would be flushed at a higher rate, that higher rate would stay local to the robot network, because it would only be sent from the coprocessor to the Rio. The Rio would send data updates at a slower rate (e.g. typically 100 ms) to all other clients, including SmartDashboard.
If you really want greater control over this, however, it is possible to create multiple NetworkTableInstances to create multiple clients or servers within a single program (the scope of flush is actually NetworkTableInstance). This lets you create entirely separate NetworkTable client/server networks or have multiple clients to one server within a single program. So in your example you could create two clients, both of which receive a full copy of updates from the server, but only one of which flushes more frequently, or create an entirely separate server on the Rio and separate client on the coprocessor that holds only the tracking data. But as mentioned in the previous paragraph, this is overkill if what you’re worried about is the amount of data going over wifi.
Is the networking speed in an actual game the same as that in a testing environment?
We connect our rpi as recommended by Screenstep to the radio, which is also connected to the Rio. When rpi sends a packet to Rio, does it have to go through the FMS and slow down?
There is no reason for local robot traffic to go over wifi to the FMS and back again.
The FMS computer really on talks to the driver station. [Edit: a better descriptor is probably field network (thanks Marshal)] Anyway. If I am understanding all this correctly. The clients are talking directly to the server on the Rio. The network switches will send the traffic by the most direct path. So what is on the robot will stay on the robot. IE not be broadcasted over the radio. When the server updates, it will be sending data to DS over the radio, but that really should not effect the traffic routing to points on the robot.
This is assuming the OM5P radio is doing what it is supposed to do which apparently sometimes it doesn’t
We’re processing at around 200 fps, and doing flush in every frame that we captured in which target is valid.
Is it too much? @Thad_House @Peter_Johnson
We are encountering a lot of packet loss when the camera is seeing a target.