iCub dependencies

[BrutusTT]

Hi,

the human-sensing modul is quite nice and does a good job at recognizing faces and gazeing direction. It would be really useful also in other contexts in which no iCub is involved. But the tide coupling to the gaze controller client and therefore to the iKinGazeCtrl module prevents from using this package without an iCub robot.

I had a brief look into the sources and it appears to me that there are only 3 calls using the gazecontrolclient.

Therefore the question is: Would it be easy to replace these 3 calls using ports instead of the gazecontrolclient? Is there a way to "simulate" a iKinGazeCtrl in case its not present?

[pattacini]

Hi @BrutusTT

Using ports in lieu of the gaze interface is anti-pattern, so I warmly suggest not to pursue this road.

Instead, what the developer in charge could do is pretty much simple: foresee a command line parameter to enable/disable the internal use of the gaze interface (with default value set to on).

[alecive]

Ideally, the perception part should be decoupled (or decouple-able) from the control part, since the tracker should work independently. @BrutusTT feel free to create a pull request on this :)

[pattacini]

Yes, ideally... but then, @alecive, how will the control module look like? Just three lines of codes? It's a matter of trade-off :smile:

[alecive]

This is why I said decouple-able :stuck_out_tongue:

[BrutusTT]

Hi,

I will have a look into it.

But just for the sake of better understanding on my side. Why is decoupling and using ports an anti-pattern? As far as I understand the yarp module architecture its about decoupled components that are communicating through messages. By binding it to a specific interface that most of the time is only being used to internally communicate to iKinGazeCtrl ports itself, its just creating a hard dependency making modules hard to be used with non-iCub robots and introducing a second paradigm of communication (using fixed API instead of ports).

I'm currently working with a different robot for which a video stream is available and has a module that is inline with iKinGazeCtrl messaging but doesn't use iKinGazeCtrl.

What would be the suggested way to deal with this kind of setup?

[pattacini]

Hi @BrutusTT

Ideally, your control module should be wrapped using the gaze interface (maybe implementing only a subset of services that are meaningful to you). This way, human-sensing will remain unchanged, relying on the same client part. You'll only need to specify which server it has to connect to: either iKinGazeCtrl or your controller.

Motor interfaces provide a further abstraction level and thus are definitely preferable over direct port communication:

• They expose a clear API with well documented inputs/outputs; doing the same over ports is not trivial at all and tend to be quite cumbersome (see the documentation of iKinGazeCtrl).
• They hide implementation details that are very likely to change over time, thus they ensure stability and maintainability. Again, iKinGazeCtrl is quite unique of its kind, given that the port comm is fully documented. By contrast, the port exchange is generally not documented for other motor interfaces (e.g. joint control).
• They also ensure decoupling among modules in the same way direct ports comm does. A control channel often foresees rpc communication (i.e. 2-ways comm), where you cannot simply send and forget messages as you would do in streaming, since you have to wait for a reply. Concluding, there's a dependency in the same way you'd have with motor interfaces. Anyway, it's fairly easy to verify whether such a dependency is met at start-up (the device driver will/won't open).

Finally, you could consider following @alecive's suggestion, going toward a bit deeper level of granularity by splitting perception from control: two completely different modules. My objections are:

• In this case the control module would be really too tiny and this approach will force you to come up with another protocol - yet simple - between the perception and the control part.
• As roboticists, we shouldn't always follow software engineering good practices favoring modularity, because often perception and control should/can not be separated :wink:.

[pattacini]

Closing for now, feel free to reopen it.