We use GPIO to talk to external devices on the NVIDIA Jetson Nano. Looky here:

Introduction

One of the nice things about the Jetson Nano is that there is an expansion header which is useful for General Purpose Input Output (GPIO). You may have thought about turning a light on or off as the output of your program, or would like a read a press from an external button. That’s where GPIO is useful!

In this article, we’ll cover how to control GPIO output by turning a Light Emitting Diode (LED) on and off. This is probably one of the most basic examples on how to use GPIO.

As you may have heard, the GPIO pin layout on the Jetson Nano is compatible with the 40 pin layout of a Raspberry Pi (RPi). Also, there is a Jetson GPIO python library which is mostly compatible with RPi.GPIO. Jetson.GPIO is preinstalled in the standard Jetson Nano disk image.

With that said, note that the electrical characteristics of the GPIO expansion header on the Jetson Nano are not the same as a Raspberry Pi. In particular, the Jetson Nano flows much less current on the GPIO pins than the RPi.

For example, a RPi can drive a LED directly from the GPIO pins, whereas a Jetson leaves the LED dimly lit because there is not enough current. The Jetson needs a little help. As you will see, a switching transistor comes to the rescue!

There are a couple of ways to use this article. The first way is to work your way through everything, and use your pearl catcher to grab the wisdom being thrown about. If you’re more pragmatic, jump around to the bits and pieces you find useful. Be forewarned that there be maths here, we’re using electricity, and things could go horribly wrong if you’re not careful. Other than that, play and have some fun.

LED Circuit

Parts List

Here are the parts we are going to use in this circuit:

• A 5mm red LED
• A P2N2222 Transistor
• 1 330Ω resistor
• 1 10kΩ resistor
• Hookup wire
• A breadboard to connect everything together

The easiest way to acquire the parts is to get a collection, such as this “Electronic Fun Kit“. There are many of these types of kits available for experimenting with Raspberry Pi and Arduinos. You may also want to acquire some extra resistors or such. Sparkfun and Adafruit are good sources.

It is also useful to have a multimeter on hand. I use a pretty hard core one, but if you’re just starting out you can get a less expensive one instead.

LEDs

If you want a little more in depth introduction to LEDs, checkout “A detailed introduction on how to use LEDs” This should give you a good feel for what we are doing here.

Here’s the thing about LEDs. They don’t use power linearly. Like little pigs they’ll suck so much current up that they will destroy themselves in a puff of magic smoke if left to their own devices. But we can make sure that does not happen.

By adding a resistor (in this application it is called a current limiting resistor), we will limit the amount of current that the LED is able draw. We select the resistor based on Ohm’s Law.

Oh My! Maths …

One of the fundamental rules in electronics is Ohm’s law. You have probably heard about it. Specifically:

Ohm’s law states that the current through a conductor between two points is directly proportional to the voltage across the two points. Introducing the constant of proportionality, the resistance,^[1] one arrives at the usual mathematical equation that describes this relationship:^[2]

where I is the current through the conductor in units of amperes, V is the voltage measured across the conductor in units of volts, and R is the resistance of the conductor in units of ohms. The main point to remember is that current, voltage and resistance are all related.

And what does that mean to us? In short, we can set the limit on the amount of current that the LED can actually draw by cleverly selecting a proper resistor. This is because a resistor’s current value responds directly proportional to the applied voltage. All we need to know is a couple of things about the LED to calculate the proper resistor value.

First, LEDs have what is called a Forward Voltage, which is basically the minimum voltage difference between the cathode and anode (different terms for this is the minus and plus sides) that you need to supply to an LED. Another thing that we need for our calculation is the Forward Current which is the maximum amount of current that the LED is able to handle continously.

In the LED data sheets, you will see Forward Voltage as $V_F$ and Forward Current as $I_F$.

The LED in this example has a Forward Current of 20mA and a Forward Voltage of 2.0V. We will be using the Jetson Nano 5V pin to drive the LED, so we subtract the Forward Voltage from the 5V and divide by 20mA (0.020A), just like Ohm’s Law tell us to:

We get a result of 150Ω This is the value to flow the maximum amount of current that is safe for this particular LED. A couple of things to note here. First, resistors don’t tend to come in a 150Ω flavor. Even if they did, they have some tolerance built in, which indicates they can have some variance from the actual stated resistance. This is usually a small percentage, but smaller inexpensive resistors may be around 20%! This means that the resistor can be in a range of 120-180Ω for one rated at 150Ω. Because we live in a modern age, we can use an online calculator to help us for this calculation.

Second:

Tyrell:
The light that burns twice as bright burns half as long – and you have burned so very, very brightly, Roy.

Blade Runner, 1982

Maybe not quite as drastically as the movie quote, but running an LED at maximum current will effect its lifespan. Typically people end up using between 220 and 470Ω resistors for this application. We will be using a generic 330Ω.

About that Transistor

That takes care of protecting our little LED friend. But as we were talking about, because a Jetson Nano GPIO pin is not strong enough to power the LED by itself it needs a little help. We will use a Transistor which will act as a switch to provide current to the LED.

Transistors amplify power. We will be using a Bipolar Junction Transistor (BJT). BJTs are available in two flavors, PNP and NPN. We will be using a NPN transistor, which is what the majority of low power switching circuits use. If you want a deeper background see: A practical guide to transistors and their use. A BJT is made up of three pieces of silicon. A NPN transistor has a piece of P-Type silicon (the Base) sandwiched between two pieces of N-Type silicon (the Collector and the Emitter).

Fun Fact: If you don’t know what P-Type and N-Type mean, here’s a quick explanation. A silicon crystal by itself is an insulator. Adding a minute amount of impurities turn the silicon from a good insulator to a viable (but not great) conductor (hence the name semiconductor). A process called Doping introduces impurities into the pure silicon crystal in order to modify the conductivity. Typically Boron (P-Doping) and Phosphorus (N-Doping) are used. Combining P-Type and N-Type silicon allows electricity to flow.

We are making the most fundamental transistor switch circuit. A normal switch would require a mechanical device to physically flip the circuit. Our switch here will be controlled by the current sent from the Jetson GPIO pin to the transistor. The control signal from the Jetson flows into the Base of the transistor, the Emitter connects to ground, and the output is tied to the Collector.

The Circuit

Here’s a schematic of the circuit we will be using:

• L1 is our 5V LED
• R1 is the current limiting resistor for the LED
• Q1 is the transistor we’ve been talking about, a P2N2222
• R2 is the Base Resistor which tells how much current to let flow in the circuit.
• For this circuit, use a NPN BJT transistor

Calculating the Transistor Bit

There’s one more bit of mystery. When the Jetson GPIO is low (0V), the transistor is in cutoff mode. It looks like an open circuit between the Collector and the Emitter.

However, there is amount of current applied to the Base at which point the transistor starts to “saturate”. This then acts like a short circuit between the Collector and the Emitter. At that point, current flows and our LED lights up, all nice and happy.

In our example the Base current is determined by a Base Resistor which sits between the Jetson GPIO pin and the base of the transistor. The Base Resistor performs much the same function as the current limiting resistor on the LED. Note that the saturation of the transistor is determined by current, not voltage in a BJT.

There’s a little more math involved to figure out what value the Base Resistor should be.

This reads as the current on the Base of the transistor is equal to the desired current at the Collector divided by the gain of the transistor. You remember that transistors are amplifiers, and have an associated gain. The term h_FE in the transistor data sheet is the gain number. For this particular transistor, it is equal to 100. If we provide 0.00020A to the Base of the transistor, we should get 20mA at the Collector.

There’s one more little trick. We need to use Ohm’s Law one more time. We know that the GPIO of the Jetson is 3.3V. We divide that by the 0.00020A to get the Resistance, right? Nope. It turns out that there is a 0.7V drop between the Base and the Emitter that we need to take into account. This drop is attributable to the N-P junction of the Base to the Emitter in the transistor. So:

In this circuit, the 13000Ω value of the Base resistor is the maximum resistance that you can have to get 20mA at the Collector.

You will notice that in our circuit we threw in a 10kΩ resistor instead of the 13kΩ. This is for a couple of reasons. First, we know that the LED won’t draw more than 20mA because of the limiting resistor from earlier. Second, 13kΩ is not a common resistor value, so we need to substitute. If you want to be safe, you would tend to go up a size rather than down. But we live wild! And we have a fire extinguisher.

There are also transistor calculators online if you need to check your maths.

Wiring

We’re now ready to wire everything up and give it a spin. Both LEDs and Transistors flow current in only one direction, and have a + and – side. For the LED, + is the anode, – is the cathode. On a 5mm LED, the + side usually has a longer leg, and usually the – side has a flat spot on the rim of the bulb.

For the Transistor, the Collector goes to the + side, and the Emitter goes to the – side. The arrangement of the pins depends on the particular part chosen.

Given the schematic above, here’s a wiring diagram:

You will need to examine your transistor. The Collector, Base, and Emitter are different depending on which part number you have. We’re using a P2N2222 here. We will be wiring the red wire to +5V on Pin 2 on the Jetson, the black wire to GND on pin 6, and the transistor Base through the base resistor on Pin 12. Pin 12 is selected for the demo examples below.

Software

Once everything is wired up, we’re ready to run some software to blink our light.

We can control our LED from the command line. Here are some useful commands:

In the above code, the 79 refers to a translation of the Linux sysfs GPIO named gpio79. If we look at the Jetson Nano J41 Header Pinout, we can see that gpio79 is physically pin 12 of the header.

Note: Except for the power, ground, I2C and UART pins, the header pins are GPIO in the Jetson default configuration. Any extra names in the Header Pinout refer to preferred usage if the user makes changes to the device tree and reassigns the pins.

In order to be able to access the GPIO pins, you need to have the proper permissions. This can be accomplished in a couple of ways. First, you can run your commands from a super user terminal. Open the Terminal and execute:

$ sudo su

You are then able to execute the commands with the correct permissions. Also, the permissions can be assigned to a group which you are a member. This is typically done by:

Install custom udev rules by copying the 99-gpio.rules file into the rules.d directory:

Please note that for the new rule to take place, you may either need to reboot or reload the udev rules by issuing this command:

This sequence is from the Jetson-GPIO Python library documentation, which is installed in the default Jetson Nano image at: /opt/nvidia/jetson-gpio/doc/README.txt.

Jetson.GPIO Python Library

There is an official Jetson.GPIO library for Python. The Jetson.GPIO library aims to be compatible with RPi.GPIO. We can run the sample for simple output to control our LED:

The run_samples.sh script sets up the paths to the Jetson.GPIO library and calls simple_out.py to flash the LED that is connected to pin 12 on the GPIO header.

This is just touching the Jetson.GPIO library, it is much richer than just this. We’ll examine more functions in subsequent articles.

Conclusion

While it seems like a lot to know to turn LEDs on and off, we now have the foundation to control external devices over the Jetson GPIO Header. In our next installment of the GPIO series, we’ll take a look at input through the GPIO header. Stay tuned!

Notes

P2N2222 Transistor Datasheet

The post Jetson Nano GPIO appeared first on JetsonHacks.

NVIDIA has released JetPack 4.2.1 and L4T R32.2. Here’s the JetPack release page.

Here’s the announcement from the NVIDIA forums:

NVIDIA is excited to have released JetPack 4.2.1 and L4T R32.2, the latest production release including new features and improvements for Jetson Nano, Jetson TX1/TX2, and Jetson AGX Xavier! See the Key Features for a list of highlights, including:

• Headless initial system configuration via the flashing USB port or UART
• NVIDIA Indicator Applet for nvpmodel performance power mode switching
• The Jetson Zoo repository of popular open-source packages and DNN models
• Improved memory available and boot-up power for Nano
• Support for Ubuntu 18.04 aarch64 for Jetson TX1
• Support for DeepStream 4.0 and ISAAC 2019.2
• New beta features:
  
  • Xavier DLA support for INT8 in TensorRT
  • NVIDIA Container Runtime with Docker Integration

The NVIDIA SDK Manager can be used to install JetPack 4.2, including developer tools with support for cross-compilation.

For more information, please refer to the JetPack Release Notes and L4T Release Notes.

JetPack 4.2.1 components:

• L4T R32.2 (K4.9)
• Ubuntu 18.04 LTS aarch64
• CUDA 10.0.326
• cuDNN 7.5.0.66
• TensorRT 5.1.6.1
• VisionWorks 1.6
• OpenCV 3.3.1
• Nsight Systems 2019.4
• Nsight Graphics 2019.2
• SDK Manager 0.9.13

Download JetPack…https://developer.nvidia.com/embedded/jetpack
Release Notes……….https://docs.nvidia.com/jetson/jetpack/release-notes/index.html
L4T Release Notes…https://developer.nvidia.com/embedded/dlc/Tegra_Linux_Driver_Package_Release_Notes_R32.2.0_GA.pdf

Go check it out!

The post JetPack 4.2.1 Release appeared first on JetsonHacks.

A simple way to control Servo Motors on the NVIDIA Jetson Nano Developer Kit is to connect the Jetson Nano via I2C to a PWM Driver. Looks here:

Background

There are four types of serial communication ports on the Jetson Nano. The most obvious is USB, which is where you plug in the mouse and keyboard. The other three are hidden away in the headers on the board.

We’ve talked about Universal Asynchronous Receiver-Transmitter (UARTs) before (one of which is the serial console). The Jetson Nano has two, one on the J44 Serial Port header, and one on the J41 Expansion Header.

There are also provisions for Serial Peripheral Interface (SPI) ports. In the default Nano Image configuration, the Jetson Nano does not have SPI port access. However, the device tree can be reconfigured for accessing SPI through the J41 Expansion Header. In the Jetson Nano J41 Pinout, NVIDIA recommends placement for two SPI ports.

Note: You may also hear the J41 Expansion Header referred to as the GPIO Header. The two terms are interchangeable.

The remaining serial ports are Inter-integrated Circuit (I2C). The Inter-integrated Circuit (I²C) Protocol goes by various names depending on who you talk to, “I squared C”, “I two C” or “I I C”. I2C is intended for short distance communication within a single device. One of the reasons that it is popular with the maker crowd is that it only requires two wires (the “data” and the “clock”) along with power and ground to get functioning.

In order to control Servo Motors, we use Pulse Width Modulation (PWM). The Jetson Nano has the capability of generating two PWM pulses on the J41 Header. However, you need to reconfigure the device tree to make these signals available on Pins 32 and 33. A simpler way is to use an external piece of hardware.

For our demo, we use a PCA9685 12-bit PWM/Servo Driver. Using only two pins, we can control 16 free-running PWM outputs. You can even chain up 62 breakouts to control up to 992 PWM outputs! The PCA9685 breakout board is a nice little application specific micro controller for servo control.

Parts

In the video, we use several different pieces of hardware. Here’s a partial list:

• Jetson Nano
• PCA9685 Breakout Board (Adafruit)
  • Alternate assembled (Sunfounder)
• SG90 Micro Servo
• Alternate inexpensive Adafruit Mini Pan and Tilt with Servos
• As shown in the video, the Robot Geek Pan and Tilt Kit w/ Servos is available from Trossen Robotics
• Breadboard
• Hookup wire

For the demo, we also use a WiFi card and game controller. Here’s an article about how to install those.

Software Install

Here we will be using the Adafruit ServoKit Library. This is a Python library built on top of the Jetson.GPIO library. There are several I2C libraries available. For example, if you are using C, C++ or Python you can use libi2c for low level access to I2C.

On the JetsonHacksNano account on Github, there is a ServoKit repository. Clone the repository, switch to that repositories directory and install the adafruit-circuitpython-servokit library:

$ git clone https://github.com/JetsonHacksNano/ServoKit
$ cd ServoKit
$ ./installServoKit.sh

This installs the ServoKit library and also sets up the I2C and GPIO permissions so that we can run programs from user space. GPIO permissions are added to support the underlying Jetson.GPIO library.

Note: The group changes do not take effect until login. You must logoff/login or reboot the computer for the changes to take effect.

Demo 1

In the default Jetson Nano Image, there are two I2C ports available on the J41 Header. From the Jetson Nano J41 Pinout :

• I2C Bus 1 SDA is on Pin 3
• I2C Bus 1 SCL is on Pin 5
• I2C Bus 0 SDA is on Pin 27
• I2C Bus 0 SCL is on Pin 28

Note: Before wiring the Jetson, make sure that the power is disconnected. When the power is plugged in, the power and ground rails on the headers are always live, even if the processor itself is off.

For the first demo in the video, we wire Bus 1:

• J41 Pin 3 (SDA) -> PCA9685 SDA
• J41 Pin 5 (SCL) -> PCA9685 SCL
• J41 Pin 1 (3.3V) -> PCA9685 VCC
• J41 Pin 6 (GND) -> PCA9685 GND

A 5V 4A power supply is connected to the PCA 9685. The SG90 micro server is connected to port 0 of the PWM outputs. Note that the GND signal is towards the outside edge of the board, the control signal is towards the center of the board.

After wiring the board, plug the Jetson in. Once the Nano is up and running, open a terminal and execute:

$ i2cdetect -y -r 1

The default address of the PCA9685 is 0x40 (this is hexadecimal 40). You should see an entry of ’40’ in the addresses listed. If you do not see the entry, then the wiring is probably incorrect. When the address does not show up, then you will not be able to use the device. Note: You can change the default address of the PCA9685, so you will need to take that into account when you check the device visibility.

We are now ready to run our first demo:

$ python3
>>> from adafruit_servokit import ServoKit
>>> kit = ServoKit(channels=16)
>>> kit.servo[0].angle=137
>>> kit.servo[0].angle=25
>>> quit()

Our servo should move to the appropriate angle when we command it.

Demo 2

Demo 2 is a little more involved. After powering down and unplugging the Nano, we wire up the PCA9685 and add the pan and tilt servo connections:

• J41 Pin 27 (SDA) -> PCA9685 SDA
• J41 Pin 28 (SCL) -> PCA9685 SCL
• J41 Pin 1 (3.3V) -> PCA9685 VCC
• J41 Pin 6 (GND) -> PCA9685 GND

Here’s the full wiring diagram:

J41 Pins 27 and 28 on the Jetson Nano conenct to I2C bus 0. Check to make sure that we can see 0x40 on IC2 Bus 0:

$ i2cdetect -y -r 0

Make sure that the game controller is paired to the Jetson Nano as described in the Jetson Nano Wifi Article (also shown in the video). You can run jstest-gtk to make sure everything is happy.

Then you are ready to run the demo:

$ python3 servoPlay.sh

After initialization (this takes a few seconds), you should be able to control the pan and tilt servos with the game controller. The left joystick in the X direction controls the bottom servo. The right joystick in the Y directions controls the top servo.

You should look through the servoPlay.sh script for insight on how all of this fits together. Also, we demonstrate the ServoKit ‘throttle’ command, which is useful for controlling continuous servos and the similar electronic speed controllers for motors.

Conclusion

This article is more complicated than the actual code and wiring itself. Get ahold of the parts, wire them up, and go play!

Notes

The Jetson Nano is running L4T 32.1 with no modifications.

The post Jetson Nano – Using I2C appeared first on JetsonHacks.

With the release of JetPack 4.2.1, L4T 32.2 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.

Note that each of these repositories have associated releases to match the repository with the L4T version. You can find releases under the ‘releases’ tab on the Github repository. For example, a typical naming convention is vL4T32.2

In no particular order, here’s the repositories with updates.

buildKernelAndModules

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. Use scripts/config to modify the .config file. Because you should be familiar with the Linux kernel make procedures, this is for advanced users only.

rootOnUSB

The scripts in this repository will setup a NVIDIA Jetson Nano Developer Kit to set the rootfs to a USB drive.  See this article: Jetson Nano – Run on USB Drive.

installLibrealsense

Build and install Intel’s librealsense for the NVIDIA Jetson Nano Developer Kit. This repository can rebuild the Linux if need be to support the Intel RealSense D400x series cameras. Now builds librealsense v2.24.0 and adds support for Python 3.

installRealSenseROS

Install the realsense-ros library on NVIDIA Jetson Nano Developer Kit. Installs RealSense ROS Version = 2.2.7, which expects a librealsense v2.24.0 installation.

Enjoy!

The post JetsonHacksNano Github Updates appeared first on JetsonHacks.

The post Protected: Install VESC 6 Plus on RACECAR/J appeared first on JetsonHacks.

Many people would like to set up their Jetson Nano without the need of attaching the Jetson to a monitor and keyboard (headless setup). With the advent of JetPack 4.2.1, this is now possible! Looky here:

Background

In earlier versions of JetPack, there was a requirement that the Jetson be connected to a monitor and keyboard (this is called ‘headed’ mode) to initially configure the Jetson the first time it boots. With the release of JetPack 4.2.1 it is possible to attach the Jetson through its default debugging port to a host computer’s tty device and enter this information through a serial application running on the host. In this case, the Jetson does not need a monitor or keyboard (this is called ‘headless’ mode).

The first time a Jetson Nano boots, a script allows the user to set their username and password, language, time zone, and so on. If the Jetson is attached to a monitor and keyboard, the user inputs the configuration from the Jetson keyboard.

In earlier versions of JetPack, this was the only way to configure the Jetson. With the advent of JetPack 4.2.1, it is now possible to do this configuration directly from a host computer without the need for the monitor and keyboard on the Jetson.

Many robotics and IoT applications do not need a desktop environment, and therefore have a different setup requirement from a desktop configuration. After all, why dig up an extra monitor and keyboard just to do a one time configuration for the Jetson? Also, because there is no desktop requirement, there is no need to have the extra support software for that environment on board. Running a minimal environment helps save space, and can lead to more efficient operation.

Note: You will see reference in most of the documentation to a host device and a target device. The Jetson is the target device, the host device is a PC desktop/laptop. On the Jetson Nano, if you simply create a SD Card Image from a NVIDIA supplied disk image, you can create the SD card and configure the Jetson from a machine running Windows, Linux or Macintosh. If you create your SD card through the SDK Manager, you will need an Ubuntu machine.

Tell me how

There is a script subsystem tool that runs on the Jetson the first time it boots, named oem-config (The link opens up the complete documentation on the NVIDIA website). If the Jetson has a display and keyboard, oem-config runs as the familiar GUI application on the Jetson and walks the user through the configuration process.

However, if there is no monitor and keyboard on the Jetson (headless mode), oem-config can configure the system through the default debugging port. On the Jetson Nano, the easiest way to access the debugging port is through the micro-USB connector. You will connect the micro-USB connector to the Jetson, and the other end of the USB cable will go to the host PC. Typically this is a USB Type A connector.

Note: Make sure that the cable is data capable. Some USB cables (such as those that come with phones) only transmit power.

You will need to supply power the Jetson through the barrel jack (don’t forget the jumper on J48!).

Setup

You will need a serial terminal application. In the video we use the app screen on the Ubuntu machine, an puTTY on the Windows machine example. screen also works on the Macintosh from the Terminal. You can install screen on Ubuntu:

$ sudo apt-get install screen

There are multiple network interfaces on the Jetson Nano, including ones which you may add yourself such as those for wifi access. Since this process is very well documented in the actual NVIDIA documentation and shown in the walk through video above, we won’t cover it in too much detail here. However, you will need to have your network connection up and running before oem-config starts setup, i.e. have your Ethernet cable plugged in and attached to the network, or wireless card installed and WiFi network accessible, etc.

You will also need to know the device/name of the Jetson when you plug it into the USB port of your host. On Linux and Macintosh, the Jetson will show up in the /dev directory. On Linux, the Jetson presents itself as a ttyACM* device (for example /dev/ttyACM0) and on a Mac a tty.usbmodem* device (something similar to /dev/tty.usbmodem148303). On Windows the Jetson is a COM* device.

On Linux and Mac you can simply ls the /dev directory, on Windows probably the easiest way is to use the Device Manager. You will need to show ‘hidden devices’ in the View menu, as ports are normally not shown.

It’s easiest to take inventory before you power the Jetson up, and then see what shows up after you power up the Jetson. Remember that it takes the Jetson ~ 45 seconds to boot, so you should be a little patient.

The Jetson interface is 115200 baud, so when using your serial terminal app you typically would enter something like:

$ screen /dev/ttyACM0 115200

where the address matches your configuration. Under Windows using puTTY, you enter the COM port number, and set the speed (see video).

You may need to hit the Esc key a couple of times when the serial app starts. Remember that it does take a while for the Jetson to boot, waiting a little while before starting setup is your friend. One of the setup issues that I have encountered is that if you try to exit/restart the configuration process, it may not be recoverable. In that case, you may need to flash the SD card and start again.

Most of the questions are simple, the only variation comes when you get to the Network Configuration screen. It is relatively straightforward. Once the Jetson is configured, it reboots. At this point you can ssh into the Jetson.

There is a small chicken and egg problem. You may not know the IP address of the Jetson. You can use the same USB cable and serial app to log in to the Jetson at this point and look up the address using something like ifconfig.

Once you know the IP address of the Jetson, you can then SSH into it. The command is:

$ ssh <account name>@<ipaddress>

An example:

$ ssh jetsonhacks@10.0.1.21

You should now be connected to the Jetson.

List o’ Stuff

Here’s a list of the bits and pieces used in the video:

• Jetson Nano: https://amzn.to/2E15tkW
• Samsung 64GB MicroSD Card: https://amzn.to/2UJEaRW
• DC Power Supply: https://amzn.to/2k0eiEV
• Alternate DC Power Supply: https://amzn.to/2HeNYiG
• Intel 8265NGW Wifi card: https://amzn.to/2WLGKrU
• A bunch of different colored jumpers: https://amzn.to/2X23dBc

These are all affiliate links. JetsonHacks gets a small commission on these items (but they don’t cost you anything more). These are all items that I have bought and used myself.

Conclusion

This is a little less nuts and bolts than most of the articles here on JetsonHacks. That’s mostly due to the fact that there are many paths your network configuration can take, as well as different machines that you can use as your host.

For most questions, you will be referred back to the official NVIDIA Jetson Nano Forum, so that a larger group of developers and NVIDIA engineers can lend their experience.

The post Jetson Nano – Headless Setup appeared first on JetsonHacks.

If you run you Jetson Nano under heavy workloads, you may find it useful to add a fan. Looky here:

Background

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.

If you are wondering about thermal benchmarks for the Jetson Nano and such, there is an excellent article over at Phoronix.com with comprehensive thermal testing: The Thermal Performance Of NVIDIA’s Jetson Nano $99 Developer Board

Money quote from the conclusion:

After hours of different benchmarks stressing both the Kepler GPU and Cortex-A57 cores, the fan-less out-of-the-box configuration led to around 58 degrees average with a peak of 69 degrees. When having the PWM fan attached, the average temperature under load was 42 degrees with a peak of 51 degrees. With the temperatures not hitting any extremes, there weren’t any workloads in our temperature-controlled environment where thermal throttling was taking place for the Jetson Nano or the performance otherwise changing, which is good.

Let’s note here that the article is from March, so there may have been some tweaks since then to the Nano system software for better thermal performance.

The tests over at Phoronix were conducted in a temperature controlled environment. If your application is such that it is exposed to more temperature extremes (like outdoors, or in a warm environment such as under direct sunlight), you may find that the Jetson reaches its thermal limits.

A couple of comments here. First, some people confuse thermal throttling with other symptoms. For example, if you are using a Jetson with a micro USB power supply you may see “stutters” or pausing. More than likely this is because the Nano is up against the amount of power it can draw from the power supply (2.5A), and is trying to adjust power consumption. You can address this by using a 4A power supply through the Nano barrel jack.

Another example is that you may experience issues with the micro SD card, where the SD card is exhibiting poor performance, failures or long access/write times. This can be due to a variety of factors of the SD card, such as poor quality, bad sectors, and so on.

Second, some people measure the temperature by touching the heatsink. They feel that if the heatsink is uncomfortable to the touch, then it needs a fan, or there are thermal issues. This is a simplistic view. There are sensors on the Tegra module (under the heat sink and thermal plate) which measure the actual temperature of the Tegra chip itself. That’s how it figures out when to do thermal throttling. The actual thermal limits for the chips are generally quite a bit higher than what would actually be comfortable for most people to actually touch.

With that said, there are certainly reasons one may need a fan. And there’s a lot to be said about just adding the fan and not have to think about it anymore.

Installation

In the video, we install a Noctua A4x20 5V PWM fan. This fan recommended by NVIDIA. The fan attaches to the Jetson Nano’s heatsink via 4 mounting points. There are 4 holes drilled into the heatsink at the factory. However, the holes do not have threads which means that we need to think about how to use them. Fortunately, Noctua gives us some mounting options and instructions.

The heatsink holes are a little bigger than 2.5mm. You can use self-tapping M3 screws or regular M2 or M2.5 25mm machine screws with nuts for attachment. The nuts are pretty small, people use tweezers to hold them. The screw and nut method can be a little frustrating if you’re not use to handling very small parts.

The easiest way to attach the fan is to use self-tapping M3 screws, 25mm long. The heatsink is soft metal, you should be able to use your screwdriver to drive the screws in fairly easily.

In the video, we show a little more complicated approach. We use a M3x0.5mm tap to place threads in the hole, and then attach the fan with M3 screws around 23mm long. A machine screw 22-25mm should work. This method is useful if you intend to detach and attach the fan multiple times.

The Noctua fan has a 4 pin connector to attach to the Jetson. The connector is keyed to help with installation. The 4 pins are:

• GND
• 5V
• Tachometer
• PWM

The fan gets power from the Jetson from the GND and 5V pins. The Tachometer signal tells the Jetson what the speed of the fan currently is, and the PWM signal allows the Jetson to control the fan speed.

Test

Under normal use, the Jetson will only spin the fan when the thermal demand is high enough to warrant its use. Some people think their fan is broken after installation because the fan does not spin when the power is applied to the Jetson. As we have discussed, there is actually quite a bit going on behind the scenes trying to manage the thermal load and balancing that against power consumption. The Jetson Nano is an embedded system, and usually biases towards a system that should use less energy when possible.

However, if we run the following scipt:

$ sudo jetson_clocks

this will spin the fan, as well as set the CPU and GPU clocks to their maximum value in the current performance profile. Install the fan, then test it with jetson_clocks. The jetson_clocks script does not persist across boots, so in order to return to normal thermal management reboot the Jetson.

Alternatives

Of course, there are many fan alternatives in this form factor. You will need a 5V fan. One thing to note is that some of the fans have 3 pin connectors. If you use a 3 pin version, the Jetson will not control the fan dynamically (there are no signals to enable that feature). The fan will spin at full speed when the Jetson Nano is powered.

The post Jetson Nano – Add a Fan! appeared first on JetsonHacks.

Here’s a fast way to set up your Jetson Nano to run from a USB drive. Looky here:

Background

For external storage, the Jetson Nano uses a Micro SD Card. The SD card holds the operating system, applications and any data in use. In the overall scheme of things, this device provides relatively slow access. Also, even though Micro SD cards are much better now than they have been in the past, the cards have a reputation of low reliability in long term or heavy use.

Most desktop/laptop computers use a different type of external storage, such as a Hard Disk Drive (HDD) or Solid Sstate Disk (SSD). Typically these are built into the computer, though you can add an external one also.

In fact, we can add one of those types of drives to the Jetson Nano through the USB 3.0 port! We will cover setting up our USB drive so that it can be the “root file system” or rootfs for the Nano. The end result is that the system will be much snappier in response because the disk access is much faster.

Typically most larger computers boot directly to the disk drive. However, this is not possible using the current configuration of the boot loader on the Jetson Nano.

Remember that the term ‘boot’ is shorthand for the slang term ‘bootstrapping’, that is, pulling ones self up by their own boot straps. The Jetson uses a two step boot process. The basic idea is that the boot loader loads a memory image with minimal support for key attached peripherals, and then loads over itself with the Linux kernel specified. It’s really clever and quite tricky.

By default, the bootloader loads the Linux kernel from the SD card and then configures the rootfs to point to files on the SD card. Here we will load the Linux kernel from the SD card, but we will Pivot the Root to point the rootfs to files on the USB drive.

Why is this difficult?

During the boot process, the Jetson bootloaders use an initrd (initial ramdisk) to load a temporary file system into memory to load the Linux kernel. The initrd is a minimal file system, with just enough for loading the kernel. What we would like to do is load the kernel, and then switch over to the USB drive.

Here’s the problem. While the actual USB drivers are built in to the Linux kernel, the firmware for the USB devices themselves are not. By the time the root file system gets mounted in the boot process, the USB controller is not yet initialized. You can’t talk to the USB drive, so the system falls back to the SD card as the rootfs. The system then loads the USB firmware to make the USB drive available.

In a previous article, we recompiled the Linux kernel to include the USB firmware to circumvent this issue. That is a fairly lengthy process that takes ~45 minutes. However, one of our readers (a special thanks to George!) pointed out a much easier way in a post they wrote on the Jetson Nano Developer Forum!

The idea is to include the USB firmware in the initrd so that the USB drive is available early on in the boot cycle. It takes less than a minute to build a new initrd with the change, and we’re off and running.

Note: In the video, we refer to the initramfs. As in most things technical, the initrd and initramfs are not strictly equivalent, but for the purposes of this discussion we treat them the same.

Install

You should do this on a freshly flashed Micro SD card. You can use a 16GB card for this process. In the video, we use a Samsung T5 500 GB USB SSD. On the JetsonHacksNano account on Github, there is a repository named rootOnUSB. Clone the repository, and then switch to the repositories directory:

$ git clone https://github.com/JetsonHacksNano/rootOnUSB

$ cd rootOnUSB

This is a 4 step process.

Step 1

Build the initramfs with USB support, so that USB is available early in the boot process. A convenience script named addUSBToInitramfs.sh provides this functionality.

$ ./addUSBToInitramfs.sh

Step 2

Prepare a USB drive (preferably USB 3.0, SSD, HDD, or SATA->USB) by formatting the disk as ext4 with a partition. In the video, we use the ‘Disks’ application. It is easier if you only plug in one USB drive during this procedure. When finished, the disk should show as /dev/sda1 or similar. Note: Make sure that the partition is ext4, as NTSF will appear to copy correctly but cause issues later on. Typically it is easiest to set the volume label for later use during this process.

Step 3

Copy the application area of the micro SD card to the USB drive. copyRootToUSB.sh copies the contents of the entire system micro SD card to the USB drive. Naturally, the USB drive storage should be larger than the micro SD card. Note: Make sure that the USB drive is mounted before running the script. In order to copyRootToUSB:

usage: ./copyRootToUSB.sh [OPTIONS]

  -d | --directory     Directory path to parent of kernel

  -v | --volume_label  Label of Volume to lookup

  -p | --path          Device Path to USB drive (e.g. /dev/sda1)

  -h | --help  This message

In the video, we:

$ ./copyRootToUSB.sh -p /dev/sda1

Remember to mount the USB drive before attempting to copy.

Step 4

Modify the /boot/extlinux/extlinux.conf file. An entry should be added to point to the new rootfs (typically this is /dev/sda1). There is a sample configuration file: sample-extlinux.conf

You should make a backup of the original extlinux.conf file. Also, when you edit the file you should make a backup of the original configuration and relabel the backup. This will allow you to access an alternate boot method from the serial console in case something goes sideways.

Then you should changed the INITRD line to:

INITRD /boot/initrd-xusb.img

So that the system uses the initramfs that we built that includes the USB firmware. Then set the root to the USB drive.

Here are some examples. You can set the drive by the UUID of the disk drive, the volume label of the drive, or the device path:

APPEND ${cbootargs} root=UUID=0e437280-bea0-42a2-967f-a240dd3075eb rootwait rootfstype=ext4
APPEND ${cbootargs} root=LABEL=JetsonNanoSSD500 rootwait rootfstype=ext4
APPEND ${cbootargs} root=/dev/sda1 rootwait rootfstype=ext4

The first entry is most specific, the last most generic. Note that you are not guaranteed that a USB device is enumerated in a certain order and will always have the same device path. That is, if you leave another USB drive plugged in along with your root disk when you boot the Jetson, the root disk may have a different path than originally, such as /dev/sdb1.

Also, there is a convenience file: diskUUID.sh which will determine the UUID of a given device. This is useful for example to determine the UUID of the USB drive. Note: If the UUID returned is not similar in length to the above example, then it is likely that the device is not formatted as ext4.

$ ./diskUUID.sh

While this defaults to sda1 (/dev/sda1), you can also determine other drive UUIDs. The /dev/ is assumed, use the -d flag. For example:

$ ./diskUUID.sh -d sdb1

You may find this information useful for setting up the extlinux.conf file

Benchmarks

If you use the Micro SD card, you typically get average read rates ~ 87 MB/s and access times of ~ 0.52 msec. With a SSD, you get average read rates of ~367 MB/s and access times of 0.29 msec. About a 4X speedup! A HDD drive performs about the same as the Micro SSD, but tends to be much more reliable over time.

Special Thanks

Thank you George for pointing this out!

Notes

• Even though the Jetson Nano has 4 USB 3.0 connectors, they all go through one USB hub. Therefore, you end up sharing the USB bandwidth with all the other USB peripherals. Bandwidth can fill up quick!
• Mostly recently tested on Jetson Nano, L4T 32.2.1 [JetPack 4.2.2]
• In the video, tested on Jetson Nano, L4T 32.2.1 [JetPack 4.2.2]

The post Jetson Nano – Run From USB Drive appeared first on JetsonHacks.

The Jetson Developer Kits are currently running a custom version of Ubuntu 18.04. If you are making the switch from another computer OS to the Jetson, here’s three tips. Looky here:

Background

The current versions of the Jetson Developer Kits (Jetson Nano, Jetson TX2 and Jetson AGX Xavier) are running L4T 32.2.x. L4T is a custom version of Ubuntu 18.04 with built in support for the Jetson Tegra processors.

L4T uses the Unity desktop. While the Ubuntu desktop is similar to other computer OSes like Windows and Macintosh, there are some differences.

Tips

Tip 1: Arrange your Launcher

The bar on the left of the desktop is called the Launcher. Once you start an installed program (which you can do from the Dash as shown in the video), an icon appears in the Launcher. Similar to Windows and MacOS, you can lock the icon to the Launcher, and arrange them.

This seems simple (because it is!), but saves valuable time because you don’t have to hunt around for your frequently used programs/apps. You will also want to get rid of the application icons that you do not use frequently to get rid of visual clutter, and make selection faster.

Tip 2: Open the Terminal using a context menu

When you are developing, sometimes you are looking at files through the GUI file browser. If you are unfamiliar with Linux, sometimes it can be difficult to translate the location of the file in the browser to the actual location in the file system.

There are a couple of tricks to know. Typically when people talk about directories (like most programmers) they are coming from a place of dealing with the file tree from a Command Line Interface (CLI). Users who come from the GUI world tend to talk about folders, which they see in the file browser windows.

As you probably know, directories and folders refer to the same thing! In fact a file browser is just a graphical representation on the file system. However, it’s not clear as to how navigate between the CLI version, and the file browser version.

As it turns out, there is a context menu (right mouse click in a file browser window), with an entry ‘Open in Terminal’. This will open a Terminal with the current working directory set to the place shown in the file browser. As shown in the video, you can see that the two addresses can be quite different, even though they represent the same place.

Also, you can drag and drop the location of a folder from the file browser to the Terminal. This makes it easier to navigate to a folder from a visual representation. You can also type in a file location into the “address” bar of the file browser (where the breadcrumb of the file location is shown) to navigate to an absolute path.

Not shown in the video is the ability to copy an address from the Terminal and navigate to it in the file browser. Use the pwd command to bring up the current working directory, copy and paste it in the file browser, and there you are.

Tip 3: Templates

Templating is a very useful feature. The idea is that you place a “template” of a file in a special folder (~/Templates). Then from a right click menu in a file browser window or desktop, you can select ‘New Document’ and the template you want to use.

Your templates can be of a file type, or a file that has a lot of information already in place. This is really useful for shell script files and Python scripts, where you may want to have headers with special prefaces, licenses, copyrights and so on.

Ubuntu will instantiate a new file based on the selected template. That way, you can create new files with all the boilerplate already in place for your projects!

The post 3 Ubuntu Tips for NVIDIA Jetson appeared first on JetsonHacks.

Visual Studio Code is a very popular Integrated Development Environment (IDE) which you can run on the NVIDIA Jetson Nano. Looky here:

Background

One of the first questions most people ask when they start using a new platform is “How should I write programs, and what development environments are available?”. Most people have experience with a few development environments, but have their standard gotos with which they are most familiar.

The Jetson Developer Kits support a wide variety of development environments. Most IDEs which run on a Linux platform either work or can be ported to the Jetson. One of the most popular IDEs is Visual Studio Code by Microsoft. Visual Studio Code is often referred to as VSCode. Fortunately, Microsoft offers an open source version of this mainstay of professional developers.

While you can install VSCode from source, there are community builds available for the Jetson. Here we install a build from headmelted.com. Make sure to go over there and give them some love. They have a version which runs on ARM 64 machines such as the Jetson Nano and Raspberry Pi. This saves a lot of work in gathering up the all the necessary libraries and building VSCode from source. Plus, the headmelted.com builds are automated, which means that they will update on an ongoing basis.

Visual Studio Code supports many different programming languages. In the video we add Python support. This is one of the more frequently asked questions here, “Which IDE should we use for Python on the Jetson?”. Try this one, and see how you like it.

Installation

On the JetsonHacksNano account on Github, there is a repository installVSCode. To clone the repository and install VSCode:

$ git clone https://github.com/JetsonHacksNano/installVSCode.git
$ cd installVSCode
$ ./installVSCode.sh

After installation, to run VSCode:

$ code-oss

Because VSCode is a GUI, it’s easiest to watch the video to get a feel on how to add different support features. In the video, we add Python support.

Because installation is from pre-built code, it only takes a few minutes.

Commentary

Right up front, this is a very simple install. Visual Studio Code is a very rich, professional level environment which supports a wide range of activities. It is beyond the scope of a short article or video on how to exploit much of this power.

However, we’ll note here that you may want to add Python environments, or remote developing capabilities. There are other articles out there that cover topics like doing “Remote development from a Windows host to a Jetson Nano using VSCode”. That particular article is well worth reading to get a better understanding of some of the niggles that you will have to overcome for such an endeavor.

Notes

In the video, we use a NVIDIA Jetson Nano Developer Kit and Raspberry Pi camera to clean up the JetsonHacksNano CSI-Camera repository.

The Incidentals

• Jetson Nano
• L4T 32.2.1 (JetPack 4.2.2)
• Visual Studio Code Code-OSS Version: 1.32.0 (user setup)
• Commit: aeaef41d51201e555735f5e8d2f38a9d0ddb9026
• Date: 2019-02-20T06:32:49.577Z

The post Jetson Nano – Visual Studio Code + Python appeared first on JetsonHacks.

You don’t need another computer to program your Arduino. You can do it from your Jetson! Looky here:

Background

Having a true microcontroller in addition to a Jetson Dev Kit can be very powerful combination. Microcontrollers are great at many low level, real time tasks that can be difficult for a SBC like a Jetson or Raspberry Pi due to the differences in architecture.

In the microcontroller world, the Arduino is what Makers turn to when the need strikes. The Arduino is the number one ecosystem in the world for interfacing with sensors and different devices. And while the Arduino is available in many configurations with different levels of sophistication, at heart they are microcontrollers. Which means that higher level, more sophisticated computing devices prove useful when more compute intense tasks arise. Tasks like machine learning and vision processing, for example.

That’s why the Jetson and the Arduino make a good pair. If your application requires a lot of I/O with the real world, a lot of compute power, and low energy consumption, the duo are hard to beat!

While the Arduino IDE in the Ubuntu ARM repository does not currently support the Jetsons, it’s easy to install pre-built versions from the Arduino website. As usual, the source for the IDE is available on Github. Thanks to Stephen Warren (a NVIDIA engineer), the Arduino supports the Jetson Dev Kits starting with version 1.8.9. The current release is 1.8.10.

Installation

While you can install the using the directions on the Arduino website, the JetsonHacksNano account on Github has a repository installArduinoIDE. The repository includes an install script.

$ git clone https://github.com/JetsonHacksNano/installArduinoIDE

$ cd installArduinoIDE

$ ./installArduinoIDE.sh

After a couple of minutes, the installer script will ask you to reboot the Jetson. There is a desktop shortcut to launch the Arduino IDE (you can also lauch it from the Ubuntu Dash). After selecting your board and port from the tools menu, you’re ready to go!

Conclusion

It’s nice to have the option of programming the Arduino from your Jetson. It makes things much simpler if everything is wired together and you don’t have to rewire everything to upload a different script to your Arduino.

Notes

• In the video, a Jetson Nano is shown
• L4T 32.2.1/JetPack 4.2.2
• Arduino SDK/IDE 1.8.10

The post Install Arduino IDE on Jetson Dev Kit appeared first on JetsonHacks.

There is a UART on the J41 GPIO Header of the NVIDIA Jetson Nano Developer Kit. Useful when you need a little bit of extra serial connectivity action. Looky here:

Background

There are two UARTs on the Jetson Nano. We have an article about the Serial Debug Console which is on the J44 header. The Serial Debug Console is useful for many tasks, including helping with start-up issues.

The second UART, which we are writing about here, is on the J41 header. This is what you consider a general purpose UART, with no special assigned function. However, there is an assumption about its use which may confuse folks who aren’t in the know.

When the Jetson starts up it opens a Serial Console on the J41 UART as a service. You can observe the console by simply wiring the Nano to another computer, either through another UART or a TTL to USB cable. Then open up a serial communications program and power on the Jetson. You will see the familiar login prompt from the Jetson.

This may not be the behavior you desire. For example, if you are interfacing with a micro-controller such as an Arduino or another device, you may want to just pass data back and forth. The Serial Console is in the way, and can lead to some strange data. The answer is simple, you need to stop the Serial Console on the UART.

Installation

The J41 UART is a 3.3V TTL signal. An easy way to communicate with the UART from another computer is via a TTL to USB Serial Cable. In the video, we use an Adafruit USB to TTL Serial Cable – Debug / Console Cable [954] available from Amazon. Most computers have a USB port, just plug the cable into the USB port.

If you are using the UART as a Serial Console, you’re almost done. You just need to run a serial terminal program on the machine that you are connecting to the Jetson. In the video, we use PuTTY on a Windows 10 PC. We start PuTTY and select Serial with 115200 baud, 8 bits, no parity, 1 stop bit.

You can plug the UART into another TTL type of device by just wiring the two directly together, but note the 3.3V signal. Many serial devices, such as some Arduinos, use 5V. The Jetson Nano is not tolerant of 5V, and if you connect directly bad things can happen. If you are using a 5V device with the Jetson Nano, you will need to do some level shifting to get the levels to match.

Also, remember to “crossover” the connections. Transmit (TXD – Transmit Data) goes to Receive (RXD – Receive Data) from the Jetson to the other machine/device. Similarly, Receive (RXD) goes to Transmit (TXD).

Wiring

The wiring is straightforward. Make sure that the Nano is disconnected from any power source and wire:

Jetson Nano J41 Pin 8 (TXD) → Cable RXD (White Wire)
Jetson Nano J41 Pin 10 (RXD) → Cable TXD (Green Wire)
Jetson Nano J4 Pin 6 (GND) → Cable GND (Black Wire)

Note: The color of the wires on your cable may be different.

The pinout of the J41 Header is available on JetsonHacks. The Jetson Nano J41 pins are also silkscreened on the underside of the board. The UART is on /dev/ttyTHS1.  After wiring, it should looks something like this:

Software

On the JetsonHacksNano account on Github, there is a repository UARTDemo. From a Terminal, clone the repository:

$ git clone https://github.com/JetsonHacksNano/UARTDemo

$ cd UARTDemo

If you do not intend to use the Serial Console on the UART, you should disable the Serial Console:

$ systemctl stop nvgetty
$ systemctl disable nvgetty
$ udevadm trigger

# You may want to reboot instead

The Demo Script requires py-serial. To install py-serial:

$ sudo apt-get install python3-serial

Now you are ready to run the Demo Script. Make sure that you have a Serial Terminal running on the computer that you connect to the Jetson. Connection speed is 115200, with 8 bits, no parity, and 1 stop bit (115200 8N1). Then run the script on the Jetson:

$ sudo python3 uart_example.py

On the connected machine, you should see a short identification when you connect. When you type on the machine, you should see the characters echo back (as if you are typing the character directly). The machine sends a character to the Jetson, the script reads the character and sends it back (we call this an echo).

In the video, we read through the script to get a feel for how it operates.

Conclusion

This should be a start on how to use the UART. The applications that you write can be very simple, or complex depending on the capabilities of the device that you attach.

As a special note, there are no serial/cereal jokes in this article because we use the monthly allotment in the video.

Notes

Tested on:

• Jetson Nano
• L4T 32.2.1
• JetPack 4.2.2
• Adafruit USB to TTL Serial Cable – Debug / Console Cable [954]

The post Jetson Nano – UART appeared first on JetsonHacks.

For robotics application, many consider Robot Operating System (ROS) as the default go to solution. The version of ROS that runs on the NVIDIA Jetson Nano Developer Kit is ROS Melodic. Installing ROS on the Jetson Nano is simple. Looky here:

Background

ROS was originally developed at Stanford University as a platform to integrate methods drawn from all areas of artificial intelligence, including machine learning, vision, navigation, planning, reasoning, and speech/natural language processing.

From 2008 until 2013, development on ROS was performed primarily at the robotics research company Willow Garage who open sourced the code. During that time, researchers at over 20 different institutions collaborated with Willow Garage and contributed to the code base. In 2013, ROS stewardship transitioned to the Open Source Robotics Foundation.

From the ROS website:

The Robot Operating System (ROS) is a flexible framework for writing robot software. It is a collection of tools, libraries, and conventions that aim to simplify the task of creating complex and robust robot behavior across a wide variety of robotic platforms.

Why? Because creating truly robust, general-purpose robot software is hard. From the robot’s perspective, problems that seem trivial to humans often vary wildly between instances of tasks and environments. Dealing with these variations is so hard that no single individual, laboratory, or institution can hope to do it on their own.

Core Components

At the lowest level, ROS offers a message passing interface that provides inter-process communication. Like most message passing systems, ROS has a publish/subscribe mechanism along with request/response procedure calls. An important thing to remember about ROS, and one of the reason that it is so powerful, is that you can run the system on a heterogeneous group of computers. This allows you to distribute tasks across different systems easily.

For example, you may want to have the Jetson running as the main node, and controlling other processors as control subsystems. A concrete example is to have the Jetson doing a high level task like path planning, and instructing micro controllers to perform lower level tasks like controlling motors to drive the robot to a goal.

At a higher level, ROS provides facilities and tools for a Robot Description Language, diagnostics, pose estimation, localization, navigation and visualization.

You can read more about the Core Components here.

Installation

The installROS repository on the JetsonHacksNano account on Github contains convenience scripts to help us install ROS. The main script, installROS.sh, is a straightforward implementation of the install instructions taken from the ROS Wiki. The instructions install ROS Melodic on the Jetson Nano.

You can clone the repository on to the Jetson:

$ git clone https://github.com/JetsonHacksNano/installROS.git
$ cd installROS

installROS.sh

The install script installROS.sh will install the prerequisites and ROS packages you specify. Usage:

Usage: ./installROS.sh  [[-p package] | [-h]]
 -p | --package <packagename>  ROS package to install
                               Multiple Usage allowed
                               The first package should be a base package. One of the following:
                                 ros-melodic-ros-base
                                 ros-melodic-desktop
                                 ros-melodic-desktop-full
 

Default is ros-melodic-ros-base if do not specify any packages. Typically people will install ros-base if they are not running any desktop applications on the robot.

Example Usage:

$ ./installROS.sh -p ros-melodic-desktop -p ros-melodic-rgbd-launch

This script installs a baseline ROS environment. There are several tasks:

• Enable repositories universe, multiverse, and restricted
• Adds the ROS sources list
• Sets the needed keys
• Loads specified ROS packages (defaults to ros-melodic-base-ros if none specified)
• Initializes rosdep

You can edit this file to add the ROS packages for your application.

setupCatkinWorkspace.sh

setupCatkinWorkspace.sh builds a Catkin Workspace.

Usage:

$ ./setupCatkinWorkspace.sh [optionalWorkspaceName]

where optionalWorkspaceName is the name and path of the workspace to be used. The default workspace name is catkin_ws. If a path is not specified, the default path is the current home directory. This script also sets up some ROS environment variables.

The script sets placeholders for some ROS environment variables in the file ~/.bashrc

The script .bashrc is located in the home directory. The preceding period indicates that the file is “hidden”. The names of the ROS variables that the script adds are (they should be towards the bottom of the .bashrc file):

• ROS_MASTER_URI
• ROS_IP

The script sets ROS_MASTER_URI to the local host, and basically lists the network interfaces after the ROS_IP entry. You will need to configure these variables for your robots network configuration and how you desire your network topology.

Notes

• In the video, the Jetson Nano is freshly prepared with L4T 32.2.1 / JetPack 4.2.2
• In the video, the Jetson Nano is running from a micro-SD card.

The post Install ROS on Jetson Nano appeared first on JetsonHacks.

With the release of JetPack 4.2.2, L4T 32.2.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.

Note that each of these repositories have associated releases to match the repository with the L4T version. You can find releases under the ‘releases’ tab on the Github repository. For example, a typical naming convention is vL4T32.2.1

In no particular order, here’s the repositories with updates.

buildKernelAndModules

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.

rootOnUSB

The scripts in this repository will setup a NVIDIA Jetson Nano Developer Kit to set the rootfs to a USB drive.  See this article: Jetson Nano – Run from USB Drive.

installLibrealsense

Build and install Intel’s librealsense for the NVIDIA Jetson Nano Developer Kit. The librealsense project supports Intel RealSense cameras such as the T265 and D400x series cameras. The installLibrealsense repository can rebuild the Linux kernel and add the kernel modules if need be to support the Intel RealSense D400x series cameras. Now builds librealsense v2.25.0.

installRealSenseROS

Install the realsense-ros library on NVIDIA Jetson Nano Developer Kit. Installs RealSense ROS Version = 2.2.8, which expects a librealsense v2.25.0 installation.

Enjoy!

The post JetsonHacksNano Github Updates – October 2019 appeared first on JetsonHacks.

Many people use Intel RealSense cameras with robots. Here we install the realsense-ros wrapper on the NVIDIA Jetson Nano developer kit. Looky here:

Background

There are several members in the Intel RealSense camera family. This includes the Depth Cameras (D415, D435, D435i) and Tracking Camera (T265). There are also more recent introductions which are just becoming available.

The cameras all share the same Intel® RealSense SDK which is known as librealsense2. The SDK is open source and available on Github. We have articles for installing librealsense (D400x article and T265 article) here on the JetsonHacks site.

The size and weight of the cameras make them very good candidates for robotic applications. Computing hardware onboard the cameras provide depth and tracking information directly, which makes it a very attractive addition to a Jetson Nano. Plus the cameras have low power consumption. Because ROS is the most popular middleware application for robotics, here’s how you install realsense-ros on the Jetson Nano.

Install RealSense Wrapper for ROS

There are two prerequisites for installing realsense-ros on the Jetson Nano. The first is to install librealsense as linked above. The second prerequisite is a ROS installation. Checkout Install ROS on Jetson Nano for a how-to on installing ROS Melodic on the Nano.

With the two prerequisites out of the way, it’s time to install realsense-ros. There are convenience scripts to install the RealSense ROS Wrapper on the Github JetsonHacksNano account.

$ git clone https://github.com/JetsonHacksNano/installRealSenseROS
$ cd installRealSenseROS
$ ./installRealSenseROS <catkin workplace name>

Where catkin workplace name is the path to the catkin_workspace to place the RealSense ROS package. If no catkin workplace name is specified, the script defaults to ~/catkin_ws.

Note: Version are in the releases section. The master branch of the repository will usually match the most recent release release of L4T, but you may have to look through the releases for a suitable version. To checkout one of the releases, switch to the installRealSenseROS directory and then:

$ git checkout <version number>

e.g.

$ git checkout vL4T32.2.1

The ROS launch file for the camera(s) will be in the src directory of the Catkin workspace realsense-ros/realsense2_camera/launch There are a variety of launch files to choose from. For example:

$ roslaunch realsense2_camera rs_camera.launch

You will need to make sure that your Catkin workspace is correctly sourced, and roscore is running.

Notes

There are dependencies between the versions of librealsense and realsense-ros. The install scripts are also dependent on the version of L4T. Check the releases on the Github accounts to match.

In the video:

• Jetson Nano
• L4T 32.2.1 / JetPack 4.2.2
• librealsense 2.25.0
• realsense-ros 2.28.0

realsense-ros does not “officially” support ROS Melodic. However, we haven’t encountered any issues as of the time of this writing.

The post RealSense ROS Wrapper – Jetson Nano appeared first on JetsonHacks.

Xavier NX! Today NVIDIA announces the Jetson Xavier NX module.

Xavier NX Overview

The Jetson Xavier NX module is the newest member of the Jetson family of devices. The architecture is similar to the powerful Jetson AGX Xavier. The Xavier NX has a 6 core Carmel ARM CPU, and a 384 core Volta GPU. Also, the Xavier NX has dual NVIDIA Deep Learning Accelerator (NVDLA) engines.

The Xavier NX contains 8GB of 128 bit memory. There are two power modes, 10W and 15W, with up to 21 TOPS of AI performance. The edge connector for the module is a 260-pin SODIMM edge connector, 70x45mm. You may recognize this as the same connector as the Jetson Nano Developer Kit. The module is compatible with the Jetson Nano Developer Kit! It even runs at 5V.

Yes, but will this dog hunt?

Dustin Franklin wrote a very nice article on the Xavier NX, Introducing Jetson Xavier NX, the World’s Smallest AI Supercomputer. It’s well worth the read.

Not to steal all the thunder, but here’s a performance graph from the article:

As we can see, this slots performance as much higher than the Jetson TX2, and slightly less than the full Jetson AGX Xavier. Yes, this dog will hunt.

The packaging and power requirements means that this Jetson should be able to easily fit in the quickly growing Jetson Nano ecosystem. Why is this important? Because it means that if your project needs more computing horsepower, then there is a straightforward upgrade path to the Jetson NX.

The NVIDIA Jetson Xavier NX will be available in March, 2020 for $399 in quantity.

Here are some more NVIDIA links:

• Page: https://developer.nvidia.com/embedded/jetson-xavier-nx
• Docs: https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_xavier_nx
• Blog: https://devblogs.nvidia.com/jetson-xavier-nx-the-worlds-smallest-ai-supercomputer

Go check it out!

The post NVIDIA Jetson Xavier NX appeared first on JetsonHacks.

RACECAR/J is now using VESC 6 electronic speed controllers. Newer versions of the VESC now require the new VESC Tool to program them. Looky here:

Background

For RACECAR/J, we replace the stock TRAXXAS ESC with the VESC 6 Plus from Trampa Boards. This is the official VESC from the creator of the VESC project, Benjamin Vedder.

Note: Earlier versions of RACECAR/J use the FOCBOX, and older versions of the MIT RACECAR use 4.X hardware. Please see our earlier article on the subject for reference material.

Another note: In the RACECAR/J Kit, we program the VESC before shipping. This article is here in case you want to re-program or configure it.

The major reason for the change is to gain full control of the robot at low speeds. Another advantage of the VESC over the stock Traxxas ESC is that the motor speed does not change in relationship to battery charge. Another reason is that the VESC is open source, which allows the curious to explore the motor controller implementation. 

Note: VESC is now a registered trademark. There are several manufacturers who build VESC compatible hardware, but expect different names.

Architecturally, the VESC has a STM32 ARM Cortex processor. The STM32 runs ChibiOS, a real-time operating system. The default firmware flashed on the VESC 6 Plus is ‘Servo-in’, which allows a remote controller to set the motor speed. For the RACECAR/J application, the VESC servo port needs to be programmed as ‘Servo-out’, which allows commands to be sent to the robot steering servo.

Fortunately there is a compiled binary of the version of the VESC firmware that includes the Servo-out setting. We can flash the STM32 directly using a program called ‘VESC Tool’. 

Once the VESC Tools loads the servo-out firmware on to the VESC, we then load a configuration file which matches the VESC configuration to control a TRAXXAS Velineon 3500 motor. 

VESC Tool Installation

Pre-compiled binaries are available for Windows, Macintosh and PC based Linux machines. There is currently no version for the Jetson architecture.

You can download the application from the VESC Project (vesc-project.com). Download the application for your platform (in the video we are on an Ubuntu 16.04 PC laptop), and extract/install the application.

VESC Firmware

Because the VESC Tool is heavily reliant on the GUI, it is easiest to watch the video to understand how to upload the firmware to the VESC.

The first step is to connect the VESC to power, and then plug it in via a USB cable. The VESC must be powered on from the battery before you can program it.

Note: On some host computers (such as the Macintosh) the VESC may not be detected unless it is powered on before plugging it into the host. You can program the VESC when it is installed in the RACECAR, though you may need a longer USB cable.

Start the VESC Tool application.

Next, connect to the VESC by clicking the connect button in the right toolbar:

The VESC Tool will autodetect the VESC. Select Firmware from the left sidebar. You will see the hardware version. Check the ‘Show non-default firmwares‘.

You will see the firmware file VESC_servout.bin. Select the file and press the upload button.

The firmware will upload to the VESC. Once the firmware uploads, the VESC will reboot. You will see the lights flash while programming, and when the VESC reboots you will see red flashing lights. The lights will turn solid after the boot sequence finishes.

Configuring the VESC

Once the VESC is up and running, reconnect via the button as above.

There are several VESC configuration files in the RACECAR/J Github repository. Because we are using a VESC 6 Plus, we use the VESC-6-Plus-30k.xml configuration. Configurations for other VESCs are available in the folder also, such as the FOCBOX and bldc versions for 4.X hardware.

You can download the entire repository, or download one configuration file as shown in the video. Once you have the configuration file on your computer, select:

File->Load Motor Configuration XML

from the File menu. Specify the file which you downloaded. Now you are ready to upload (write) the configuration to the VESC. Press the Write Motor Configuration button on the right toolbar. It looks like this:

The configuration file will upload to the VESC. You are now ready to run your RACECAR/J!

Notes

Here’s an article on how to install your VESC 6 on the RACECAR/J platform.

Here’s an article on how to install the RACECAR/J Software on the Jetson TX2.

The post RACECAR/J – Programming the Electronic Speed Controller appeared first on JetsonHacks.

Running OpenCV on Jetson Dev Kits has more nuance than many people expect. Looky here:

Background

OpenCV is the most popular computer vision library in the world. There are many gems of algorithms and downright computer vision goodness in there.

At the same time, OpenCV is what we call in computer lingo a “rich” environment. That usually means that it is configurable in many different and sometimes baffling ways depending on your perspective.

Any particular build of OpenCV has many options. Obviously which processor the library is built for (such as ARM 64 for the Jetsons), but also which media libraries, video handling libraries, 3rd party libraries it incorporates and so on.

The default version of OpenCV that NVIDIA supplies with the Jetsons (L4T 32.2.1/L4T 4.2.2) is OpenCV 3.3.1.

Point 1 – What Version of OpenCV is available

The version of OpenCV is important for a couple of reasons. First the version tells you which features are available. Recently OpenCV 4.X has come on the scene, version OpenCV 3.X is the mature, stable branch.

The second reason the version is important is that on the Jetson, the default OpenCV version on the Jetson is different than the one in the Ubuntu repositories. Many applications will load the older version of OpenCV when they install via apt-get. This may overwrite the default version, or cause confusion during application loading.

One of the main differences between the version in the Ubuntu repository and the Jetson default version is GStreamer support. The Jetson default has it, the other doesn’t. That makes it more difficult to interface with the Jetson CSI camera.

You can find the OpenCV version with dpkg

$ dpkg -l | grep libopencv

Note that there may be multiple installations of OpenCV on the Jetson, so you may have to examine library paths, and search through /usr/lib and /usr/local/lib to find out what is really going on. Some people are really sneaky and place it other places too.

Point 2 – Python 3 and OpenCV

Does Python 3 work with the default OpenCV? The short answer is yes. However you will need to install numpy first.

$ sudo apt-get install python3-numpy

Of course, if you want to use pip3 instead to install numpy, that’s a fine route to take.

Point 3 – Does OpenCV has feature XYZ

You have OpenCV on your machine, but you don’t know what features it supports.

OpenCV itself has a function, getBuildInformation. This is easy to access from Python 2.7 (this is in the default Jetson Image). From a Terminal:

$ python

>>> import cv2

>>> print cv2.getBuildInformation()

This will list to the console a large amount of information, which tells how OpenCV is built, what modules are available, media and video support and so on.

Looking at the build information, we see that the default version of OpenCV on the Jetsons have GStreamer support, but no CUDA support.

Point 4 – Python and CUDA and OpenCV

From Point 3, you can find out if the version of the OpenCV library you are using has Python support. That’s straightforward. We can also tell if CUDA support is built it. That’s straightforward.

What is not straightforward is if there is Python support for CUDA in the OpenCV library. Again, there’s a short answer. If you build OpenCV with CUDA support, version 4.X can build Python wrappers for GPU functions. Version 3.X does not.

There may be ways around this, but it’s not simple.

Point 5 – Other Packages May Not Play Nice

As we discussed in Point 1, applications may load different versions of OpenCV, depending on how they were built. Typically they load a version from the Ubuntu repository when you install them from the Ubuntu repository.

If this happens, then you usually have a different feature set than the default one from the Jetson. This is probably the major point of confusion people report as they do not know that the default OpenCV has been overwritten.

Bonus

Just because you have OpenCV CUDA enabled, this does not automatically mean that you get better performance. There are many factors, here’s a few.

First, not all OpenCV functions have CUDA code available. Second, some algorithms do not benefit from parallel execution. Third, the processing pipeline may not be able to take advantage of parallel execution.

Also, the amount of time it takes to setup for CUDA execution (memory transfers and other setup), may take longer than the execution speed that you gain from the CUDA code.

One more thing, think of this as double bonus, this is from James Bowley:

The benefit you will get from moving your processing to the GPU with OpenCV will depend on the function you call and configuration that you use, in addition to your processing pipeline. That said from, what I have observed, on average the CUDA functions are much much quicker than their CPU counterparts.

Conclusion

I hope you are able to get something out of this little discussion. We get many questions about this topic, I think having this discussion available here will make life simpler.

The post 5 Things about OpenCV on Jetson appeared first on JetsonHacks.

Building OpenCV 4 with CUDA support on the NVIDIA Jetson Nano Developer Kit can be a bit of a chore. Here’s some help. Looky here:

Background

In an earlier article, 5 Things about OpenCV on Jetson, we discuss some of the reasons which you may want to build OpenCV from source. The reasons include:

• You need a specific version of OpenCV (the default on the Jetson is 3.3.1)
• You would like to use OpenCV version 4
• You would like to have CUDA acceleration
• You would like to have a different configuration than the default version, such as support for Qt, OpenGL, and so on.

In the video, we use:

• Jetson Nano
• A Samsung T5 USB drive
• A RPi V2 camera
• A 5V, 4A power supply

You can find these items on the JetsonHacks Amazon store. Buying through the link does not cost you anything additional, and sends a small commission to the channel. Thank you for your support!

Resources

There are already some good resources for building OpenCV on the Jetson. First, there is the “official” NVIDIA script in this Github repository: https://github.com/AastaNV/JEP As of this writing, the OpenCV script is in the scripts directory, the name of the script is install_opencv4.1.1_Jetson.sh

NVIDIA updates this script frequently to support newer versions of OpenCV and L4T. A good choice if you want something to work and do not want to spend the time specifying your configuration. In the video, we go over the script.

Michael de Gans is a frequent Jetson forum contributor. He knows what’s up! Michael has a Github repository with the name nano_build_opencv which contains a script to build OpenCV. The script has much more structure than the NVIDIA one, you will benefit reading through/using it.

Sergio Canu’s excellent article on building OpenCV 4.1 discusses how to increase the size of the system swap file when building OpenCV (assumes that you are running L4T 32.2.1/JetPack 4.2.2). This is worth doing, it should cut build time significantly.

Another great resource is JK Jung’s blog. The blog covers many aspects of using Jetsons in machine learning, certainly one of the best Jetson resources out there. There are articles on different Machine Learning frameworks, how to speed up your projects with TensorRT, ML optimizing and more.

By going through JK Jung’s blog post, you will begin to understand some of the decisions that you may need to make for any given environment. OpenCV is a very rich environment. In computer speak that usually means that it is so flexible that it takes a lot of knowledge to configure it for best performance for any given application.

Which leads us to the gist of this post. The JetsonHacks take on build OpenCV. In the broad sense, this is version updates previous work we have done on the other members of Jetson family.

Building OpenCV 4

The version of OpenCV 4 that we are building has the following features:

• CUDA support
• Gstreamer support
• Video for Linux support (V4L2)
• Qt support
• OpenCV version 4.1.1
• Python 2 and Python 3 support
• Build an OpenCV package with installer
• Build for Jetson Nano

In the video, we are using a Jetson Nano running L4T 32.2.1/JetPack 4.2.2. The Nano is running with the rootfs on a USB drive. This speeds up the build time considerably. As in Sergio Canu’s article, you can increase the size of the swap file to reduce memory thrashing:

sudo apt-get install zram-config

sudo edit /usr/bin/init-zram-swapping

Replace the line:
mem=$(((totalmem / 2 / ${NRDEVICES}) * 1024))

with this line:

mem=$(((totalmem / ${NRDEVICES}) * 1024))

And then reboot.

Note: The swap file in the video is only 2GB, and results in a lot of memory thrashing when building the Python wrappers.

Let’s build this puppy

As we discuss in the video, you will want to set the CMAKE flags to reflect the OpenCV configuration you want to build. We have a quick walk through in the video, but it is certainly worth exploring on your own. To build from a Terminal:

$ git clone https://github.com/JetsonHacksNano/buildOpenCV

$ cd buildOpenCV

$ ./buildOpenCV.sh |& tee openCV_build.log

The last command will build OpenCV, and send the results of the build to the file openCV_build.log. This is useful when you want to review your build configuration, or help hunt down issues that may occur during the build.

The resulting Package of OpenCV will end up in the opencv directory: ~/opencv/build/_CPACK_Packages/Linux/STGZ with a name similar to OpenCV-4.1.1-<commit>-aarch64.sh, where commit is the name of the Github version.

We can run a couple of demos to make sure things are working. Please see the Examples folder and follow the README instructions (as shown in the video). The demos expect that you have a RPi V2 camera, you may have to change some code for a USB camera.

Note about pkg-config

By default, OpenCV does not build a .pc file for use by pkg-config. In order to build the file, the correct Cmake option is:

OPENCV_GENERATE_PKGCONFIG=YES

When installation is complete, you will need to relocate the .pc file (assuming the script default install path here) /usr/local/lib/pkgconfig/ and edit the file paths in the .pc file appropriately. Make sure you run:

$ sudo ldconfig -v

afterwards so that pkg-config knows where to look.

Conclusion

That’s a lot of reading for three simple lines of code! However, when undertaking a project like this it make sense to understand why you are doing it, what your options are, and what benefit you expect to receive after completion.

Notes

In the video:

• Jetson Nano
• Build OpenCV 4.1.1
• L4T 32.2.1/JetPack 4.2.2

The post OpenCV 4 + CUDA on Jetson Nano appeared first on JetsonHacks.

Swap memory is now part of the default NVIDIA Jetson Nano distribution. Here’s how to change the amount of swap memory in use. Looky here:

Background

Recent releases of L4T/JetPack enable swap memory as part of the default distribution. You may remember an earlier article on JetsonHacks, Jetson Nano – Use More Memory! which describes how to implement a swap file on earlier versions of L4T which did not have this feature enabled.

The current JetPack distribution uses the zram module for managing the swap memory. You can read more in depth about zram on Wikipedia. Zram does some clever things in maximizing compression and performance when using ramdisk/swap disk. There’s a lot under the hood. More than we will cover here, but the reference material is out there if you want to read up on it.

In the default distribution, the swap memory size is 2GB. At times this may not be enough if you are doing very large projects. For example, building OpenCV from source. Let’s go over how you might expand/contract the swap memory.

Note that these techniques are most useful on external drives on the Jetson (USB SSD and hard drives).

Setting Up

The Jetson Nano by default has 2GB of swap memory. The swap memory allows for “extra memory” when there is memory pressure on main (physical) memory by swapping portions of memory to disk. Because the Jetson Nano has a relatively small amount of memory (4GB) this can be very useful, especially when, say, compiling large projects.

In the video, we use:

• Jetson Nano
• Samsung T5 USB Drive
• A 5V, 4A power supply

You can support the channel by shopping for these items on the JetsonHacks Amazon store front! The shop has these items available. There’s no charge to you, and the channel gets a small commission. Thanks!

In the video, we are using the USB drive as the root file system.

The swap memory method in use is Zram. You can examine the swap memory information:

$ zramctl

You will notice that there are four entries (one for each CPU of the Jetson Nano) /dev/zram0 – /dev/zram3. Each device has an allocated amount of swap memory associated with it, by default 494.6M, for a total of around 2GB. This is half the size of the main memory.

The configuration for the Zram allocation is done on startup. The file that controls this is /etc/systemd/nvzramconfig.sh

The size of the Zram for each CPU is calculated by the line:

mem=$(((“${totalmem}” / 2 / “${NRDEVICES}”) * 1024))

where totalmem is the total amount of memory, and NRDEVICES is the number of CPUs.

Basically it divides the amount of physical memory by the number of CPUS with a divisor, in this case 2 to get the 2GB total. You can simply edit this equation using a text editor. You should probably make a backup of the file first, just in case. You will need sudo permissions to change the file.

sudo gedit /etc/systemd/nvzramconfig.sh

For example, you may remove the divisor to get a full 4GB.

On the JetsonHacksNano account on Github, there is a repository named resizeSwapMemory. The repository contains a convenience script to set the size of the swap memory.

$ git clone https://github.com/JetsonHacksNano/resizeSwapMemory

$ cd resizeSwapMemory

To use the script in the repository:

usage: ./setSwapMemorySize [ [-g #gigabytes ] | [ -m #megabytes ] | [ -h ]
  -g #gigabytes – #gigabytes total to use for swap area
  -m #megabytes – #megabytes total to use for swap area
  -h – help 

Example usage:

$ ./setSwapMemorySize -g 4

will set the entire swap memory size to 4GB.

This will modify the /etc/systemd/nvzramconfig.sh to set the requested memory for the swap memory as specified.

You will need to reboot for the change to take effect.

Notes

You will need to have the amount of memory that you specify for the swap memory available on disk. The recommended swap memory size is 2GB for a 4GB Jetson Nano. Larger swap memory sizes can sometimes cause decreased performance. You may want to switch swap memory size for specific tasks (such as compiling a very large program) and then revert to the default size of 2GB afterwards.

Tested on Jetson Nano

• Jetson Nano
• L4T 32.2.1/JetPack 4.2.2
• L4T 32.2.3/JetPack 4.3

The post Jetson Nano – Even More Swap appeared first on JetsonHacks.