Omnigrasp: Simulated Humanoid Grasping on Diverse Objects

Authors: zhengyi  luo
jinkun  cao
sammy  christen
alexander  winkler
kris  kitani
weipeng  xu
Venue: NeurIPS_cc_2024_Conference
Published: 2024-04-23 05:34:56

Abstract: We present a method for controlling a simulated humanoid to grasp an object and move it to follow an object's trajectory. Due to the challenges in controlling a humanoid with dexterous hands, prior methods often use a disembodied hand and only consider vertical lifts or short trajectories. This limited scope hampers their applicability for object manipulation required for animation and simulation. To close this gap, we learn a controller that can pick up a large number (>1200) of objects and carry them to follow randomly generated trajectories. Our key insight is to leverage a humanoid motion representation that provides human-like motor skills and significantly speeds up training. Using only simplistic reward, state, and object representations, our method shows favorable scalability on diverse objects and trajectories. For training, we do not need a dataset of paired full-body motion and object trajectories. At test time, we only require the object mesh and desired trajectories for grasping and transporting. To demonstrate the capabilities of our method, we show state-of-the-art success rates in following object trajectories and generalizing to unseen objects. Code and models will be released.

Main paper: 
 introduction: 
 Given an object mesh, we aim to control a simulated humanoid equipped with two dexterous hands to pick up the object and follow plausible trajectories, as shown in Fig. 1 . This capability could be broadly applied to creating human-object interactions for animation and AV/VR, with potential extensions to humanoid robotics [27] . However, controlling a simulated humanoid with dexterous hands for precise object manipulation poses significant challenges. The bipedal humanoid must maintain balance to enable detailed movements of the arms and fingers. Moreover, interacting with objects requires forming stable grasps that accommodate diverse object shapes. Combining these demands with the inherent difficulties of controlling a humanoid with a high degree of freedom (e.g. 153 DoF) significantly complicates the learning process.These challenges have led previous methods of simulated grasping to employ a disembodied hand [16, 17, 61, 85] to grasp and transport. While this approach can generate physically plausible grasps, employing a floating hand compromises physical realism: the hands' root position and orientation are controlled by invisible forces, allowing it to remain nearly perfectly stable during grasping. Moreover, studying the hand in isolation does not accurately reflect its typical use, which is when it is attached to a mobile and flexible body. A naive approach to supporting hands is to use existing full-body motion imitators [42] to provide body control and train additional hand controllers for grasping. However, the presence of a body introduces instability, limits hand movement, and requires synchronizing the entire body to facilitate finger motion. State-of-the-art (SOTA) full-body imitators also have an average 30mm tracking error for the hands, which can cause the humanoid to miss objects. Due to the above challenges, previous work that studies full-body object manipulations often limits its scope to only one sequence of object interaction [78] and encounters difficulties in trajectory following [6] , even when trained with highly specialized motion priors.Another challenge of grasping is the diversity of the object shapes and trajectories. Each object may require a unique type of grasping, and scaling to thousands of different objects often requires training procedures such as generalist-specialist training [85] or curriculum [75, 101] . There is also infinite variability in potential object trajectories, and each trajectory may necessitate precise full-body coordination. Thus, prior work typically focuses on simple trajectories, such as vertical lifting [16, 85] , or on learning a single, fixed, and pre-recorded trajectory per policy [17] . The flexibility with which humans manipulate objects to follow various trajectories while holding them remains unobtainable for current humanoids, even in simulations.In this work, we introduce a full-body and dexterous humanoid controller capable of picking up and following diverse object trajectories using Reinforcement Learning (RL). Our proposed method, Omnigrasp, presents a scalable approach that generalizes to unseen object shapes and trajectories. Here, "Omni" refers to following any trajectory in all directions within a reasonable range and grasping diverse objects. Our key insight lies in using a pretrained universal dexterous motion representation as the action space. Directly training a policy on the joint actuation space using RL results in unnatural motion and leads to a severe exploration problem. Exploration noise in the torso can lead to a large deviation in the location of the arm and wrist as the noise propagates through the kinematic chain. This can lead to the humanoid quickly knocking the object away, which hinders training progress. Prior work has explored using a separate body and hand latent space trained using adversarial learning [6] . However, as the adversarial latent space can only cover small-scale and curated datasets, these methods do not achieve a high grasping success rate. The separation of hands and body motion prior also adds complexity to the system. We propose using a unified universal and dexterous humanoid motion latent space [41] . Learned from a large-scale human motion database [45] , our motion representation provides a compact and efficient action space for RL exploration. We enhance the dexterity of this latent space by incorporating articulated hand motions into the existing body-only human motion dataset.Equipped with a universal motion representation, our humanoid controller does not require any specialized interaction graph [78, 102] to learn human-object interactions. Our input to the policy consists only of object and trajectory-following information and is devoid of any grasp or reference body motion. For training, we use randomly generated trajectories and do not require paired full-body human-object motion data. We also identify the importance of pre-grasps [17] (the hand pose right before grasping) and utilize it in our reward design. The resulting policy can be directly applied to transport new objects without additional processing and achieve a SOTA success rate on following object trajectories captured by Motion Capture (MoCap).To summarize, our contributions are: (1) we design a dexterous and universal humanoid motion representation that significantly increases sample efficiency and enables learning to grasp with simple yet effective state and reward designs; (2) we show that leveraging this motion representation, one can learn grasping policies with synthetic grasp poses and trajectories, without using any paired full-body and object motion data. (3) we demonstrate the feasibility of training a humanoid controller that can achieve a high success rate in grasping objects, following complex trajectories, scaling up to diverse training objects, and generalizing to unseen objects.Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?Answer: [Yes] Justification: We propose a framework to train simulated humanoid to pick up diverse objects and follow omnidirectional trajectories, and showcase our performance on popular datasets and video results.Guidelines:• The answer NA means that the abstract and introduction do not include the claims made in the paper. • The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or NA answer to this question will not be perceived well by the reviewers. • The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings. • It is fine to include aspirational goals as motivation as long as it is clear that these goals are not attained by the paper. 
related works: 
 Simulated Humanoid Control. Simulated humanoids can be used to create animations [26, 36, 54, 55, 56, 57, 80, 94, 102] , estimate full-body pose from sensors [23, 30, 33, 40, 43, 79, 92, 93, 95] , and transfer to real humanoid robots [20, 27, 28, 59, 60] . Since there are no ground truth data for joint actuation and physics simulators are often non-differentiable, model-based control [29] , trajectory optimization [36, 83] , and deep RL [13, 54] are used instead of supervised learning. Due to its flexibility and scalability, deep RL has been popular among efforts in simulated humanoids, where a policy/controller is trained via trial and error. Most of the previous work on humanoids does not consider articulated fingers, except for a few [3, 6, 36, 49] . A dexterous humanoid controller is essential for humanoids to perform meaningful tasks in simulation and in the real world.Dexterous Manipulation. Dexterous manipulation is an essential topic in robotics [7, 8, 11, 12, 15, 16, 19, 37, 62, 75, 85, 96, 97, 98] and animation [2, 6, 34, 101] . This task usually involves pick-andplace [7, 8] , lifting [75, 85, 97] , articulating objects [98] , and following predefined object trajectories [6, 9, 17] . Most of these efforts use a disembodied hand for grasping and employ non-physical virtual forces to control the hand. Among them, D-Grasp [16] leverages the MANO [66] hand model for physically plausible grasp synthesis and 6DoF target reaching. UniDexGrasp [85] and its followup [75] use the Shadow Hand [1] . PGDM [17] trains a grasping policy for individual object trajectories and identifies pre-grasp initialization (initializing the hand in a pose right before grasping) as a crucial factor for successful grasping. For the works that consider both hands and body, PMP [3] and PhysHOI [78] train one policy for each task or object. Braun et al. [6] studies a similar setting to ours but relies on MoCap human-object interaction data and only uses one hand. Compared to prior work, Omnigrasp trains one policy to transport diverse objects, supports bimanual motion, and achieves a high success rate in lifting and object trajectory following. Kinematic Grasp Synthesis. Synthesizing hand grasp can be widely applied in robotics and animation. A line of work [5, 10, 10, 18, 21, 38, 47, 51, 84, 89] focuses on reconstructing and predicting grasp from images or videos, while others [52, 90] study hand grasp generation to help image generation. Among them, Manipnet and CAMS [99] predict finger poses given a hand object trajectory. TOCH [103] and GeneOH [39] denoise dynamic hand pose predictions for object interactions. More research in this area focuses on generating static or sequential hand poses with a given object as the condition [31, 70, 88] . For synthesizing body and hand poses jointly, there are limited MoCap data available [71] due to difficulties in capturing synchronized full-body and object trajectories. Some generative methods [22, 35, 69, 72, 73, 82, 91] can create paired human-object interactions, but they require initialization from the ground truth [22, 69, 82] , or only predict static full-body grasps [73] . In this work, we use GrabNet [70] trained on object shapes from OakInk [86] to generate hand poses as reward guidance for our policy training.Humanoid Motion Representation. Due to the high DoF of a humanoid and the sample inefficiency of RL training, the search space within which the policy operates during trial and error is crucial. A more structured action space such as motion primitives [24, 25, 48, 63] or motion latent space [56, 74] can significantly increase sample efficiency since the policy can sample coherent motion instead of relying on random "jittering" noise. This is especially important for humanoids with dexterous hands, where the torso motion can drastically affect the hand movement and lead to the humanoid knocking the object away. Thus, prior work in this space utilizes part-based motion priors [3, 6] trained on specialized datasets. While effective in the single task setting where the humanoid only needs to perform actions close to the ones in the specialized datasets, these motion priors can hardly scale to more free-formed motion, such as following randomly generated object trajectories. We extend the recently proposed universal humanoid motion representation, PULSE [41] , to the dexterous humanoid setting and demonstrate that a 48-dimensional, full-body-and-hand motion latent space can be used to pick up and follow randomly generated trajectories. Question: Does the paper discuss the limitations of the work performed by the authors?Answer: [Yes]Justification: Limitations, failure cases, and visulizations of failure cases are disucssed in the main paper and supplementary materials.Guidelines:• The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper. • The authors are encouraged to create a separate "Limitations" section in their paper.• The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be. • The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with a few runs. In general, empirical results often depend on implicit assumptions, which should be articulated. • The authors should reflect on the factors that influence the performance of the approach. For example, a facial recognition algorithm may perform poorly when image resolution is low or images are taken in low lighting. Or a speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon. • The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size. • If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness. • While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an important role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations. 
preliminaries: 
 We define the human pose as q t ≜ (θ t , p t ), consisting of 3D joint rotation θ t ∈ R J×6 and position p t ∈ R J×3 of all J links on the humanoid (hands and body), using the 6 degree-of-freedom (DOF) rotation representation [104] . To define velocities q1:T , we have qt ≜ (ω t , v t ) as angular ω t ∈ R J×3 and linear velocities v t ∈ R J×3 . For objects, we define their 3D trajectories q obj t using object position p obj t , orientation θ obj t , linear velocity v obj t , and angular velocity ω obj t . As a notation convention, we use • to denote the kinematic quantities from Motion Capture (MoCap) or trajectory generator and normal symbols without accents for values from the physics simulation. Ô refers to a dataset of diverse object meshes.Goal-conditioned Reinforcement Learning for Humanoid Control. We define the object grasping and transporting task using the general framework of goal-conditioned RL. Namely, a goalconditioned policy π is trained to control a simulated humanoid to grasp an object and follow object trajectories qobj 1:T using dexterous hands. The learning task is formulated as a Markov Decision Process (MDP) defined by the tuple M = ⟨S, A, T , R, γ⟩ of states, actions, transition dynamics, reward function, and discount factor. The simulation determines the state s t ∈ S and transition dynamics T , where a policy computes the action a t . The state s t contains the proprioception s p t and the goal state s g t . Proprioception is defined as s p t ≜ (q t , qt , c t ), which contains the 3D body pose q t , velocity qt , and contact forces c t on the hand. The goal state s g t is defined based on the states of the objects. When computing the states s g t and s p t , all values are normalized with respect to the humanoid heading (yaw). Based on proprioception s p t and the goal state s g t , we define a reward r t = R(s p t , s g t ) for training the policy. We use proximal policy optimization (PPO) [68] to maximize discounted reward E T t=1 γ t-1 r t . Our humanoid follows the kinematic structure of SMPL-X [53] using the mean shape. It has 52 joints, of which 51 are actuated. 21 joints are body joints, and the remaining 30 joints are for two hands. All joints have 3 DoF, resulting in an actuation space of a t ∈ R 51×3 . Each degree of freedom is actuated by a proportional derivative (PD) controller, and the action a t specifies the PD target.Question: For each theoretical result, does the paper provide the full set of assumptions and a complete (and correct) proof?Answer: [NA] Justification: We do not include theoretical results.Guidelines:• The answer NA means that the paper does not include theoretical results.• All the theorems, formulas, and proofs in the paper should be numbered and cross-referenced.• All assumptions should be clearly stated or referenced in the statement of any theorems.• The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide a short proof sketch to provide intuition. • Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material. • Theorems and Lemmas that the proof relies upon should be properly referenced. 
omnigrasp: grasping diverse objects and follow object trajectories: 
 To tackle the challenging problem of picking up objects and following diverse trajectories, we first acquire a universal dexterous humanoid motion representation in Sec.4.1. Using this motion representation, we design a hierarchical RL framework (Sec. 4.2) for grasping objects using simple ‡ state and reward designs guided by pre-grasps. Our architecture is visualized in Figure 2 . ‡ Here, the "simple reward" refers to not needing paired full-body-and-hand MoCap data when computing the reward, which increases complexity.We introduce PULSE-X that extends PULSE [41] to the dexterous humanoid by adding articulated fingers. We first train a humanoid motion imitator [42] that can scale to a large-scale human motion dataset with finger motion. Then, we distill the motion imitator into a motion representation using a variational information bottleneck (similar to a VAE [32] ).Data Augmentation. Since full-body motion datasets that contain finger motion are rare (e.g., 91% of the AMASS sequences do not have finger motion), we first augment existing sequences with articulated finger motion and construct a dexterous full-body motion dataset. Similarly to the process in BEDLAM [4] , we randomly pair full-body motion from AMASS [45] with hand motion sampled from GRAB [71] and Re:InterHand [50] to create a dexterous AMASS dataset. Intuitively, training on this dataset increases the dexterity of the imitator and the subsequent motion representation.PHC-X: Humanoid Motion Imitation with Articulated Fingers. Inspired by PHC [42] , we design PHC-X π PHC-X for humanoid motion imitation with articulated fingers. For the finger joints, we treat them similarly as the rest of the body (e.g. toe or wrist) and find this formulation sufficient to acquire the dexterity needed for grasping. Formally, the goal state for training π PHC-X with RL is s g-mimic t ≜ ( θt+1 ⊖ θ t , pt+1 -p t , vt+1 -v t , ωt+1 -ω t , θt+1 , pt+1 ), which contains the difference between proprioception and one frame reference pose qt+1 .Learning Motion Representation via Online Distillation. In PULSE [44] , an encoder E PULSE-X , decoder D PULSE-X , and prior P PULSE-X are learned to compress motor skills into a latent representation. For downstream tasks, the frozen decoder and prior will translate the latent code to joint actuation. Formally, the encoder E PULSE-X (z t |s p t , s g-mimic t) computes the latent code distribution based on current input states. The decoder D PULSE-X (a t |s p t , z t ) produces action (joint actuation) based on the latent code z t . The prior P PULSE-X (z t |s p t ) defines a Gaussian distribution based on proprioception and replaces the unit Gaussian distribution used in VAEs [32] . The prior increases the expressiveness of the latent space and guides downstream task learning by forming a residual action space (see Sec.4.2). We model the encoder and prior distribution as diagonal Gaussian:EQUATIONTo train the models, we use online distillation similar to DAgger [67] by rolling out the encoderdecoder in simulation and querying π PHC-X for action labels a PHC-X t . For more information and evaluation of PHC-X and PULSE-X, please refer to the Appendix B.Using hierarchical RL and PULSE-X's trained decoder D PULSE-X and prior P PULSE-X , the action space for our object manipulation policy becomes the latent motion representation z t . Since the action space serves as a strong human-like motion prior, we can use simple state and reward design and do not require any paired object and human motion to learn grasping policies. We use only hand pose before grasping (pregraps), either from a generative method or MoCap, to train our policy.State. To provide the task policy π Omnigrasp with information about the object and the desired object trajectory, we define the goal state asEQUATIONwhich contains the reference object pose and the difference between the reference object trajectory for the next ϕ frames and the current object state. σ obj ∈ R 512 is the object shape latent code computed using the canonical object pose and Basis Point Set (BPS) [58] . p obj t -p hand t is the difference between the current object position and each hand joint position. All values are normalized with respect to the humanoid heading. Notice that the state s g t does not contain body pose, grasp, or phase variables [6] , which makes our method applicable to unseen objects and reference trajectories at test time.Action. Similar to downstream task policies in PULSE, we form the action space of π Omnigrasp as the residual action with respect to prior's mean µ p t and compute the PD target a t : where µ p t is computed by the prior P PULSE-X (z t |s p t ). The policy π Omnigrasp computes z omnigrasp t ∈ R 48 instead of the target a t ∈ R 51×3 directly, and leverages the latent motion representation of PULSE-X to produce human-like motion.EQUATIONReward. While our policy does not take any grasp guidance or reference body trajectory as input, we utilize pre-grasp guidance in the reward. We refer to pre-grasp qpre-grasp ≜ ( ppre-grasp , θpre-grasp ) as a single frame of hand pose consisting of hand translation ppre-grasp and rotation θpre-grasp . PGDM [17] shows that initializing a floating hand to pre-grasps can help the policy better reach objects and initiate manipulation. As we do not initialize the humanoid with the pre-grasp pose as in PGDM, we design a stepwise pre-grasp reward:EQUATIONbased on time and the distance between the object and hands. Here, λ = 1.5s indicates the frame in which grasping should occur, and p hand t indicates the hand position. When the object is far away from the hands (∥ ppre-graspp hand t ∥2 > 0.2), we use an approach reward r approach t similar to a point-goal [42, 81] rewardr approach t = ∥ ppre-grasp -p hand t ∥2 -∥ ppre-grasp -p hand t-1 ∥2,,where the policy is encouraged to get close to the pre-grasp. After the hands are close enough (≤ 0.2m), we use a more precise hand imitation reward: r pre-grasp t = whpe -100∥ ppre-grasp -p hand t ∥ 2 ×1{∥ ppre-grasppobj t ∥ 2 ≤0.2} +whre -100∥ θpre-grasp -θ hand t ∥ 2 , to encourage the hands to be close to pre-grasps. For grasps that involve only one hand, we use an indicator variable 1{∥p pre-grasppobj t ∥2 ≤ 0.2} to filter out hands that are too far away from the object. After timestep λ, we use only the object trajectory following reward:r obj t = (wope -100∥ pobj t -p obj t ∥ 2 +wore -100∥ θobj t -θ obj t ∥ 2 +wove -5∥v obj t -v obj t ∥ 2 +woave -5∥ ωobj t -ω obj t ∥ 2 )•1{C}+1{C}•wc. (5)r obj t computes the difference between the current and reference object pose, which is filtered by an indicator variable 1{C} that is set to true if the object is in contact with the humanoid hands. The reward 1{C} • wc encourages the humanoid's hand to have contact with the object. Hyperparameters can be found in Appendix C.Object 3D Trajectory Generator. As there is a limited number of ground-truth object trajectories [17] , either collected from MoCap or animators, we design a 3D object trajectory generator that can create trajectories with varying speed and direction. Using the trajectory generator, our policy can be trained without any ground-truth object trajectories. This strategy provides better coverage of potential object trajectories, and the resulting policy achieves higher success in following unseen trajectories (see Table 1 ). Specifically, we extend the 2D trajectory generator used in PACER [65, 76] to 3D, and create our trajectory generator T 3D (q obj 0 ) = qobj 1:T . Given initial object pose q obj 0 , T 3D can generate a sequence of plausible reference object motion qobj 1:T . We limit the z-direction trajectory to between 0.03m and 1.8m and leave the xy direction unbounded. For more information and sampled trajectories, please refer to Appendix C. Training. Our training process is depicted in Algo 1. One of the main sources of performance improvement for motion imitation is hard-negative mining [42, 43] , where the policy is evaluated regularly to find the failure sequences to train on. Thus, instead of using object curriculum [75, 85, 101] , we use a simple hard-negative mining process to pick hard objects Ôhard to train on. Specifically, let sj be the number of failed lifts for object j over all previous runs. The probability of choosing object j among all objects is P (j) =s j J i s i .Object and Humanoid Initial State Randomization. Since objects can have diverse initial positions and orientations with respect to the humanoid, it is crucial to have the policy exposed to diverse initial object states.Given the object dataset Ô and the provided initial states (either from MoCap or by dropping the object in simulation) q obj 0 , we perturb q obj 0 by adding randomly sampled yaw-direction rotation and adjusting the position component q obj 0 . We do not change the pitch and yaw of the object's initial pose as some poses are invalid in simulation. For the humanoid, we use the initial state from the dataset if provided (e.g. GRAB dataset [71] ), and a standing T-pose if there is no paired data.Inference. During inference, the object latent code p obj t , a random object starting pose q obj 0 , and desired object trajectory qobj 1:T is all that is required, without any dependency on pre-grasps or paired kinematic human pose.Question: Does the paper fully disclose all the information needed to reproduce the main experimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?Answer: [Yes] Justification: We describe our method in full detail and will provide code and trained models.Guidelines:• The answer NA means that the paper does not include experiments.• If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not. • If the contribution is a dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable. • Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed. • While NeurIPS does not require releasing code, the conference does require all submissions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example (a) If the contribution is primarily a new algorithm, the paper should make it clear how to reproduce that algorithm. (b) If the contribution is primarily a new model architecture, the paper should describe the architecture clearly and fully. (c) If the contribution is a new model (e.g., a large language model), then there should either be a way to access this model for reproducing the results or a way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset). (d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome to describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers to have some path to reproducing or verifying the results. 
experiments: 
 Datasets. We use the GRAB [71] , OakInk [86] , and OMOMO [34] to study grasping small and large objects.The GRAB dataset contains 1.3k paired full-body motion and object trajectories of 50 objects (we remove the doorknob as it is not movable). Since the GRAB dataset provides reference body and object motion, we use them to extract initial humanoid positions and pre-grasps. We follow prior art [6] in constructing cross-object (45 for training and 5 for testing) and cross-subject (9 subjects for training and 1 for testing) train-test sets. On GRAB, we evaluate on following MoCap object trajectories using the mean body shape humanoid. The OakInk dataset contains 1700 diverse objects of 32 categories with real-world scanned and generated object meshes. We split them into 1330 objects for training, 185 for validation, and 185 for testing. Train-test splits are conducted within categories, with train and test splits containing objects from all categories. Since no paired MoCap human motion or grasps exists for the OakInk dataset, we use an off-the-shelf grasp generator [86] to create pre-grasps.The OMOMO dataset contains 15 large objects (table lamps, monitors, etc.) with reconstructed mesh, and we pick 7 of them that have cleaner meshes. Due to the limited number of objects from OMOMO, we only test lifting on the objects used for training to verify that our pipeline can learn to move larger objects. On OMOMO and OakInk, we study vertical lifting (30cm) and holding (3s) as the trajectory for quantitative results.Implementation Details. Simulation is conducted in Isaac Gym [46] , where the policy is run at 30 Hz and the simulation at 60 Hz. For PULSE-X and PHC-X, each policy is a 6-layer MLP. For the grasping task, we employ a GRU [14] based recurrent policy and use a GRU with a latent dimension of 512, followed by a 3-layer MLP. We train Omnigrasp for three days collecting around 10 9 samples on a Nvidia A100 GPU. PHC-X and PULSE-X are trained once and frozen, which takes around 1.5 weeks and 3 days. Object density is 1000 kg/m 3 . The static and dynamic friction coefficients of the object and humanoid fingers are set to 1. For reference object trajectory, we use ϕ = 20 future frames sampled at 15Hz. For more details, please refer to Appendix C.For the object trajectory following, we report the position error Epos (mm), rotation error Erot (radian), and physics-based metrics such as acceleration error Eacc (mm/frame 2 ) and velocity error Evel (mm/frame). Following prior art in full-body simulated humanoid grasping [6] , we report the grasp success rate Succgrasp and Trajectory Targets Reached (TTR). The grasp success rate Succgrasp deems a grasp successful when the object is held for at least 0.5s in the physics simulation without dropping. TTR measures the ratio of the target position (< 12cm away from the target position) reached over all the time steps in the trajectory and is only measured on successful trajectories. To measure the complete trajectory success rate, we also report Succtraj, where a trajectory following is unsuccessful if, at any point in time, the object is > 25cm away from the reference. As motion is best seen in videos, please refer to supplement site for extended evaluation on trajectory following, unseen objects, and robustness. Unless otherwise specified, all policies are trained on their respective dataset training split, and we conduct cross-dataset experiments on GRAB and OakInk. All experiments are run 10 times and averaged as the simulator yields slightly different results for each run due to e.g. floating-point error. As full-body simulated humanoid grasping is a relatively new task with a limited number of baselines, we use Braun et [6] as our main comparison. We also implement AMP [57] and PHC [42] as baselines. We train AMP with a similar state and reward design (without using PULSE-X's latent space) and a task and discriminator reward weighting of 0.5 and 0.5. PHC refers to using an imitator for grasping, where we directly feed ground-truth kinematic body and finger motion to a pretrained imitator to grasp objects. Since PHC and PULSE-X require pre-training, we also include PPO-10B, which is trained using RL without PULSE-X for a month (∼10 billion samples).GRAB Dataset (50 objects). Since Braun et al. do not use randomly generated trajectories, we train Omnigrasp using two different settings for a fair comparison: one trained with MoCap object trajectories only, and one trained using synthetic trajectories only. From Table 1 , we can see that our method outperforms prior SOTA and baselines on all metrics, especially on success rate and trajectory following. Since all methods are simulationbased, we omit penetration/foot sliding metrics and report the precise trajectory tracking errors instead. Training directly using PPO without PULSE-X leads to a performance that significantly lags behind Omnigrasp, even though it has used similar aggregate samples (counting PHC-X and PULSE-X training). Compared to Braun et al., Omnigrasp achieves a high success rate on both object lifting and trajectory following. Directly using the motion imitator, PHC, yields a low success rate even when the ground-truth kinematic pose is provided, showing that the imitator's error (on average 30mm) is too large to overcome for precise object grasping. The body shape mismatch between MoCap and our simulated humanoid also contributes to this error. AMP leads to a low trajectory success rate, showing the importance of using a motion prior in the actions space. Omnigrasp can track the MoCap trajectory precisely with an average error of 28mm. Comparing training on MoCap trajectories and randomly generated ones, we can see that training on generated trajectories achieves better performance on success rate and position error, though worse on rotation error. This is due to our 3D trajectory generator offering good coverage on physically plausible 3D trajectories, but there is a gap between the randomly generated rotations and MoCap object rotation. This can be improved by introducing more rotation variation on the trajectory generator. The gap between trajectory Succtraj and grasp success Succgrasp shows that following the full trajectory is a much harder task than just grasping, and the object can be dropped during trajectory following. Qualitative results can be found in Fig. 3 .OakInk Dataset (1700 objects). On the OakInk dataset, we scale our grasping policy to >1000 objects and test our generalization to unseen objects. We also conduct cross-dataset experiments, where we train on the GRAB dataset and test on the OakInk dataset. Results are shown in Table 3 . We can see that 1272 out of the 1330 objects are trained to be picked up, and the whole lifting process also has a high success rate. We observe similar results on the test split. Upon inspection, the failed objects are usually either too large or too small for the humanoid to establish a grasp. The large number of objects also places a strain on the hard-negative mining process. The policy trained on both GRAB and OakInk shows the highest success rate, as on GRAB, there are bi-manual pre-grasps, and the policy learned to use both hands. Using both hands significantly improves the success rate on some larger objects, where the humanoid can scoop up the object with one hand and carry it with both. As OakInk only has pre-grasps using one hand, it cannot learn such a strategy. Surprisingly, training on only GRAB achieves a high success rate on OakInk, picking up more than 1000 objects without training on the dataset, showcasing the robustness of our grasping policy on unseen objects.OMOMO Dataset (7 objects). On the OMOMO dataset, we train a policy to show that our method can learn to pick up large objects. Table 2 shows that our method can successfully learn to pick up all the objects, including chairs and lamps. For larger objects, the pre-grasp guidance is essential for guiding the policy to learn bi-manual manipulation skills (as is shown in Fig 3 )Ablation. In this section, we study the effects of different components of our framework using the cross-object split of the GRAB dataset. Results are shown in Table 4 . First, we compare our method trained with (Row 6) or without (R1) PULSE-X's action space. Using the same reward and state design, we can see that using the universal motion prior significantly improves success rates. Upon inspection, using PULSE-X also yields human-like motion, while not using it leads to unnatural motion (see in supplement site). R2 vs. R6 shows that the pre-grasp guidance is essential in learning grasps that are stable for grasping objects, but without it, some objects can still be grasped successfully. The difference between R3 and R6 is whether to train using the dexterous AMASS dataset. R3 vs R6 shows that without training on a dataset that has diverse hand motion and full-body motion, the policy can learn to pick up objects (high grasp success rate), but struggles in trajectory following. This is expected as the motion prior probably lacks the motion of "holding the object while moving". R4 and R5 show that object position randomization and hard-negativing mining are crucial for learning robust and successful policies. Ablations on the object latent code, RNN policy, etc. can be found in the Appendix C.Analysis: Diverse Grasps. In Fig. 4 , we visualize the grasping strategy used by our method. We can see that based on the object shape, our policy uses a diverse set of grasping strategies to hold the object during the trajectory following. Based on the trajectory and object initial pose, Omnigrasp discovers different grasping poses for the same object, showcasing the advantage of using simulation and laws of physics for grasp generation. We also notice that for larger objects, our policy will resort to using two hands and a non-prehensile transport strategy. This behavior is learned from pre-grasps in GRAB, which utilize both hands for object manipulation.Analysis: Robustness and Potential for Sim-to-real Transfer. In Table 5 , we add uniform random noise [-0.01, 0.01] to both task observation (positions, object latent codes, etc.) and proprioception. A similar scale (0.01) of random noise is used in sim-to-real RL to tackle noisy input in real-world humanoids [28] . We see that Omnigrasp is relatively robust to input noise, even though it has not been trained with noisy input. Performance drop is more prominent in the acceleration and velocity metrics. Adding noise during training can further improve robustness. We do not claim that Omnigrasp is currently ready for real-world deployment, but we believe that a similar system design plus sim-to-real modifications (e.g. domain randomization, distilling into a vision-based policy) has the potential. We conduct more analysis on the robustness of our method with respect to initial object position, object weight, and object trajectories on our supplement site.6 Limitations, Conclusions, and Future WorkLimitations. While Omnigrasp demonstrates the feasibility of controlling a simulated humanoid to grasp diverse objects and hold them to follow diverse trajectories, many limitations remain. For example, though the 6DoF input is provided in the input and reward, the rotation error remains to be further improved. Omnigrasp has yet to support precise in-hand manipulations. The success rate on trajectory following can be improved, as objects can be dropped or not picked up. Another area of improvement is to achieve specific types of grasps on the object, which may require additional input such as desired contact points and grasp. Human-level dexterity, even in simulation, remains challenging. For visualization of failure cases, see supplement site.In conclusion, we present Omnigrasp, a humanoid controller capable of grasping > 1200 objects and following trajectories while holding the object. It generalizes to unseen objects of similar sizes, utilizes bi-manual skills, and supports picking up larger objects. We demonstrate that by using a pretrained universal humanoid motion representation, grasping can be learned using simplistic reward and state designs. Future work includes improving trajectory following success rate, improving grasping diversity, and supporting more object categories. Also, improving upon the humanoid motion representation is a promising direction. While we utilize a simple yet effective unified motion latent space, separating the motion representation for hands and body [3, 6] could lead to further improvements. Effective object representation is also an important future direction. How to formulate an object representation that does not rely on canonical object pose and generalizes to vision-based systems will be valuable to help the model generalize to more objects.Acknowledgement. Zhengyi Luo is supported by the Meta AI Mentorship (AIM) program. We evaluate PULSE-X and PHC-X on our constructed dexterous AMASS dataset.The metrics we use are the mean perjoint position error (mm) for both global Eg-mhpe and local Empjpe (root-relative) settings. We also report acceleration and velocity errors, similar to the object trajectory following the setting but averaged across all body joints. From Table 6 , we can see that PHC-X and PULSE-X achieve a high success rate on training data while maintaining a low per-joint error. Distilling from PHC-X to PULSE-X, we observe similar degradation in imitation performance as in PULSE, akin to the reconstruction error in training VAEs [32] .Since the simulator requires convex objects for simulation, we use the built-in v-hacd function to decompose the meshes into convex geometries. The parameters we use for decomposition can be found in Table 7 . To compute object latent code, we use 512-d BPS [58] by randomly sampling 512 points on a unit sphere and calculating their distances to points on the object mesh. As some object meshes have a large number of vertices, we also perform quadratic decimation on the mesh if it contains more than 50000 vertices.Early Termination. During training, we terminate the episode whenever the object is more than 12cm away from its desired reference trajectory at time step t: ∥ pobj t -p obj t ∥2 > 0.12. Contact Detection. As IsaacGym does not provide easy access to contact labels and only provides contact forces, there is no way of differentiating between contact with the table, humanoid body, or objects. Thus, we resort to a heuristic-based way to detect contact. Specifically, if the object is within 0.2m from the hands, has non-zero contact forces, and has a non-zero velocity, we deem it to have contact with the hands.Trajectory Generator. Randomly generated trajectories can be seen on our supplement site on the OakInk and OMOMO dataset, as there is no paired MoCap object motion for these datasets. We sample a random velocity and delta angle at each time step and aggregate the velocities to produce full trajectories. We bound the velocity of our randomly generated trajectories to be between [0, 2] m/s and bound the angles to be between [0, 1] radian. With a probability of 0.2, a sharp turn could happen where the angle is between [0, 2π]. As the trajectories can not be too high or low, we bound the z-direction translation to be between [0.1, 2.0]. For orientation, we sample a random ending orientation at the end of the trajectory and interpolate it between the object's initial trajectory to obtain a sequence of target rotations.Table 8 : Additional ablations: Object-latent refers to whether to provide the object shape latent code σ obj to the policy. RNN refers to either using an RNN-based policy or an MLP-based policy. Im-obs refers to whether to provide the policy with ground truth full-body pose qt+1 as input. In Table 8 , we provide additional ablations left out due to space limitations. Comparing Row 1 (R1) and R4, we can see that on the GRAB dataset cross-object test set, a policy trained without the object shape latent code σ obj can be on par with a policy with access to it. This is because the humanoid learned a general "grasping" for small objects, and the 5 testing objects do not deviate too much from these strategies. Also, upon inspection, R1 learns to rely on bi-manual manipulation and using two hands when it cannot pick it up with one hand, at which point the object shape no longer affects the grasping pose as much. As a result, R1 suffers a higher rotation error Erot. On the GRAB cross-subject test (44 objects), R1 has a trajectory success rate of Succtraj 84.2%, worse than R4's 90.5%. R2 vs. R4 shows that the RNN policy is more effective than the MLP-based policy, confirming our intuition that some form of memory is beneficial for a sequential task, such as grasping and omnidirectional trajectory following. R3 studies the scenario where we provide ground truth full-body pose qt to the policy at all times, similar to the setting in PhysHOI [78] (though without the contact graph). Results show that this strategy leads to worse performance, and also prevents us from training on objects that do not have paired MoCap full-body motion. This indicates that the contact graph is needed to imitate human-object interaction precisely. Omnigrasp provides a flexible interface to support learning and testing on novel objects without needing paired ground-truth full-body motion. In Table 9 , we break down the per-object success rate on the cross-object split of the GRAB dataset. Of the 5 novel objects, our model finds it hardest to pick up the toothpaste, which has an elongated surface.Upon inspection, we find that Omnigrasp will slip on the round edges of the toothpaste surface and fail to grasp the object. Compared to previous SOTA [6] ,Omnigrasp outperforms in all metrics and objects.One alternative way for reusing the motor skills from a motion imitator like PHC-X is to train a kinematic motion latent space to provide reference motion to drive PHC-X. Such a general-purpose kinematic latent space has been used in physics-based control for pose estimation [77] and animation [100] . However, few have been extended to include dexterous hands. These latent spaces, like HuMoR [64] , model motion transition using an encoder q ϕ (zt|q t , qt-1 ) and decoder p θ (q t |zt, qt-1 ) where qt is the pose at time step t and zt is the latent code. q ϕ and p θ are trained using supervised learning. The issue with applying such a latent space to simulated humanoid control is twofold:• The output qt of the VAE model, while representing natural human motion, does not model the PD-target (action) space required to maintain balance. This is shown in prior art [77, 100] , where an additional motion imitator is still needed to actuate the humanoid by imitating qt instead of using qt as policy output (PD-target).• q ϕ and p θ are optimized using MoCap data, whose qt values are computed using ground truth motion and finite difference (for velocities). As a result, q ϕ and p θ handle noisy humanoid states from simulation poorly. Thus, [77] runs the kinematic latent space in an open-loop auto-regressive fashion without feedback from physics simulation (e.g. using qt-1 from the previous time step's output rather than from simulation). The lack of feedback from physics simulation leads to floating and unnatural artifacts [77] , and the imitator heavily relies on residual force control to maintain stability.E Broader social impact.Our method can be used to create a realistic grasping policy for humanoids, generate animation, or synthesize stable grasps. While the state designs have access to privileged information, the overall system design methodology (plus sim-to-real transfer techniques such as domain randomization) has the potential to be transferred to a real humanoid robot. Thus, it has a potential positive social impact, as it can create content or help build the next generation of home robots.NeurIPS Paper ChecklistQuestion: Does the paper provide open access to the data and code, with sufficient instructions to faithfully reproduce the main experimental results, as described in supplemental material? Answer: [Yes]Justification: Code and instructions are included in the supplement.Guidelines:• The answer NA means that paper does not include experiments requiring code.• Please see the NeurIPS code and data submission guidelines (https://nips.cc/public/ guides/CodeSubmissionPolicy) for more details. • While we encourage the release of code and data, we understand that this might not be possible, so "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).• The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https://nips.cc/public/ guides/CodeSubmissionPolicy) for more details. • The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc. • The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only a subset of experiments are reproducible, they should state which ones are omitted from the script and why. • At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable). • Providing as much information as possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code is permitted. 
experimental setting/details: 
 Question: Does the paper specify all the training and test details (e.g., data splits, hyperparameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?Answer: [Yes]Justification: Experimental settings are explained in detail for training and testing in the main paper and supplement.Guidelines:• The answer NA means that the paper does not include experiments.• The experimental setting should be presented in the core of the paper to a level of detail that is necessary to appreciate the results and make sense of them. • The full details can be provided either with the code, in the appendix, or as supplemental material. Guidelines:• The answer NA means that the paper does not include experiments. 
 
 Appendix:  


Decision: The manuscript presents a novel pipeline, called Omnigrasp, that is able to learn controllers for humanoids with dexterous hands such that they can manipulate a wide range of objects along complex paths. By employing a universal motion representation for humanoids (called PULSE-X), the authors enhance training efficiency and scalability. Omnigrasp demonstrates state-of-the-art success rates in object manipulation tasks and strong generalization to new objects and trajectories.

The authors' responses were clear, concise, and offered valuable discussions. Overall, their comments reflect a strong grasp of the literature. Additionally, all reviewers had a positive opinion of the work. The authors also discussed about the limitations of their approach, and I expect that the text will be enhanced with the discussions/comments by the reviewers. For those reasons, I recommend acceptance (poster).

Reviews: review: paper_summary: paper_summary: This paper proposes an approach to learning a humanoid controller that can manipulate objects to follow trajectories. It first assembles a dataset of human bodies and hands motions, and learns a control policy from the state transitions in the dataset. Then, they distill this policy using a VAE to obtain an action decoder that models realistic human action distributions. After that, they use this distribution as the action space to learn an RL policy whose reward is based on object trajectory following. With this action space, the neural network policy can output realistic actions and avoid exploration difficulties. The authors demonstrate several impressive, yet natural and physically plausible motions for a simulated humanoid to grasp and move objects according to trajectories.
strength_weakness: strength_weakness: While I definitely think this paper is good, I believe there are several critical aspects that should be more carefully evaluated, either qualitatively or quantitatively. I will provide the summary comments in this section and write the specific questions that I would like answers to during the discussion phase in the next section.

First, I’m generally curious about the robustness of the proposed system. The object trajectory following policy takes a few inputs without noise from the simulator (joint positions, object latent code, proprioception). However, in reality, these quantities are far from perfect.

Second, this approach assumes the humanoid is similar enough to the mocap data. I agree this is a reasonable assumption. However, in reality, humanoid robots and their hands are usually not perfect replicas of humans. How similar do their morphologies need to be?

Regarding the learning approach, it first learns a policy to output actions given the human sequence data. Then it distills this policy network using VAE to learn the distributions as the action space. There should be an alternative approach that can serve as a simple baseline (details below). This is not discussed (or I missed the reference?).

The current reward contains several terms with different reward weights and hyper-parameters. I would not say this is a simple reward, especially without a concrete comparison to previous work.
questions: questions: Regarding the robustness of the system: How would the policy perform in noisy situations? For example, when the joint positions are not accurate (real robots will have imperfect joint encoders). And how accurate does the object mesh need to be?

How important is the morphology similarity between the humanoid and the hand? For example, do they need to have the same number of joints or links? I also observed even in the current system, it seems the simulated humanoid does not perfectly match human kinematics. Is this correct? If so, how do you bridge this gap?

Regarding the simple baseline alternatives:
* Instead of learning actions from human trajectory sequences between two timesteps, why not directly using a VAE to reconstruct human poses? This VAE will directly learning a distribution of human joint positions. Then in the RL policy training, you can map the policy output to natural human joint positions using this VAE.
* Even when one wants to learn the “actions” instead of “joint positions”, one could use a encoder-decoder structure (either VAE or vanilla auto-encoder) as the policy backbone and directly learn in the PULSE-X phase, instead of separating it into two stages.
I’m curious if the authors tried these alternatives before? Or does this comparison exist in the literature? Are they performing not well? It would be much helpful to analyze this problem or provide references in the text.

A more comprehensive discussion on the failure cases would be helpful. You show several videos of the failure cases, which I think is very helpful. But why do they fail? Is it because the objects themselves are quite difficult? Regarding this point, it would also be much helpful to have a per-object accuracy analysis.
limitations: limitations: The authors describe the limitations mainly as not performing dexterous in-hand manipulation. The authors could consider using recent learning-based dexterous in-hand manipulation work as the “mocap dataset” in your formulation and learn action distribution using it.

I think there is another limitation, which is that the current formulation does not demonstrate capability when the object needs to interact with the environment.

While I acknowledge that the above two points are out of scope and will not affect my assessment at all, they might be interesting future directions.
paper_summary: paper_summary: The paper introduces a method for controlling a simulated humanoid robot to grasp and move objects along a trajectory with the use of a dex hand, This approach enables the robot to handle diverse objects with diverse trajectories. The key contribution is a humanoid motion representation that enhances training efficiency and human-like manipulation skills and applies it to grasping tasks. The method achieves a reasonable success rate in completing object trajectories and generalizes well to unseen objects.
strength_weakness: strength_weakness: * Despite extensive ablation studies, the work lacks some important baselines, such as fully end-to-end RL with similar compute (R1 in ablation), considering that training PHC-X and PULSE-X takes half a month. Baselines utilizing human motion prior data in different ways, such as AMP or ASE, are also missing.
* More details about the dexterous hand should be included, given its significance over previous work on PHC. Comparisons with experiments using PHC but not PHC-X, such as using PHC for body control and raw action space for the hand, are needed. The ablation study compares with motion prior to training without Dex-AMASS, but it’s unclear how the hand joints are controlled, and more details are necessary.
* [Minor - Nothing significant]Though the authors claim the work can be extended to real robots in supplementary material, it seems unlikely due to the low simulation frequency (leading to low simulation fidelity), unrealistic robot methodology design, and the use of privileged information.
questions: questions: * Considering most of the human body motions and hand motions are randomly paired from different datasets, why not train the model separately (PHC for body motion and another model for hand motion)? What additional benefits does modeling them together provide?
limitations: limitations: The authors include a reasonable discussion of the limitation and no obvious potential negative societal impact needs to be discussed.
paper_summary: paper_summary: The paper introduces Omnigrasp, a method for controlling a simulated humanoid with dexterous hands to grasp and manipulate a wide variety of objects along complex trajectories. The authors leverage a universal humanoid motion representation to improve training efficiency and scalability. This method achieves state-of-the-art success rates in object manipulation tasks and generalizes well to unseen objects and trajectories. Key contributions include a dexterous motion representation, the allowance for simple state and reward designs for training, and high success rates in diverse object manipulation scenarios.
strength_weakness: strength_weakness: While the paper marks a significant advancement in humanoid dexterous grasping, some inherent flaws in the setting hinder its seamless transfer to real-world scenarios. I.e., some state variables, such as the object mesh, pose, and velocity, cannot be accurately accessed in the real world. This discrepancy between simulation and reality poses a challenge for the practical deployment of the proposed method.
questions: questions: 1. How do you plan to bridge the gap between simulation and real-world applications? Given that the input assumes access to the object pose, velocity, and mesh, which are impossible to obtain in the real world.
2. How do you envision the way your method could be adapted for, or at least benefit, downstream tasks? E.g., more fine-grained dexterous manipulation.
limitations: limitations: 1. The approach is validated only in a simulated environment, which may not capture all real-world complexities and variabilities.
2. The method assumes accurate state estimation for object meshes, poses, and velocities, which is challenging to achieve in real-world scenarios.
3. Fine-grained dexterous manipulation is yet to be achieved by this method.

Comments: title: Follow up to Comment by Reviewer gXSs
Thank you for your comments and response!
Keep my original recommendation
comment: Thank you for the discussion! 

PULSE is not compatible with the body of the SMPL-X humanoid, since it is trained using the SMPL humanoid. As the body shape for SMPL and SMPL-X is not the same, SMPL-X and SMPL humanoids have slightly different bone lengths and directions. Since the GRAB dataset we are using is in SMPL-X format, we initiated this work to support the SMPL-X humanoid. As more and more dataset is captured using SMPL-X instead of SMPL-H, we hope our pipelines can be future-proof and support SMPL-X based datasets. 

We would also like to note that raw hand actions are problematic as the controller can use non-human-like strategies in grasping (see Supplement Site, Training Without PULSE-X).  Using raw actions leads to hands being distorted due to their high degree-of-freedom and unbounded exploration. To provide motion prior to the hand's motion, either AMP or PULSE-like motion prior will be needed. Using PULSE for the body and then the raw-action space for the hand plus some form of hand prior would also be quite close to our method in terms of methodology and compute overhead (for training PHC and PULSE), and would support our story that using a strong motion prior one can enable learning diverse grasping and object trajectory following. We are actively exploring using separate hand and body priors, though it does not seem to be the bottleneck yet.  

Please feel free to ask us any additional questions!
Thank you for addressing the concerns. I'm keeping my original evaluation.

One additional question about separately controlling hand and body, though it might require output kinematic pose using PHC, it seems using PULSE (which if I understand it correctly takes latent command as input) + separate controller for hand should address most of the problems authors raised for using kinematic poses. Is there any specific challenge or problem with this?
The authors appreciate your suggestions and Accept recommendation. Please let us know if you have any additional questions!
Despite its current limitations in transferability and scalability, I believe this work can provide a foundation for future humanoid grasp learning methods. I will keep my original decision.