NVIDIA Jetson TK1

[dbbones]

Hello jetsons...

Team4915 is using a TK1 this year (for the first time) and we wondered if anyone has thoughts on best-practices for ensuring that vision software is running during competition.

The goal is to ensure our attached usb camera and associated vision services are running across power-down/restart events.

Currently, we're hoping that installing our software as an init.d service will just work, but we're encountering issues that may be related to intermittent network connectivity (during the reboot sequence). We've also seen some threads about usb power and auto-login may also be contributing to this.

Our current workaround is to ssh in and restart our services, but this seems fragile in a real competition setting.

Any comments are greatly appreciated!

Thanks!

Dana Batali, Spartronics 4915 mentor

[dbbones]

For future jetsonians, here's where we've gotten on this. No claims are made that this is the best approach, but it does seem to work for us (so far).

1. we built and installed a custom mjpg-streamer webserver on the jetson to serve mjpg streams to the driver station... This boots just fine as a standard init.d script.

2. our custom-built mjpg-streamer http server has a trivial extension that allows a remote webbrowser to control parameters of our vision algorithm. This just launches a shell script, which can be modified as desired. We haven't gotten any more fancy than this, but could imagine going further into CGI land or beyond. This would require more webserver hacking and doesn't seem justified at this point.

The result: after powering on the robot, the webserver is available on port 80 on the jetson. (We enabled mDNS services on ubuntu via avahi-set-host-name). Now we can launch our imaging service and it drops occasional images for delivery by mjpg-streamer to the smart dashboard on the driver station.

Issues: if we suffer from brown-out on the robot, the jetson powers off and requires a physical button-press to recover... Anyone have any thoughts on that issue?

Finally: to further protect the jetson, we invested in a power conditioning device. There is some discussion of this issue in the TX1 thread, but here's the one we landed on fwiw:

http://www.amazon.com/gp/product/B011KLQNRG

[lethc]

Originally Posted by dbbones

For future jetsonians, here's where we've gotten on this. No claims are made that this is the best approach, but it does seem to work for us (so far).

1. we built and installed a custom mjpg-streamer webserver on the jetson to serve mjpg streams to the driver station... This boots just fine as a standard init.d script.

2. our custom-built mjpg-streamer http server has a trivial extension that allows a remote webbrowser to control parameters of our vision algorithm. This just launches a shell script, which can be modified as desired. We haven't gotten any more fancy than this, but could imagine going further into CGI land or beyond. This would require more webserver hacking and doesn't seem justified at this point.

The result: after powering on the robot, the webserver is available on port 80 on the jetson. (We enabled mDNS services on ubuntu via avahi-set-host-name). Now we can launch our imaging service and it drops occasional images for delivery by mjpg-streamer to the smart dashboard on the driver station.

Issues: if we suffer from brown-out on the robot, the jetson powers off and requires a physical button-press to recover... Anyone have any thoughts on that issue?

Finally: to further protect the jetson, we invested in a power conditioning device. There is some discussion of this issue in the TX1 thread, but here's the one we landed on fwiw:

http://www.amazon.com/gp/product/B011KLQNRG

We are using the Jetson TK1 as well, and we also had the issue of needing a physical button press to start it at times. We did some research and found this. Essentially, you need to remove the C6D4 capacitor from the board to get it to always power on when it's receiving power. We did this with pliers.

Would you be willing to share your code? Your webserver implementation sounds awesome.

[ctetrick]

Originally Posted by marshall

The Zed is a fancy camera but it was born for this kind of stuff unlike the Kinect, the RealSense Cameras, and even the existing OpenCV libraries, which can't easily sync frames between cameras.

That being said, if you are going to go the OpenCV route then I would suggest looking at the PlayStation Eye cameras. You can also hack them to sync frames. They are very inexpensive and the frame rates can be jacked up to where they'll work great. I do recommend a reliable USB hub for those though into the Jetson.

Marshall, got any suggestions on a good usb 3.0 hub? preferably one that is likely to work with the TK1/Zed combo.

[KJaget]

Originally Posted by sanelss

Anyone else trying to use a ZED camera with a tk1? We got it working but it's not looking promising.

First off, you CAN'T use any sort of hub with the zed and usb 3. I've tried two different usb 3 hubs and it's an issue regardless. if you use a hub with other peripherals the image corruption will make it completely unusable. I had to buy a mini pci-e usb module to hook the keyboard and mouse up to so the ZED is the only device on the usb 3 port. Even with that, there is still some occasional image corruption, but at least it's usable.

The other issue the depth viewer example only gets 5-8 fps..... that's abysmally slow. Even other examples without as much heavy lifting don't get much better than that....

Have you set the CPU and GPU clocks to max? See http://elinux.org/Jetson/Performance.

Have you reduced the resolution, fps and depth reconstruction quality of the Zed processing? Take a look at the Zed camera constructor and init calls to adjust those parameters.