search

ahundt / grl

Robotics tools in C++11. Implements soft real time arm drivers for Kuka LBR iiwa plus V-REP, ROS, Constrained Optimization based planning, Hand Eye Calibration and Inverse Kinematics integration.
https://ahundt.github.io/grl/
BSD 2-Clause "Simplified" License
153 stars 72 forks source link

FRI not running on the Arm #98

Closed rkojcev closed 7 years ago

rkojcev commented 8 years ago

Hi Andrew,

  1. When I run the grl_driver I get the following error at the beginning:

[ INFO] [1465417757.473397698]: done creating subscribers using: 192.170.10.100 30200 192.170.10.2 30200 [2016-06-08 16:29:17.474941] [0x3993c7c0] [trace] KukaLBRiiwaRosPlugin: Connecting ZeroMQ Socket from tcp://0.0.0.0:30010 to tcp://172.31.1.147:30010 No new FRI data available, is an FRI application running on the Kuka arm? Total sucessful transfers: 0 Total attempts: 1 Consecutive Failures: 1 Consecutive Successes: 0

Everything seems to be fine on the FRI side, right ports, ip, everything. I have confirmed this with pinging the ip of the FRI on the controller as well as running the KUKA FRI demo apps.

  1. Second interesting thing is that when you start the grl driver without issuing any position commands, the arm locks itself and becomes stiff. If in Cartesian Impedance Mode this is bad because the arm suddenly becomes stiff.

After issuing joint pose commands via ROS, the arm moves in the right position and then the Cartesian Impedance is always on. And it stays like this without self locking.

Is this behavior how it should be in your code or is something we can have a look to improve?

ahundt commented 8 years ago

Are you trying to send FRI commands? That's very close to working but not quite there yet. If FRI commands are not enabled that may be a bug in recent patches I added to work towards getting FRI working properly but didn't get 100% there

On Wednesday, June 8, 2016, Risto Kojcev notifications@github.com wrote:

Hi Andrew,

  1. When I run the grl_driver I get the following error at the beginning:

[ INFO] [1465417757.473397698]: done creating subscribers using: 192.170.10.100 30200 192.170.10.2 30200 [2016-06-08 16:29:17.474941] [0x3993c7c0] [trace] KukaLBRiiwaRosPlugin: Connecting ZeroMQ Socket from tcp://0.0.0.0:30010 to tcp:// 172.31.1.147:30010 No new FRI data available, is an FRI application running on the Kuka arm? Total sucessful transfers: 0 Total attempts: 1 Consecutive Failures: 1 Consecutive Successes: 0

Everything seems to be fine on the FRI side, right ports, ip, everything. I have confirmed this with pinging the ip of the FRI on the controller as well as running the KUKA FRI demo apps.

  1. Second interesting thing is that when you start the grl driver without issuing any position commands, the arm locks itself and becomes stiff. If in Cartesian Impedance Mode this is bad because the arm suddenly becomes stiff.

After issuing joint pose commands via ROS, the arm moves in the right position and then the Cartesian Impedance is always on. And it stays like this without self locking.

Is this behavior how it should be in your code or is something we can have a look to improve?

— 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/98, or mute the thread https://github.com/notifications/unsubscribe/AADZwK7eUh4_Yoqje7v2qukW1HNMheoPks5qJysfgaJpZM4IxYsF .

Cheers! Andrew Hundt

Ph.D. Student Johns Hopkins University

rkojcev commented 8 years ago

No I am just using the default configuration. I am trying to send commands via Smart Servo but I do not receive any commands of the joint position via FRI anymore...

KukaCommandMode is set to be Java KukaMonitorMode is set to be FRI

ahundt commented 8 years ago

Hmm I'm very surprised because I tested everything I committed just before I left

On Thursday, June 9, 2016, Risto Kojcev notifications@github.com wrote:

No I am just using the default configuration. I am trying to send commands via Smart Servo but I do not receive any commands of the joint position via FRI anymore...

KukaCommandMode is set to be Java KukaMonitorMode is set to be FRI

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ahundt/grl/issues/98#issuecomment-224877447, or mute the thread https://github.com/notifications/unsubscribe/AADZwOLyMvDYdMNMIgi_XP5JxBRTe1iYks5qKAQ9gaJpZM4IxYsF .

Cheers! Andrew Hundt

rkojcev commented 8 years ago

Hmmm same with me especially because all the ip's are set correctly and the FRI is running on the demo's provided by KUKA...

Any pointers in the code where I should look?

ahundt commented 8 years ago
  1. I would try using wire shark to verify packets are actually arriving/departing.
  2. Debug the code flow in Java to make sure FRI is on
  3. Look in KukaDriver.hpp to see if member variables are being updated
  4. Go down to kukaFRI driver look at those member values
  5. Look at recent commits to see what code changed debug to see if data in those particular locations looks reasonable
  6. Let me know what you found out and I can give you other ideas

You might only need step 1, and hopefully won't need all of them but I tried to think of everything I could.

On Friday, June 10, 2016, Risto Kojcev notifications@github.com wrote:

Hmmm same with me especially because all the ip's are set correctly and the FRI is running on the demo's provided by KUKA...

Any pointers in the code where I should look?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ahundt/grl/issues/98#issuecomment-225191656, or mute the thread https://github.com/notifications/unsubscribe/AADZwMrre-yuT-SYRpthHKuIcLbDxM6pks5qKW_LgaJpZM4IxYsF .

Cheers! Andrew Hundt

rkojcev commented 7 years ago

Closing this one.