habitat-sim icon indicating copy to clipboard operation
habitat-sim copied to clipboard

[WIP] Robotics Coordinate System Migration

Open aclegg3 opened this issue 10 months ago • 0 comments

Motivation and Context

This PR represents a prototype of converting the default Habitat coordinate system to robotics conventions (Z-up, X-forward).

To make this work several systems needed to be changed:

  • PathFinder: Recast Navigation is hard-coded to a local coordinate system with Y-up. To accommodate this requirement, we convert points between the coordinate systems in the wrapper layer. Part of this refactor is also to remove Eigen from the wrapper layer in preparation for parallel refactor (#2301).
  • CoordinateFrame and ESP_UP/ESP_FRONT logic and defaults changed to fix a bug and correctly represent the new defaults.
  • gravity vector is now -Z in the default config
  • All configs for stages and objects should correctly represent the local up and front vectors in their own local asset coordindate system. This is now correctly converted to the new coordinate system.
  • All Habitat custom URDFs previously had a default 1.56 radian rotation around X in the rpy. These should now be removed. Default URDF coordinate system will import correctly now.
  • Added some test axis assets for debugging

TODO:

  • needs many adaptations in the code where Y-up is hardcoded.
  • needs many changes in the asset configs we host

How Has This Been Tested

Added examples/coordinate_system.py to test this migration.

  • Changed hab_spot_arm.urdf to remove the base rotation rpy
  • Changed the stage_config.json to correctly identify the local up and front.
  • Apply a rotation to the camera (default cameras are in graphics convention with Y-up and need to be rotated).

Example. Note the colored axis (RGB == XYZ) indicating that we're now in robotics conventions!: tmpa8rh9jur

Types of changes

  • [x] Docs change / refactoring / dependency upgrade
  • [ ] Bug fix (non-breaking change which fixes an issue)
  • [x] New feature (non-breaking change which adds functionality)
  • [x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • [x] My code follows the code style of this project.
  • [x] My change requires a change to the documentation.
  • [ ] I have updated the documentation accordingly.
  • [x] I have read the CONTRIBUTING document.
  • [x] I have completed my CLA (see CONTRIBUTING)
  • [ ] I have added tests to cover my changes.
  • [ ] All new and existing tests passed.

aclegg3 avatar Dec 21 '24 00:12 aclegg3