install instructions + run example

[ahundt]

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
  • need to resolve dealing with vtk6 from kinetic - director initial setup & installation error director#576
• 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

[sammy-tri]

The README.md is a bit incomplete about the last steps, I see. You'll need to unzip a copy of the FRI library source code and apply the patch as described in https://github.com/RobotLocomotion/drake-iiwa-driver#c-driver (which should apply to FRI 1.7 through 1.13, possibly other versions). After that you should just be able to do bazel build //... from the top level directory and the driver will be emitted as bazel-bin/kuka-driver/kuka_driver. There's also CMake build infrastructure, but it hasn't really been tested outside of other superbuilds.

You'll also need the corresponding Java application installed through Sunrise as described in https://github.com/RobotLocomotion/drake-iiwa-driver#creating-the-java-application

[ahundt]

I was able to guess some of that, but I think there are assumptions that I have access to your internal repository.

± bazel build //...
..............
INFO: Analysed target //kuka-driver:kuka_driver (16 packages loaded).
INFO: Found 1 target...
WARNING: /private/var/tmp/_bazel_athundt/2e02f43188a422c4c0469b2e655f98c4/external/kuka_fri/BUILD.bazel:5:1: input 'external/kuka_fri/build/GNUMake' to @kuka_fri//:kuka-fri-build is a directory; dependency checking of directories is unsound
WARNING: /private/var/tmp/_bazel_athundt/2e02f43188a422c4c0469b2e655f98c4/external/kuka_fri/BUILD.bazel:5:1: input 'external/kuka_fri/src' to @kuka_fri//:kuka-fri-build is a directory; dependency checking of directories is unsound
INFO: From Linking external/glib/libglib.a [for host]:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: bazel-out/host/bin/external/glib/libglib.a(empty.o) has no symbols
warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: bazel-out/host/bin/external/glib/libglib.a the table of contents is empty (no object file members in the library define global symbols)
INFO: From Linking external/glib/libglib.a:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: bazel-out/darwin-fastbuild/bin/external/glib/libglib.a(empty.o) has no symbols
warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: bazel-out/darwin-fastbuild/bin/external/glib/libglib.a the table of contents is empty (no object file members in the library define global symbols)
INFO: From Linking external/lcm/lcm-gen [for host]:
clang: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument]
ERROR: /private/var/tmp/_bazel_athundt/2e02f43188a422c4c0469b2e655f98c4/external/kuka_fri/BUILD.bazel:5:1: Executing genrule @kuka_fri//:kuka-fri-build failed (Exit 2)

... snip (a bunch of g++ commands) ...
cp -uf SimulatedTransformationProvider ../../bin
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
cp: illegal option -- u
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file ... target_directory
make[1]: *** [install] Error 64
cp: illegal option -- u
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file ... target_directory
make[1]: *** [install] Error 64
cp: illegal option -- u
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file ... target_directory
make[1]: *** [install] Error 64
cp: illegal option -- u
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file ... target_directory
make[1]: *** [install] Error 64
cp: illegal option -- u
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file ... target_directory
make[1]: *** [install] Error 64
cp: illegal option -- u
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc] source_file ... target_directory
make[1]: *** [install] Error 64
make: *** [examples] Error 2
Target //kuka-driver:kuka_driver failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 54.095s, Critical Path: 18.46s
FAILED: Build did NOT complete successfully
-> [1]

[sammy-tri]

Ah! I have unfortunately never tested the build on mac, which I see you've just discovered.

You may be able to get it to build by editing build/GNUMake/tools.mak and changing the definition of CP on line 13 to just be cp -f without the -u.

[ahundt]

ok removing u worked for that step.

[ahundt]

hmm, I'm still working on the macOS setup but since ubuntu was recommended by dependencies I started that but I've run into some problems on 16.04 RobotLocomotion/drake#7615

[ahundt]

I'm confused about the setup and configuration process needed to run on the linux side. I know what to do with respect to installing sunrise and the java code on the robot controller.

1. If I build drake, spartan, director, and drake-iiwa-driver with Bazel, is there a way to install on the system and set up a CMake find script so my own project can use the headers and binaries?
2. How do I connect this to the other repositories?
3. Do I need to provide a find path in my project's user code?
   • I looked through https://github.com/RobotLocomotion/drake-shambhala does my use case fits any of those examples? Which approach should I use?
4. Alternately, do you recommend I go with all CMake builds?

Sorry for so many questions and I appreciate the help!

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

[ahundt]

Any chance you have or could create a docker container startup command that I could run from 16.04?

This might let me dodge all the setup issues and skip right to testing things out, but no worries if it doesn't exist or won't be practical. Thanks again for your help!

[peteflorence]

Hi Andrew, check out the Spartan docker build and just ccmake to use the iiwa driver, should work.

…

On Fri, Dec 15, 2017 at 6:26 PM Andrew Hundt ***@***.***> wrote: Any chance you have or could create a docker container startup command that I could run? This might let me dodge all the setup issues and skip right to testing things out, but no worries if it doesn't exist or won't be practical. Thanks again for your help! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFYQqHPUo8LXoj_f8_NdMzCyhXC6ZhIaks5tAwArgaJpZM4RClJk> .

[ahundt]

I also created a list so it will be easy for me to communicate my current progress towards running an example in the initial issue post at the top.

[ahundt]

@peteflorence thanks for the recommendation, I'll give that a shot!

I'm familiar with ccmake and I've read most of the instructions, but is there a command you can recommend that would actually move the robot?

I'm not sure what to expect when I complete this step from the README.md:

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.

If I run the program and it negotiates the connection I assume it will report some kind of success status but the following questions remain:

1. What do I do after running kuka_driver?
2. How should I expect the robot to be mounted?
3. Are there any safety precautions I should take?

Sorry for the flurry of questions, I appreciate your help!

[sammy-tri]

(sorry for the delayed response!) Also sorry because that text is not very clear and even kinda wrong.

When kuka_driver starts up, it just sits there waiting for FRI traffic from the cabinet. It won't do anything until there's a Java application running which creates the FRISession (which then starts communicating with kuka_driver). It will print to the console indicating the establishment of the FRI session (DrakeFRIPositionDriver / DrakeFRITorqueDriver will also print that the session is established on the Kuka pad).

I don't think the mounting of the robot matters much as long as it's compatible with Kuka's requirements.

The arm shouldn't move at all until an LCM message is received by the driver, so no major safety precautions. The driver will (by default) stop the arm if it the torque sensed at a joint exceeds an limit in the driver. (That being said, I still wouldn't want to get pinched between the arm and anything else if that happens).

I just realized that I never committed the version of our code which starts DrakeFRITorqueDriver in joint impedance mode to git. I'll do that shortly (it does a bit less damage in the event of a collision).

Also those Java programs are not well named. The iiwa will track the positions sent in the LCM messages in either mode. I don't have sufficient experience sending non-zero torques to the arm to know precisely what happens, but I believe the extra torque will be added to whatever the iiwa is doing for position control and cause additional deflection at that joint.

[sammy-tri]

#18 has the change for joint impedance mode in the torque driver. Will probably land tomorrow.