Skip to content

Conversation

@sanjaypokkali
Copy link

lerobot hardware module

@sanjaypokkali sanjaypokkali requested a review from a team January 16, 2026 03:11
@sanjaypokkali sanjaypokkali changed the base branch from main to dev January 16, 2026 03:11
@greptile-apps
Copy link

greptile-apps bot commented Jan 16, 2026

Greptile Summary

  • Integrates SO101 robotic arm with LeRobot framework by adding comprehensive driver implementation, URDF models with two calibration variants, and complete 3D asset pipeline including OnShape CAD metadata and STL mesh files
  • Adds LeRobot dependencies to pyproject.toml manipulation extras to support FeetechMotors hardware integration and kinematics capabilities required for SO101 arm control
  • Creates kinematics wrapper that bridges LeRobot conventions with existing codebase patterns, implementing forward/inverse kinematics, Jacobian computation, and 5-DOF orientation constraints for the manipulator

Important Files Changed

Filename Overview
dimos/hardware/manipulators/so101/so101_wrapper.py New comprehensive SDK wrapper for SO101 arm using LeRobot's FeetechMotorsBus; requires review of hard-coded calibration values and error handling
dimos/hardware/manipulators/so101/so101_driver.py New driver implementation with velocity-to-position control conversion; SDK initialization doesn't pass configuration parameters
dimos/hardware/manipulators/so101/lerobot_kinematics.py New kinematics integration with LeRobot framework; numerical Jacobian approach and quaternion conversions need validation
dimos/hardware/manipulators/so101/urdf/assets/*.stl Multiple empty STL mesh files that will cause critical failures in robot visualization and collision detection

Confidence score: 2/5

  • This PR requires careful review due to multiple empty STL files that will break robot visualization and simulation systems
  • Score reflects significant issues with asset files, hard-coded calibration values, missing error handling, and incomplete SDK integration that could cause runtime failures
  • Pay close attention to all STL files in the assets directory and the wrapper/driver implementation files for proper configuration handling

Sequence Diagram

sequenceDiagram
    participant User
    participant SO101Driver
    participant BaseManipulatorDriver
    participant SDK as SO101SDKWrapper
    participant FeetechBus as FeetechMotorsBus
    participant LerobotKin as LerobotKinematics
    participant Motors as STS3215Motors

    User->>SO101Driver: "set_joint_positions(positions)"
    SO101Driver->>BaseManipulatorDriver: "_process_command(position_cmd)"
    BaseManipulatorDriver->>SDK: "set_joint_positions(positions)"
    SDK->>SDK: "apply joint offsets"
    SDK->>SDK: "convert radians to degrees"
    SDK->>FeetechBus: "sync_write('Goal_Position', cmd)"
    FeetechBus->>Motors: "send position commands"
    Motors-->>FeetechBus: "acknowledge"
    FeetechBus-->>SDK: "command sent"
    SDK-->>BaseManipulatorDriver: "success"
    BaseManipulatorDriver-->>SO101Driver: "command processed"
    SO101Driver-->>User: "movement initiated"

    loop "State Feedback (100Hz)"
        BaseManipulatorDriver->>SDK: "get_joint_positions()"
        SDK->>FeetechBus: "sync_read('Present_Position')"
        FeetechBus->>Motors: "read positions"
        Motors-->>FeetechBus: "return positions"
        FeetechBus-->>SDK: "joint positions"
        SDK->>SDK: "apply joint offsets"
        SDK-->>BaseManipulatorDriver: "joint positions"
        BaseManipulatorDriver->>BaseManipulatorDriver: "publish joint_state"
    end

    User->>SO101Driver: "set_cartesian_position(pose)"
    SO101Driver->>SDK: "set_cartesian_position(pose)"
    SDK->>LerobotKinematics: "ik(current_joints, target_pos, target_quat)"
    LerobotKinematics->>LerobotKinematics: "iterative jacobian-based IK"
    LerobotKinematics-->>SDK: "joint_solution"
    SDK->>SDK: "convert to degrees"
    SDK->>FeetechBus: "sync_write('Goal_Position', joint_cmd)"
    FeetechBus->>Motors: "send joint commands"
    Motors-->>SDK: "cartesian motion executed"
    SDK-->>SO101Driver: "success"
    SO101Driver-->>User: "cartesian movement complete"
Loading

Copy link

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional Comments (1)

  1. dimos/hardware/manipulators/so101/urdf/assets/motor_holder_so101_base_v1.stl, line 1 (link)

    logic: STL file appears to be empty or corrupted - no binary mesh data is present. This will cause URDF loading failures when the robot model is instantiated.

43 files reviewed, 9 comments

Edit Code Review Agent Settings | Greptile

@sanjaypokkali sanjaypokkali marked this pull request as draft January 16, 2026 07:13
@spomichter
Copy link
Contributor

@mustafab0

@sanjaypokkali sanjaypokkali marked this pull request as ready for review January 16, 2026 13:55
Copy link

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional Comments (8)

  1. dimos/hardware/manipulators/so101/urdf/assets/motor_holder_so101_wrist_v1.stl, line 1 (link)

    logic: Empty STL file will cause robot visualization and collision detection failures. STL files must contain valid 3D mesh data for URDF parsing and physics simulation to work correctly.

  2. dimos/hardware/manipulators/so101/urdf/assets/motor_holder_so101_base_v1.stl, line 1 (link)

    logic: Empty STL file will cause robot visualization and collision detection failures. STL files must contain valid 3D mesh data for URDF models to function properly. Was this file supposed to contain 3D mesh data, or is there a separate process to generate it?

  3. dimos/hardware/manipulators/so101/urdf/assets/base_motor_holder_so101_v1.stl, line 1 (link)

    logic: Empty STL file will cause robot visualization and collision detection failures. STL files must contain binary mesh data for the base motor holder component.

  4. dimos/hardware/manipulators/so101/urdf/assets/wrist_roll_pitch_so101_v2.stl, line 1 (link)

    logic: Empty STL file will cause visualization and collision detection failures when robot model is loaded. STL files must contain valid mesh data with vertices and triangular faces.

  5. dimos/hardware/manipulators/so101/urdf/assets/upper_arm_so101_v1.stl, line 1 (link)

    logic: Empty STL file will break robot visualization and collision detection

  6. dimos/hardware/manipulators/so101/urdf/assets/moving_jaw_so101_v1.stl, line 1 (link)

    logic: Empty STL file will cause robot visualization and collision detection to fail completely. The gripper jaw geometry is essential for URDF loading and physics simulation.

  7. dimos/hardware/manipulators/so101/urdf/assets/under_arm_so101_v1.stl, line 1 (link)

    logic: Empty STL file will cause robot visualization and collision detection to fail. STL files must contain binary 3D mesh data for URDF models to render properly in RViz, Gazebo, or other robotics simulators.

  8. dimos/hardware/manipulators/so101/urdf/assets/wrist_roll_follower_so101_v1.stl, line 1 (link)

    logic: Empty STL file will cause robot visualization and simulation failures. STL files must contain valid 3D mesh data for URDF parsers and robotics frameworks to function properly.

35 files reviewed, 20 comments

Edit Code Review Agent Settings | Greptile

if self._last_velocity_time > 0:
dt = current_time - self._last_velocity_time
else:
dt = 1.0 / self.control_rate # Use nominal period for first command
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

logic: Control rate accessed without validation - could cause division by zero if not set

<default class="sts3215">
<geom contype="0" conaffinity="0"/>
<joint damping="0.60" frictionloss="0.052" armature="0.028"/>
<!-- For lerobot this are not exactly the motor params as the Kp and Kd not map 1-to-1 thus motor idendification with lerobot Kp=16 and Kd=32 should actually be done -->
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

syntax: 'idendification' should be 'identification'

Suggested change
<!-- For lerobot this are not exactly the motor params as the Kp and Kd not map 1-to-1 thus motor idendification with lerobot Kp=16 and Kd=32 should actually be done -->
<!-- For lerobot these are not exactly the motor params as the Kp and Kd not map 1-to-1 thus motor identification with lerobot Kp=16 and Kd=32 should actually be done -->


<!-- Gripper frame (dummy link + fixed joint) -->
<link name="gripper_frame_link">
<origin xyz="0 0 0" rpy="0 -0 0"/>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style: Redundant origin tag inside link definition - URDF links don't need origin tags at the link level, only within visual/collision/inertial elements

Suggested change
<origin xyz="0 0 0" rpy="0 -0 0"/>
<link name="gripper_frame_link">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0"/>
<mass value="1e-9"/>
<inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0"/>
</inertial>
</link>

<origin xyz="-0.0079 -0.000218121 -0.0981274" rpy="0 3.14159 0"/>
<parent link="gripper_link"/>
<child link="gripper_frame_link"/>
<axis xyz="0 0 0"/>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style: Axis specification unnecessary for fixed joints - fixed joints don't rotate so axis is ignored

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Comment on lines +290 to +297
<link name="gripper_frame_link">
<origin xyz="0 0 0" rpy="0 -0 0"/>
<inertial>
<origin xyz="0 0 0" rpy="0 0 0"/>
<mass value="1e-9"/>
<inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0"/>
</inertial>
</link>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

syntax: Gripper frame link has origin tag outside inertial block - this should be moved inside inertial or removed entirely

Suggested change
<link name="gripper_frame_link">
<origin xyz="0 0 0" rpy="0 -0 0"/>
<inertial>
<origin xyz="0 0 0" rpy="0 0 0"/>
<mass value="1e-9"/>
<inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0"/>
</inertial>
</link>
<link name="gripper_frame_link">
<inertial>
<origin xyz="0 0 0" rpy="0 0 0"/>
<mass value="1e-9"/>
<inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0"/>
</inertial>
</link>

@sanjaypokkali sanjaypokkali changed the title [WIP] Lerobot integration bounty Lerobot integration bounty Jan 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants