Re: ipc.pdf ... some remarks
Herman Bruyninckx <[email protected]>
| Newsgroups | gmane.science.robotics.orocos.user |
|---|---|
| Message-ID | <Pine.LNX.4.44.0206201154180.11042-100000@pc25-213.mech.kuleuven.ac.be> |
On Thu, 20 Jun 2002, Christian Schlegel wrote: [...guard in battery-level event...] > 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. That is exactly what we want to avoid: reporting to the consumer about an internal state of the producer... > > 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 ... This is what we came up with: every consumer of a battery low event registers with the battery component one event for each level that it wants to be notified for. For example: battery_below_10percent, batter_above_10percent, etc. And the battery component fires these events when the corresponding values are reached. In this way, no guard is needed, and no ambiguity exists about the interpretation of each event. Herman -- K.U.Leuven, Mechanical Engineering, Robotics Research Group <http://www.mech.kuleuven.ac.be/~bruyninc> +32 16 322480