Hello!
Our team is implementing vision for the first time this year. We are using RoboRealm, and are able to detect the openings on the tower already. Our RoboRealm set-up finds two openings, their centers-of-gravity (each one), and stores them as variables. Then, we use a Network Table to send it. This is our network table set up:
However, we aren’t sure how to set up the LabVIEW side to actually receive and utilize the variables. Where should we start to receive these variables, and make adjustments based on them?
Thanks for the help!
The LV implementation implements the same Network Tables or SmartDashboard protocol as everyone else. So once you get RoboRealm to connect to the server running on the robot, the variables should show up on the robot and in the dashboard. I am not sure if RoboRealm support putting a device name in the address field, but that would are ideal – that would mean putting a roboRIO-team-FRC.local. If that doesn’t work, you can find the IP address of the roboRIO and type that into the address field. But that is not going to be ideal for the official matches.
Greg McKaskle
Does the connection have to go through Smart Dashboard? If so, where could I get it?
Also, in what library would one find the Network Tables/Smart Dashboard Protocols?
Thanks a bunch!
LV can communicate in many many ways, but you have to find one in common with RoboRealm and one that works on the field. If you find documentation that explains how to do lower level UDP, TCP sockets, or other from RoboRealm, then those are options. But the Network Tables protocol was built specifically for communicating to the robot from other clients such as the SmartDashboard. I’m pretty sure it works as long as the connection can be established by IP number or name.
Greg McKaskle
What I am understanding is that roboRealm sends the data to the dashboard, and then the dashboard can send it to the roboRIO.
I think I understand how to get the data from the Dash to the roboRIO, but I’m still not sure how to connect the data from RoboRealm to the Dashboard.
Thanks for the help.
That understanding is close, but let me adjust it.
Network tables is a shared table of named values. The REAL values exist on the robot, which is called the server. Other code, on the dashboard, in RoboRealm, on other coprocessor cards, etc. can act as clients and can use the network table functions to read and write to those values.
The clients and server constantly send messages to each other to get in synch. You can read the documentation if you have curiosity about how it works, and of course you have the code, but it is a bit complicated. For most situations, you can simply trust that as long as your client is connected, that it has the same values as everyone else and can change any value at anytime and the others will get is almost instantly.
Greg McKaskle
On a related note, I’ve been having trouble getting Network Tables to actually work at all with RoboRealm.
On the documentation, it mentions Network Tables 2.0, but I think the one running on the RoboRIO is 3.0, correct?
If this is the case, then is RoboRealm incompatible? Or is my problem something else?
Another note:
I kind of got RoboRealm to send a bit of mangled data to the network tables, but it’s nothing usable. Also, when it connects, the Driver Station starts spewing errors such as this one:
http://put.nu/files/gKabPtt.png
Makes me fear that RoboRealm is just completely incompatible with this year’s control system.
I’ve been having similar problems where I get these errors (same ones) and garbage data.
EDIT: Due to this, we’ve decided to reformat our work into Vision Assistant, and go from there.
This is not your problem. Not a problem caused by anything you did.
I wasn’t aware that RoboRealm was still using 2.0. We are looking to see if it can be updated.
Greg McKaskle
Does “Still using 2.0” mean that we need to stick with TCP and the API?
I read that network tables are the perffered way to do this but I don’t know why of if they will work.
