On Thu, Jan 24, 2013 at 10:01:14AM -0600, Gooding, Dustin R. (JSC-ER411) wrote:
> On Jan 24, 2013, at 9:52 AM, Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...> wrote:
>
> > Here[1] is v1.0, after almost two years in beta :-)
> >
> > This release does not add much new since beta6. Just a couple of minor
> > bug fixes and the "await" plugin. Using this plugin you can handle
> > multi-event AND transitions (that only trigger after multiple events
> > are received _while_ the source state of the transition is
> > active). Example
> >
> > trans{ src='off', tgt='on', events={"await(e_motor_on, e_checks_passed)"} },
> >
> > will only be enabled after both e_motor_on and e_checks_passed have
> > been received. This can also be done using the emem plugin, however
> > the latter is significantly more costly since it needs to
> > keep counting all events, while await will only track the ones it is
> > interested in. See the examples/await.lua and the docs [2]
> >
> > What's next:
> >
> > - implement internal events and history connectors
> > - find a better solution than string events to RTT (see Peter's message some time back)
> > - editors and visualization
> > - tools to manage distributed rFSM systems
> > - improve the docs, especially move the rFSM specific stuff from the
> > Cookbook page to a separate one.
> >
> > Thanks a lot to everyone for using, testing or providing feedback!!!
> >
> > Markus
> >
> >
> > [1] https://github.com/kmarkus/rFSM
> > [2] http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html
>
> Thanks for the nice software Markus. I'll upgrade soon and let you
> know if I run into anything.

Great, thanks!

> Regarding editors, we've been working on a tool in-house that allows
> us to visually create rFSM states and transitions. Additionally,
> you can define all your standard methods (entry, doo, etc), as well
> as global functions and variables. The end result is a
> auto-generated set of rFSM Lua scripts. Each state gets its own
> file (to help with composing). It works as a plugin (of sorts) to
> our robot command interface GUI. We're not ready to release it, but
> just letting you know it's beginning to exist. If you have
> suggestions/requirements, we're glad to hear them.

Interesting! Isn't having on file per state a bit unwieldy? What
tools or language is this tool implemented with?

Don't hesitate to release an alpha, I think there are many people
(incl myself) who would would be interested in testing and
contributing.

Markus

On Thu, 24 Jan 2013, Gooding, Dustin R. (JSC-ER411) wrote:

> On Jan 24, 2013, at 9:52 AM, Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...> wrote:
>
>> Here[1] is v1.0, after almost two years in beta :-)
>>
>> This release does not add much new since beta6. Just a couple of minor
>> bug fixes and the "await" plugin. Using this plugin you can handle
>> multi-event AND transitions (that only trigger after multiple events
>> are received _while_ the source state of the transition is
>> active). Example
>>
>> trans{ src='off', tgt='on', events={"await(e_motor_on, e_checks_passed)"} },
>>
>> will only be enabled after both e_motor_on and e_checks_passed have
>> been received. This can also be done using the emem plugin, however
>> the latter is significantly more costly since it needs to
>> keep counting all events, while await will only track the ones it is
>> interested in. See the examples/await.lua and the docs [2]
>>
>> What's next:
>>
>> - implement internal events and history connectors
>> - find a better solution than string events to RTT (see Peter's message some time back)
>> - editors and visualization
>> - tools to manage distributed rFSM systems
>> - improve the docs, especially move the rFSM specific stuff from the
>> Cookbook page to a separate one.
>>
>> Thanks a lot to everyone for using, testing or providing feedback!!!
>>
>> Markus
>>
>>
>> [1] https://github.com/kmarkus/rFSM
>> [2] http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
> Thanks for the nice software Markus. I'll upgrade soon and let you know if I run into anything.
>
> Regarding editors, we've been working on a tool in-house that allows us
> to visually create rFSM states and transitions. Additionally, you can
> define all your standard methods (entry, doo, etc), as well as global
> functions and variables. The end result is a auto-generated set of rFSM
> Lua scripts. Each state gets its own file (to help with composing). It
> works as a plugin (of sorts) to our robot command interface GUI. We're
> not ready to release it, but just letting you know it's beginning to
> exist.

Thanks!!!

> If you have suggestions/requirements, we're glad to hear them.

Some "meta level" suggestions, for any kind of tool:
- try to separate the model from the tool, in the sense that the
_constraints_ that are in the model are represented _explicitly_ and not
in the code.
- the code that deals with the constraints should be _generated_ from their
model.

I already know the practical objections against my suggestions: there are
not rich enough constraint languages out there, with good software support
in different languages, sigh...

I do expect that (a subset of) OCL could do the job, in the context of
state machines where all constraints are "structural" (linking two states
via a transition; calling function when the FSM enters or leaves; etc.) and
not "behavioural" (time outs; state memory constraints; etc.).

> -dustin

Herman