On Tue, 4 Dec 2012, Markus Klotzbuecher wrote:

> On Tue, Dec 04, 2012 at 11:00:49AM +0100, Herman Bruyninckx wrote:
>> On Tue, 4 Dec 2012, Markus Klotzbuecher wrote:
>>
>>> On Tue, Dec 04, 2012 at 10:44:57AM +0100, Herman Bruyninckx wrote:
>>>> On Tue, 4 Dec 2012, Markus Klotzbuecher wrote:
>>>>
>>>>> On Tue, Dec 04, 2012 at 10:30:08AM +0100, Herman Bruyninckx wrote:
>>>>>> On Tue, 4 Dec 2012, Markus Klotzbuecher wrote:
>>>>>>
>>>>>>> Hi Ruben,
>>>>>>>
>>>>>>> On Tue, Dec 04, 2012 at 09:24:47AM +0100, Ruben Smits wrote:
>>>>>>>
>>>>>>>> I'm currently using the seqand extension of rfsm and I noticed some
>>>>>>>> unexpected behaviour.
>>>>>>>>
>>>>>>>> I have a coordinator running with a period of 5ms
>>>>>>>>
>>>>>>>> When my fsm enters the seqand state which has 2 child fsms I expect
>>>>>>>> that both of the child fsms runs after each 5ms. But this is not
>>>>>>>> what's happening. What I see is that first one child fsm runs and only
>>>>>>>> after 5 ms the second child fsm runs.
>>>>>>>>
>>>>>>>> Is this how it is supposed to go, or is this behaviour a bug?
>>>>>>>
>>>>>>> No, both should be advanced, depending on the arguments you pass in
>>>>>>> (checkout the inline documentation of the parameters in
>>>>>>> rfsm_ext.lua). But the default is only to call step() once. If you
>>>>>>> want more steps or run() to be called, you need to define the 'run' or
>>>>>>> 'step' parameter:
>>>>>>>
>>>>>>> rfsm.seqand {
>>>>>>> run=true,
>>>>>>> -- or e.g. step=3
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> Does that solve your problem? (I slightly improved the dbg messages on
>>>>>>> the dev branch)
>>>>>>
>>>>>> A side note: it looks to me that the current implementation is not yet
>>>>>> sufficiently separating the _modelling_ of the state machine from the
>>>>>> _execution_. Is this a correct interpretation? If so, how can the situation
>>>>>> be improved?
>>>>>
>>>>> Why do you think so? IMO the seqand beast only illustrates the many
>>>>> assumptions involved in parallel states by trying to make them
>>>>> explicit using configuration parameters. And that's even only for
>>>>> pseudo-parallelism...
>>>>
>>>> I agree that these "beasts" are relevant for the configuration of the
>>>> execution of a state machine. But I am worried that these execution-related
>>>> configurations are specified together with the configurations that describe
>>>> the activity definition model represented by the state machine
>>>> This worry comes from seeing examples like
>>>> <https://github.com/kmarkus/rFSM/blob/master/examples/seqand.lua>
>>>> where both aspects (modelling, and execution configuration) are mixed
>>>> in the same specification, without any semantic discrimination.
>>>
>>> I see what you mean. The question is to which extent execution
>>> parameters can be separated out. For pure rFSM this works OK and is
>>> defined by the surrounding component in which it is deployed. But for
>>> the seqAND its not so straightforward: while we could just "elevate"
>>> these parameters to the toplevel, the user will only be allowed to
>>> change them within certain boundaries in order to maintain the
>>> originally specified behavior.
>>
>> I think you mean that the "model" part of the FSM provides the right
>> context for the "execution" part of the model? I tend to agree, so in one
>> way or another, there _is_ a dependency that sooner or later must be
>> realised. While this could mean that the _final_ outcome of the separation
>> between modelling of the behaviour and modelling of the execution would be
>> the same as what we have now, I do think that it is wise to keep both
>> aspects decoupled.
>
> Yes, because the execution parameters are really system-level
> configuration (ie. the frequency at which the FSM is advanced). But
> only to that extent that the fundamental behavior remains invariant,
> and expressing that variability is what we're currently missing.
>
>>> To specify this, we need real
>>> parametrization support for rFSM, which is on my long list of
>>> todos.
>>
>> The lack of perfect tooling is showing more and more, indeed.
>> (All over robotics, not just in the rFSM context, of course.)
>>
>> Do you know of examples of FSM tools that already realise the "separation of
>> concerns" that I am after? The ones I know hide the execution model behind
>> the (G)UI, in the _implementation_ of the tool, without providing an
>> explicit execution semantics.
>
> Are you looking for the separation of model and execution parameters
> or of model and execution semantics? I see the latter as a paradox,
> since the purpose of the model is to add semantics.

Agreed!

> Markus

Herman