NVIDIA JetBot: an educational Jetson Nano robot you assemble and program from a browser

What the JetBot reference design is for

JetBot is not a product. It is an NVIDIA-designed open-source robot platform built around the Jetson Nano, intended for AI learning and experimentation. The README frames the value in three claims: an add-on cost under $150 on top of the Nano, tutorials that move from basic motion to AI-based collision avoidance, and interactive programming from a web browser. The last point matters more than it sounds. Because the workflow is a browser session rather than a compiled application, a learner can change a motor speed or a detection threshold and see the result on the robot immediately.

The audience is therefore narrow and specific. This is for someone who already has or plans to buy a Jetson Nano and wants a physical target for computer vision work. It is not for someone who wants a finished robot. The repository ships a Python package, notebooks, a docker directory and documentation sources under mkdocs.yml, but no chassis, no motors and no camera. Those come from a kit. The README points to a third party kits page listing SparkFun JetBot, Waveshare JetBot and other community or vendor variants, which tells you the project expects you to source hardware elsewhere and treats the software as the shared layer.

How the jetbot package, notebooks and motor HAT fit together

The architecture visible in the repository is a thin Python library sitting between notebooks and hardware. setup.py declares the package name jetbot at version 0.4.3, and its install_requires list is the clearest statement of what the software actually talks to: Adafruit_MotorHat, Adafruit-SSD1306 and sparkfun-qwiic. Motor control goes through the Adafruit motor HAT, the small OLED status display goes through the SSD1306 driver, and the Qwiic dependency covers I2C peripherals. Nothing exotic.

The build step is unusual for a pure Python package. setup.py defines a build_libs function that shells out to cmake followed by make before setup() runs, and package_data ships compiled shared objects under jetbot/ssd_tensorrt/*.so. That naming points at TensorRT-accelerated SSD detection, and it explains why installation is not a simple pip install on an arbitrary machine: the package expects to compile against the Jetson environment and to place a .so file inside the installed package. The notebooks directory then holds the tutorials that call into this library, and docs/ with mkdocs.yml builds the site published at jetbot.org.

The data flow for the collision avoidance example, as the tutorial structure implies, is camera frame into the detection model, detection result into a steering decision in the notebook, steering decision out through the motor HAT. The notebook is the control loop. That is a deliberate teaching choice, and it is also the main performance ceiling: a Python notebook driving motors will not match a compiled control loop.

Installing JetBot and running a first notebook

The README does not contain install commands. It says to read the JetBot documentation at jetbot.org, and the repository carries a docker directory and a scripts directory that the documentation covers. The repository does state the package name and the build dependency chain, so what follows is drawn from setup.py rather than from a documented procedure.

setup.py runs cmake and make before installing the package, so the build tools have to be present first. On a Jetson Nano running the JetPack 4.5 environment that release v0.4.3 targets, the entry point the repository provides is the setup script itself:

python3 setup.py install

The expected result is an installed jetbot package with the compiled TensorRT shared object in place. If cmake or make is missing, or if the CUDA and TensorRT headers are not present, this step fails before anything is installed, which is the most common first obstacle.

Once the package is present, the tutorials live in the notebooks directory and are opened as Jupyter notebooks. The README's description of the workflow is that you program the robot interactively from a web browser, so the practical first run is to start Jupyter on the Nano and open a notebook from that directory.

A second thing the repository shows is the dependency list that any working setup has to satisfy:

install_requires=[
    'Adafruit_MotorHat',
    'Adafruit-SSD1306',
    'sparkfun-qwiic'
]

Those three names are what the library imports at runtime. If a kit ships a different motor driver or omits the OLED, that is where the mismatch will surface, and the README does not describe how to adapt the library to a different board.

Where JetBot stops being the right tool

The release history is the honest limitation. The most recent release listed is v0.4.3 from 2021-02-02, described as support for JetPack 4.5. The two before it, v0.4.2 and v0.4.1, both landed in January 2021, covering a third party motor variant and Jetson Nano 2G with Docker. There is no release listed after February 2021, and the README does not document a migration path to newer JetPack versions. Anyone building today should treat JetPack 4.5 as the assumed target and verify that their Nano image matches, because the compiled TensorRT artifacts imply a tight coupling to the CUDA and TensorRT versions present at build time.

A second limitation is the notebook control loop. Interactive notebooks are excellent for teaching and poor for anything with timing requirements. If your project needs a deterministic control rate, or needs to run headless without a browser session, the JetBot notebook pattern is the wrong starting point even though the underlying jetbot package could still be used as a library.

Third, the software assumes a specific hardware stack. The install_requires list names an Adafruit motor HAT and an SSD1306 display. A kit built around a different motor driver, or a differential drive base without an OLED, will need code changes that the documentation does not cover. The README's mention of third party kits and the v0.4.2 fix for a third party motor variant shows this has been an ongoing source of variation rather than a solved problem.

JetBot compared with a ROS-based robot stack

The obvious alternative approach is a ROS-based robot, and the related searches show people look for exactly that comparison. The difference is not cosmetic. A ROS stack separates nodes, topics and a build system, so perception, planning and actuation are independent processes that can be swapped, restarted or replaced. JetBot puts the decision logic in a notebook cell and calls the motor library directly. For a learner, that means one file to read and no build system to learn. For a team, it means every change to the control flow is a change to a notebook, and there is no message bus to instrument.

The trade-off runs the other way too. ROS on a Jetson Nano brings a heavier runtime and a steeper setup curve for someone whose goal is to understand how a camera image becomes a steering command. JetBot's value is that this path is short and visible. If your goal is to learn computer vision on embedded hardware, the short path is the point. If your goal is to build a robot that integrates with other sensors and processes, the notebook pattern becomes an obstacle fairly quickly, and the jetbot package alone, without the notebooks, is the part worth keeping.

Maintenance, licensing and what an upgrade actually costs

The last push to the repository was on 2026-06-30, so the repository is not abandoned, but the release cadence tells a different story: no tagged release since 2021-02-02. Documentation and repository housekeeping can continue while the pinned software target stays where it was. Plan for the software side of JetBot as a fixed target rather than a moving one.

Licensing is straightforward in the sense that matters here. The repository is MIT licensed, with the licence file at LICENSE.md. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. This article is not legal advice, and the practical point is narrower: MIT covers the code in this repository, not the third party kits, the Jetson Nano itself, or the JetPack components the package compiles against. Those carry their own terms.

The upgrade cost is dominated by the build. Because setup.py compiles libraries and ships .so files for TensorRT, moving to a newer JetPack is not a version bump in a requirements file. It means rebuilding against the new CUDA and TensorRT, and the documentation does not describe that procedure for anything past JetPack 4.5. Budget the effort as a port, not an upgrade.

Editorial conclusion

Adopt JetBot if you want a documented, MIT-licensed reference platform for teaching AI on a Jetson Nano and you are prepared to build the hardware and stay on JetPack 4.5, which the v0.4.3 release targets. Do not adopt it if you need a maintained software stack with current JetPack support, or if you want a robot that works without assembling a chassis, motors and a motor HAT. Before buying anything, read the third party kits page at jetbot.org to see whether a SparkFun or Waveshare variant matches the parts you can actually source, and check the Adafruit_MotorHat, Adafruit-SSD1306 and sparkfun-qwiic dependencies in setup.py against what your kit ships.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NVIDIA-AI-IOT/jetbot on GitHub
4. README
5. Releases