passing sensor_msgs::Image across different processes
Hi All,
I have a working ROS program that contains two nodes:
usb_cam_node (
/opt/ros/electric/stacks/bosch_drivers/usb_cam/src/usb_cam_node
) , andA node named B that processes videos with cv_bridge.
The basic logic of this program is simple:
usb_cam_node gets a video frame from the USB camera, and then publishes a message (of type
sensor_msgs::ImageConstPtr& msg
) onto a topic to which B subscribes;B has a callback function that processes the frame upon receiving a message. This callback function looks like this:
callbackB(const sensor_msgs::ImageConstPtr& msg){//Do image processing}
So far usb_cam_node and B are working fine on Ubuntu 10.10.
Now I plan to move the image processing part within callbackB(const sensor_msgs::ImageConstPtr& msg)
to a real-time task spawned by Xenomai APIs within B. B and this real-time task, say, R, are two different processes, although R is spawned within B. In this new version, callbackB(const sensor_msgs::ImageConstPtr& msg)
now only notifies R the receiving of msg
and sends &msg
to R. Once R have &msg
, it is supposed to do the exactly same thing as the old version of callBackB() does. In my experiment, R can read some basic frame (image) info such as msg->height
, which means R should get the correct (?) reference to the image via msg
; However, the whole program crashes when cv_bridge::toCvCopy(msg, enc::BGR8);
is called.
I am confused here: It seems R gets the correct reference to msg
(i.e., &msg
), as msg->height
gets the correct value. Then why the whole program crashes when cv_bridge::toCvCopy(msg, enc::BGR8);
is called? In GDB, I did notice something related to segment fault when this call is executed. Is this related to the fact that msg
is a "smart pointer" instead of a normal C++ pointer? Did I wrongly assume that B and R have the same address space? (But then why R can read msg->height
correctly?)
With Man Thanks,
Tom
RT_TASKS
spawned byrt_task_create(..)
or similar can be considered threads, all within the same process. This would makeR
not a "different process" (Just realized this is an old question). Also:cv_bridge::toCvCopy()
in a real-time task?