Support Raspberry Pi

[ThomasJClark]

It would be cool if GRIP ran on a Raspberry Pi. To do this, we need:

• A Pi build of libntcore
• A Pi build of JavaCV
• A more flexible deploy too
  • Probably with defaults suited to the roborio, but have the username/password/directories customizable

GRIP would likely only work in headless mode (I don't think JavaFX is supported on arm/linux)

[bradamiller]

I have a pi set aside to bring in tomorrow anticipating this discussion. I wonder if it would work as a test if we created the directories on the pi so it looks like a roboRIO?

Brad

_____________________________

From: Thomas Clark notifications@github.com
Sent: Thursday, January 14, 2016 9:14 PM
Subject: [GRIP] Support Raspberry Pi (#366)
To: WPIRoboticsProjects/GRIP grip@noreply.github.com

It would be cool if GRIP ran on a Raspberry Pi. To do this, we need: A Pi build of libntcore A Pi build of JavaCV A more flexible deploy tool Probably with defaults suited to the roborio, but have the username/password/directories customizable

GRIP would likely only work in headless mode (I don't think JavaFX is supported on arm/linux)

—
Reply to this email directly or view it on GitHub.

[ThadHouse]

Pi 1 will not work for sure, It's Arm v6 whereas the RoboRIO is Arm v7. I did try RoboRIO ntcore builds on a BeagleBoneBlack, and they did not work either. I'm guessing because of the VFP vs HardFloat differences. I'm actually setting up a build server to build ntcore for Armv7 hf and android. The builds I'm building can be found here http://198.199.94.5/ntcore/ if you want to try them out. The arm-linux-gnueabihf should be the builds that work on the Pi 2. They will not work on a Pi 1, but I will look at trying to find a Pi 1 cross compiler, and then can add it really easily.

[JLLeitschuh]

The deploy script is already incredibly flexible. The UI components are extensible. I could probably get this working in ~1.5 hours.
(Getting the UI to look right will probably take the most time)

[bradamiller]

I wouldn't spend much time on a pi 1 build where the the performance is so much less and a pi 2 is only $40. Maybe I'll have time to play with it over the weekend, but I'm bring a few pi 2 boards if the grip guys want to try.

[ThadHouse]

I just a bit of testing. Running my build on a BeagleBone Black started to load correctly, however then gave an error saying libstdc++.so.6 wasn't right. Spent a while trying to debug that, but couldn't. Don't know enough linux to debug that more. The cross compiler was GCC 4.9.3, but my BBB only had 4.9.2, and I couldn't figure out how to upgrade it. Hopefully it works on a Pi 2, or you can get GCC 4.9.3 onto it.

I also retested the RoboRIO image on the BBB. It gave a bad format error when trying to load. So that build will almost certainly not work on a Pi.

[ThadHouse]

I added a zip of the lib folder used for cross compiling to the ntcore folder. That should have all the libraries needed if any more are needed.

[ThadHouse]

Ok. So by preloading the libstdc++.so.6 in the zip folder, the cross compiled version started working on my BeagleBone Black. So the builds should work on Pi 2 either without issues, or require preloading a library before running, which shouldn't be too bad.

EDIT: Tested on my brand new CHIP as well, and the builds worked there too, as long as you had the specific libstdc++.so.6. So I put that file alone in the ntcore directory. And all you should need to do is when you run the program set LD_LIBRARY_PATH to whatever folder you put that library in.

[dcodeh]

Could you elaborate on the process you used to get this working on the BBB/Pi 2?

We have been attempting to re-build with some of the suggestions in this thread to no avail.

[ThadHouse]

I didn't test getting the full GRIP suite working. I was only doing testing to see if I could get NetworkTables working properly.

[multiplemonomials]

I also got an error message about how the JVM couldn't load the libraries when I tried GRIP on my Beaglebone Black (running Arch Linux). However, ThadHouse's ntcore.so and libstdc++ didn't fix it for me. Then, I tried rebuilding ntcore on the BBB, and using that .so file fixed the error message about ntcore.so. I then rebuilt all of OpenCV and the JavaCPP bindings (javacpp-presets) using arm-linux-gnueabihf-gcc from the AUR in an Arch VM, and then substituted them into the GRIP jar file. It WORKED! I guess the libjniopencv_foo libraries in opencv-3.0.0-1.1-linux-frc.jar have the wrong ABI for the BBB (and others?).

If you want to try it, just scp the this file and a GRIP save file onto your coprocessor, and run with

java -jar GRIP-archlinuxarm-deployable.jar test.grip

[ThadHouse]

You should have been able to use the jar in the Java folder, but maybe it doesn't support Arch. I've only ever tested it on Debian based OS's, and only the actual library, not the jar. I'll try the jar tonight on my BBB and Pi 2.

And it's not surprising that the FRC jar does not work. The RIO is is Soft Float, whereas Pi's and BBBs are Hard Float.

[multiplemonomials]

It was a journey, but I completed the first two items on your list of what was necessary for Raspberry Pi support. I built NTCore, opencv, and the OpenCV JavaCPP Preset for linux-arm. Not entirely sure about the ABI, these were compiled with GCC 5.3.0 arm-linux-gnueabihf on Arch Linux. I also added the prebuilt natives (which existed for every platform except linux-arm), and edited the build.gradle file to add all of this stuff into the jar. I changed the core project dependencies block to this:

dependencies {
        compile name: 'javacpp-opencv-preset'

        compile name: 'NetworkTables-3.0.0-natives-arm'    
        compile name: 'opencv-natives-linux-arm-hardfloat'
        compile name: 'opencv-natives-linux-x86'
        compile name: 'opencv-natives-linux-x86_64'
        compile name: 'opencv-natives-macosx-x86_64'
        compile name: 'opencv-natives-windows-x86'
        compile name: 'opencv-natives-windows-x86_64'

        compile group: 'org.bytedeco', name: 'javacpp', version: '1.1'
        compile group: 'org.bytedeco', name: 'javacv', version: '1.1'
        compile group: 'org.python', name: 'jython', version: '2.7.0'
        compile group: 'com.thoughtworks.xstream', name: 'xstream', version: '1.4.8'
        compile group: 'org.apache.commons', name: 'commons-lang3', version: '3.4'
        compile group: 'com.google.guava', name: 'guava', version: '18.0'
        // We use the no_aop version of Guice because the aop isn't avaiable in arm java
        // http://stackoverflow.com/a/15235190/3708426
        // https://github.com/google/guice/wiki/OptionalAOP
        compile group: 'com.google.inject', name: 'guice', version: '4.0', classifier: 'no_aop'
        compile group: 'com.google.inject.extensions', name: 'guice-assistedinject', version: '4.0'
        compile group: 'edu.wpi.first.wpilib.networktables.java', name: 'NetworkTables', version: '3.0.0-SNAPSHOT', classifier: 'desktop'
}

JavaCPP doesn't distinguish between hard and soft float ARM (I assume that's the crucial difference between the RPi and the RoboRIO), and there's no easy way to make it do so. Therefore, natives for the RoboRIO and other Linux boards cannot coexist in the same jar. I think it would make sense to have two jars that are deployable: one with some or all of the above natives, and one with just

        compile name: 'opencv-linux-arm-roborio'
        compile name: 'NetworkTables-3.0.0-natives-roborio'

The user could select whether to deploy to a "generic" coprocessor, which would use the multi-native file, or a RoboRIO specifically, which would use the other jar with just those natives.

Also, arm-linux does actually have OpenJFX, so using these libraries would allow GRIP's GUI to run on embedded Linux boards.

I hope this is useful to you, and I hope we can get this working. You can download the libs here.

Things I built:
javacpp-opencv-preset.jar: The Java code which interfaces directly with the native OpenCV libs
opencv-natives-linux-arm-hardfloat.jar: The OpenCV 3.0.0 library natives, and the JavaCPP-generated interface libraries
NetworkTables-3.0.0-natives-arm.jar: libntcore.so, built for linux-armhf