Ask Your Question
0

Beginning with ECTO

asked 2013-03-25 05:15:42 -0600

updated 2014-01-28 17:15:53 -0600

ngrennan gravatar image

Hello I am fairly new to the world of ECTO and I am trying to create something similar to the http://wg-perception.github.com/object_recognition_core/ (Object Recognition Kitchen) for our own purposes. The idea is to create an adaptive pipeline which is able to change what implementation is being used to solve a problem based on the input from the environment and the feedback from various nodes.

The basic concept was to have the system essentially broken down into the initial 3 steps:

  • Data Capture
  • Filtering Step(s)
  • Segmentation Step(s)

This is where my confusion begins. I am trying to set up the framework and to get everything organized and I am not sure I am grasping the point of ECTO. We want to leverage ECTO for its ability to dynamically connect and disconnect various cells as well as its built in life cycle for the cells. What I am not sure of is how to organize the file structure to best represent this.

Should I have each one of the above tasks as its own "repository" with the cells and module inside of it or should it be in one "perception pipeline" repository which contains inside of the "cells" folders different modules which will be able to communicate with each other? I have seen several different versions from the GitHub repositories and I am wondering if there is a best practices or something out there to guide me in setting all of this up.

I have tried to find out this basic information by going through the documentation but it is sadly lacking in what I assume to be fairly basic information either that or I have missed it entirely. If anyone could point out how this should be set up as I need all of the modules to be able to talk to each other and to interact with the scheduler which will be added at a later date.

Any pointers you could provide would be very helpful!

All the best, Mat

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2013-03-25 10:42:42 -0600

fergs gravatar image

Generally speaking, the repositories are broken up in such a way to minimize the dependency tree of each. For instance, ecto_opencv, ecto_pcl, and ecto_ros each have a significant major dependency (opencv, pcl, ros respectively). The idea here is that many people may only want 2d-image functions and will never use ecto_pcl, so there is no sense installing so many packages to make ecto_pcl work (and vice versa if you are using 3d features primarily).

If all of your cells are interrelated and intended to be used together, then I would suggest a single repository for your new cells. Regardless of where you build your cells, at runtime, it won't make much difference other than your import statements to bring those cells into your final pipeline.

edit flag offensive delete link more

Comments

Thanks @fergs this was a big help. It leads me to my next question about plasms maybe you have some pointers? I have started a second question to ensure this did not become a multiquestion post: http://answers.ros.org/question/59156/connecting-plasms-in-ecto/

BadRobot gravatar imageBadRobot ( 2013-03-25 11:04:06 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2013-03-25 05:15:42 -0600

Seen: 179 times

Last updated: Mar 25 '13