On Thu, Jan 24, 2013 at 1:15 AM, Peter Soetens <peter [..] ...>wrote:

> On Wed, Jan 23, 2013 at 4:25 PM, Adolfo Rodríguez Tsouroukdissian
> <adolfo [dot] rodriguez [..] ...> wrote:
> > Hi all,
> >
> > I have a component that exposes an RTT::Service providing operation,
> > configuration and data flow interfaces. Is it possible to connect all
> > interfaces with a single call?, eg.
> >
> > requires("robot")->connectTo(peer->provides("robot"));
> >
> > Connecting service operations is already very convenient, but I'm not
> sure
> > if the same is possible for ports and properties. This 2010 topic [1]
> pretty
> > much addresses this issue, so I'm wondering what the currrent status is,
> and
> > how others go about it.
>
> I don't know that much users of ServiceRequesters, except those
> already on the list. It only has an advantage in C++ code, and most
> clearly for operations, less clearly for ports or properties.
>

As a disclaimer, my practical experience with Orocos 2.x, and services in
particular is... two days. I'm trying to wrap my head around services and
how to best use them to express design requirements, so please bear with me.

>
> For example, would a Service with input ports have to match a
> ServiceRequester with output ports ? Or would these Output ports
> belong to a Service as usual ? Or to both ?
>

I had that same question on my mind yesterday, whether it makes sense to
expose a service in(out)put port also as an in(out)put port on the
requester side. Are there valid use cases for this?, could this be useful
to achieve composition by interface forwarding?.

>
> Any proposal from your side of what works/solves a problem is a
> welcome light on this topic...
>

Operations like connectPeers match input/output ports with similar names
and types, an _easy_ solution to a _simple_ task, as it should be!. What is
missing is something like connectPeers but within a limited scope. Services
can already be used as a scoping unit for providing a specific interface
(data flow, configuration, operations), what is missing is a convenient way
to connect these interfaces. In the same way one can require() operations,
one could also require() data flow connections, and thus connect to a part
of (or all of) the provided data flow interface.

Maybe a concrete example can help, so read on for some context. Let's
consider the case of a joint controller manager that manages a robot with:
- Velocity controlled mobile base.
- Effort-controlled arms.
- Position controlled pan-tilt unit.
- Position and velocity readings available for all joints.

This joint controller manager should then _provide_:
- A velocity sink only for the joints of the mobile base.
- An effort sink for the arm joints.
- A position sink for the pan-tilt joints.
- A position and velocity source for all joints.

Client controllers would on their part state their requirements. One
particular example: A trajectory interpolator that _requires_ a position
source and sink for all its controlled joints. This controller could be
used directly for the position-controlled pan-tilt unit, but not for the
arms. The latter would require an additional block that sits between the
interpolator and the joint controller manager that converts the position
source into an effort source, eg. a PID controller.

Mapping the above concept of providing and requiring sources and sinks and
managing their connections should involve the least possible amount of red
tape, and I think we're almost there. There's just a bit of tape around
connecting service ports that I'd like to get rid of, if possible.

Thanks for reading,