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

Target Loading Update #76

Merged
merged 11 commits into from
Aug 11, 2020
Merged

Conversation

marip8
Copy link
Collaborator

@marip8 marip8 commented Aug 7, 2020

This PR revises the functions for loading a target definition from YAML file or string path in order to support loading different types of targets (specifically ChArUco and ArUco grid targets).

In order to have the functions with the same parameters (i.e. ROS node handles, strings, etc.) but return a different datatype (i.e. modified circle grid target, ChArUco grid target), I had to create a template struct that is specializable based on the target type.

@schornakj can you review?

@schornakj
Copy link
Contributor

@marip8 I'll take a look!

@schornakj
Copy link
Contributor

@marip8 I noticed that this functionality in rct_ros_tools didn't have any tests previously. Do you think this is a good time to add a test that exercises loading a target from parameters?

@marip8
Copy link
Collaborator Author

marip8 commented Aug 10, 2020

@schornakj I'm getting the following build error on Xenial from the ROS unit test that I added to rct_ros_tools.

target_loader_utest.cpp:(.text._ZN7testing8internal21TypeParameterizedTestI16TargetLoaderTestNS0_11TemplateSelI26TargetLoaderTest_test_TestEENS0_6Types1IN15rct_image_tools24ModifiedCircleGridTargetEEEE8RegisterEPKcRKNS0_12CodeLocationESC_SC_iRKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISM_EE[_ZN7testing8internal21TypeParameterizedTestI16TargetLoaderTestNS0_11TemplateSelI26TargetLoaderTest_test_TestEENS0_6Types1IN15rct_image_tools24ModifiedCircleGridTargetEEEE8RegisterEPKcRKNS0_12CodeLocationESC_SC_iRKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISM_EE]+0x1fd): undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*, char const*, char const*, char const*, testing::internal::CodeLocation, void const*, void ()(), void ()(), testing::internal::TestFactoryBase*)'

I think this might be a result of us downloading GTest for rct_optimizations but trying to link against a version of GTest provided by rostest in the unit test added by this PR. Any thoughts about how to resolve this? I don't think I can use GTest directly because this unit test requires ROS to be launched with parameters in order to successfully execute. Maybe we change which version of GTest we download to match the one included by rostest?

@schornakj
Copy link
Contributor

@marip8 That's rather annoying. I agree that the way around this is probably to make sure that we use the same version of GTest as the one rostest is using.

We might be able to resolve this by changing how we install GTest. Right now we build it from source in the rct_common package, but during my brief research I noticed that there's a rosdep key for GTest, which for Ubuntu points to libgtest-dev. Maybe we can try installing that and see if it'll work with the pure-GTest unit tests in the other packages.

@marip8
Copy link
Collaborator Author

marip8 commented Aug 11, 2020

Per @Levi-Armstrong this issue is fixed by calling find_package(GTest REQUIRED) and targeting against GTest::GTest and GTest::Main before ${catkin_LIBRARIES}, which seems to use the downloaded version of GTest before finding the catkin-provided version.

@marip8 marip8 merged commit 2bd3d87 into Jmeyer1292:master Aug 11, 2020
@marip8 marip8 deleted the update/target_loading branch August 11, 2020 16:13
@jdlangs
Copy link
Collaborator

jdlangs commented Aug 11, 2020

Just curious, what was there reason the templated struct had to be added versus just templating and specializing the functions themselves?

@marip8
Copy link
Collaborator Author

marip8 commented Aug 11, 2020

In order to have the functions with the same parameters (i.e. ROS node handles, strings, etc.) but return a different datatype (i.e. modified circle grid target, ChArUco grid target), I had to create a template struct that is specializable based on the target type.

I ran into build errors initially trying to do what you suggested, so I implemented this solution instead. I didn't look too much into the issue. Ultimately I would like to remove the non-throwing loaders, so maybe we can revisit this in the future.

marip8 added a commit to schornakj/robot_cal_tools that referenced this pull request Aug 25, 2020
* Moved the custom loading exceptions to its own file

* Added new file for loader utils

* Added specializable struct for creating a target object from ROS param

* Added target loader specialization for modified circle grid target

* Integrated target loader struct in rct_ros_tools

* Integrated target loader struct in rct_examples

* Revised modified circle grid target struct

* Added unit test for target loaders
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