Jetson comm to RoboRIO

[Greg McKaskle]

To add to the other good advice. The latency of a wired ethernet connection is ~1ms. It will degrade if lots of other traffic is present, or if one end is busy, but that is unlikely to happen, is easy to measure, and easy to control. Gigabit ethernet is one of the big standards for industrial camera control and streaming.

Another nice aspect if this is that you can easily modify the connection lengths and topology during the season. The devices can be on bench while the roboRIO is on robot and your laptop is at a desk. When they make room for the devices, you can shorten the cable, remove a switch, etc. And you can substitute devices easily too. If it has the IP or DNS info, it is the droid you are looking for. This allows you to experiment and incrementally deploy while keeping developer tools friendly.

If you decide that you want most of the network table data shared between your targets, then that is a good option -- over TCP by the way. If you only want data shared one direction, or a specific subset of data, it is very easy to serialize your data, send it over either TCP or UDP, and deserialize it on the other target. You can also add it to network tables once received. There plenty examples for doing this in all languages, and the transport of the data is language independent.

Greg McKaskle

[gpetilli]

Thank you all. It looks like ethernet sockets is the clear winner. I guess we (more likely just me) have some homework to do.

[billbo911]

Originally Posted by gpetilli

Thank you all. It looks like ethernet sockets is the clear winner. I guess we (more likely just me) have some homework to do.

Sockets will work. Just make certain you do not saturate the Rio with incoming data. From experience, I can tell you bad things happen.
The issue you may face is causing the Rio to miss command packets from the DS. When this happens, you can loose control of the robot.

As long as you are reasonable with your approach, you "shouldn't" have any issues.
If you find you are having issues, look at using UDP sockets instead of TCP.

[feverittm]

I have a question regarding talking to the Jetson over a network connection. I have heard a number of stories this year of camera code not working because the FMS was blocking some port or another during competition. Everything would be fine in the pits, but on the field the camera was dead. Are their any know best practices for how to work with this type of network code.

Thanks

[frcguy]

Originally Posted by feverittm

I have a question regarding talking to the Jetson over a network connection. I have heard a number of stories this year of camera code not working because the FMS was blocking some port or another during competition. Everything would be fine in the pits, but on the field the camera was dead. Are their any know best practices for how to work with this type of network code.

Thanks

See here: https://wpilib.screenstepslive.com/s...fms-whitepaper

Information on recommended bandwidth usage, open ports, and more.

[marshall]

Originally Posted by feverittm

Are their any know best practices for how to work with this type of network code.

Treat FMS like a black box until FIRST provides more details about what it is doing. Refer to the white papers I listed earlier in this thread for the setup that 900 ran this year for vision. We had no issues with vision communication on the robot. We did have issues with our driver station at one event, likely created by a non-constrained loop on the driver console and definitely not the result of our vision configuration.

Anecdotally, all the teams that I heard/saw having issues with cameras were not relying on static addresses but on mDNS. I'm not saying mDNS was the problem but I know that the documentation for both of these is lacking for making forward progress for integrated vision systems.

I would really like to see simple block & wire diagrams from FIRST documenting how all of the components of FMS work together and outlining ports/protocols in use along with what data is collected and when and any exposed APIs that the teams can use. I think having all of this documented would go a long way towards solving the "it works on the practice field" issues that plague a lot of teams.

Originally Posted by frcguy

See here: https://wpilib.screenstepslive.com/s...fms-whitepaper

Information on recommended bandwidth usage, open ports, and more.

This is severely lacking technical details for what is going on with the FMS and is not a white paper describing FMS so much as a set of guidelines for teams to use. There is a lot of information that is not detailed here.

[AustinSchuh]

Originally Posted by billbo911

As long as you are reasonable with your approach, you "shouldn't" have any issues.
If you find you are having issues, look at using UDP sockets instead of TCP.

We've found UDP to be easier to use and the right answer for communicating controls data (both for work and robotics).

[billbo911]

Originally Posted by AustinSchuh

We've found UDP to be easier to use and the right answer for communicating controls data (both for work and robotics).

When Austin speaks, you would be wise to listen!

Besides, he is the one who pointed me to start using UDP. So far It has been fantasic.