Unboxing and Setting Up the NVIDIA Jetson Nano

I pre-ordered the NVIDIA Jetson Nano and had the opportunity to have my first experiences with it this week. For those that are considering the Nano I give you the gift of my hindsight so that you can have a smoother experience when you get started. My experience wasn’t bad by any measure. But there were some accessories that I would have ordered at the same time as the Jetson so that I would have everything that I needed at the start. I’ve also made a YouTube video covering this same information. You can view it here.

How does the Nano Compare to Other Jetson Devices?

The Jetson line of devices from NVIDIA can be compared across several dimensions. But where the Jetson Nano stands out is the price. It is priced at about 100 USD making it affordable to hobbiest. Compare this to the Jetson TK1 which is available for about 500 USD or the Jetson Xaviar available for about 1,200 USD. Another dimension of interest is the number of CUDA cores that the units have. CUDA cores are hardware units used for parallel execution.

  • TK1 – 192 CUDA Cores
  • TK2 – 256 CUDA cores
  • Nano – 128 CUDA Cores
  • Xavier – 512 CUDA Cores

In addition to the cores the other Jetson kits have support for other interfaces, such as SATA for adding hard drives or a CAN bus for interfacing with automotive systems. For someone getting started with experimentation the Jetson Nano is a good start.

What is In the Box?

Not much. You’ll find the unit, a small paper with the URL of the getting started page, and a cardboard cutout used for supporting the card on the case.

What Else Do I Need

  • SD Card
  • Power Supply
  • Keyboard
  • Mouse
  • Monitor (HDMI or Display Port)
  • 40mmx40mm Cooling Fan (optional)
  • WebCam (optional)
  • WiFi adapter or Ethernet cable to router

Most of the things on that list you might already have. For an SD card get one at least 8 gigs or larger.

Power Supply

A power supply! It uses a 5 volt power supply like what is used in a phone. Well, kind of. Don’t expect for any of your 5V power supplies to work. I found the hard way that many power supplies don’t deliver the amount of current that is needed. Even if the power supply is capable a USB cable might not allow the needed amount of current to pass. If this happens the device will just cut off. There’s no warning, no error message, nothing. It just cuts off. I only came to realize what was going on after I used a USB power meter on the device. I used a power meter for USB-A, but the board already has contacts for using a USB-C port. Depending on when you get your board it may have a USB-C port on it (possibly, speculatively).

Web Cam

A Raspberry Pi camera will work. But I used a Microsoft LifeCam. There are a number of off-the-shelf webcams that work. You’ll only need a camera if you plan on performing visual processing. If your going to be processing something non-visual or if your visual data is coming from a stream (file, network location) then of course this won’t be necessary.

WiFi

You have two options for WiFi. One option is a USB WiFi dongle. There are a number of them that are compatible with Linux that will also work here. I am using  the Edimax EW-7811UN. After being connected to one of the USB ports it just works. Another solution is to install a WiFi card into the M.2 adapter. It might not be apparent at first, but there is a M.2 slot on the case. I chose to use this solution. Like the USB solution there’s not much to be done here; inserting the WiFi adapter into the slot, securing it is most of the work. Note that you’ll also need to connect antennas to the wireless card.

Operating System Image

The instructions for writing a new operating system image are almost identical to that of a Raspberry Pi. The difference is the URL from which the OS image is downloaded. Otherwise you download an image, write it to an SD card, and insert it into the Nano. Everything else will be done on first boot. You’ll want to have a keyboard connected to the device so that you can respond to prompts. When everything is done you’ll have an ARMs build of Ubuntu installed.

For writing the OS image I used balenaEtcher. It is available for OS X and Linux. The usage is simple; select an OS image, select a target drive/memory device, and then let it start writing to the card.  The process takes a few minutes. But once it is done put the SD card in the Jetson Nano’s memory card slot.

Case Options

A case may be one of the last things that you need. But if you seriously have interest in having the Jetson Nano I suggest ordering the case at the start. There are no off-the-shelf cases available for purchase for the Nano. But there are a few 3D printable plans for the Jetson Nano. I’ve come across three and have settled on one.

First Place: Nano Mesh

NanoMesh case Image
NanoMesh 3D Printable Case

The case is a bit thick, but it isn’t lacking for ventilation. The case height accommodates a fan. While the design doesn’t include any holes for mounting antennas for WiFi drilling them is easy enough.

Second Place: Nano Box

NanoBox
Nanobox Case for nVidia Jetson Nano

The NanoBox will envelope the Jetson leaving the heat sink almost flush with the case. I’d suggest this one if you plan don’t plan to use a fan on the Jetson.  If you ever change your mind and decide that you want to have a fan it can be added. But it will be on the outside of the case.

Third Place: Nano-Pac

Nano-Pac 3D printable case
Nano-Pac case

There’s not much to say about this case. It fully envelopes the Jetson Nano. But I’ve got questions about the cooling effectiveness of this case.

It’s Assembled and Boots Up. Now What?

Once the Jetson is up and running the next thing to do is to setup a development environment. There is a lot of overlap between targeting the Jetson series and targeting a PC that has an NVIDIA GPU. What I write on this will be applicable to either except for when I state otherwise.

 

Advertisements

Current Bright Sign Models

There are 4 main units in the BrightSign product line (there are a few others available for hardware integrators, but I’m ignoring these for now and am only looking that the units in their own cases).

LS Line

The LS line of the bright sign players is compact. It is idea when working with a single HD stream at up to 60 frames per second. It also offers a single USB port for connecting to other peripherals.

Models

slide

HD Line

The HD line can decode a single 4K video stream. With the HD line of players a GPIO port is also added to allowing additional hardware to be connected to the player for other forms of interaction.

Models

slide

XD Line

These units are set apart from the HD line in being capable of decoding up to 2 4K video streams and have an improved HTML rendering capabilities.

Models

slide

XT Line

These are the most capable Brightsign units, able to decode two 4K video streams at once. Some of the units in this family also feature an HDMI in allowing them to mix in video from another source with content. These units have 2 USB ports (USB-A and USB-C). They can also be powered via PoE.

Models

 

slide

 

 

 

 

TIP: Creating a New CUDA Project with Visual Studio 2019

If you’ve installed Visual Studio 2019 and are trying to work with CUDA there are a couple of problems that you’ll encounter. The first is going to be an error that you receiving when trying to opan any CUDA project about missing properties. This is from the CUDA installer placing some of the files in the wrong place. It places the files based on what was in Visual Studio 2019 Preview. It was only recently that the full release of 2019 was made available (and for the full release theses files need to go into a different place). To work around that see this post for where to move the missing files to.

Once that is resolved the next problem is that the CUDA project templates are missing. An NVidia representative in the NVidia developer forums acknowledged the problem and says a fix will come in an upcoming release. Until then the current solution is to grab an existing CUDA project and rename it. If you need an existing CUDA project you can find them in the folder for the NVidia CUDA samples or download one from here:

https://devtalk.nvidia.com/cmd/default/download-comment-attachment/78613/

 

 

Tip: Installing CUDA SDK on Visual Studio 2019

If you try to install the nVidia CUDA SDK and plan to use Visual Studio 2019 there’s an additional manual step that you’ll need to take. The installer available for the current version of CUDA (10.1) doesn’t specifically target the recently released Visual Studio 2019, but it will mostly work with it. I say “mostly” because after installing it you’ll find that the CUDA related project templates are missing and you can’t open the sample projects.

Fixing this is as simple as copying a few files.  Copying everything from the following folder

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\extras\visual_studio_integration\MSBuildExtensions

Place it into this folder

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v160\BuildCustomizations

You may have to reply to administrative prompts. But once those files are copied you should have access to the project templates and the samples.

BrightSign HTML: Where is the Persistent Storage?

BrightSign Media Players work with a number of content management systems.  With a content management system, you can upload a BrightSign presentation as an asset and it will be distributed to the the units out in the field automatically.

Recently, I was investigating what the options are for other persistent storage.  The assets to be managed were not a full presentation, but were a few files that were going to be consumed by a presentation. As expected, the solution needed to be tolerant to a connection being dropped at any moment.  If an updated asset were to be partially downloaded, the expected behavior would be that the BrightSign continues with the last set of good assets that it had until a complete new set could be completely downloaded.

The first thing that I looked into was whether the BrightSign units supported service workers.  If they did, this would be a good area to place an implementation that would check for new content and initiate a download.  I also wanted to know what storage options were supported.  I considered indexedDB, localStorage, and caches.  The most direct way of checking for support was to make an HTML project that would check if the relevant objects were available on the window object.  I placed a few fields on an HTML page and wrote a few lines of JavaScript code to place the results in the HTML page.

Here’s the code and the results.

function main() {
    $('#supportsServiceWorker').text((navigator.serviceWorker)?'supported':'not supported');
    $('#supportsIndexDB').text((window.indexedDB)?'supported':'not supported');
    $('#supportsLocalStorage').text((window.localStorage)?'supported':'not supported');
    $('#supportsCache').text((window.caches)?'supported':'not supported');
    supportsCache
}
$(document).ready(main);
Feature Support
serviceWorker supported
indexedDB supported
localStorage supported
cache supported

Things looked good, at first.  Then, I checked the network request.  While inspection of the objects suggests that the service worker functionality is supported, the call to register a service worker script did not result in the script downloading and executing.  There was no attempt made to access it at all.  This means that service worker functionality is not available.  Bummer.

Usually, I’ve used the cache object from a service worker script.  The use of it there was invisible to the other code that was running in the application.  But with the unavailability of the service worker the code for the presentation will show more awareness of the object.  Not quite what I would like, but I know know that is one of the restrictions in which I must operate.

The Caches object is usually used by a service worker.  But the object can be used by the window, while it is defined as a part of the service worker spec, there’s no requirement that it be only used by it.

The next thing worth trying was to manually cache something and see if it could be retrieved.

if(!window.caches)
return;
window.caches.open(‘cache1’)
.then(function (returnedCache) {
cache = returnedCache;
});

This doesn’t actually do anything with the cache yet.  I just wanted to make sure I could retrieve a cache object.  I ran this locally and it ran just fine.  I tried again, running it on the BrightSign player, and got an unexpected result, window.caches is non-null, and I can call window.caches.open and get a callback.  The problem is that the callback always receives a null object.  It appears that the cache object isn’t actually supported.  It is possible that I made a mistake.  To check on this, I posted a message in the BrightSign forum and moved on to trying the next storage option, localStorage.

The localStorage option didn’t give me the results that I expected on the BrightSign. For the test I made a function that would keep what I hoped to be a persistent count of how many times it ran.

function localStorageTest() { 
    if(!window.localStorage) {
        console.log('local storage is not supported' );
        return;
    }
    var result = localStorage.getItem('bootCount0') || 0;
    console.log('old local storage value is ', result);
    result = Number.parseInt( result) + 1;
    localStorage.setItem('bootCount0', result);
    result = localStorage.getItem('bootCount0', null)
    console.log('new local storage value is ', result);
}

When I first ran this, things ran as expected.  My updated counts were saving to localStorage.  So I tried rebooting.  Instead of saving, the count reset to zero.  On the BrightSign, localStorage had a behavior exactly like sessionStorage.

Based on these results, it appears that persistent storage isn’t available using the HTML APIS.  That doesn’t mean that it is impossible to save content to persistent storage.  The solution to this problem involves NodeJS.  I’ll share more information about how Node works on BrightSign in my next post.  It’s different than how one would usually use it.

-30-

Brightsign: An Interesting HTML Client

Of the many HTML capable clients that I’ve worked with, among them is an interesting family of devices called BrightSign Media Players (made by Roku). One of the things that they do exceptionally well is playing videos.  They support a variety of codecs for that job and it’s easy to have them go from one video to another in response to a network signal, a switch being pressed, or a touch on the screen. I’m using the XT1143 and XT1144 models for my test.

For simple video-only projects, the free tool BrightAuthor works well.  But the scenarios that this is best fit for seem to be scenarios with relatively low amounts of navigation complexity.  For projects with higher amounts of navigational complexity or projects that require more complex logic in general, an HTML based project may be a better choice.

After working on a number of HTML projects for BrightSign, I’ve discovered some of the boundaries of what can and can’t be done to have a different shape than on some other platforms.  I have seen that there are some things that while taxing to other devices, work well on the BrightSign players; and other things that don’t work so well on BrightSign that will work fine on other players.

The BrightSign HTML rendering engine in devices with recent firmware is based on Chromium.

BrightSign Firmware Version Rendering Engine
4.7-5.1 Webkit
6.0-6.1 Chromium 37
6.2-7.1 Chromium 45
8.0 (not released yet) Chromium 65

You can encounter some quirky rendering behaviour if you are on a device with an older firmware version.  At the time that I’m writing this the 8.0 firmware isn’t actually available (coming soon). I’ve found that while the device can render SVG, if I try to animate SVG objects, then performance can suffer greatly.  It is also only possible to have no more than two media items playing at a time (audio or video).  If an attempt is made to play more than two items, then the third item will be queued and will not begin to play until the previous two complete playing.

Rather than spend a lot of time developing and testing something in Chrome before deploying it to a BrightSign, it is better if you start off testing your code on the BrightSign as soon as possible.  The normal deployment process for code that is to run from the BrightSign is to copy a set of files to an HTML card, insert it into the BrightSign, reboot it, and wait a minute or two for the device to start up and render your content.

Compared to something being tested locally ,where you can just hit a refresh button to see how it renders, this process is way too long.  A better alternative, if your development machine and BrightSign are on the same network and sub-net is to make a BrightSign presentation that contains an HTML widget that points back to your development machine.  You’ll need to have a web server up and running on your machine and use the URL for the page of interest in the BrightSign presentation.  You will also want to make sure that you have enabled HTML debugging.  This is necessary for quick refreshes of the page.

When the BrightSign boots up, if everything is properly configured you should see your webpage show up.  You’ve got access to all of the BrightSign specific objects even though the page is being  served from another page.  You can inspect the elements of the page or debug the JavaScript by opening a Chrome browser on your development machine and browsing to the IP address of the BrightSign, port 2999.  Note that only one browser tab instance can be debugging the code running on the BrightSign.

The interface that you see here is identical to what you would see in the Chrome Developer Console when debugging locally.  If you make a change to the HTML, refreshing the page is simply a matter of pressing [CTRL]+[R] from the development window.  This will invoke a refresh on the BrightSign too.

I’ll be working on a BrightSign project over the course of the next few weeks and will be documenting some of the other good-to-know things and things that do or don’t work well on the devices.

-30-