FRI not running on the Arm

[rkojcev]

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]

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

Cheers!
Andrew Hundt

Ph.D. Student
Johns Hopkins University

[rkojcev]

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]

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
#98 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AADZwOLyMvDYdMNMIgi_XP5JxBRTe1iYks5qKAQ9gaJpZM4IxYsF
.

Cheers!
Andrew Hundt

[rkojcev]

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]

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
#98 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AADZwMrre-yuT-SYRpthHKuIcLbDxM6pks5qKW_LgaJpZM4IxYsF
.

Cheers!
Andrew Hundt

[rkojcev]

Closing this one.