[Proposal] Inconsistent Grid Cloning

[shafeef901]

Proposal

The logic for grid cloning in grid_cloner.py (func: get_clone_transforms()) and in terrain_importer.py (func: _compute_env_origins_grid()) are different, consequently they give inconsistent values. Is there any particular reasoning/need for it?

Motivation

While initializing a new entity, I'd like to save some values from the environments during its initialization. However, during the initialization of an entity, the grid locations are based on the env_origins generated by grid_cloner.py but later overridden by the one in terrain_importer.py. This feature can be beneficial in avoiding recomputation of values that do not change in an environment, hence speeding up the training. In my case, these values were the poses of sampled points on a static object in the world frame. These values can be stored during initialization, and the distances from the robot base to these points could be updated as required.

Alternatives

I'm currently using a quadruped on a flat ground interacting with a static object. Hence, updating _compute_env_origins_grid() as follows would suffice to make the logic match:

def _compute_env_origins_grid(self, num_envs: int, env_spacing: float) -> torch.Tensor:
    """Compute the origins of the environments in a grid based on configured spacing."""
  
    num_rows = int(np.ceil(np.sqrt(num_envs)))  # Calculate number of rows based on total environments
    num_cols = int(np.ceil(num_envs / num_rows))  # Adjust number of columns based on rows
  
    env_origins = torch.zeros(num_envs, 3, device=self.device)
  
    for i in range(num_envs):
        row = i // num_cols
        col = i % num_cols
  
        # Calculate position with row-first approach
        x = -(row - (num_rows - 1) / 2) * env_spacing
        y = (col - (num_cols - 1) / 2) * env_spacing
  
        env_origins[i, 0] = x
        env_origins[i, 1] = y
        env_origins[i, 2] = 0.0
  
    return env_origins

Another possible solution would be to ensure that all entities are added to the scene only after the final grid configuration is computed, i.e., in this case, after _compute_env_origins_grid() is called. This would be a more permanent solution.

Checklist

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

Acceptance Criteria

• Update logic of _compute_env_origins_grid() in terrain_importer.py
• Add entities to the scene only after the final grid configuration is computed

[Mayankm96]

Hi @shafeef901 ,

There is no reason for this inconsistency. We wanted to avoid having a for loop. Would be happy to have a fix that makes it consistent without looping over all the environments. Maybe the indexing order in the meshgrid function does the trick?

[shafeef901]

Thank you for your response. As suggested, changing the indexing order to its default 'ij' and a slight change in the logic (negation in the row dimension) does the job as below:

def _compute_env_origins_grid(self, num_envs: int, env_spacing: float) -> torch.Tensor:
    """Compute the origins of the environments in a grid based on configured spacing"""
    # create tensor based on number of environments
    env_origins = torch.zeros(num_envs, 3, device=self.device)
    # create a grid of origins
    num_rows = int(np.ceil(np.sqrt(num_envs))) 
    num_cols = int(np.ceil(num_envs / num_rows))  
    ii, jj = torch.meshgrid(torch.arange(num_rows, device=self.device), torch.arange(num_cols, device=self.device), indexing="ij")
    env_origins[:, 0] = -(ii.flatten()[:num_envs] - (num_rows - 1) / 2) * env_spacing
    env_origins[:, 1] = (jj.flatten()[:num_envs] - (num_cols - 1) / 2) * env_spacing
    env_origins[:, 2] = 0.0
    return env_origins

This logic also looks identical to the previously proposed loop-based approach above.

[Mayankm96]

That's great. We should merge this to be consistent with Isaac Sim (until they also move to meshgrid logic). Could you please send an MR? Or should we handle this? :)

[shafeef901]

I have sent an MR. Kindly let me know if everything looks good :)

Thanks!