DEV Community

Md Shaifur Rahman
Md Shaifur Rahman

Posted on

Squeezing Every Megabyte: Optimizing an 8GB NVIDIA Jetson Orin Nano for Headless ROS 2 and Edge-AI

#robotics #nvidia #ros2 #linux

When building an autonomous robot, compute efficiency is everything. If you are running on an NVIDIA Jetson Orin Nano (8GB), you are dealing with Unified Memory (UMA)—meaning your CPU and GPU share the exact same physical RAM pool.

Out of the box, JetPack 7.2 running Ubuntu 24.04 LTS boots a full GNOME graphical desktop that devours 1.5 GB to 2.0 GB of RAM just idling. If you are loading an Edge-AI model (like Gemma 2B), running dual IMX219 CSI cameras, processing 2D LiDAR data, and running a ROS 2 navigation stack, that desktop environment is a luxury you cannot afford.

In this guide, we will walk through a complete, step-by-step engineering log to:

  1. Connect and configure a headless Jetson over a direct Ethernet/USB interface.
  2. Systematically strip down the OS to reclaim over 1 GB of precious RAM (bringing idle usage down to ~600 MiB).
  3. Install a native, lightweight ROS 2 Jazzy Jalisco environment.

Part 1: Headless Connection & Setup

When working on a mobile robot, you rarely want an HDMI monitor dangling off your vehicle. Connecting to your Jetson headlessly over a direct Ethernet link or the USB-C device port is the gold standard.

Local Hostname Resolution

Ubuntu uses the Avahi mDNS stack. Instead of searching for IP leases in your router's client list, you can connect directly using your Jetson's hostname:

ssh username@your-jetson-hostname.local
Enter fullscreen mode Exit fullscreen mode

Tip: If you are connecting via a direct Ethernet cable between your laptop and the Jetson, ensure your laptop's Ethernet interface is set to "Link-Local Only" or "Share to other computers" to auto-assign compatible IP addresses.

Part 2: Squeezing Memory for Headless Operations

Let's look at the actual optimization path. Our starting point on a fresh, graphical JetPack 7.2 installation was 913 MiB of active RAM usage (with no monitor attached, using SSH). We want to bring this down as low as possible.

Step 1: Deactivate the Graphical User Interface (GUI)

The single biggest RAM culprit is the graphical environment. Since our robot is autonomous and headless, we can safely instruct systemd to boot directly to a text-only target.

# Set the default system target to multi-user (headless)
sudo systemctl set-default multi-user.target

# Instantly terminate the active desktop manager session
sudo systemctl isolate multi-user.target
Enter fullscreen mode Exit fullscreen mode

Result: Idle memory drops instantly from **913 MiB* to 699 MiB, saving over 200 MiB.*

Step 2: Ruthlessly Pruning Background Services

Even in headless mode, standard desktop Ubuntu environments run helper programs, network daemons, and background profiling tools that are completely useless on an embedded robot.

Let's list running services:

systemctl list-units --type=service --state=running
Enter fullscreen mode Exit fullscreen mode

Based on this analysis, we can safely disable several heavy-hitting daemons.

The "Safe to Disable" List

  1. lttng-sessiond.service: A kernel tracing tool useful for core OS developers, but unnecessary for robotics applications.
  2. iperf3.service: A bandwidth benchmarking tool left running as an open port in the background.
  3. smbd.service & nmbd.service: Samba file sharing engines designed to host network folders for Windows/macOS network discovery.
  4. kerneloops.service: Collects and submits crash signatures back to Canonical.
  5. bluetooth.service: (Optional) Unless you are pairing a wireless gamepad directly to the Jetson to steer the car, disable this to free up resources.

Disable them all in one command:

sudo systemctl disable --now lttng-sessiond.service iperf3.service smbd.service nmbd.service kerneloops.service bluetooth.service
Enter fullscreen mode Exit fullscreen mode

What We MUST Keep Running

  • nvargus-daemon.service: Absolutely essential if you are running CSI cameras (like IMX219s) because it handles the direct hardware Image Signal Processor (ISP) routing.
  • nvfancontrol.service: Crucial for active cooling! It dynamically regulates fan speed based on thermal zones.
  • jtop.service: The daemon for jetson-stats—virtually zero footprint, but indispensable for system profiling.

Step 3: Adjust Swappiness and Drop Caches

Because the Jetson uses flash storage (like an NVMe SSD), aggressive swapping can wear down your drive and introduce latency. By default, Linux has a high "swappiness" value (60), meaning it starts swapping idle memory pages early.

We want to lower this value to 10, telling the kernel to swap only as an absolute last resort:

# Temporarily set swappiness to 10
sudo sysctl vm.swappiness=10

# Make it permanent
echo "vm.swappiness=10" | sudo tee -a /etc/etc/sysctl.conf
Enter fullscreen mode Exit fullscreen mode

Additionally, you can manually drop inactive system file caches to clear up immediate memory blocks right before loading high-impact AI pipelines:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
Enter fullscreen mode Exit fullscreen mode

Part 3: Native ROS 2 Jazzy Installation

With our OS footprint optimized, we now have a perfect foundation for ROS 2 Jazzy Jalisco (the Tier-1 supported LTS release for Ubuntu 24.04).

Since we are running a headless robot, we will opt for the ros-base package installation. This avoids bringing back any desktop GUI tools (like RViz or rqt) which would pull in hundreds of megabytes of heavy X11/Qt visual dependencies.

Step 1: Add ROS 2 Repositories 

# 1. Ensure locales are configured for UTF-8
sudo apt update && sudo apt install locales -y
sudo locale-gen en_US en_US.UTF-8
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
export LANG=en_US.UTF-8

# 2. Enable the Ubuntu Universe repository
sudo apt install software-properties-common -y
sudo add-apt-repository universe -y

# 3. Add the ROS 2 GPG key
sudo apt update && sudo apt install curl -y
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg

# 4. Add the repository to your sources list
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null
Enter fullscreen mode Exit fullscreen mode

Step 2: Install ROS 2 Base 

sudo apt update
sudo apt install ros-jazzy-ros-base ros-dev-tools -y
Enter fullscreen mode Exit fullscreen mode

Step 3: Source the Environment Permanently

To make the ROS 2 tools available automatically every time you log in via SSH:

echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc
source ~/.bashrc
Enter fullscreen mode Exit fullscreen mode

Verify your installation:

ros2 --help
Enter fullscreen mode Exit fullscreen mode

The Ultimate Payoff

With all of these steps completed, let's look at our final memory profile:

mdshaifur@shaifur-orin-nano:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.4Gi       607Mi       6.2Gi        12Mi       817Mi       6.8Gi
Swap:           15Gi          0B        15Gi
Enter fullscreen mode Exit fullscreen mode

By transitioning to headless mode and optimizing background services, our baseline memory plummeted to an astonishing 607 MiB!

This leaves you with 6.8 GiB of fully available, ultra-fast unified memory. You are now in the perfect position to safely run:

  • LLM Inference: Host local models like Gemma 2B via llama.cpp using ~1.5–2 GB of VRAM on the Jetson's GPU.
  • Dual CSI Cameras: Feed high-bandwidth IMX219 streams into your ROS 2 stack without running out of frame buffers.
  • Complex Robotics Pipelines: Execute localization, navigation, and obstacle avoidance simultaneously.

Optimizing your hardware limits isn't just about resource conservation—it is what makes robust, low-latency, and reliable edge robotics possible!

Have you optimized your Jetson platform for edge-AI or robotics? Let me know your favorite tricks in the comments below!

Top comments (1)

Collapse
 
topstar_ai profile image
Luis •

I found the approach to stripping down the OS to reclaim RAM very informative, especially the step of deactivating the graphical user interface and pruning background services. I've had similar experiences with optimizing embedded systems for autonomous applications, where every megabyte counts. One thing I'd like to add is that it's also important to consider the trade-offs between disabling services and potential debugging or maintenance needs. For instance, disabling kerneloops.service might save some resources, but it could also make it harder to diagnose issues in the field. Have you encountered any challenges or limitations when implementing these optimizations in your own projects, particularly with regards to balancing resource usage and system maintainability?