Recovering from a fault two-fingered gripper - ROS

mhebert

Hello,

This is sort of a difficult problem to describe but I will do my best.

I have a 85 two-fingered gripper that I am trying to control with ROS. Everything seems to work fine except for a few rare occasions where the gripper sends this fault message: 0x05 Action delayed, activation (reactivation) must be completed prior to renewed action. I am not really sure what causes the error because I can re-produce it by opening and closing the hand a bunch of times. When this happens, the indicator light goes red temporarily, then purple, then back to solid blue but I can no longer send the hand commands because the is_reset method returns true. I have tried running through the whole initialization code over and nothing. The only thing that works is restarting the program. Interestingly, if I move the hand at a slow speed, I can never get this to happen. It is only when I move quickly.

Hopefully that made some sense and somebody can help. Let me know if I can clarify things.

Thanks in advance,
Mitchell

Etienne_Samson

@mhebert,

I just opened a ticket case to follow-up on your bug, know that we do not support ROS, but we will do our best to help you out. Are you able to reproduce this bug using the Robotiq User Interface ?

You can check out this thread to learn more on the Robotiq User Interface.

mhebert

Interestingly, I can also produce the behavior in the UI as well. A typical sequence might be, connect to the device, active the gripper, select the go to mode, move it around a bunch, and then I get into the same exact scenario I get into with ROS ("Action delayed, activation (reactivation) must be completed prior to renewed action" is displayed in the bottom left). It temporarily loses the connection, the light goes red, it reconnects, and after reactivation I can no longer send it position commands without restarting the UI. Maybe this isn't a ROS issue? I was trying to figure out what bytes to send to the hand via ROS in order to re-initialize the hand and get it in ready mode and it seems like maybe the UI is having the same issue?

Also, the fault seems to happen when the hand is moving quickly or interacts with an object. I have yet to see the hand when it is moving slowly. Also I tried to reproduce the bug 5 times in the UI and one of those times it was able to recover and send commands again but the other 4 it was not. All 5 times seemed identical from my perspective otherwise.

Thanks again!

Etienne_Samson

@mhebert normally if we need to re-activate the Gripper then it has loss power, maybe for a short fraction of time. The re-activate does not cause the conneciton lost, it's the opposite, the connection lost / power lost shut downs the Gripper and then it needs to be re-activated to work again. What power supply are you using ? What about your communication setup ? It could be an intermittent connection on your cable.

Etienne_Samson

@mhebert Can you update ? Any progress ?

mhebert

So I sort of set this issue aside for the time being but I still need to resolve it. Just to update where I left it, I am currently using a lab DC power supply at the recommended 1A and 12V. I am communicating over the USB / RS485 converter. The strangest part is that if I set the gripper to the slowest speed, I can never get the error to happen. As soon as I turn it up to about half speed, simply opening and closing it will cause it to happen. I can produce it both using the Robotiq GUI and with a python ROS script which makes me think it most likely hardware based. It also faults when it tries to grip something and slips.

I have a second converter that I could try, do you think that could be the issue?

Etienne_Samson

@mhebert the supply must be 24V DC 1A (if you got the latest design) or 2A (2 years old units and more).

That's probably why you can control with lower speed/force, you draw less power, if you go higher, you draw enough power to clip the internal supply of the Gripper.

mhebert

Sorry I had a brain lapse. I am using 24V DC 1 A. I read the wrong channel off of the power supply and we do have the latest design.

Etienne_Samson

@mhebert your problem does seems to be hardware, have you check you serial communication GND ? I had an issue 2 weeks ago with a customer with similar symptom, communication would drop because of noise on the cables. It was fixed when they wired the ground of the serial converter.

Another thing that would give this is if your power-supply clips, for example if for some reason your Gripper consumes more current then usual, if the power supply is not really outputting 1A or if you have anything else wired in serie with it, then the Gripper could loose power for a short time and you would loose communication. 

You should investigate in both of these directions.