grl iiwa driver

[ahundt]

Hey,

I'm the author of https://github.com/ahundt/grl, and I'm interested to see how is FRI based control is working for you in practice?

I'd also like to mention these two recent papers by Disney research on control of the KUKA via FRI:

1. https://www.disneyresearch.com/publication/toward-torque-control-of-a-kuka-lbr-iiwa/
2. https://www.disneyresearch.com/publication/toward-controlling-a-kuka-lbr-iiwa-for-interactive-tracking/

[sammy-tri]

It's been working pretty well for us, though we haven't use the torque control features extensively (we have used it to some extent though). We have had intermittent issues where we lose FRI control of the robot and need to reboot the control cabinet (this is usually accompanied by an error on the pad which reads something like 'Connection to Sunrise failed'), though that seems to be happening less frequently these days.

I looked at grl a bit a year or two ago, it looks like it's come a long way since then.

Thanks for the pointers to the papers, I'll definitely take a look!

Let me know if you have any more specific questions about FRI (or our experiences) and if I don't know I'll try to track down someone who might.

[ahundt]

@sammy-tri I'm continuing the conversation from https://github.com/RobotLocomotion/drake-iiwa-driver/issues/15#issuecomment-351823754 regarding runtime. Which program would be the best one to run with no end effector to give your stack a first try?

I see

• https://github.com/RobotLocomotion/drake/tree/master/examples/kuka_iiwa_arm
• https://github.com/RobotLocomotion/spartan/tree/master/scripts/bin

I'd appreciate your advice.

[sammy-tri]

Unfortunately the best example in drake is suffering from some bitrot and you'd basically need to build spartan anyway to get the needed dependencies to get it to work (there's a backlog item to replace the demo in drake with something newer but sadly we haven't gotten there). If you can get https://github.com/RobotLocomotion/spartan/blob/master/scripts/bin/kuka_iiwa_procman to run successfully, there's a director-based app to teleop the arm which would give you a basic example... but spartan is not easy to build in my experience.

@rcory has recently gotten a working mac build of spartan (I think), tagging him in here to see if he's got any pointers.

Unfortunately you've come across a major gap in our new user experience where our sample code was written for director which is no longer shipped with drake. My apologies for this situation (and for the fact that it's gone on this long).

[ahundt]

No worries, I appreciate that you're looking to close that gap and improve the user experience! It looks like drake has also come a long way.

There has been quite a bit of progress with grl but our team is of limited size. This is very tentative, but if drake is easy to set up and run it might be sensible for me to make a pull request integrating some of the key grl features such as switching FRI/java control modes at runtime and go from there.

Would there be any potential interest in this from you/your team?

It looks like the only additional driver dependency I'd have is flatbuffers, which is used to pack and send UDP packets to the robot controller which configure the mode such as FRI position control, FRI torque control, SmartServo, DirectServo, Teach.

[sammy-tri]

Being able to set the control mode parameters (FRI position vs. torque, joint impedance constants, fri configuration) without deploying a new app with Sunrise would definitely be of interest to us, I've just been too lazy to add a control protocol to do it. :)