[Bug 423] New: [Project] Improve Component execution model

For more information about this bug, visit
A new bug was added:
Summary: [Project] Improve Component execution model
Product: RTT
Version: 1.2.0
Platform: All
OS/Version: All
Status: NEW
Severity: project
Priority: P2
Component: Real-Time Toolkit (RTT)
AssignedTo: orocos-dev [..] ...
ReportedBy: peter [dot] soetens [..] ...

As the ROSTA (http://www.robot-standards.eu) and OMG Robotics
(http://robotics.omg.org/) groups are acknowledging, there are three main
execution models (i.e. ways in which the component algorithm is executed) in
component based robotics: periodic, event driven and invoked (from a central
component). Orocos has very good support for periodic component execution, very
good support for component method invocations, but poor support for event
driven data flows.

Event driven data flows can only exist if: 1. the component data ports emit
internal events upon reception of data, such that a function can handle the
incomming data; and 2. the component has a state in which it accepts this data
and allows the functions to handle the data. Orocos components have neither
explicitly built in. This causes that Orocos components are mainly 'polling'
for data in a periodic thread, which performs poorly in distributed systems.
Research revealed that most, (if not all) distributed robotics middleware
(Mico, GeNoM, Orca II, Constellation,...) use event driven data flow primarily.

In order to remedy this, two actions need to be undertaken:
1. next to DataPort and BufferPort, there is an EventPort (or similar) which
calls a component function when data arrives. It would also be possible to
extend DataPort and BufferPort such that they emit these events.
2. The component state diagram must be updated such that an 'Active' state is
present in a component, similar to the 'active' status of an Orocos State
Machine in which events are processed, but no periodic execution is done.

Both action points can be done in a backwards manner. 1. introduces a new class
or extends an existing class. 2. adds an extra 'may skip' state in the
component state diagram.

Special attention must be directed at making sure that components with
different execution models can still communicate. For example, that a component
with periodic execution can still connects its data ports with event driven
components and vice verse.

--
(this mail is best viewed with a fixed font)
Configure bugmail: https://www.fmtc.be/orocos-bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Bug 423] [Project] Improve Component execution model

For more information about this bug, visit
A comment was added:
------- Comment #3 from herman [dot] bruyninckx [..] ... 2007-06-27 15:05

(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > >
> > > Event driven data flows can only exist if: 1. the component data ports emit
> > > internal events upon reception of data, such that a function can handle the
> > > incomming data; and 2. the component has a state in which it accepts this data
> > > and allows the functions to handle the data.
> >
> > I don't fully understand what this state means... Can you give a simple
> > example, please? At first sight, it seems to me that this state belongs to
> > the _application_ state machine, and not to the infrastructure state
> > machine in the RTT middlewere...

[Bug 423] [Project] Improve Component execution model

For more information about this bug, visit
A comment was added:
------- Comment #2 from peter [dot] soetens [..] ... 2007-06-27 14:52

(In reply to comment #1)
> (In reply to comment #0)
> >
> > Event driven data flows can only exist if: 1. the component data ports emit
> > internal events upon reception of data, such that a function can handle the
> > incomming data; and 2. the component has a state in which it accepts this data
> > and allows the functions to handle the data.

[Bug 423] [Project] Improve Component execution model

For more information about this bug, visit
A comment was added:
------- Comment #1 from herman [dot] bruyninckx [..] ... 2007-06-26 22:43

(In reply to comment #0)
> As the ROSTA (http://www.robot-standards.eu) and OMG Robotics
> (http://robotics.omg.org/) groups are acknowledging, there are three main
> execution models (i.e. ways in which the component algorithm is executed) in
> component based robotics: periodic, event driven and invoked (from a central
> component). Orocos has very good support for periodic component execution, very
> good support for component method invocations, but poor support for event
> driven data flows.