Package map fails when Drake is cloned to a folder with name other than "drake"

[rdeits]

Trying to run the humanoid balancing demo currently fails with the following message:

± ./bazel-bin/examples/humanoid_controller/valkyrie_balancing_demo
[2018-01-25 11:35:35.207] [console] [warning] Couldn't find package 'valkyrie' in the supplied packagepath.
[2018-01-25 11:35:35.207] [console] [warning] Mesh 'package://valkyrie/urdf/model/meshes/pelvis/pelvis.dae' could not be resolved and will be ignored by Drake. If you don't want it to be ignored, please include it in the package map.
terminate called after throwing an instance of 'std::runtime_error'
  what():  multibody/parsers/urdf_parser.cc: ParseGeometry: ERROR: Mesh file name could not be resolved from the provided uri "package://valkyrie/urdf/model/meshes/pelvis/pelvis.dae".
[1]    1338 abort (core dumped)  ./bazel-bin/examples/humanoid_controller/valkyrie_balancing_demo

likewise for the simulation:

± bazel-bin/examples/valkyrie/valkyrie_simulation
[2018-01-25 11:34:48.532] [console] [warning] Couldn't find package 'valkyrie' in the supplied packagepath.
[2018-01-25 11:34:48.532] [console] [warning] Mesh 'package://valkyrie/urdf/model/meshes/pelvis/pelvis.dae' could not be resolved and will be ignored by Drake. If you don't want it to be ignored, please include it in the package map.
terminate called after throwing an instance of 'std::runtime_error'
  what():  multibody/parsers/urdf_parser.cc: ParseGeometry: ERROR: Mesh file name could not be resolved from the provided uri "package://valkyrie/urdf/model/meshes/pelvis/pelvis.dae".
[1]    1180 abort (core dumped)  bazel-bin/examples/valkyrie/valkyrie_simulation

The mesh file does exist, and it's still at valkyrie/urdf/model/meshes/pelvis/pelvis.dae, so it would seem that there's something wrong with the parser's package handling. Any suggestions?

Edit: this is because my Drake clone is called drake-distro, and the examples only work if the clone is called drake

[jwnimmer-tri]

I can't immediately reproduce this error. My steps:

• git checkout master (at 741ac01ad963759d3de88611479faf80ecc99c15)
• comment-out the throw std::runtime_error("Gurobi solver not available."); in qp_inverse_dynamics.cc
• bazel build //examples/humanoid_controller:valkyrie_balancing_demo
• bazel-bin/examples/humanoid_controller/valkyrie_balancing_demo then I see

  [2018-01-25 11:54:55.555] [console] [info] Welding joint left_camera_optical_frame_joint
  [2018-01-25 11:54:55.555] [console] [info] Welding joint right_camera_optical_frame_joint

  followed by a long pause.

[jwnimmer-tri]

My only guess at the moment is that DRAKE_RESOURCE_ROOT may be pointing to a problematic copy of the resource, and thus pre-empting use of the copy from the source tree.

I'll come back to this later today and see if there is more debug tracing we can turn on.

[rdeits]

I haven't run this code since before the drake folder hoist. Is there anything special I need to do to account for the hoisting?

[jwnimmer-tri]

Nope, it should just work (without any environment variables). Setting DRAKE_RESOURCE_ROOT is an override that changes where Drake looks; if you had some old value in your shell environment possibly its confusing things, though.

[rdeits]

No, I don't have a DRAKE_RESOURCE_ROOT environment variable in that shell.

[rdeits]

This line looks suspiciously like it's searching up the directory tree for a folder called "drake", which no longer exists: https://github.com/RobotLocomotion/drake/blob/7d805aca8d3636bf343ee824362f2ea237cb8f8a/multibody/parsers/package_map.cc#L175

[rdeits]

Confirmed: changing kDrakeFolderName to drake-distro fixes the issue. It looks like that constant must be exactly equal to the name under which Drake is cloned.

[rdeits]

It appears that this is actually a duplicate of https://github.com/RobotLocomotion/drake/issues/7593 . I'll update the title.

[jwnimmer-tri]

Ah, thanks for diagnosing.

~#7593 fixed the bazel run //examples:foo form to work; this issue it about fixing the bazel-bin/examples/foo form.~

Edit: Actually, that wasn't right. #7593 fixed finding URDFs; this issue is about finding sub-resources like OBJs, based on package.xml search heuristics.

[jwnimmer-tri]

@rdeits I am curious if #7864 fixes it for your case. It seems to work in my testing.

[rdeits]

Thanks! I'll try it out as soon as possible.

[rdeits]

@jwnimmer-tri yes, #7864 seems to fix it for me. Thanks!