[ros-users] Current state of SMACH in ROS

[Ingo Lütkebohle]

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?

cheers,

-- 
Ingo Lütkebohle
Bielefeld University
http://www.techfak.uni-bielefeld.de/~iluetkeb/

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B