Correct Robot Network Architecture

[BoilerMentor]

My team has been experiencing remarkably long connection times and significant communication latency once connected (only on the vision feed, no input lag to speak of).

My question is simply what the correct setup for the robot side of the network should be.

Currently both ports of the radio are occupied
-One port is connected directly to the RoboRio
-The other is connected to an unmanaged switch (D-Link GO-SW-5G)

The switch has two of five ports occupied
-One port is connected to the radio
-One port is connected to the camera (Axis 1013)

Is this the most correct configuration?

Are there any device configuration settings that we may be overlooking that could help resolve this issue? I've read the WPI "Networking at the event" PDF.

It occurs to me, we might consider making the switch central with the radio, roborio, and camera all connected to it using a single port on the radio for communication.

Additionally, the Axis Camera is currently set up not using a static IP and I wonder if it would be worthwhile to switch back to using a static IP?

Any help anyone can provide would be greatly appreciated. Thank you!

[mwtidd]

When are you seeing this issue? (when connected to the FMS, when on wireless, when tethered, etc)

Where are you seeing the issue? (on the DS, on the Rio in code, etc)

I would recommend using the static IPs because that eliminates just one of the many things that may cause issues. When setting up the static IPs I also suggest you use a default gateway of nothing or 0.0.0.0.

I have also sent you a PM.

[Alan Anderson]

Originally Posted by BoilerMentor

Is this the most correct configuration?

It seems fine to me. The direct radio-to-roboRIO connection is required by the rules, and the rest of it follows from there if you want the ability to connect your Driver Station by Ethernet cable to the robot network.

Have you tried a different computer as the Driver Station? Vision lag on the Dashboard is often due to networking delays in the DS computer.

[BoilerMentor]

It sounds like we may just want to ditch the switch for regular match play and only use it for the practice field. Such a tiny AP is great, I just wish it had 3-4 ports. I'm certainly open to any other theories, but this one is easy enough to test.

I'll also make the effort to see if the alternative configuration makes a difference, so that we may be able to use that for off-field testing. Parallel USB to roborio and ethernet to camera tethering wasn't working reliably for whatever reason, so that still begs a solution even if removing the switch fixes the issue under FMS control.

As far as the laptop being used for the driver's station, we haven't tested another machine, but that variable hasn't changed over the course of the season. We did check the power use settings to verify that it wasn't adjusting network settings as a power saving measure.

[GreyingJay]

Originally Posted by BoilerMentor

Currently both ports of the radio are occupied
-One port is connected directly to the RoboRio
-The other is connected to an unmanaged switch (D-Link GO-SW-5G)

The switch has two of five ports occupied
-One port is connected to the radio
-One port is connected to the camera (Axis 1013)

This is almost the exact configuration my team used, with that exact switch. (Tiny innit? ) The power to the switch was wired into the VRM. Our camera was a TP-Link something or other instead of an Axis. We also had a Raspberry Pi 2 connected on another port on the switch. We had no trouble with this setup during competition, including tethering to the RoboRio in the pits and on the practice field by connecting our long tether cable to one of the free ports on the switch.

I have read on this forum that which port of the OpenMesh radio the RoboRio is connected to matters. I don't really know why. Try swapping the ports and see if that changes anything.

[BoilerMentor]

Well...

Turns out some things were in Dynamic IP settings and some things were in Static IP settings. AMAZINGLY when everything was configured appropriately with static IP settings in the correct range almost all of the problems went away.

We did still have some instances of intense packet loss which resulted in either lag or crashing of the vision code, so it's still not perfect, but much improved and we still managed to qualify for champs in a district points position.