-
Notifications
You must be signed in to change notification settings - Fork 303
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
Nacho/re enable ipc #253
Nacho/re enable ipc #253
Conversation
It's the same but seems to be a more common practice in ROS 2 codebases
@roncapat I know you might be quite busy :) But if you don't mind taking a look into this I'd be delighted, you are the authority in terms of IPC for me :P Thanks :) |
Hi Ignacio, from my experience using const Basically with the constness you are guaranteeing the IPC manager that you will not edit that memory region, but read only, so you can share among multiple subscribers with no issues IIRC. |
Wow! Thanks for the fast reply! So I guess it's again me just being paranoid. Then this doesn't change anything right? As long as the "data producers" use But then how does it work with the shared_ptr? Does it still eat the same piece of memory on the heap? |
Yeah basically this promotion happens when using the pattern I described: |
Oh yeah! thanks for pointing to the implementation! I was doing a bit of "testing" anyway, so posting it here in case anyone is also curious. namespace kiss_icp_ros {
class Dummy : public rclcpp::Node {
public:
/// Dummy constructor
Dummy() = delete;
explicit Dummy(const rclcpp::NodeOptions &options) : rclcpp::Node("dummy_node", options) {
pointcloud_sub_ = create_subscription<sensor_msgs::msg::PointCloud2>(
"pointcloud_topic", rclcpp::SensorDataQoS(),
std::bind(&Dummy::CallBack, this, std::placeholders::_1));
pointcloud_pub_ =
create_publisher<sensor_msgs::msg::PointCloud2>("/kiss/input", rclcpp::SensorDataQoS());
RCLCPP_INFO(this->get_logger(), "DUMMY node initialized");
}
/// Register new frame
void CallBack(sensor_msgs::msg::PointCloud2::UniquePtr msg) {
printf("Published message with stamp: %d, and address: 0x%" PRIXPTR "\n",
msg->header.stamp.sec, reinterpret_cast<std::uintptr_t>(msg.get()));
pointcloud_pub_->publish(std::move(msg));
}
/// Data subscribers.
rclcpp::Subscription<sensor_msgs::msg::PointCloud2>::SharedPtr pointcloud_sub_;
rclcpp::Publisher<sensor_msgs::msg::PointCloud2>::SharedPtr pointcloud_pub_;
};
} // namespace kiss_icp_ros
#include "rclcpp_components/register_node_macro.hpp"
RCLCPP_COMPONENTS_REGISTER_NODE(kiss_icp_ros::Dummy) Then added this on the composable launch file: ComposableNode(
package="kiss_icp",
plugin="kiss_icp_ros::Dummy",
name="dummy_node",
extra_arguments=[{"use_intra_process_comms": True}],
remappings=[("pointcloud_topic", LaunchConfiguration("topic"))],
), The correspondence print msg on the "consumer" on this composition and the results are just amazing: [component_container-1] Published message with stamp: 1697626087, and address: 0x5653678DE080
[component_container-1] Received message with stamp: 1697626087, and address: 0x5653678DE080 |
@roncapat I've updated the PR with just 1 bit. Since I was still getting this error, thanks a lot for looking over !!!
|
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.
Sorry for the late reply! I was planning to dive more into ROS2 components and IPC when reviewing this, but I did not find the time. However, this PR looks fine from my side!
Fix
IPC
forOdometryServer
in ROS 2 wrapperOld Description
After #163 was merged, #171 was also added. But we missed the fact that the subscription must be done with
unique_ptr
if zero-copy intra-process communication should be enabled.From the ROS 2 Intra-Process-Communication documentation:
After debating and testing with @roncapat I realized that I was panicking with no reason about
unique_ptr
Nevertheless, I've changed a bit (QoS) that was not working for me when composing the node and also relaxed a bit the rviz topic subscriptionsOpen questions
.launch.py
files, one for "plain nodes" + "composable nodes", or just use the old launch file and let the users compose "their own" nodes? A: No, it doesn't make sense to have 2 launch files for mePlayer
andRecorder
nodes ros2/rosbag2#902) this seems like a silly idea. A: Yes it is a silly idea.