Quantcast
Channel: JetsonHacks
Viewing all 339 articles
Browse latest View live

What is Programming Again? – Thoughts on Programming

$
0
0

Exactly what is programming again? We’ve been discussing some programming languages, and some assumptions about what programming should be like today. Back in the 1973 Bret Victor gave a seminal talk on “The Future of Programming”. Well, actually he gave the talk in 2013 as if he were giving the talk in 1973 at a DBX Conference. Confused? This is a great talk that is about 30 minutes long. Looky here:

The overhead projector was much more fun than a PowerPoint deck.

Discussion

Usually there isn’t homework in these articles, but I think it’s useful to take a look at different perspectives on any given subject so that you can better understand some of the ramifications of the bias and decision-making based on a given set of assumptions.

If you’re of a certain age and background, you have been exposed to the ideas in the above talk. You probably have implemented your own compilers and interpreters, built your own domain specific languages (DSLs), and other computer science-y things.

If you have are a bit younger, you should have been given this information as background as part of your computer science education. However, Bret makes an absolutely brilliant and fundamental point: a couple of generations now view programming as dogma. People know how to program, here’s how you do it and here’s the language that you use. The program architecture stacks are given. The OS, the graphics library, the desktop/main screen, APIs, and so on.

Run time environments

Parts of this are true. If you are programming Windows boxen, you have a very well-defined set of tools it is in your best interest to use if you want your program to work and for you to keep your job. Same with Macintosh and iOS. Android, check. If you are programming web boxen in the cloud, then you get a much broader selection of tools. You might get to use one or two programming languages on the server, and then deliver some type of magical javascript/css mish-mash to the browser.

Lock-In

It is in the interest of each of the computing ecosystems to have everything work together. So each platform has the same calling conventions, and everyone is worried about things like the size of any particular number being sent to a particular API in case the API doesn’t understand such things. In other words, most of the arguments about programming are literally bookkeeping. The size of this particular number, where this particular memory gets allocated, where and how should things be stored. People even come up with commandments such as DRY (Don’t repeat yourself!) because it makes bookkeeping harder. Up until fairly recently, things work as they do today with this one model, from this one perspective.

All this works. Until it doesn’t.

Let’s look through a different perspective, one that comes from biological systems. Now people disagree as to if humans are more sophisticated computational devices than computers, but one thing is clear. Humans have a different way of calculating and learning than current computers.

Humans also don’t seem to obey the ‘commandments’ of computing. For example, each cell in a human (except for erythrocytes, you’ll point out) has DNA in it composed of about 3 billion base pairs per cell. DNA is a map of just about everything physical in a human. And it’s replicated about a trillion times give or take in a 150 lb person. At a hardware level, biologics repeat themselves. People have some protocols built-in, but are flexible in negotiating different types of communication.

For example, two people who speak different languages can still communicate though not as efficiently as if they are both fluent in the same language. An important point is that given some time, the two people will be able to communicate efficiently. Computers find that difficult.

Leave this Place

Surprisingly, if you give a human a set of protocols for a complex task, unlike a computer they can rarely execute the protocols correctly on the first try. In fact, it may take them several thousand hours to become extremely proficient on some tasks such as playing a musical instrument or playing a sport. But one of the main attributes that humans have is the ability to learn new things, and improve on what they were originally taught.

If you train an artist like a computer, you might first try giving them a coloring book to paint with a very specific color between the lines until they are proficient at painting. Then teach them to draw a straight line by giving the mathematical equation for a line (don’t forget negative slopes!), then a curve, and so on. You might share this actual idea with an artist, and watch their reaction. You are sure to be amused.

Throughout history people have been training to be artists, and each generation tends to bring with it different ideas and evolution on what it means to actually be an artist. Pointedly, we don’t do that with computers in the traditional sense. The question is, “Can we?”

To the Future!

Think about what was discussed in the video, and think about what’s going on now. There are a whole lot of people centered directly and who work only in the dogma world. People are just now getting around to start thinking in the manner of the ideas in the video.

A biology inspired metaphor, called neural networks, is similar to the ideas discussed in the video. The first randomly wired neural network machine (SNARK) was built by Marvin Minsky in … 1951! The idea itself isn’t new, but the discovery of backpropogation in 1975 by Werbos and the application of GPUs on the problem in 2012 by Geoff Hinton now make teaching machines how to “think” possible.

You see what a great conflict is about to happen! On one hand you have the standard guard, who think of the computer as a conscript who needs to be told exactly when and what to do, no deviation. This number is an unsigned 32 bit integer soldier! On the other hand, you have a group of people who believe you just show the computer a dataset and a goal, adjust some dials, sliders, and buttons, and have the computer figure out what it needs to know. Drive a car? Sure, give it enough sensor footage and it will figure it out. Play the game Go? Shown all the games of Go ever played, and Alpha Go can beat almost any human.

Of course you will ask, “How do you know that the computer learned everything it needed to know, for example, to drive a car safely?” The standard guard will go on and on about the edge cases and rigorous unit tests for each and every situation that they lovingly hand coded. The machine learning guys will have a sheepish smile and say “It works doesn’t it? Oh, and it does it better than people do now.” This will play out great in the courtrooms.

Conclusion

In earlier articles we talked about system level programming languages which tend to be rather standard guard, low-level, do exactly what I say types of things. Those languages are certainly valuable, but should be thought of as the building blocks for building more intelligent and interesting systems.

For machines like the Jetson Dev Kit, there are software tools built-in for leveraging machine learning. Train models on a large system, deploy them on the Jetson. At the same time, it is important to be able to reliably communicate with peripherals and other devices without having to worry about memory safety or storage minutiae. Use the proper tool for the proper job.

The take away is that a lot of people treat computers and languages like religions. Believe this, or believe that, the other side is completely wrong. Burn heretics and all that. Hopefully you take another view with perspective. Computer science is in its infancy. Actively seek out new ideas and explore them.

Here’s a handy trick. Take the calendar year and add a leading zero, i.e. 2016 becomes 02016. Programming started around 01950. If you think everything is known about computing in this small slice of the 10,000 year calendar, you need to think again.

As Alan Kay says “The computer revolution hasn’t started yet!”

The post What is Programming Again? – Thoughts on Programming appeared first on JetsonHacks.


ROS Rviz – NVIDIA Jetson TK1

$
0
0

RViz is a 3D visualizer for the Robot Operating System (ROS) framework. In a lot of cases, RViz is run on a visualization workstation to monitor a robot.

However, sometimes it is useful to have RViz running on the robot itself. On the Jetson TK1 in particular this presents an issue, because running RViz causes a segmentation fault. Here’s the workaround:

The basic story is that one of the dependencies (pcre) is unhappy and needs one of the environmental variables unset. This seems to make everything happy and fluffy again.

RViz
RViz

The post ROS Rviz – NVIDIA Jetson TK1 appeared first on JetsonHacks.

JetPack 2.3 Development Tools Released – NVIDIA Jetson Development Kits

$
0
0

JetPack 2.3 for the NVIDIA Jetson Development Kits is now out in the wild! JetPack 2.3 is available here.

JetPack

Background

JetPack is an on-demand package which installs all of the software tools required to develop on Jetson Development Kits. The JetPack installer includes host and target development tools, APIs and packages to enable developers full access to the Jetson Embedded Platform. JetPack runs on an Ubuntu 14.04 PC based host machine.

Major Features

The JetPack 2.3 release supports the Jetson TX1 Developer Kit, running 64-bit Linux for Tegra (L4T) 24.2 operating system (which is derived from Ubuntu 16.04) . JetPack 2.3 also supports the Jetson TK1 Developer Kit, running 32-bit L4T 21.5. In particular, many upgrades and features are added to the TX1. In addition to upgrading to Ubuntu 16.04, existing packages have been significantly upgraded and a GPU Inference Engine, called TensorRT, is now available.

TensorRT

TensorRT is a deep learning inference engine which can double the performance of applications such as image processing, object detection, and segmentation on trained neural networks which support the prototxt model format.

cuDNN 5.1

cuDNN provides a CUDA accelerated library for deep learning that includes standard routines for convolutions, activation functions and tensor transformations. cuDNN includes support for LSTM (long short-term memory), and other types of recurrent neural networks.

CUDA 8.0

The CUDA NVCC CUDA compiler now achieves a 2x faster compilation time. Support for cuBLAS and nvGRAPH is now available.

Multimedia API

Access to a low-level Camera API and V4L2 API have been improved for L4T 24.2

Conclusion

Again, you’re sitting here reading this when you can be installing new goodness? Go and get it!

The post JetPack 2.3 Development Tools Released – NVIDIA Jetson Development Kits appeared first on JetsonHacks.

Caffe Deep Learning Framework – 64-bit NVIDIA Jetson TX1

$
0
0

Back in February, we installed Caffe on the TX1. At the time, the TX1 was running a 32-bit version of L4T 23.1. With the advent of the 64-bit L4T 24.2, this seems like a good time to do a performance comparison of the two. The TX1 can now do an image recognition in about 8 ms! For the install and test, Looky Here:

Background

As you recall, Caffe is a deep learning framework developed with cleanliness, readability, and speed in mind. It was created by Yangqing Jia during his PhD at UC Berkeley, and is in active development by the Berkeley Vision and Learning Center (BVLC) and by community contributors.

The L4T 23.1 Operating System release was a 64-bit kernel supporting a 32-bit user space. For the L4T 24.2 release, both the kernel and the user space are 64-bit.

Caffe Installation

A script is available in the JetsonHack Github repository which will install the dependencies for Caffe, downloads the source files, configures the build system, compiles Caffe, and then runs a suite of tests. Passing the tests indicates that Caffe is installed correctly.

This installation demonstration is for a NVIDIA Jetson TX1 running L4T 24.2, an Ubuntu 16.04 variant. The installation of L4T 24.2 was done using JetPack 2.3, and includes installation of OpenCV4Tegra, CUDA 8.0, and cuDNN 5.1.

Before starting the installation, you may want to set the CPU and GPU clocks to maximum by running the script:

$ sudo ./jetson_clocks.sh

The script is in the home directory, and is also included in the installCaffeJTX1 repository for convenience.

In order to install Caffe:

$ git clone https://github.com/jetsonhacks/installCaffeJTX1.git
$ cd installCaffeJTX1
$ ./installCaffe.sh

Installation should not require intervention, in the video installation of dependencies and compilation took about 10 minutes. Running the unit tests takes about 45 minutes. While not strictly necessary, running the unit tests makes sure that the installation is correct.

Test Results

At the end of the video, there are a couple of timed tests which can be compared with the Jetson TK1, and the previous installation:

Jetson TK1 vs. Jetson TX1 Caffe GPU Example Comparison
10 iterations, times in milliseconds
Machine Average FWD Average BACK Average FWD-BACK
Jetson TK1 (32-bit OS) 234 243 478
Jetson TX1 (32-bit OS) 179 144 324
Jetson TX1
with cuDNN support (32-bit OS)
103 117 224
Jetson TX1 (64-bit OS) 110 122 233
Jetson TX1
with cuDNN support (64-bit)
80 119 200

There is definitely a performance improvement between the 32-bit and 64-bit releases. There are a couple of factors for the performance improvement. One is the change from a 32-bit to 64-bit operating system. Another factor is the improvement of the deep learning libraries, CUDA and cuDNN, between the releases. Considering that the tests are running on the exact same hardware, the performance boost is impressive. Using cuDNN provides a huge gain in the forward pass tests.

The tests are running 50 iterations of the recognition pipeline, and each one is analyzing 10 different crops of the input image, so look at the ‘Average Forward pass’ time and divide by 10 to get the timing per recognition result. For the 64-bit version, that means that an image recognition takes about 8 ms.

NVCaffe

It is worth mentioning that NVCaffe is a special branch of Caffe used on the TX1 which includes support for FP16. The above tests use FP32. In many cases, FP32 and FP16 give very similar results; FP16 is faster. For example, in the above tests, the Average Forward Pass test finishes in about 60ms, a result of 6 ms per image recognition!

Conclusion

Deep learning is in its infancy and as people explore its potential, the Jetson TX1 seems well positioned to take the lessons learned and deploy them in the embedded computing ecosystem. There are several different deep learning platforms being developed, the improvement in Caffe on the Jetson Dev Kits over the last couple of years is quite impressive.

Notes

The installation in this video was done directly after flashing L4T 24.2 on to the Jetson TX1 with CUDA 8.0, cuDNN r5.1 and OpenCV4Tegra. Git was then installed:

$ sudo apt-get install git

The latest Caffe commit used in the video is: 80f44100e19fd371ff55beb3ec2ad5919fb6ac43

The post Caffe Deep Learning Framework – 64-bit NVIDIA Jetson TX1 appeared first on JetsonHacks.

Build TX1 Kernel and Modules – NVIDIA Jetson TX1

$
0
0

In this article, we cover building a kernel onboard the NVIDIA Jetson TX1. Looky here:

Background and Motivation

Note: This article is for intermediate users, and the methods within are somewhat experimental. You should be familiar with the purpose of the kernel. You should be able to read shell scripts to understand the steps described.

When the Jetson TX1 was first shipped the operating system, L4T 23.1, was a hybrid 64-bit kernel, 32-bit user space affair. The only practical route to rebuild the kernel was to use a host computer because two different development toolchains are needed.

With the introduction of the L4T 24.X releases (currently L4T 24.2), both the kernel and the user space are now 64-bit. NVIDIA gives detailed instructions on how to build the system using a host computer. There are other good sets of instructions around, including “Compiling Tegra X1 source code” over at RidgeRun.

If you are building systems which require generating the entirety of Jetson TX1 system, those are good options. For a person like me, it’s a little overkill. Most of the time I just want to compile an extra driver or two as modules to support some extra hardware with the TX1. What to do, what to do …

As it turns out the 24.X kernels are mostly 64-bit, but there’s a sprinkle of 32-bit object files here and there. So here’s an idea: why not just grab the compiled 32-bit sprinkles from a host build, and put them into the kernel build process? That way the kernel and modules can be built on the Jetson TX1 itself without the need for a host development environment.

Now normally I am against developing on host machines when I can develop on a target machine. The TX1 is certainly competent enough for development. But in this case, it seemed worth it to build the needed 32-bit object files on a development host. Once the 32-bit files are built, it is a pretty straightforward task to build the rest of the kernel (with the associated modules) entirely on the TX1 itself.

Installation

The script files to build the kernel on the Jetson TX1 are available on the JetsonHacks Github account in the buildJetsonTX1 repository.

$ git clone https://github.com/jetsonhacks/buildJetsonTX1Kernel.git
$ cd buildJetsonTX1Kernel

There are three main scripts. The first script, getKernelSources.sh gets the kernel sources from the NVIDIA developer website, then unpacks the sources into /usr/src/kernel.

$ ./getKernelSources.sh

After the sources are installed, the script opens an editor on the kernel configuration file. In the video, the local version of the kernel is set. The stock kernel uses -tegra as its local version identifier. Make sure to save the configuration file when done editing.

The second script, patchAndBuildKernel.sh, patches one of the sources files to more easily compile the kernel.

$ ./patchAndBuildKernel.sh

Then the script copies over the 32-bit object files, and proceeds to build the kernel and modules using make. The modules are then installed in /lib/modules/

The third script, copyImage.sh, copies over the newly built Image and zImage files into the /boot directory.

$ ./copyImage.sh

Once the images have been copied over to the /boot directory, the machine must be restarted for the new kernel to take effect.

Spaces!

The kernel and module sources, along with the compressed versions of the source, are located in /usr/src

After building the kernel, you may want to save the sources off-board to save some space (they take up about 3GB) You can also save the boot images and modules for later use, and to flash other Jetsons from the PC host.

Conclusion

For a lot of use cases, it makes sense to be able to compile the kernel and add modules from the device itself. This particular technique is the first attempt at that. Note that it is new, and not thoroughly tested at this point. Use it at your own risk.

Note

The video above was made directly after flashing the Jetson TX1 with L4T 24.2 using JetPack 2.3.

The post Build TX1 Kernel and Modules – NVIDIA Jetson TX1 appeared first on JetsonHacks.

Sony PlayStation Eye – NVIDIA Jetson TX1

$
0
0

In our last article, we built a kernel for the Jetson TX1. In this article, we go over an example of how to build a simple module for the ubiquitous Sony PlayStation Eye for the Jetson TX1. Looky here:

Preface

Note: If all you are looking for is a prebuilt PlayStation Eye Camera driver module for the standard Jetson TX1 dev kit, check out a version on Github available here. The Github version is for the L4T 24.2 release, kernel 3.10.96-tegra.

To load the module:

$ git clone https://github.com/jetsonhacks/installPlayStationEyeTX1.git
$ cd installPlayStationEyeTX1
$ ./setupPS3Eye.sh

If you want to learn how to build modules, continue on.

PS3 Eye
PS3 Eye

Background

Way back in January 2015, we covered how to build a PlayStation Eye driver module for the Jetson TK1. The PS3 Eye’s inexpensive price, relatively good performance, and the ability to mod the device to detect infrared makes the camera a favorite among DIYers. The procedure for building the driver module for the camera is the very much the same as for the Jetson TX1.

The instructions assumed that the kernel source has been installed as described in the previous article.

$ cd /usr/src/kernel
$ sudo make xconfig

This will bring up the kernel configuration editor.

Here’s the path to enable building the camera device driver module:

Device Drivers -> Multimedia Support -> Media USB Adapters -> GSPCA based Webcams. Scroll down to OV534 OV772x USB Camera Drive

Make sure to save the kernel configuration. Next, prepare the modules, and then build them:

$ sudo make modules_prepare
$ sudo make modules SUBDIRS=drivers/media/usb/gspca

Once the module is built, it’s time to copy it over to the appropriate /lib/modules directory:

$ sudo cp /usr/src/kernel/drivers/media/video/gspca/gspca_ov534.ko /lib/modules/$(uname -r)/kernel/drivers/media/usb/gspca/

You can then insert the module:

$ sudo depmod -a
$ cd /lib/modules/$(uname -r)/kernel/drivers/media/usb/gspca/
$ sudo insmod gspca_ov534.ko

At this point, you should be good to go!

Note: If the insert module gives you an error, it main be because gspca_main is not inserted. gspca_main should be listed when you run:

$ lsmod

If gspca_main is not listed:

$ sudo insmod gspca_main.ko
$ sudo insmod gspca_ov534.ko

Running lsmod again should show both gspca_main and gspca_ov534 loaded.

Some shortcuts

Instead of copying the driver, you can run:

$ sudo make modules_install

Note that this will install all of the modules, and might cause issues.

Also, rebooting the system once the driver has been copied to the correct location should result in the driver being loaded, and mean that you don’t have to run the insmod command.

Conclusion

Hopefully by this point, you have an idea of how to build the kernel and auxiliary modules on the Jetson TX1. This is not an all inclusive description, but just a sample to get started.

The post Sony PlayStation Eye – NVIDIA Jetson TX1 appeared first on JetsonHacks.

Intel RealSense Camera Installation – NVIDIA Jetson TX1

$
0
0

Intel RealSense cameras can use an open source library called librealsense as a driver for the Jetson TX1 development kit. Looky here:

Background

Note: This article is intended for intermediate users who are comfortable with Linux kernel development, and can read and modify simple shell scripts if needed.

In earlier articles we talked about the Intel RealSense R200 Camera, which is a relatively inexpensive RGBD device in a compact package. The camera uses USB 3.0 to communicate with a computer.

Intel has made available an open source library, librealsense on Github. librealsense is a cross platform library which allows developers to interface with the RealSense family of cameras, including the R200. Support is provided for Windows, Macintosh, and Linux.

There are two major parts to getting the R200 camera to work with the Jetson. First, operating system level files must be modified to recognize the camera video formats. When doing development on Linux based machines you will frequently hear the terms “kernel” and “modules”. The kernel is the code that is the base of the operating system, the interface between hardware and the application code.

A kernel module is code that can be accessed from the kernel on demand, without having to modify the kernel. These modules provide ancillary support for different types of devices and subsystems.

A module is compiled code which is stored as a file separately from the kernel, typically with a .ko extension. The advantage of having a module is that it can be easily changed without having to modify the entire kernel. We will be building a module called uvcvideo to help interface with the RealSense camera. Normally uvcvideo is built-in to the kernel, we will designate it as a module as part of our modification. We will modify uvcvideo to recognize the RealSense camera data formats.

The second part of getting the R200 to work with the Jetson TX1 is to build and install librealsense.

Kernel and Module Building

Note: In the video above, the installation was performed on a newly flashed L4T 24.2.1 TX1 using JetPack 2.3

We have covered building the kernel for the Jetson TX1 in a previous article. Here are the major steps involved:

The script files to build the kernel on the Jetson TX1 are available on the JetsonHacks Github account in the buildJetsonTX1 repository.

$ git clone https://github.com/jetsonhacks/buildJetsonTX1Kernel.git
$ cd buildJetsonTX1Kernel

The script getKernelSources.sh gets the kernel sources from the NVIDIA developer website, then unpacks the sources into /usr/src/kernel.

$ ./getKernelSources.sh

After the sources are installed, the script opens an editor on the kernel configuration file. In the video, the local version of the kernel is set. The stock kernel uses -tegra as its local version identifier. Make sure to save the configuration file when done editing.

Next, patchAndBuildKernel.sh, patches one of the sources files to more easily compile the kernel:

$ ./patchAndBuildKernel.sh

and proceeds to build the kernel and modules using make. The modules are then installed in /lib/modules/3.10.96[local version name]

Install librealsense

A convenience script has been created to help with this task in the installLibrealsense repository on the JetsonHacks Github account.

$ cd $HOME
$ git clone https://github.com/jetsonhacks/installLibrealsenseTX1.git
$ ./installLibrealsense.sh

This will build the librealsense library and install it on the system. This will also setup udev rules for the RealSense device so that the permissions will be set correctly and the camera can be accessed from user space.

USB Video Class Module

Note: This step assumes that the kernel is located in /usr/src/kernel and that the kernel is to be installed on the board. If this is not your intent, modify the script accordingly. applyUVCPatch.sh has the command to patch the UVC driver with the RealSense camera formats.

The third major step is to build the USB Video Class (UVC) driver as a kernel module. This is can be done using the script:

$ ./buildPatchedKernel.sh

The buildPatchedKernel script will modify the kernel .config file to indicated that the UVC driver should be built as a module. Next, the script patches the UVC driver to recognize the RealSense camera formats. Finally the script builds the kernel, builds the kernel modules, installs the modules and then copies the kernel image to the /boot directory.

Note: The kernel and modules should have already been compiled once before performing this step. Building the kernel from scratch as described in the ‘Kernel and Module Building’ section above pulls a few shenanigans to get things to build properly the first time through.

One more minor point of bookkeeping. In order to save power, the Jetson TX1 will auto-suspend USB ports when not in use for devices like web cams. This confuses the RealSense camera. In order to turn auto-suspend off, run the following script:

$ ./setupTX1.sh

Once finished, reboot the machine for the new kernel and modules to be loaded.

Conclusion

So there you have it. This has been a little bit more involved than some of our other projects here, but if you are interested in this kind of device, well worth it.

Notes

There are several notes on this project:

  • In the video above, the installation was done on a Jetson TX1 running L4T 24.2.1 immediately after being flashed by JetPack 2.3
  • These scripts only support the 64-bit L4T series, 24.X
  • One difference between L4T 24.2 and L4T 24.2.1 is that a soft link issue with Mesa drivers has been resolved. If you are using L4T 24.2, you may have to:

    $ cd /usr/lib/aarch64-linux-gnu
    $ sudo rm libGL.so
    $ sudo ln -s /usr/lib/aarch64-linux-gnu/tegra/libGL.so libGL.so

  • QtCreator and Qt 5 are installed as dependencies in the librealsense part of the install. There are QtCreator project files located in the librealsense.qt directory. The project files build the library and example files. If you do not use QtCreator, consider modifying the installer script to take QtCreator out.
  • The librealsense examples are located in librealsense/bin after everything has been built.
  • These scripts install librealsense version v1.11.0 (last commit 74ff66da50210e6b9edc3157411bad95c209740f)
  • The RealSense R200 is the only camera tested at this time.
  • Examples using librealsense are located in librealsense/bin

The post Intel RealSense Camera Installation – NVIDIA Jetson TX1 appeared first on JetsonHacks.

Robot Operating System (ROS) on NVIDIA Jetson TX1

$
0
0

Robot Operating System (ROS) can now be installed from Debian packages on the 64-bit L4T 24.2 Jetson TX1. Looky here:

Background

As discussed previously, the 64-bit ARM environment is relatively new. This means that most applications, including ROS, need to be ported to the new processor. For a complicated application like ROS, this may necessitate a variety of code and environment changes to support the new computer architecture.

Previously the only way to get ROS running on the Jetson TX1 was to compile everything from source. Even for experienced users that is a daunting task. Fortunately pre-built Debian packages are now available for ROS Kinetic on ARM 64. This means that binaries can be directly installed on the Jetson TX1 without the need for building from source.

Installation

The installROSTX1 repository on the JetsonHacks Github account contains scripts which install ROS on the TX1.

The main script, installROS.sh, is a straightforward implementation of the install instructions taken from the ROS Wiki.

You can grab the repository and run the script:

$ git clone https://github.com/jetsonhacks/installROSTX1.git
$ cd installROSTX1
$ ./installROSTX1

The script installs ros-base, rosdep and rosinstall. You can modify the script to install ros-desktop or ros-desktop-full if desired. ROS has a huge number of packages (over 1700) to choose from, this script provides an outline for installation.

There is a convenience script to install a Catkin Workspace, which is a tools supported environment for ROS. The script is called setupCatkinWorkspace.sh. An optional parameter after the script names the workspace, the default name is catkin_workspace. The workspace will be installed in the home directory. For example:

$ ./setupWorkspace.sh jetsonbot

will create a Catkin Workspace directory named jetsonbot in the home directory.

Notes

  • In the video, the Jetson TX1 was flashed with L4T 24.2.1 using JetPack 2.3. L4T 24.2.1 is derived from Ubuntu 16.04. These scripts are for installation on 64-bit versions of L4T 24.X only.
  • A custom kernel was compiled for the TX1. See this article. Note that this is an optional step, installing ROS will work on a stock kernel.
  • There appears to be an issue with SSL certificates which prevent rosdep from initializing correctly on the Jetson TX1. The script rehashes the SSL certificates as a work around.

The post Robot Operating System (ROS) on NVIDIA Jetson TX1 appeared first on JetsonHacks.


Intel RealSense Package for ROS on NVIDIA Jetson TX1

$
0
0

Intel provides an open source ROS package for their RealSense cameras. In this article, we install the package on the Jetson TX1. In the video, we even take the package out for a spin with a RealSense R200 camera connected to a Jetson TX1. Looky here:

Background

The Intel RealSense cameras are small form factor RGBD cameras that provide high performance at an inexpensive price point. For many robotic applications, the RealSense camera is a good fit. Getting the RealSense ROS packages up and running on the Jetson TX1 is fairly straightforward.

Installation

The RealSense ROS package has two prerequisites on the Jetson TX1. First, modify the Jetson TX1 kernel to allow the Jetson to understand the different video modes of the RealSense cameras. This previous article describes the process: Intel RealSense Camera Installation – NVIDIA Jetson TX1.

The librealsense installation article above installs librealsense on the TX1. This is strictly not necessary as the RealSense ROS packages needs librealsense to be installed from source in the Catkin Workspace. However, following the article allows for easy testing. Note that you can uninstall the librealsense library if desired:

$ cd librealsense
$ sudo make uninstall

The second prerequisite is that ROS must be installed on the Jetson TX1, along with a Catkin Workspace. Here is an earlier article Robot Operating System (ROS) on NVIDIA Jetson TX1 about the installation process.

Install RealSense Packages for ROS

There are convenience scripts to install the Intel RealSense ROS package on the Github JetsonHacks account. After the prerequisites mentioned above have been installed:

$ git clone https://github.com/jetsonhacks/installRealSenseROSTX1
$ cd installRealSenseROSTX1
$ ./installRealSenseROSTX1 <catkin workspace name>

Where catkin_workspace_name is the name of the Catkin Workspace to place the RealSense package. In the video, the workspace is named jetsonbot.

Launch files for the camera node/nodelet are available in the realsense_camera source directory in the launch folder. There are also rviz launch files in the rviz folder.

Notes

There is a file called Notes.txt in the installRealSenseROSTX1 directory which has some short notes for installing rviz and rqt-reconfigure to help visualize the output from the RealSense camera and adjust camera parameters on the Jetson TX1.

The installation above shows a Jetson TX1 running L4T 24.2.1. The scripts install Intel RealSense ROS package version 1.5.

Unlike most of articles and videos on JetsonHacks, installation of the Intel RealSense packages requires some prerequisites to be installed before installation. While previous articles cover the steps involved, be aware that this is a little more complicated than most of the software installation articles on this site.

As always, the scripts made available from JetsonHacks only provide a guide for how to complete the described task, you may have to modify them to suit your needs.

The post Intel RealSense Package for ROS on NVIDIA Jetson TX1 appeared first on JetsonHacks.

Single Chip LIDAR – VL53L0X – NVIDIA Jetson Dev Kits

$
0
0

ST Microelectronics recently introduced an inexpensive single chip time of flight sensor. The VL53L0X can be interfaced to a Jetson Development Kit (either TX1 or TK1) over I2C. Looky here:

Background

The last couple of years have seen a major push towards solid state LIDAR. As autonomous vehicles, robotics and mobile technologies become more prevalent, LIDAR sensing is working towards becoming less expensive and more robust. There have been several announcements for solid state LIDARs recently, ST Microelectronics has begun shipping a new generation of Time-of-Flight laser-ranging module housed in the smallest package on the market today, the VL53L0X.

Here’s a quick view from the ST Microelectronics web site:

The VL53L0X is a new generation Time-of-Flight (ToF) laser-ranging module housed in the smallest package on the market today, providing accurate distance measurement whatever the target reflectances unlike conventional technologies. It can measure absolute distances up to 2m, setting a new benchmark in ranging performance levels, opening the door to various new applications.

The VL53L0X integrates a leading-edge SPAD array (Single Photon Avalanche Diodes) and embeds ST’s second generation FlightSenseTM patented technology.

The VL53L0X’s 940nm VCSEL emitter (Vertical Cavity Surface-Emitting Laser), is totally invisible to the human eye, coupled with internal physical infrared filters, it enables longer ranging distance, higher immunity to ambient light and better robustness to cover-glass optical cross-talk.

The package is 4.4 x 2.4 x 1.0 mm.

VL53L0X Carrier Board

Pololu Robotics & Electronics sells a carrier/breakout board for the VL53L0X for ~ $14 USD at the time of this writing. Money quote from the Pololu website:

The VL53L0X is a great IC, but its small, leadless, LGA package makes it difficult for the typical student or hobbyist to use. It also operates at a recommended voltage of 2.8 V, which can make interfacing difficult for microcontrollers operating at 3.3 V or 5 V. Our breakout board addresses these issues, making it easier to get started using the sensor, while keeping the overall size as small as possible.

The carrier board includes a low-dropout linear voltage regulator that provides the 2.8 V required by the VL53L0X, which allows the sensor to be powered from a 2.6 V to 5.5 V supply. The regulator output is available on the VDD pin and can supply almost 150 mA to external devices. The breakout board also includes a circuit that shifts the I²C clock and data lines to the same logic voltage level as the supplied VIN, making it simple to interface the board with 3.3 V or 5 V systems, and the board’s 0.1″ pin spacing makes it easy to use with standard solderless breadboards and 0.1″ perfboards. The board ships fully populated with its SMD components, including the VL53L0X, as shown in the product picture.

For a similar but shorter-range sensor (up to 20 cm, or 60 cm with reduced resolution) that includes ambient light sensing functionality, see our VL6180X carrier.

In addition, Pololu wrote a library for the VL53L0X to interface with an Arduino. The JetsonHacks library JHVL53L0X is based on the Pololu library.

Wiring

Make sure that the Jetson is turned off before wiring.

NVIDIA Jetson TX1 Development Kit

The software library defaults to using I2C bus 0. Wire the Jetson TX1 J21 header to the VL53LV0X carrier board as follows:

Jetson TX1
J21 Pin 1 (3.3V) → VL53L0X Vin
J21 Pin 6 (GND) → VL53L0X GND
J21 Pin 3 (SDA) → VL53L0X SDA
J21 Pin 5 (SCL) → VL53L0X SCL

NVIDIA Jetson TK1 Development Kit

The software library defaults to using I2C bus 0. Wire the Jetson TK1 J3A1 header to the VL53LV0X carrier board as follows:

Jetson TK1
J3A1 Pin 10 (3.3V) → VL53L0X Vin
J3A1 Pin 2 (GND) → VL53L0X GND
J3A1 Pin 21 (SCL) → VL53L0X SCL
J3A1 Pin 23 (SDA) → VL53L0X SDA

Software Setup and Installation

Note: The demonstration was filmed after flashing the Jetson with JetPack 2.3.
Once the board is wired up, turn the Jetson on.
Install the JHVL53L0X library:

$ git clone https://github.com/jetsonhacks/JHVL53L0X.git
$ cd JHVL53L0X
$ ./installPre.sh

The install script installs the i2c tools and development libraries, and enables I2C to be accessed from user space.

After installation, in a Terminal execute:

$ sudo i2cdetect -y -r 0

ubuntu@tegra-ubuntu:~$ sudo i2cdetect -y -r 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: — — — — — — — — — — — — —
10: — — — — — — — — — — — — — — — —
20: — — — — — — — — — 29 — — — — — —
30: — — — — — — — — — — — — — — — —
40: — — — — — — — — — — — — — — — —
50: — — — — — — — — — — — — — — — —
60: — — — — — — — — — — — — — — — —
70: — — — — — — — —

You should see an entry of 0x29, which is the default address of the VL53L0X.

Example Demos

The directory ‘example’ contains two examples. The first example prints the distance in millimeters of an object from the sensor to the console.

$ cd example
$ make
$ ./example

The second example plots the distance of an object from the sensor. The second example assumes that Qt Creator is installed. In a file browser, open JHVL53L0X->example->LidarPlotExample. The project file is named LidarPlotExample.pro. Compile and run the example.

Equipment and Supplies

Here’s some of the equipment used in the video:

New to electronics? This is a pretty easy project, looky here: Electronics Tutorials for some introductory material on how to start becoming a master.

Conclusion

There are many uses for an inexpensive 1D LIDAR. Availability of an inexpensive 1D LIDAR chip for close range sensing marks an important stepping stone to bringing autonomous robots into more wide spread use. By placing the VL53L0X on a hobbyist accessible carrier board, Pololu is enabling an intriguing number of possibilities for new projects.

The post Single Chip LIDAR – VL53L0X – NVIDIA Jetson Dev Kits appeared first on JetsonHacks.

LIDAR on a Chip Outside – NVIDIA Jetson Development Kits

$
0
0

In the previous article on the LIDAR on a Chip, some folks asked if it is possible to run the chip outdoors. Looky here:

This is just a short article on how the test was done.

The LIDAR on a Chip in this article is a VL53L0X from ST Microelectronics. Pololu Robotics & Electronics sells the carrier/breakout board for the VL53L0X that was used in the video.

In the video, the VL53L0X is wired to a Jetson TK1 Development Kit over I2C. The TK1 is running a wireless access point and a web server. The web server posts a web page which displays the current reading of the VL53L0X range in millimeters through a web socket.

A NVIDIA Shield Tablet is shown which connects to the Jetson TK1 through the WAP and connects to the TK1 web server through a web browser. In that way, the Shield shows the current reading of the VL53L0X.

Results

The test was performed at noon on a sunny day in November in Southern California. With sunlight hitting the sensor (but not pointing the sensor directly at the sun of course) it looked as if the sensor could measure objects up to about 350mm. When the sun was not directly hitting the sensor, range increased somewhat. This is what we would expect, almost any light gathering device has some type of hood/lens to shield the sensor from unwanted light. The laser on the chip emits 940nm light, this is usually pretty good for use outdoors.

It appears that with the application of some shielding/hooding over the sensor, range could be increased significantly. Overall, still pretty good for outdoors use if you want close proximity sensing. Certainly worth checking out!

The post LIDAR on a Chip Outside – NVIDIA Jetson Development Kits appeared first on JetsonHacks.

Jetson TX1 Swap File and Development Preparation

$
0
0

Adding a swapfile and doing some preparation for development is one of the first things to do after flashing a NVIDIA Jetson Development Kit. Looky here:

Background

Over the last couple of years, the software capabilities of the Jetson Development Kits have increased dramatically. JetPack does a great job of keeping track and installing the many software libraries and Jetson specific software packages and demos. However, this does come at a cost. Because the Jetson Development Kit has a relatively small “hard drive” and a limited amount of memory, sometimes development can get bogged down a bit because of lack of system resources.

Fortunately, there are work arounds. Some of the larger programs and applications out there, such as TensorFlow and ROS to name just a couple, require more memory to build than the Jetson has available. A good work around for this is to use what is called a swap file, which allows the Jetson to use disk space as virtual memory. We talked about this in an earlier article.

Also, sometimes we would like to reclaim some of that disk space used by the installed software and demos, and repurpose it for development. In the video, we show how to get rid of some of the low hanging fruit.

Getting to Work

The video was performed directly after flashing the Jetson using JetPack 2.3.1. JetPack installed:

  • L4T 24.2.1
  • CUDA 8.0
  • cuDNN 5.1

which is need for the project that I’m currently working on. Other libraries and demos were also installed such as VisionWorks.

On the JetsonHacks account on Github, there is a repository named postFlashTX1 which contains some convenience scripts for creating a swap file and reclaiming some of the disk space from some applications that sometimes are not used on development machines.

Swapfile

In the video, a 250GB Samsung EVO 850 SSD is connected to the Jetson TX1. The SSD is formatted as ext4. In order to create a swap file:

$ sudo ./createSwapfile.sh -d [directory location] -s [size in gigabytes] -a

All of the arguments are optional. The default is for a 8GB swapfile to be created in the current directory. The -a flag indicates whether the swapfile should be automatically be loaded on boot. If the swapfile is to be loaded at boot time, make sure to set up the media that it is on so that it is available when the machine boots.

For the 4 GB Jetson TX1, a 8 GB swapfile is a good size. The rule of thumb for the swap file size is about 2X real memory size. Also, try to place the swapfile on external media that is as fast as possible. While you can place the swapfile on a USB stick or SD card, note that there will be a real performance hit when compared to placing it on a SSD.

Important Note

Setting up a swapfile on a SSD or other flash type memory can lead to wear of the device. Most current flash memory has a lifetime number of reads and writes it can perform, a busy swap file can consume a good chunk of those. Note that this is also true of hard drives. Newer SSDs have built in mechanisms to help distribute the “write wear”. As always, make backups of your drives and store them away.

In the video, the swap file is auto mounted when the machine boots. This is great for development, but afterwards you may want to disable that feature. To do so:

$ sudo gedit /etc/fstab

and comment out the line that does the ‘swapon’. Make sure to save the file, reboot and check to make sure that swap is off.

Also, you may want to be a little more hard core about your swap area. You can set aside a ‘swap partition’ and use that instead of a swap file. This approach may be faster because the swap area is set aside contiguously. This route is similar to setting up a swap file, but is beyond the scope of this article.

More stuff

The other convenience files in the repository do some more cleanup work.

$ ./uninstallLibreoffice.sh

Will remove the Libre Office suite from the machine. While these are useful tools, they may not be needed for a development machine.

$ ./uninstall_unity_scope.sh

Will remove a lot of the links which support desktop like activities, such as shopping.

Conclusion

This is just a general purpose rough cut to get started on getting the machine ready for development. Obviously the development environment needs to reflect the applications that are being built. However, more memory and some more disk space is a real fine way to start.

The post Jetson TX1 Swap File and Development Preparation appeared first on JetsonHacks.

TensorFlow on NVIDIA Jetson TX1 Development Kit

$
0
0

Building TensorFlow on the NVIDIA Jetson TX1 is a little more complicated than some of the installations we have done in the past. Looky here:

Background

TensorFlow is one of the major deep learning systems. Created at Google, TensorFlow is an open-source software library for machine intelligence. The Jetson TX1 ships with TensorRT, which is the run time for TensorFlow. TensorRT is what is called an “Inference Engine“, the idea being that models that are trained on much larger systems can be transferred over and “run” on the Jetson.

However, some people would like to use the entire TensorFlow system on a Jetson. This has been difficult for a few reasons. The first reason is that TensorFlow binaries aren’t generally available for ARM based processors like the Tegra TX1. The second reason is that actually compiling TensorFlow takes a larger amount of system resources than is normally available on the Jetson TX1. The third reason is that TensorFlow itself is rapidly changing (it’s only a year old), and the experience has been a little like building on quicksand.

In this article, we’ll go over the steps to build TensorFlow r0.11 on the Jetson TX1. This will take about three hours or so to build.

Note: You may want to read through this article and then read the secret article: Install TensorFlow on TX1. Just a thought. But you didn’t hear it from me.

Preparation

This article assumes that JetPack 2.3.1 is used to flash the Jetson TX1. Install:

  • L4T 24.2.1 an Ubuntu 16.04 64-bit variant (aarch64)
  • CUDA 8.0
  • cuDNN 5.1.5

Note that the library locations when installed by JetPack may not match a manual installation. TensorFlow will use CUDA and cuDNN in this build.

In order to get TensorFlow to compile on the Jetson TX1, a swap file is needed for virtual memory. Also, a good amount of disk space ( > 5.5GB ) is needed to actually build the program. If you’re unfamiliar with how to set the Jetson TX1 up like that, see a previous article: Jetson TX1 Swap File and Development Preparation.

There is a repository on the JetsonHacks account on Github named installTensorFlowTX1. Clone the repository and switch over to that directory.

$ git clone https://github.com/jetsonhacks/installTensorFlowTX1
$ cd installTensorFlowTX1

Next, tell the dynamic linker to use /usr/local/lib

$ ./setLocalLib

Prerequisites

There is a convenience script which will install the required prerequisites such as Java, along with Protobuf, grpc-java and Bazel. The script also patches the source files appropriately for ARM 64. Bazel and grpc-java each require a different version of Protobuf, so that is also taken care of in the script.

$ ./installPrerequisites.sh

From the video installation of the prerequisites takes a little over 30 minutes, but will depend on your internet connection speed.

Building TensorFlow

First, clone the TensorFlow repository and patch for Arm 64 operation:

$ ./cloneTensorFlow.sh

then setup the TensorFlow environment variables. This is a semi-automated way to run the TensorFlow configure.sh file. Note that most of the library locations are configured in this script. As stated before, the library locations are determined by the JetPack installation.

$ ./setTensorFlowEV.sh

We’re now ready to build TensorFlow:

$ ./buildTensorFlow.sh

This will take a couple of hours. After TensorFlow is finished building, we package it into a ‘wheel’ file:

$ ./packageTensorFlow.sh

The wheel file will be in the $HOME directory, tensorflow-0.11.0-py2-none-any.whl

Installation

Pip can be used to install the wheel file:

$ pip install $HOME/tensorflow-0.11.0-py2-none-any.whl

Test

Then run a simple TensorFlow example for the initial sanity check:

$ cd $HOME/tensorflow
$ time python tensorflow/models/image/mnist/convolutional.py

Conclusion

So there you have it. Building TensorFlow is quite a demanding task, but hopefully some of these scripts may the job a little bit simpler.

The post TensorFlow on NVIDIA Jetson TX1 Development Kit appeared first on JetsonHacks.

Install TensorFlow on NVIDIA Jetson TX1 Development Kit

$
0
0

You just finished looking at TensorFlow on NVIDIA Jetson TX1 Development Kit and are wondering, “Is there anyway that I could actually use TensorFlow on the Jetson TX1 without having to compile the whole thing myself?” The official JetsonHacks response? “No. Suck it up!”

This is an unofficial post, just a point of information that perhaps a clever person like you can use to your advantage.

Actually, I happen to have placed the Wheel file that we created in the previous article on Google Drive. No guarantees about it’s suitability (or even that it works), but it is the result of the process that we followed building TensorFlow in the previous article. Be aware that this is completely untested, you are on your own. I haven’t even tried it myself. Looky here:

TensorFlow Wheel File

Installation

We assume that JetPack 2.3.1 is used to flash the Jetson TX1. Install:

  • L4T 24.2.1 an Ubuntu 16.04 64-bit variant (aarch64)
  • CUDA 8.0
  • cuDNN 5.1.5

Note that the library locations when installed by JetPack may not match a manual installation. TensorFlow will use CUDA and cuDNN in this build. The TensorFlow build depends on the location of the libraries installed by JetPack.

You will need to install the appropriate dependencies. If you look at the build dependencies:

https://github.com/jetsonhacks/installTensorFlowTX1/blob/master/scripts/installDependencies.sh

You’ll see the usual suspects, I would guess that you need python-dev python-pip at a minimum, I’m not sure about Java, that may have just been needed for the build.

Then it’s the usual:

pip install tensorflow-0.11.0-py2-none-any.whl

and TensorFlow should be installed. You’ll have to figure it out on your own, but it should be somewhat simpler than having to build it yourself, if just for starters.

We’ll keep this little secret between ourselves.

The post Install TensorFlow on NVIDIA Jetson TX1 Development Kit appeared first on JetsonHacks.

State of JetsonHacks 2016

$
0
0

First I want to thank everyone for reading JetsonHacks.com, and wish everyone a super duper 2017. It’s usually fun to recap some statistics about the website, I know sometimes people are curious to see how many other people are using JetsonHacks.

JetsonHacks Website

The following chart helps give you an idea of how much the website has grown over the last 12 months. JetsonHacks came online in June 2014, shortly after the NVIDIA Jetson TK1 Development Kit was introduced. The Jetson TX1 Development Kit was introduced in October 2015:

JetsonHacks Traffic

As you can see, the number of page views more than doubled from 2015 to 2016. 2015 brought in more than 130,000 views from 52,000 visitors. In contrast, 2016 brought in more than 290,000 views from 92,000 visitors! The site appears to be still growing a smidge, the average daily page views has increased from 360 in 2015 to 800 in 2016.

The most popular posts continue to be deep learning related. Caffe Deep Learning Framework – NVIDIA Jetson TX1 and NVIDIA Jetson TK1 – cuDNN install with Caffe example each received over 7,000 views in 2016. Basic how to articles and screencasts are next, while robotics and vision related posts remain quite popular. In 2015, JetsonHacks posted 120 articles. In 2016, 71 articles were posted.

Visitors came from over 148 countries to visit JetsonHacks. Here are the top ten from 2016:

JetsonHacks Countries List

The list is much the same as last year, with the exception that China jumped to the second spot from number 9. Thank you for taking the time to stop by!

JetsonHacks YouTube Channel

The associated JetsonHacks YouTube Channel has also shown the same type of growth in 2016.

In 2015, there were 135K views with a watch time of 314K minutes. There were 658 Likes, 25 Dislikes, 166 Shares and 780 Subscribers were added. For 2016, there were 223K views with a watch time of 515K minutes. There were 1,043 Likes, 40 Dislikes, 321 Shares and 1228 Subscribers added. 45 new videos were posted in 2016, the entire channel currently has around 155 videos.

As you might expect, people consume video differently than they do on the JetsonHacks website. The video viewers appear to be more pragmatic, the videos for JetPack installation and how to install the Stereolabs ZED camera and Intel RealSense Camera are the most popular.

Unfortunately everyone pretty much behaved themselves and I didn’t get to ban anyone this year. One can always hope.

Just a quick note. “Likes” in the YouTube world, along with how long the video is watched, helps to recommend the video to other viewers. Subscriptions and comments do much the same thing. If you like the video, give it a thumbs up. On the other hand, if you disliked the video and give it a thumbs down, it would be useful to know why you didn’t like it in the comments. If you dislike the video I won’t hate you forever, just for what’s left of my natural life.

JetsonHacks Github Repository

In the JetsonHacks Github Repository, there are now 71 repositories, up from 43 in 2015. People have been using the repositories on a regular basis, I hope everyone is finding them useful. Make sure to give them a star if you find them useful, it helps decide future projects. Also, feel free to generate pull requests for improvements.

On to 2017

Certainly if you have anything you’re working on and would like JetsonHacks to know about, send an email.

Again, thank you for all of your support. I hope your 2017 goes really swell. Oh, and it’s good to see you survived 2016, others weren’t so lucky.

Peace Out,

Jim

The post State of JetsonHacks 2016 appeared first on JetsonHacks.


Quick Tip: Web Browser on Jetson TX1

$
0
0

The Chromium web browser is now available from the Ubuntu repositories. It’s easy to install. Looky here:

Background

Most Ubuntu systems, including the 32-bit versions of the Jetson Development Kits, install a web browser in the desktop Launcher for easy access.

However, when the NVIDIA Jetson TX1 Development Kit switched over to 64-bit only, it presented a small dilemma. There were no mainstream web browsers available for ARM-64 bit architecture. NVIDIA rectified this in a subsequent release by providing a special version of Chromium (the open source version of the Google Chrome web browser) as a binary, along with access to the modified source code. However, the version installed is a developer version,  which included sandboxing. Most users are used to a different experience.

As time passed, eventually the 64-bit ARM version of the Chromium browser appeared in the Ubuntu repositories, and can now be installed using apt-get.

Web Browser Installation

In the video above, installation was performed directly after flashing the Jetson TX1 with L4T 24.2.1 using JetPack 2.3.1. At a Terminal execute:

$ sudo apt-get install chromium-browser

Answer ‘Y’ at the install prompt. Once Chromium is installed, you can access the Chromium Web Browser from the search icon. It may also be convenient to lock the application icon to the Launcher after you start Chromium. You can right click on the Chromium icon in the Launcher and select ‘Lock to Launcher’, or move the icon to a different location on the Launcher which will lock it in place.

Hopefully this makes life a little easier for those of us who had issues configuring the installed developer version of Chromium.

The post Quick Tip: Web Browser on Jetson TX1 appeared first on JetsonHacks.

Building TensorFlow Update – Jetson TX1

$
0
0

Here’s a quick update on building TensorFlow for the NVIDIA Jetson TX1. Late last month, we looked at installing TensorFlow on the Jetson TX1. Of course, we are talking about the installTensorFlowTX1 repository on the JetsonHacks Github account.

As is not atypical in developing open source software, a week goes by and it doesn’t build anymore. “Double double, toil and trouble”. The good news is that none of the code in the TensorFlow repository changed for the tag v0.11. It can be particularly annoying when the people controlling releases go back and changed tagged version. Doesn’t stop people from doing it (mostly because they don’t know better) …

Library Relocation

Fortunately the fix had been brought up in the TensorFlow Github issues list, the zlib library had been updated. The link in the TensorFlow code base points to the ‘latest version’ of zlib, instead of a particular version in a permanent location. This isn’t quite best practices either, but it is understandable how it happens.

Typically a project that has as many dependencies as TensorFlow does is built rather simply at the beginning by a handful of people. Most people will grab a link to the latest and greatest version of any dependencies. You’ll see things like people linking to the master branch of a Github repository, or the latest version of a compressed library or binary. Time passes, the project gets a lot more people working on it, and invariably the dependencies codes change. Open source advocates say this is really good, everything is always getting better. For people actually working on the projects, it means that things can break unexpectedly in strange ways.

Anyway, a patch was added to point to the permanent location of the zlib library used by version v0.11 of TensorFlow which is applied when the TensorFlow library is git cloned.

Incremental Compilation

Another issue that is addressed in the latest update is incremental building using Bazel. TensorFlow is a big project, there are lots of dependencies and such. Bazel is a build system for putting together such beasts. As is the case for most build programs for large systems, the actual build programs are nearly as complicated as the large systems themselves.

In the case of TensorFlow, there’s an issue in the CUDA configuration file tensorflow/third_party/gpus/cuda_configure.bzl where the rule:

cuda_configure = repository_rule(
implementation = _cuda_autoconf_impl,
local = True,
)

basically tells the build system that the an incremental build cannot be used. When it takes over two hours to build TensorFlow on the Jetson TX1 (the build can fail for a variety of trivial reasons) this is particularly annoying. In other words, let’s say you perform a build. Everything but three files compile, which means that you have to start again from scratch. By removing the ‘local = True,’ line, incremental build goes into effect, which means that in the example all you have to do is ‘buildTensorFlow.sh’ again, and the build will continue where it left off and compile the three missing files. This patch is applied to the TensorFlow code base when the repository is clone using ‘cloneTensorFlow.sh’.

Hopefully this helps.

The post Building TensorFlow Update – Jetson TX1 appeared first on JetsonHacks.

Run Jetson TX1 from SD Card

$
0
0

This is a short article on copying the contents of the internal flash memory of a NVIDIA Jetson TX1 over to a SD card, and then running the Jetson from the SD card itself. Looky here:

Background

There may be times when you want to run your Jetson TX1 from a SD card. For example, you may have to share your Jetson with other people or you may need more disk space to develop applications. This is pretty straightforward. There are a few up front warnings.

First, not all SD cards are created equal. The Jetson TX1 supports UHS-I, speed class up to 10 and capacity to 2 TB. You want to get a card with a speed class of 10, but be aware that the quality of some SD cards can vary even between the same brand and model. People have reported issues with the same model of card from the same manufacturer, one works another may not. Make sure to test out your card after installation.

The SD card used in the video is a PNY Elite Performance 64GB Flash Memory High Speed SDXC Class 10 UHS-I. I have had good luck with these.

Second, note that this is a copy of the the internal flash memory of the Jetson TX1. There are a couple other ways to do the same procedure, for example you can ‘flash’ the SD card from a PC. However, one of the issues is that it is difficult to load CUDA and other packages on to the SD card in as simple a manner as JetPack allows you to do with the internal flash memory. The easiest way to get a complete working system on the SD card is to use JetPack to do a normal install which sets up everything to internal flash, and then copy over the root system of the internal flash to the SD card.

Third, this is a mostly GUI solution, there are command line equivalents that others may use and are more sophisticated. Just be forewarned that if you ask for help, others may speak in ‘CLI‘ language.

Installation

Note: The installation on the video was done on a Jetson TX1 running L4T 24.2.1, which was flashed from JetPack 2.3.1.

Because the installation demonstration is using mostly GUI tools, please refer to the video for the walk through. Here are the basic steps:

First, format the SD card with a ext4 format. You will need at least 1 partition. The partition size should be at least 16GB. There are a couple of ways of doing this, an easy way is to use the Disks application which provides a GUI for formatting disks.

Second, mount the SD card. Double clicking the SD card icon will mount the SD card and open a file browser.

Third, copy the contents of the root directory of the internal flash memory to the SD card. In the video example:

$ sudo cp -ax / ‘/media/ubuntu/SD Root’

copies the root directory to the mounted SD card named ‘SD Root’. For a nearly full internal flash memory, this will take about 20 minutes.

The last setup step is to modify the file extlinux.conf file on the SD card. Make sure that you switch over to the SD card, e.g.

$ cd ‘/media/ubuntu/SD Root’

make a backup of the extlinux.conf file, and then edit it:

$ cd /boot/extlinux
$ sudo cp extlinux.conf extlinux.conf.original
$ sudo gedit /boot/extlinux/extlinux.conf

An editor will open on the configuration file. Duplicate the eMMC entry (usually named primary), and change the entries as shown in the video. One of the major changes indicates the device and partition, which is:

Internal eMMC

root=/dev/mmcblk0p1

SD Card:

root=/dev/mmcblk1p1

Sample extlinux.conf File

The completed example file shown in the video is:

TIMEOUT 30
DEFAULT sdcard

MENU TITLE p2371-2180 eMMC boot options

LABEL sdcard
MENU LABEL SD Card
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk1p1 rw rootwait

LABEL internalemmc
MENU LABEL Internal EMMC
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait

Make sure to save the file.

Now restart the machine and it will boot from the SD card. The boot order on the Jetson TX1 is SD card and then eMMC, so if the SD card is present with a boot directory it will boot from there.

Note: If the machine does not boot, hook up a serial console and examine the boot sequence. The entries that you have changed should show up in the boot options.

Once the machine boots, you should run some typical programs or compiles to make sure everything works and is installed correctly. There are some things to watch out for, such as check to make sure that settings for swap files are correct. In general, it is a copy of the internal eMMC, so it should all pretty much behave itself.

The post Run Jetson TX1 from SD Card appeared first on JetsonHacks.

Run Jetson TX1 from USB Drive

$
0
0

This is a the second in a series of short articles about running the Jetson TX1 from external storage. This article discusses copying the contents of the internal flash memory of a NVIDIA Jetson TX1 over to a USB Drive, and then running the Jetson from the USB Drive itself. Looky here:

The USB Flash Drive in the video is a SanDisk 64GB Ultra Flair.

Background

USB flash drives and other types of USB drives are ubiquitous and inexpensive. When people need larger and faster storage on a Jetson TX1, they will frequently select USB drives as a solution. The method described in the video works with both flash and hard drives. For best results, choose a full speed USB 3.0 drive and make sure if a USB hub is being used that it is also USB 3.0. This will provide the fastest speeds possible.

In general, USB drives can be twice as fast as SD Cards.

You can simply use the USB drive as supplemental storage, or choose to use the drive as the root directory of the operating system. This basically means that the system runs from the USB drive instead of the internal flash (eMMC) memory. The video describes the process to copy the root over from the internal eMMC over to the USB drive, and then modify the boot process to use the USB drive as root.

This method is a mostly GUI solution, there are command line equivalents that others may use and are more sophisticated. Just be forewarned that if you ask for help, others may speak in ‘CLI‘ language.

An embedded system like the Jetson TX1 uses a different boot sequence than a PC. A PC uses system firmware called a BIOS which is able to easily assign different devices to be the boot device. Embedded systems tend to be simpler and more direct. While there are several different strategies used, the Jetson TX1 uses the extlinux boot loader. By modifying the file extlinux.conf in /boot/extlinux, we can directly control which device and partition are set to be the root directory for Linux.

Installation

Note: The installation on the video was done on a Jetson TX1 running L4T 24.2.1, which was flashed from JetPack 2.3.1.

Because the installation demonstration is using mostly GUI tools, please refer to the video for the walk through. Here are the basic steps:

First, format the USB drive with a ext4 format. You will need at least 1 partition. The partition size must be at least 16GB. There are a couple of ways of doing this, an easy way is to use the Disks application which provides a GUI for formatting disks.

Second, mount the USB drive. Double clicking the USB drive icon will mount the USB drive and open a file browser.

Third, copy the contents of the root directory of the internal flash memory to the USB drive. In the video example:

$ sudo cp -ax / ‘/media/ubuntu/USB Root’

copies the root directory to the mounted USB Drive named ‘USB Root’. For a nearly full internal flash memory, this will take about 7 minutes depending on the speed of the USB drive.

The last setup step is to modify the file extlinux.conf file on the eMMC. The system will boot from the internal eMMC, then the kernel will set the root directory to point to the USB drive.

First, switch to the extlinux directory:

$ cd /boot/extlinux

Next, make a backup of the existing extlinux configuration:

$ sudo cp extlinux.conf extlinux.conf.original

Now edit the configuration to set up the USB drive:

$ sudo gedit /boot/extlinux/extlinux.conf

An editor will open on the configuration file. Duplicate the eMMC entry (usually named primary), and change the entries as shown in the video. One of the major changes indicates the device and partition, which is:

Internal eMMC

root=/dev/mmcblk0p1

USB Drive:

root=/dev/sda1

Sample extlinux.conf File

The completed example file shown in the video is:

TIMEOUT 30
DEFAULT usbflash

MENU TITLE p2371-2180 eMMC boot options

LABEL usbflash
MENU LABEL USB Flash Drive
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/sda1 rw rootwait

LABEL emmc
MENU LABEL Internal eMMC
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait

Make sure to save the file.

Now restart the machine and it will boot to the USB drive.

Note: If the machine does not boot, hook up a serial console to a host and examine the boot sequence. The entries that you have changed should show up in the boot options.

Once the machine boots, you should run some typical programs or compiles to make sure everything works and is installed correctly. There are some things to watch out for, such as checking to make sure that system level settings for things such as swap files are correct. In general, it is a copy of the internal eMMC, so it should all pretty much behave itself.

Things to Watch Out For

Lions, Tigers, and Bears for starters. Badgers are really mean, be careful of those.

Once past the usual suspects, one thing that you need to be aware of is that if the Jetson can’t see the USB drive, it will not boot. You may see error messages on the screen or console that it is hunting through USB devices, looking for a boot drive. If there is another USB drive which is not bootable, then you may see errors that look like the Jetson is flat out broken.

If the bootable USB drive is not available for some reason, you can use the serial console to select the internal eMMC as the boot device. That will allow you to edit the extlinux.conf file to boot from a different device.

The post Run Jetson TX1 from USB Drive appeared first on JetsonHacks.

Install Samsung SSD on NVIDIA Jetson TX1

$
0
0

This is the third in a series of short articles about running the Jetson TX1 from external storage. This article discusses installing a Samsung SATA SSD on a Jetson TX1, and formatting the SSD so that it can be used as external storage. In addition the contents of the internal flash memory of the Jetson TX1 are copied over to the SSD so that the SSD can be used as the root directory. Looky here:

The SSD Drive in the video is a Samsung 850 PRO SSD 256GB.
A SATA cable is a 22-pin (7+15) Sata Male to Female Data and Power Combo Extension Cable.

Background

SATA drives are used in many desktop and laptop computers. While this article describes installing a Solid State Disk, this information can be used to install other types of SATA drives. SATA drives are probably the fastest external storage interface to the Jetson TX1, they can be more than twice as fast as USB drives. Also, SATA drives are relatively inexpensive for the amount of storage they hold.

You can simply use the SATA drive as supplemental storage, or choose to use the drive as the root directory of the operating system. This basically means that the system runs from the SATA drive instead of the internal flash (eMMC) memory. The video describes the process to copy the root over from the internal eMMC over to the SATA drive, and then modify the boot process to use the SATA drive as root directory.

This method is a mostly GUI solution, there are command line equivalents that others may use and are more sophisticated. Just be forewarned that if you ask for help, others may speak in ‘CLI‘ language.

An embedded system like the Jetson TX1 uses a different boot sequence than a PC. A PC uses system firmware called a BIOS which is able to easily assign different devices to be the boot device. Embedded systems tend to be simpler and more direct. While there are several different strategies used, the Jetson TX1 uses the extlinux boot loader. By modifying the file extlinux.conf in /boot/extlinux, we can directly control which device and partition are set to be the root directory for Linux.

Installation

Note: The installation on the video was done on a Jetson TX1 running L4T 24.2.1, which was flashed from JetPack 2.3.1.

Because the installation demonstration is using mostly GUI tools, please refer to the video for the walk through. Here are the basic steps:

Make sure that the Jetson is powered down, and attach the SATA drive to the Jetson using a SATA extension cable. Some SSD drives will fit on the Jetson TX1 SATA connector directly. However, this can be rather precarious as the SSD can act as a big lever which when bumped may break off the connector from the TX1 carrier board. Adding a cable minimizes this risk.

With the SATA drive installed, start up the machine.

Format the SATA drive by adding at least one partition with a ext4 format. The partition size must be at least 16GB. There are a couple of ways of doing this, an easy way is to use the Disks application which provides a GUI for formatting disks.

Next, mount the SATA drive. Double clicking the SATA drive icon in the sidebar will mount the SATA drive and open a file browser.

If you are only looking to add external storage to the Jetson, then you are finished.

SATA Drive as Root Directory

On the other hand, if you want to use the SSD as your root directory you copy the contents of the root directory of the internal flash memory to the SATA drive. In the video example:

$ sudo cp -ax / ‘/media/ubuntu/JetsonSSD-256’

copies the root directory to the mounted SSD Drive named ‘JetsonSSD-256’. For a nearly full internal flash memory, this will take about 3 minutes depending on the speed of the SATA drive.

The last setup step is to modify the file extlinux.conf file on the eMMC. The system will boot from the internal eMMC, then the kernel will set the root directory to point to the SATA drive.

First, switch to the extlinux directory:

$ cd /boot/extlinux

Next, make a backup of the existing extlinux configuration:

$ sudo cp extlinux.conf extlinux.conf.original

Now edit the configuration to set up the USB drive:

$ sudo gedit /boot/extlinux/extlinux.conf

An editor will open on the configuration file. Duplicate the eMMC entry (usually named primary), and change the entries as shown in the video. One of the major changes indicates the device and partition, which is:

Internal eMMC

root=/dev/mmcblk0p1

SSD Drive:

root=/dev/sda1

Sample extlinux.conf File

The completed example file shown in the video is:

TIMEOUT 30
DEFAULT satassd

MENU TITLE p2371-2180 eMMC boot options

LABEL satassd
MENU LABEL primary SATA SSD
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/sda1 rw rootwait

LABEL emmc
MENU LABEL Internal eMMC
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait

Make sure to save the file.

Now restart the machine and it will boot to the SATA drive.

Note: If the machine does not boot, hook up a serial console to a host and examine the boot sequence. The entries that you have changed should show up in the boot options.

Once the machine boots, you should run some typical programs or compiles to make sure everything works and is installed correctly. There are some things to watch out for, such as checking to make sure that system level settings for things such as swap files are correct. In general, it is a copy of the internal eMMC, so it should all pretty much behave itself.

Things to Watch Out For

Lions, Tigers, and Bears for starters. Badgers are really mean, be careful of those.

Once past the usual suspects, one thing that you need to be aware of is that if the Jetson can’t see the SATA drive, it will not boot. You may see error messages on the screen or console that it is looking for a boot drive.

If the root SATA drive is not available for some reason, you can use the serial console to select the internal eMMC as the boot device. That will allow you to edit the extlinux.conf file to boot from a different device.

I would advise keeping a bootable SD card around in case something really goes wrong.

If you have changed file system settings (such as those in /etc/fstab, automount, swap files, etc) you will need to revisit the changes to make sure that they are compatible with the new root system.

The SATA drive will usually mount at /dev/sda, which means that USB drives will move up one, i.e. /dev/sda becomes /dev/sdb. The number following the sda (e.g. /dev/sda1) represents the partition.

The post Install Samsung SSD on NVIDIA Jetson TX1 appeared first on JetsonHacks.

Viewing all 339 articles
Browse latest View live