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

Port moveit_cpp to ROS 2 #163

Merged
merged 1 commit into from
Jan 31, 2020

Conversation

henningkayser
Copy link
Member

@henningkayser henningkayser commented Jan 29, 2020

No description provided.

@henningkayser henningkayser force-pushed the pr-migrate_moveit_cpp branch 4 times, most recently from ee43c71 to 4115e29 Compare January 30, 2020 14:49
@henningkayser henningkayser changed the title WIP: Port moveit_cpp to ROS 2 Port moveit_cpp to ROS 2 Jan 30, 2020
Copy link
Contributor

@JafarAbdi JafarAbdi left a comment

Choose a reason for hiding this comment

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

Are you planning to port the test into a stand-alone PR .?

moveit_ros/planning_interface/CMakeLists.txt Outdated Show resolved Hide resolved
moveit_ros/planning_interface/package.xml Outdated Show resolved Hide resolved
moveit_ros/planning_interface/package.xml Outdated Show resolved Hide resolved

class MoveItCpp
{
public:
/// Specification of options to use when constructing the MoveItCpp class
struct PlanningSceneMonitorOptions
{
void load(const ros::NodeHandle& nh)
void load(const rclcpp::Node::SharedPtr& node)
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason to not use the templated approach that is popular in the ros2 code base?

template<class NodeT>
void load(NodeT && node){
    return load(node->get_node_parameters_interface())
}
void load(rclcpp::node_interfaces::NodeParametersInterface::SharedPtr& node_parameters_interface){
    ...
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Right now this is just a migration step so I didn't consider it. We're planning to make a bigger refactoring for parameter loading that includes declaring all parameters that we use. However, I don't see a real upside to use the template version, why do you think we should use it?

Copy link
Contributor

Choose a reason for hiding this comment

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

It would be nice to be able to use weak pointers but to be honest, I really don't see that as a strong enough use case for going back and templating everything

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, I see that it can make sense of you structure your library around the node components (which would actually be very nice) but introducing this in an existing library is probably not that easy. I would be interested in some discussions how we can improve node management in MoveIt for later milestones.

@henningkayser
Copy link
Member Author

@mlautman I think you're right about using the node templates for end consumers, but here we are using and sharing (probably) all components of the node. We would have to start by refactoring node use in all used components and then work our way up until these base classes. A big downside of this approach would be that we would heavily restrict what we can do inside the member classes, so for now I wouldn't go this path.

{
if (!tf_buffer_)
tf_buffer_.reset(new tf2_ros::Buffer());
tf_listener_.reset(new tf2_ros::TransformListener(*tf_buffer_));
tf_buffer_ = std::make_shared<tf2_ros::Buffer>(node_->get_clock());
Copy link
Contributor

Choose a reason for hiding this comment

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

Something to consider: You may need to establish what time of clock is used by the tf_bufffer. Most every example I found in the ros2 code base uses auto clock = std::make_shared<rclcpp::Clock>(RCL_ROS_TIME)) to ensure that the TF buffer uses the correct clock

Copy link
Member Author

Choose a reason for hiding this comment

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

That's actually a good point. I wasn't aware that system time was the default in the clock constructor. However, nodes always use ROS time, so using Node::get_clock() and Node::now() is valid everywhere you want to use ROS time.

Copy link
Contributor

@mlautman mlautman left a comment

Choose a reason for hiding this comment

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

Overall just a few nits. Good job!

@mlautman
Copy link
Contributor

+1 feel free to ignore my comments about templates and node components in other PR's as well.

@henningkayser
Copy link
Member Author

@mlautman I addressed all comments and rebased onto master

Copy link
Contributor

@nbbrooks nbbrooks left a comment

Choose a reason for hiding this comment

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

minor

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.

I don't think I'm very qualified to give this ROS 2 stuff an approval, but since @nbbrooks and @mlautman approved.

@davetcoleman davetcoleman merged commit 9e32ec5 into moveit:master Jan 31, 2020
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

5 participants