The student programmers here at Team 900 have done a wonderful job of getting a nVIDIA Jetson TK1 to process images from an HD(Logitech C920) USB camera, detect our Frisbee targets, and send the information to the roboRIO to act on. The code is a tad bit messy in a “few” places, and we could probably speed up the processing, but hey, it works.
We have the Jetson TK1 powered through the VRM(Voltage Regulator Module) on the 12v@2A bus.
Team 3826 is trying to use the Jetson. We pulled the source code from the link “nVIDIA Jetson TK1 Code:”. We’ve tried to compile it and are getting the following errors:
$ make
– Configuring done
– Generating done
– Build files have been written to: /home/mgb/900_opencv/frisbeelocating
Scanning dependencies of target testing
50%] Building CXX object CMakeFiles/testing.dir/gpuTesting.cpp.o
c++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
c++: error: unrecognized command line option ‘-mfpu=neon-vfpv4’
c++: error: unrecognized command line option ‘-mvectorize-with-neon-quad’
make[2]: *** [CMakeFiles/testing.dir/gpuTesting.cpp.o] Error 1
make[1]: *** [CMakeFiles/testing.dir/all] Error 2
make: *** [all] Error 2
[1]- Done emacs Makefile.cmake (wd: ~/900_opencv/frisbeelocating/CMakeFiles)
(wd now: ~/900_opencv/frisbeelocating)
[2]+ Done emacs CMakeCache.txt
I’ve found the -mcpu can be changed to -mtune using the same parameter to remove the -mcpu error, however, we don’t see a work around for the other two errors.
We’re compiling on ubuntu on a VirtualBox VM running on Win7 with the Jetson TK1 installed. Have this been seen before? Any suggestions?
Looks like you’re compiling for x86 rather than ARM. Remove those two ARM-specific options and the code should build correctly. Or alternatively, you could push the code to a Jetson board and build there and things should just work.
If you’re trying to cross-compile (build ARM binaries on an x86 Linux host machine) you’ll need to point to the correct compiler. The compiler name is usually of the form “arm-none-linux-gnueabihf-g++” or the like. Sometimes “none” is called “unknown” instead, but the general idea is the same.
If you are planning to run on x86, be aware that the code is written to run on the GPU. If I remember there are fallbacks to run on the CPU, but the CPU code wasn’t the focus of our development effort so it may be different than the GPU code.
We are compiling for the Jetson, but building on a Ubuntu system. We did take you suggestion and point to the correct compiler, we are not compiling. We are now working through some what I think are link problems and pointing to x86-65 linux libraries instead of ARM libraries.
We used a Jetson this year, and compiling OpenCV on the Jetson took about 40 minutes utilizing all 4 CUDA cores. I wouldn’t worry too much if you have to do it on the board.
40 minutes is insane. Our ODROID X2 is able to compile the latest OpenCV with a gazillion features in about 10-20 minutes. How many jobs are you using? I’d suggest you use at least -j 6 or maybe -j 8 when compiling on the jetson. It’s got plenty of power for that!
How is that working out? The sticker on our Jetson suggests that we need a 4.8A power supply (which seems extremely high for a mobile chip). Have you had any slow-downs or drop-outs from consuming too much power?
I can’t find the thread, but I believe I’ve seen someone from NVIDIA mention that 4.8A was way overkill, and they would be refining the requirements later. On my bench setup, I haven’t seen the Jetson draw more than 1.5 amps at 12V, and this was during testing of low voltage conditions on the regulator.
Thought I would take a moment to update this thread with some sample video from Palmetto this year:
We’re tracking the recycle bins. I can’t talk a lot about the technical nitty gritty but I can tell you that it is using OpenCV and it is running on the GPU of the Jetson. There are another couple of folks who can shed more light on the technical details if you are interested.
All of them as far as I know. The FPS is in the video but somewhere between 5 and 10 from what I know about it. Hoping to double that with some upgrades after the season is through and we can put more effort into this.
I’d be more than happy to help you optimize the code, as 1706 is going to be getting a jetson board to experiment with.
You must be running some very inefficient code if you’re only getting 5-10 fps with gpu accelerated opencv (http://opencv.org/platforms/cuda.html)…We are using a depth camera and are getting 26 fps on the odroid XU, which has the same amount of ram and an older arm based cpu and cannot be gpu accelerated.
Anyways, the video you posted is really cool and seems to work very well. Good job on whoever wrote that. I’m sure many teams would eat up a whitepaper about it.
Awesome sauce! One of the students has volunteered to work on a white paper but I’m not sure how far along he is on that. I believe he is working on it though. I’ll be pestering him about it over the next few months.
I can’t speak to the efficiency of the code but it was written largely by students and it is doing what we were aiming for. I suspect there are a lot of improvements we can make but I know the resolution has a lot to do with the lower frame rates. We’ll keep perfecting it though and it will get published publicly at some point… likely alongside the white paper.
Team 4534 used the same system this year, it might be worth building a library for the Rio. Let us know if you have any questions or want to compare how our systems worked.
