Hello,
we really started to use Orocos now.
One question:
For connecting components, when is it better to use a service
and when is it better to use a port?
We currently have the following data processing chain:
1. Ethercat Master, providing services
2. Filter component, querying the services (the Ethercat input modules)
at a fixed frequency (200 or 400 Hz) and distributing the filtered data
to a set of data processing components.
What is the best way to connect a number of data processing components
to the filter component?
Best regards:
Uwe Fechner, TU Delft
Service vs. Port
On Mon, Dec 10, 2012 at 9:45 PM, Uwe Fechner <u [dot] fechner [..] ...> wrote:
> Hello,
>
> we really started to use Orocos now.
>
> One question:
>
> For connecting components, when is it better to use a service
> and when is it better to use a port?
Do you mean 'use a port in a service' versus 'use a port in a component' ?
It's only an architectural choice. New users tend to use ports in
service less, until they feel more confortable with the concept of
dynamic extension of the component interface.
>
> We currently have the following data processing chain:
>
> 1. Ethercat Master, providing services
> 2. Filter component, querying the services (the Ethercat input modules)
> at a fixed frequency (200 or 400 Hz) and distributing the filtered data
> to a set of data processing components.
I'm assuming the 'querying' is done through ports ?
>
> What is the best way to connect a number of data processing components
> to the filter component?
Using ports :-) All data flow should be port-based.
Peter
Service vs. Port
On Thu, 13 Dec 2012, Peter Soetens wrote:
> On Mon, Dec 10, 2012 at 9:45 PM, Uwe Fechner <u [dot] fechner [..] ...> wrote:
>> Hello,
>>
>> we really started to use Orocos now.
>>
>> One question:
>>
>> For connecting components, when is it better to use a service
>> and when is it better to use a port?
>
> Do you mean 'use a port in a service' versus 'use a port in a component' ?
>
> It's only an architectural choice. New users tend to use ports in
> service less, until they feel more confortable with the concept of
> dynamic extension of the component interface.
>
>>
>> We currently have the following data processing chain:
>>
>> 1. Ethercat Master, providing services
>> 2. Filter component, querying the services (the Ethercat input modules)
>> at a fixed frequency (200 or 400 Hz) and distributing the filtered data
>> to a set of data processing components.
>
> I'm assuming the 'querying' is done through ports ?
>
>>
>> What is the best way to connect a number of data processing components
>> to the filter component?
>
> Using ports :-) All data flow should be port-based.
Indeed. Services are meant to support a "command flow", not a "data flow".
(Compare to a web service interface, such as REST
<http://en.wikipedia.org/wiki/Representational_state_transfer>.)
The differences in the _communication_ middleware that transfers both
"flows" might be minor.
But the _policies_ how to buffer the flow messages at the _boundaries_ of a
component are typically very different.
For example: if one component requests a service from another one, it is
natural that (i) the request is not deleted without informing the
requester, and (ii) after the service request has been executed the
requester gets a response. This is typically not the case with data
exchanged between components.
As are the policies with which the _inside_ of a component typically deal
with both kinds of "flows".
For example: different service requests from different components to the
same service component are typically handled separately, while different
data ports are ofte used together within the receiving component.
And then there is still a third "flow" with a different "policy" semantics,
and that are the "events".
For example: an event can _change_ the way the handling component reacts to
its service and data ports.
There will always be use cases that cross the boundaries of the
above-mentioned "definitions"... Or, put it differently: you should
question the semantic clarity of your design if you do not know very well
which "flow" to use for each part of your design :-)
I hope this sheds some light on the topic...
> Peter
Herman
Service vs. Port
On Mon, Dec 10, 2012 at 9:45 PM, Uwe Fechner <u [dot] fechner [..] ...> wrote:
> We currently have the following data processing chain:
>
> 1. Ethercat Master, providing services
> 2. Filter component, querying the services (the Ethercat input modules)
> at a fixed frequency (200 or 400 Hz) and distributing the filtered data
> to a set of data processing components.
>
> What is the best way to connect a number of data processing components
> to the filter component?
Hello Uwe, Greetings from Leuven! We are doing something similar.
We have a component called "masterTimer" that has output ports that
are just used as clock signals with different frequencies. Some of
our hardware (i.e. our ethercat interface and our ethernet connection
to the microcontroller on the plane) we use as low level services, but
usually there is some higher level component calling them at a known
time and writing the results to an output port.
We also have some pure functions (i.e. sensor measurement functions)
that are also in separate components and called as services. Our
camera setup is a funny hybrid; triggering the cameras is a service of
the DAQ (ebox) board, but the firewire cameras then asynchronously
capture and transfer the data to the PC, and another component talks
to the camera driver, does the image processing, and outputs the data
to an output port. Our two biggest components, the state estimator
and the controller, both trigger off an eventport input, and output
their result on an output port.
If a component (i.e. the state estimator) has a bunch of input ports
that should all be used at the same time, we set things up so that the
port that gets written to last is the eventport that actually triggers
the component. This breaks the component abstraction very slightly,
since we're baking something about the timing of the graph into
components at compile time. Maybe the orocos devs know of a better
way.
To stay sane we timed every component and manually "scheduled" what
would execute when. By schedule I don't mean that we hard coded times,
but we do have a diagram drawn to scale of what will we expect to
preempt what at what times. There were multiple ways we could have set
up our triggering to achieve the same sequence of events, and figuring
out what should trigger off of what took a bit of creativity.