[SLAB-Mr.Thomas]

Me too! I was about to post this same error. We use C++ with the SampleRobot. The Java runtime for the grip gets the error when we execv it. Tested Java runtime with a Hello World and that worked fine.

Can't get grip to work on the driver station laptop either - don't know how to get a roboRIO USB camera image to it so no grip for us right now.

Now the next day and this is brutal but more hours of frustration and I out lasted it and got some results.

Doesn't seem to do the same thing 2 times in a row but the out of memory errors subsided and the robot program and the TableViewer are able to see changing values in realtime.

GRIP is running on the roboRIO using the USB camera.

What seems to give the most repeatable runs was in the driverstation GRIP pipeline development turn off all the eye preview images, then download the grip files, and close GRIP on the driverstation.

Then on the roboRIO deploy the robot code.

Still, rerunning GRIP sometimes gives varying results such as out of memory or Port 175 error 111 - connection refused. Rebooting everything helps.

GRIP leaves a lot of trash on the roboRIO in the /tmp directory and the /home/lvuser directory. Tedious going through tmp deleting files.

Other than some random crashes and failure to restart cleanly for unknown reasons, the only bug that's obvious is selecting ContoursReport publishing values area and height creates NetworkTables keys height and centerY usually and sometimes solidity and height.

I did have to change the sample program a bit:

auto grip = NetworkTable::GetTable("grip");

had to be changed. The "auto grip =...." was brought into the class, made a smart pointer and initialized in the constructor initialization list. Then it worked. Couldn't resist a few other "improvements" to the sample but they probably only help troubleshooting and didn't make the code run any better.

GRIP could be a valuable vision processing program when it's stable. Hope that is very soon so we can use it.

More thinking: Conjecture about one of the errors related to unable to connect. When the roboRIO starts its robot code the GRIP process is created, too. When another robot program is deployed in Eclipse it starts immediately but has a connection refused error. My conjecture is the GRIP process from the previous robot code start is still running and attempts to start another such process for GRIP fail. If I manually kill the grip process and deploy again, it works okay.

How can we get the GRIP cleaned up to allow another process to run?

And I'm still stewing about all the trash files left behind each GRIP run and am concerned about that GRIP log that is continuously being written to.