Introduction to the Haptic Teleoperation Demo

The Haptic Teleoperation Demo uses the Whole Body Control Framework (WBC) to control position and orientation of the KUKA LWR. This introduction describes the multiprocess software setup for doing torque control with the KUKA LWR using a non-realtime operating system. This is the basis for having your ron SCL controllers run on the KUKA LWR. Details of how to feedback forces and torques to the haptic device are not covered in this WIKI, butin the Master Thesis of Fabian Gerlinghaus.

1. Multiprocess Software Setup

As WBC outputs torques a torque interface to the LWR was implemented using the impedance controller of the FRI. Stiffness and Damping of the FRI Impedance Controller were set to zero and torques. The additional torque variable in KUKA's torque equations was used to set the desired torque.

Since SCL has not been ported to VxWorks, Linux was used to interface with the FRI. Linux is not a realtime operating system. The only way to make it respond to the KUKA-FRI within 2ms after every tick, was to split the Linux machine into three CPU sets. The following setup reserves 2 CPU cores exclusively for the communication with the FRI.

CPU SET 1 2 Cores - only running the kuka_torque_interface for communication with the KUKA-FRI

CPU SET 2 1 Core - only running the kuka_scl_controller for computing the torques, feedbacking forces/torques to the haptic device, taking care of sensor input, sensor filtering, communication with the WSG50 Gripper, graphical representation of the KUKA LWR

CPU SET 3 1 Core - running every other system process

The two processes kuka_torque_interface and kuka_scl_controller communicate with each other using the custom library SMIC (Shared Memory Interprocess Communication). If the kuka_scl_controller process does not compute the required torques quite fast enough, the last computed torque signal is sent to the FRI by the kuka_torque_interface.

The kuka_torque_interface also puts in place several safety layers. If any of the following limits is crossed, an emergency error will be called and the brakes of the LWR will be activated.

• The Tool Center Point (TCP) gets closer to the ground than 45cm.
• Any of the joints gets within 5 deg of the actual physical limits
• Any joint surpasses its respective Angular Velocity Limit
• If the SCL controller process (kuka_scl_controller) should crash or be terminated, kuka_torque_interface will take over control and safely move the robot back to the candle position, until the SCL controller process is started again.

The modular two-process-software-setup has two advantages.

• The safety limits are implemented in a different program. Consequently they cannot be deactivated by accident, when developing a new SCL controller.
• Starting up the KUKA LWR everytime you want to test a change you made to your SCL controller (e.g. starting it with a different gain) is a tedious time-consuming process. kuka_torque_interface will keep the robot in the candle position until you start your SCL controller process. It will then move the robot to a starting position outside of the singularity and hand over control to the scl controller process (in my case kuka_scl_controller). If the kuka_scl_controller (or your custom controller) should be terminated on purpose or crash by accident the kuka_torque_interface will move the robot back to the candle position safely. This adds to safety and saves the developer considerable time.

2. Run your own SCL controller software on the KUKA LWR

In order to develop your own controller in SCL and have it run on the KUKA LWR, you need to start kuka_torque_interface and let your process communicate with it using the SMIC library. How to do this is documented in:

https://bitbucket.org/samirmenon/scl-manips-group/wiki/haptic_teleoperation_demo/software

Contact: gerlinghaus@cs.stanford.edu