On Fri, 17 Feb 2012, Jonathan Bohren wrote:

> On Fri, Feb 17, 2012 at 8:09 AM, Ingo Lütkebohle <iluetkeb@gmail.com> wrote:
>       I agree, and we deliberately only use a subset of SCXML's
>       functionality, with other features being rejected at design time.
>       However, everything that I want to express in a state-machine
>       language, I can express in it. That's a very good start, in my
>       opinion, and something that is otherwise lacking.
> 
> 
> Well, I think going to a pure state-machine / state-chart specification would be a
> step back. The reason why we created SMACH in the first place was because in robotics
> applications and experiments, we often want more than what just an FSM-equivalent
> representation would allow us to specify. Remember, the SMACH semantics are more like
> a switched hybrid system than a pure FSM, since the true "state" at any given time is
> not only the task state but also the state of the data flowing between the task
> states. This was our attempt to increase the amount of an application which was being
> strictly modeled in the executive, without putting an unnecessary burden on the
> developer. It's a small step forward, but I think it enables us to achieve a lot more.

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.

Herman