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

Melodic robot model testing utils #1176

Conversation

BryceStevenWilley
Copy link
Contributor

Description

Originally discussed in #1126, this PR provides a Builder class for making RobotModels. While it's aimed at making it very simple to make a specific RobotModel with the details you need for a test, I'm making it able to handle more complex Models as well.

I'm marking this as a WIP because there are a few tests that I haven't converted to use this yet, and I wanted to ask for feedback: does it look easy to use, etc. It's not going to be useful if we (the developers/community) think the interface is clunky or verbose.

Checklist

  • Required by CI: Code is auto formatted using clang-format
  • Extended the tutorials / documentation:
    Inline docs are present, but a section under the tutorials would be nice too.
  • Document API changes relevant to the user in the moveit/MIGRATION.md notes
  • Created tests, which fail without this PR reference
  • Decide if this should be cherry-picked to other current ROS branches (should not)

Copy link
Contributor

@rhaschke rhaschke left a comment

Choose a reason for hiding this comment

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

Great contribution! Thanks a lot for this effort. I have only some minor remarks.

* \param[in] joint_origins The "parent to joint" origins for the joints connecting the links. If not used, all
* origins will default to the identity transform
*/
void add(std::string section, std::string type, std::vector<geometry_msgs::Pose> joint_origins = {});
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not using enum JointModel::JointType for type instead of string? Strings are always error-prone.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I like this idea, but JointModel::JointType doesn't have a CONTINUOUS value. Since this is writing directly to URDF, which does support continuous, we'd have to stick with strings.

add_library(${MOVEIT_LIB_NAME} src/lexical_casts.cpp)
set_target_properties(${MOVEIT_LIB_NAME} PROPERTIES VERSION ${${PROJECT_NAME}_VERSION})
if(CATKIN_ENABLE_TESTING)
add_library(${MOVEIT_LIB_NAME}
Copy link
Member

Choose a reason for hiding this comment

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

i don't like how this library changes scope based on whether testing is enabled or not. why not just have a separate library for things that are only for tests, and other utils?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can do a separate library. My main concern was requiring moveit_resources to build moveit_core, which didn't seem right.

@@ -0,0 +1,178 @@
/*********************************************************************
Copy link
Member

Choose a reason for hiding this comment

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

is this intended to be used anywhere that is not test-specific? if not, rename file to something like robot_model_test_utils.h

if you intend to use it outside of test, i'm concerned it has duplicate functionality with
https://github.com/ros-planning/moveit/tree/melodic-devel/moveit_ros/planning/rdf_loader
https://github.com/ros-planning/moveit/tree/melodic-devel/moveit_ros/planning/robot_model_loader

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not intended to be used elsewhere, I'll clarify that. Also, wasn't aware of those other methods, neat.

Copy link
Member

Choose a reason for hiding this comment

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

I didn't do a deep dive, but do you think can we get rid of the rdf_loader after this is added? Or are they very different things? I haven't looked in a few years

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wouldn't say they're very different, rdf_loader seems to be a bit more general, looks like it handles Xacro files as well. It wouldn't be hard to move rdf_loader into moveit_core/utils and merge with loadTestingRobotModel() et al. though. Should that be another PR, or should it go it here?

Copy link
Member

Choose a reason for hiding this comment

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

Looking at it further, the rdf_loader has more ROS dependencies than allowed in moveit_core, e.g.

#include <ros/ros.h>
#include <ros/package.h>

For example it uses the parameter server. While I am conflicted about moveit_core's level of ROS-agnotistism (not very, but still a little) I think that's a discussion for another issue/PR. I'd say let's move with this PR as-is

moveit_core/utils/src/robot_model_builder.cpp Outdated Show resolved Hide resolved
moveit_core/utils/src/robot_model_builder.cpp Outdated Show resolved Hide resolved
if (link_names.empty())
{
ROS_ERROR_NAMED(LOGNAME, "No links specified (empty section?)");
return;
Copy link
Member

Choose a reason for hiding this comment

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

if this is going to be used for unit tests it seems the function should return false?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm, that's a good point. However, I don't think I like the tests looking like this:

bool is_valid = true;
is_valid = is_valid && builder.add(....);
is_valid = is_valid && builder.add(....);
...
ASSERT_TRUE(is_valid);

The same thing can be done internally, so most of tests should just look like:

builder.add(...);
builder.add(...);
...
ASSERT_TRUE(builder.isValid());

moveit_core/utils/src/robot_model_builder.cpp Outdated Show resolved Hide resolved
Copy link
Member

@davetcoleman davetcoleman left a comment

Choose a reason for hiding this comment

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

This is a really great contribution that levels-up moveit!

@davetcoleman
Copy link
Member

Before we merge this, can you make a short PR to the tests tutorial explaining how to use this and linking to an example file or two in the code base?

@davetcoleman
Copy link
Member

Also please remove WIP when you're ready

@BryceStevenWilley BryceStevenWilley changed the title WIP: Melodic robot model testing utils Melodic robot model testing utils Nov 1, 2018
@BryceStevenWilley
Copy link
Contributor Author

Should be ready. Ended up making a conscious choice not to add enough features to converts bits of code like this, since it would make the interface too complicated to be used easily. Might tackle that in a later PR.

Copy link
Contributor

@rhaschke rhaschke left a comment

Choose a reason for hiding this comment

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

Some more comments. Otherwise lgtm.

moveit_core/utils/CMakeLists.txt Outdated Show resolved Hide resolved
@rhaschke rhaschke merged commit 0e40658 into moveit:melodic-devel Nov 2, 2018
@davetcoleman
Copy link
Member

Whoo-hoo!

@BryceStevenWilley BryceStevenWilley deleted the melodic-robot-model-testing-utils branch November 3, 2018 13:51
sjahr pushed a commit to sjahr/moveit that referenced this pull request Jun 21, 2024
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.

None yet

3 participants