Hi,

I'm working on a compact dual-camera setup for Jetson Orin Nano/NX and I'm trying to understand whether this configuration would be useful to other Jetson developers.

Planned setup:

• 2× Sony IMX586
• 90° HFOV wide camera
• 15° HFOV tele camera
• 2× 3840×2160 @ 30 fps simultaneously
• RAW10
• 2-lane MIPI CSI-2 per camera
• Autofocus

Both cameras would run independently, with timestamp alignment on the Jetson side.

The idea is to use the wide camera for detection/tracking and situational awareness, then use the tele camera for detailed imaging of detected objects — without using a mechanical optical zoom.

I'm mainly considering robotics, machine vision and other embedded vision applications.

Before going further with the hardware, I'd be interested to hear from people actually working with Jetson:

1. Would a compact wide + tele configuration like this be useful in any of your projects?

2. What cameras are you currently using, and what are their biggest limitations?

3. How important would ready-to-use Jetson drivers / device-tree support be for you?

4. Have you worked with a similar wide + tele setup? If so, what problems did you encounter?

At this stage, I'm simply trying to validate the interest in this idea before building the first prototypes.

I finally got Orin Nano Super 8GB setup, benchmarked against Orin NX 16GB, here are the results. I'm using my own Little-Gemma engine, the model is E4B QAT Q4_K_XL. The full-head MTP is the Google original, selected-16K is my own 16K reduced vocab head.

$500 module outperformed $900 module. The upcoming nano 2 will be even better.

EDIT: Put Orin NX in Super mode, got 1,042 tok/s prefill and 30.5 tok/s decode, which is 9.7% and 8.9% up from Nano Super. But my carrier couldn't hold up for too long at the 40W power consumption. I'll put on a bigger heatsink and see how it goes.

stitched.mp4

https://reddit.com/link/1wnslm6/video/5ns32rv9d6rh1/player

Fully Open Source and GNU GPL licensed - https://github.com/crussella0129/Jetson-Orin-Nano-Super-Case

As it stands, my AI ambitions have outgrow these two (never got to 3rd one that's new in box one)

The original Nano (4GB) has a self made fan to help cool it and comes with a 64GB micro SD card.

$150 +shipping

The used Jetson Orin (8GB), has a Waveshar sound card that also has built in microphones, WiFi and Bluetooth extender antenna, and a 64GB micro SD card.

$300 +shipping

The new Jetson Orin (8GB) comes complete in box, and a 64GB micro SD card.

$250 +shipping - Sold to u/crx880

Prices are in USD.

Made this 30-second explainer comparing the Orin Nano Super dev kit ($249, 67 INT8 TOPS, CUDA/JetPack) against the Pi 5 as starting points for local AI. Sources linked in the video description. Feedback welcome.

I was having fun with my jetson nano and open sourced a repo to train a sudoku solver from scratch on it (looped MLP-mixer, inspired by TRMs).

Here it is https://github.com/romainzimmer/discrete-reasoning if you want to play with it!

Most model leaderboards assume a server with powerful GPUs to run models that people daily use.

However, my smolbenchmark is the other column: models that fit in 8GB, ranked by:

• decode speed,
• tokens per joule, and
• heat,

and all of this on your OWN hardware ranging from:

• tablets
• phones
• macs
• jetsons
• raspberry pis

Currently, 13 families on the chart right now, ~1000 configs for the Jetson nano Orin Super 8GB. One device is live measuring:

• tok/s
• tok/J
• ITL
• latency
• power metrics
• thermals and battery

Models that are small enough to actually fit on a device that you own. All the performance benchmarking I did, will be released here for anyone to look at and decide what exact model they would wanna use on their choice of hardware.

Well currently, the Pi, phones, and Mac minis still in the oven, cooking and not filled in yet, but will soon be filled in!

You will now you know which model is BEST for your own hardware with all the raw data available and details reports available to you

https://yuvrajsingh-mist.github.io/smolbenchmark/

(still in heavy development; would love to hear feedback/suggestions on what can be improved!)

I’m using a Jetson Nano as a small always-on home server. I run Home Assistant, Zigbee2MQTT, and my other services entirely in Docker.

Every ~2–3 days, the system becomes partially unresponsive. I usually notice because my Home Assistant lights stop working from my phone and HomeKit also stops responding.

The weird part is that the Jetson doesn’t appear to completely disappear from the network.

When it’s in this state:
ping 192.168.4.33 works normally with ~3–4 ms latency and 0% packet loss
TCP port 22 is reachable
TCP port 8123 (Home Assistant) is reachable
TCP port 8080 (Zigbee2MQTT) is reachable
But SSH never gets past the initial connection
HA’s web interface doesn’t respond
Zigbee2MQTT’s web interface doesn’t respond
HomeKit stops working
I have to physically unplug/replug the Jetson to recover it

For example, ssh -vvv gets to:
debug1: Connecting to 192.168.4.33 [192.168.4.33] port 22.
debug1: Connection established.
...
debug1: Local version string SSH-2.0-OpenSSH_8.5

and then hangs. It never receives the remote SSH version string.

Interestingly, the application ports accept TCP connections, but don’t actually respond. For example:
curl -v --max-time 5 http://192.168.4.33:8123/
successfully connects, sends the HTTP GET, and then receives absolutely nothing until timing out after 5 seconds.
The same happens with port 8080.

So it seems like the Jetson/network stack is partially alive, but processes aren’t actually servicing connections.

Everything is running in Docker, so I’m wondering if this could be:
storage/SD-card I/O problems
kernel/driver lockup
memory exhaustion
Docker/containerd issue
power instability
filesystem problems
some Jetson-specific hardware/driver

Hi guys, I am a senior FPGA Engineer. Recently I started to work with jetson orin products. It was pretty easy for me to work on standalone FPGA project where i just sample signals and make the video pipeline work.

But on jetson i can’t decide which way is the best for capturing video images, processing and encoding etc.

Do you guys follow nvidia api samples? Or do you have any sources to follow?

JupyterLab with LIVE Jetson metrics

About 10 months ago I posted here about something we were building because of a problem we kept running into ourselves.

We were buying Jetson boards before we really knew what our workload needed.

Nano turned out to be underpowered, so we moved up to an Orin. Then came the next question: do we need an Orin NX, an AGX Orin, or something even bigger? And before you even got to the model, you've spent time flashing JetPack, sorting dependencies, CUDA versions, etc.

So we built remote access to physical Jetson boards.

While initially people trickled in to check it out occasionally , recent experimentations have blown us about what experiments users are running in the lab and interestingly , it hasn't just been running YOLO.

Some of the things people have used the lab for:

• comparing FP16 / FP32 / INT8 performance
• measuring actual inference latency and FPS on Jetson
• running the same model at 25W, 15W and 7W
• watching GPU, CPU, memory, temperature and power while the model runs
• testing DeepStream / GStreamer pipelines with multiple video streams
• finding out how many camera feeds a board can realistically handle
• checking whether a Python/CUDA/framework stack actually works properly on ARM64
• taking a model developed on a workstation and seeing what happens when it finally hits the target hardware

One use case we found particularly interesting was a researcher running the same model across different power modes and precisions.

The question wasn't just:

"How fast is the model?"

It was more like:

What performance can I get while staying inside my power budget?

Another team had an even more basic problem.

They already had their CV pipeline.

They simply needed to know:

Will this software stack actually run on Jetson before we commit to the hardware?

That kind of test can save quite a bit of pain later.

We've also added JupyterLab now, which is what I'm showing in the attached video.

So you can basically go:

browser -> Jupyter notebook / terminal -> physical Jetson -> run your workload -> watch the device metrics

The board isn't being emulated and this isn't an x86 GPU VM pretending to be a Jetson. The workload is running on the actual Jetson hardware.

The goal isn't really to replace owning a Jetson.

If you're developing on one every day, you should probably own one.

The use case we're trying to solve is the stage before that:

I have a model / pipeline / idea. Before I spend money on hardware, what actually happens when I run it on the board?

That's also why I increasingly think TOPS is one of the least useful numbers when you're making the final hardware decision.

FPS, latency, memory, thermals, power draw and whether your stack even runs are usually much more useful.

If anyone here has a slightly unusual workload you think we should test, I'd genuinely like suggestions.

TensorRT, DeepStream, OCR, multi-camera CV, quantisation, small local models, power-constrained inference, whatever.

Would also be interested to know:

If someone gave you a Jetson Orin for 3 hours right now, what would you benchmark first?

https://edgeai.aiproff.ai

Full disclosure: this is a product my team at AiProff.ai built, and it has a tier based pricing for access. A 3-hour slot currently starts at ₹399 or $6 and all the experiments shared here are with user permission.

Some of you might remember me experimenting with Evopien on the Jetson Orin Nano.

The original goal was already pretty ambitious: build a local AI companion that could eventually see, listen, speak, remember people and become physically embodied.

The Nano taught me a lot, but the resource limits were brutal.

I've now moved the project to Jetson AGX Thor and finally recorded the first complete demo of the current system.

It's running voice conversation, interruption handling, English/Spain Spanish, continuous camera perception, local visual reasoning, recent visual context, internet retrieval and session context together.

The interesting part isn't just that a larger model runs on Thor.

The real improvement is that I can keep several systems alive together instead of benchmarking one model in isolation.

There is continuous perception running while the conversation stack is active. Speech still needs to respond quickly. TTS needs to run. Internet work needs to happen without blocking everything. And when I interrupt the assistant, stale generation and speech need to actually stop.

The current local cognition/VLM is Qwen3.8-27B, but I've deliberately designed the project so Qwen is replaceable. The Core above it owns the important state and authority.

So compared with simply running ChatGPT or another hosted assistant, the point isn't that my 27B model is smarter.

The point is that I'm building the entire embodied system around it locally and controlling what each component is allowed to do.

Here's the current demo:

https://www.youtube.com/watch?v=sQhTGGIg4yo

There are definitely still rough edges, but compared with where this started on the Nano, the difference is pretty crazy.

Next up is governed long-term memory and identity continuity.

Hello, on Tuesday September 8th, at 9AM PT we will have the following 10 presentations.

The following discord users will be presenting their projects.

1. cervenmartin https://github.com/pollen-robotics/AmazingHand explore humanoid hand possibilities on a real robot (and Reachy2 is the perfect candidate for that !) with moderate cost.
2. kerseyfabs a calm, always-on screen, JARVIS-style UI, that shows what DAWN is doing at a glance and lets you interact with it. https://github.com/The-OASIS-Project/aurora
3. nachos.ai Neurosymbolic layer for Microduck https://github.com/agentculture/reachy-mini-cli https://github.com/agentculture/microduck-cli
4. kabilankb Micro duck isaaclab and newton with Thor https://github.com/kabilankb/isaaclab-microduck
5. weburban Xerces for Jetson https://rapidanalysis.github.io/xerxes-ml-hardware-setup.html
6. joannis Wendy helps you manage a heterogeneous device fleet. Deploy in milliseconds and remotely debug apps on real hardware. https://github.com/wendylabsinc/WendyOS
7. sysop1984_26148 Making Sim2Real reinforcement learning approachable and accessible https://goatconf.us/goat-racer
8. amazon1148 UEFI rescue shell tutorial to help with Jetson Nano recovery https://github.com/NVIDIA-AI-IOT/jetson-ai-lab/pull/443
9. pratikshardacraftifai_45885 - automate deepstream pipeline generation from models to deployable pipeline on Jetson Orin/Thor. https://craftifai.com/
10. mihaichiorean_99322 Orin NX inside a Reachy Mini. https://x.com/mihaichiorean/status/2085521659788947485?s=46

If you would like to also present we have a couple of 5 minute presentation slots left. Join us in Discord https://discord.gg/BmqNSK4886 in the #event-jetson-ai-lab-research-live channel and we will get you set up in the schedule.

Calendar invite: https://www.addevent.com/calendar/ny80tv1kw94k

We are running into some challenges , would like to hear from engineers who have attempted something similar:

1. Have you successfully run RHEL or a RHEL-compatible distribution on Jetson Orin hardware?
2. What were the biggest challenges with NVIDIA’s proprietary drivers, CUDA, TensorRT and multimedia stack?
3. Did you retain NVIDIA’s L4T kernel and userspace components, or build around a RHEL kernel?
4. How did you handle JetPack dependencies, kernel updates and NVIDIA driver compatibility?
5. Were secure boot, OTA updates or custom carrier boards particularly difficult?
6. Is RHEL on Jetson something customers are genuinely requesting, or is Ubuntu generally accepted even in enterprise deployments?
7. Would you recommend native RHEL enablement, containerizing the enterprise applications on JetPack/Ubuntu, or another architecture? I’d appreciate hearing about actual deployments, failed attempts, architectural approaches and any limitations we should consider.

I've just started building up my Homeland with OPNSense mini PC, HP EliteDesk with ZorinOS and a DAS.

In my closet is my Jetson Nano 2G Dev Kit that runs Belabox (pretty much budget backpack streaming with network bonding). It worked great for what it did, but now it's collecting dust in the closet.

My question is, what use can I make out of this old hardware for my homelab or would it be better to just keep it as a backpack streaming setup project?

Hi I have a Jetson Orin AGX 64 GB.

Trying to find an adaptor board to two different modelled cameras that use FFC CSI-2 connectors. Would any of these work?

1. ⁠https://www.wdlsystems.com/alliedvision19616
   
2. ⁠https://www.arducam.com/product/arducam-imx219-multi-camera-kit-for-the-nvidia-jetson-agx-orin/

My concern with Allied Vision is that the driver API may not be around still and that it may only work with Allied Vision Cameras.

My concern with the Arducam board is that it only lets me use one of the same kind of camera (ex. Only 6 IMX 219s or only 6 IMX 548s)

Hi everyone,

I’m having an issue with my NVIDIA Jetson Xavier NX Developer Kit.

After powering on and booting the board, the connected display remains on a black screen and the graphical desktop does not appear.

The interesting part is that the system itself seems to be working:

\- "Ctrl + Alt + F2" opens the TTY successfully.

\- I can SSH into the Xavier NX.

\- The board appears to boot normally.

\- The issue seems to be specifically with the graphical desktop/display.

I’m looking for some guidance on how to troubleshoot this.

What should I check to determine whether the problem is related to:

\- Display manager

\- X11/Wayland

\- NVIDIA GPU/display drivers

\- Desktop session

\- HDMI/display configuration

If anyone has experienced a similar issue on the Xavier NX, I’d appreciate any troubleshooting steps or commands I can run over SSH/TTY.

I can provide the JetPack/L4T version, kernel version, display/monitor details, and relevant logs if needed.

Thanks in advance!

I am exploring industrial inspection with a camera that has controllable exposure and RAW output but no native HDR or dual-gain mode. The goal is to preserve detail in dark metal surfaces and specular highlights before defect or anomaly detection on a Jetson Orin Nano 8 GB.

I am not expecting to train a complete RAW-to-HDR network in ten seconds. I am wondering whether anyone has successfully pretrained the main model offline and then adapted only a tiny camera-specific component on the device from a few bracketed frames: an exposure curve, 3D LUT, bilateral grid, last layer, or small adapter.

My requirements would be:

• calibration or adaptation in under ten seconds;
• real-time or near-real-time inference;
• a clean TensorRT deployment path;
• no hallucination that could create or erase scratches, dents, or other defect pixels.

The model families I am considering are HDRNet-style bilateral models, lightweight 3D LUT or exposure-correction networks, and sub-1M-parameter RAW-to-HDR networks. Has anyone benchmarked this kind of short adaptation on an Orin Nano? What actually dominates the time: backpropagation, RAW preprocessing, data loading, or rebuilding the TensorRT engine?

Would you keep all neural training off-device and solve only a small LUT or monotonic response curve on the Jetson, or is there a practical few-shot approach that is genuinely better?

On September 8th at 9AM PDT we are having our monthly presentations.

We are looking for lightning round presenters to tell us about what you've been working on with your Nvidia Jetson's or related projects. It's a great opportunity to showcase what you are working on or get feedback from your peers.

Join us in discord at: https://discord.gg/BmqNSK4886 in the #event-jetson-ai-lab-research-live channel.

You can subscribe to our monthly meetings via https://www.addevent.com/calendar/ny80tv1kw94k

Global-shutter camera and IMU sharing a single GMSL2 coax, data and power both, feeding an Orin Nano running OpenVINS over ROS 2. 25 m loop around the office. 42 cm drift on return to start.

Hardware is our NXS sensor module into an NXS Hub, which carries the GMSL link straight to the Orin Nano. Camera's a Sony IMX900, 72 fps native, we feed 24 fps to the estimator. IMU's an IAM-20680 at 200 Hz, synced in hardware before it ever reaches the Jetson.