Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use drake cmakelists #233

Merged
merged 9 commits into from
Jan 20, 2018
Merged

use drake cmakelists #233

merged 9 commits into from
Jan 20, 2018

Conversation

manuelli
Copy link
Collaborator

@manuelli manuelli commented Jan 18, 2018

  • bump drake to master and use CMake build that wraps bazel
  • remove drake-schunk-driver built with bazel, rely on ros package version
  • build libbot from source since it's gone from drake

This change is Reviewable

@manuelli
Copy link
Collaborator Author

manuelli commented Jan 19, 2018

@gizatt looks like the build is failing due to an issue with VHACD which is part of your trimesh external project. Do you know what the issue is? Can you either fix it? In the meantime I disabled with WITH_TRIMESH flag for jenkins.

@gizatt
Copy link
Collaborator

gizatt commented Jan 19, 2018

I'm seeing an Apriltags build error, not VHACD, in the Jenkins build log:

21:29:49 CMakeFiles/drc-apriltags-driver.dir/apriltags_driver.cpp.o: In function `AprilTagDetector::AprilTagDetector(getopt*)':
21:29:49 apriltags_driver.cpp:(.text._ZN16AprilTagDetectorC2EP6getopt[_ZN16AprilTagDetectorC5EP6getopt]+0x2c2): undefined reference to `YAML::LoadFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
21:29:49 apriltags_driver.cpp:(.text._ZN16AprilTagDetectorC2EP6getopt[_ZN16AprilTagDetectorC5EP6getopt]+0x317): undefined reference to `YAML::detail::node_data::begin()'
21:29:49 apriltags_driver.cpp:(.text._ZN16AprilTagDetectorC2EP6getopt[_ZN16AprilTagDetectorC5EP6getopt]+0x3ec): undefined reference to `YAML::detail::node_data::end()'
21:29:49 collect2: error: ld returned 1 exit status
21:29:49 src/CMakeFiles/drc-apriltags-driver.dir/build.make:170: recipe for target 'bin/drc-apriltags-driver' failed
21:29:49 make[8]: *** [bin/drc-apriltags-driver] Error 1
21:29:49 CMakeFiles/Makefile2:117: recipe for target 'src/CMakeFiles/drc-apriltags-driver.dir/all' failed
21:29:49 make[7]: *** [src/CMakeFiles/drc-apriltags-driver.dir/all] Error 2
21:29:49 Makefile:127: recipe for target 'all' failed
21:29:49 make[6]: *** [all] Error 2
21:29:49 CMakeFiles/apriltags_driver.dir/build.make:112: recipe for target 'src/apriltags_driver-stamp/apriltags_driver-build' failed
21:29:49 make[5]: *** [src/apriltags_driver-stamp/apriltags_driver-build] Error 2
21:29:49 CMakeFiles/Makefile2:404: recipe for target 'CMakeFiles/apriltags_driver.dir/all' failed
21:29:49 make[4]: *** [CMakeFiles/apriltags_driver.dir/all] Error 2
21:29:49 make[4]: *** Waiting for unfinished jobs....

The old use-Drake-CMakelists upgrade had a VHACD failure, so I would expect to see one here (it has to be related to an environment change due to the top-level CMake changes). It's OK to turn it off to get this old branch landed if you can verify the error still happens -- change the default in the top-level CMakelist and change the Jenkins CMake build command in setup/build/run_jenkins.sh

@manuelli
Copy link
Collaborator Author

manuelli commented Jan 19, 2018

The build is now failing with


CMakeFiles/drc-apriltags-driver.dir/apriltags_driver.cpp.o: In function `AprilTagDetector::AprilTagDetector(getopt*)':
21:29:49 apriltags_driver.cpp:(.text._ZN16AprilTagDetectorC2EP6getopt[_ZN16AprilTagDetectorC5EP6getopt]+0x2c2): undefined reference to `YAML::LoadFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
21:29:49 apriltags_driver.cpp:(.text._ZN16AprilTagDetectorC2EP6getopt[_ZN16AprilTagDetectorC5EP6getopt]+0x317): undefined reference to `YAML::detail::node_data::begin()'
21:29:49 apriltags_driver.cpp:(.text._ZN16AprilTagDetectorC2EP6getopt[_ZN16AprilTagDetectorC5EP6getopt]+0x3ec): undefined reference to `YAML::detail::node_data::end()'
21:29:49 collect2: error: ld returned 1 exit status
21:29:49 src/CMakeFiles/drc-apriltags-driver.dir/build.make:170: recipe for target 'bin/drc-apriltags-driver' failed
21:29:49 make[8]: *** [bin/drc-apriltags-driver] Error 1
21:29:49 CMakeFiles/Makefile2:117: recipe for target 'src/CMakeFiles/drc-apriltags-driver.dir/all' failed
21:29:49 make[7]: *** [src/CMakeFiles/drc-apriltags-driver.dir/all] Error 2
21:29:49 Makefile:127: recipe for target 'all' failed
21:29:49 make[6]: *** [all] Error 2

it looks like apriltags driver is not finding yaml-cpp. @jamiesnape I am guessing this related to this PR? This is in the director build and I guess drake no longer supplies yaml-cpp linker flags.

@gizatt yes the original error was VHACD, which I then fixed by disabling it in the jenkins build. This yaml-cpp error is new.

@jamiesnape
Copy link

@manuelli
Copy link
Collaborator Author

@jamiesnape so I guess drake still has yaml-cpp,. I am not sure why the apriltags-driver is suddenly having problems linking against yaml-cpp. Do you think it is related to the bug in yaml-cpp mentioned in RobotLocomotion/drake#7602? As a short term fix we can disable apriltags_drivers as no one is using them.

@jamiesnape
Copy link

jamiesnape commented Jan 19, 2018

Looks like the variable yaml-cpp_LIBRARIES referred to here is called YAML_CPP_LIBRARIES in the system installed library: https://github.com/patmarion/apriltags_driver/blob/fb0eff3f569b70de14ce8d7398fef98263f12446/src/CMakeLists.txt#L46

(${yaml-cpp_LIBRARIES} would resolve to the empty string so you end up with no link flags)

@manuelli
Copy link
Collaborator Author

manuelli commented Jan 19, 2018

Ok thanks @jamiesnape that makes sense. I will implement a fix upstream in the apriltags driver or disable it. It seems like adding yaml-cpp to target_link_libraries fixes things.

@jamiesnape
Copy link

Yes:

# - Config file for the yaml-cpp package
# It defines the following variables
#  YAML_CPP_INCLUDE_DIR - include directory
#  YAML_CPP_LIBRARIES    - libraries to link against

...

# These are IMPORTED targets created by yaml-cpp-targets.cmake
set(YAML_CPP_LIBRARIES "yaml-cpp")

@@ -11,6 +11,8 @@ include_directories(${Eigen3_INCLUDE_DIR})
find_package(VTK REQUIRED)
include_directories(${VTK_INCLUDE_DIRS})

find_path(yaml-cpp REQUIRED)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

find_package ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, typo on my part. Just pushed a fix.

@manuelli
Copy link
Collaborator Author

I just tested the IK issue from #234 and it seems to be working fine. I think this is ready to be merged. @peteflorence @gizatt

@gizatt
Copy link
Collaborator

gizatt commented Jan 19, 2018

:lgtm:


Reviewed 1 of 3 files at r1, 4 of 5 files at r2, 1 of 1 files at r3, 1 of 2 files at r4, 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 2 unresolved discussions.


src/ReachabilityAnalyzer/CMakeLists.txt, line 26 at r5 (raw file):

    ${VTK_LIBRARIES}
    RemoteTreeViewerWrapper
    yaml-cpp)

I think more "correct" would be ${YAML_CPP_LIBRARIES}, but this is probably safer since that variable name hasn't been consistent across system-vs-local Yaml in the recent past...


Comments from Reviewable

@manuelli
Copy link
Collaborator Author

manuelli commented Jan 22, 2018

@jamiesnape @fbudin69500 I was under the impression that the bot_core python package and bot_core lcmtypes were provided by libbot correct? From what I understand drake no longer has libbot, but does it still build those lcmtypes? We have somehow ended up with two versions of the bot_core python package installed. One is in

spartan/build/install/lib/python2.7/site-packages/bot_core

and the other in

spartan/build/install/lib/python2.7/dist-packages/bot_core

They have a very different set of lcmtypes. In particular the one in site-packages has many more, including position_3d_t. Is one of these being installed by drake and the other by the libbot CMake External project? This is all related to issue #236.

In particular some drake lcmtypes use bot_core lcmtypes as fields, see here

@jamiesnape
Copy link

jamiesnape commented Jan 22, 2018

They have a very different set of lcmtypes. In particular the one in site-packages has many more, including position_3d_t. Is one of these being installed by drake and the other by the libbot CMake External project?

Yes, there was a fork of the bot_core lcmtypes to https://github.com/openhumanoids/bot_core_lcmtypes.

@jamiesnape jamiesnape deleted the UseDrakeCMakeLists-merge branch January 22, 2018 20:40
@jamiesnape
Copy link

(you probably want the site-packages version first in your PYTHONPATH)

@manuelli
Copy link
Collaborator Author

Yeah I am coming to that conclusion. Somehow when I launch files a particular way the dist-packages gets put in front. Is there a way to avoid having two copies of bot_core installed?

@jamiesnape
Copy link

Somehow when I launch files a particular way the dist-packages gets put in front.

Via directorPython?

@manuelli
Copy link
Collaborator Author

Looks like the bot-procman-sheriff executable is modifying the PYTHONPATH.

#!/bin/sh
export PYTHONPATH=/home/manuelli/spartan/build/install/lib/python2.7/dist-packages:/home/manuelli/spartan/build/install/lib/python2.7/site-packages:${PYTHONPATH}
exec /usr/bin/python -m bot_procman.sheriff_gtk.sheriff_gtk $*

I am guessing that bot-procman-sheriff is installed by libbot.

@manuelli
Copy link
Collaborator Author

manuelli commented Jan 22, 2018

bot-procman-sheriff is modifying the pythonpath. Looks like that logic is happening here. So it is putting dist-packages ahead of site-packages. I don't know the logic behind modifying the pythonpath in the bot-procman-sheriff executable.

@jamiesnape
Copy link

I guess we should be appending rather than prepending, I will PR a change.

@manuelli
Copy link
Collaborator Author

Thanks. Once we do that should we update spartan to point to libbot/master?

@jamiesnape
Copy link

Yes, RobotLocomotion/libbot2@0813e5a.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants