Our team is preparing to use a Jetson Nano for our next competition. Are we able to plug the Jetson into the unused port on the radio, and if so, will it communicate with the roboRIO as expected?
I think you should be able to. Just make sure that it is set to a static IP and it is not plugged into the port closest to the power jack because that is where the rio has to be plugged in. I am basing this off of our teams work with a raspberry pi because it looks similar but other than that it should work.
You can plug the Jetson (or any other co-processor) into the second radio port. But keep in mind, that means you no longer have a port to tether the robot to the driver station over ethernet. At competition where you can’t run over wifi in the pits, that will make it hard to fully test the robot’s functionality. I suggest getting a small ethernet switch, plug that into the second radio port, and plug the Jetson into that. Then when you need to tether you’ll have a spare port in the switch you can use to connect to the driver station.
But you can control the robot by connecting the driver station to the roboRIO over USB, right?
Yes and no. You can use USB B to enable the robot and control it. But you won’t be on the robot’s LAN network so you won’t be able to connect to or test the Jetson. That’s usually a problem when teams need to test their vision code in the pits or practice field, or even make sure the camera is working properly during pre-match checks.
Also, USB cables are generally limited to around 3m in length. That’s fine in the pits, but on the practice field it means someone has to hold the driver station and run around the field following the robot. (I know we’ve done that many times in the past, but it’s really not the best method.) On the other hand, ethernet cables have a max length of around 100m, and most teams have long cables (aka tethers) they use for the practice field. That allows you to set up the driver station like you would normally for a match on the side of the practice field and just take care not to run over the tether.
I could be wrong but, isn’t there an exception to the “No wifi in the pits” rule when you are on the practice field?
That’s an emphatic no. You are never allowed to run your robot using your competition-configured radio (or home-configured radio for that matter) during the event. Some events do have specially-configured practice field radios you can use to substitute in place of your team radio to control the robot wirelessly, but there’s no guarantee that your event will have them. It’s also better to be able to test and troubleshoot with your own radio if you’re running into connectivity problems.
At a couple of the event’s that we have attended, we were indeed allowed to operate our robot over a practice field configured radio, but I agree, an Ethernet cable is always an simpler option…
For 2020, WPILib will include a Port Forwarding feature that would allow you to receive data from ethernet connected coprocessors while you’re connected to the roboRIO with USB. http://docs.wpilib.org/en/latest/docs/networking/networking-utilities/portforwarding.html
As said earlier, yes, you can plug your coprocessor (Jetson) into the other port on the radio. However, be aware that a few teams, mine included, had serious trouble with this setup, on the field (and only on the field). It worked fine in our shop and in the pit, but the communication between the coprocessor and Rio and Driver Station was flaky and unpredictable on the field. Other teams reported this issue but I never found a good explanation.
The fix is to use a small Ethernet switch on the robot. Plug the coprocessor and the Rio into the switch, and then the switch into the radio. With that setup, we had no problems, and it gives extra ports for tethering in the pit and practice field. We using a small usb-power switch, others have 12V powered ones.
I’m curious if anyone ever found a good explanation or easy fix for this, since we are testing vision with a coprocessor at CowTown this weekend that works pretty well and I’d hate to see it not work just because of a field bug. Anyone?
Yeah, it’s a problem with the firmware on the OpenMesh OM5P-AC APs. If you want an in-depth technical explanation then I don’t have it but I know from testing that this continues to be a problem with those APs (I believe it’s some kind of race condition with how the secondary port is enabled at boot and it results in the ports being effectively isolated from each other and not acting as a switch).
The simple solution is to use a switch and only 1 of the AP ports or use the OM5P-ANs.
OK, thanks. To go from 12V to 5V for the switch off the PDP I guess we need something like this, right?
(bonus points for being waterproof because you never know what kind of game we’ll get next year)
if you don’t need a huge current draw you could also use the ports on the VRM
You do need something like that but I will caution you that not all DC converters are the same and you really need to do some testing to figure out when it stops putting out 5v from voltage sag. This is our go-to converter for all of these applications and we definitely recommend it: https://www.amazon.com/dp/B00JKG57T4/ref=cm_sw_em_r_mt_dp_U_tifUDb4KZ0MXY
My recollection is that this is against the rules. Your Rio has to be plugged directly into the radio – in fact, the rules specified which port on the radio had to have the Rio (IIRC, it was the one that ran PoE). Instead, you can connect the switch to the other port.
Your memory is incorrect:
Thanks. Yes, we knew about the “direct connect” recommendation. However, given the flaky behavior of the radio on the field, it seemed safer to only use 1 port on the radio, and we did not have any trouble with the setup.
In terms of figuring out what was going on, I should adjust my previous post. We only tested the connectivity in the pits using a network switch, so the radio was not involved. It may be that the field configured radio is the problem, but irrelevant except on the field (where wifi is used).
As for the real issue, a few people have said that the 2 ports in the radio are not actually a proper switch. But OTOH, it seems to work fine when not in field configuration.
There is no hardware switch in the radio. The functionality of the ports is set up by the OS on the radio, so the firmware will make a difference.