Re: ipc.pdf ... some remarks

Christian Schlegel <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Organization FAW Ulm
Message-ID <[email protected]>
Herman Bruyninckx wrote:

> On Thu, 20 Jun 2002, Christian Schlegel wrote:
>
> [...]
> > > I describe a lower-level implementation, that should be compatible
> > > with _any_ IPC. (If that is not the case, then something is wrong :-))
> > > And the goal is to maybe come to a core library that many other Orocos
> > > libraries could use...
> >
> > Ok, but at this level it might be interesting to check if there are any parts
> > which are not compatible with middleware like CORBA. If yes, that is an
> > important topic to talk about ...
>
> I _think_ nothing is incompatible with CORBA. How could it?

Yes, that really is true since CORBA leaves you alone when you have to decide on
how to structure a complex application. That is exactly where the OROCOS framework
is more than just middleware and I was in some sense irritated because I got the
impression that your proposal is more like "let us provide everything which might
be needed" instead of "we know what is needed above general IPC to end up with
structured complex systems"

> [...]
> > Ok, mechanism and policy are sometimes difficult to differentiate since I do
> > not want to implement all kinds of mechanisms which might be needed but are
> > not yet needed. So sometimes the tradeoff is to implement only those
> > mechanisms which are needed for a specific policy.
>
> Indeed! That's what I say in the text also. And this was exactly my
> motivation: find the minimum set of mechanisms that _all_ Orocos
> components need. And if we can implement this set in the Core (as
> Peter and Takis are doing now), it could help the project a lot as far
> as code and documentation reuse is concerned :-)

Yes

> > But of course the overall
> > mechanisms should fit together in a coherent way.
>
> Exactly. And this coherence can only come from looking at the
> mechanisms of different Orocos components from distance. And by
> somebody who is not too involved in all the particular components. And
> I think that's me :-)

Yes, I agree. And even that we are all working on different levels of robotic
systems we end up at general mechanisms, which I think is very promising for our
approaches !

> [...]
> > > Can you give an example of where you need a guard?
> >
> > Very simple example: An event pattern is used to report on the battery
> > voltage. Therefore the producer of the event reads the battery voltage
> > regularly and has to decide when to fire the event. It now might have various
> > components which have to be notified on specific voltage levels. Activating
> > the event from the consumer includes the voltage threshold.
>
> Ok, good example! This `guard' doesn't leave the event mediator, so I
> don't have a problem with that. I even think this is not a guard, but
> part of the listener that the event consumers have registered with the
> event object.

The question is what has to be transmitted to consumers. If I have the check for
the event condition at the producer I do not have to transmit anything to the
consumer (sometimes it is not only the battery voltage but an image e.g.). An
important reason why I want to have the event check at the producer is because I
have access to several producer internal states which I can collect in case the
event fires. I can report a complete state to the consumer.

> Another approach is that the component that is
> responsible for the battery has a method that others can use to fire
> an event under specific battery load conditions.
>
> I'll discuss this example with Takis and Peter...

Ok ...

>
>
> [...]
> > > interesting for the public.... Let me know if you don't mind if I post
> > > these messages to the list.
> >
> > Yes, you can post it ....
>
> Fine :-)
>
> Herman

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.