[ros-users] Current state of SMACH in ROS

[Herman Bruyninckx]

On Sun, 19 Feb 2012, Ingo Lütkebohle wrote:

> On Sat, Feb 18, 2012 at 10:23 PM, Herman Bruyninckx
> <Herman.Bruyninckx at mech.kuleuven.be> wrote:
>> I know at least one area where it achieves a lot less: reusability of the
>> coordination over different platforms. And the reason being that the data
>> flow state is a lot more tied to one particular platform than the "logic"
>> in a pure coordinator. ("Pure" meaning: only doing event logic
>> computations.) We have encountered lots of examples where it was impossible
>> to transfer an application written for one robot platform to another one
>> that was 100% capable of doing the task, but was using different data
>> flows. Simple example: porting an assembly task from an impedance
>> controlled platform to a force controlled platform.
>
> Very good point. That is exactly the sort of problem I'm interested in
> hearing about, to find out what is missing currently.
>
> We cannot have a complete system without data flow, so if that is not
> described within the state-machine, it is described somewhere else.
> From my naive perspective, if the way that state-machine is embedded
> in the system is platform-specific, we still have something to solve.
>
> However, whether this is really a problem depends a bit on how
> difficult specifying the state-flow is, and furthermore, whether it is
> easier to model it outside of the state-machine.
>
> In my personal experience, and Jonathan seems to be making the same
> point, I have found that the state-machine needs to interact with the
> data-flow anyway, and that this does not make it particularly
> platform-specific. This may depend on the problem we're trying to
> solve, though, so let me describe what I'm doing shortly:
>
> For example, in my coordination state-machines, one typical use-case
> is deciding whether a request for an action should or can be
> performed, given the current (global) system-state, and if yes, the
> request is passed on to the corresponding component, to perform the
> action. In that situation, information is passed from the requesting
> component to the executing one by the coordination component, which is
> internally modeled as state-chart. The state-chart doesn't need to
> know very much about the goal, however. Often, the goal specification
> is opaque, and is just copied from an incoming to an outgoing event.
> In such a situation, the functionality to locally store and pass on
> data is essential.


>
> Another typical situation is to decide which of several possible
> actions to take, depending on the content of an input event. This
> requires looking at the input in detail, and again all or part of its
> payload may need to be copied as information for the executing
> component.
>
> For that to work well, the state-machine needs to be fairly
> independent of the specific data types being exchanged. My
> coordination implementation has substantial independence in that way,
> but it comes at a cost, of course. For example, I use mappings to a
> common attribute-value representation internally, and flexible
> path-matching expressions to analyze the data further. I recognize
> that not all state-machines implementations might want to do this. I
> have chosen this approach, because my coordination tasks are at the
> interface between different parts of the system, so some munging of
> incoming to outgoing data is unavoidable.
>
> However, I realize that if you want to model coordination between some
> fairly closely coupled components, then all of this might be just
> overhead, and because the interacting components are coupled anyway,
> it might be a better idea to set up data-flow between them directly,
> and just pass some control events in and out. Is that your approach or
> are you doing something different entirely?

If I understand correctly what you mean, my short answer is "yes"! The
Coordinator just does the event processing, and most of the events
resulting from this will trigger re-configurations of the components that
process the data flow. In other words, there is no need for the FSM to do
the data flow itself. Take the obvious example of the Board of a company:
their decisions are not processing the data in the company itself, but are
giving signals to the upper management to change something in the way the
whole company deals with its data (or products, for that matter).
That's also the reason why a good manager can job-hop to companies with
very different activities without much problems: his coordination skills
are reusable, even with limited domain knowledge :-)
> cheers,
>
> -- 
> Ingo Lütkebohle

Herman

> Bielefeld University
> http://www.techfak.uni-bielefeld.de/~iluetkeb/
>
> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>

--
   KU Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
   EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
   Open Realtime Control Services <http://www.orocos.org>
   Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>