Latest Eclipse plugin breaks OpenCV/Camera Server on Rio

I’ve been banging my head for a week now where the vision software crashes on the robot every time you call cs::CvSink.GrabFrame in C++. I see an “unresolved symbol” error in the log just before it crashes. This method is called to grab a frame. Here’s what’s logged:

/home/lvuser/FRCUserProgram: symbol lookup error: /home/lvuser/FRCUserProgram: undefined symbol: _ZN2cs20GrabSinkFrameTimeoutEiRN2cv3MatEdPi
➔ Launching «’/home/lvuser/FRCUserProgram’»

And this just repeats every time the vision thread is launched.

I found the solution was to remove the latest Eclipse plugins (version 3.1) from First and install the old one (version 1.1) and it works again.

Where do we post the bug report on this?

I’ve posted bug reports here a long time ago: https://bugs.eclipse.org/bugs/

The reason for the error is that the shared libraries on the roboRio are not up to date with the user program. The Eclipse plugins should automatically be copying the new libraries to the roboRio for you (along with the user program) when you do a “WPILib C++ Deploy”. How are you copying the user program to the roboRio?

Bugs can be reported on GitHub (e.g. at the cscore link in my sig).

I suspected something with the tools & naming since nm shows everything resolving on my laptop.

To deploy, after a successful build I click on the project name, click on:

Run -> Run As… -> WPILib C++ Deploy

Is there something else I should be doing?
It copies the program out there and kills the process and restarts it.
But then it just keeps looping after it crashes with the name error.

Where and what libraries should I copy to the Rio? I wouldn’t mind doing it manually to get past that hump and use the update.

I’ll have to wait until I get home to access github. The school here blocks github…

That’s the correct command; the library copy should be done as part of that process (build.xml lines 133-151). Have you changed your roboRio’s admin account or password? We do want to figure out what’s the underlying cause the libraries aren’t copying for you, but to get you up and running, the libraries need to be installed to /usr/local/frc/lib/ on the roboRio from your computer’s $HOME/wpilib/cpp/current/lib (libHALAthena.so, libntcore.so, libwpiutil.so, libopencv*.so.3.1, libcscore.so, and libwpilibc.so) and also from $HOME/wpilib/user/cpp/lib (*.so) if you’re using any 3rd party libraries like the CTRE ones.

I think the problem was a confused: WPI_Native_Libraries.properties file.
I was able to get it to update the libraries by moving that out of the way on the RoboRio. We have several people that have been doing deployments and it was very mixed up with duplicates and changes on it as some folks had the update and others didn’t.

So it look like just removing that file and doing a deployment gets the correct libraries deployed.

We found this problem a few times between the various machines that pushed code to the RoboRio… Because we’re not using Eclipse, we just modified the build.xml in the lib to ignore the check and push all the libraries every time. It takes a few seconds longer, but it’s a time savings in the long haul.

Yes, deleting WPI_Native_Libraries.properties file will result in a clean deploy of all libs (should have mentioned that). The reason for its existence is to reduce flash wear and speed up deploys by only copying the files if they’ve actually changed (by caching checksums). We may re-look at this for next year to see if we can come up with a more reliable method for this (part of the challenge is that the Eclipse plugins only have limited SSH capability, so each SSH command is a new connection).

Would it be too late for this year to add a “force-deploy” task that’s not the default to give teams a “quick-fix”?