Image issue with network tables

[brhea]

I've an application that I've loaded as a java jar file and it is scheduled and runs. Network tables seems to be sporadic as viewed from Outline viewer when writing from the PI app. I've only got a few statements now in the code that uses an Entry.setDouble(counter) value to the network table. A counter just runs and updates counter and it repeatedly writes to the network table.

I've got a labview app that displays the entry in the network table and it updates properly. When I load outline viewer, the value updates 1 time and stops. Table entries that are read by the app are never read by the app. Seems to be the same problem with shuffleboard.

Is there a problem with nt core library or image or outlineview/shuffleboard?

A minor issue is that when I click application and choose file to upload a java jar file, I get the message "No file chosen" even though the file was uploaded and scheduled to run. Also when restarting the default option of "built in multi camera streaming" is always selected even though it is not the current option selected.

I also have a question about the "custom" option. When I select this and then look at vision status a process still seems to be monitored and restarted when I hit kill. It also starts on boot even though I have custom selected which might conflict with my application?

Does the image start a network table on boot that might conflict with my app? A description of what happens in sequence on boot might help.

Another helpful item would be to have a java routine that would enable and disable "write" on the image. I'd like to be able to save tuning parameters and then set the image back to read only programmatically.

I've spent a lot of time with this network table issue.... I'm a bit at my wits end.

[PeterJohnson]

Regarding your NetworkTables question: are you running the Pi NetworkTables in client or server mode? If running in client mode, I'm assuming you have a robot on the network with robot code running? When you say a LabView app, is that a dashboard app or a robot application? If it's a LabView robot application, are you pausing the robot application at all during this testing? The only application running that uses NetworkTables on the Pi is the vision application.

Regarding uploading: the upload occurs very quickly. When you click "save" the upload is near-instantaneous so it will go back to saying "no file chosen" immediately. The default option should not come back if you've successfully saved/uploaded; I've never seen that behavior.

Regarding the "custom" option: this is for people who want to write their own runCamera script instead of using one of other the web dashboard options. It's really intended for advanced users only; almost everyone should be fine with one of the other options (which cause the web dashboard to overwrite the runCamera script).

[brhea]

The "no file chosen" message is no longer a problem for me as I now understand how it works. It was just not initially intuitive. I expected a "file transfer complete" message. The default option only comes back after I reboot the rPI. Again, no longer a problem for me as I now understand how it works.

"custom" is also no longer an issue for our team as I have the java upload working... I expected that when I selected custom for the image to stop loading and running any program... but it continued to run the last option that I had selected before custom.

We were previously using putty and filezilla with the rPI to upload and start programs... now we can do this with just uploading using your web interface. Thanks!

I'm running NetworkTables in client mode. The server is on the robot and its running last year's labview robot code. I have updated the entire development system to this year's labview and all of this years libraries for java/vscode. The robot application never pauses.

I compiled our vision app developed for an image running java 8 by copying your sample project to get the latest copy of gradle and build file. Then I replaced your main.java with ours. The compile ran fine after I ran the batch file that loads frcvars2019.

Let me share the key parts of the code. I've put the loop near the top so that the code never starts any camera and really does nothing other than loop and update a counter while writing to network tables.

... / these load properly from the rPI image System.loadLibrary("opencv_java344"); System.loadLibrary("ntcore");
System.loadLibrary("wpiutil"); System.loadLibrary("cscore");

... String visionInst = "Vision1"; String robotId = "20"; String piAddr = "83"; //String[] roboRioAddress = {"10.40." + robotId + ".2", "frc-40" + robotId + "-roborio.local"};
String[] roboRioAddress = {"10.40." + robotId + ".2"};
// I commented out the "frc-40"+robotId+"-roborio.local" for testing as it was throwing a connect error ... // Connect NetworkTables NetworkTableInstance NTinstance = NetworkTableInstance.getDefault(); NTinstance.startClient(roboRioAddress); NetworkTable tuneTable = NTinstance.getTable("SmartDashboard/"+visionInst+"/Tune");
NetworkTable targetTable = NTinstance.getTable("SmartDashboard/"+visionInst+"/Target");
NetworkTable controlTable = NTinstance.getTable("SmartDashboard/"+visionInst+"/Control"); NetworkTable diagnosticTable = NTinstance.getTable("SmartDashboard/"+visionInst+"/Diagnostic"); NTinstance.setUpdateRate(0.1); // set update rate to 100 ms // note I've tested update rate with 0.01 also but same results.... // initially I was using NTinstance.flush() to send data immediately but have commented that out for testing. // the only difference I seen in our code vs your sample code is you start the client using the team number... eg. 4020 in our case,,, the client seems to connect correctly per the console messages.

... NetworkTableEntry counterEntry = diagnosticTable.getEntry("counter"); double counter = 0;

while (counter != -1){ // loop forever System.out.print("counter value: "+counter); counterEntry.setDouble(counter); // sleep for 100 ms ... try { Thread.sleep(100); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } counter++; } ... // I recreated the loop part from memory as I'm not at the school now and don't have the test code on my pc.

I'm running labview interactively... (e.g. not deployed for startup) so I can view the variables in labview. I've also set up a counter in labview and am writing its value to the network tables.... and they both show up in smartdashboard section on outline viewer. I've also inserted an NTread in labview to read the "counter" entry written to by the rPI.

When I run labview interactively and look at the "counter" from rPI and also the counter from labview, both are increasing.

When I load outline viewer, both the "counter" from rPI and the counter from labview show up in the tree. The labview counter is increasing in outline viewer and has the same values as on labview. "counter" from rPI never increases on outline viewer . The rPI "counter" messages on the web console show "counter" continuously increasing and with the same value as seen on labview.

On outline viewer, "counter" has the value of "counter" when outline viewer loaded. It never changes. If I delete the "counter" entry on outline viewer, it is immediately created again and it has the same value that the rPI console had when it was created but it never changes. On labview, the counter goes to 0 and is not updated... eg. it uses the default value because it can no longer read it. When I restart the labview code it again reads the "counter".

I was trying to use outline viewer to debug the code and parameters that will pass to the roborio and the driver's station. I think I had the same issue with shuffleboard reading the tables but have not tested it as fully.

We're running the outline viewer and shuffleboard/dashboard from this years install... e.g. outline viewer is loaded from the users\public\frc2019\frccode....etc directory.

I tried reimaging the roborio again...

[brhea]

Is there any folder on the rPI that we could read/write to that is not read only? For example, if we wanted to quickly write a file with vision tuning parameters when they are changed and then close the file? Chances of shutting down and corrupting the file during a write would be minimal. We'd only read the file when the app started.

[PeterJohnson]

No, all filesystems are set up to be read-only (other than temporary filesystems that are only in memory, and thus lost on power-off). If you look at /etc/bash.bashrc you'll see the shell aliases rw and ro which make the filesystem read/writable. You can run those same commands via whatever Java provides for running external programs to do what you want.

I'm still puzzled by the NT behavior too. Is this with this year's version of LabView? Could you try deploying the program to see if behaves any differently than running interactively? You're not writing to the same value anywhere else, right?

[brhea]

Thanks... I'll look at using the shells,,, or we can do this like we did last year and save the settings on the roborio. Its just a bit cleaner to put it on the PI.

Yes this is with this years version of labview. We've updated everything on all of our dev systems to this years version.

No. Nothing is writing to the same value... the NT keys are different.... I added the vision1 prefix to everything that we're reading/writing this year so the NT keys should all be different. I'll be going to our school in a few minutes. I'll try deploying the code to run on startup. Another thing I want to try is to use a blank template for a labview project and run it. That should not have any code in it that has any potential to conflict.

Worst case for now is to have labview read all of the values that the rPI writes and then write them immediately back to another network table key.... and also read values from network table and write them back to the keys that the rPI is reading. This would allow us to continue with development and tuning while trying to figure this out... not a long term fix that I want to live with though.

[brhea]

Tried deploying and running Labview code as startup with no changes. Problem is still the same. Also tried using a blank Labview robot template (command/control) and the problem was the same.

We wrote some code in Labview to pass parameters back and forth with some success. Still debugging that part.

[PeterJohnson]

This looks like it's a bug with LabView acting as the server. I can't reproduce this issue with a Java robot program, but can with a LabView robot program. I will contact the right folks at NI to try to start debugging this issue.

[brhea]

Thanks Peter... my next thought was to try building the sample java robot project and testing with its NT server. That would verify its not our machine or a conflict on it. We had some problems with shuffleboard starting to read network tables on startup last year. We'd restart shuffleboard and it would usually work. This may be the same problem.

[brhea]

This would allow us to test and get our vision program fully running while waiting on a fix from NI.

[rzblue]

I'm having this issue too, although with limelight.

• LabVIEW code running on the RoboRIO acting as the server.
• Limelight is connected, posting and reading values to NT successfully, verified by LabVIEW code running on RIO and LabVIEW client code running on dev laptop.
• LabVIEW client code running on dev laptop reads and writes values successfully.
• OutlineViewer appears to read the values once on startup and stops updating. Setting values does not work. I have tested against a clean frc java program and OutlineViewer reads and writes values normally

The odd thing is OutlineViewer connects and updates normally to a LabVIEW server running on localhost.

[brhea]

I started an example program on the roborio and the NTserver worked fine. We're able to continue development/testing of our vision detection.

I also tried calling the alias's that you referenced to set system to ro or rw. I could not find a way to call an alias and have it execute properly. However, I was able to create an myro.sh and myrw.sh batch file and copy the commands assign to the aliases to the batch files and it worked perfectly. Thanks!

[brhea]

Do you think the Labview support will fix this before end of build season. Our team is on the cusp of deciding if we want do develop a really onerous work around in labview or punt Labview and become a Java team. I think we have to make the decision this weekend.

[rzblue]

Are you having issues with reading values from the pi from within LabVIEW or just from OutlineViewer?

[brhea]

Reading only seems to be a problem within Outline Viewer (and also shuffleboard). Note that the NT server is on labview on the rio.

These two apps seem to read the values when the programs load but then they never update.

I also have some issues with Outline Viewer writing double array values back to the PI. The PI initializes the variables (writes to the keys one time) to create the key. Then I try to change the key in Outline viewer and I cannot edit the array values,,, I open the array, edit, then click add and the values don't change. This works for a string array.

Note that these are probably 2 separate issues.

[brhea]

Array issue is https://github.com/wpilibsuite/OutlineViewer/issues/64

[PeterJohnson]

This has been confirmed to be a LabView server issue; updates coming from a client are distributed to other clients in such a way that C++/Java clients ignore the distributed values. They have figured out the root cause, but I don't know the timeline for making a fix available.

[PeterJohnson]

This was fixed in the LabView 2019.2.0 update / v14 roboRio image.