Flexiv Rizon4s Reach Policy Support

[shauryadNv]

Description

Added support to train a reach policy for the Flexiv Rizon 4s robot. Defined new envs/tasks for this.
Added required robot config for the Flexiv Rizon 4s.
Added documentation for a tutorial on training a reach policy (with both, UR and Rizon).

Type of change

• New feature (non-breaking change which adds functionality)
• Documentation update

Checklist

• I have read and understood the contribution guidelines
• I have run the pre-commit checks with ./isaaclab.sh --format
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have updated the changelog and the corresponding version in the extension's config/extension.toml file
• I have added my name to the CONTRIBUTORS.md or my name already exists there

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds support for training reach policies on the Flexiv Rizon 4s robot, following the same pattern as the existing UR10e implementation.

Key additions:

• New robot configuration for Flexiv Rizon 4s (7-DOF arm) with actuator specifications
• Complete environment configs for training, play mode, and ROS inference deployment
• PPO training configuration with 1500 iterations and 256-128-64 network architecture
• Comprehensive documentation tutorial covering both UR10e and Rizon 4s reach policy training
• Workspace bounds configured for Rizon 4s: x[0,0.8]m, y[-0.4,0.4]m, z[0.05,0.75]m

Issues found:

• Critical: Hardcoded absolute path in flexiv_rizon.py will prevent other users from running this code
• Duplicate policy_action_space assignment in ROS inference config
• Minor comment inconsistency about visualization setting

Confidence Score: 2/5

• This PR cannot be merged as-is due to hardcoded local path that will break for other users
• The hardcoded absolute path /home/shauryad/workspaces/... in the robot config is a blocker that must be fixed. The duplicate variable assignment should also be corrected. Otherwise the implementation follows established patterns correctly.
• Pay special attention to flexiv_rizon.py which contains a hardcoded path that must be changed to a nucleus directory path before merging

Important Files Changed

Filename	Overview
source/isaaclab_assets/isaaclab_assets/robots/flexiv_rizon.py	adds Flexiv Rizon 4s robot config with hardcoded local path that will break for other users
source/isaaclab_tasks/isaaclab_tasks/manager_based/manipulation/deploy/reach/config/rizon_4s/joint_pos_env_cfg.py	reach environment config for Rizon 4s with workspace bounds and action scale, minor comment inconsistency
source/isaaclab_tasks/isaaclab_tasks/manager_based/manipulation/deploy/reach/config/rizon_4s/ros_inference_env_cfg.py	ROS inference config with duplicate policy_action_space assignment

Sequence Diagram

sequenceDiagram
    participant User
    participant GymEnv as Gym Environment
    participant ReachEnv as Rizon4sReachEnvCfg
    participant Robot as Flexiv Rizon 4s
    participant Policy as PPO Policy
    participant FrameTransformer

    User->>GymEnv: Register Isaac-Deploy-Reach-Rizon4s-v0
    GymEnv->>ReachEnv: Initialize environment config
    ReachEnv->>Robot: Load FLEXIV_RIZON4S_CFG
    Note over Robot: 7-DOF arm with actuator limits
    ReachEnv->>FrameTransformer: Setup ee_frame_wrt_base_frame
    Note over FrameTransformer: Track flange pose relative to base_link
    
    loop Training Episode
        ReachEnv->>ReachEnv: Sample target pose (pos + quat)
        Note over ReachEnv: Workspace: x[0,0.8], y[-0.4,0.4], z[0.05,0.75]
        ReachEnv->>Policy: Observe (joint_pos[7], joint_vel[7], target_pose[7])
        Note over Policy: Input dim: 21
        Policy->>Policy: Forward pass (256→128→64 network)
        Policy->>ReachEnv: Output incremental joint positions[7]
        Note over Policy: Scale: 0.0625
        ReachEnv->>Robot: Apply RelativeJointPositionAction
        Robot->>Robot: Update joint positions
        FrameTransformer->>ReachEnv: Compute end-effector pose
        ReachEnv->>ReachEnv: Calculate reward (pose tracking error)
        ReachEnv->>Policy: Return (obs, reward, done)
    end
    
    User->>GymEnv: Load trained policy for deployment
    GymEnv->>ReachEnv: Initialize ROS inference config
    Note over ReachEnv: Fixed target or ROS commanded
    loop Deployment
        ReachEnv->>Policy: Observe robot state
        Policy->>Robot: Command joint increments
        Robot->>Robot: Execute motion
    end

Loading

[greptile-apps]

_{3 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

comment says "Disable visualization" but code sets debug_vis = True

consider clarifying whether visualization should be enabled or disabled for Rizon 4s and update comment accordingly

[AntoineRichard]

Hello, it's very unlikely we will merge this to main. Could you target develop instead? Thanks!

[kellyguo11]

LGTM, we can merge this once we resolve the asset upload and TODO in the doc

[isaaclab-review-bot]

🤖 Isaac Lab Review Bot

Summary

This PR adds support for the Flexiv Rizon 4s robot with a reach policy training pipeline. It introduces:

• A new robot asset configuration (FLEXIV_RIZON4S_CFG)
• Gym environment registrations (train, play, ROS inference)
• PPO training configuration
• Comprehensive documentation tutorial

Design Assessment

The overall structure follows the established pattern set by the existing UR10e reach deployment config. The new Rizon 4s config properly extends ReachEnvCfg, overrides robot-specific parameters, and registers the expected gym environments. Good adoption of existing abstractions.

Architecture Impact

• Additive only — no changes to shared base classes or APIs
• Blast radius is limited to the new robot config and documentation
• No risk of breaking existing UR10e environments

Implementation Verdict

🟡 Minor issues found — 2 bugs (1 docs build-breaker, 1 missing feature parity), plus minor style observations.

Test Coverage

• ❌ No tests added (checkbox unchecked in PR template). This is acceptable for a new config if manually validated, but integration tests for environment instantiation would strengthen confidence.

CI Status

• ✅ pre-commit passed
• ⏳ license-check, Docker builds, and docs builds are still pending

Findings

See inline comments for details.

[isaaclab-review-bot]

⚠️ Suggestion: Use DRY pattern for action_scale_joint_space

The UR10e config uses a cleaner pattern:

self.action_scale_joint_space = [self.joint_action_scale] * self.action_space

Instead of manually listing the scale 7 times. This avoids a subtle bug if action_space is changed but the list length isn't updated.

Suggested change

	"joint7",
	self.action_scale_joint_space = [self.joint_action_scale] * self.action_space

[isaaclab-review-bot]

⚠️ Minor: Duplicate policy_action_space assignment

self.policy_action_space = "joint" is set on line 22 and again on line 30. The second assignment is redundant.

Suggested change

	"joint1",
	self.arm_joint_names = [

[isaaclab-review-bot]

🤖 Isaac Lab Review Bot — Follow-up

1 new issue found in the latest push.

[isaaclab-review-bot]

🐛 Bug: Image extension mismatch — broken figure

The added image file is reach_train.png but this directive references reach_train.jpg. Sphinx will not find the file and the figure will be missing from the rendered docs.

Suggested change

	:figwidth: 100%
	.. figure:: ../../_static/policy_deployment/03_reach/reach_train.png

[isaaclab-review-bot]

🤖 Isaac Lab Review Bot — Follow-up #2

Previous image extension bug (.jpg → .png) is fixed ✅

1 new minor docs issue found.

[isaaclab-review-bot]

📝 Minor: Incorrect approximation in video interval comment

The comment says "~every 100 training iterations" but with num_steps_per_env = 512:

• 72000 / 512 ≈ 140 iterations, not 100

The number 72000 comes from 720 steps/episode × 100 = 72000, so this should read:

Suggested change

	- ``--video_interval 72000``: Records a video every 72000 environment steps (~every 100 training iterations).
	- ``--video_interval 72000``: Records a video every 72000 environment steps (~every 100 episodes).

[isaaclab-review-bot]

🤖 Isaac Lab Review Bot — Follow-up #3

Previous initial_joint_pos concern is now addressed ✅

1 new bug found: syntax error introduced in the latest push.

[isaaclab-review-bot]

🐛 Bug: Duplicate action_scale_joint_space — first assignment missing closing ]

The latest push appears to have appended the new block without removing the original. The first action_scale_joint_space assignment (starting around line 42) is missing its closing bracket ], followed immediately by a second full assignment. This will raise a SyntaxError on import.

Expected: a single assignment. Remove the first (broken) one and keep only:

Suggested change

	self.action_scale_joint_space = [
	self.joint_action_scale,
	self.joint_action_scale,
	self.joint_action_scale,
	self.joint_action_scale,
	self.joint_action_scale,
	self.joint_action_scale,
	self.joint_action_scale,
	]

Or even better (DRY):

self.action_scale_joint_space = [self.joint_action_scale] * self.action_space

[huidongc]

the sim2real ref is not defined and causing a doc build error:

docs/source/policy_deployment/04_reach/reach_policy.rst:670: WARNING: undefined label: 'sim2real' [ref.ref]

Is the ref pointing to docs/source/policy_deployment/00_hover/hover_policy.rst?

[isaaclab-review-bot]

Good catch! You're right — the :ref:sim2real`` label is undefined on develop and will cause a doc build error.

I traced it: the .. _sim2real: label is defined in docs/source/experimental-features/newton-physics-integration/sim-to-real.rst, but that file only exists on main, not on develop (the target branch). So the cross-reference is dangling.

It's not pointing to hover_policy.rst — that file only has an external URL reference (.. _README of Sim2Real deployment: ...), not an RST label.

Suggested fix: either (1) remove the sim2real bullet from the Further Resources section since the target page doesn't exist on develop yet, or (2) replace it with a direct external link to the relevant sim-to-real resource (e.g., the HOVER sim2real README or similar). Option 1 is probably cleanest for now — the line can be re-added once sim-to-real.rst lands on develop.