[ros-users] Current state of SMACH in ROS

Sun Feb 19 13:43:41 UTC 2012

Dear all,

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.). This can most easily be enforced by a
model-driven approach. The component model provides the ports for task
coordination mechanisms (task nets, finite state machines etc. in
whatever implementation, SmartTCL, SMACH, etc.).

The interesting questions for me are:

- at a component level, what are appropriate state machines inside a
component to allow for coordination from outside?
    => set components into states which allow for rewiring /
reconfiguration without caring about the data flow dependencies between
components!

- 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?

- and also: what kind of expressiveness do we need at the task
coordination with respect to variable bindings / forwardings?
    => I just want to receive bindings from events, e.g., and forward
information to the next state to be used there as part of its
configuration, e.g.

We are dealing with these questions within our SmartSoft component model
and our task coordination mechanisms. For example, see the following

-
http://www.zafh-servicerobotik.de/dokumente/ZAFH-TR-01-2011-ISSN-1868-3452.pdf
- http://www.zafh-servicerobotik.de/ULM/dokumente/masterthesis-steck.pdf
    => in particular 31ff

Cheers,
Christian

Am 19.02.2012 14:00, schrieb 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,
>
>   

-- 
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm

Tel.: 0731 / 50-28242

http://www.hs-ulm.de/schlegel
http://www.zafh-servicerobotik.de/ (Sprecher)
http://www.joser.org/ (Associate Editor)
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/