Support Quest teleop for G1 locomanipulation example#350
Support Quest teleop for G1 locomanipulation example#350linqianqian-work wants to merge 9 commits intomainfrom
Conversation
2261210 to
63130c1
Compare
df10ae8 to
1eb21e2
Compare
1eb21e2 to
ba26d7a
Compare
peterd-NV
left a comment
There was a problem hiding this comment.
This is a great addition, thanks for putting it all together!
docs/pages/example_workflows/locomanipulation/step_2_teleoperation.rst
Outdated
Show resolved
Hide resolved
|
|
||
| # Expand to batch dimension | ||
| actions = action.repeat(env.num_envs, 1) | ||
| # Hack for G1 Pink WBC to transferm EE into robot base coordinates |
There was a problem hiding this comment.
I wondering why this transformation from world frame to robot frame needs to happen in the action term versus being something done by the XR retargetters. Seems like it would make sense for the action from the teleop device to be already relative to the robot since the robot can be placed arbitrarily anywhere.
Totally fine to have this as it is right now but just curious if you know why XR designed the retargetter for G1 like that.
There was a problem hiding this comment.
We can do world space to some frame of reference attached to some part of the robot, but then that would require that the retargeter be aware of where the robot is w.r.t. the teleop "world origin/base space" coordinate frame. I felt that would introduce additional shared state between the teleop stack and the application and require a tighter integration.
The other option is to consider every EE target a "relative pose" based on the initial or calibrated position of the teleoperator. We opted against this for the Lab integration because it requires a manual calibration step, or for the teleoperator to be aware of their initial starting position relative to the initial position of the robot. This is currently how real robot teleop works since they do not have a shared origin.
Once Isaac Teleop is integrated here, we can take advantage of this setup if you all prefer since it's also shared by the real robot stack (with clutching of the inputs, etc). Another option once Isaac Teleop is integrated, you can specify which coordinate system to output transforms in and apply a per frame offset. So if you pass in the robot base link to scene origin transform, you'll get all the poses relative to that link.
There was a problem hiding this comment.
FWIW, in lab this is done in an action term before passing the EE tasks to IK
There was a problem hiding this comment.
I've tried including this in the action term process_action before passing the IK, but then the recorded action is in world coordinate, and during reply this is sensitive to the record/replay delta of the robot position and leads to gradual but noticable motion drift during replay when replaying multiple episodes. See the video in this thread
isaaclab_arena_g1/g1_env/mdp/actions/g1_decoupled_wbc_pink_action.py
Outdated
Show resolved
Hide resolved
|
XR/teleop parts LGTM. Thanks @linqianqian-work |
Summary
Support Quest3 for loco-manipulation teleop and record/replay
Detailed description
Support Quest3 for loco-manipulation teleop for g1_pink example. This allows proper data recording for the locomanipulation.
Adds openxr + g1_pink teleop support
Adds documention for locomanip data recording with Quest