ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
Create four different nodehandles with four different names:
ros::NodeHandle nh1("image1");
ros::NodeHandle nh1("image2");
...
And then create four ImageTransports and so on:
image_transport::ImageTransport it1(nh1);
image_transport::ImageTransport it2(nh2);
then you'll get four different camera_info topics:
/image1/camera_info
/image2/camera_info
...
Or skip having four different camera_infos, use a regular ImageTransport::Publisher instead of CameraPublisher, just publish the image from four publishers (building off of http://wiki.ros.org/image_transport/Tutorials/PublishingImages) from the one ImageTransport but any subscriber should have camera_info remapped to the original source one. Even if you are doing something like splitting the images where only every 4th image goes out on the 4th topic, a subscriber that cares about camera_infos will match it up with the right one and ignore the other three camera_infos that don't correspond to any received images (though some nodes will output some warnings about this, they should still function fine).
2 | No.2 Revision |
Create four different nodehandles with four different names:
ros::NodeHandle nh1("image1");
ros::NodeHandle nh1("image2");
...
And then create four ImageTransports and so on:
image_transport::ImageTransport it1(nh1);
image_transport::ImageTransport it2(nh2);
...
then you'll get four different camera_info topics:
/image1/camera_info
/image2/camera_info
...
Or skip having four different camera_infos, use a regular ImageTransport::Publisher instead of CameraPublisher, just publish the image from four publishers (building off of http://wiki.ros.org/image_transport/Tutorials/PublishingImages) from the one ImageTransport but any subscriber should have camera_info remapped to the original source one. Even if you are doing something like splitting the images where only every 4th image goes out on the 4th topic, a subscriber that cares about camera_infos will match it up with the right one and ignore the other three camera_infos that don't correspond to any received images (though some nodes will output some warnings about this, they should still function fine).