Our team has a raspberry pi that we need to connect to the roborio with Ethernet. Currently the solution is to use Ethernet over USB. This solution makes it very hard to deploy code to the pi because we would have to unplug it from the Rio, and use a separate cable for normal Ethernet.
Is there a better way to do this that can still be used at competitions? If we plug the rpi into the radio, there aren’t any ports left for a laptop for use in the pits.
You could put a network switch on the robot. We did that a couple of years ago and it worked out well
Any suggestions for a cheap one?
Find an old router that no one wants, and change it’s settings so that essentially it’s just a switch.
Also, for my team, we ended up connecting the raspberry pi and the roborio to the two ports on the robot router; when we were in the pit, we would unplug it on the rpi/roborio side and connect it to a stationary and always on switch (saved much time in waiting for the onboard router/switch to boot and connect successfully).
I think I have a few old routers lying around. I will give that a shot.
Can’t remember the exact model we used, but it was some super cheap trendnet one off amazon
As for the programming side of it, I recommend just writing a ServerSocket and Socket. NetworkTables is nice because it is easy, but god it is slow. ServerSocket and Socket are quite easy to work with, and they interface perfectly between Java and Python.
I also thought that NetworkTables was too slow (at 10 times per second) so I developed my own UDP setup for vision processing between the pi and the roborio (using Java Serialization). But I would not recommend doing that as it complicates the process significantly and you will need to spend hours making sure the packets are not corrupt.
Furthermore, it turns out that you can increase the frequency of the network tables using
public void setUpdateRate(double interval)
(from the documentation)
From that other thread, it appears people have been able to get the rate down to 5ms — which is most likely fast enough for this application.
But how do you know it is for a video stream? Why would you transfer a video stream off the Pi? It would be better to do the calculations on the pi and send the numeric results over a TCP datastream
We have used custom UDP transports, it was not too bad, but in general I would recommend using well tested code. I am a fan of http://zeromq.org/ which is rock solid and fast.
+1 to zeromq, we used it in 2017 and it worked pretty well. You can see examples implemented in both C++ (vision coprocessor side) and Java (robot side)
+1 to zeromq as well, we used it as a replacement this past offseason and won’t be looking back
I agree you shouldn’t use a video stream (I apologize if my answer made you think that was what I’m talking about). For sending the numeric results, which is what I do, I think it’s better to use the network tables with a lower update rate than to implement a custom TCP connection as network tables basically are TCP at their core and are highly tested. Using something such as zeromq as suggested by @phurley67 should also work, I would just recommend anything that is highly tested.
I agree that UDP isn’t that bad, but given that you can update the network table rate to as low as 5ms (and the roborio update rate is 20ms), I see no reason why not to use that (unless you can think of something).
I believe the fastest network tables update rate is 10ms, not 5ms (see link below). Probably not a deal-breaker for most teams, but certainly slower than what you can achieve with zeromq or a custom UDP solution.
Use the other port on the radio
Story time! At CHS 2017 district champs, we were unable to connect to our robot from our driver station for our first two matches. Upon investigation, which required a call to FIRST HQ, we found that instead of connecting to our robot, our driver station connected to an old D-Link router in our pit that we had been using as a switch. Somehow, the communication protocol from 2013 was similar enough to that of 2017 that the driver station thought it was the robot.
Moral of the story: don’t use old routers as switches unless you are ABSOLUTELY sure that your driver station won’t get confused.
Note you can use Flush() to get an immediate flush of NetworkTables data changes rather than waiting for the periodic sweep. If you set the periodic rate very slow and call Flush() immediately after updating the values, latency is minimized to basically zero. This is how the Limelight gets low latency updates via NetworkTables.
It looks like your team started in 2015. You might have at least one of the old D-Link routers around somewhere.
@ewpratten in any case of what your team chooses to do, please make sure your cables are neatly organized and labeled. If an FTA/FTAA/CSA needs to try an diagnose an issue, the last thing they want to try to do is to trace unorganized network cables between extra hubs and hardware.