[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] Port connections in real-time?
From:       peter.soetens () gmail ! com (Peter Soetens)
Date:       2010-03-16 9:21:28
Message-ID: 201003161021.28355.peter.soetens () gmail ! com
[Download RAW message or body]

On Tuesday 09 March 2010 14:01:08 Stephen Roderick wrote:
> On Mar 9, 2010, at 05:25 , Peter Soetens wrote:
> > On Friday 05 March 2010 22:14:25 S Roderick wrote:
> >> A while back Peter mentioned that making/breaking port connections was
> >> not a real-time operation in v1.x. Can anyone (cough, Peter) elaborate
> >> more on this?
> >
> > It depends. In 1.x, each connection object (lookup ConnectionInterface)
> > has a connect()/disconnect() feature that tries to form all connections
> > across all ports part of that connection. A port can only be part of one
> > 'connected' connection object, but may be part of any number of
> > disconnected connection objects. connect()/disconnect() is a real-time
> > operation.
> >
> > As such, you can have multiple connection objects that share the same
> > ports and carefully connect/disconnect them such that no two 'connected'
> > connection objects touch the same ports.
> 
> Huh? So using two separate connection objects between the same two ports ==
>  bad?

It's not bad (ie it is allowed), but if you try to connect() one such 
connection object which points to an already connected port, the connect() 
call will fail, until you disconnect that port, by calling disconnect on that 
port or by disconnecting the connection using that port.

> 
> > The deployer is unaware of this feature.
> 
> Understood.
> 
> >> We have an application where one component has multiple possible input
> >> image sources. We can't afford the overhead of a coordinating component
> >> multiplexing between the multiple sources (the image copy is too
> >> expensive on this little CPU), and I'm wondering about just
> >> making/breaking port connections instead. This is a soft real-time
> >> system, so we could probably deal with the non-real-time aspects vs the
> >> image copy overhead.
> >>
> >> Just trying to get more details ... grok'ing the source hasn't helped
> >> much ...
> >
> > I don't fully understand the architecture. in RTT 1.x, multiplexing is
> > always enabled because any number of readers and writers may share a
> > connection. Do you mean that you can't stop the producers from producing
> > images ? In that case, the above solution would work.
> 
> Imagine an application with a "Front" camera component, and a "Side" camera
>  component. Both have an "Image" port. The "Image" port of each camera
>  component is connected to multiple other components. We also have an
>  "Analysis" component that has a single "Image" port. For one application
>  we connect just one camera to the Analysis component, but in another
>  application we want to be able to switch between cameras. Possible options
>  are
> 
> 1) Make another Analysis component that is 2-camera aware, and can
>  coordinate itself between them.
> 
> 2) Put a coordinating component between the 2 cameras and the Analysis
>  component, which just selects one of its two input images and copies it to
>  an output port (which is connected to Analysis)
> 
> 3) Use a coordinating component that can switch the Image port connection
>  on Analysis, between the two cameras. This would not affect any existing
>  connections.

So this is possible in 1.x

> 
> 4) Duplicate the Analysis component and connect one instance to Front, and
>  one to Side. Use a coordinator that starts/stops things appropriately.

5) Connect both Camera components to the analysis port and start the camera 
needed/ stop the camera unneeded. If your camera is providing images to other 
parts than Analysis, this is no option of course.

> 
> The first is not scalable and is more maintenance, the second has overhead
>  we can't afford, and the third is the option I was considering. Realise
>  that we have more than one Analysis component that requires this
>  switching.
> 
> I have already implemented the fourth version, but would like to see if 3)
>  was possible. I have other problems that might require something like that
>  in the future. Also, I think 3) would be less code than 4), and definitely
>  cleaner.

There's not much 'common sense' in the current connection mechanism. In 2.x, 
we could do 3) only if we a. break+create connections or b. allow to 'disable' 
a connection between camera X and Analysis.

Peter

[prev in list] [next in list] [prev in thread] [next in thread]