Contributing

​

Bug reports and feature requests

​

Reporting bugs

1. Search existing issues: Do a quick search to see if your issue has already been reported
2. Comment on existing issues: If your issue exists, add any additional information as a comment

1. Open a new GitHub issue
2. Include a clear title and description
3. Provide:
   • Steps to reproduce the error
   • Expected behavior vs actual behavior
   • Code samples or test cases demonstrating the issue
   • Error messages and stack traces
   • Environment details (CUDA version, GPU model, OS, etc.)

​

Suggesting features

1. Clarify your idea: Make sure you have a clear vision of the enhancement
2. Check documentation: Verify the feature doesn’t already exist
3. Search existing issues: Do a quick search to avoid duplicates

1. Provide a clear title and description
2. Explain the use case: Why would this enhancement be useful?
3. Show examples: Highlight similar features in other libraries if applicable
4. Include code examples: Demonstrate how the feature would be used

​

Making a pull request

​

Initial setup (one-time)

git clone https://github.com/USERNAME/Isaac-GR00T.git
# or
git clone [email protected]:USERNAME/Isaac-GR00T.git

git remote add upstream https://github.com/NVIDIA/Isaac-GR00T.git

git remote -v

origin    https://github.com/USERNAME/Isaac-GR00T.git (fetch)
origin    https://github.com/USERNAME/Isaac-GR00T.git (push)
upstream  https://github.com/NVIDIA/Isaac-GR00T.git (fetch)
upstream  https://github.com/NVIDIA/Isaac-GR00T.git (push)

uv pip install -e .[dev]

​

Keeping your fork up-to-date

git checkout main  # if not already on main
git pull --rebase upstream main
git push

​

Creating a branch for your changes

# Replace BRANCH with a descriptive name
git checkout -b BRANCH
git push -u origin BRANCH

​

Testing your changes

​

Code formatting and linting

# Format code
ruff format .

# Fix linting issues automatically
ruff check --fix .

​

Running tests

# Run all tests
pytest -v

# Run specific test module
pytest -v tests/gr00t/data/test_embodiment.py

# Run tests for a specific function you modified
pytest -v tests/gr00t/policy/test_policy.py::test_get_action

pytest -v tests/gr00t/policy/test_policy.py

​

Opening a pull request

1. Open a new GitHub pull request
2. Provide a clear description of:
   • The problem being solved
   • Your solution approach
   • Links to related issues
3. Reference any relevant issues (e.g., “Fixes #123”)

​

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

​

Code style guidelines

​

Python code formatting

• Use ruff format for consistent formatting
• Use ruff check --fix for linting
• Follow PEP 8 guidelines
• Maximum line length: 100 characters (enforced by ruff)

​

Documentation

• Write clear docstrings for all public functions and classes
• Use Google-style docstring format
• Update relevant documentation when changing functionality

​

Commit messages

• Use clear, descriptive commit messages
• Start with a verb in present tense (e.g., “Add”, “Fix”, “Update”)
• Reference issue numbers when applicable (e.g., “Fix #123: …”)

Add support for new embodiment tag

- Implement NEW_EMBODIMENT configuration
- Add tests for new modality config
- Update documentation

Fixes #456

​

Testing guidelines

​

Writing tests

• Place tests in tests/ directory matching the source structure
• Name test files with test_ prefix (e.g., test_policy.py)
• Use descriptive test function names (e.g., test_get_action_with_valid_observation)
• Include both positive and negative test cases
• Test edge cases and error conditions

​

Test coverage

• Aim for high test coverage of new code
• Run tests locally before submitting PR
• CI will run full test suite on all supported platforms

​

Continuous Integration

• Code formatting: ruff format --check
• Linting: ruff check
• Unit tests: pytest
• Type checking: mypy (if configured)

​

Getting help

• Ask questions in your pull request
• Comment on related issues
• Check existing documentation and examples
• Review similar merged pull requests for guidance

​

License

SPDX-FileCopyrightText: Copyright (c) 2025 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
SPDX-License-Identifier: Apache-2.0

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

​

Thank you