[WIP] enforce passing Capture by their Sensor

As discuss (and agreed) during our last meeting, captures should be added to the problem through their sensor as it makes more sense than having them free-floating and calling the ->process() function themselves.

Processing a capture is now done within the call of my_sensor->addCapture(my_capture) rather than calling it directly (my_capture->process()).

This PR is WIP as I would like to propose to remove the SensorBasePtr from the CaptureBase constructor. :

from

CaptureBase(const std::string& _type, const TimeStamp& _ts, SensorBasePtr _sensor_ptr = nullptr);

to

CaptureBase(const std::string& _type, const TimeStamp& _ts);

as it is also set in SensorBase::addCapture(...).

Mentioned in merge request !90 (closed)

@jsola @joanvallve @acoromin ping.

I think this issue is also related with the wolf tree building/destructing mechanisms:

From nodeLinked, we had parent-oriented mechanisms (parents adds/removes their childs to/from the tree, so also set all the pointers, etc).

Now that we have removed nodeLinked and we can rethink that. I think that we should move to self-oriented mechanisms (each node adds/removes itself to/from the tree, set all pointers to their parents and add itself to the list of childs...)

So, in that specific case (but coherently with all type of nodes), the capture constructor should have the pointer to its parent (frame) and its sensor.

However, the sensor should have something like createCapture() analogously to the installSensor(), installProcessor()orcreateFrame()` in which the sensor pointer wouldn't be necessary as you say. What do you think?

I do agree about passing the sensor pointer to the constructor of a capture, it makes sense. I am not sure about the parent frame as I don't have a full insight of this mechanism yet. The point of this PR is mostly about the capture entry-point into the wolf problem, more than where/how is the sensor pointer set.

How would you imagine a createCapture() ?? I think that the problem with having such a function is that according to the semantic, and possibly the logic, it would require to create a fully constructed Capture (with the data properly set-up). The problem is then how would you do that assuming that the data can come in all kind of form ?? (e.g. an image can be opencv Mat, or from another lib, or custom etc). I think that for now we better keep the current flow, let the user create a capture and fill it with it's data but pass it to the wolf problem through a Sensor::addCapture(...).

Status changed to merged

@joanvallve I see the point. As for now, and as a matter of reference, Wolf creation / addition / removal / destruction of nodes is as follows:

Creation: Through the following mechanisms:

• Constructor, e.g. FrameBase::FrameBase(...) <-- This is forbidden in Problem
• Creator method, e.g. static FrameBase::create(...) <-- this is mandatory in Problem
• Factory, e.g. FrameFactory::get()->create(...) <-- This is highly recommended in Sensor and Processor
• Installer, e.g. Problem::installSensor(...) <-- This is highly recommended in Sensor and Processor

Addition: through the parent's addX() method

Removal: through the node remove() method

Destruction: Automatic through shared_ptr