Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Design Change] Enable Bringing Your Own Control Scheme #462

Open
MichaelrMentele opened this issue Oct 4, 2024 · 2 comments
Open

[Design Change] Enable Bringing Your Own Control Scheme #462

MichaelrMentele opened this issue Oct 4, 2024 · 2 comments

Comments

@MichaelrMentele
Copy link

A key limitation of

is that it is tightly coupled to taking in a leader robot when all it really needs to take in is a publisher that provides target joint angles.

The downside of tight coupling to a leader robot is that it precludes infinite other control schemes that could provide those target joint angles, also the articulation and robot are a tightly coupled pair, we may as well package them as such for the robot.

Proposal

Instead of taking in a "Leader" take in a ArticulationProvider interface. This change should be invisible to the codebase since this is done by hydra .yaml anyway

Old ManipulatorRobot interface:

    robot = ManipulatorRobot(
        robot_type="koch",
        calibration_dir=".cache/calibration/koch",
        leader_arms=leader_arms,  # But I want to use a ps4 controller or ultraleap or XYZ
        follower_arms=follower_arms,
    )

We could just have the arm be packaged with it's articulation provider from the get go.

New interface:

    robot = ManipulatorRobot(
        robot_type="koch",
        calibration_dir=".cache/calibration/koch",
        arms=arms,
    )

The koch.yaml would change to:

arms:
  arm1:
    _target_: lerobot.common.robot_devices.motors.dynamixel.DynamixelMotorsBus
    port: /dev/tty.usbmodem575E0031751
    articulationProvider: <path to class or separate config>
    motors:
      # name: (index, model)
      shoulder_pan: [1, "xl330-m077"]
      shoulder_lift: [2, "xl330-m077"]
      elbow_flex: [3, "xl330-m077"]
      wrist_flex: [4, "xl330-m077"]
      wrist_roll: [5, "xl330-m077"]
      gripper: [6, "xl330-m077"]

For the first iteration we'd simply have the provider passed in be a DynamixelMotorsBus wrapped with a few read commands. Then we could start adding XYZ new providers from the community.

Seems like a relatively straightforward refactor, mild indirection added, for infinite extensibility for articulation control schemes.

@MichaelrMentele
Copy link
Author

We still need to define the interface for the provider a bit, agree on names, but let me know if we agree on the direction first.

@MichaelrMentele MichaelrMentele changed the title [Design Change] Generalize Manipulator Class [Design Change] Enable Bringing Your Own Control Scheme Oct 4, 2024
@Cadene
Copy link
Collaborator

Cadene commented Oct 4, 2024

Thanks for your suggestions! As you know, our project regarding real robot interfaces needs iterations. We prefer to wait a bit before refactoring. Instead, we want to focus on supporting real well a minimal set of use cases. We also want to make our code simple enough so that it is easy for people to import lerobot and add their own robots or interfaces on top!
Let's see how it goes!

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

No branches or pull requests

2 participants