[ros-users] Current state of SMACH in ROS

[Ingo Lütkebohle]

On Sun, Feb 19, 2012 at 2:43 PM, Christian Schlegel <schlegel at hs-ulm.de> wrote:
> A component model is an appropriate approach to achieve "separation of
> concerns" since the idea of a component model always is to provide a
> black-box view from the outside (hiding the internals and how they are
> implemented). To achieve a black box view, a robotics software component
> model needs to explicate services for setting parameters, life-cycle
> management (activation / deactivation etc.) and data flow configuration
> (dynamic wiring etc.).

Agreed. Not necessarily necessary, but sufficient ;-)

I might add that many current robotic frameworks provide much, if not
all, of the functionality mentioned above, albeit usually without
formal description.

> This can most easily be enforced by a
> model-driven approach.

Well, I'm skeptical about the concept of "enforcement"  here. It is
very difficult, in software, to enforce anything strictly. One can
often side-step whatever facilities are provided, if that is desired.
The operating system people can probably tell some good stories here
;-)

However, when speaking in terms of "enabling", then there is more to
it, and that is also how I understood SmartSoft, so far. Given a
model, it enables automation of many things which are usually done
manually.

However, I would caution that the benefits of this approach are often
over-stated, in the sense that their utility is not appreciated by
many, for understandable reasons (e.g., they have other, more pressing
problems, and being tied to, say, ROS, doesn't seem to worry them).
The advocates of MDE seem to think that everybody is concerned with
portability and such things. Not everybody is. I am, but I've learned
that it is not a predominant view. Maybe everybody /should/ be, but
that is another question ;-)

> The component model provides the ports for task
> coordination mechanisms (task nets, finite state machines etc. in
> whatever implementation, SmartTCL, SMACH, etc.).

Where can I learn more about that? I'm not an expert on component
models, but I've looked at a few, and they usually concentrate only on
the static structure of a system, and maybe with establishing or
changing it at runtime instead of compile-time. So far, the dynamic
view -- in the sense of which actions are performed -- seems to be
(intentionally?) left out.

> - at a task coordination level, how to name configurations, events etc.
> in such a way that they can be mapped onto components?
>    => how to do the mapping of the names used in state machines to the
> names used at component interfaces?
>    => is there a generic way of how to express and link those mappings
> of names and perhaps even generate glue logic?

Could you tell me whether you find the Task-State-Pattern at all
useful in this regard? The paper is at http://bit.ly/yn29yE

In section 4.4, we talk about a typical toolkit API, for use by
consumers and providers of task-executing components. In figure 4, you
can see the API side for clients, which achieves a decomposition of
the general from the task-specific parts, with section 4.4.1 providing
a static model, if you will, of tasks. For the server-side, we usually
provide two APIs: One, which is event-based and essentially mirrors
the client interface, and one -- explained in section 4.4.2 of the
paper -- where a mapping from the generic states to methods of a
server class is provided.

I think that the latter section could provide an answer to your
questions above. I also point out the more event-driven APIs, though,
because we have also found those necessary, particularly for the
components doing coordination. This is an issue not to be
under-estimated, and I feel that component models with an
object-oriented structure fare poorly in event-driven systems.

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