Task/Simplify SDK wrapper: Add backend registry with auto-discovery

[mustafab0]

Simplify SDK wrapper: Add backend registry with auto-discovery and unified hardware schema

Backend Registry with Auto-Discovery: Added registry.py that auto-discovers manipulator backends using pkgutil.iter_modules(). Adding a new robot backend now only requires creating a subpackage with a register() function - no need to edit the coordinator.

Consistent Unit Conversion Pattern: Standardized unit conversion constants at module level (MM_TO_M, RAD_TO_MILLIDEG, etc.) instead of inline magic numbers or static methods.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR introduces a plugin-style backend registry with automatic discovery, eliminating the need to manually update coordinator code when adding new robot backends. The refactoring also standardizes unit conversion patterns across backends and renames "orchestrator" to "coordinator" throughout the codebase.

Key Changes:

• Added registry.py with auto-discovery using pkgutil.iter_modules() to find and register manipulator backends
• Standardized backend constructors to use address parameter (instead of ip/can_port) and accept **kwargs for compatibility
• Replaced inline unit conversions with module-level constants (MM_TO_M, RAD_TO_MILLIDEG, etc.)
• Introduced unified HardwareComponent schema with explicit joint name lists
• Renamed all "orchestrator" references to "coordinator" for consistency
• Updated all backends to provide a register() function for auto-registration

Issues Found:

• Minor typo in components.py docstring ("ControlCoordnator")
• Backend import failures are logged at debug level, which may hide configuration issues
• Some validation logic could be more explicit

The registry pattern is well-designed and significantly simplifies adding new backends. The unit conversion standardization improves code maintainability.

Confidence Score: 4/5

• This PR is safe to merge with careful testing of backend discovery and hardware initialization.
• The refactoring is well-structured with comprehensive test coverage (unit tests updated, e2e tests added). The registry auto-discovery pattern is clean and follows Python conventions. Score reflects the architectural change scope - while the implementation is solid, there's inherent risk in refactoring core infrastructure like backend loading and renaming throughout the codebase. The changes are backward-incompatible (constructor parameter changes from ip/can_port to address), requiring coordination with any external code.
• Pay close attention to dimos/hardware/manipulators/xarm/backend.py due to constructor parameter changes and dimos/hardware/manipulators/registry.py for the auto-discovery mechanism.

Important Files Changed

Filename	Overview
dimos/hardware/manipulators/registry.py	New auto-discovery registry for manipulator backends using pkgutil to find and register backends dynamically
dimos/hardware/manipulators/xarm/backend.py	Changed constructor parameter from ip to address, standardized unit conversions to module-level constants, added register() function
dimos/control/coordinator.py	New coordinator module using registry for backend creation, replaces orchestrator with renamed module
dimos/control/components.py	New unified hardware component schema with type aliases and make_joints helper function
dimos/control/hardware_interface.py	Updated to use HardwareComponent config, changed from joint prefix generation to explicit joint names, returns JointState objects

Sequence Diagram

sequenceDiagram
    participant User
    participant Coordinator as ControlCoordinator
    participant Registry as BackendRegistry
    participant PkgUtil as pkgutil
    participant Backend as XArmBackend

    User->>Coordinator: start()
    Coordinator->>Coordinator: _setup_from_config()
    Coordinator->>Coordinator: _create_backend(component)
    Coordinator->>Registry: backend_registry.create("xarm", ...)
    
    alt First call - discovery needed
        Registry->>Registry: _discover()
        Registry->>PkgUtil: iter_modules(dimos.hardware.manipulators)
        PkgUtil-->>Registry: ["mock", "piper", "xarm", ...]
        
        loop For each subpackage
            Registry->>Registry: importlib.import_module("dimos.hardware.manipulators.xarm.backend")
            Registry->>Backend: hasattr(module, "register")
            Backend-->>Registry: True
            Registry->>Backend: module.register(self)
            Backend->>Registry: registry.register("xarm", XArmBackend)
        end
        
        Registry->>Registry: _discovered = True
    end
    
    Registry->>Backend: XArmBackend(**kwargs)
    Backend-->>Registry: backend instance
    Registry-->>Coordinator: backend instance
    
    Coordinator->>Backend: backend.connect()
    Backend-->>Coordinator: True
    Coordinator->>Coordinator: add_hardware(backend, component)

Loading

[greptile-apps]

_{3 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[spomichter]

Where is this used and what is difference between manipulator and gripper.

[mustafab0]

Grippers are parallel jaw grippers, dextrous hands etc. manipulators are just the 6-dof arms.

I have kept the current xarm gripper integrated with the manipulator for now. Can be separated later.

[spomichter]

By default shouldnt we build this from URDF automatically?

[mustafab0]

Yes by default.

As a feature, the URDF should be the only source of truth for the robot config. A user should only need to modify their existing robot_descriptions and the control module, the manipulation module and the sim module would use as a source.

[spomichter]

Super hard to read since 80% of the diff is just the name changes

[spomichter]

Need to in future actually PR the stuff relevant to the PR not unrelated sematnic changes

[mustafab0]

Super hard to read since 80% of the diff is just the name changes

Filter commits of new PR from
commit_id: e9683cf
to
commit_id: 1886b60

you can skip the semantic changes and only see the actual code change.