Issues with NetworkTables library install on Jetson TX1

So earlier today I installed NetworkTables on an nvidia Jetson TX1. I used cmake (instead of Gradle because I was having issues getting it to build on arm) to build ntcore. After that, I just did “make” and “sudo make install” and added the

#include <networktables/NetworkTable.h>

line to my .cpp file and

include_directories("ntcore")
include_directories("ntcore/include")
link_directories("ntcore")
target_link_libraries(client ntcore)

to CMakeLists.txt.

Now whenever I try to “make” it just spits out this:

In file included from /usr/include/c++/5/mutex:35:0,
                 from /usr/local/include/networktables/NetworkTable.h:12,
                 from /home/ubuntu/Desktop/Vision2017/client.cpp:3:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support \

as well as dozens of other errors found (I’m presuming from a version mismatch) in the NetworkTable library code.

Adding set(CMAKE_CXX_FLAGS “-std=c++11”) didn’t help the cause. I feel like this is a really easy error to fix but I’m just overthinking it.

Couple of side notes:

If I remove the #include <networktables/NetworkTable.h> line from my code it “makes” (compiles? I don’t really know what to call this) successfully but only if I run cmake with the -DCUDA_USE_STATIC_CUDA_RUNTIME=OFF flag. Is there a way I can add this to CMakeLists.txt so I don’t have to dig up the flag every time I change CMakeLists.txt in the future? I noticed 900 had set (CUDA_USE_STATIC_CUDA_RUNTIME OFF) in CMakeLists.txt but adding that line didn’t work for me.

README.md for the ntcore repo on Github says that

ARM Toolchain - To crosscompile ntcore for the roboRIO, you must have the FRC ARM toolchain installed, which can be found here.

Is this bullet point something I should care about when working on the Jetson? Or does this only apply for the RIO?

Thanks in advance

Run “make VERBOSE=1” to verify that the -std=c++11 option made it into the command line. Your modification is probably being overwritten somewhere else? The best way to set those variable is to use add_definitions(). Other option to preserve previous settings is something like set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -std=c++11”) - that way you add to the list of flags rather than replacing them.

If I remove the #include <networktables/NetworkTable.h> line from my code it “makes” (compiles? I don’t really know what to call this) successfully but only if I run cmake with the -DCUDA_USE_STATIC_CUDA_RUNTIME=OFF flag. Is there a way I can add this to CMakeLists.txt so I don’t have to dig up the flag every time I change CMakeLists.txt in the future? I noticed 900 had set (CUDA_USE_STATIC_CUDA_RUNTIME OFF) in CMakeLists.txt but adding that line didn’t work for me.

This was weird for us too. We’re still working at it, but good news is if you do
-DCUDA_USE_STATIC_CUDA_RUNTIME=OFF once it stays set unless you blow away the entire project and start over so it isn’t all that painful.

README.md for the ntcore repo on Github says that

Is this bullet point something I should care about when working on the Jetson? Or does this only apply for the RIO?

Only applies if you’re cross compiling. That is, if you’re building on a system other than the one you’re running on. Don’t do it for the Jetson.

Using add_definitions() fixed all of the version errors I was having when “making” my source code. Thanks for this tip.

Now I’m having issues trying to install cscore… Gradle is having a hard time finding a C++ compiler. How can I add the path to a C++ compiler in the system path?

Edit: Fixed the C++ issue… I think? Now I’m getting errors with Java and Gradle.

Execution failed for task ':native:compileJava'.
> Could not initialize class net.ltgt.gradle.errorprone.ErrorProneCompiler$SelfFirstClassLoader

and now I’m getting errors which look like this (what even is life anymore):

Could not create service of type FileCollectionSnapshotterRegistry using TaskExecutionServices.createFileCollectionSnapshotterRegistry().
> Could not create service of type CachingFileHasher using TaskExecutionServices.createFileSnapshotter().

Execution failed for task ':arm:linkCscoreSharedLibrary'.
> A build operation failed.
      Linker failed while linking libcscore.so.

This thread here makes me think it’s near impossible to install cscore on the Jetson. I think we will look for an alternative way to stream video.

The Jetson can be a pain. I would suggest looking into gstreamer. You can set up a gstreamer pipeline to autostart when the jetson boots up and then on the DS you can install gstreamer and receive the video. You could also create your own MJPEG streamer.

Try adding this to your CMakeLists


option(CUDA_USE_STATIC_CUDA_RUNTIME OFF)

Thanks for the idea. Can we use gstreamer to stream multiple cameras and output from an OpenCV program? I really want to avoid having to make my own MJPEG streamer…

If you’ve tested this in the past… what settings do you recommend for gstreamer? H.265 or H.264?

This worked for me. Thanks for the tip.

On a side note: Is there a list of syntax/guide for using CMakeLists on the Jetson? I feel like all of the Stackoverflow/NVidia forum threads just give information which doesn’t work…

Gstreamer can be used to stream multiple cameras. I have not used it in an openCV program but it looks like it is possible to implement it in a video capture. A quick google search gave me this which adds the gstreamer pipeline onto a video cap.

  cv::VideoCapture cap("v4l2src ! video/x-raw, framerate=30/1, width=640, height=480 

.
I have used gstreamer before for testing without streaming from openCV and it worked. However it cut out when FMS kicked in when we tried it but I think it was a bandwidth limit. Here is the code we used

Jetson side

 gst-launch-1.0 v4l2src device=/dev/video0 ! image/jpeg, width=640, height=480, framerate=30/1 ! nvjpegdec ! video/x-raw ! omxh264enc control-rate=2 bitrate=2000000 ! video/x-h264, stream-format=byte-stream ! udpsink host=10.63.25.5 port=5800 

You can add another camera by using the same code but a different port and v4l2 device. Also make sure host= the ip of the DS. The code above gets the camera stream from index 1, resizes the image to 640 x 480, sets the framerate, decodes the stream so that it can change the bitrate and control rate, re-encodes it and sends it to the DS. If you guys also get a bandwidth error try changing bitrate to something lower.

DS side
I could not find the code for the DS but you basically use the same gst-launch with the port and host. Also on windows you have to change a couple things.

I have not found anything yet. There is a lot of outdated info out there. I remember when we first got the Jetson we copied example code from OpenCV and it threw errors :smiley: