[Bug] (Minor) IMU type checking failing

[Z3ZEL]

Description

Issue description

-> Minimal reproducible example

from isaacsim.sensors.experimental.physics import IMU


def create_imu() -> IMU:

    imu = IMU.create("/World/imu")

    return imu


def main() -> None:
    """Create an IMU sensor in the simulation."""
    imu = create_imu()
    print(f"Created IMU sensor at: {imu.paths}")

Then when launching a type-checker (ty in my case):

return imu : Return type does not match returned value: expected IMU, found _PhysicsSensorAuthoring

For typings, I used generated types from your codebase using pybind11

The cause

It should be of type IMU, as it is literally a factory for this IMU object. Moreover, if _PhysicsSensorAuthoring is indeed the right type to use to manipulate this sensor, its name should not start with an underscore.

This bug comes from the fact that IMU does not implement its inherited create() method from _PhysicsSensorAuthoring.

Quick fix

A quick fix could be to simply re-implement the static method in the IMU object (not tested) or remove the privacy prefix of PhysicsSensorAuthoring.

In any case, this is a minor bug since it only concerns compliance with ty. I guess no type checker is used in the IsaacSim codebase, as the current architecture is not friendly AT ALL with Python types.

JFYI, the Python typing system was released 10 years ago and is widely used by many developers. Having native IsaacSim Python stubs in the codebase would not be purely cosmetic, just saying...

Isaac Sim version

6.0.1

Operating System (OS)

Ubuntu 24.04

GPU Name

RTX 1000 PRO Blackwell

GPU Driver and CUDA versions

Driver Version: 580.167.08 CUDA Version: 13.0

Logs

No response

Additional information

No response

[hawkeyeking]

Thank you for reporting this. We were able to reproduce the type-checking issue and confirm that runtime construction correctly returns an IMU.

The inherited create() method currently declares _PhysicsSensorAuthoring as its return type. Updating it to use typing.Self resolves the incorrect inference without changing runtime behavior. We will take a look at the fix in PR #777.

Appreciate the clear reproduction and suggested direction!