Jetson Orin Nano 2 announcement: should your robot project wait?

What NVIDIA announced on 25 August

NVIDIA announced Jetson Orin Nano 2 with 78 TOPS, 8GB memory and an eight-core Arm CPU. It claims twice the inference performance of Orin Nano Super, the same compact form factor, and 40% lower power at equivalent performance in its stated 15-watt comparison. These are vendor claims, not measurements from this site.

The module and developer kit are expected in the first half of 2027. The release does not give a price. It also does not supply enough benchmark detail to reproduce the performance comparison or establish a complete carrier-board compatibility matrix.

参考资料： NVIDIA announces Jetson Orin Nano 2

Nano 2 is not the December 2024 Super software upgrade

The earlier Orin Nano Super launch offered a $249 developer kit, 67 INT8 TOPS and software improvements for existing Orin Nano kit owners. NVIDIA's December 2024 post described an 8GB module and a six-core Arm CPU. That historical kit price is not a quotation for Nano 2.

Keep separate entries in your purchasing spreadsheet for the board you own, a currently quoted replacement, and the newly announced product. Record the exact part number rather than shortening every entry to 'Jetson Nano'. A seller's listing title is not sufficient evidence that two products share a module, supported software image or accessory bundle.

参考资料： NVIDIA unveils its most affordable generative AI supercomputer

Buy or wait: decide from the experiment's deadline

If you need to collect robot demonstrations next month, the useful question is whether your existing computer can record the required camera and joint streams reliably. You do not need to choose the final inference device before validating lighting, camera position, timestamps and task boundaries. Progress on those pieces reduces uncertainty regardless of which board eventually runs the policy.

For a later product programme, create a checkpoint rather than an open-ended wait. Write down the latest date by which an evaluation unit, supported software stack and acceptable commercial quotation must exist. Define an alternative platform before that checkpoint arrives. Otherwise an interesting announcement can quietly become an unbudgeted dependency on your delivery schedule.

A working prototype should only be migrated for a measurable reason: missed inference deadlines, insufficient memory, an unacceptable enclosure temperature, or a demonstrated integration requirement. Rebuilding a functioning setup merely because a successor is announced can consume the time you needed for task evaluation.

A useful first robotics trial: visual inspection without motion

Consider a bench that checks whether a fixture contains the expected part. Start with recorded images that include empty fixtures, reflections, partially hidden parts and objects outside the training set. Define the accepted output as a classification with an explicit unknown state. Keep the first trial disconnected from machine outputs so incorrect detections cannot initiate a cycle.

Next, run the camera feed alongside the processes you actually need: capture, decoding, preprocessing, inference, a small display and logging. Measure from image capture to the result the application consumes. Frames per second alone can hide a queue of old observations. Record how the application discards stale frames and how quickly it recovers after the camera is unplugged.

This proposed trial answers a narrower and more useful question than whether a board can 'run robotics': can your complete inspection path produce timely, inspectable results under the conditions at your bench? It is an evaluation method, not a claim that this launch demonstrates inspection accuracy.

LeRobot-style projects: budget the whole deployment

For a learned manipulation policy, separate data collection, training and deployment. Build an inventory of camera streams, observation history, model weights, runtime dependencies and action outputs. State where training happens. A compact inference target should not automatically inherit the requirements of the workstation used to train the policy.

Before purchasing, test export and loading with your exact model revision and intended inference backend. Preserve a small set of recorded observations and expected outputs to detect conversion mistakes. Then profile sustained execution with logging enabled, not a single forward pass after all other applications have been closed.

Include a memory worksheet with entries for the operating system, model, intermediate tensors, image buffers and application processes. Measure peak use during startup as well as steady operation. Reducing precision or input resolution is only useful if the resulting behaviour still passes your task evaluation. This guide does not establish that any specific LeRobot policy or release already supports the announced device.

The benchmark evidence worth asking for

Ask the supplier to identify the model, input dimensions, numerical precision, batch size, runtime versions and selected power mode behind a comparison. Specify whether preprocessing and postprocessing are included. Without those conditions, a performance multiple is a lead to investigate, not a multiplier to apply to your own cycle-time estimate.

Use the same test recordings and quality threshold on both candidate systems. Report median and tail latency, dropped frames, sustained temperature and energy over a representative run. A faster inference kernel may be irrelevant if camera acquisition or data transfer dominates. Equally, an average that looks acceptable may conceal occasional delays that make an interactive application frustrating.

The worksheet below is a proposed acceptance record. Set numerical limits from your task rather than copying arbitrary thresholds from another robot.

A matching outline is not a finished installation

Before reusing a carrier or enclosure, obtain the relevant mechanical, electrical and software compatibility documents for the actual module revision. Check connector clearances, camera interfaces, power delivery, cooling, storage and recovery access. A similar external outline does not, by itself, approve an existing installation.

Request a written bill of materials that distinguishes the module, carrier, storage, power supply, cooler and enclosure. Include cameras, cables and any software support you need. Ask which items are included in the kit and which are substitutions. For an imported purchase, retain the quotation, product identifiers and agreed delivery terms rather than relying on a marketplace thumbnail.

Do not populate an unknown price with the predecessor's launch price. Use an explicitly unpriced option in the budget until a dated quotation exists. Compare the total installed prototype cost and the effort of maintaining it, not just the board line. A cheap acquisition can still be the wrong choice if the necessary integration work exceeds your available time.

For an FR3 or FR5, keep inference separate from control

A potential Fairino application might classify a workpiece, suggest a destination or assist an operator with a document search. Those tasks do not make the inference computer the robot's motion controller. Confirm supported interfaces against the exact controller and software revision before assuming an Ethernet cable makes the systems compatible.

For an initial integration, consume read-only observations and display proposals for review. Do not translate unrestricted model text into executable motion commands. Any later action interface needs deliberately constrained inputs, authorisation and independent checks appropriate to the installation. Define what happens when observations are old or inference disappears.

Protective functions and the equipment's risk assessment remain separate engineering responsibilities. A cancelled model request is not a protective stop, and a board's AI performance figure says nothing about the suitability of a safety function. This article is not a commissioning procedure.

Leave the evaluation with a decision, not a shopping list

Write a short decision record with three outcomes: continue on existing hardware, reserve an evaluation slot for the new device, or choose another available platform. Attach the workload definition, unresolved compatibility questions and the date for the next review. Give each unknown an owner so missing evidence does not become an assumed specification.

For a forum comparison, share the task, camera configuration, model revision, power setting and the result you measured. State whether the hardware was actually in your possession. That gives other builders something reproducible to discuss and keeps anticipation, vendor claims and practical experience from being blended into the same recommendation.

检查清单

• Identify the exact product and distinguish the module from a developer kit.
• Keep unknown price and compatibility fields explicitly unconfirmed.
• Set an evaluation deadline and a fallback for the project's delivery date.
• Profile a representative full application on equipment already available.
• Record model revision, precision, input size, runtime and power setting.
• Budget camera buffers, logs, storage, cooling and integration time.
• Keep proposed AI outputs outside the motion and protective-control boundary.
• Require a dated quotation and shipping evidence before treating a listing as available inventory.

常见问题