Generalized manipulator driver

[mustafab0]

Introduces component-based architecture for manipulator drivers enabling rapid integration of new robot arms.

• BaseManipulatorSDK: Abstract interface for vendor SDK wrappers (standardized units: radians, meters)
• BaseManipulatorDriver: 2-thread architecture (100Hz control loop, 10Hz monitor) with DIMOS Module integration
• Standard Components: Reusable Motion, Servo, Status components with @component_api decorator for auto RPC exposure
• Implementations: XArm and Piper drivers using new architecture (~50 lines each)
• Documentation: How-to README and architecture reference

Adding new arms now requires only an SDK wrapper + thin driver assembly.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[spomichter]

@greptile

[greptile-apps]

Greptile Overview

Greptile Summary

Introduces a well-designed component-based architecture for manipulator drivers, enabling rapid integration of new robot arms with minimal code (~50 lines per driver).

Key Changes:

• BaseManipulatorSDK: Abstract interface for vendor SDK wrappers with standardized units (radians, meters)
• BaseManipulatorDriver: 2-thread architecture (100Hz control loop, 10Hz monitor) with automatic @component_api RPC exposure
• Standard Components: Reusable Motion, Servo, and Status components that work across all manipulators
• XArm & Piper Implementations: Thin driver assemblies demonstrating the architecture
• Supporting Infrastructure: New message types (JointState, RobotState, WrenchStamped), trajectory controller, and Cartesian motion controller

Architecture Highlights:

• Thread-safe SharedState for cross-thread communication
• @component_api decorator for automatic RPC method registration
• Comprehensive validation utilities for joint limits, velocities, and trajectories
• MockSDK for hardware-independent unit testing

Minor Issues Found:

• Unused expression in trajectory validation (line 189 in validators.py)
• Redundant condition in XArm servo check (line 270 in xarm_wrapper.py)

Confidence Score: 4/5

• This PR is safe to merge with minor non-critical issues that don't affect functionality.
• Well-architected component-based framework with comprehensive tests. Two minor code quality issues found: an unused expression in validators.py and a redundant condition in xarm_wrapper.py. Neither affects runtime behavior or safety.
• Minor attention needed for dimos/hardware/manipulators/base/utils/validators.py (unused expression) and dimos/hardware/manipulators/xarm/xarm_wrapper.py (redundant condition).

Important Files Changed

File Analysis

Filename	Score	Overview
dimos/hardware/manipulators/base/driver.py	5/5	New base driver class with 2-thread architecture (100Hz control loop, 10Hz monitor), component management, and RPC auto-exposure. Well-structured with proper thread safety.
dimos/hardware/manipulators/base/sdk_interface.py	5/5	Abstract SDK interface defining standardized units (radians, meters) and required methods for all manipulator wrappers. Clean abstraction layer.
dimos/hardware/manipulators/base/components/motion.py	5/5	Standard motion component with joint/cartesian control, trajectory execution, and validation. Uses @component_api decorator for RPC exposure.
dimos/hardware/manipulators/base/components/servo.py	5/5	Servo control component handling enable/disable, control modes, emergency stop, and error recovery. Properly tracks state transitions.
dimos/hardware/manipulators/base/utils/validators.py	4/5	Validation utilities for joint limits, velocities, and trajectories. Contains unused expression on line 189 (velocity computed but not used).
dimos/hardware/manipulators/xarm/xarm_wrapper.py	4/5	XArm SDK wrapper with degree-to-radian conversion. Contains redundant condition in are_servos_enabled() on line 270.
dimos/hardware/manipulators/xarm/xarm_driver.py	5/5	Thin XArm driver (~50 lines) assembling SDK wrapper and standard components. Clean implementation using new architecture.
dimos/hardware/manipulators/piper/piper_driver.py	5/5	Piper driver with velocity-to-position integration override. Properly handles CAN-based control and servo auto-enable on start.
dimos/hardware/manipulators/base/tests/test_driver_unit.py	5/5	Comprehensive unit tests for BaseManipulatorDriver using MockSDK. Tests cover connection, motion control, servo control, threading, and edge cases.

Sequence Diagram

sequenceDiagram
    participant App as Application
    participant Driver as BaseManipulatorDriver
    participant Components as Standard Components
    participant SDK as SDK Wrapper
    participant HW as Hardware

    App->>Driver: start()
    Driver->>Driver: Create control & monitor threads
    Driver->>SDK: connect(config)
    SDK->>HW: Connect via IP/CAN

    loop Control Loop (100Hz)
        Driver->>Driver: Process command queue
        Driver->>SDK: set_joint_positions()
        SDK->>HW: Send command
        Driver->>SDK: get_joint_positions()
        SDK->>HW: Read state
        Driver->>Driver: Publish JointState
    end

    loop Monitor Loop (10Hz)
        Driver->>SDK: get_robot_state()
        SDK->>HW: Read status
        Driver->>Driver: Publish RobotState
    end

    App->>Driver: enable_servo() [RPC]
    Driver->>Components: StandardServoComponent.enable_servo()
    Components->>SDK: enable_servos()
    SDK->>HW: Enable motors
    SDK-->>Components: success
    Components-->>Driver: {success: true}
    Driver-->>App: Result

    App->>Driver: move_joint(positions) [RPC]
    Driver->>Components: StandardMotionComponent.move_joint()
    Components->>Driver: Queue Command
    Driver->>SDK: set_joint_positions()
    SDK->>HW: Send trajectory
    SDK-->>App: Command queued

Loading

[greptile-apps]

_{99 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[mustafab0]

@greptile

[greptile-apps]

_{99 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[paul-nechifor]

It doesn't look like this is used anywhere. Same for the piper one.

[paul-nechifor]

Many other components aren't used. Are they the old ones? Should they be deleted?

[mustafab0]

These are for gripper controls, they need to be developed and tested further.

[paul-nechifor]

I've skimmed through and left some comments.

[paul-nechifor]

@mustafab0 Can you please merge #874 into this PR? I added the autofixes generated by the currently commented-out ruff rules. (I can't uncomment them yet until I fix the underlying issues first.)

[mustafab0]

@mustafab0 Can you please merge #874 into this PR? I added the autofixes generated by the currently commented-out ruff rules. (I can't uncomment them yet until I fix the underlying issues first.)

Done

[ruthwikdasyam]

Passed all 12 checks. Control for piper, xarm6, xarm7 is tested with MuJoCo and hardware, and is working well. Base components are well written to produce driver stack for any new arm. Trajectory control and Cartesian control are verified with hardware - using arm specific drivers.