Code Monkey home page Code Monkey logo

drake-iiwa-driver's Introduction

drake-iiwa-driver

This repository contains the application code used to communicate with the KUKA iiwa are from Drake. Communicating with the arm requires two pieces, a Java application to run on the KUKA Sunrise cabinet, and an local C++ application communicating with the cabinet using the FRI protocol.

The KUKA control cabinet has two network interfaces which are configured with static IP addresses. Both will need to be connected to communicate with the arm.

  • X66: 172.31.1.147/16 -- This interface is used by Sunrise Workbench to load new software onto the controller.
  • KONI: 192.170.10.2/24 -- This is the interface which FRI clients communicate over. That's not in the reserved IP space, so it could potentially cause a conflict if you happen to want to contact a host in that subnet.

Selecting the command mode to use for the arm (position vs. torque) is done by starting a different Java application on the arm (DrakeFRIPositionDriver vs. DrakeFRITorqueDriver). The C++ driver will detect which mode the FRI connection is in and send commands appropriately.

Sunrise Workbench

Provisioning the IIWA arm must be done from Sunrise Workbench. Please ensure that you have Sunrise Workbench 1.14 installed, and that it is compatible with your control cabinet (see below). If you need instructions for older versions, please see 1faf413.

When installing, the default checkboxes for Connectivity Software should cover the use cases needed here.

The computer running Sunrise Workbench must be configured with an address which can communicate with 172.31.1.147/16, and which is connected to the X66 port.

Note: Try to briefly familiarize yourself with first-party documentation from KUKA. For relevant software, the documents should be named something along the lines of "KUKA Sunrise.OS / KUKA Sunrise.Workbench", "KUKA Sunrise.FRI".

Backing up Existing Applications / Checking Compatibility

Before creating a new project, it is recommended to back up existing projects from the controller. This is useful for backing up and ensuring that your Sunrise Workbench is compatible with the Sunrise OS installed on the control cabinet.

  • (Optional) Switch to a new workspace: File -> Switch Workspace.
  • File -> New -> Sunrise project
    • Select "Load project from controller"
    • Instructions from here should be straightforward.

Creating the Java Application

TODO(sam.creasey) Can I just zip up a project/workspace?

  • File -> New -> SunriseProject

    • IP address of the controller can be left at 172.31.1.147
    • Create new project
    • Project Name: DrakeFRIDriver
    • Topology template: LBR iiwa 14 R820 (or the appropriate model)
    • Media Flange: Medien-Flansch Touch pneumatisch (or the appropriate model)
    • Uncheck "Create Sunrise application (starts another wizard)"
    • Source folder: whatever
    • Package: drake_fri
    • Name: DrakeFRIDriver
  • In "Package Explorer", select StationSetup.cat

    • Software
      • Leave anything that is already checked as-is
      • Check "Fast Robot Interface Extension"
    • Save (Ctrl-S)
  • In "Package Explorer", select SafetyConfiguration.sconf

    • Customer PSM
      • Uncheck row 1 "External EMERGENCY STOP"
      • Uncheck row 2 "Operator Protection",
      • Uncheck row 3 "Safety Stop"
  • Copy the Java source code for DrakeFRIPositionDriver and DrakeFRITorqueDriver.

    • In "Package Explorer", expand tree for your new project, navigate to src, right-click, and select New -> Package. Name this new package drake_fri.
    • Use code from kuka-driver/sunrise_1.14.
    • Copy DrakeFRIPositionDriver.java and DrakeFRITorqueDriver to DrakeFRIDriver/src/drake_fri. It may be easiest to drag and drop from a Windows Explorer window into the "Package Explorer" pane. You can remove any exising DrakeFRIDriver files.
  • In "Package Explorer", select StationSetup.cat

    • Installation
      • Push "Install" (this will not actually install the application, but it will wipe the existing configuration of the KUKA cabinet and replace it with yours). It will take a few minutes, and eventually will reboot the controller.
  • Press the "sync" button. It's on the toolbar at the top, 5th from the right. It looks a bit like a square with a couple of arrows over it (though it doesn't look much like this). This will compile the Java source code and install the resulting applications.

    • Execute

Enabling the Safety Configuration on the Robot

When you upload a new safety configuration to the robot it needs to be enabled. To do this go to Safety-->Activation on the pendant. Then click Activation. Use the default user, the password is argus. This should enable the new configuration.

C++ driver

Once Sunrise Workbench is provisioned, you'll need to configure the system which will communicate directly with the KONI interface. This system must be configured for the IP address 192.170.10.200 (netmask /24, or 255.255.255.0) (this can be changed in the Java applications). KUKA recommends directly attaching the computer to the KONI port instead of using a switch. Some network interfaces (particularly some Intel models) have issues when cabled directly to the KONI port (problems include link flapping up/down repeatedly).

On the SmartPad, turn the key switch, and choose the "AUT" mode, then turn the key switch back. Choose either "DrakeFRITorqueDriver" or "DrakeFRIPositionDriver" from "Application". Press the green "Play" button on the left sidebar of the SmartPad.

Compiling the driver

Next, build the driver program to communicate with the iiwa arm using FRI, and with the controlling application using LCM. Compiling this project will output a single program in the build directory called "kuka_driver". Running it with no arguments will connect to the IIWA at it's default address and port (192.170.10.2, port 30200), negotiate LCM into the command state, and report the IIWA status via LCM.

An application wishing to control the arm should listen to LCM for status updates and command the joints appropriately in response.

Before you begin, install the prerequisite:

sudo apt install libgflags-dev

The C++ driver can be build with either CMake or bazel. There are two external dependencies which need to be provided, FRI and drake.

This repository is configured with a private git submodule for the KUKA FRI source code. To pull it:

git submodule init
git submodule update

If you do not have access to that repository, you will need to install your own version of the FRI source (which can be found in your Sunrise project in the directory FastRobotInterface_Client_Source).

cd kuka-fri
unzip /path/to/your/copy/of/FRI-Client-SDK_Cpp.zip
patch -p1 < ../fri_udp_connection_file_descriptor.diff

The patch above applies correctly to the FRI 1.7, 1.11, and 1.14 source. Other versions have not been tested.

Building with bazel

When building with bazel, it will automatically fetch a copy of drake to build against. You should be able to run bazel build //... to produce a working driver.

This is the easiest method for developers who are already working with the drake source, since a working bazel build enviornment for drake should be sufficient to build this package.

Building with CMake

When building with CMake, you'll need a binary copy of drake. The latest release can be found at https://github.com/RobotLocomotion/drake/releases. Uncompress the binary tarfile, and add -DCMAKE_PREFIX_PATH=<path-to-drake>/drake/lib/cmake to your cmake command line. For example:

mkdir build
cd build
cmake .. -DCMAKE_PREFIX_PATH=/tmp/drake/lib/cmake
make

drake-iiwa-driver's People

Contributors

adityabhat-tri avatar calderpg-tri avatar ericcousineau-tri avatar hongkai-dai avatar jwnimmer-tri avatar manuelli avatar mpetersen94 avatar nepfaff avatar patmarion avatar russtedrake avatar sammy-tri avatar siyuanfeng-tri avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

drake-iiwa-driver's Issues

Unexpected violent jerk during motion

Hi, when I was running kuka_driver.cc and send the goal pose info via lcm, the robot arm (Kuka IIWA) may sometimes return to zero position in a violent jerk. After I went deep into codes, it seems to me that the reason is something wrong with the fri communication. I saw a flag (restart_fri) and if I set it to be true, the robot will first return to zero position in a jerk and then come back in another jerk...
Does someone observe the same thing happens? Is it possible that we solve the fri communication issue, or at least when it breaks, the robot arm keeps still?
Thanks in advance for any suggestions.

Driver should have an option to detect dangerous commands on startup

It's possible that when the driver starts, a controller may still be running from a previous session which is sending LCM commands which will cause the robot to stop (e.g. joint positions significantly distant from the current pose). We should add an option to the driver to refuse to pass commands to the robot if this condition is detected.

How to use low pass filter in your case?

Hi,
Since there is so much vibration in my application, I want to use your low_pass_filter to reduce it,but I encounter some problems.
According to your example in kuka_driver.cc, I applied it into my project. This is the pseudo-code:

cutoff_hz = 250;
q_diff = currentJointPosition - previousJointPosition;

robot_dt = utime_now - utime_last_;  // 0.004s

joint_velocity_estimated = vel_filters_[i].filter(q_diff/robot_dt)

// kTimeStep =0.004s
diffToGoal = joint_velocity_estimated*kTimeStep;

utime_last_ = utime_now;

commandToSend = currentJointPosition + diffToGoal;

commandToSendPlusIPOJointPos = commandToSend + ipoJointPosition;

// Then send commandToSendPlusIPOJointPos to robot in every kTimeStep.

Is this procedure OK?
It seems strange to me that robot couldn't follow the path I planed.
I'm wondering if it is caused by diffToGoal = joint_velocity_estimated*kTimeStep, since I didn't find anything about how to integrate joint_velocity_estimated to commandPosition.
Would you please give me some suggestions or instructions?

Thanks,
Chunting

KONI Port Issues

I know this is more related to hardware, but I'm guessing that someone here has dealt with this issue before. After successfully building drake and the drake-iiwa-driver, I am now having issues connecting to the KONI port. I made sure to set the IP/netmask on my computer to 192.170.10.200/24 as instructed. Here are the steps I've taken so far to try to resolve the issue:

  • Tried pinging the control box from both a linux and windows computer
  • Disabled firewall features from windows computer
  • Replaced ethernet cable with crossover cable
  • Restarted the control box

When I run the drake-iiwa-driver, it prints "Listening for robot 0 port 30200". I looked in the file, but didn't see any print statements for when the robot is connected....will something notify me that I'm actually connected to the robot? Here's a screenshot of my terminal showing "Destination Host Unreachable" when I try to ping the KONI port. I'm grateful for any help you guys can provide.

koni_ip_error

install instructions + run example

I've built http://drake.mit.edu/from_source.html with the bazel build. What are the steps for building this repository?

Current Status of my progress towards running an iiwa example:

  • drake builds with bazel
  • does director build with CMake or Bazel?
    • answer: (TODO)
  • director build complete
  • spartan builds
  • drake-iiwa-driver builds
  • procman example runs

Also, here is the automated setup script I'm creating as I go:
https://github.com/ahundt/robotics_setup/blob/master/locomotion_robotics.sh

Small vibration is found when the robot switch from the static status to motion

Hi,
I just found some small vibrations when the robot switches from the static status to motion as new command is received.
I plot all the waypoints computed from the Kuka_plan_runner and the real_real pose data (shown in the attached image).
It seems to that it is due to the piecewise polynomial method changes the starting point in order to get zero gradient (red line in the figure). As a result, the robot's motor would vibration a bit at very beginning when the motion command is received.
Anyone has seen this before? Should I modify the polynomial method?
Screenshot from 2021-11-19 16-19-58

URDF model for torque control

Hi,

I have seen that you are using FRI also so do torque control of the robot.

I was wondering if you have a dynamic model of the robot. masses, CoM, inertia matrix in order to control better.

Best,

Julen U.

Obtaining the End Effector external forces through FRI

Hi,

I am not sure if you have dealed with this problem, but as far as I found, I have not been able to obtain the external end effector Force directly from the robot using the FRI communication.

Have you solved the problem in any way? Or you are applying Jacobian to obtain it in PC side?

Thanks!!

Add More Detailed Instructions

Hi,

We have several questions regarding how to build the C++ driver file.

  1. Is the Drake package required to build the driver? We are assuming that it is required because we are getting an error which says "cannot find drake package".
  2. If the Drake package is required, it is unclear where to install the package so that it can be found by the driver.
  3. Can you tell us any dependency issues that are absolutely required for this to work? E.g. Ubuntu version, cmake version, compiler version, etc
  4. Will it be easier to build using cmake or Bazel? It appears like most people here are using Bazel, but we are not too familiar with how this build software works

If you could provide some detailed step-by-step instructions on how to successfully install the C++ driver, we would greatly appreciate it.

Thanks,
Dan

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.