Gripper Drift and Asymmetry in LoCoBot Arm Control

Isaac Sim Version

4.5.0
4.2.0
4.1.0
4.0.0
4.5.0
2023.1.1
2023.1.0-hotfix.1
Other (please specify):

Operating System

Ubuntu 22.04
Ubuntu 20.04
Windows 11
Windows 10
Other (please specify):

GPU Information

  • Model: RTX 3500 Ada Generation
  • Driver Version: 570.124.06

Topic Description

Detailed Description

My LoCoBot gripper exhibits an issue where it initially loads in a centred state (aligned with the bar), but when I command it to open or close, it shifts away from the centre. Despite multiple attempts using both open-loop and closed-loop control methods, the gripper fingers do not maintain symmetry and drift over time. Additionally, the gripper appears to have reversed behaviour in that the commanded motion does not translate into the expected movement of the fingers. I have manually defined the expected positions (max closed: left=0.01126, right=-0.01126; max open: left=0.03632, right=-0.03632) and implemented closed-loop control using these values, but the drift persists.

Error Messages

None

Screenshots or Videos

Additional Information

What I’ve Tried

  • Open-Loop and Closed-Loop Control:
    I initially tried an open-loop command mapping using joint limit values and then implemented a closed-loop proportional controller that continuously corrects the gripper positions.
  • Manual Joint Target Values:
    I manually defined the target positions for the fully closed and fully open states (left finger: 0.01126 and 0.03632; right finger: -0.01126 and -0.03632) and computed the centred state as their average.
  • Force Symmetry Enforcement:
    I averaged the deltas between the default positions and the open/closed targets to force symmetric movement of both fingers.
  • Physics Parameter Tuning:
    I increased joint drive stiffness and damping to counteract the drift, but the problem persists.

Related Issues

Wrong parallel gripper position when gripping an object

Surface Gripper off-center in single manipulator

Additional Context

  • The gripper starts centred when the simulation is loaded but gradually drifts after executing commands.
  • The drift occurs regardless of the closed-loop feedback control I implemented, suggesting that the issue might be due to inherent asymmetry in the joint drive resolution or missing mimic joint functionality.
  • Everything was done using the Python API

Hi @psykaunot thank you for your question. This problem can be caused by many thing. As one observation it seems like the mesh collider of the two fingers did not load correctly, so it could be issues with loading the robot from URDF. Would it be possible for you to share a minimal setup to reproduce your error? It can help us speed up the time to help you with the gripper issue.

Hi Michalin, yes, I could share a minimal setup, but only privately for confidential reasons.

1 Like

I have tried to repro this issue and it seemed like it is due to URDF not defined correctly. I have tried to download a new URDF from pyrobot/robots/LoCoBot/locobot_description/urdf at main · Interbotix/pyrobot · GitHub and renamed the joints to work with your scripts. I’ve attached the URDF (without the meshes) for your reference.
interbotix_locobot_description.urdf (40.5 KB)

This is the behavior I get

I looked at my urdf and managed to reproduce the same movement you had.

My urdf file was a urdf. xacro that was calling different parts of the robot (arm, base…) in one single file. I obtained a single file when I converted it into the urdf format. I suspect the conversion to have impacted specific attributes in the urdf.

My initial problem was that the finger’s position shifted slightly to the left when running the simulation. The position of both fingers in the urdf of x, y and z was set to 0. In Isaac Sim, when both are set to 0, the fingers collide; the meshes cross. I thus decided to place them in the simulation to a position I estimated to be the closed position (y = 0.01126 and y = -0.01126). Being satisfied with this position, I changed the y values of both fingers in the urdf, allowing the gripper to start at the perfect position. I later discovered that the robot developers were using 0.015 instead, but I decided to keep mine.

In conclusion, I can reproduce the movement using the minimal version I shared. However, when I merge it with the rest of my implementation and in a simulated office, the gripper does not open and stays closed.
To be more precise, they move, but the displacement is so tiny that it looks like they’re always in the close position, and I can’t figure out why we do work in the minimal version and not the complete implementation.

1 Like

That is great you were able to get a minimal version working. For when you integrate with the rest of the environment, would you be able to try with other environments? Maybe there is something wrong with the office one? Maybe an object has a wrong collider mesh (just guessing).

I loaded the office scene with the minimal version, and it works. I tried the complete version in other environments or without a scene, and it does work.
The complete version comprises functions for creating the LiDAR, IMU, Camera sensors, ROS2 Tf three and other robot components.

The other components work, but when merged with the gripper, the gripper doesn’t.

As I said last time, your observation helped me to fix the gripper pose.
However, I had an issue merging it with the rest of my code. I figured out that there were some physics initialization issues and conflicts between asynchronous functions. I had to rebuild the code around the arm and make sure it worked before adding the sensors.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.