[Question] Unexpected joints behavior when deploy policy on real unitree GO1

[Pansamic]

Question

I'm trying to deploy unitree-go1-flat policy on real robot but the legs kicked and shaked suddenly and the robot entered power protection.

Deployment Details

I noticed that the model input is:

+----------------------------------------------------------+
| Active Observation Terms in Group: 'policy' (shape: (48,)) |
+-----------+--------------------------------+-------------+
|   Index   | Name                           |    Shape    |
+-----------+--------------------------------+-------------+
|     0     | base_lin_vel                   |     (3,)    |
|     1     | base_ang_vel                   |     (3,)    |
|     2     | projected_gravity              |     (3,)    |
|     3     | velocity_commands              |     (3,)    |
|     4     | joint_pos                      |    (12,)    |
|     5     | joint_vel                      |    (12,)    |
|     6     | actions                        |    (12,)    |
+-----------+--------------------------------+-------------+

The output is:

+------------------------------------+
|  Active Action Terms (shape: 12)   |
+--------+-------------+-------------+
| Index  | Name        |   Dimension |
+--------+-------------+-------------+
|   0    | joint_pos   |          12 |
+--------+-------------+-------------+

For input: base_lin_vel, base_ang_vel, projected_gravity are calculated by my pose estimation system. And I've check the data. Numbers seems reasonable and correct. velocity_commands are set to (0,0,0). joint_pos and joint_vel are from unitree legged sdk. Both of them are the original data from unitree legged sdk. actions is the last model output.

For output: joint_pos is multiplied by 0.25 and is added default motor position.

Model runtime: Use onnxruntime c++. I've tested several input data and the output is equal to pytorch runtime.

[Mayankm96]

Did you make sure the joint ordering is correct?

[Pansamic]

I'm not sure. I didn't find the motor order description in code. I found that the unitree GO1 velocity tracking task is from walk-these-ways so I use the motor order of that repo. FL_hip,FR_hip,RL_hip,RR_hip,FL_thigh,FR_thigh,RL_thigh,RR_thigh, FL_calf,FR_calf,RL_calf,RR_calf

[Pansamic]

I found the joint_pos observation function is in source/extensions/omni.isaac.orbit/omni/isaac/orbit/envs/mdp/observations.py

def joint_pos_rel(env: BaseEnv, asset_cfg: SceneEntityCfg = SceneEntityCfg("robot")) -> torch.Tensor:
    """The joint positions of the asset w.r.t. the default joint positions.

    NOTE: Only the joints configured in :attr:`asset_cfg.joint_ids` will have their positions returned.
    """
    # extract the used quantities (to enable type-hinting)
    asset: Articulation = env.scene[asset_cfg.name]
    return asset.data.joint_pos[:, asset_cfg.joint_ids] - asset.data.default_joint_pos[:, asset_cfg.joint_ids]

But this function doesn't show me the motor order.

[Mayankm96]

You can get the order as:

if (asset_cfg.joint_ids == slice(None)):
    print(asset.joint_names)
else:
    print(asset_cfg.joint_names)

This ordering will be different from Isaac Gym as mentioned here: https://docs.omniverse.nvidia.com/isaacsim/latest/isaac_gym_tutorials/tutorial_gym_transfer_policy.html#joint-order

[Pansamic]

Thanks, but it prints

['FL_hip_joint', 'FR_hip_joint', 'RL_hip_joint', 'RR_hip_joint', 'FL_thigh_joint', 'FR_thigh_joint', 'RL_thigh_joint', 'RR_thigh_joint', 'FL_calf_joint', 'FR_calf_joint', 'RL_calf_joint', 'RR_calf_joint']

which is the same with the order i'm using. So it seems not the problem of motor order. What should I check next?

[Mayankm96]

Interesting. Isaac Gym does depth-first parsing while Isaac Sim does breadth-first parsing. These shouldn't be the same unless walk-these-ways manually changes the ordering everywhere (observations, actions). I am unfamiliar with their code to comment on this part, unfortunately.

We have been deploying RL policies for ANYmal with Orbit and haven't seen any unexpected issues. The main things that diverge from the legged-gym code were:

• Ordering of joints: BFS instead of DFS
• Ordering of height-scans: "XY" instead of "YX" (explained here)

[Pansamic]

Thanks for your sharing. I find motor order of legged gym is actually different from orbit.

About this issue, I suspect that there's something wrong with unitree GO1 actuator net model. In this repo, it use actuator net for unitree GO1 but it seems not to work well with the RL policy. I replaced actuator net with PD model and trained a new policy. My real GO1 robot won't unexpectedly kick and shake its legs until power protection and it can stand on the ground with velocity_commands is all zero.