ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Your first case seems to be a bug, please file one on https://github.com/plasmodic/ecto_openni/issues to keep track of it (I am also looking into it at the same time).

We usually do not use the raw openni wrapper but create_source ("from ecto_image_pipeline.io.source import create_source") but that would not work with PCL indeed.

The second is incomplete code, you forgot a "from ecto_ros import ecto_sensor_msgs" and you also need to call "ecto_ros.init(sys.argv, "Whatever")" at first as mentioned on the docs here: http://plasmodic.github.io/ecto_ros/

That second code works for me. Please file a bug if that is not the case for you.

Your first case seems to be a bug, please file one on https://github.com/plasmodic/ecto_openni/issues to keep track of it (I am also looking into it at the same time).

We usually do not use the raw openni wrapper but create_source ("from ecto_image_pipeline.io.source import create_source") but that would not work with PCL indeed.

The second is incomplete code, you forgot a "from ecto_ros import ecto_sensor_msgs" and you also need to call "ecto_ros.init(sys.argv, "Whatever")" at first as mentioned on the docs here: http://plasmodic.github.io/ecto_ros/

That second code works for me. Please file a bug if that is not the case for you.

UPDATE: ok, to answer one of the comments, ecto is definitely maintained, not necessarily developed (I will update the docs for that):

  • ecto had specs that were met and we have not found a core bug in two years (yeah, crazy ...)
  • ecto_ros is mostly autogenerated publishers/subscribers/bad tools around ROS msgs. So nothing to really add (if you think so, please file a bug report)
  • ecto_pcl is not really used anywhere but we can definitely wrap more functionalities.
  • ecto_openni is a wrapper around the OpenNI driver which has been stable for a while, except we usually use the OpenNICapture (bad naming) which works with OpenCV
  • ecto_opencv wraps old or upcoming OpenCV functionalities so we update it once in a while
  • ecto_image_pipeline is a re-write of image_pipeline in ecto and we should probably simply merge it upstream

So, on the ecto side, it's pretty stable and all the nodelets from image_common, image_pipeline, pcl_ros vision_opencv should use it for stability increase (ecto is basically ROS-agnostic Python/C++ stable nodelets with a scheduler). We're kindof waiting on when they'll ask the community about what ROS 2.0 should have before changing everything.