GraspGen turns a point cloud into ranked 6-DOF grasps

Three axes of variation, and a model that scores its own output

GraspGen is described as a modular framework for diffusion based six degree of freedom robotic grasp generation, and the modularity is defined along three axes. The first is embodiments, where the framework covers distinct gripper types, and the readme names three of them, an industrial pinch gripper and a suction gripper among the supported set. The second is observability, meaning tolerance of partial point clouds against complete ones, which is the difference between a system that only works with a perfect depth scan and one that works in a cluttered bin. The third is complexity, grasping a single object against grasping in clutter. On top of the generator there is a second learned component, a grasp discriminator that scores and ranks the generated grasps, trained with what the readme calls a novel and performant recipe on the generator itself. That component is the reason the output is a ranked list rather than a single pose, and in a robot stack a ranking is far more useful than a lone suggestion, because the caller can try the top candidate and fall back.

The performance claims, and where they come from

The readme states that GraspGen outperforms prior methods in both real and simulated settings, with state of the art performance on the FetchBench grasping benchmark and a seventeen percent improvement, while being memory efficient at twenty one times less memory and running in real time at twenty hertz before TensorRT. Those are the project's own numbers, published in the readme and in the linked paper, and they are worth reading carefully for what they imply. A benchmark improvement measures a distribution of scenes and objects rather than your scene, and the memory figure is the difference that makes the method usable on a single GPU rather than a cluster, which is the practical constraint for most robotics groups. The hertz figure is the one that matters for deployment, and the qualifier is important, since twenty hertz is before TensorRT optimisation, so the number is a floor for the optimised path rather than a ceiling. The paper is on arXiv and the project page carries the visuals, the radar comparison figure and the demonstration clips, and the paper was accepted to ICRA in February 2026.

Three grippers, and a separate project for the rest

The most important limitation is stated in a note near the top of the readme. This repository only supports three grippers, the Franka-Panda, the Robotiq-2F-140 and a suction cup, and anyone who wants grasp generation for other grippers, with DROID robots and the Robotiq-2F-85 given as examples, is pointed to a separate extension project, GraspGen-X, which is described as a cross-embodiment foundation model for grasping. That separation is a reasonable design, because supporting an arbitrary gripper means varying the action space and the training data, which is a research programme rather than a configuration flag. It also means the two projects have different conditions and a different maturity, and the project you need may not be the project in this repository. Within the supported set, the framework does cover the interesting cases, since a pinch gripper and a suction cup have very different contact behaviour, and the data generation code for suction grippers is included here while the antipodal gripper data generation based on Isaac Lab was released as a separate package.

Four ways to install, chosen by what you are doing

The installation section is organised by use case, and the table that follows makes the recommendation explicit. For training, Docker is recommended, and for inference the pip and uv route is described as the fastest and easiest option. If you want to run GraspGen as a standalone server, for example so that a language model agent or a remote robot client can call it, there is a client-server directory built on ZMQ, which means no installation is needed on the client side. And there is an MCP directory for calling GraspGen as a tool by a language model, which was added in March 2026 alongside the ZMQ server. The Docker path is a clone and a build script.

git clone https://github.com/NVlabs/GraspGen.git && cd GraspGen
bash docker/build.sh # This will take a while

The pip path assumes a Python 3.10 environment, with conda offered for creating one.

conda create -n GraspGen python=3.10 -y && conda activate GraspGen

And the PyTorch install is pinned to a specific CUDA wheel index.

pip install torch==2.1.0 torchvision==0.16.0 torch-cluster torch-scatter -f https://data.pyg.org/whl/torch-2.1.0+cu121.html

That pin is the single most likely source of friction for a new user, and it connects to the hardware caveat below.

The dependency stack is old, and the backbone choice depends on your GPU

The packaging file pins a stack that was current in 2024 rather than 2026. PyTorch is fixed at 2.1.0 with torchvision at 0.16.0, numpy at 1.26.4, diffusers at 0.11.1, timm at 1.0.15 and the huggingface hub at 0.25.2, with a sparse convolution build for CUDA 12.0 and a set of tooling packages around it. The requirements file carries the same pins for a subset. More consequential is the note in the roadmap section, which says the point transformer version three backbone does not yet run on CUDA 12.8 or Blackwell GPUs because of a dependency issue in the upstream implementation, and that if you are on CUDA 12.8 you should use the PointNet++ backbone for now until it is resolved, with a working example of the newer backbone available in the extension project. So the hardware you own determines which model you can evaluate, and a machine with a current generation card is pushed onto the older backbone unless you wait for the dependency fix.

Models, data and three different licences

The artefacts are published outside the repository. The model checkpoints live in a Hugging Face model repository and the dataset in a separate one under the NVIDIA PhysicalAI Robotics organisation, and the readme links a dataset licence file, with the badge indicating a Creative Commons Attribution 4.0 licence for the data specifically. That distinction matters, because the code, the model weights and the dataset do not share a licence. The code is under a licence the repository listing classifies as a custom one that GitHub cannot classify, the packaging metadata names the licence as NVIDIA Corporation, and the setup script carries a clause stating that NVIDIA and its licensors retain all intellectual property and proprietary rights, that any use, reproduction, disclosure or distribution without an express licence agreement is prohibited, and that the software is provided on an as is basis with no warranties. There is a separate licence file for assets. For a research team this is workable, and for anyone shipping a product built on it, the terms are the thing to read first rather than last.

Editorial conclusion

GraspGen earns a place for a robotics team that needs grasp candidates for a cluttered scene with a real gripper in the loop, since it releases the whole pipeline rather than a model card, and the discriminator means the output is a ranked list rather than a single guess. It is the wrong choice if your gripper is not one of the three supported, since the extension path is a separate project with its own conditions, and it is the wrong choice if you are on current hardware, because the point transformer backbone does not run on newer CUDA builds and the fallback changes the model you are evaluating. Verify three things before you start: which gripper you are generating for, whether the CUDA and PyTorch versions in the dependency set match your machine, since the container and the pip path are pinned to older releases, and what the licence permits, since the project is published under an NVIDIA Corporation licence with a separate terms file for assets and a Creative Commons licence for the dataset. The last push was on 2026-07-06 and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. NVlabs/GraspGen on GitHub
3. Project website
4. README