{"id":134147,"date":"2026-09-30T12:59:53","date_gmt":"2026-09-30T12:59:53","guid":{"rendered":"https:\/\/www.seeedstudio.com\/blog\/?p=134147"},"modified":"2026-09-30T12:59:56","modified_gmt":"2026-09-30T12:59:56","slug":"jetson-powered-mobile-robot-full-stack-development-in-practice-module-1-jetson-ros2","status":"publish","type":"post","link":"https:\/\/www.seeedstudio.com\/blog\/2026\/09\/30\/jetson-powered-mobile-robot-full-stack-development-in-practice-module-1-jetson-ros2\/","title":{"rendered":"Mobile Robot Full-stack Development In Practice \u2160: Build the Robot Brain First \u2014 Jetson, ROS 2, and the Development Foundation"},"content":{"rendered":"\n

If this is your first time coming across the series, Mobile Robot Full-stack Development In Practice<\/strong> is an open-source, hands-on course built around a simple idea: instead of learning robotics as a collection of isolated algorithms, learn how the pieces connect into a real system.<\/p>\n\n\n\n

The course starts from the computing platform and gradually moves into perception, sensor fusion, SLAM, autonomous navigation, semantic understanding, manipulation, and deployment. The goal is not just to run a few impressive demos. It is to understand how sensors, edge AI, robotics middleware, control software, and physical hardware come together in one robot.<\/p>\n\n\n\n

\"Mobile<\/a><\/figure>\n\n\n\n

If you have not seen the full course overview yet, start there first to understand the overall learning path. All open-source documentation, code, and future updates are also available on GitHub.<\/p>\n\n\n\n

\ud83d\udc49 Course Introduction<\/a><\/p>\n\n\n\n

\ud83d\udc49 Mobile Robot Full-Stack Development GitHub<\/a><\/strong><\/p>\n\n\n\n

\ud83d\udc49 M01 \u2014 Platform and Development Environment<\/a><\/strong><\/p>\n\n\n\n

When you actually put a mobile robot on the bench, the first problem is rarely, \u201cWhich model should I train?\u201d A more basic set of questions comes first. Where does camera data enter the system? Can the GPU actually be used? How do LiDAR, IMU, and motor controllers connect to the computer? How does a development PC communicate with the robot? And how do multiple software components keep running together without turning the whole robot into one giant, fragile script?<\/p>\n\n\n\n

If that foundation is missing, even a strong vision model, navigation stack, or embodied AI policy can remain nothing more than an isolated demo.<\/p>\n\n\n\n

So this first article focuses on something less flashy, but much more fundamental:<\/p>\n\n\n\n

How do you turn an edge AI computer into a reliable, extensible robotics development platform?<\/strong><\/p>\n\n\n\n

The reference setup used here is a reComputer Robotics J5011 powered by NVIDIA Jetson AGX Orin 32GB<\/strong>, running L4T 36.4.4 \/ JetPack 6.2.1, together with an Ubuntu 22.04.5 LTS host PC for development and validation.<\/p>\n\n\n\n

A Robot Computer Is More Than a PC with a GPU<\/h2>\n\n\n\n

When people compare robot computers, AI performance is often the first number they notice. The J5011 uses Jetson AGX Orin 32GB, while the J5012 uses the 64GB module, reaching up to 200 TOPS and 275 TOPS respectively.<\/p>\n\n\n\n

But TOPS alone does not explain why a robotics computer is different from a desktop workstation.<\/p>\n\n\n\n

A desktop PC mainly needs to run software. A robot computer has to do that and<\/strong> connect software to the physical world.<\/p>\n\n\n\n

A mobile robot may be receiving images from multiple cameras while a LiDAR streams point clouds, an IMU updates motion estimates, and the chassis controller waits for velocity commands. At the same time, perception, localization, planning, and control processes may all be running concurrently.<\/p>\n\n\n\n

These are not sequential jobs where one program finishes before the next starts. They are continuous data streams and control loops that need to coexist.<\/p>\n\n\n\n

That means a practical robotics platform needs both compute<\/strong> and connectivity<\/strong>.<\/p>\n\n\n\n

\"reComputer<\/a><\/figure>\n\n\n\n

The reComputer Robotics J501 provides multiple Ethernet interfaces, USB, four CAN-FD channels, UART, RS-232\/422\/485, M.2 expansion, and GMSL2 camera connectivity. In a specification table, these are simply interfaces. In a robot, they map directly to LiDARs, cameras, motor controllers, IMUs, GNSS modules, storage, and network links.<\/p>\n\n\n\n

This is why it is more useful to think of the J501 as an information hub for the robot<\/strong>: sensor data enters through physical interfaces, algorithms run on the compute platform, and control commands leave through another set of physical interfaces.<\/p>\n\n\n\n

Product family:<\/strong>
reComputer Robotics J501 Series<\/a><\/p>\n\n\n\n

J501 hardware guide:<\/strong>
https:\/\/wiki.seeedstudio.com\/ai_robotics_recomputer_j501_robotics_getting_started\/<\/a><\/p>\n\n\n\n

\"Rear<\/figure>\n\n\n\n

Start by Asking: Can Linux Actually See the Hardware?<\/h3>\n\n\n\n

Before debugging ROS 2 or Python, verify that the operating system can see the hardware you expect to use.<\/p>\n\n\n\n

The first set of tools is not exotic. It is standard Linux:<\/p>\n\n\n\n

# USB devices\nlsusb\n\n# Network and CAN interfaces\nip link show\n\n# PCIe devices\nlspci\n\n# I2C \/ SPI \/ UART\nls \/dev\/i2c-*\nls \/dev\/spidev*\nls \/dev\/ttyTHS*\n\n# Storage devices\nlsblk<\/code><\/pre>\n\n\n\n
This may look basic, but it reflects one of the most important debugging habits in robotics:<\/p>\n\n\n\n
Verify the physical and operating-system layer before debugging the application layer.<\/strong><\/p>\n\n\n\n
If a camera disappears, a CAN interface is down, or a serial port never appears under \/dev<\/code>, reinstalling ROS 2 will not solve the problem.<\/p>\n\n\n\n
On the reference platform, can0<\/code> and can1<\/code> use the native Tegra mttcan controller, while can2<\/code> and can3<\/code> are provided through external MCP251XFD controllers over SPI. Multiple I\u00b2C, SPI, and UART device paths are also available for IMUs, GNSS receivers, actuators, and other peripherals.<\/p>\n\n\n\n
This is the first systems-level lesson worth keeping:<\/p>\n\n\n\n
Every ROS topic, model input, or control command eventually has to map back to real hardware.<\/strong><\/p>\n\n\n\n
\"reComputer<\/figure>\n\n\n\n
\n
The J501 acts as the connection point between sensing, compute, communication, and robot actuation.<\/p>\n<\/blockquote>\n\n\n\n
JetPack Is Not Just \u201cUbuntu for Jetson\u201d<\/h2>\n\n\n\n
Once the hardware is visible, the next layer is the Jetson software stack.<\/p>\n\n\n\n
It is easy to think of JetPack as simply an Ubuntu image for Jetson, but that misses most of what makes the platform useful for robotics and edge AI.<\/p>\n\n\n\n
The reference environment uses JetPack 6.2.1 with L4T 36.4.4, CUDA 12.6.11, cuDNN 9.3, TensorRT 10.3, VPI 3.2.4, OpenCV, PyTorch, FFmpeg, and GStreamer.<\/p>\n\n\n\n
A useful way to understand the stack is layer by layer:<\/p>\n\n\n\n
J501 hardware \u2192 L4T \/ Ubuntu \u2192 CUDA \/ cuDNN \/ TensorRT \/ VPI \u2192 PyTorch \/ ROS 2 \u2192 robotics applications<\/strong><\/p>\n\n\n\n
At the bottom, the Jetson platform provides CPU, GPU, memory, and I\/O resources. L4T and the Linux BSP provide the kernel, drivers, and platform support. CUDA, cuDNN, TensorRT, and VPI expose hardware acceleration to software. PyTorch and ROS 2 then sit higher in the stack, where developers actually build perception, inference, communication, and control applications.<\/p>\n\n\n\n
That dependency chain matters.<\/p>\n\n\n\n
Ubuntu may boot normally while CUDA is broken. PyTorch may import successfully while GPU acceleration is unavailable. TensorRT may be installed but not on the expected path. A camera may physically be connected while the driver layer is still wrong.<\/p>\n\n\n\n
So a healthy Jetson environment should be verified, not assumed<\/strong>.<\/p>\n\n\n\n
A practical baseline check looks like this:<\/p>\n\n\n\n
# L4T \/ JetPack base\ncat \/etc\/nv_tegra_release\n\n# Ubuntu\ncat \/etc\/os-release\n\n# Kernel\nuname -a\n\n# CPU\nlscpu\n\n# Memory and disk\nfree -h\ndf -h\n\n# GPU\nnvidia-smi\n\n# CUDA\n\/usr\/local\/cuda\/bin\/nvcc --version\n\n# TensorRT Python binding\npython3 -c \"import tensorrt; print(tensorrt.__version__)\"\n\n# OpenCV\npython3 -c \"import cv2; print(cv2.__version__)\"<\/code><\/pre>\n\n\n\n
There are a few details worth remembering.<\/p>\n\n\n\n
The OpenCV 4.8.0 build in the reference environment does not<\/strong> include CUDA acceleration by default. Having CUDA installed does not automatically mean every OpenCV operation will run on the GPU. If your workflow depends on CUDA-enabled OpenCV, you need an appropriate build or container.<\/p>\n\n\n\n
Likewise, tools such as nvcc<\/code> and TensorRT’s trtexec<\/code> may exist without being available directly in your shell PATH.<\/p>\n\n\n\n
Jetson also forces you to think about something desktop AI development often hides:<\/p>\n\n\n\n
performance, power, and thermals are coupled.<\/strong><\/p>\n\n\n\n
Using nvpmodel<\/code>, you can inspect and change power modes. jetson_clocks<\/code> can lock CPU, GPU, and memory clocks for more consistent performance testing.<\/p>\n\n\n\n
For short benchmarks, MAXN may be appropriate. Inside a battery-powered mobile robot, however, runtime, heat, and sustained stability matter just as much as peak throughput.<\/p>\n\n\n\n
That distinction becomes increasingly important once the robot starts running perception and planning continuously rather than in short demos.<\/p>\n\n\n\n
\n
Suggested image:<\/strong> Vertical Jetson robotics software stack
Caption:<\/strong> Each software layer depends on the layer below it, from J501 hardware and L4T to CUDA acceleration, ROS 2, and robot applications.<\/p>\n<\/blockquote>\n\n\n\n
From \u201cThe System Runs\u201d to \u201cThe System Is Pleasant to Develop On\u201d<\/h2>\n\n\n\n
A validated JetPack installation means the machine is capable of running AI workloads.<\/p>\n\n\n\n
It does not yet mean the development workflow is efficient.<\/p>\n\n\n\n
\"Mobile<\/figure>\n\n\n\n
Real robot development involves a repetitive loop: remotely connect to the robot, sync code, create or switch environments, install dependencies, run containers, inspect logs, monitor GPU and memory usage, modify code, and repeat.<\/p>\n\n\n\n
Without a clean workflow, the system gradually becomes difficult to reproduce and harder to debug.<\/p>\n\n\n\n
For this part, the course points developers to Seeed’s reComputer Jetson for Beginners<\/strong> material, which covers everyday Jetson tooling such as Linux networking, SSH, remote desktop, Python, CUDA, TensorRT, PyTorch, Docker, Jtop, VS Code, JupyterLab, and uv<\/code>.<\/p>\n\n\n\n
Basic Tools and Getting Started:<\/strong>
https:\/\/github.com\/Seeed-Projects\/reComputer-Jetson-for-Beginners\/tree\/main\/3-Basic-Tools-and-Getting-Started<\/a><\/p>\n\n\n\n
Remote Development First<\/h3>\n\n\n\n
Once the J501 is mounted inside a robot, attaching a monitor and keyboard every time you need to change code becomes impractical.<\/p>\n\n\n\n
A better model is:<\/p>\n\n\n\n
Host PC = development console<\/strong>
J501 = onboard robot computer<\/strong><\/p>\n\n\n\n
SSH handles most command-line work:<\/p>\n\n\n\n
# On J501: check the IP address\nip addr\n\n# On the host PC: test network reachability\nping <J501_IP>\n\n# Connect remotely\nssh <username>@<J501_IP><\/code><\/pre>\n\n\n\n
This same network-first mindset also helps later with ROS 2.<\/p>\n\n\n\n
If the machines cannot even ping each other, there is no reason to start debugging DDS.<\/p>\n\n\n\n
For graphical workflows, NoMachine or another remote desktop solution can be used when needed.<\/p>\n\n\n\n
Isolate Python Projects<\/h3>\n\n\n\n
Robot projects tend to accumulate dependencies quickly.<\/p>\n\n\n\n
A vision experiment may need one version of a package, while another tool requires something different. Installing everything into the system Python is a reliable way to create conflicts over time.<\/p>\n\n\n\n
A cleaner approach is to give each project its own environment. With uv<\/code>, for example:<\/p>\n\n\n\n
mkdir robot_project\ncd robot_project\n\nuv venv\n\nsource .venv\/bin\/activate<\/code><\/pre>\n\n\n\n
The important point is not the specific tool. It is the habit of keeping project environments isolated and reproducible<\/strong>.<\/p>\n\n\n\n
On Jetson, GPU frameworks require an extra level of care.<\/p>\n\n\n\n
PyTorch compatibility depends on JetPack and CUDA versions, so the safe order is:<\/p>\n\n\n\n
Verify JetPack \/ CUDA \u2192 choose a compatible PyTorch build \u2192 install project dependencies<\/strong><\/p>\n\n\n\n
not:<\/p>\n\n\n\n
Install the latest package and hope CUDA works.<\/strong><\/p>\n\n\n\n
Use Docker for the Whole Runtime<\/h3>\n\n\n\n
Python virtual environments isolate Python dependencies. Docker can isolate a much broader runtime, including system libraries, Python packages, application code, and parts of the AI software stack.<\/p>\n\n\n\n
That matters because robotics and edge AI applications often depend on specific combinations of CUDA, TensorRT, and system packages.<\/p>\n\n\n\n
On Jetson, however, a container must also be able to access the NVIDIA GPU.<\/p>\n\n\n\n
Before relying on a GPU container, at least verify:<\/p>\n\n\n\n
docker --version\ndocker info\n\nnvidia-smi\ncat \/etc\/nv_tegra_release<\/code><\/pre>\n\n\n\n
Later, the Isaac ROS environment provides a more practical test by checking whether ROS 2 and the Orin GPU are both visible inside<\/strong> the development container.<\/p>\n\n\n\n
Monitor the Robot Computer Like a Robot Computer<\/h3>\n\n\n\n
When frame rate suddenly drops, the model is not always the problem.<\/p>\n\n\n\n
The GPU may not be saturated. Memory may be tight. The power mode may be wrong. Thermal throttling may be reducing clocks.<\/p>\n\n\n\n
Monitoring tools such as Jtop make CPU, GPU, memory, frequency, power, and thermal behavior much easier to inspect. Combined with nvpmodel<\/code> and jetson_clocks<\/code>, they turn \u201cthe robot feels slower today\u201d into a measurable systems problem.<\/p>\n\n\n\n
VS Code and JupyterLab then serve different roles in the development cycle.<\/p>\n\n\n\n
A notebook is convenient for testing a camera frame or a small inference pipeline. A maintained ROS 2 package is a better home for production robot software.<\/p>\n\n\n\n
The healthy progression is usually:<\/p>\n\n\n\n
quick experiment \u2192 validated idea \u2192 reusable package \u2192 integrated robot node<\/strong><\/p>\n\n\n\n
By this point, the J501 has stopped being \u201ca Jetson that boots\u201d and has become an actual robotics workstation: remotely accessible, environment-aware, container-ready, and observable.<\/p>\n\n\n\n
ROS 2: A Robot Is Not One Big Program<\/h2>\n\n\n\n
This is the point where the setup becomes a robotics system.<\/p>\n\n\n\n
A real mobile robot should not be one enormous Python script.<\/p>\n\n\n\n
The camera driver should capture images. A perception node should process them. Localization should estimate pose. Navigation should plan motion. A chassis node should execute velocity commands.<\/p>\n\n\n\n
These components may be maintained by different developers and may even run on different computers.<\/p>\n\n\n\n
ROS 2 provides the coordination layer.<\/p>\n\n\n\n
Its core concepts map cleanly to common robotics patterns:<\/p>\n\n\n\n