Robot Move Error (Copied from franka-community.de)

[Abraham190137]

This conversation is being copied from the Franka Community forum incase someone else runs into a similar problem (https://www.franka-community.de/t/vr-teleoperation-with-oculus-quest-2/5197/5)

From [chmk10]: Hi @Abraham190137. First of all, awesome project! Thank you so much for sharing it.

I have tried it out. The set up works perfectly with panda gym, but I am still having problems with the robot.

The robot definitely connects to unity as opening and closing the grip works perfectly. Besides, I am also able to move the robot.

But the robot moves very fast a violently to the same spot every time and is then stuck there. I am not sure what the problem is. Have you experienced anything similar? I am running the Teleoperation_Minimum.py script with USE_ROBOHAND = False.

If you have any idea what the cause could be, I’d be extremely grateful!

[Abraham190137]

Hello @chmk10, sorry to hear you are having trouble. This sounds like the controller is causing the problem. To check this, in Teleoperation.py add a print statement in the run loop to print out the message sent from unity - either “print(data)” on line 100 (to see the entire message), or “print(pose)” on line 128 (to just see the goal pose). To keep the robot from moving while you do this, remove the pose controller by commenting out all lines that contain “self.PoseController”.

If the goal pose makes sense, then the issue lies in the controller. First, try replacing PoseController with the goto_pose command from FrankaPy - just make sure you set block = False so that the code can continue to execute (Teleoperation.py, line 130, replace with “self.fa.goto_pose(pose, block=False)”). This will work, but it will result in a non-smooth motion with high latency, as each goto pose command will fully execute before the next is called. That being said, it’s a good debugging step.

Moving onto the actual issue, what you’re describing seems like one of two problems - the arm is running into a virtual wall (where is the spot it gets stuck?) or the Pose Controller (impedance control) has the wrong goal position/cartesian impedances. The Pose Controller does have a limit (specified by step_size) to the total distance it will command the robot to translate from its current position, but it does not have any limit on rotation. If it is being told to significantly rotate the gripper in a single time step, this might cause the issue you’re experiencing (I’ve never run into this problem, but it might happen). Testing with frankapy’s goto_pose will let you know that is the issue. You can also print out the pose sent to Franka by the Pose Controller (frankapy_extensions.py, line 52, “print(self.pose)”). Alternatively, you may need to either reduce the step_size parameter or alter the cartesian impedances (currently frankapy’s defaults).

Hope this helps! Let me know how the debugging goes.

[carolina-kawabata]

Hey @Abraham190137 I am sorry I never got back to you. In the end we found a solution but I don't even remember what was the problem. I went through the steps here, and something worked. So thank you so much for the time you took answering me.

[carolina-kawabata]

I am sorry but was wondering if you could help us with another problem.

We are using Teleoperation_Minimum.py

When I grab an object in this mode, the gripper no longer works. Is this a safety mechanism? Is there anyway I could turn it off?

[carolina-kawabata]

Setting a weaker force e.g 5 and grasp=True to self.fa.goto_gripper solved my issue!

[Abraham190137]

Yeah, the gripper is a bit funky. If you don't have grasp = True, then the grasp command runs until the gripper reaches the goal width, which can cause the code to block if something is in the way of the gripper