Task/universal schema for joints and hardware ids

[mustafab0]

Add typed schema for hardware components (HardwareComponent, HardwareType, JointState)

This PR addresses issue #1026
Rename "orchestrator" → "coordinator" throughout the codebase for clarity

[greptile-apps]

Greptile Summary

This PR introduces a typed schema for hardware components and joints, replacing the previous HardwareConfig with a more structured HardwareComponent dataclass, and renames "orchestrator" to "coordinator" throughout the codebase for clarity.

Key changes:

• Added dimos/control/components.py with typed schema: HardwareComponent, HardwareType enum, and JointState dataclass
• Replaced HardwareConfig with HardwareComponent that explicitly specifies joint names via joints list instead of generating them from joint_prefix
• Changed hardware_interface.py to use JointState dataclass instead of position/velocity/effort tuples
• Renamed OrchestratorState → CoordinatorState and ControlOrchestrator → ControlCoordinator across all files
• Updated all blueprints to use new schema with make_joints() helper function
• Added new E2E tests and interactive client for coordinator

Issues found:

• Minor docstring inconsistency in components.py:15 still references "ControlOrchestrator" instead of "ControlCoordinator"

Confidence Score: 4/5

• This PR is safe to merge with one minor docstring fix needed
• The refactoring is well-executed with consistent renaming across 12 files, proper typing with dataclasses, and comprehensive test coverage. The changes maintain backward compatibility in functionality while improving type safety. Only one minor docstring inconsistency was found that references the old "ControlOrchestrator" name.
• Pay attention to dimos/control/components.py - fix the docstring reference on line 15

Important Files Changed

Filename	Overview
dimos/control/components.py	New file defining typed schema (HardwareComponent, JointState, HardwareType) - has one docstring inconsistency referencing old name
dimos/control/coordinator.py	Renamed from orchestrator.py, updated to use HardwareComponent schema instead of HardwareConfig, maintains same functionality
dimos/control/blueprints.py	Updated all blueprint configs to use HardwareComponent instead of HardwareConfig, renamed all orchestrator references to coordinator
dimos/control/hardware_interface.py	Updated to use HardwareComponent and JointState dataclass, removed joint_prefix parameter in favor of component.joints list
dimos/control/task.py	Renamed OrchestratorState to CoordinatorState throughout, updated all documentation references

Sequence Diagram

sequenceDiagram
    participant User
    participant Coordinator as ControlCoordinator
    participant HWInterface as BackendHardwareInterface
    participant Component as HardwareComponent
    participant Backend as ManipulatorBackend
    participant Task as ControlTask
    participant TickLoop

    User->>Coordinator: Initialize with config
    Note over Coordinator: tick_rate, hardware list, tasks list
    
    User->>Coordinator: start()
    Coordinator->>Coordinator: _setup_from_config()
    
    loop For each HardwareComponent in config
        Coordinator->>Backend: _create_backend(component)
        Backend-->>Coordinator: ManipulatorBackend instance
        Coordinator->>Backend: connect()
        Backend-->>Coordinator: connection success
        Coordinator->>HWInterface: BackendHardwareInterface(backend, component)
        Note over HWInterface: Uses component.joints list<br/>instead of generating from prefix
        Coordinator->>Coordinator: add_hardware(backend, component)
        Coordinator->>Coordinator: Map joints to hardware_id
    end
    
    loop For each TaskConfig in config
        Coordinator->>Task: _create_task_from_config(cfg)
        Task-->>Coordinator: ControlTask instance
        Coordinator->>Coordinator: add_task(task)
    end
    
    Coordinator->>TickLoop: Create TickLoop
    Coordinator->>TickLoop: start()
    
    loop Every tick (100Hz)
        TickLoop->>HWInterface: read_state()
        HWInterface->>Backend: read_joint_positions/velocities/efforts()
        Backend-->>HWInterface: raw arrays
        HWInterface-->>TickLoop: dict[JointName, JointState]
        Note over HWInterface: Returns JointState dataclass<br/>with position, velocity, effort
        
        TickLoop->>TickLoop: Build CoordinatorState
        Note over TickLoop: Contains JointStateSnapshot,<br/>t_now, dt
        
        loop For each active task
            TickLoop->>Task: compute(CoordinatorState)
            Task-->>TickLoop: JointCommandOutput
        end
        
        TickLoop->>TickLoop: Arbitrate conflicts<br/>(per-joint, highest priority)
        
        loop For each hardware
            TickLoop->>HWInterface: write_command(commands, mode)
            HWInterface->>Backend: write_joint_positions/velocities()
            Backend-->>HWInterface: success
        end
        
        TickLoop->>Coordinator: publish JointState
    end
    
    User->>Coordinator: execute_trajectory(task_name, trajectory)
    Coordinator->>Task: execute(trajectory)
    Note over Task: Task becomes active,<br/>will be called in next tick
    
    User->>Coordinator: stop()
    Coordinator->>TickLoop: stop()
    loop For each hardware
        Coordinator->>HWInterface: disconnect()
        HWInterface->>Backend: disconnect()
    end

Loading

[greptile-apps]

_{12 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[spomichter]

thanks

[spomichter]

This seems pretty horrible how can you possibly assume people will conform to doing this _left or _right thing

[mustafab0]

This is a client-side hack for convenience/testing. The coordinator itself will have explicit task-to-joint mappings.