Open ashk-on opened 8 years ago
You will have to look in the driver classes. One solution is to send a new joint command before switching modes. The other is to look at the function that sets the mode in the appropriate class, and have mode switch function set the commanded joint angles to the measured ones.
You could do that here: https://github.com/ahundt/grl/blob/master/include/grl/ros/KukaLBRiiwaROSPlugin.hpp#L249
Though the problem would still be present in the lower level drivers when they are used independently
Thus it should also at least be done here: https://github.com/ahundt/grl/blob/master/include/grl/kuka/KukaDriver.hpp#L299
The current arm state measurement should be stored here: https://github.com/ahundt/grl/blob/master/include/grl/kuka/KukaDriver.hpp#L400
Let me know if you have any questions!
On Monday, June 13, 2016, Ashkan372 notifications@github.com wrote:
Currently switching between 'TeachArm' and 'MoveArmJointServo' is problematic... it makes the robot jump to the position of the previous mode, and does not consider the current position... I would like to know what would be the best solution to fix this...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ahundt/grl/issues/99, or mute the thread https://github.com/notifications/unsubscribe/AADZwEDJN2z11OBl0WAi9rIuohsybNFsks5qLXDSgaJpZM4I0a1e .
Cheers! Andrew Hundt
Ph.D. Student Johns Hopkins University
So, it kinda got fixed by clearing the armstate_ in this line: https://github.com/ahundt/grl/blob/master/include/grl/kuka/KukaDriver.hpp#L243 also, I pass the current position, to KukaJavaDriver at the same place.
(Also I should mention switching to TeachArm from MoveArmJointServo was already ok, it's the other way around that's problematic)
Now there are still some issues while switching to MoveArmJointServo from TeachArm:
1- (more important issue) If there is a small force on the robot, it can't do the switch. (As expected, since in Cartesian Impedance when we have some force, it goes crazy while we start the robot)
2- Sometimes, the robot randomly moves toward candle position, and then comes to the previous position, and then the switching is done correctly.
Well there is a "hold position" step between move arm joint servo and teach arm which is a workaround for a bug in kuka's implementation. Can you upload a YouTube video of this problem? I don't totally understand from the description.
On Tuesday, June 14, 2016, Ashkan372 notifications@github.com wrote:
So, it kinda got fixed by clearing the armstate_ in this line:
https://github.com/ahundt/grl/blob/master/include/grl/kuka/KukaDriver.hpp#L243 http://url also, I pass the current position, to KukaJavaDriver at the same place.
(Also I should mention switching to TeachArm from MoveArmJointServo was already ok, it's the other way around that's problematic)
Now there are still some issues while switching to MoveArmJointServo from TeachArm:
1- (more important issue) If there is a small force on the robot, it can't do the switch. (As expected, since in Cartesian Impedance when we have some force, it goes crazy while we start the robot)
2- Sometimes, the robot randomly moves toward candle position, and then comes to the previous position, and then the switching is done correctly.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ahundt/grl/issues/99#issuecomment-226027233, or mute the thread https://github.com/notifications/unsubscribe/AADZwDSRvL6kXHPvf8J7bHkMkmAn4BYEks5qLyJggaJpZM4I0a1e .
Cheers! Andrew Hundt
Good! But is there a way to switch to MoveArmJointServo while holding(and possible exerting force on) the robot? I will post a video of that...
On Wed, Jun 15, 2016 at 4:37 AM, Ashkan372 notifications@github.com wrote:
Good! But is there a way to switch to MoveArmJointServo while holding(and possible exerting force on) the robot?
I don’t actually know the answer to that question, I’m also not sure of the details of what you’re trying to accomplish so I can’t advise with 100% accuracy at the moment.
My best guess at what you describe may not be possible if they have some integrated checks when it switches modes. For that sort of behavior that’s probably when you’d have to implement the whole algorithm including hand guidance yourself in position or torque control mode…
Cheers! Andrew Hundt
Since this has come up twice here and in https://github.com/ahundt/grl/issues/89, I'd say the default behavior should set the goal to the current position when switching modes. Perhaps a flag can be added for other behaviors if needed.
Currently switching between 'TeachArm' and 'MoveArmJointServo' is problematic... it makes the robot jump to the position of the previous mode, and does not consider the current position... I would like to know what would be the best solution to fix this...