The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Bayer decoding can have a noticeable effect on the CPU usage of the camera1394 driver. Doing it in a separate nodelet thread is generally a good idea. The de-Bayer cycles still occur, but they can take advantage of multiple CPUs (if any), and will not delay capturing new frames in the driver.
Looking at your launch file, you passed
<param name="bayer_pattern" value="rggb" />
<param name="bayer_method" value="" />
to image_proc/debayer. That looks wrong. You probably want to pass those values to camera1394/driver, not image_proc. They should cause the driver not to de-Bayer in its own thread.
I cannot tell what parameters are defined by "$(find omnisensor)/params/ffmv.yaml". If you still have problems, perhaps you should add them to your question, as well.
| | 2 | add update |
Bayer decoding can have a noticeable effect on the CPU usage of the camera1394 driver. Doing it in a separate nodelet thread is generally a good idea. The de-Bayer cycles still occur, but they can take advantage of multiple CPUs (if any), and will not delay capturing new frames in the driver.
Looking at your launch file, you passed
<param name="bayer_pattern" value="rggb" />
<param name="bayer_method" value="" />
to image_proc/debayer. That looks wrong. You probably want to pass those values to camera1394/driver, not image_proc. They should cause the driver not to de-Bayer in its own thread.
I cannot tell what parameters are defined by "$(find omnisensor)/params/ffmv.yaml". If you still have problems, perhaps you should add them to your question, as well.
Update
I see you are already passing those same parameters to the driver. Passing them to image_proc should have no effect, so parameter confusion is the not the cause of this problem.
| | 3 | No.3 Revision |
Bayer decoding can have a noticeable effect on the CPU usage of the camera1394 driver. Doing it in a separate nodelet thread is generally a good idea. The de-Bayer cycles still occur, but they can take advantage of multiple CPUs (if any), and will not delay capturing new frames in the driver.
Looking at your launch file, you passed
<param name="bayer_pattern" value="rggb" />
<param name="bayer_method" value="" />
to image_proc/debayer. That looks wrong. You probably want to pass those values to camera1394/driver, not image_proc. They should cause the driver not to de-Bayer in its own thread.
I cannot tell what parameters are defined by "$(find omnisensor)/params/ffmv.yaml". If you still have problems, perhaps you should add them to your question, as well.
Update
I see you are already passing those same parameters to the driver. Passing them to image_proc should have no effect, so parameter confusion is the not the cause of this problem.
There should not be any heavy processing in the driver thread. It does have to allocate an Image message and copy the data there (for publishing shared_ptr to other nodelets). The rest of that thread is mainly libdc1394.
Are you able to distinguish overhead in the camera_nodelet_manager process by thread? If the driver thread uses 60-70%, what about the image_proc thread?
As an experiment, what happens if you don't run image_proc? Can you see Bayer-encoded black and white images on /camera/image_raw? Does that reduce the overhead significantly?
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.