Skip to content

[Proposal] Consolidate Franka Panda config names after flat-asset migration #8186

Open

Description

@maxkra15

Proposal

After #8169, #8170, and #8171 land and their task/checkpoint contracts are qualified, consolidate the standard Franka Panda configurations around the shared flat franka_panda.usda. Select Physics and Colliders variants explicitly; keep gripper-only collisions as the normal default. Agree on one durable public name for the standard Panda configuration (prefer FRANKA_PANDA_CFG) and retain a separate high-PD configuration only where its control contract is genuinely needed.

Motivation

The migration temporarily exposes FRANKA_PANDA_CFG, FRANKA_PANDA_FLAT_CFG, FRANKA_PANDA_HIGH_PD_CFG, FRANKA_PANDA_FLAT_HIGH_PD_CFG, and FRANKA_PANDA_MENAGERIE_CFG. These names encode asset history rather than the intended robot/control contract. They also carry different USD and actuator-group contracts (for example, panda_shoulder/panda_forearm versus panda_arm), making the right choice unclear for tasks and downstream users.

Alternatives

Keeping FLAT in the permanent name is safe but exposes an implementation detail. Removing compatibility names immediately would break existing callers. The Robotiq-gripper Franka is a distinct robot configuration and is not part of this consolidation.

Build Info

Checklist

  • I have checked that there is no similar issue in the repo

Acceptance Criteria

  • Decide and document the canonical standard and high-PD names, including the actuator-group contract. Do not silently repurpose a deprecated name; align warnings and migration guidance before the breaking release.
  • Migrate maintained core/contrib tasks, examples, tests, docs, and public type stubs to the chosen names; leave no maintained task dependent on the legacy or nested-instance Panda asset.
  • Keep backend and collider selection explicit and independent, without duplicate Panda asset definitions. Preserve the distinct Robotiq configuration.
  • Retire transitional aliases only after their announced deprecation window (currently Isaac Lab 4.0), with release notes and an import/actuator migration example.
  • Validate representative PhysX and Newton task startup and the qualified pretrained-policy contracts after the rename.

Activity

  1. AntoineRichard commented on Sep 30, 2026

    @AntoineRichard
    Collaborator

    Can we make sure we have a single asset for Franka that we've calibrated for all our backends? @rdsa-nv for viz.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    assetNew asset feature or requestenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions