Dear all,
I need to implement the "coordination" part for the component.
I want to use rFSM as task describer ("Boss") and I want to set, in the
configuration step
of component, the code that allows to catch the state of "Boss" and
changes the behaviour
and properties.
Any suggestions?
Fabrizio
p.s. Greetings to everybody!
Coordination of component
On Fri, 13 Jul 2012, Fabrizio Boriero wrote:
> Dear all,
> I need to implement the "coordination" part for the component.
>
> I want to use rFSM as task describer ("Boss") and I want to set, in the
> configuration step of component, the code that allows to catch the state
> of "Boss" and changes the behaviour and properties.
What do you mean exactly with "to catch the state"?
> Any suggestions?
>
> Fabrizio
>
>
> p.s. Greetings to everybody!
Thanks! :-)
Herman
Coordination of component
On Fri, Jul 13, 2012 at 1:03 PM, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Fri, 13 Jul 2012, Fabrizio Boriero wrote:
>
>> Dear all,
>> I need to implement the "coordination" part for the component.
>>
>> I want to use rFSM as task describer ("Boss") and I want to set, in the
>> configuration step of component, the code that allows to catch the state
>> of "Boss" and changes the behaviour and properties.
>
>
> What do you mean exactly with "to catch the state"?
The FSM declares its current state and the component
do some actions for that point of the task
es. "event" o--[ FSM ]--o "current_state" "current_state" o--[
Coordination of component { switch(current_state) case "A":... case
"B".... ]--o "event"
Am I wrong?
Fabrizio
>
>
>> Any suggestions?
>>
>> Fabrizio
>>
>>
>> p.s. Greetings to everybody!
>
>
> Thanks! :-)
>
> Herman
Coordination of component
On Fri, 13 Jul 2012, Fabrizio Boriero wrote:
> On Fri, Jul 13, 2012 at 1:03 PM, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Fri, 13 Jul 2012, Fabrizio Boriero wrote:
>>
>>> Dear all,
>>> I need to implement the "coordination" part for the component.
>>>
>>> I want to use rFSM as task describer ("Boss") and I want to set, in the
>>> configuration step of component, the code that allows to catch the state
>>> of "Boss" and changes the behaviour and properties.
>>
>>
>> What do you mean exactly with "to catch the state"?
>
> The FSM declares its current state and the component
> do some actions for that point of the task
>
> es. "event" o--[ FSM ]--o "current_state" "current_state" o--[
> Coordination of component { switch(current_state) case "A":... case
> "B".... ]--o "event"
>
> Am I wrong?
I don't know :-) Since I do not completely understand your explanation :-)
Anyway, what the FSM _should_ be doing is to listen to events that other
components fire, and to interpret them with some event logic, which
possibly result in one or more events sent out. The other components then
use those events to reconfigure what they are doing.
This is theory. In practice, many people let the state machine do the
configuration directly. I don't like that at all, since this couples the
logic of an application too much with the specific configuration values of
one particular robot system. Hence, reducing the reusability of the FSM.
>
> Fabrizio
Herman
>>> Any suggestions?
>>>
>>> Fabrizio
>>>
>>>
>>> p.s. Greetings to everybody!
>>
>>
>> Thanks! :-)
>>
>> Herman
>
Coordination of component
...
>>
>> Am I wrong?
>
> I don't know :-) Since I do not completely understand your explanation :-)
> Anyway, what the FSM _should_ be doing is to listen to events that other
> components fire, and to interpret them with some event logic, which
> possibly result in one or more events sent out. The other components then
> use those events to reconfigure what they are doing.
>
> This is theory. In practice, many people let the state machine do the
> configuration directly. I don't like that at all, since this couples the
> logic of an application too much with the specific configuration values of
> one particular robot system. Hence, reducing the reusability of the FSM.
This is the point! One solution is that the component has a memory
allocation that allows
to put, in the configuration step, the code that understand what the
rFSM event means...
But how is it possible in (best) practice? :D
>>
>> Fabrizio
>
> Herman
>
>>>> Any suggestions?
>>>>
>>>> Fabrizio
>>>>
>>>>
>>>> p.s. Greetings to everybody!
>>>
>>>
>>> Thanks! :-)
>>>
>>> Herman
>>
>
Coordination of component
On Sat, 14 Jul 2012, Fabrizio Boriero wrote:
> ...
>>>
>>> Am I wrong?
>>
>> I don't know :-) Since I do not completely understand your explanation :-)
>> Anyway, what the FSM _should_ be doing is to listen to events that other
>> components fire, and to interpret them with some event logic, which
>> possibly result in one or more events sent out. The other components then
>> use those events to reconfigure what they are doing.
>>
>> This is theory. In practice, many people let the state machine do the
>> configuration directly. I don't like that at all, since this couples the
>> logic of an application too much with the specific configuration values of
>> one particular robot system. Hence, reducing the reusability of the FSM.
>
> This is the point! One solution is that the component has a memory
> allocation that allows
> to put, in the configuration step, the code that understand what the
> rFSM event means...
>
> But how is it possible in (best) practice? :D
Again, your comment is not really clear to me...:-( More in particular,
what do you mean with "the code that understands what the rFSM event
means"? This is the implementation of the FSM in the COordinator component,
so, plain C++ or Lua.
>>> Fabrizio
Herman
>>>>> Any suggestions?
>>>>>
>>>>> Fabrizio
>>>>>
>>>>>
>>>>> p.s. Greetings to everybody!
>>>>
>>>>
>>>> Thanks! :-)
>>>>
>>>> Herman
>>>
>>
>
Coordination of component
>
> > This is the point! One solution is that the component has a memory
> > allocation that allows
> > to put, in the configuration step, the code that understand what the
> > rFSM event means...
> >
> > But how is it possible in (best) practice? :D
> Again, your comment is not really clear to me...:-( More in particular,
> what do you mean with "the code that understands what the rFSM event
> means"? This is the implementation of the FSM in the COordinator component,
> so, plain C++ or Lua.
I'm joining to the discussion, hopefully in order to "solve"
misunderstanding (and not generating more chaos...)
As far I understand, a component can provide some ports, services and so
on...hence, a (computational) component can provide (through ports
(EventPorts) as implementation part in Orocos); the component can react to
an event (executing the code into the callback), or it can generate an
event (caused by internal reasons/features).
In conclusion, the (computational) components, in according to his internal
use, already define how to react to some events, or when generate some
other events. The behavior, the reaction to one specific event is defined
inside the component which receive the event, not on external components.
The coordinator instead have to know in advance which events can be used/is
provided by the set of components inside your system. As the name suggest,
the coordinator "coordinate" existing components, sending events in
according to the (prior) knowledge about every single component.
So
> One solution is that the component has a memory
> allocation that allows
> to put, in the configuration step, the code that understand what the
> rFSM event means...
It's not the component that have to deal/understand what the rFSM means,
but at the opposite, it's the rFSM that send a specific event because it
has a specific meaning on that component.
Just a simple example: a component which communicate/control a mobile
platform can provide an even "reset_odometry", which assume (in this case)
a kind of client-server paradigm. How that component reset the odometry is
not important, but the (r)FSM which coordinate the whole system (or part of
it, like the navigation part) will raise a "reset_odometry" event in
accoring to the state of the "task" (or application? which name is more
appropriate in this case?). For instance, before to start to navigate (init
phase), or because some third component provide a better localisation pose
after some time (ie. marker found and the robot know exactly where it is..)
Once again, it's the coordinator that have to know what "reset_odometry"
means in according to what the (computational) component provide.
I don't know if I explain it properly, neither if my "vision" is right, so
please correct me if I am wrong!!
- Enea
Coordination of component
In my opinion it's a problem of subdivision between the components of the
system that should follow a certain logic behaviour (i.e. task supervisor)
and the remaining components that are supposed to work at a lower level
(i.e. ethercat motor drives). Let me give you an example: if I need to
implement the control system of a robot I'll (probably) need at least one
Supervisor component who can receive/send events from/to the outer world.
If the Supervisor receives the event "e_move" and it is in a compatible
state, it will (for example) check for a KDL::Frame in input and send it to
a trajectory generator or to a "kinematics and dynamics" block. So the
Supervisor has a knowledge of the meaning of the event "e_move" but this is
not needed anymore when we move to the "lower level" components for which
the Supervisor can directly generate outputs in accordance with the current
state of the state machine. In this way the lower level components are
indipendent from the presence of a Supervisor or any other components able
to generate the data that they need in order to work (you should anyway
have some coordination mechanism between the different parts of the
system). At least this is my idea about the separation between the logic
and the "operative" parts of the system.
2012/7/16 Enea Scioni <scnnee [..] ...>
> > This is the point! One solution is that the component has a memory
>> > allocation that allows
>> > to put, in the configuration step, the code that understand what the
>> > rFSM event means...
>> >
>> > But how is it possible in (best) practice? :D
>> Again, your comment is not really clear to me...:-( More in particular,
>> what do you mean with "the code that understands what the rFSM event
>> means"? This is the implementation of the FSM in the COordinator
>> component,
>> so, plain C++ or Lua.
>
>
> I'm joining to the discussion, hopefully in order to "solve"
> misunderstanding (and not generating more chaos...)
> As far I understand, a component can provide some ports, services and so
> on...hence, a (computational) component can provide (through ports
> (EventPorts) as implementation part in Orocos); the component can react to
> an event (executing the code into the callback), or it can generate an
> event (caused by internal reasons/features).
> In conclusion, the (computational) components, in according to his
> internal use, already define how to react to some events, or when generate
> some other events. The behavior, the reaction to one specific event is
> defined inside the component which receive the event, not on external
> components.
> The coordinator instead have to know in advance which events can be
> used/is provided by the set of components inside your system. As the name
> suggest, the coordinator "coordinate" existing components, sending events
> in according to the (prior) knowledge about every single component.
>
> So
>
>> One solution is that the component has a memory
>> allocation that allows
>> to put, in the configuration step, the code that understand what the
>> rFSM event means...
>
> It's not the component that have to deal/understand what the rFSM means,
> but at the opposite, it's the rFSM that send a specific event because it
> has a specific meaning on that component.
>
> Just a simple example: a component which communicate/control a mobile
> platform can provide an even "reset_odometry", which assume (in this case)
> a kind of client-server paradigm. How that component reset the odometry is
> not important, but the (r)FSM which coordinate the whole system (or part of
> it, like the navigation part) will raise a "reset_odometry" event in
> accoring to the state of the "task" (or application? which name is more
> appropriate in this case?). For instance, before to start to navigate (init
> phase), or because some third component provide a better localisation pose
> after some time (ie. marker found and the robot know exactly where it is..)
> Once again, it's the coordinator that have to know what "reset_odometry"
> means in according to what the (computational) component provide.
>
> I don't know if I explain it properly, neither if my "vision" is right, so
> please correct me if I am wrong!!
>
> - Enea
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
Coordination of component
>
> In my opinion it's a problem of subdivision between the components of the
> system [...] At least this is my idea about the separation between the
> logic and the "operative" parts of the system.
I think it's right, at least as main idea.
Anyway
> If the Supervisor receives the event "e_move" and it is in a compatible
> state, it will (for example) check for a KDL::Frame in input and send it to
> a trajectory generator or to a "kinematics and dynamics" block.
I am not so sure if it's supervisor responsability to deliver "KDL::Frame"
to the trajectory generator(or other computational component(s) responsible
to start the movement).
Mainly because of (i) in this way, you define the datatype of the "goal"
(KDL::Frame in this case) - maybe you don't want to specify that datatype
at supervisor level. Then you can reuse/replace the "trajectory generator"
component with other ones which use different datatype as "goal".
(ii) For semantic reasons/separation between coordination and computation.
Supervisor shouldn't deal with data, or be used as "data interface" with
the "higher" level, or as multiplexer, delivering data infos. Hence, once
received the event "e_move", the "trajectory generator" should take care
"to listen" the goal to be computed: the fact that he received that event
enable to accept that data and process the output (because of the
compatible state for a movement, as described by Nicola previously).
- Enea
Coordination of component
Yes, I get your point of view, I conceptually agree on the fact that
probably there should not be passage of data through a Supervisor and in
fact mine was just an example (may be a wrong one ;) ) to explain the
passage from a component that handles events to a component that handles
data. A solution may be in the creation of an EventPort in the subordinate
component on which the Supervisor may send a command (or just a boolean
flag) in order to ask for a certain action (i.e. check a particular input
port for new data, a KDL::Frame in the previous example). Can we call it
coordination?
Nicola
PS - I'm sorry, I did not sign my previous post!
2012/7/16 Enea Scioni <scnnee [..] ...>
> In my opinion it's a problem of subdivision between the components of the
>> system [...] At least this is my idea about the separation between the
>> logic and the "operative" parts of the system.
>
> I think it's right, at least as main idea.
>
> Anyway
>
>> If the Supervisor receives the event "e_move" and it is in a compatible
>> state, it will (for example) check for a KDL::Frame in input and send it to
>> a trajectory generator or to a "kinematics and dynamics" block.
>
> I am not so sure if it's supervisor responsability to deliver "KDL::Frame"
> to the trajectory generator(or other computational component(s) responsible
> to start the movement).
> Mainly because of (i) in this way, you define the datatype of the "goal"
> (KDL::Frame in this case) - maybe you don't want to specify that datatype
> at supervisor level. Then you can reuse/replace the "trajectory generator"
> component with other ones which use different datatype as "goal".
> (ii) For semantic reasons/separation between coordination and computation.
> Supervisor shouldn't deal with data, or be used as "data interface" with
> the "higher" level, or as multiplexer, delivering data infos. Hence, once
> received the event "e_move", the "trajectory generator" should take care
> "to listen" the goal to be computed: the fact that he received that event
> enable to accept that data and process the output (because of the
> compatible state for a movement, as described by Nicola previously).
>
> - Enea
>
>
Coordination of component
On Mon, Jul 16, 2012 at 11:50:56AM +0200, Nicola Preda wrote:
> Yes, I get your point of view, I conceptually agree on the fact that
> probably there should not be passage of data through a Supervisor and in
> fact mine was just an example (may be a wrong one ;) ) to explain the
> passage from a component that handles events to a component that handles
> data. A solution may be in the creation of an EventPort in the subordinate
> component on which the Supervisor may send a command (or just a boolean
> flag) in order to ask for a certain action (i.e. check a particular input
> port for new data, a KDL::Frame in the previous example). Can we call it
> coordination?
The paper about separating "4C" says that "The _coordination part_ defines
patterns of interactions, ie. it determines _when_ certain communication take
place." If the decision about "when" something should happen requires to
analyse some data, then I see nothing wrong to pass this data to the
"Supervisor." On the other hand, I think, that sending any data not related to
_when_ out the "Supervisor" (e.g., in the form of command arguments or boolean
flag) violates the separation of "4C."
Please correct me if I am wrong.
Coordination of component
On Mon, 16 Jul 2012, Piotr Trojanek wrote:
> On Mon, Jul 16, 2012 at 11:50:56AM +0200, Nicola Preda wrote:
>> Yes, I get your point of view, I conceptually agree on the fact that
>> probably there should not be passage of data through a Supervisor and in
>> fact mine was just an example (may be a wrong one ;) ) to explain the
>> passage from a component that handles events to a component that handles
>> data. A solution may be in the creation of an EventPort in the subordinate
>> component on which the Supervisor may send a command (or just a boolean
>> flag) in order to ask for a certain action (i.e. check a particular input
>> port for new data, a KDL::Frame in the previous example). Can we call it
>> coordination?
>
> The paper about separating "4C" says that "The _coordination part_ defines
> patterns of interactions, ie. it determines _when_ certain communication take
> place." If the decision about "when" something should happen requires to
> analyse some data, then I see nothing wrong to pass this data to the
> "Supervisor."
We went from the original "4C" paper to a "5C" version, exactly to separate
"Coordination" and "Configuration" :-)
This material has not yet really been published in a decent way,
unfortunately :-( Should be done by the end of the Summer...
> On the other hand, I think, that sending any data not related to
> _when_ out the "Supervisor" (e.g., in the form of command arguments or boolean
> flag) violates the separation of "4C."
>
> Please correct me if I am wrong.
I do not understand your last sentence...
> Piotr Trojanek
Herman
Coordination of component
On Mon, Jul 16, 2012 at 12:41:50PM +0200, Herman Bruyninckx wrote:
> >The paper about separating "4C" says that "The _coordination part_ defines
> >patterns of interactions, ie. it determines _when_ certain communication
> >take place." If the decision about "when" something should happen requires
> >to analyse some data, then I see nothing wrong to pass this data to the
> >"Supervisor."
>
> We went from the original "4C" paper to a "5C" version, exactly to separate
> "Coordination" and "Configuration" :-)
The paper I am referring to [1] already separates "Coordination" and
"Configuration" (?!).
In particular, section 2.2 "From Configuration to Coordination" talks about
_dynamic coordination_, i.e., changes of the interaction patters that are
triggered by computational agents. I guess, that this is what Nicola means when
saying that "[Supervisor] ... will (for example) check for a KDL::Frame in
input."
> This material has not yet really been published in a decent way,
> unfortunately :-( Should be done by the end of the Summer...
>
> >On the other hand, I think, that sending any data not related to
> >_when_ out the "Supervisor" (e.g., in the form of command arguments or boolean
> >flag) violates the separation of "4C."
> >
> >Please correct me if I am wrong.
>
> I do not understand your last sentence...
The above section is not clear about sending data from the coordination part to
the computation part. It allows the coordination part to "interfere with
interactions." However, I think that this is not what Nicola means when saying
that "the Supervisor will send the KDL::Frame to a trajectory generator." I
think, that such a transmission is not the best practice for the coordination.
[1] M. Radestock and S. Eisenbach, "Coordination in Evolving Systems."
http://www.springerlink.com/content/743j11671438km0q/
Coordination of component
On Mon, 16 Jul 2012, Piotr Trojanek wrote:
> On Mon, Jul 16, 2012 at 12:41:50PM +0200, Herman Bruyninckx wrote:
>>> The paper about separating "4C" says that "The _coordination part_ defines
>>> patterns of interactions, ie. it determines _when_ certain communication
>>> take place." If the decision about "when" something should happen requires
>>> to analyse some data, then I see nothing wrong to pass this data to the
>>> "Supervisor."
>>
>> We went from the original "4C" paper to a "5C" version, exactly to separate
>> "Coordination" and "Configuration" :-)
>
> The paper I am referring to [1] already separates "Coordination" and
> "Configuration" (?!).
Their "configuration" is basically what we (more correctly) call
"Composition"... Or a vague mixture of Composition and Coordination.
Anyway, [1] has a lot less clean and clear view on the separation of
concerns than we have now. And this thread is an example of that :-)
> In particular, section 2.2 "From Configuration to Coordination" talks about
> _dynamic coordination_, i.e., changes of the interaction patters that are
> triggered by computational agents. I guess, that this is what Nicola means when
> saying that "[Supervisor] ... will (for example) check for a KDL::Frame in
> input."
>
>> This material has not yet really been published in a decent way,
>> unfortunately :-( Should be done by the end of the Summer...
>>
>>> On the other hand, I think, that sending any data not related to
>>> _when_ out the "Supervisor" (e.g., in the form of command arguments or boolean
>>> flag) violates the separation of "4C."
>>>
>>> Please correct me if I am wrong.
>>
>> I do not understand your last sentence...
>
> The above section is not clear about sending data from the coordination part to
> the computation part. It allows the coordination part to "interfere with
> interactions." However, I think that this is not what Nicola means when saying
> that "the Supervisor will send the KDL::Frame to a trajectory generator." I
> think, that such a transmission is not the best practice for the coordination.
>
I agree.
> [1] M. Radestock and S. Eisenbach, "Coordination in Evolving Systems."
> http://www.springerlink.com/content/743j11671438km0q/
>
Coordination of component
On Mon, 16 Jul 2012, Nicola Preda wrote:
> Yes, I get your point of view,
(Note: It's best not to top post (<http://en.wikipedia.org/wiki/Top_posting>) when
replying to an ongoing thread, because it's impossible to know exactly to
what parts of the thread you are referring/replying/....)
> I conceptually agree on the fact that probably there should not
> be passage of data through a Supervisor and in fact mine was just an example (may be a wrong one
> ;) ) to explain the passage from a component that handles events to a component that handles
> data. A solution may be in the creation of an EventPort in the subordinate component on which
> the Supervisor may send a command (or just a boolean flag) in order to ask for a certain action
> (i.e. check a particular input port for new data, a KDL::Frame in the previous example). Can we
> call it coordination?
You can! :-) The best "real world" metaphor is the "CEO" as manager
("Coordinator") of a company: the CEO takes the decisions to put the other
people in the company to work in a certain way, but these decisions do not
contain the operational data that the company workers work with.
The "5C" approach advocated by the BRICS project foresees a separate
"Configuration" components (possibly integrated into a Computational
component) that reacts to the "CEO/COordinator" events and reconfigures the
component it is responsible for to switch to the right "behaviour".
Separating the decision making (event-based Coordination) from the
execution of the decision ((re-)Configuration) makes it easier to port the
Coordinator from one robot platform to another: while the Coordinatoed task
might be the same, the configuration of the components involved will be
different for different "platforms".
> Nicola
Herman
>
> PS - I'm sorry, I did not sign my previous post!
>
> 2012/7/16 Enea Scioni <scnnee [..] ...>
> In my opinion it's a problem of subdivision between the components of
> the system [...] At least this is my idea about the separation between
> the logic and the "operative" parts of the system.
>
> I think it's right, at least as main idea.
>
> Anyway
> If the Supervisor receives the event "e_move" and it is in a compatible state,
> it will (for example) check for a KDL::Frame in input and send it to a
> trajectory generator or to a "kinematics and dynamics" block.
>
> I am not so sure if it's supervisor responsability to deliver "KDL::Frame" to the
> trajectory generator(or other computational component(s) responsible to start the
> movement).
> Mainly because of (i) in this way, you define the datatype of the "goal" (KDL::Frame in
> this case) - maybe you don't want to specify that datatype at supervisor level. Then you
> can reuse/replace the "trajectory generator" component with other ones which use different
> datatype as "goal".
> (ii) For semantic reasons/separation between coordination and computation. Supervisor
> shouldn't deal with data, or be used as "data interface" with the "higher" level, or as
> multiplexer, delivering data infos. Hence, once received the event "e_move", the
> "trajectory generator" should take care "to listen" the goal to be computed: the fact that
> he received that event enable to accept that data and process the output (because of the
> compatible state for a movement, as described by Nicola previously).
>
> - Enea
>
>
>
>
Coordination of component
....
>
> Separating the decision making (event-based Coordination) from the
> execution of the decision ((re-)Configuration) makes it easier to port the
> Coordinator from one robot platform to another: while the Coordinatoed task
> might be the same, the configuration of the components involved will be
> different for different "platforms".
>
>> Nicola
>
>
> Herman
In the end I think that the easiest way is to do something like this:
http://dl.dropbox.com/u/24297622/coordination.png
So I make a "snapshot" of the proprieties (variable part of behaviour)
of the components for every state and than I call
the right "snapshot" when I go inside a new FSM state.
Regards,
Fabrizio
Coordination of component
Hi Fabrizio,
On Fri, Jul 20, 2012 at 01:51:04PM +0200, Fabrizio Boriero wrote:
> ....
> >
> > Separating the decision making (event-based Coordination) from the
> > execution of the decision ((re-)Configuration) makes it easier to port the
> > Coordinator from one robot platform to another: while the Coordinatoed task
> > might be the same, the configuration of the components involved will be
> > different for different "platforms".
> >
> >> Nicola
> >
> >
> > Herman
>
> In the end I think that the easiest way is to do something like this:
> http://dl.dropbox.com/u/24297622/coordination.png
>
> So I make a "snapshot" of the proprieties (variable part of behaviour)
> of the components for every state and than I call
> the right "snapshot" when I go inside a new FSM state.
I think this is the best you can currently do. We are working on a
"Configurator" component that switches between such configurations
upon receiving an event, but it's not there yet.
Best regards
Markus
Coordination of component
On Fri, 20 Jul 2012, Fabrizio Boriero wrote:
> ....
>>
>> Separating the decision making (event-based Coordination) from the
>> execution of the decision ((re-)Configuration) makes it easier to port the
>> Coordinator from one robot platform to another: while the Coordinatoed task
>> might be the same, the configuration of the components involved will be
>> different for different "platforms".
>>
>>> Nicola
>>
>>
>> Herman
>
> In the end I think that the easiest way is to do something like this:
> http://dl.dropbox.com/u/24297622/coordination.png
>
> So I make a "snapshot" of the proprieties (variable part of behaviour)
> of the components for every state and than I call
> the right "snapshot" when I go inside a new FSM state.
Conceptually yes. But I would not "call" anything from the FSM, just send
out a corresponding event, to which all components can react and do the
necessary "calling" themselves. Decoupling the "calling" from the event has
the following advantages:
- one event can be reacted to by multiple components,
- they could react in parallel
- the logic of the Coordinator is easier to port to similar applications or
platforms, where the "calling" would be different but not the
meaning/intention of why the coordination takes place.
> Regards,
> Fabrizio
Herman
Coordination of component
On 07/21/2012 05:26 PM, Herman Bruyninckx wrote:
> Conceptually yes. But I would not "call" anything from the FSM, just send
> out a corresponding event, to which all components can react and do the
> necessary "calling" themselves. Decoupling the "calling" from the
> event has
> the following advantages:
> - one event can be reacted to by multiple components, - they could
> react in parallel
> - the logic of the Coordinator is easier to port to similar
> applications or
> platforms, where the "calling" would be different but not the
> meaning/intention of why the coordination takes place.
>
I completely agree with you but the point is: How?
In my context (surgical tasks) the actions described by the events are
very specific and task-dependent so
the logic have to be changed for every specific task or following the
surgeon actions.
The summary is that the "logic" can not be coded inside the component
(or we lose the generality) and I don't know how to do in
a "dynamic" way.
Regards,
Fabrizio
>Herman
Coordination of component
On Mon, 23 Jul 2012, Fabrizio Boriero wrote:
> On 07/21/2012 05:26 PM, Herman Bruyninckx wrote:
>> Conceptually yes. But I would not "call" anything from the FSM, just send
>> out a corresponding event, to which all components can react and do the
>> necessary "calling" themselves. Decoupling the "calling" from the event
>> has
>> the following advantages:
>> - one event can be reacted to by multiple components, - they could react
>> in parallel
>> - the logic of the Coordinator is easier to port to similar applications
>> or
>> platforms, where the "calling" would be different but not the
>> meaning/intention of why the coordination takes place.
>>
> I completely agree with you but the point is: How?
>
> In my context (surgical tasks) the actions described by the events are very
> specific and task-dependent so
> the logic have to be changed for every specific task or following the surgeon
> actions.
Probably yes. The portability does not work between different tasks, but
between different robot systems that do the same task.
The Coordinator is the _main_ source of "added value" in a robot
application. (Together with the "Configuration" components, that decouple
the specific robot platform from the task COordination.)
But Coordination is also the most time consuming, for the human expert.
> The summary is that the "logic" can not be coded inside the component (or we
> lose the generality) and I don't know how to do in
> a "dynamic" way.
"Dynamic" = changing at runtime? State machines can in principle be
adapated online; the RTT Lua state machines allows this, for example.
> Regards,
> Fabrizio
Herman