Our friends over at ETA Prime recently shot an Extreme Cooling video about using the ICE Tower Cooler from Seeed Studio on the NVIDIA Jetson Nano Developer Kit. Looky here:
If you throw all the bells and whistles at a cooling solution, you end up with the ICE Tower CPU Cooling Fan from Seeed Studio. There’s copper tubes, a multi-layer aluminum heat sink, RGB lights, all PWM controllable.
While we haven’t experienced any thermal issues with our Jetson Nanos here at JetsonHacks, I will suggest that any thermal issue would be scared away if you mount this fan o’ fun on your Nano.
You can pick one up on Amazon using our affiliate link, or directly from Seeed Studio.
Thermal Performance
Under most conditions, the large heatsink on the Jetson Nano keeps the system running within the design thermal limits. However there may be times when running very GPU intensive loads or when the Jetson is in a very warm environment, that the thermal limits may be reached.
Once the thermal limits are reached, the system software will lower the clock speeds on the CPU and GPU to help reduce the heat being generated. This is called thermal throttling.
As discussed in the video, the ICE Tower Cooler helps keep the Nano a few degrees cooler in comparison to a bare heatsink and a more traditional fan solution. For some applications you need extreme cooling. This may be a make or break problem which needs a solution.
However, if you want to impress your friends and confuse your enemies, it’s ok to get the Ice Tower Cooler just for the looks alone.
One of the hardware items on the JetBot is the Adafruit PiOLED (product id 3527). You can pick this up at the JetsonHacks Amazon Storefront, or directly from Adafruit itself.
While the Adafruit PiOLED is useful on the JetBot, there are a wide range of applications and uses that make this a valuable addition to our project tool chest. It’s great to be able to display a small snippet of information without having the bulkiness of a full display!
You can imagine several uses where this may be particularly valuable. For example, let’s say you have a robot where you need to be able to determine the network address. It’s difficult to guess what the address might be, so having it display on the PiOLED is a really nice feature.
In fact, many headless applications of the Jetson Nano can benefit from this. In the example we provide, you can monitor such things as memory usage, disk usage, and even make simple graphs for CPU and GPU use. Plus, you won’t have to SSH into the Jetson to have to figure out some simple things you could have at a glance.
Installation
The PiOLED is simple to install on the Jetson. The female header on the PiOLED mounts directly to the Jetson Nano J21 GPIO expansion header pins 1 through 6. You should be able to align the pins with the header, and by gently pressing down, be able to seat the display. It should look like this.
$ git clone https://github.com/JetsonHacksNano/installPiOLED $ cd installPiOLED
The PiOLED uses a SSD1306 driver chip. Adafruit has written a driver to interface with the chip. To install the driver along with a simple example app:
$ ./installPiOLED
You can now test the PiOLED:
cd pioled sudo python3 stats.py
Note: About the sudo usage. The isntallPiOLED sets user permissions so you can access the display from ‘user space’. These permissions take effect once you log out/log in to your account. We use sudo here, just because we didn’t do that. Rebooting works too, of course.
To terminate the app, use Ctrl-C in the Terminal.
Running on Startup
One of the cool features of the JetBot is that the PiOLED starts displaying when the Jetson Nano starts up. We’ve nicked that code here too, and modified it a little for our use.
To turn our app as a startup service, execute:
$ ./createService.sh
This will build the app into a Python project distribution .whl file, and install it for global use. In the shell script, we use pip3 for the install.
Note: If we use sudo with pip3, the project will install in /usr/local/bin/python3.6/dist-packages. If we do not use sudo, pip3 installs the library in a hidden local folder, ~/.local/ lib/python3.6/site-packages. We want to be able to use this globally, so we use sudo.
After installation, we can power down the Jetson. The next time we power up the Nano, the PiOLED will display our app information.
About Python Packaging & Startup
A couple of things about packaging Python code. The script in the repository is the barest of skeleton for doing this. There are three points to look at if you want to do this for ‘reals’.
First, the top level directory contains the file setup.py. This file builds the proper descriptors for a Python package. There are many items in a properly constructed setup statement, you will need to research these items to determine which are suitable for your project.
Second, there’s a bit of Python nomenclature. A module is simply a Python script, in our case stats.py. A Python package is a directory/folder which contains module(s) and a special file, __init__.py. You may hear people refer to this as dunder init (double underscore). The dunder init tells the Python packaging script to include this directory in the package.
On Linux/Ubuntu, one of the places to store startup actions is in /etc/systemd. In our case, we store a .service file in the subfolder system. The script utils/create_stats_service.py builds the pioled_stats.service file. It’s worth looking through the .service file, the important line is:
ExecStart=/bin/sh -c “python3 -m pioled.stats”
This line launches a shell, and runs python3 with our application. pioled.stats resolves to the stat.py that we install from our previous script. Notice that because out display loop for PiOLED is in an infinite loop, the process will not terminate after we start it up.
A more detailed explanation
Over on the NVIDIA Jetson Nano forum, user mdegans wrote a way excellent post on how to properly set up a program/script to run at startup using the systemd service mechanism. Well worth the read if your interests lie in understanding and implementing a startup service correctly.
There are a whole bunch of great new features. Two that are particularly noteworthy:
OTA Update – Over the Air Updates (!!!) A new Debian package server is now in place to host all NVIDIA JetPack-L4T components for installation and future JetPack updates
Jetson-IO tool to configure 40-pin header (!!!) New, easy-to-use tool for configuring 40-pin header on Jetson Developer kits.
And if you are getting ready to use the upcoming Jetson Xavier NX or its big brother Jetson AGX Xaver, there’s a developer preview of Vision Programming Interface (VPI). VPI is a software library that provides Computer Vision and Image Processing algorithms implemented on Xavier Vision Accelerator, GPU and CPU.
JetPack 4.3
Here is the official blurb from the NVIDIA Jetson forums:
We are pleased to announce JetPack 4.3 supporting Jetson AGX Xavier series, Jetson TX2 series, Jetson TX1, and Jetson Nano.
JetPack 4.3 key features include new versions of TensorRT and cuDNN, Docker support for CSI cameras, Xavier DLA, and Video Encoder from within containers, and a new Debian package server put in place to host all NVIDIA JetPack-L4T components for installation and future JetPack OTA updates.
Support for installation of JetPack components via Debian package archives
JetPack components are provided as Debian packages via a public APT server hosted by NVIDIA, enabling easier upgrades of JetPack components to future versions. Previous versions of JetPack need to be re-flashed to JetPack 4.3, after which the APT server can be used.
Support for CSI, DLA, and Video Encoder from within containers
On all Jetson products: Camera Serial Interface (CSI) and NVENC are now supported from within containers.
On Jetson AGX Xavier series only: NVIDIA Deep Learning Accelerator (DLA) engines are now supported from within containers.
Support for DeepStream 4.0.2
Support for ISAAC SDK version 2019.3
New easy to use tool to configure 40-pin header on Jetson developer kits
Developer preview of VPI (Vision Programing Interface), a software library that provides Computer Vision and Image Processing algorithms implemented on Xavier Vision Accelerator, GPU and CPU.
GPU and CPU implementations are not optimized for performance in this preview release of VPI. A future release will bring performance optimized GPU and CPU implementations
You can now install an Intel RealSense camera on a NVIDIA Jetson Nano Developer Kit in under 5 minutes! Looky here:
Background
Over the last several years we have been installing Intel RealSense on Jetson Development Kits through a painful process of patching the Linux kernel, compiling kernel modules and building the RealSense driver SDK, librealsense, from source.
All of that has changed! Intel now has an APT repository with a version that is ready to install directly on the Jetson use the apt utility. It takes less than 5 minutes !!! Much better than the hours required previously.
Intel now recommends using the USB Video Class (UVC) as the backend for the RealSense SDK. This has the added advantage of letting the RealSense camera act as a web cam device when appropriate.
Installation
In order to install the RealSense SDK, we must first add the Intel repository to our sources list. After updating, then we can use the apt command to install the SDK. Here are step by step instructions from Intel.
The end of the decade. Let me start by thanking everyone for participating in the JetsonHacks community.
Background
When I first started JetsonHacks in 2014, one of the goals was to get a better understanding of social media through application. By training, I am a software engineer so I understand the concept of “network effect”, or least the theory. How does this translate to a social network? The main question, “How long does it take to build a community around a technical product using social media?” Social media, in this case being YouTube, Twitter and the JetsonHacks blog.
As you might guess, being a computer guy and all, I wanted to know the metrics. How long does it take to get 100 views? 100 subscribers and so on. Quick answers, on YouTube the first 100 view day took about 6 weeks, the first 100 subscribers were on board in three months. There were ~23,500 views the first six months on the YouTube channel.
Now try to take that information and do a five year projection. Remember that the channel only covers NVIDIA Jetson centric content, which means in general that there is a product launch about every year or so. What kind of numbers would you guess?
2019
Going into 2019, the social media properties seemed pretty healthy. YouTube had ~425,000 views and 7,800 subscribers. The JetsonHacks website saw ~188,000 visitors go through 582,000 views. That’s a lot of people consuming a lot of JetsonHacks content!
The 2017 and 2018 user counts and views were both about the same. I figured that we had reached a plateau of sorts, about the size of the Jetson community give or take.
I figured wrong! In March, NVIDIA launched the Jetson Nano Developer Kit. The reaction was immediate, traffic doubled over night.
YouTube
The introduction video on the Jetson Nano is the first video to reach 100K views on the JetsonHacks channel. That video alone is more that 25% of the entire 2018 video view total! We also added some new YouTube subscribers. 10,900 new subscribers (!!!). Right now we’re right at 19,000 subscribers, up from 7,800 last year. Wow. Welcome aboard!
YouTube Views 2018 vs 2019
YouTube views? 920,000. To put that in perspective, the combined views in the 4.5 years leading to 2019 were 1,250,000. We’re now at 2.1M views lifetime. That’s amazing!
JetsonHacks Website
As you know, the YouTube videos usually have an associated article on the JetsonHacks website. Here’s the website traffic:
JetsonHacks 2019 Website Views
Views in 2018 were 582,000, 2019 959,000. Visitors? 188,000 versus 338,000. I would say that there is a little growth happening in this trend.
The most popular article on the website in 2019 was Jetson Nano + Raspberry Pi Camera with 58,600 views. Visitors from around the globe stopped by for some Jetson goodness. Here’s the top 10:
JetsonHacks 2019 Views by Country
It remains quite surprising to me that the website is this widely read.
Github
With the advent of the Jetson Nano, we started a new Github repository on the JetsonHacksNano account. A large driver of traffic to the website and YouTube channel is the Jetson Nano, it makes sense to split it off into another entity.
The Good, Bad and Ugly
As the channel has grown, the inevitable happened. First, there are physically too many comments, questions and emails for me to physically answer. I do try to read them though. It’s part of the network effect we mentioned earlier.
A lot of the questions are better asked in the official NVIDIA Jetson Developer forums. And certainly if you bought hardware and are looking for support, please ask the manufacturer for help first.
Second, kinda behind the scenes, the amount of spam went up exponentially. Please excuse anything that the spam killers and I don’t catch.
Third, bigger audience, more bans! I know that a lot of people want to share their opinion on products or me personally. While I appreciate them sharing, there are bounds. Even more fun, the bounds are all at my sole discretion! So if I wake up one morning and don’t like the sound of something, ban! Fortunately we’re in a small corner of the Internet, and I only had to ban a dozen or so this year. Does it make me a bad person to say that I kinda enjoy it?
Thank you for all of emails and invitations to work on projects. Unfortunately my time is pretty well accounted for these days, and it is difficult to fit other projects into my schedule. That doesn’t mean that I don’t want to hear about it, certainly if it is interesting!
Next Decade
Wandering into 2020, we should see all sorts of new and exciting Jetson products and projects. I am actively working on making everything mo’ better. I want to thank you for your support, and I am glad that you are part of this community! Are these ’20s going to be roaring too? Happy 2020.
With the release of JetPack 4.3, L4T 32.3.1 is now available for the NVIDIA Jetson Nano Developer Kit. Several of the JetsonHacksNano Github repositories on the JetsonHacksNano account have been updated to support this release.
We have updated some of the JetsonHacksNano repositories to reflect the changes. Note that previous releases can be found in the ‘release’ section of each repository.
Simple example of using a MIPI-CSI(2) Camera (like the Raspberry Pi Version 2 camera) with the NVIDIA Jetson Nano Developer Kit. L4T 32.3.1 uses OpenCV 4.1.1 (previous versions were OpenCV 3.X), so the path names were changed to reflect the new library location.
This is a utility repository which aids in building the Linux kernel and modules. Several different repositories use this as the basis to build new kernel images. Note that the intended use is to use the repository scripts to download the kernel source files, compile the kernel, and compile the modules. Uses scripts/config to modify the .config file. Because you should be familiar with the Linux kernel make procedures, this is for advanced users only.
Starting with L4T 32.2.1 (JetPack 4.2.2) on the NVIDIA Jetsons and the Intel RealSense SDK version v2.23.0, it is now possible to do a simple install from a RealSense debian repository (i.e. apt-get install). Previous versions of this repository require building librealsense from source, and (possibly) rebuilding the Linux kernel.
The current recommendation from Intel is to use UVC for video input on the Jetson family. The UVC API in librealsense has been rewritten to better support this use case.
Install the realsense-ros library on NVIDIA Jetson Nano Developer Kit. Installs RealSense ROS Version = 2.2.11, which expects a librealsense v2.31.0 installation.
With the release of JetPack 4.3, L4T 32.3.1 is now available for the NVIDIA Jetson Nano Developer Kit. Several of the JetsonHacks Github JetsonHacksNano Github repositories on the JetsonHacks account have been updated to support this release.
Note that previous releases can be found in the ‘release’ section of each repository when applicable.
Build the NVIDIA Jetson TX2 Kernel and Modules on the TX2 device itself.
There have been changes since this repository was originally published a few years ago, namely the Linux kernel is now signed and stored in a disk partition separate from the APP partition. That means that, while compiling the Linux kernel from source on the TX2 is possible, there is now an intermediate step to flash the new kernel to the TX2 via a host system. So, compiling the kernel on the TX2 is not as useful as it used to be.
However, it is still possible to compile modules on board the TX2 and install them. The scripts help quite a bit in this regard.
Build the NVIDIA Jetson Xavier Kernel and Modules on the Xavier device itself.
There have been changes since this repository was originally published a few years ago, namely the Linux kernel is now signed and stored in a disk partition separate from the APP partition. That means that, while compiling the Linux kernel from source on the Xavier is possible, there is now an intermediate step to flash the new kernel to the Xavier via a host system. So, compiling the kernel on the Xavier is not as useful as it used to be.
However, it is still possible to compile modules on board the Xavier and install them. The scripts help quite a bit in this regard.
Starting with L4T 32.2.1 (JetPack 4.2.2) on the NVIDIA Jetsons and the Intel RealSense SDK version v2.23.0, it is now possible to do a simple install from a RealSense debian repository (i.e. apt-get install). Previous versions of this repository require building librealsense from source, and (possibly) rebuilding the Linux kernel.
The current recommendation from Intel is to use UVC for video input on the Jetson family. The UVC API in librealsense has been rewritten to better support this use case.
Install the realsense-ros library on NVIDIA Jetson Nano Developer Kit. Installs RealSense ROS Version = 2.2.11, which expects a librealsense v2.31.0 installation.
Note that previous releases can be found in the ‘release’ section of each repository.
Note: The V1 Raspberry Pi Camera Module is not compatible with the default Jetson Nano Install. The driver for the imaging element is not included in the base kernel modules.
Installation
Installation of the camera is the same as on the earlier development kit, and the Raspberry Pi. You’ll need a couple of RPi cameras, the new Jetson Nano B01, and so on:
Installation is simple. On a Camera Connector, lift up the plastic camera cable retainer which holds the ribbon cable in place. Be gentle, the retainer is fragile. You should be able to pry it up with a finger/fingernail or a small screwdriver. Once loose, insert the camera ribbon cable with the contacts on the cable facing inwards towards the Nano module. Make sure that the ribbon cable seats all the way into the connector. The tape on the connector should face towards the outer edge of the board. Then press down on the plastic tab to capture the ribbon cable, applying even pressure on both sides of the retainer. Some pics (natch):
Lift up the Camera Cable Retainer
Press down on Camera Connector Retainer
RPi camera installed!
Dual RPi Cameras on Jetson Nano B01
Once you have the cameras installed, you can easily test them. The Gstreamer pipeline element nvarguscamerasrc parameter sensor_id controls which camera is being selected:
The examples in the CSI-Camera examples have been extended to support the extra parameter. Also, as shown in the video, we’ve added some instrumented examples so that we can get the elapsed time for executing blocks of code, and print the number of frames per second being both read from the camera and displayed on the screen.
Software
On the JetsonHacksNano account on Github, there is a repository named CSI-Camera. There are a couple of simple ‘read the camera and show it in a window’ code samples using OpenCV, one written in Python, the other C++. You can checkout v3.1 to match the video, though releases are bound to change.
For the Python examples you may need to install numpy. You can install it using pip:
$ sudo apt-get install python3-pip
$ pip3 install cython
$ pip3 install numpy
The third demo is more interesting. The ‘face_detect.py’ script runs a Haar Cascade classifier to detect faces on the camera stream. You can read the article Face Detection using Haar Cascades to learn the nitty gritty. The example in the CSI-Camera repository is a straightforward implementation from that article. This is one of the earlier examples of mainstream machine learning.
Mo’ Better Frame Rates
In the ‘instrumented’ folder of CSI-Camera, there are several different works in progress and tools for benchmarking performance. These are written in Python. One of these tools is a very simple minded time profiler which allows you examine the elapsed time for executing a block of code. This is written as a Python class in the file timecontext.py.
You can play with the samples, like we did in the video. Of note is the CSI_Camera class, which allows camera capture to happen in a separate process. On a multi-processor CPU like the Jetson, we typically think of a separate process running on a different CPU. Of course, this is only if another CPU is available. This is all handled transparently by the operating system.
Dealing with the camera hardware in a separate thread provides several advantages. Typically the main thread has a loop (usually referred to as the display loop) which gathers the frame from the camera, processes the frame, displays the frame in a window, and then yields for a short amount of time to the operating system so that other processes can execute. These processes include things like reading the keyboard, mouse movements, background tasks and so on.
The main thread has a limited amount of time for this loop, it’s a pretty close match to the maximum expected frame rate. By reading the camera in another process, we get the benefit of reading the camera frames in a timely manner, regardless of the main loop speed. This helps with obvious frame speed mismatches, say when you are using a camera that is providing 120 fps, but the display loop can only show 30.
Reading through the code, you will see that the camera read saves the latest frame. When the display loop requests the latest frame, the CSI-Camera instance will return the latest frame that it has received from the camera. This effectively skips over any frames that were not consumed by the main loop, essentially discarding them.
Pick Your Frame Size Wisely
Processing video data is all about picking the smallest amount of data that you can get away with and still receive consistent results. Let’s say we have a frame size of 1280×720. Remember that if we ‘halve’ the size to 640×360, we have reduced the number of pixels that we need to process to 1/4 of the full frame! In other words, it takes 4 640×360 frames to make up a full 1280×720 frame. In many cases, this is a reasonable tradeoff. You will notice that many machine learning algorithms also use this trick, using what what we usually think of as thumbnail size images to represent full images.
The Raspberry Pi Camera provides several different frame sizes and frame rates. Pick what best fits your need. Also, remember that the nvarguscamerasrc supports setting the frame rate the camera driver returns. You may find this useful.
Watch the video, play with the code!
Notes
Demonstration environment:
Jetson Nano Developer Kit – B01
L4T 32.3.1 (JetPack 4.3)
OpenCV 4.1.1
Raspberry Pi Camera Module V2.1
In the video, we also use a Logitech Webcam: https://amzn.to/2HTXkCq with the Cheese application.
The Developer Preview (DP) of JetPack 4.4 is now available. This release brings in support for the new Jetson NX Xavier module, along with new versions of CUDA, Tensor RT, cuDNN and support for the upcoming DeepStream 5.0 Developer Preview. JetPack 4.3 remains the latest production release.
We are pleased to announce JetPack 4.4 Developer Preview 25 supporting Jetson AGX Xavier series, Jetson Xavier NX, Jetson TX2 series, Jetson TX1, and Jetson Nano. (JetPack 4.3 remains the latest production release.)
JetPack 4.4 key features include support for Jetson Xavier NX module, new versions of CUDA, TensorRT and cuDNN, and support for the upcoming DeepStream 5.0 Developer Preview.
Support for Generic Timestamping Engine (GTE) for Jetson AGX Xavier and Jetson Xavier NX
Support for Dynamic Frequency Scaling (DFS) for Video Image Compositor (VIC) using actmon
SE (Security Engine) samples to demonstrate hardware backed authentication and encryption capabilities of Jetson TX2 series, Jetson AGX Xavier and Jetson Xavier NX modules.
Utility to fuse multiple Jetson modules simultaneously
Option to specify APP partition size on the microSD card during initial configuration at first boot of Jetson Nano Developer Kit
JetPack 4.4 components:
L4T R32.4.2
CUDA 10.2
cuDNN 8.0.0 (Developer Preview)
TensorRT 7.1.0 (Developer Preview)
VisionWorks 1.6
OpenCV 4.1
Vulkan 1.2
VPI 0.2.0 (Developer Preview)
Nsight Systems 2020.2
Nsight Graphics 2020.1
Nsight Compute 2019.3
Existing installations of JetPack 4.3 can be upgraded in-place to JetPack 4.4 Developer Preview without re-flashing the device. For more information about upgrading JetPack via the Debian package management tool, please refer to the JetPack documentation here 11.
Remember when you had to jump through all sorts of hoops to get your NVIDIA Jetson NVIDIA Kit to be able to understand Serial Protocol Interface (SPI) devices? Those days be gone. Looky here:
Background
The introduction of JetPack 4.3 brings with it a new tool, Jetson-IO. All of the Jetson developer kits include a 40-pin GPIO expansion header. Many of the pins can be used either as General Purpose I/O (GPIO) or Special Function I/O (SFIO). SFIO are functions such as I2C, I2S, SPI, and so on.
The default configuration of the pins is defined and programmed into the Jetson when flashed. Previously you had to go through a, let’s call it less than straightforward, process to reconfigure the pins to your needs.
The new Jetson-IO tool is here to help! While the previous process is useful for system designers, the majority of developers many times just look to modify the pins to the NVIDIA recommended special functions.
For example, if we look at a typical Jetson GPIO Expansion Header (such as this one for the Jetson Nano), we see that there are several pins that list as SPI_1, but we know that in the default configuration they are GPIO.
This is similar to other Linux embedded systems such as the Raspberry Pi. The RPi has a similar utility, raspi-config, to help with configuring pins on that device.
The default configuration sets most of the pins to GPIO. Here’s how to run Jetson-IO to change that.
Jetson-IO
The Jetson-IO utility is just a youngster, and in its initial release on the Jetson in JetPack 4.3 (L4T 32.3.1) there are some issues. These issues are noted in the documentation. The following two issues have been addressed in later releases.
The first issue involves initialization of some of the code. To fix it:
Then there’s a niggle to which you should be aware. If the Terminal window that you are working in is too small, then the menus have difficulty displaying. Make sure that your Terminal window is large, so it can hold the menus.
Running Jetson-IO
After the setup, we’re ready to go:
$ sudo /opt/nvidia/jetson-io/jetson-io.py
Which will bring us to the main screen:
Jetson-IO Main Screen – Image Courtesy NVIDIA
We select Configure 40-pin expansion header:
Configuration Screen
In our case we select SPI1 (pins 19,21,23,24,26). Use the arrow keys to navigate to the desired entry, Return selects/deselects the entry. Select Back when done. You should see the new configuration on the main menu. Save and reboot to reconfigure pins. You will go through the familiar Confirm/’Deny everything you have ever done’ prompts, then the system will reboot. After that, SPI goodness is available.
Of course, the Jetson-IO utility has much more functionality than this simple example. Look through the documentation to see what you can do to amaze your friends and confuse your enemies!
After soldering the headers onto the display, we wire the display:
Jetson Nano
Adafruit 1.8″ TFT Display
Pin 6 GND
Pin 1 GND
Pin 1 3.3V
Pin 2 VCC
Pin 18 gpio15
Pin 3 Reset
Pin 22 gpio13
Pin 4 D/C
Not Connected
Pin 5 CARD_CS
Pin 24 SPI_1_CS0
Pin 6 TFT_CS
Pin 19 SPI_1_MOSI
Pin 7 MOSI
Pin 23 SPI_1_SCK
Pin 8 SCK
Not Connected
Pin 9 MISO
Pin 17 3.3V
Pin 10 LITE
Connections
Note that while SPI is only 4 signals (6 if you count power and ground), this device has a couple of more in use. One of the extra connections provides power to the backlight of the display.
The Jetson Xavier NX dev kit brings Jetson Xavier performance to help solve AI and robotics where you need some serious machine learning horsepower.
The entry level Jetson Nano is a good way to start for a lot of people, introducing the fundamentals of machine learning and GPU computing power. Consider the Xavier NX as a professional level to that, where you need beast mode to get serious work done.
Like other Jetsons, the Xavier NX dev kit can be thought of in two parts. The first part, the Jetson NX Module contains the compute and memory components. The second part is the carrier board, which provides affordance for connecting peripherals and providing power input.
The Jetson Xavier NX carrier board is the same layout as the Jetson Nano, with a couple of nice changes. First, there is a wireless card in the M.2 Key E slot on the underside of the board, pre-installed with antennas captured by the plastic base. Second, there is a M.2 Key M slot, also on the other side of the carrier board, which affords the means to install expansion items such as a NVMe SSD.
Like the Jetson Nano, the Jetson Xavier NX runs from a micro SD card. Unlike the Nano, the Xavier NX only runs from the supplied 19V power supply through the barrel jack. While you can power the Nano via the micro USB 2.0 port, the Xavier needs more power than can be supplied over that port. The Xavier runs in either 10W or 15W power profiles, the carrier board supports up to 5A@19V.
The Jetson Xavier NX includes special purpose machine learning hardware, including 48 Tensor Cores and 2 NVIDIA Deep Learning Accelerators Engines (NVDLA). Overall performance in machine learning tasks averages over 10x that of a Jetson TX2.
Gigabit Ethernet, M.2 Key E (WiFi/BT included), M.2 Key M (NVMe)
Display
HDMI and display port
USB
4x USB 3.1, USB 2.0 Micro-B
Others
GPIO, I2C, I2S, SPI, UART
Mechanical
103 mm x 90.5 mm x 34.66 mm
Some Pics natch – Click to Expand
Dev Kit Top View
Underside Carrier Board
Power, Display, USB, Ethernet
μSD Card, Button Headers
GPIO Headers
Camera Connectors
Carrier Board – Module Removed
Jetson Module Underside
Containers
The next big push in the Jetson ecosystem is Docker based containers. While Docker support has been on the Jetsons for a few releases, they are now going mainstream. NVIDIA has built a server ecosystem, NVIDIA NGC, which contains pre-trained AI models and other resources which serve as building blocks in AI application development.
A great example of this is shown in the video as a demo. The 4 applications that are running are containers, running 7 machine learning models in total.
This shows the power of the Jetson Xavier architecture, where you get desktop level performance in a power budget of only 15W.
The NVIDIA Jetson Xavier NX Developer Kit is the real deal for edge applications and robotics. There’s enough horsepower to run several models at once, while at the same time maintaining a very small power budget.
To be clear, this is pro level. If you are just getting started, the Jetson Nano is a good starting place. On the other hand, if you have outgrown the Nano, have experience with machine learning and/or have demanding inferencing applications, certainly checkout the Jetson Xavier NX Developer Kit.
It is a simple task to a sea of gigabyte goodness to the NVIDIA Jetson Xavier NX by adding a NVMe SSD. This is the best performance upgrade you can make for your Jetson. Looky here:
Background
Even though they share the same form factor, the Jetson Xavier NX Developer Kit has a nice addition in comparison to the Jetson Nano. A M.2 Key M slot. With the M.2 Key M slot, we can easily add a Solid State Drive (SSD). The M.2 Key M slot uses the Non-Volatile Memory Express (NVMe) protocol that runs over PCIe.
There are two types of SSDs that use Key M. When you install a SSD card in the slot, the card needs to be the NVMe PCIe type.
The SSD is typically 5-20x faster than the flash memory in a SD card, so anytime you do disk access things speed up considerably.
This process works on the Jetson AGX Xavier too. See Notes below.
Materials and Tools
In the video, we install a Western Digital 500GB NVMe SSD. There are several different sizes and brands of these types of devices, we also get good results with the Samsung variety. We also use our trusty iFixit Pro Tech Toolkit which contains a variety of useful tools for just this purpose.
Hardware Installation
The M.2 Key M connector is on the underside of the carrier board. A retaining screw is at the end of the M.2 slot. Remove the retaining screw. From the factory, the screw may have some blue thread locker on it, which may require a little elbow grease to start the removal process.
Remove Retaining Screw
Next install the the SSD card into the Key M connector, and then use the same retaining screw to hold it in place.
Install SSD and secure with retaining screw
Disk Configuration
After the hardware install, it is time to configure the disk under Ubuntu. Hook the Xavier back up to a keyboard, mouse and monitor. In the video above, we use mostly GUI tools, please refer to the video for a walk through.
The basic steps are to format the disk, and then create partition(s). In the video, we just allocate most of the disk space to one big ol’ partition. However you may want to be a little fancier. Being Linux, there are tools for doing this through the command line, as all the pros will tell you.
At this point, you can now begin using the SSD. It will show up on your desktop as an unmounted drive.
Running from SSD
We go a little further here. After the Jetson boots the image from the SD card, we switch the rootfs to point to the SSD. In effect, the system will now run from the SSD, the SD card is only there to boot the system.
You should do this process directly after creating a new SD card.
Next, copy the rootfs of the eMMC/SD card to the SSD
$ ./copy-rootfs-ssd.sh
Finally, we will add a service which will run a script when the system starts up. The script will “pivot the root” to the SSD so that the system will run from the SSD.
$ ./setup-service.sh
There’s a chapter in the video ‘Tech Talk Time’ that walks through how the script works. After setting up the service, reboot for the changes to take effect.
The performance of your system will feel much snappier after this simple modification.
Boot Notes
These script changes the rootfs to the SSD after the kernel image is loaded from the eMMC/SD card. For the Xavier NX, you will still need to have the SD card installed for booting. As of this writing, the default configuration of the Jetson NX does not allow direct booting from the NVMe.
Upgrading
Once this service is installed, the rootfs will be on the SSD. If you upgrade to a newer version of L4T using OTA updates (using the NVIDIA .deb repository), you will need to also apply those changes to the SD card that you are booting from.
Typically this involves copying the /boot* directory and /lib/modules/<kernel name>/ from the SSD to the SD card. If they are different, then modules load will be ‘tainted’, that is, the modules version will not match the kernel version.
Installation of the SSD is different on the AGX Xavier. See: Install NVMe SSD on NVIDIA Jetson Developer Kit. After formatting the drive, software installation is the same as shown in the article.
Some of the more popular pages on JetsonHacks are the pinouts for the GPIO headers on each of the Jetson developer kits. Here’s a new one for the Xavier NX!
The Jetson Xavier NX GPIO J12 Header Pinout gathers together some of the information that’s spread over several documents such as the sysfs number for the GPIO pins, I2C bus numbers and the device of the UART and places it in one place. Plus there’s a bunch of fun colors!
NVIDIA announces today that the production version of JetPack 4.4 is now available. JetPack 4.4 replaces the current JetPack 4.3 as the production version.
Just some of the Jetsons supported
There are many upgrades and new features. Here’s the official blurb from NVIDIA:
We are pleased to announce the JetPack 4.4 production release 1 supporting Jetson AGX Xavier series, Jetson Xavier NX, Jetson TX2 series, Jetson TX1, and Jetson Nano. (JetPack 4.4 replaces JetPack 4.3 as the latest production release.)
The JetPack 4.4 production release builds on top JetPack 4.4 Developer Preview, and includes production versions of TensorRT 7.1 and cuDNN 8.0.
Along with JetPack 4.4, we are introducing a web based Power Estimator tool 2 to simplify creation of custom nvpmodel power profiles for Jetson.
Support for Dynamic Frequency Scaling (DFS) for Video Image Compositor (VIC) using actmon
SE (Security Engine) samples to demonstrate hardware backed authentication and encryption capabilities of Jetson TX2 series, Jetson AGX Xavier and Jetson Xavier NX modules.
Utility to fuse multiple Jetson modules simultaneously
Option to specify APP partition size on the microSD card during initial configuration at first boot of Jetson Nano Developer Kit
JetPack 4.4 components:
L4T R32.4.3
CUDA 10.2
cuDNN 8.0.0
TensorRT 7.1.3
VisionWorks 1.6
OpenCV 4.1
Vulkan 1.2
VPI 0.3 (Developer Preview)
Nsight Systems 2020.2
Nsight Graphics 2020.1
Nsight Compute 2019.3
Existing installations of JetPack 4.4 Developer Preview and JetPack 4.3 can be upgraded in-place to the JetPack 4.4 production release without re-flashing the device. For more information about upgrading JetPack via the Debian package management tool, please refer to the JetPack documentation here 1.
Over The Air (OTA) updates is one of the new features for the JetPack 4.4 Production Release – L4T 32.4.2. Unfortunately, there are some issues with this feature that people are encountering in the product rollout.
Here’s the money quote from NVIDIA:
Note: We have temporarily disabled the feature of upgrading JetPack or L4T using debian package management tool due to an issue we found in one of our debian packages causing the device to not boot properly. We have identified the root cause and fixing it currently. We will re-enable this feature soon once fixed and update this post.
Please note that one can still install JetPack using SDKM or downloading SD card images (for Jetson Nano and Jetson Xavier NX) from the JetPack page.
The major issue people are reporting is that after a system upgrade, the Jetson boots, but goes to a blank screen with a blinking cursor. You can read through this thread on the Jetson Xavier NX forum: Jetson Xavier NX not booting.
There appears to be a work around, but since these issues are just coming to light the day of the rollout it feels prudent to take this into account before upgrading your system.
Note: If you create a system from a JetPack 4.4 SD card image (on the Jetson Nano and Jetson Xavier NX) or install JetPack 4.4 using the SDK Manager (Jetson AGX Xavier, Jetson TX2), you will not encounter these issues. However, if you issue the commands:
$ sudo apt update $ sudo apt upgrade
When you reboot the system, you will get a black screen and a flashing cursor, no GUI.
OTA updates is one of the most anticipated features of this release. The folks at NVIDIA are working on this, there should be fixes soon.
The JetPack 4.4 Over The Air (OTA) updates issue that some folks encountered on on the first couple of days of the release have been fixed! Life be good again.
That gives us marching orders. The end goal will be to upgrade our systems to the new version. I don’t recall really having a good article about upgrading Jetson articles here on JetsonHacks, so I think it’s about time to make an effort to do so. We’ll share some tips and tricks from how some people work through this process.
There are several things that are apparent from watching peoples reactions to the recent update/upgrade issues. One can certainly tell the professional developers from the normal people.
Developers
Most professional developers are very wary of system updates/upgrades (there’s a certain amount of dread in updating a system). Part of that it is human nature. The trade off is that your are on a system which you know is flawed, but if you have been working on it a while you know where the flaws are hiding. An update/upgrade may fix the flaws, but may require a significant amount of work on the developers part to take advantage of the new fixes, features and so on.
On the other hand, the developer may have no interest in the flaws that are being addressed in the update. However, the updates and upgrade may affect parts of the system that will require work on the developers part for integration. For example, an update to a system library (like CUDA, let’s say) means that any programs that are compiled against an earlier version need to be rebuilt for the new version. New features are great and everything, but if the developer doesn’t use them in their project it’s just extra work.
Also, each library version update seems to have its own little niggles for it to build and work properly with other libraries. Niggling can be time consuming.
The experienced developer knows at any time things can break, and out of self defense tend to have strategies for minimizing the amount of down time in getting things back in running order.
Normal People
Most people have a different expectation of updates and upgrades than a developer. The basic idea of updating and upgrading is that the system will become better, increase performance and improve capabilities.
This is true as most updates don’t break the system, and the system is better afterwards. However, this is also a “Rainbows and Unicorn” view of the world. People can benefit from managing their expectations about what updates and upgrades can bring, and take some precautions to protect themselves in case things go south.
Backups
Backups are two things. Mind numbingly boring, and absolute sheer terror. Boring in that there is really no sense of pleasure when they are working correctly, and absolute terror when you have to actually depend on one to work.
Because developers are frequently dealing at a system level, there is always the possibility that they can break the system (perhaps irreparably). Therefore, they tend to have various backup strategies. This usually includes some sort of source version control for their code base, backups for their data, full system backups and so on.
Out of self defense, the developer generally has a method to regenerate a new system, typically with scripts to automate the build process. When a new major version of an OS comes out they will build a new system from scratch. They keep the previous version, along with their development environment, and build a new version. That way, if there are issues with the new version they can go back to the old version and check for differences. Extra dependencies always seem to sneak in but don’t get tracked correctly, forcing a rebuild from scratch exposes these.
Developers know that if you can’t build your system from scratch, you don’t have a system. Instead, you have a ball of pain that is guaranteed to bite you at the worst time.
Most normal people don’t think in these terms. However they do know from possibly unpleasant experiences that they need to keep a backup of some sort, or at the very least backup data that they feel is important.
Marching Orders – Backup & Upgrade
That sets up our next couple of articles. “Backup for Jetson” and “Upgrading to JetPack 4.4 via OTA updates”, or the same articles with even more clever names. Look for those, coming to a web page near you soon.
We can benefit from talking about how to go about backing up our system, and various ways of preparing for what we will call ‘something bad happening’.
Once we have our backups ready, then we will be able to upgrade our system.
Upgrading is straightforward, especially after all the fretting we’ve been doing about backups and doomsday scenarios. There is another case we will talk about in the upgrade.
In an earlier article, Jetson Xavier NX – Run from SSD , we setup our system to run on a NVMe SSD once the system boots. We will need to take an extra step when we upgrade our system to accommodate this.
Once you have your Jetson all setup the way you like it, back it up! Looky here:
Nuts and Bolts
If you are only interested in a backup method, we’ve written some scripts that use the Linux rsync command line utility to backup the root directory of a Jetson to another directory. Typically the other directory is on a different drive.
You will need some backup medium. Network attached storage, another computer, or external drive. A relatively inexpensive way to get started is to use a USB drive:
Western Digital 8TB (other sizes available): https://amzn.to/2ZLSijf
These are 5400 RPM disk drives generally meant to be used for archiving data.
The scripts are located in the JetsonHacks account on Github in the backupJetson repository. There are basic instructions there, though you may find it useful to watch the video. These are overly simple scripts, you may want to tailor them to your needs. rsync provides a very large number of parameters for configuration, you may want to choose others than the ones in the scripts.
As an alternative you can use a GUI front end to rsync such as Back In Time as demonstrated in the video.
In any case, reading the rest of the article below will help put everything in context. Here’s the money quote:
If you cannot regenerate a system from scratch, you do not have a system. You have a pain train that is on the tracks coming towards you. When will it arrive? One of the few guarantees in life. The pain train will arrive when you least expect it, when it is the most costly, and when it will hurt the most. That is right before the big demo, or a big project is due, or some other time when your system absolutely has to work.
Background
Let’s go over some of the ways that people handle backups in a professional environment. The idea here is that if we understand why these backup procedures are in place, we can tailor them to suit our needs.
Backups are a mind numbingly boring subject that can elicit sheer terror when they are not present, or don’t work. Most people that have used computers for any amount of time encounter an “Alt-shift” moment when they accidentally delete important information or a system update puts their system into an unusable state.
Think of backups as insurance. The amount of insurance you take depends on what type of loss you are you trying to protect yourself from. We usually think about backups as either time, or loss.
If we are looking through the time lens, “How long does it take me to get back to the point before I needed to restore my system?” Also, “Does restoring my system get me back to where I can start working again?” Sometimes backups bring you back to a point where the system will just corrupt itself again when restored, say in the case of a system upgrade.
When we look at backups through a loss lens, we think about data that is difficult or impossible to recreate or replace. Typically this is data that has been uniquely gathered or created, some common examples being the pictures on your phone, spreadsheets you create, documents that you have written, presentations you make and so on.
This idea helps us bin the data as to whether it is unique or if it is common. Unique data is what we have created, unique to us. On the other hand, common data is information that we can gather from other sources. While our system relies on common data, there are always copies of this data available so that we can get it from another source. Large data sets that are available on the Internet are examples of common data, a prime example being machine learning inferencing models.
Temporary Data
Another type of data that is stored on systems is temporary or cached data, which you can think of as working products. This can be a significant amount of data, but you do not think of it as ‘valuable’ in the sense that you can always recreate it from source material.
In more concrete terms, when creating the video above, the cache to render the video is around 100 gigabytes. As we will explain later, we actually need to make 3 copies of the data , that ends up being ~300GB. We’ve done about 250 videos on the JetsonHacks YouTube channel, so that would end up around 75 Terabytes of data.
But this data is not valuable in any meaningful sense, it is a by-product of rendering the video. That’s why people go through a multi-step process to archive information. When a project is done, they remove the caches and such, then archive their project on secondary storage.
We don’t actually save the caches from the video, of course. While people will tell you that “data storage is free”, ordering 75 Terabytes of disk storage from Amazon ends up in a good sized bill. Programs that backup data provide ways to exclude directories such as temp directories or directories holding cache information.
Types of Backup
Most of the time we think about backups in a few different ways.
Full System
You can think of this as a snapshot in time
Desktop systems have dedicated programs to do this, for example Macintosh has Time Machine
On a Jetson, this might be thought of as the base L4T system + the programs that you run on your machine, like machine learning and trained models
Differential and Incremental backups
Differential are files that have changed since the last full backup
Incremental backups are files that have changed since the backup, be it full or incremental backup
This can be automated, backup every X amount of time, minutes, hours, days, weeks, system startup
Most expensive
Data backup
You may have data that you want to keep safe and accessible
Separate from the system software
Generally unique to your system, for example saved images, videos or other gathered information
May be irreplaceable
Developers backups (programming)
Generally this includes the source code and associated build information, data and documentation
Versioned, so you can keep track of changes that are made
Especially important in a group programming environment
Usually has a separate formal system for this, such as Git or Subversion
There are easy ways to do this on a personal level, such as Github
Some programming environments have built in support
3-2-1 Rule
In most professional environments, the physical aspect of storing backup information is referred to as “The 3-2-1 rule”
Keep at least three copies of your data
Original copy and at least two backups
Keep the backed-up data on two different storage types
The data is less likely to be corrupted when on two different types of storage
Keep at least one copy of the data offsite
A local disaster (like a fire!) could ruin your backups
This is easier now because of cloud backup
Each approach has a different cost in terms of storage space, time and effort. Here’s the bullet points:
Storage Space
Money attached – Drives cost money!
Hardware – Takes up physical space, and you need it wire it
Different types: Local drives, network storage, cloud storage
Organization – keeping track of data can be a challenge in and of itself
You need to make at least 3 copies – Production (the data on the computer), Local (a copy of production), and Offsite (another copy of production). Offsite probably means cloud storage
Time
How much of our time is needed, and how much computer time?
Our time – Initial Setup – backup programs/commands/tests
Computer time – How long does it take to make a backup, or an incremental backup?
Manual or automated? If it’s not automated, it may be skipped
Effort
How much do you need to know to make a backup?
What do you have to do to start a backup?
If it’s too hard, you won’t make backups frequently
Jetson Backup
Why embedded systems are a little different than a desktop:
More susceptible to hardware failures or experiments that go bad
Usually depend on memory (eMMC or SD card) which can be relatively unreliable (SD cards especially)
Jetson in particular has a different drive layout than other systems with several different partitions
Different Categories of Users
Developers
If you are a developer you always just assume that something will break catastrophically, and that you will need to regen a system. Most developers have enough experience working at a system level that they know if you make a mistake, the system can become unstable.
If you cannot regenerate a system from scratch, you do not have a system. You have a pain train that is on the tracks coming towards you. When will it arrive? One of the few guarantees in life. The pain train will arrive when you least expect it, when it is the most costly, and when it will hurt the most. That is right before the big demo, or a big project is due, or some other time when your system absolutely has to work.
As part of the testing regimen, developers typically will have different versions of an operating environment that they need to support. For example on the Jetson, they may have an environment for the JetPack 4.3 and another for the JetPack 4.4 version. That’s why professional developers don’t get excited about new releases, because it means more things that they have to keep track of and more work to bring everything thing forward.
Typically for a major release, the developers will gen up a new system and rebuild the system from scratch just to make everything works as expected.
With that said, developers will usually create a base system with their environment modifications (like their programming environment, data sets and so on), and then make a full system backup. The system is then backed up periodically (depending on the place, usually once every day or two). Some places will make local backups more frequently (let’s say every hour), and then ripple that to more permanent storage less frequently.
Typically a developer will have some plan for backing up their work so they won’t lose more than a half days worth of work or so if things go terribly wrong.
Remember this is for active developers, people who are making changes to their system day in and day out. Also, they may be changing the way that the overall system works.
To restore the system, it’s pretty simple. Find the last backup snapshot, restore the system and try to piece back everything together since that point in time.
Normal People
For normal people who are not actively trying to destroy, I mean, improve their system like a developer, backups are usually thought of in a different manner. In a business that is collecting data, let’s say an accounting system, the accounting software will organize the data collection so that it is backed up as part of the process of collection. This is typical of most data base types of software applications where you will hear terms like audit trails and journaling. In most cases, the data is gathered over a network type of application with the actual data being stored on network attached storage. People have begun doing these types of application over the Internet, with most of the data being stored in the cloud.
Even if data is stored in the cloud, remember the 3-2-1 rule. The information is downloaded on a schedule so that the information can be stored locally.
Usually in this situation there is a full system backup that can restore all of the application software and configurations on the local computer. In a separate step, you then retrieve the data from a backup data store and then you’re ready to get back to work. In most places, there is an IT or system administrator person that handles this procedure.
Yeah, but what’s a happy balance?
That’s great and everything, but what do we do on something like a Jetson? At JetsonHacks we are developers. Most of our development and programming changes go into a version control system, Git. Typically we create a “system environment” which has a base L4T version along with the programming tools and data sets we need. Then we make a backup, so that if things go south then we have a stable base to work from.
We also make backups of the data sets we are working on regularly. Thus, restoring the system consists of restoring the base system environment that we backed up, and then adding the data sets and the Git repositories of the source code and scripts for our project. Remember, these data sets and the Git repositories are also from backups. We pull from three backup silos so to speak.
To be clear, whenever a new L4T is released, we build a new “system environment” from scratch. The “system environment” gets backed up. We then add in our data sets and Git source. There are some inevitable hiccups in this procedure, usually due to library version mismatches. However, it is reliable and it is rare that we have a “Alt-Shift” moment.
A Recipe
If you are not a developer, you will benefit from organizing your system before backups. Create a base “system environment” which includes all of the applications and libraries that you want to use. Then make a backup.
Certainly keep track of what your system environment contains, you will need to recreate it from scratch at some point.
Whenever you add another essential program that you know you want in your system environment, make another backup.
Now, if you keep the specialized data you use in specific directories, then you only need to back up those directories on a regular basis. Even if you have a catastrophic failure, you only need to restore a system environment and add your last data backup. Then you are up and running again.
Just to be clear …
Backups are a surprisingly deep subject. The above are just some suggestions on handling backing up your data. In fact there is an entire industry that has sprung up around saving computer data.
It is not possible to cover in a short article “what you should do” when making computer backups, as everyone has their own special situation. You will do best by reading some background material, and then deciding what best fits your situation.
The more organized your are, the easier the task becomes. If your data is spread out all over that place, programs and libraries added without much thought and so on, you steer yourself towards a full backup solution. That’s not bad, but it requires more resources in physical drive space and time.
On the other hand, if you only need data backups and make full system backups when you add your programs, you cut down a lot on the number of backups that you make and the resources required.
An often asked question is “How do I backup the SD card for a Jetson Nano or Jetson Xavier NX?” Here’s an answer, “Let’s use the dd tool”! Looky here:
Background
According to Wikipedia, dd is a command line utility, the primary purpose of which is to convert and copy files. With dd, you can easily copy a partition or an entire drive.
The dd command is the oldest disk imaging tool on Linux still in use. Why? Because it works! dd is a powerful tool. We will use it to create a clone of a Jetson µSD card into an image file using an Ubuntu host computer. Then we will use the image file to create a clone image on another card.
While we can create a clone of a µSD and use it in our Jetson Nano or Jetson Xavier NX Developer Kits, other Jetson models with built in eMMC memory cannot easily use this method.
Careful Icarus!
It is important that you understand the arguments that you are using with dd. Incorrect arguments can lead to catastrophic data loss on your host machine. You have been warned!
The dd utility will copy every byte on your µSD card (even unused space). We will use a file compression tool, gzip, to help reduce the size of the µSD card image.
Note: Naturally, you will need enough drive space on your host computer to store the card image. If you do not use file compression, the size of the image file will be the size of the µSD card. For example, if you have a 64GB SD card, then you will need a little more than 64GB in free drive space on the host to create the image file.
Here are some SD cards and drives we use here at JetsonHacks:
By using file compression the resulting image file may be much smaller, but you still need a significant amount of free space.
Let’s Clone!
The first step is to figure out which drive is our µSD card. Plug the card into the host computer. You can then check for the device name using the command line:
You can also use the Disks GUI application to identify the µSD card:
Disks application
The device name should be similar to /dev/sdX where the X represents a letter. In the examples above the µSD card is /dev/sdc
The Jetsons have several partitions on the µSD card. These partitions serve a variety of purposes, mostly to do with machine configuration and startup. You will need to copy all of the partitions for your Jetson to work properly with the card.
Note: A number following the device name indicates a partition on the drive. Because we are copying the entire drive, we only need to use the device name, and do not include a partition identifier.
Clone the Drive
The second step is to create the clone of the card:
Naturally, you can name the image file and place it where you want. The above will place the backup_image.img.gz file in the home directory. As an example, if the card is /dev/sdc
The arguments sets the block size (bs) to 64K (you can experiment with this, larger block sizes are faster), noerror ignores read errors, and sync fills blocks with zeros if there are read errors.
Once the command starts, it may take a long while to complete depending on the size of the card. There is no progress indicator. This may take a while, in the example copying a 64GB card with 15GB in use took around 45 minutes. The amount of time varies widely depending on the usual factors, such as disk speeds, transfer speeds, size of the card and so on. When the copy is done and the Terminal prompt returns, you can remove the SD card from the host computer.
Restore the Drive
Once the image has been created, you are ready to test it out. Using a different µSD card that is the same size or larger than the original, insert the new card into the host computer. Typically we try to use the same type/brand of card, if only for good luck. The card does not have to be formatted, as dd makes a bit for bit copy of the drive.
Then, go for it. Again, make sure that the card is not mounted, and start the restore. Depending on how your system is set up, you may not need to be in super user mode to do the restore. In other words, ignore the sudo su command. To restore:
Once this process is complete, you should go check it out in your Jetson! Pop the card in, start it up, and you should be right where you left off with the master disk.
Another Big Fat Warning
You should only use these clones in the same machine. This is a quite wonderful method for creating a backup for your Jetson once you have it setup the way you like it. However, you do not want these clones to run on more than one Jetson due to security reasons. Here’s a more comprehensive NVIDIA Jetson forum thread on the subject: https://forums.developer.nvidia.com/t/jetson-nano-cloning-and-deployment-of-the-image-to-other-devices/74904
Conclusion
The actual process of creating a clone of a µSD for the Jetson is simple. Having a backup (or several) provides quite a bit of comfort when things go bad. Takes a while, but then doesn’t everything?
At GTC today, NVIDIA announces the new Jetson Nano 2GB priced at only $59! Looky here:
Background
Back in March 2019, NVIDIA introduced the the Jetson Nano. Today, NVIDIA announces it’s little brother, the Jetson Nano 2GB. The Jetson Nano 2GB is available for pre-order. In addition to the Nano 2GB you’ll also need a USB-C power supply and a micro-SD card. Here’s some Amazon affiliate links:
I recommend you get 64GB micro SD cards if you plan on following the Jetson AI Fundamentals course.
There are a some differences in addition to the price. First, the differences in the hardware:
The Jetson Nano 2GB has 2 GB of main memory, where as the current Jetson Nano has 4 GB.
By comparison, the Jetson Nano 2GB has 1 MIPI-CSI camera connector, whereas the Jetson Nano with 4GB has 2 camera connectors.
The Jetson Nano 2GB has fewer I/O connectors, and some of the header pins on the Nano 2GB are not populated, for example the fan header and the POE header. However, there are places on the carrier board for adding those headers.
Second, the major difference in the software is that the Jetson Nano 2GB runs lxde as its desktop. The Jetson Nano uses GNOME. If you run lxde on a Jetson Nano, you save more than 1GB of memory versus running GNOME. That means that you may think of the Jetson Nano 2GB of having more memory than it would originally appear. The 2GB will run the same software as the Jetson Nano or other members of the Jetson family.
You get most of the power of a Jetson Nano, but it costs 40% less!
Rather than replicate all of the specs and performance benchmarks on this blog, here’s a link to the NVIDIA blog entry where they detail the important parts. The 2GB uses the same Tegra X1 SoC that the Jetson Nano uses, the only major difference on the Jetson module is 2GB instead of 4GB of main memory.
Jetson AI Certification
Along with the Jetson Nano 2GB, NVIDIA also is making available the Jetson AI Fundamentals series as the start of their Jetson AI Certification course. Looky here:
I’ll say that the series is very important, because I helped make some of the videos, centered around build and programming a JetBot! Looky here:
I’ll point out that the JetBot even has a spiffy song.
Conclusion
The Jetson Nano 2GB is a great entry level device for getting started in machine learning for makers, students and educators. For those projects that need a little more compute power than the usual suspects deliver, it’s a great addition. And because the Nano 2GB is software compatible with the rest of the Jetson lineup, it means that you can upgrade easily if you need more compute power later on. Check it out!
The introduction of the Jetson Nano 2GB ships with a different desktop environment than the other Jetsons. The desktop environment is LXDE. You can change over to this desktop environment fairly easily. Looky here:
Background
Up till now, the default desktop environment on the Jetson has been Unity/GNOME. Unity is a shell around the GNOME desktop environment. While GNOME is attractive and easy to use this comes at a cost, namely memory. On a fresh install of JetPack, the memory in use is ~ 1.7GB.
With the introduction of the Jetson Nano 2GB this presents a problem. There is only 2GB of memory, so using 1.7GB to get the system up and running is a no go. Fortunately there are other desktop environments which use less memory. Lightweight X11 Desktop Environment (LXDE) is one such environment, and was chosen to be the default on the Jetson Nano 2GB. This saves ~ 1GB of main memory, which makes life much more comfortable on more memory constrained devices.
You may want to follow much the same procedure on other Jetsons, the Jetson Nano (4GB) can also benefit from these memory savings. Fortunately this is easy to do with the latest JetPack 4.4.1 release.
Installation
If you are using JetPack 4.4.1 (L4T 32.4.4), there are a couple of steps. First you will need to select LXDE as your desktop environment. This selection is available when you login (this screen is known as a greeter) in the settings menu (the gear icon):
If you normally login automatically, you can get to the greeter screen by using ‘logout’ in the power down menu.
Once you have logged in (LXDE should now be your desktop environment), you can switch over from the GNOME display manager (gdm3) to lightdm. This will also set the window compositor to Compton. From a LXTerminal (there is a shortcut on the desktop):
$ sudo dpkg-reconfigure lightdm
This will bring up a menu where you can select lightdm as the display manager:
After you make your selection, reboot for the change to take effect.
When you log back in, you can check your memory. You will find that you are saving ~ 1GB in comparison to using GNOME!
JetPack 4.4 and earlier
You can switch over to LXDE if you are using JetPack 4.4 and earlier. The process is described here:
Over on the JetsonHacks account on Github, there is a convenience script to help: installLXDE. Download the repository, switch over to the directory and install:
$ git clone https://github.com/jetsonhacks/installLXDE.git $ cd installLXDE $ ./installLXDE.sh
Once installed, you can follow the steps described earlier to switch over to LXDE. See the video for more explanation.
Configuration
As with most desktop environments, LXDE is highly configurable. You can set the desktop background, widget themes, font sizes and so on. See the video for some examples.
You can go back to GNOME of course. Go to the greeter screen, and select Unity/GNOME. GNOME is built with gdm3 in mind, but also seems to work with lightdm which saves some space. Use the dpkg-reconfigure command as shown above if you would like to switch back to gdm3.
Tech Talk
First, as a side note, the Raspberry Pi uses a modified version of LXDE for their desktop environment.
We’ve introduced a lot of different names in this article, such as GNOME, LXDE, lightdm, gdm3. The GUI that you see on the screen represents a stack of software which speaks to the hardware of the machine.
From the bottom up, the software stack looks like the following list. Rather than go through a full explanation, here are links to Wikipedia articles which describe each part to get you started if you have interest.
X Window System (aka X11): A network protocol encoding things such as graphic primitives, images, pointer motion, and key presses.
X Display Server (e.g. Xorg and XFree86): X server implementing X11 and providing an interface to keyboards, mice, and video cards.
X Display Manager (e.g. GDM, and LightDM): Graphical login manager which starts a session on an X server from the same or another computer
Window Managers (e.g. Mutter which is used by Gnome, OpenBox which is used by LXDE): Decorating X window primitives and supporting various operations such as moving, resizing, and maximizing of windows.
Desktop Environments (e.g. GNOME, KDE, XFCE, and LXDE): Providing libraries and specifications that applications use and follow in order to “play nice” with other applications.
Note that some Desktop Environments have shells around them (e.g. Unity for GNOME). Also, some of these programs combine different components of this architecture.
A compositor, such as Compton, usually works with a display manager to composite windows from the Window Manager. In more integrated solutions, this may be a little more hidden.
You may also hear the term “Wayland” which is a X Windows replacement. “Weston” is an reference implementation of Wayland. In this case, Wayland represents the bottom of the stack and works its way up from there. Many of the display managers, window managers and desktop environments have built in Wayland support.
Notes
The demo shown in the video is on a Jetson Nano (4GB). Other Jetsons can also benefit from the steps described above, but we did not test them here.
The summary of the desktop environment stack is taken from:
This is a surprisingly difficult subject to summarize, especially considering that X Windows originated in 1984. In part, this is because of the overlap and popularization some of these terms.
