Offer pre-built drake-visualizer in Drake's Bazel WORKSPACE #5621

jwnimmer-tri · 2017-03-26T16:00:52Z

As part of #3129, I am on my way to putting a drake-visualizer binary into Drake's Bazel WORKSPACE using pre-compiled releases (https://github.com/jwnimmer-tri/drake/tree/bazel-drake-visualizer-prebuilt). This is likely to be both easier and more robust than trying to recompile drake-visualizer from within Bazel, at least for a while.

For now, I'm prototyping using Pat's binaries (http://people.csail.mit.edu/patmarion/software/director/releases/) -- thanks, Pat! Those builds are good enough for spike testing, but not quite good enough for Drake master. For our WORKSPACE on master, we need anyone on the drake-developers team to be able to reliably rebuild all of the binaries, get them uploaded to the drake-provisioning S3 bucket, and update the Drake WORKSPACE to refer to the new builds.

Does anyone have opinions on how to get from here to there?

To me, the best option seems that Director CI should create the binary archives (I believe it already does this, at least on request), and either that CI or some manual process can push those into S3. Possibly this could be related to WORKSPACE-related backups and mirroring that we should also be developing concurrently, for all http_archive-related repositories (which is basically everything).

Of much lower priority, it would also be slightly better to have only drake-visualizer in the pre-built release, vs of all of Director. I think it would be a smaller download, and it seems to me like we should encourage Director users to use the Director build system and/or its own releases and/or the Drake superbuild, instead of sideloading Director pre-built into the Drake WORKSPACE. So a visualizer-only binary archive would be a nice extra feature to eventually add to Director CI, if its not already there.

/CC @patmarion @david-german-tri @jamiesnape

The text was updated successfully, but these errors were encountered:

jamiesnape · 2017-03-27T13:07:28Z

Certainly Jenkins could push binaries to S3 on continuous/nightly builds now. We could also proxy uploads and downloads from S3 through a separate server using GitHub auth. I am very much against granting direct write access to buckets to anyone other than service accounts and administrators unless there is no other choice.

sammy-tri · 2017-03-27T17:27:24Z

I'm hesitant to claim that Drake should lean on director's CI effort quite so much. I think at the least if we're going to consider going down that road we should think about how Drake's vastly better staffed CI effort could help instead of asking for more director features in support of our interests in refactoring the Drake build. (apologies if I misunderstood your proposal, just thinking about the fact that the existence of drake-visualizer binaries and other director artifacts are the result of a volunteer effort).

jwnimmer-tri · 2017-03-28T01:06:22Z

I like the idea of having the Drake CI produce binary releases of drake-visualizer semi-automatically. If it makes sense to proxy them (because of S3 fees?) with Girder, then that's okay too. Or should we try to push the "most recent recommended" drake-visualizer (or a few of them) to https://github.com/RobotLocomotion/drake/releases?

I guess I'm a little hesitant to upload every nightly though (nevermind Continuous) -- that seems like it would grow big fast? I imagine it changing perhaps monthly or less. Is there any easy way in Jenkins UI to push a "request build" button with some kind of tickbox that the result should be archived?

In the meantime, perhaps it would make sense to make a hand-rolled release for all platforms and get it uploaded? Then I could work on the Bazel integration and testing, and someone else could work on automating the building of new releases?

sammy-tri · 2017-03-28T14:42:49Z

Starting with hand-rolled releases on github might be the shortest reasonable path forward. Tentative +1.

david-german-tri · 2017-04-04T14:42:14Z

From conversation with @jwnimmer-tri: Jeremy has tried hand-rolling a drake-visualizer release, and has only succeeded using system VTK, which of course bakes a brittle load-time dependency into the binary. We could release those as a stopgap, but a more durable solution would be:

Complete Create and host VTK binary packages for Drake's supported platforms #5564 (VTK packages)
Add support for the VTK packages in the Director build.
Cut drake-visualizer releases using VTK packages, not system VTK.

The long pole there is of course (2).

patmarion · 2017-04-04T14:50:17Z

Another option for consideration- the drake-visualizer binaries are currently built on Travis-CI. If I set the configuration option USE_SYSTEM_VTK=OFF then the drake-visualizer binaries would include vtk and would not have a dependency on system vtk5. The only potential blocker of this option is the time limitation of the free Travis-CI service, as it takes additional time to compile vtk5. It could be worth a try if anyone is looking for a short term solution.

jwnimmer-tri · 2017-04-04T15:00:14Z

(One clarification from David's note: for "hand-rolling" what I actually did was run director's Dockerfile locally.)

... USE_SYSTEM_VTK=OFF then the drake-visualizer binaries would include vtk and would not have a dependency on system vtk5.

I tried this (in Docker), but the resulting package on Xenial did not load correctly for some reason. It had a Qt-related segfault that I couldn't figure out before I ran out of time. Given that we want to move away from VTK5 with high priority, I figured it was worth waiting for the prebuilt VTKs to be integrated into director's superbuild first, before returning to the question of non-system VTK in release images.

patmarion · 2017-04-04T15:10:38Z

Yup, that make sense.

I think the packaging part will look similar, whether it's using vtk5 currently or vtk7 down the road.

Thanks for noting the segfault. Setting USE_SYSTEM_VTK=OFF is not quite working, unfortunately. There is an extra install step that is required to make this method work. Some folks have been using a workaround by setting PYTHONPATH. I think the extra python install step is also required for building the packages in #5564.

jwnimmer-tri · 2017-04-04T15:16:11Z

Ah interesting. If you have a link to some work-around recipe, I can try it locally -- I already have in place a launcher wrapper to glue the director release tarball into the Bazel build, so I can make the paths be whatever I want in there. I did try some PYTHONPATH solutions but didn't find a working one.

patmarion · 2017-04-04T15:26:29Z

EDIT: The issue discussed in this comment has now been resolved in director/master.

The issue is that the vtk install step does not actually install the vtk python libs. The workaround has been to set the LD_LIBRARY_PATH and PYTHONPATH as described in Step 6 here:

http://drake.mit.edu/from_source_ros_kinetic.html#drake-ros-kinetic-build-workspace

But, the correct fix is to run the install step for vtk's python modules. This will copy the vtk python libraries into the correct location so that setting LD_LIBRARY_PATH and PYTHONPATH is unnecessary.

I haven't tested it myself, but it's something like:

cd <vtk build>/Wrapping/Python
make install

jwnimmer-tri · 2017-04-06T01:04:50Z

I'd like to do a first PR that integrates Pat's already-built binaries into Bazel, to get this solution bootstrapped. Speak up if anyone objects.

The hazard that if the release ever needed an update for some reason, we might not have an immediate solution, so we'd have to fall back to running CMake director builds by hand. I think that seems better than always having to run CMake builds, like we do now.

I think we can revisit some release engineering improvements after #5564 has landed.

patmarion · 2017-04-07T15:04:38Z

Sounds good. I will offer Dockerfiles to automate the packaging of drake-visualizer with vtk, for ubuntu14 and ubuntu16. I will leave it to you guys to determine where to run the packaging and where to upload the packages, if you find this useful at all.

jwnimmer-tri · 2017-04-07T17:44:57Z

Yes, I think it will very useful, thanks! I expect I'll run it on my workstation for now (and have a buddy check to make sure a second workstation can do it), and medium-term try to get Drake's cloud to do it somehow, one some time there frees up.

patmarion · 2017-04-09T21:21:35Z

if you want to try, here are some ubuntu 16 binaries:

experimental- director with vtk7 (depends on system qt5)

director with vtk5 (depends on system qt4)

jwnimmer-tri · 2017-05-04T14:17:50Z

My (somewhat stale) WIP branch is at https://github.com/jwnimmer-tri/drake/tree/bazel-drake-visualizer-prebuilt.

jamiesnape · 2017-05-04T16:04:30Z

@mwoehlke-kitware and/or @sankhesh will create a drake-visualizer binary using the binary VTK 8 pre-release packages that we are building.

patmarion · 2017-05-04T16:29:56Z

very interested to hear progress updates if you have a chance, this sounds great! for me in the near future, i hope to use director with vtk 7.1 (and hopefully move to 8 when a stable release is available), qt 4 (not 5 quite yet) and python 3.

jwnimmer-tri · 2017-05-05T12:07:27Z

@jamiesnape @mwoehlke-kitware @sankhesh I suspect you know this, but to be clear: while creating and hosting the binary is a meaningful chunk of the work, we already could have pointed at existing Director pre-built releases that are mostly fine. The remaining challenge in resolving this issue is preparing the repeatable build and release process (code and doc, e.g., Docker and then docs or automation for how to push new tarballs). I do not think we should point WORKSPACE at a pre-compiled drake-visualizer unless mostly all Drake developers could freshen the binaries if they need to. So the release automation is the second part to focus on.

sankhesh · 2017-05-05T13:53:19Z

very interested to hear progress updates if you have a chance, this sounds great! for me in the near future, i hope to use director with vtk 7.1 (and hopefully move to 8 when a stable release is available), qt 4 (not 5 quite yet) and python 3.

@patmarion I am working on adding support for VTK 8 with Qt5 with the QVTKOpenGLWidget.

sankhesh · 2017-05-18T15:56:00Z

#5564 (comment)

jamiesnape · 2017-05-25T15:50:59Z

Bazel logic should be up shortly.

For the automated builds, how often should drake-visualizer be refreshed. What would the trigger for a rebuild be? New tagged release of Director created? Some other change in Director? Some change in Drake?

stonier · 2017-06-06T13:49:41Z

bump @jamiesnape for the bazel logic PR, @jwnimmer-tri for a decision on how you'd like builds to automate/trigger.

jamiesnape · 2017-06-06T13:54:30Z

#6259

stonier · 2017-06-06T13:55:54Z

👍

jwnimmer-tri · 2017-06-06T14:05:34Z

For the automated builds, how often should drake-visualizer be refreshed. What would the trigger for a rebuild be? New tagged release of Director created? Some other change in Director? Some change in Drake?

If the refresh were free, it should happen on every PR that merges into Director master, because that means we'll find out immediately if there was a (detected) error in the binary release process, and we'd (likely) trivially be able to bump up to a new visualizer release anytime we needed one.

If we don't re-release on every merged PR, then we'd want at least the ability for any Drake Developer to launch a new binary release, after a certain PR merges. So there would be some kind of opt-in system.

stonier · 2017-06-06T14:10:08Z

@jamiesnape is there any technical obstacle that would force one or the other?

jamiesnape · 2017-06-06T14:21:26Z

We can hook Jenkins into the Director repo to build and upload to S3 on each merge with just a one-off setup cost really. The remaining question is more how to handle the SHA bumps in Drake, which in part depends on how much Director is expected to change. It would not be especially difficult for Jenkins to open a PR automatically on Drake, but if Director changes frequently, that may get annoying.

jwnimmer-tri · 2017-06-06T14:29:59Z

I am okay with not PR'ing the sha-bump to Drake right away. If we find ourselves with late-breaking integration defects then we can revisit, but given that the Director PR will have passed Director's CI, hopefully the likelihood of a broken drake-visualizer binary release is low.

RussTedrake · 2017-06-16T10:27:32Z

Just took this for a spin on mac... ran all of the latest homebrew instructions on our install page, but still get

Russs-MacBook-Pro% bazel run //tools:drake_visualizer
INFO: Found 1 target...
Target //tools:drake_visualizer up-to-date:
  bazel-bin/tools/drake_visualizer
INFO: Elapsed time: 0.170s, Critical Path: 0.00s

INFO: Running command line: bazel-bin/tools/drake_visualizer
objc[30495]: Class QCocoaMenuLoader is implemented in both /usr/local/Cellar/qt/5.9.0/plugins/platforms/libqcocoa.dylib (0x10b419848) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374af90). One of the two will be used. Which one is undefined.
objc[30495]: Class QNSApplication is implemented in both /usr/local/Cellar/qt/5.9.0/plugins/platforms/libqcocoa.dylib (0x10b4197a8) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374afe0). One of the two will be used. Which one is undefined.
objc[30495]: Class QCocoaApplicationDelegate is implemented in both /usr/local/Cellar/qt/5.9.0/plugins/platforms/libqcocoa.dylib (0x10b419758) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374b030). One of the two will be used. Which one is undefined.
objc[30495]: Class QNSOpenSavePanelDelegate is implemented in both /usr/local/Cellar/qt/5.9.0/plugins/platforms/libqcocoa.dylib (0x10b419988) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374b170). One of the two will be used. Which one is undefined.
objc[30495]: Class QCocoaPageLayoutDelegate is implemented in both /usr/local/opt/qt/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport (0x1085fbef0) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374b2b0). One of the two will be used. Which one is undefined.
objc[30495]: Class QCocoaPrintPanelDelegate is implemented in both /usr/local/opt/qt/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport (0x1085fbf40) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374b328). One of the two will be used. Which one is undefined.
objc[30495]: Class QNSImageView is implemented in both /usr/local/Cellar/qt/5.9.0/plugins/platforms/libqcocoa.dylib (0x10b419a28) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374b350). One of the two will be used. Which one is undefined.
objc[30495]: Class QNSStatusItem is implemented in both /usr/local/Cellar/qt/5.9.0/plugins/platforms/libqcocoa.dylib (0x10b419a78) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374b3a0). One of the two will be used. Which one is undefined.
objc[30495]: Class QNSMenu is implemented in both /usr/local/Cellar/qt/5.9.0/plugins/platforms/libqcocoa.dylib (0x10b419ac8) and /usr/local/opt/qt@4/lib/QtGui.framework/Versions/4/QtGui (0x11374b3c8). One of the two will be used. Which one is undefined.
objc[30495]: Class vtkCocoaTimer is implemented in both /usr/local/opt/[email protected]/lib/libvtkRenderingOpenGL2-8.0.1.dylib (0x105789f38) and /usr/local/Cellar/vtk5/5.10.1/lib/vtk-5.10/libvtkRendering.5.10.dylib (0x112c9fe28). One of the two will be used. Which one is undefined.
objc[30495]: Class vtkCocoaServer is implemented in both /usr/local/opt/[email protected]/lib/libvtkRenderingOpenGL2-8.0.1.dylib (0x105789fd8) and /usr/local/Cellar/vtk5/5.10.1/lib/vtk-5.10/libvtkRendering.5.10.dylib (0x112c9fe78). One of the two will be used. Which one is undefined.
objc[30495]: Class vtkCocoaFullScreenWindow is implemented in both /usr/local/opt/[email protected]/lib/libvtkRenderingOpenGL2-8.0.1.dylib (0x105789fb0) and /usr/local/Cellar/vtk5/5.10.1/lib/vtk-5.10/libvtkRendering.5.10.dylib (0x112c9fef0). One of the two will be used. Which one is undefined.
objc[30495]: Class vtkCocoaGLView is implemented in both /usr/local/opt/[email protected]/lib/libvtkRenderingOpenGL2-8.0.1.dylib (0x10578a028) and /usr/local/Cellar/vtk5/5.10.1/lib/vtk-5.10/libvtkRendering.5.10.dylib (0x112c9ff18). One of the two will be used. Which one is undefined.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/private/var/tmp/_bazel_russt/3e477aa1673e9c80e91d410bb65d1970/execroot/drake-distro/bazel-out/osx-opt/bin/tools/drake_visualizer.runfiles/drake/external/director/lib/python2.7/dist-packages/director/drakevisualizerapp.py", line 36, in main
    applicationName=appName)
  File "/private/var/tmp/_bazel_russt/3e477aa1673e9c80e91d410bb65d1970/execroot/drake-distro/bazel-out/osx-opt/bin/tools/drake_visualizer.runfiles/drake/external/director/lib/python2.7/dist-packages/director/componentgraph.py", line 148, in construct
    self.initComponent(name, defaultFields)
  File "/private/var/tmp/_bazel_russt/3e477aa1673e9c80e91d410bb65d1970/execroot/drake-distro/bazel-out/osx-opt/bin/tools/drake_visualizer.runfiles/drake/external/director/lib/python2.7/dist-packages/director/componentgraph.py", line 164, in initComponent
    newFields = initFunction(inputFields)
  File "/private/var/tmp/_bazel_russt/3e477aa1673e9c80e91d410bb65d1970/execroot/drake-distro/bazel-out/osx-opt/bin/tools/drake_visualizer.runfiles/drake/external/director/lib/python2.7/dist-packages/director/mainwindowapp.py", line 172, in initView
    applogic.setCameraTerrainModeEnabled(view, True)
  File "/private/var/tmp/_bazel_russt/3e477aa1673e9c80e91d410bb65d1970/execroot/drake-distro/bazel-out/osx-opt/bin/tools/drake_visualizer.runfiles/drake/external/director/lib/python2.7/dist-packages/director/applogic.py", line 143, in setCameraTerrainModeEnabled
    if getCameraTerrainModeEnabled(view) == enabled:
  File "/private/var/tmp/_bazel_russt/3e477aa1673e9c80e91d410bb65d1970/execroot/drake-distro/bazel-out/osx-opt/bin/tools/drake_visualizer.runfiles/drake/external/director/lib/python2.7/dist-packages/director/applogic.py", line 138, in getCameraTerrainModeEnabled
    return isinstance(view.renderWindow().GetInteractor().GetInteractorStyle(), vtk.vtkInteractorStyleTerrain2)
AttributeError: 'vtkCommonCorePython.vtkObject' object has no attribute 'GetInteractor'

soonho-tri · 2017-06-16T10:43:39Z

@RussTedrake , could you try the following and test it again?

brew uninstall pyqt@4 qwt-qt4 vtk5

RussTedrake · 2017-06-16T10:49:32Z

that solved it. thanks!

but note that our installation instructions tell people to install all of those?
http://drake.mit.edu/mac.html

RussTedrake · 2017-06-16T10:52:34Z

ah. i see now that (of course) calling

bazel run //tools:drake_visualizer &
bazel run monolithic_pick_and_place_demo

isn't actually a workflow, because i get

Another command (pid=30820) is running.  Waiting for it to complete...

i know that a more user-friendly launch instructions were in flight. did they land?

soonho-tri · 2017-06-16T10:52:40Z

For now, IIRC, cmake build is still requiring those packages while they interfere with bazel build (as you experienced).

AFAIK, @jamiesnape is working on this issue.

RussTedrake · 2017-06-16T10:57:20Z

Thanks. To be clear about my understanding: i think the automotive demos have a python launch script that brings up both drake-visualizer and the sim, etc. so that would work fine (one invocation of bazel). But my traditional workflow has been to launch drake_visualizer once for my system, and run many simulations, etc. Launching drake_visualizer manually from in bazel-bin is not working for me yet.

jamiesnape · 2017-06-16T12:36:35Z

but note that our installation instructions tell people to install all of those?
http://drake.mit.edu/mac.html

Until we can fully switch over Director, unfortunately we have to support both VTK versions. We are very close to switching, but we have a backlog of platform reviews in Drake and some of RobotLocomotion/director#508 was unfortunately removed from RobotLocomotion/director#518.

jwnimmer-tri · 2017-06-16T13:40:09Z

The implicit feature request also buried in the above is that bazel-bin/tools/drake_visualizer should work. I think we can do that with some additional path heuristics in the tools/drake_visualizer_linux.sh and shell script (and its apple friend).

jwnimmer-tri · 2017-06-16T14:41:00Z

The implicit feature request also buried in the above is that bazel-bin/tools/drake_visualizer should work. I think we can do that with some additional path heuristics in the tools/drake_visualizer_linux.sh and shell script (and its apple friend).

Sorry, that was unhelpful. In #6319, I already added this feature for Linux. I guess someone on OSX can re-implement it to work for them, as well.

jamiesnape · 2017-06-20T17:21:31Z

See #6391.

EricCousineau-TRI · 2018-02-08T04:37:55Z

Closing this, as it is presently provided. #7050 addresses CI needs.

jwnimmer-tri added configuration: bazel priority: high unused type: question labels Mar 26, 2017

jwnimmer-tri self-assigned this Mar 26, 2017

jwnimmer-tri mentioned this issue Mar 26, 2017

Add support for Bazel build system #3129

Closed

jwnimmer-tri mentioned this issue Apr 3, 2017

In from_source, recommend Xenial #5695

Merged

jwnimmer-tri added the unused team: kitware label Apr 28, 2017

jamiesnape assigned sankhesh and mwoehlke-kitware May 4, 2017

jwnimmer-tri removed their assignment May 5, 2017

jamiesnape unassigned mwoehlke-kitware May 8, 2017

jamiesnape mentioned this issue Jun 20, 2017

Let drake_visualizer work outside sandbox on Mac #6391

Merged

jwnimmer-tri mentioned this issue Sep 19, 2017

CI coverage of pre-built drake visualizer #7050

Closed

EricCousineau-TRI closed this as completed Feb 8, 2018

Offer pre-built drake-visualizer in Drake's Bazel WORKSPACE #5621

Offer pre-built drake-visualizer in Drake's Bazel WORKSPACE #5621

Comments

jwnimmer-tri commented Mar 26, 2017

jamiesnape commented Mar 27, 2017

sammy-tri commented Mar 27, 2017

jwnimmer-tri commented Mar 28, 2017

sammy-tri commented Mar 28, 2017

david-german-tri commented Apr 4, 2017

patmarion commented Apr 4, 2017

jwnimmer-tri commented Apr 4, 2017

patmarion commented Apr 4, 2017

jwnimmer-tri commented Apr 4, 2017

patmarion commented Apr 4, 2017 • edited Loading

jwnimmer-tri commented Apr 6, 2017

patmarion commented Apr 7, 2017

jwnimmer-tri commented Apr 7, 2017

patmarion commented Apr 9, 2017

jwnimmer-tri commented May 4, 2017

jamiesnape commented May 4, 2017

patmarion commented May 4, 2017 • edited Loading

jwnimmer-tri commented May 5, 2017

sankhesh commented May 5, 2017

sankhesh commented May 18, 2017

jamiesnape commented May 25, 2017 • edited Loading

stonier commented Jun 6, 2017 • edited Loading

jamiesnape commented Jun 6, 2017

stonier commented Jun 6, 2017

jwnimmer-tri commented Jun 6, 2017

stonier commented Jun 6, 2017

jamiesnape commented Jun 6, 2017

jwnimmer-tri commented Jun 6, 2017

RussTedrake commented Jun 16, 2017

soonho-tri commented Jun 16, 2017 • edited Loading

RussTedrake commented Jun 16, 2017

RussTedrake commented Jun 16, 2017

soonho-tri commented Jun 16, 2017

RussTedrake commented Jun 16, 2017

jamiesnape commented Jun 16, 2017 • edited Loading

jwnimmer-tri commented Jun 16, 2017

jwnimmer-tri commented Jun 16, 2017

jamiesnape commented Jun 20, 2017

EricCousineau-TRI commented Feb 8, 2018

patmarion commented Apr 4, 2017 •

edited

Loading

patmarion commented May 4, 2017 •

edited

Loading

jamiesnape commented May 25, 2017 •

edited

Loading

stonier commented Jun 6, 2017 •

edited

Loading

soonho-tri commented Jun 16, 2017 •

edited

Loading

jamiesnape commented Jun 16, 2017 •

edited

Loading