-
Notifications
You must be signed in to change notification settings - Fork 493
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
Port moveit_cpp to ROS 2 #163
Conversation
ee43c71
to
4115e29
Compare
4115e29
to
8c853af
Compare
There was a problem hiding this 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 .?
8c853af
to
19d12ce
Compare
|
||
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) |
There was a problem hiding this comment.
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){
...
}
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
moveit_ros/planning_interface/moveit_cpp/include/moveit/moveit_cpp/moveit_cpp.h
Show resolved
Hide resolved
moveit_ros/planning_interface/moveit_cpp/include/moveit/moveit_cpp/moveit_cpp.h
Show resolved
Hide resolved
moveit_ros/planning_interface/moveit_cpp/include/moveit/moveit_cpp/moveit_cpp.h
Show resolved
Hide resolved
moveit_ros/planning_interface/moveit_cpp/include/moveit/moveit_cpp/moveit_cpp.h
Show resolved
Hide resolved
moveit_ros/planning_interface/moveit_cpp/include/moveit/moveit_cpp/moveit_cpp.h
Show resolved
Hide resolved
moveit_ros/planning_interface/moveit_cpp/include/moveit/moveit_cpp/planning_component.h
Show resolved
Hide resolved
moveit_ros/planning_interface/moveit_cpp/include/moveit/moveit_cpp/planning_component.h
Show resolved
Hide resolved
@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()); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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!
+1 feel free to ignore my comments about templates and node components in other PR's as well. |
19d12ce
to
da8698a
Compare
da8698a
to
b01f490
Compare
@mlautman I addressed all comments and rebased onto master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No description provided.