[BUG] Grav gripper cannot be initialized using Gripper::Init

[pzhu-flexiv]

Version information

• RDK: v1.5.1
• Robot software: v3.7.1
• OS: Ubuntu

Describe the bug
flexiv::rdk::Gripper::Init cannot trigger gripper initialization of Grav gripper in v1.5.1, this used to work in v1.4.

Steps to reproduce

1. Boot up the robot with Grav gripper.
2. Run the basics6_gripper_control example.
3. Gripper has no response.

Expected behavior
The gripper should initialize itself and start moving.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[pzhu-flexiv]

This bug will be fixed in v1.6. Currently the workaround is to use Flexiv Elements to manually initialize the gripper first, then use RDK to control it. This manual initialization is only needed once per power cycle.

[aravind-arpar]

Thank you for adding the information about the gripper manual initialization. I look forward to the fix in v1.6, meanwhile this manual initialization seems to work when I run the ./basic6_gripper_control example.

1. I can see the gripper move but I do get this fault 306003 The value of device parameter is smaller than the minimum value allowed both on the output of the executable as well as a dialog box on the elements when the function gripper.Stop() is called.
   2. Opening and closing seems to work but I noticed that closing doesn’t close all the way.

When initializing the gripper as you have shown, do the default values targetWidth=0.06, targetVelocity=0.06 and targetForce=10.0 as shown play a role in the initialization? Do they need to be set to some specific value in order to avoid these issues?

[aravind-arpar]

2. Opening and closing seems to work but I noticed that closing doesn’t close all the way.

please ignore this issue, I can see the gripper does close all the way. The target width specified was not 0 in my previous test, hence wasn't closing all the way.

However I still see the issue (1) mentioned in my last message.

[pzhu-flexiv]

@aravind-arpar Issue (1) is also caused by the the same bug in a newly deployed device control pipeline that caused Gripper::Init() to fail, and will be fixed in v1.6 as well. Apology for the inconvenience. We will make sure to update our QA workflow to fully cover the new pipeline.

As of now, you can use a workaround to stop the gripper by calling Gripper::Move() with target width set to the current width, which can be obtained via Gripper::states().width