search

wg-perception / object_recognition_core

The core of object recognition, where the development now happens
48 stars 47 forks source link

Camera frame ID isn't being handled in a sane fashion #4

Closed macmason closed 11 years ago

macmason commented 12 years ago

Hard-coding the frame ID in the config file is a hack; a convenient hack, but it should be replaced by something more reasonable; carrying the frame ID around in the pipeline is probably the best answer.

jonbinney commented 12 years ago

Similarly the timestamp will need to be passed around, right?

macmason commented 12 years ago

@jonbinney: yes, presumably. If we're going to add one, we may as well add the other.

jonbinney commented 12 years ago

Looking at ecto_image_pipepline/io/source/ros.py, it looks like the OpenNISubscriber provides the ROS messages for the images, in addition to the images. So (I think?) the frame_id and stamp should already be in the headers for those images.

macmason commented 12 years ago

But ecto is using cv::Mats internally, right? Those don't have the ROS headers attached.

jonbinney commented 12 years ago

It has wrappers for lots of different datatypes, including cv::Mats and some ROS messages (including everything in std_msgs). The ros_kinect node outputs both the "image" (which should be a cv::Mat) and the "image_message" (which should be the wrapped message.

jonbinney commented 12 years ago

This isn't in the ecto core repository though; its in ecto_ros and the ecto_image_pipeline. Are you using the full recognition_kitchen?

macmason commented 12 years ago

This is a kitchen-related bug, but Vincent said I should put it in core, so I did.

jonbinney commented 12 years ago

At least in the tabletop object recognition pipeline, it appears that the rgb_frame_id parameter in the config file is completely ignored, and the frame from the image message is used. I deleted it from the config file with no ill effects. Not sure if the other pipelines use it.