2011/11/7 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> Hi,
>
> Just to let you know that I brought the rFSM docs up to date again. I
> hope they are much clearer now. Furthermore, the documentation now
> also covers the important extensions that have been added during the
> last year (timeevents, the graphviz figure generation, event memory,
> etc.):
>
> http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html
>
> And we have a logo!
>
> Feedback welcome!
>
> Best regards
> Markus
>
>
Hi Markus,
I tried to find what is the git repo to get it. If I ead carefully, there
is no hints, neither in the cookbook neither in the rfsm doc
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Revised rFSM documentation
2012/2/18 Willy Lambert <lambert [dot] willy [..] ...>
>
>
> 2011/11/7 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>
>> Hi,
>>
>> Just to let you know that I brought the rFSM docs up to date again. I
>> hope they are much clearer now. Furthermore, the documentation now
>> also covers the important extensions that have been added during the
>> last year (timeevents, the graphviz figure generation, event memory,
>> etc.):
>>
>> http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html
>>
>> And we have a logo!
>>
>> Feedback welcome!
>>
>> Best regards
>> Markus
>>
>>
> Hi Markus,
>
> I tried to find what is the git repo to get it. If I ead carefully, there
> is no hints, neither in the cookbook neither in the rfsm doc
>
>
I finish to find it :
https://github.com/kmarkus/rFSM.git
I have some remarks on the documentation (that is very well done btw ! it's
just about details) :
_ I think that it misses emphasis on the fact that the difference between
composite and simple state is (just ?) the "doo" function.
_ I did not understand connector at all. I don't know if it is me or the
fact that you know your subject, but I really missed the point
_ I find that the 4.1.2 paragraph (Particularities of the root composite
state) is a bit short. If I understood it is quite advanced stuff, so
reader don't need this at first glance but it stay misterious for me.
_ I don't understand the 7.- rfsm-sim end statement : "It requires an image
viewer which automatically updates once the file displayed changes. For
exampleevince works nicely." should it go in the 7.5 rfsm-viz section ?
_ in the RTT lua cookbook there is no C++ example to run an rFSM in RTT. Is
it possible ?
I also need help to use the simu. Something seems to be wrong :
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim
examples/hello_world.lua
lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
unexpected symbol near `#'
Is there any work going on code generation with a graphical interface to
create the statechart ?
> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>
>
Revised rFSM documentation
Hi Willy,
On Mon, Feb 20, 2012 at 02:33:12AM +0100, Willy Lambert wrote:
>
> I tried to find what is the git repo to get it. If I ead carefully, there
> is no hints, neither in the cookbook neither in the rfsm doc
>
>
>
> I finish to find it :
> https://github.com/kmarkus/rFSM.git
Ups, I'll update the docs ASAP!
> I have some remarks on the documentation (that is very well done btw ! it's
> just about details) :
Thanks a lot! This feedback is much appreciated!
> _ I think that it misses emphasis on the fact that the difference between
> composite and simple state is (just ?) the "doo" function.
Good one! Yes, that is (was) the only difference. For the upcoming
version we have consoldiated composite_state and simple_state, because
this minor difference didn't justify having two primitives and also
because internally there wasn't hardly any difference at all.
> _ I did not understand connector at all. I don't know if it is me or the fact
> that you know your subject, but I really missed the point
It's not you, others have been confused too. The connector has several
use cases:
- initial connector: the default entry point of a composite state
- as entry and exit points: to permit entering and exiting composite
states in different ways.
- to permit construction of so called composite transitions built
from multiple simple ones. This is advanced stuff, you'll know it
when you'll need it (it sometimes permits to reduce the number of
transitions drastically or for implementing "dispatchers")
> _ I find that the 4.1.2 paragraph (Particularities of the root composite state)
> is a bit short. If I understood it is quite advanced stuff, so reader don't
> need this at first glance but it stay misterious for me.
It's a silly title: it should top-level FSM configuration or
similar. At the root state you can configure how errors/warnings are
printed and more importantly, supply the 'getevents' hook, which is a
callback invoked by the rFSM engine to retrieve the current list of
events.
> _ I don't understand the 7.- rfsm-sim end statement : "It requires an image
> viewer which automatically updates once the file displayed changes. For example
> evince works nicely." should it go in the 7.5 rfsm-viz section ?
rfsm-viz only generates different types of figures of you fsm.
rfsm-sim will simulate a fsm and offer you a simple command line
interface to run/step and send events. It can also draw graphviz based
figures. If you supply a viewer, it will open the file in that viewer
so you get sort of a real-time visualization.
> _ in the RTT lua cookbook there is no C++ example to run an rFSM in RTT. Is it
> possible ?
I've not tried it, but it should not be a problem. Can you explain in
more detail what you want to do?
> I also need help to use the simu. Something seems to be wrong :
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim
> examples/hello_world.lua
> lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> unexpected symbol near `#'
Hmm, works here. Is you $LUA environment variable set to something?
Does running it directly as below work?
$ lua -i tools/rfsm-sim.lua examples/hello_world.lua
> Is there any work going on code generation with a graphical interface to create
> the statechart ?
Its on the TODO..!
Thanks again for you valuable feedback!
Markus
Revised rFSM documentation
2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> Hi Willy,
>
> On Mon, Feb 20, 2012 at 02:33:12AM +0100, Willy Lambert wrote:
> >
> > I tried to find what is the git repo to get it. If I ead carefully,
> there
> > is no hints, neither in the cookbook neither in the rfsm doc
> >
> >
> >
> > I finish to find it :
> > https://github.com/kmarkus/rFSM.git
>
> Ups, I'll update the docs ASAP!
>
> > I have some remarks on the documentation (that is very well done btw !
> it's
> > just about details) :
>
> Thanks a lot! This feedback is much appreciated!
>
> > _ I think that it misses emphasis on the fact that the difference between
> > composite and simple state is (just ?) the "doo" function.
>
> Good one! Yes, that is (was) the only difference. For the upcoming
> version we have consoldiated composite_state and simple_state, because
> this minor difference didn't justify having two primitives and also
> because internally there wasn't hardly any difference at all.
>
Ok let me know when I can try the new version.
>
> > _ I did not understand connector at all. I don't know if it is me or the
> fact
> > that you know your subject, but I really missed the point
>
> It's not you, others have been confused too. The connector has several
> use cases:
>
> - initial connector: the default entry point of a composite state
>
>
I don't understand how this is different from 2 transitions. Does this two
lines of the example really need a connector ?
rfsm.trans{src='initial', tgt='software_err', events={'e_sw_err'}},
rfsm.trans{src='initial', tgt='hardware_err', events={'e_hw_err'}},
> - as entry and exit points: to permit entering and exiting composite
> states in different ways.
>
> - to permit construction of so called composite transitions built
> from multiple simple ones. This is advanced stuff, you'll know it
> when you'll need it (it sometimes permits to reduce the number of
> transitions drastically or for implementing "dispatchers")
>
>
I suggest you edit the example (and add the graphical figure) to have
something showing this different cases, because I think the given example
is a bit too simple to show the connector use cases.
This raises other question to me :
_ if a transition is ready when we enter the state, does the doo function
be executed once ?
_ if there are several transition active in several level of the
composition, what will happen ? Does the "top level" transition will have
the priority ?
_ if I come back to my composition above, what is the new initial substate
? is it the last active, or the coded initial state ?
>
> > _ I find that the 4.1.2 paragraph (Particularities of the root composite
> state)
> > is a bit short. If I understood it is quite advanced stuff, so reader
> don't
> > need this at first glance but it stay misterious for me.
>
> It's a silly title: it should top-level FSM configuration or
> similar. At the root state you can configure how errors/warnings are
> printed and more importantly, supply the 'getevents' hook, which is a
> callback invoked by the rFSM engine to retrieve the current list of
> events.
>
I'd had love to see an example of this with few lines of code. It is always
great to be abble to copy paste the example use case for the first time you
use something. It's always reassuring.
>
> > _ I don't understand the 7.- rfsm-sim end statement : "It requires an
> image
> > viewer which automatically updates once the file displayed changes. For
> example
> > evince works nicely." should it go in the 7.5 rfsm-viz section ?
>
> rfsm-viz only generates different types of figures of you fsm.
>
> rfsm-sim will simulate a fsm and offer you a simple command line
> interface to run/step and send events. It can also draw graphviz based
> figures. If you supply a viewer, it will open the file in that viewer
> so you get sort of a real-time visualization.
>
You should detail the call API of the rfsm-sim then. I don't see how I give
him the graphical editor, is it a parameter or an env variable ?
What is the meaning of "all" in second position in the command line ?
tools/rfsm-sim all examples/ball_tracker_scope.lua
>
> > _ in the RTT lua cookbook there is no C++ example to run an rFSM in RTT.
> Is it
> > possible ?
>
> I've not tried it, but it should not be a problem. Can you explain in
> more detail what you want to do?
>
> > I also need help to use the simu. Something seems to be wrong :
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim
> > examples/hello_world.lua
> > lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> > unexpected symbol near `#'
>
> Hmm, works here. Is you $LUA environment variable set to something?
>
Yes it should be :
ard@ard-host(9.0):~$ echo $LUA_PATH
;/opt/ros_addons/orocos_toolchain/rFSM/?.lua;/opt/ros_addons/orocos_toolchain/ocl/lua/modules/?.lua
ard@ard-host(9.0):~$ roscd rFSM
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim all
examples/hello_world.lua
lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
unexpected symbol near `#'
> Does running it directly as below work?
>
> $ lua -i tools/rfsm-sim.lua examples/hello_world.lua
>
>
No, it's the same :
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -i
tools/rfsm-sim.lua examples/hello_world.lua
lua: tools/rfsm-sim.lua:7: unexpected symbol near `#'
>
> > Is there any work going on code generation with a graphical interface to
> create
> > the statechart ?
>
> Its on the TODO..!
>
Great, I can't wait to see this. I used to play with Smach and Orocos
scripts. rFSM seems to correct several needs nicely. The 2 important points
on the user side (if we do not consider the efficiency of the core system
underlying) are : the dynamic view, and a the graphical code generation to
let not-developpers to code on robots.
I don't know any fsm framework doing the code generation nicely, and Orocos
scripts doesn't have a dynamic view, and Smach viewer has performance
problems as soon as your design growth. By the way, did you tested rFSM
with hudge design ?
> Thanks again for you valuable feedback!
> Markus
>
Revised rFSM documentation
On Mon, Feb 20, 2012 at 12:27:46PM +0100, Willy Lambert wrote:
>
>
> 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>
> Hi Willy,
>
> On Mon, Feb 20, 2012 at 02:33:12AM +0100, Willy Lambert wrote:
> >
> > I tried to find what is the git repo to get it. If I ead carefully,
> there
> > is no hints, neither in the cookbook neither in the rfsm doc
> >
> >
> >
> > I finish to find it :
> > https://github.com/kmarkus/rFSM.git
>
> Ups, I'll update the docs ASAP!
>
> > I have some remarks on the documentation (that is very well done btw !
> it's
> > just about details) :
>
> Thanks a lot! This feedback is much appreciated!
>
> > _ I think that it misses emphasis on the fact that the difference between
> > composite and simple state is (just ?) the "doo" function.
>
> Good one! Yes, that is (was) the only difference. For the upcoming
> version we have consoldiated composite_state and simple_state, because
> this minor difference didn't justify having two primitives and also
> because internally there wasn't hardly any difference at all.
>
>
> Ok let me know when I can try the new version.
Will do!
> > _ I did not understand connector at all. I don't know if it is me or the
> fact
> > that you know your subject, but I really missed the point
>
> It's not you, others have been confused too. The connector has several
> use cases:
>
> - initial connector: the default entry point of a composite state
>
> I don't understand how this is different from 2 transitions. Does this two
> lines of the example really need a connector ?
>
> rfsm.trans{src='initial', tgt='software_err', events={'e_sw_err'}},
> rfsm.trans{src='initial', tgt='hardware_err', events={'e_hw_err'}},
Here the initial connector define the default way of entering the
composite state (here the FSM root). Whenever a transition stops on
the boundary of a composite state, you can imagine it extended to its
initial connector.
>
> - as entry and exit points: to permit entering and exiting composite
> states in different ways.
>
> - to permit construction of so called composite transitions built
> from multiple simple ones. This is advanced stuff, you'll know it
> when you'll need it (it sometimes permits to reduce the number of
> transitions drastically or for implementing "dispatchers")
>
>
>
> I suggest you edit the example (and add the graphical figure) to have something
> showing this different cases, because I think the given example is a bit too
> simple to show the connector use cases.
Yes, you are right.
> This raises other question to me :
> _ if a transition is ready when we enter the state, does the doo function be
> executed once ?
doo has lowest priority, so if you enter a state and there are new
events available that trigger an outgoing transition, then that
transition will be taken and not the doo.
> _ if there are several transition active in several level of the composition,
> what will happen ? Does the "top level" transition will have the priority ?
Yes, the one whose source state is closest to the FSM root will
execute. If two or more at the same level are enabled, you have a
conflict and the FSM becomes non-deterministic (i.e. it will take a
random one (but don't rely on this being good quality randomness!))
You can resolve this using guards or priority numbers.
> _ if I come back to my composition above, what is the new initial substate ? is
> it the last active, or the coded initial state ?
Can you rephrase this question, please?
> > _ I find that the 4.1.2 paragraph (Particularities of the root composite
> state)
> > is a bit short. If I understood it is quite advanced stuff, so reader
> don't
> > need this at first glance but it stay misterious for me.
>
> It's a silly title: it should top-level FSM configuration or
> similar. At the root state you can configure how errors/warnings are
> printed and more importantly, supply the 'getevents' hook, which is a
> callback invoked by the rFSM engine to retrieve the current list of
> events.
>
>
> I'd had love to see an example of this with few lines of code. It is always
> great to be abble to copy paste the example use case for the first time you use
> something. It's always reassuring.
I'll try to update this soon. If you look at the example here:
http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49
You can see how first the fsm is loaded from a file:
fsm = rfsm.init(rfsm.load("fsm.lua"))
and little later the getevents hook is setup to a (generated) function
that when called returns all events on the given port
fsm.getevents = rfsm_rtt.gen_read_events(events_in)
For example to direct the noisy rFSM dbg messages to the rtt logger
you could do
fsm.info=function(...) rtt.logl('Warning', table.concat({...}, ' ')) end
> > _ I don't understand the 7.- rfsm-sim end statement : "It requires an
> image
> > viewer which automatically updates once the file displayed changes. For
> example
> > evince works nicely." should it go in the 7.5 rfsm-viz section ?
>
> rfsm-viz only generates different types of figures of you fsm.
>
> rfsm-sim will simulate a fsm and offer you a simple command line
> interface to run/step and send events. It can also draw graphviz based
> figures. If you supply a viewer, it will open the file in that viewer
> so you get sort of a real-time visualization.
>
> You should detail the call API of the rfsm-sim then. I don't see how I give him
> the graphical editor, is it a parameter or an env variable ?
Yes, you can try setting $RFSM_VIEWER to something like evince, okular
that will automatically update when the file changes. Note that this
is very primitive and likely not very useful to you, but has been
valuable during early debugging.
> What is the meaning of "all" in second position in the command line ?
> tools/rfsm-sim all examples/ball_tracker_scope.lua
It means generate "all" types of figures :-)
This all needs an update. The problem is that I am working on
replacing these primitive tools with something more powerful, but I
am not there yet... Meanwhile they are there, because still useful
> > _ in the RTT lua cookbook there is no C++ example to run an rFSM in RTT.
> Is it
> > possible ?
>
> I've not tried it, but it should not be a problem. Can you explain in
> more detail what you want to do?
>
> > I also need help to use the simu. Something seems to be wrong :
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim
> > examples/hello_world.lua
> > lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> > unexpected symbol near `#'
>
> Hmm, works here. Is you $LUA environment variable set to something?
>
>
> Yes it should be :
> ard@ard-host(9.0):~$ echo $LUA_PATH
> ;/opt/ros_addons/orocos_toolchain/rFSM/?.lua;/opt/ros_addons/orocos_toolchain/
> ocl/lua/modules/?.lua
> ard@ard-host(9.0):~$ roscd rFSM
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim all
> examples/hello_world.lua
> lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> unexpected symbol near `#'
>
>
> Does running it directly as below work?
>
> $ lua -i tools/rfsm-sim.lua examples/hello_world.lua
>
>
>
> No, it's the same :
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -i tools/
> rfsm-sim.lua examples/hello_world.lua
> lua: tools/rfsm-sim.lua:7: unexpected symbol near `#'
But what does
$ echo $LUA show?
and
$ lua -v
show?
> > Is there any work going on code generation with a graphical interface to
> create
> > the statechart ?
>
> Its on the TODO..!
>
>
> Great, I can't wait to see this. I used to play with Smach and Orocos scripts.
> rFSM seems to correct several needs nicely. The 2 important points on the user
> side (if we do not consider the efficiency of the core system underlying) are :
> the dynamic view, and a the graphical code generation to let not-developpers to
> code on robots.
We are working on various tools to make life easier, dynamic
visualization being part of it. But don't hold your breath...
>
> I don't know any fsm framework doing the code generation nicely, and Orocos
> scripts doesn't have a dynamic view, and Smach viewer has performance problems
> as soon as your design growth. By the way, did you tested rFSM with hudge
> design ?
We have used larger ones (in the order of few tens of states) but not
really huge. The reason for this, I suppose, is that at some point we
tend to break fsm's into smaller, separate ones again.
Best regards
Markus
Revised rFSM documentation
2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> On Mon, Feb 20, 2012 at 12:27:46PM +0100, Willy Lambert wrote:
> >
> >
> > 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> >
> > Hi Willy,
> >
> > On Mon, Feb 20, 2012 at 02:33:12AM +0100, Willy Lambert wrote:
> > >
> > > I tried to find what is the git repo to get it. If I ead
> carefully,
> > there
> > > is no hints, neither in the cookbook neither in the rfsm doc
> > >
> > >
> > >
> > > I finish to find it :
> > > https://github.com/kmarkus/rFSM.git
> >
> > Ups, I'll update the docs ASAP!
> >
> > > I have some remarks on the documentation (that is very well done
> btw !
> > it's
> > > just about details) :
> >
> > Thanks a lot! This feedback is much appreciated!
> >
> > > _ I think that it misses emphasis on the fact that the difference
> between
> > > composite and simple state is (just ?) the "doo" function.
> >
> > Good one! Yes, that is (was) the only difference. For the upcoming
> > version we have consoldiated composite_state and simple_state,
> because
> > this minor difference didn't justify having two primitives and also
> > because internally there wasn't hardly any difference at all.
> >
> >
> > Ok let me know when I can try the new version.
>
> Will do!
>
> > > _ I did not understand connector at all. I don't know if it is me
> or the
> > fact
> > > that you know your subject, but I really missed the point
> >
> > It's not you, others have been confused too. The connector has
> several
> > use cases:
> >
> > - initial connector: the default entry point of a composite state
> >
> > I don't understand how this is different from 2 transitions. Does this
> two
> > lines of the example really need a connector ?
> >
> > rfsm.trans{src='initial', tgt='software_err', events={'e_sw_err'}},
> > rfsm.trans{src='initial', tgt='hardware_err', events={'e_hw_err'}},
>
> Here the initial connector define the default way of entering the
> composite state (here the FSM root). Whenever a transition stops on
> the boundary of a composite state, you can imagine it extended to its
> initial connector.
>
> >
> > - as entry and exit points: to permit entering and exiting composite
> > states in different ways.
> >
> > - to permit construction of so called composite transitions built
> > from multiple simple ones. This is advanced stuff, you'll know it
> > when you'll need it (it sometimes permits to reduce the number of
> > transitions drastically or for implementing "dispatchers")
> >
> >
> >
> > I suggest you edit the example (and add the graphical figure) to have
> something
> > showing this different cases, because I think the given example is a bit
> too
> > simple to show the connector use cases.
>
> Yes, you are right.
>
> > This raises other question to me :
> > _ if a transition is ready when we enter the state, does the doo
> function be
> > executed once ?
>
> doo has lowest priority, so if you enter a state and there are new
> events available that trigger an outgoing transition, then that
> transition will be taken and not the doo.
>
> > _ if there are several transition active in several level of the
> composition,
> > what will happen ? Does the "top level" transition will have the
> priority ?
>
> Yes, the one whose source state is closest to the FSM root will
> execute. If two or more at the same level are enabled, you have a
> conflict and the FSM becomes non-deterministic (i.e. it will take a
> random one (but don't rely on this being good quality randomness!))
> You can resolve this using guards or priority numbers.
>
> > _ if I come back to my composition above, what is the new initial
> substate ? is
> > it the last active, or the coded initial state ?
>
> Can you rephrase this question, please?
>
Imagine I have two states A and B. I am in A which initial transition is to
go to a1. Something happens I am in a2. Something happens, a transition
from A to B is fired. I leave A.a2 state to B.initial state. Something
happens, I transit from B to A. Which is the state ? A.a2 or A.initial or
A.a1 ?
>
> > > _ I find that the 4.1.2 paragraph (Particularities of the root
> composite
> > state)
> > > is a bit short. If I understood it is quite advanced stuff, so
> reader
> > don't
> > > need this at first glance but it stay misterious for me.
> >
> > It's a silly title: it should top-level FSM configuration or
> > similar. At the root state you can configure how errors/warnings are
> > printed and more importantly, supply the 'getevents' hook, which is a
> > callback invoked by the rFSM engine to retrieve the current list of
> > events.
> >
> >
> > I'd had love to see an example of this with few lines of code. It is
> always
> > great to be abble to copy paste the example use case for the first time
> you use
> > something. It's always reassuring.
>
> I'll try to update this soon. If you look at the example here:
>
> http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49
>
> You can see how first the fsm is loaded from a file:
>
> fsm = rfsm.init(rfsm.load("fsm.lua"))
>
> and little later the getevents hook is setup to a (generated) function
> that when called returns all events on the given port
>
> fsm.getevents = rfsm_rtt.gen_read_events(events_in)
>
> For example to direct the noisy rFSM dbg messages to the rtt logger
> you could do
>
> fsm.info=function(...) rtt.logl('Warning', table.concat({...}, ' ')) end
>
> > > _ I don't understand the 7.- rfsm-sim end statement : "It requires
> an
> > image
> > > viewer which automatically updates once the file displayed
> changes. For
> > example
> > > evince works nicely." should it go in the 7.5 rfsm-viz section ?
> >
> > rfsm-viz only generates different types of figures of you fsm.
> >
> > rfsm-sim will simulate a fsm and offer you a simple command line
> > interface to run/step and send events. It can also draw graphviz
> based
> > figures. If you supply a viewer, it will open the file in that viewer
> > so you get sort of a real-time visualization.
> >
> > You should detail the call API of the rfsm-sim then. I don't see how I
> give him
> > the graphical editor, is it a parameter or an env variable ?
>
> Yes, you can try setting $RFSM_VIEWER to something like evince, okular
> that will automatically update when the file changes. Note that this
> is very primitive and likely not very useful to you, but has been
> valuable during early debugging.
>
> > What is the meaning of "all" in second position in the command line ?
> > tools/rfsm-sim all examples/ball_tracker_scope.lua
>
> It means generate "all" types of figures :-)
>
> This all needs an update. The problem is that I am working on
> replacing these primitive tools with something more powerful, but I
> am not there yet... Meanwhile they are there, because still useful
>
> > > _ in the RTT lua cookbook there is no C++ example to run an rFSM
> in RTT.
> > Is it
> > > possible ?
> >
> > I've not tried it, but it should not be a problem. Can you explain in
> > more detail what you want to do?
> >
> > > I also need help to use the simu. Something seems to be wrong :
> > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
> tools/rfsm-sim
> > > examples/hello_world.lua
> > > lua:
> /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> > > unexpected symbol near `#'
> >
> > Hmm, works here. Is you $LUA environment variable set to something?
> >
> >
> > Yes it should be :
> > ard@ard-host(9.0):~$ echo $LUA_PATH
> >
> ;/opt/ros_addons/orocos_toolchain/rFSM/?.lua;/opt/ros_addons/orocos_toolchain/
> > ocl/lua/modules/?.lua
> > ard@ard-host(9.0):~$ roscd rFSM
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim
> all
> > examples/hello_world.lua
> > lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> > unexpected symbol near `#'
> >
> >
> > Does running it directly as below work?
> >
> > $ lua -i tools/rfsm-sim.lua examples/hello_world.lua
> >
> >
> >
> > No, it's the same :
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -i tools/
> > rfsm-sim.lua examples/hello_world.lua
> > lua: tools/rfsm-sim.lua:7: unexpected symbol near `#'
>
> But what does
> $ echo $LUA show?
>
> and
>
> $ lua -v
>
> show?
>
I add the dpkg to show youwhat's installed :
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -v
Lua 5.0.3 Copyright (C) 1994-2006 Tecgraf, PUC-Rio
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ dpkg -l | grep lua
ii liblua5.1-0 5.1.4-5
Simple, extensible, embeddable programming language
ii liblua5.1-0-dev 5.1.4-5
Simple, extensible, embeddable programming language
ii liblua50 5.0.3-4
Main interpreter library for the Lua 5.0 programming language
ii liblualib50 5.0.3-4
Extension library for the Lua 5.0 programming language
ii lua50 5.0.3-4
Small embeddable language with simple procedural syntax
ii luatex 0.60.2-1
next generation TeX engine
ii texlive-luatex 2009-11
TeX Live: LuaTeX packages
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
I have no lua prerequisite, so I can change anything about this
installation. Should I use somehting like 'rosdep install' instead of
manually doing this ?
>
> > > Is there any work going on code generation with a graphical
> interface to
> > create
> > > the statechart ?
> >
> > Its on the TODO..!
> >
> >
> > Great, I can't wait to see this. I used to play with Smach and Orocos
> scripts.
> > rFSM seems to correct several needs nicely. The 2 important points on
> the user
> > side (if we do not consider the efficiency of the core system
> underlying) are :
> > the dynamic view, and a the graphical code generation to let
> not-developpers to
> > code on robots.
>
> We are working on various tools to make life easier, dynamic
> visualization being part of it. But don't hold your breath...
> >
> > I don't know any fsm framework doing the code generation nicely, and
> Orocos
> > scripts doesn't have a dynamic view, and Smach viewer has performance
> problems
> > as soon as your design growth. By the way, did you tested rFSM with hudge
> > design ?
>
> We have used larger ones (in the order of few tens of states) but not
> really huge. The reason for this, I suppose, is that at some point we
> tend to break fsm's into smaller, separate ones again.
>
> Best regards
> Markus
>
Revised rFSM documentation
Hi Willy,
(Would you mind switching to plaintext email, this thread is getting
quite unreadable...)
On Mon, Feb 20, 2012 at 01:29:44PM +0100, Willy Lambert wrote:
>
>
> 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>
> On Mon, Feb 20, 2012 at 12:27:46PM +0100, Willy Lambert wrote:
> >
> >
> > 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> >
> > Hi Willy,
> >
> > On Mon, Feb 20, 2012 at 02:33:12AM +0100, Willy Lambert wrote:
> > >
> > > I tried to find what is the git repo to get it. If I ead
> carefully,
> > there
> > > is no hints, neither in the cookbook neither in the rfsm doc
> > >
> > >
> > >
> > > I finish to find it :
> > > https://github.com/kmarkus/rFSM.git
> >
> > Ups, I'll update the docs ASAP!
> >
> > > I have some remarks on the documentation (that is very well done
> btw !
> > it's
> > > just about details) :
> >
> > Thanks a lot! This feedback is much appreciated!
> >
> > > _ I think that it misses emphasis on the fact that the difference
> between
> > > composite and simple state is (just ?) the "doo" function.
> >
> > Good one! Yes, that is (was) the only difference. For the upcoming
> > version we have consoldiated composite_state and simple_state,
> because
> > this minor difference didn't justify having two primitives and also
> > because internally there wasn't hardly any difference at all.
> >
> >
> > Ok let me know when I can try the new version.
>
> Will do!
>
> > > _ I did not understand connector at all. I don't know if it is me
> or the
> > fact
> > > that you know your subject, but I really missed the point
> >
> > It's not you, others have been confused too. The connector has
> several
> > use cases:
> >
> > - initial connector: the default entry point of a composite state
> >
> > I don't understand how this is different from 2 transitions. Does this
> two
> > lines of the example really need a connector ?
> >
> > rfsm.trans{src='initial', tgt='software_err', events={'e_sw_err'}},
> > rfsm.trans{src='initial', tgt='hardware_err', events={'e_hw_err'}},
>
> Here the initial connector define the default way of entering the
> composite state (here the FSM root). Whenever a transition stops on
> the boundary of a composite state, you can imagine it extended to its
> initial connector.
>
> >
> > - as entry and exit points: to permit entering and exiting composite
> > states in different ways.
> >
> > - to permit construction of so called composite transitions built
> > from multiple simple ones. This is advanced stuff, you'll know it
> > when you'll need it (it sometimes permits to reduce the number of
> > transitions drastically or for implementing "dispatchers")
> >
> >
> >
> > I suggest you edit the example (and add the graphical figure) to have
> something
> > showing this different cases, because I think the given example is a bit
> too
> > simple to show the connector use cases.
>
> Yes, you are right.
>
> > This raises other question to me :
> > _ if a transition is ready when we enter the state, does the doo function
> be
> > executed once ?
>
> doo has lowest priority, so if you enter a state and there are new
> events available that trigger an outgoing transition, then that
> transition will be taken and not the doo.
>
> > _ if there are several transition active in several level of the
> composition,
> > what will happen ? Does the "top level" transition will have the
> priority ?
>
> Yes, the one whose source state is closest to the FSM root will
> execute. If two or more at the same level are enabled, you have a
> conflict and the FSM becomes non-deterministic (i.e. it will take a
> random one (but don't rely on this being good quality randomness!))
> You can resolve this using guards or priority numbers.
>
> > _ if I come back to my composition above, what is the new initial
> substate ? is
> > it the last active, or the coded initial state ?
>
> Can you rephrase this question, please?
>
>
>
> Imagine I have two states A and B. I am in A which initial transition is to go
> to a1. Something happens I am in a2. Something happens, a transition from A
> to B is fired. I leave A.a2 state to B.initial state. Something happens, I
An (the!) important property of a connector is that it is not a state,
hence you can not be in it. You can only be in states. The execution
of a transition (composite or not) is atomic.
> transit from B to A. Which is the state ? A.a2 or A.initial or A.a1 ?
If you are in some state in B and transition back to A, then A will be
entered via the initial connector and transition to the state
connected by that. I hope I understood you correctly, if not, please
try to specify the question using a textual rFSM model.
> > > _ I find that the 4.1.2 paragraph (Particularities of the root
> composite
> > state)
> > > is a bit short. If I understood it is quite advanced stuff, so
> reader
> > don't
> > > need this at first glance but it stay misterious for me.
> >
> > It's a silly title: it should top-level FSM configuration or
> > similar. At the root state you can configure how errors/warnings are
> > printed and more importantly, supply the 'getevents' hook, which is a
> > callback invoked by the rFSM engine to retrieve the current list of
> > events.
> >
> >
> > I'd had love to see an example of this with few lines of code. It is
> always
> > great to be abble to copy paste the example use case for the first time
> you use
> > something. It's always reassuring.
>
> I'll try to update this soon. If you look at the example here:
>
> http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49
>
> You can see how first the fsm is loaded from a file:
>
> fsm = rfsm.init(rfsm.load("fsm.lua"))
>
> and little later the getevents hook is setup to a (generated) function
> that when called returns all events on the given port
>
> fsm.getevents = rfsm_rtt.gen_read_events(events_in)
>
> For example to direct the noisy rFSM dbg messages to the rtt logger
> you could do
>
> fsm.info=function(...) rtt.logl('Warning', table.concat({...}, ' ')) end
>
> > > _ I don't understand the 7.- rfsm-sim end statement : "It requires
> an
> > image
> > > viewer which automatically updates once the file displayed changes.
> For
> > example
> > > evince works nicely." should it go in the 7.5 rfsm-viz section ?
> >
> > rfsm-viz only generates different types of figures of you fsm.
> >
> > rfsm-sim will simulate a fsm and offer you a simple command line
> > interface to run/step and send events. It can also draw graphviz
> based
> > figures. If you supply a viewer, it will open the file in that viewer
> > so you get sort of a real-time visualization.
> >
> > You should detail the call API of the rfsm-sim then. I don't see how I
> give him
> > the graphical editor, is it a parameter or an env variable ?
>
> Yes, you can try setting $RFSM_VIEWER to something like evince, okular
> that will automatically update when the file changes. Note that this
> is very primitive and likely not very useful to you, but has been
> valuable during early debugging.
>
> > What is the meaning of "all" in second position in the command line ?
> > tools/rfsm-sim all examples/ball_tracker_scope.lua
>
> It means generate "all" types of figures :-)
>
> This all needs an update. The problem is that I am working on
> replacing these primitive tools with something more powerful, but I
> am not there yet... Meanwhile they are there, because still useful
>
> > > _ in the RTT lua cookbook there is no C++ example to run an rFSM in
> RTT.
> > Is it
> > > possible ?
> >
> > I've not tried it, but it should not be a problem. Can you explain in
> > more detail what you want to do?
> >
> > > I also need help to use the simu. Something seems to be wrong :
> > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/
> rfsm-sim
> > > examples/hello_world.lua
> > > lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/
> rfsm-sim.lua:7:
> > > unexpected symbol near `#'
> >
> > Hmm, works here. Is you $LUA environment variable set to something?
> >
> >
> > Yes it should be :
> > ard@ard-host(9.0):~$ echo $LUA_PATH
> > ;/opt/ros_addons/orocos_toolchain/rFSM/?.lua;/opt/ros_addons/
> orocos_toolchain/
> > ocl/lua/modules/?.lua
> > ard@ard-host(9.0):~$ roscd rFSM
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ tools/rfsm-sim
> all
> > examples/hello_world.lua
> > lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> > unexpected symbol near `#'
> >
> >
> > Does running it directly as below work?
> >
> > $ lua -i tools/rfsm-sim.lua examples/hello_world.lua
> >
> >
> >
> > No, it's the same :
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -i tools/
> > rfsm-sim.lua examples/hello_world.lua
> > lua: tools/rfsm-sim.lua:7: unexpected symbol near `#'
>
> But what does
> $ echo $LUA show?
>
> and
>
> $ lua -v
>
> show?
>
>
> I add the dpkg to show youwhat's installed :
>
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -v
> Lua 5.0.3 Copyright (C) 1994-2006 Tecgraf, PUC-Rio
This is most likely the problem. Your current Lua is 5.0, which is too
old for rFSM (which requires 5.1)
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ dpkg -l | grep lua
> ii liblua5.1-0 5.1.4-5
> Simple, extensible, embeddable programming language
> ii liblua5.1-0-dev 5.1.4-5
> Simple, extensible, embeddable programming language
> ii liblua50 5.0.3-4 Main
> interpreter library for the Lua 5.0 programming language
> ii liblualib50 5.0.3-4
> Extension library for the Lua 5.0 programming language
> ii lua50 5.0.3-4
> Small embeddable language with simple procedural syntax
> ii luatex 0.60.2-1 next
> generation TeX engine
> ii texlive-luatex 2009-11 TeX
> Live: LuaTeX packages
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
You have both versions installed.
> I have no lua prerequisite, so I can change anything about this installation.
> Should I use somehting like 'rosdep install' instead of manually doing this ?
If you can I would just throw out the 5.0 versions (liblua50,
liblualib50, lua50). Alternatively you can switch your current Lua
using update-alternatives(8) or some gui frontend.
Does this solve the issue?
Best regards
Markus
Revised rFSM documentation
2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>
> Hi Willy,
>
> (Would you mind switching to plaintext email, this thread is getting
> quite unreadable...)
>
youps
> On Mon, Feb 20, 2012 at 01:29:44PM +0100, Willy Lambert wrote:
> >
> >
> > 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> >
> > On Mon, Feb 20, 2012 at 12:27:46PM +0100, Willy Lambert wrote:
> > >
> > >
> > > 2012/2/20 Markus Klotzbuecher
> > <markus [dot] klotzbuecher [..] ...>
> > >
> > > Hi Willy,
> > >
> > > On Mon, Feb 20, 2012 at 02:33:12AM +0100, Willy Lambert wrote:
> > > >
> > > > I tried to find what is the git repo to get it. If I ead
> > carefully,
> > > there
> > > > is no hints, neither in the cookbook neither in the rfsm
> > doc
> > > >
> > > >
> > > >
> > > > I finish to find it :
> > > > https://github.com/kmarkus/rFSM.git
> > >
> > > Ups, I'll update the docs ASAP!
> > >
> > > > I have some remarks on the documentation (that is very well
> > done
> > btw !
> > > it's
> > > > just about details) :
> > >
> > > Thanks a lot! This feedback is much appreciated!
> > >
> > > > _ I think that it misses emphasis on the fact that the
> > difference
> > between
> > > > composite and simple state is (just ?) the "doo" function.
> > >
> > > Good one! Yes, that is (was) the only difference. For the
> > upcoming
> > > version we have consoldiated composite_state and simple_state,
> > because
> > > this minor difference didn't justify having two primitives and
> > also
> > > because internally there wasn't hardly any difference at all.
> > >
> > >
> > > Ok let me know when I can try the new version.
> >
> > Will do!
> >
> > > > _ I did not understand connector at all. I don't know if it
> > is me
> > or the
> > > fact
> > > > that you know your subject, but I really missed the point
> > >
> > > It's not you, others have been confused too. The connector has
> > several
> > > use cases:
> > >
> > > - initial connector: the default entry point of a composite
> > state
> > >
> > > I don't understand how this is different from 2 transitions. Does
> > this
> > two
> > > lines of the example really need a connector ?
> > >
> > > rfsm.trans{src='initial', tgt='software_err',
> > events={'e_sw_err'}},
> > > rfsm.trans{src='initial', tgt='hardware_err',
> > events={'e_hw_err'}},
> >
> > Here the initial connector define the default way of entering the
> > composite state (here the FSM root). Whenever a transition stops on
> > the boundary of a composite state, you can imagine it extended to
> > its
> > initial connector.
> >
> > >
> > > - as entry and exit points: to permit entering and exiting
> > composite
> > > states in different ways.
> > >
> > > - to permit construction of so called composite transitions
> > built
> > > from multiple simple ones. This is advanced stuff, you'll
> > know it
> > > when you'll need it (it sometimes permits to reduce the
> > number of
> > > transitions drastically or for implementing "dispatchers")
> > >
> > >
> > >
> > > I suggest you edit the example (and add the graphical figure) to
> > have
> > something
> > > showing this different cases, because I think the given example is
> > a bit
> > too
> > > simple to show the connector use cases.
> >
> > Yes, you are right.
> >
> > > This raises other question to me :
> > > _ if a transition is ready when we enter the state, does the doo
> > function
> > be
> > > executed once ?
> >
> > doo has lowest priority, so if you enter a state and there are new
> > events available that trigger an outgoing transition, then that
> > transition will be taken and not the doo.
> >
> > > _ if there are several transition active in several level of the
> > composition,
> > > what will happen ? Does the "top level" transition will have the
> > priority ?
> >
> > Yes, the one whose source state is closest to the FSM root will
> > execute. If two or more at the same level are enabled, you have a
> > conflict and the FSM becomes non-deterministic (i.e. it will take a
> > random one (but don't rely on this being good quality randomness!))
> > You can resolve this using guards or priority numbers.
> >
> > > _ if I come back to my composition above, what is the new initial
> > substate ? is
> > > it the last active, or the coded initial state ?
> >
> > Can you rephrase this question, please?
> >
> >
> >
> > Imagine I have two states A and B. I am in A which initial transition is
> > to go
> > to a1. Something happens I am in a2. Something happens, a transition
> > from A
> > to B is fired. I leave A.a2 state to B.initial state. Something happens,
> > I
>
> An (the!) important property of a connector is that it is not a state,
> hence you can not be in it. You can only be in states. The execution
> of a transition (composite or not) is atomic.
This is an important part to understand what's going on. I think you
should add this to the doc.
But I don't understand where you are in the example when this is triggered :
rfsm.trans{src='software_err', tgt='recovered', events={'e_recovered'}},
You leave software_err for the connector. But as you can't stay in the
connector, I don't really see where you are.
>
> > transit from B to A. Which is the state ? A.a2 or A.initial or A.a1 ?
>
> If you are in some state in B and transition back to A, then A will be
> entered via the initial connector and transition to the state
> connected by that. I hope I understood you correctly, if not, please
> try to specify the question using a textual rFSM model.
that's it. thanks.
>
> > > > _ I find that the 4.1.2 paragraph (Particularities of the
> > root
> > composite
> > > state)
> > > > is a bit short. If I understood it is quite advanced stuff,
> > so
> > reader
> > > don't
> > > > need this at first glance but it stay misterious for me.
> > >
> > > It's a silly title: it should top-level FSM configuration or
> > > similar. At the root state you can configure how
> > errors/warnings are
> > > printed and more importantly, supply the 'getevents' hook,
> > which is a
> > > callback invoked by the rFSM engine to retrieve the current
> > list of
> > > events.
> > >
> > >
> > > I'd had love to see an example of this with few lines of code. It
> > is
> > always
> > > great to be abble to copy paste the example use case for the first
> > time
> > you use
> > > something. It's always reassuring.
> >
> > I'll try to update this soon. If you look at the example here:
> >
> > http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49
> >
> > You can see how first the fsm is loaded from a file:
> >
> > fsm = rfsm.init(rfsm.load("fsm.lua"))
> >
> > and little later the getevents hook is setup to a (generated)
> > function
> > that when called returns all events on the given port
> >
> > fsm.getevents = rfsm_rtt.gen_read_events(events_in)
> >
> > For example to direct the noisy rFSM dbg messages to the rtt logger
> > you could do
> >
> > fsm.info=function(...) rtt.logl('Warning', table.concat({...}, ' '))
> > end
> >
> > > > _ I don't understand the 7.- rfsm-sim end statement : "It
> > requires
> > an
> > > image
> > > > viewer which automatically updates once the file displayed
> > changes.
> > For
> > > example
> > > > evince works nicely." should it go in the 7.5 rfsm-viz
> > section ?
> > >
> > > rfsm-viz only generates different types of figures of you fsm.
> > >
> > > rfsm-sim will simulate a fsm and offer you a simple command
> > line
> > > interface to run/step and send events. It can also draw
> > graphviz
> > based
> > > figures. If you supply a viewer, it will open the file in that
> > viewer
> > > so you get sort of a real-time visualization.
> > >
> > > You should detail the call API of the rfsm-sim then. I don't see
> > how I
> > give him
> > > the graphical editor, is it a parameter or an env variable ?
> >
> > Yes, you can try setting $RFSM_VIEWER to something like evince,
> > okular
> > that will automatically update when the file changes. Note that this
> > is very primitive and likely not very useful to you, but has been
> > valuable during early debugging.
> >
> > > What is the meaning of "all" in second position in the command
> > line ?
> > > tools/rfsm-sim all examples/ball_tracker_scope.lua
> >
> > It means generate "all" types of figures :-)
> >
> > This all needs an update. The problem is that I am working on
> > replacing these primitive tools with something more powerful, but I
> > am not there yet... Meanwhile they are there, because still useful
> >
> > > > _ in the RTT lua cookbook there is no C++ example to run an
> > rFSM in
> > RTT.
> > > Is it
> > > > possible ?
> > >
> > > I've not tried it, but it should not be a problem. Can you
> > explain in
> > > more detail what you want to do?
> > >
> > > > I also need help to use the simu. Something seems to be
> > wrong :
> > > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
> > tools/
> > rfsm-sim
> > > > examples/hello_world.lua
> > > > lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/
> > rfsm-sim.lua:7:
> > > > unexpected symbol near `#'
> > >
> > > Hmm, works here. Is you $LUA environment variable set to
> > something?
> > >
> > >
> > > Yes it should be :
> > > ard@ard-host(9.0):~$ echo $LUA_PATH
> > > ;/opt/ros_addons/orocos_toolchain/rFSM/?.lua;/opt/ros_addons/
> > orocos_toolchain/
> > > ocl/lua/modules/?.lua
> > > ard@ard-host(9.0):~$ roscd rFSM
> > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
> > tools/rfsm-sim
> > all
> > > examples/hello_world.lua
> > > lua:
> > /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
> > > unexpected symbol near `#'
> > >
> > >
> > > Does running it directly as below work?
> > >
> > > $ lua -i tools/rfsm-sim.lua examples/hello_world.lua
> > >
> > >
> > >
> > > No, it's the same :
> > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -i
> > tools/
> > > rfsm-sim.lua examples/hello_world.lua
> > > lua: tools/rfsm-sim.lua:7: unexpected symbol near `#'
> >
> > But what does
> > $ echo $LUA show?
> >
> > and
> >
> > $ lua -v
> >
> > show?
> >
> >
> > I add the dpkg to show youwhat's installed :
> >
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -v
> > Lua 5.0.3 Copyright (C) 1994-2006 Tecgraf, PUC-Rio
>
> This is most likely the problem. Your current Lua is 5.0, which is too
> old for rFSM (which requires 5.1)
>
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ dpkg -l | grep
> > lua
> > ii liblua5.1-0 5.1.4-5
> > Simple, extensible, embeddable programming language
> > ii liblua5.1-0-dev 5.1.4-5
> > Simple, extensible, embeddable programming language
> > ii liblua50 5.0.3-4
> > Main
> > interpreter library for the Lua 5.0 programming language
> > ii liblualib50 5.0.3-4
> > Extension library for the Lua 5.0 programming language
> > ii lua50 5.0.3-4
> > Small embeddable language with simple procedural syntax
> > ii luatex 0.60.2-1
> > next
> > generation TeX engine
> > ii texlive-luatex 2009-11
> > TeX
> > Live: LuaTeX packages
> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
>
> You have both versions installed.
>
> > I have no lua prerequisite, so I can change anything about this
> > installation.
> > Should I use somehting like 'rosdep install' instead of manually doing
> > this ?
>
> If you can I would just throw out the 5.0 versions (liblua50,
> liblualib50, lua50). Alternatively you can switch your current Lua
> using update-alternatives(8) or some gui frontend.
>
> Does this solve the issue?
>
> Best regards
> Markus
Revised rFSM documentation
On Mon, Feb 20, 2012 at 02:28:07PM +0100, Willy Lambert wrote:
> 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> >
> > Hi Willy,
> >
> > (Would you mind switching to plaintext email, this thread is getting
> > quite unreadable...)
> >
>
> youps
Thanks!
> > On Mon, Feb 20, 2012 at 01:29:44PM +0100, Willy Lambert wrote:
> > >
> > >
> > > 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> > >
> > > On Mon, Feb 20, 2012 at 12:27:46PM +0100, Willy Lambert wrote:
> > > >
...
> > > Imagine I have two states A and B. I am in A which initial transition is
> > > to go
> > > to a1. Something happens I am in a2. Something happens, a transition
> > > from A
> > > to B is fired. I leave A.a2 state to B.initial state. Something happens,
> > > I
> >
> > An (the!) important property of a connector is that it is not a state,
> > hence you can not be in it. You can only be in states. The execution
> > of a transition (composite or not) is atomic.
>
> This is an important part to understand what's going on. I think you
> should add this to the doc.
> But I don't understand where you are in the example when this is triggered :
> rfsm.trans{src='software_err', tgt='recovered', events={'e_recovered'}},
>
> You leave software_err for the connector. But as you can't stay in the
> connector, I don't really see where you are.
Ah, now I see the problem. The recovered and failed connectors serve
as exit points (see the comment under the code) hence they will only
be connected to when this error handling fsm is included in some other
FSM.
This is a contrived example, but imagine you wanted to reuse this
error handling fsm. You would load it (e.g. with
error_handler=rfsm.load("err_handler.lua")
When you transition to "error_handler" it will internally dispatch
based on the type of error and try to handle it. The "exit"-API of
this state provides two exit connectors "error_handler.recovered" and
"error_handler.failed" that you then connect to some of your states.
Markus
Revised rFSM documentation
2012/2/20 Willy Lambert <lambert [dot] willy [..] ...>:
> 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>>
>> Hi Willy,
>>
>> (Would you mind switching to plaintext email, this thread is getting
>> quite unreadable...)
>>
>
> youps
>
>> On Mon, Feb 20, 2012 at 01:29:44PM +0100, Willy Lambert wrote:
>> >
>> >
>> > 2012/2/20 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>> >
>> > On Mon, Feb 20, 2012 at 12:27:46PM +0100, Willy Lambert wrote:
>> > >
>> > >
>> > > 2012/2/20 Markus Klotzbuecher
>> > <markus [dot] klotzbuecher [..] ...>
>> > >
>> > > Hi Willy,
>> > >
>> > > On Mon, Feb 20, 2012 at 02:33:12AM +0100, Willy Lambert wrote:
>> > > >
>> > > > I tried to find what is the git repo to get it. If I ead
>> > carefully,
>> > > there
>> > > > is no hints, neither in the cookbook neither in the rfsm
>> > doc
>> > > >
>> > > >
>> > > >
>> > > > I finish to find it :
>> > > > https://github.com/kmarkus/rFSM.git
>> > >
>> > > Ups, I'll update the docs ASAP!
>> > >
>> > > > I have some remarks on the documentation (that is very well
>> > done
>> > btw !
>> > > it's
>> > > > just about details) :
>> > >
>> > > Thanks a lot! This feedback is much appreciated!
>> > >
>> > > > _ I think that it misses emphasis on the fact that the
>> > difference
>> > between
>> > > > composite and simple state is (just ?) the "doo" function.
>> > >
>> > > Good one! Yes, that is (was) the only difference. For the
>> > upcoming
>> > > version we have consoldiated composite_state and simple_state,
>> > because
>> > > this minor difference didn't justify having two primitives and
>> > also
>> > > because internally there wasn't hardly any difference at all.
>> > >
>> > >
>> > > Ok let me know when I can try the new version.
>> >
>> > Will do!
>> >
>> > > > _ I did not understand connector at all. I don't know if it
>> > is me
>> > or the
>> > > fact
>> > > > that you know your subject, but I really missed the point
>> > >
>> > > It's not you, others have been confused too. The connector has
>> > several
>> > > use cases:
>> > >
>> > > - initial connector: the default entry point of a composite
>> > state
>> > >
>> > > I don't understand how this is different from 2 transitions. Does
>> > this
>> > two
>> > > lines of the example really need a connector ?
>> > >
>> > > rfsm.trans{src='initial', tgt='software_err',
>> > events={'e_sw_err'}},
>> > > rfsm.trans{src='initial', tgt='hardware_err',
>> > events={'e_hw_err'}},
>> >
>> > Here the initial connector define the default way of entering the
>> > composite state (here the FSM root). Whenever a transition stops on
>> > the boundary of a composite state, you can imagine it extended to
>> > its
>> > initial connector.
>> >
>> > >
>> > > - as entry and exit points: to permit entering and exiting
>> > composite
>> > > states in different ways.
>> > >
>> > > - to permit construction of so called composite transitions
>> > built
>> > > from multiple simple ones. This is advanced stuff, you'll
>> > know it
>> > > when you'll need it (it sometimes permits to reduce the
>> > number of
>> > > transitions drastically or for implementing "dispatchers")
>> > >
>> > >
>> > >
>> > > I suggest you edit the example (and add the graphical figure) to
>> > have
>> > something
>> > > showing this different cases, because I think the given example is
>> > a bit
>> > too
>> > > simple to show the connector use cases.
>> >
>> > Yes, you are right.
>> >
>> > > This raises other question to me :
>> > > _ if a transition is ready when we enter the state, does the doo
>> > function
>> > be
>> > > executed once ?
>> >
>> > doo has lowest priority, so if you enter a state and there are new
>> > events available that trigger an outgoing transition, then that
>> > transition will be taken and not the doo.
>> >
>> > > _ if there are several transition active in several level of the
>> > composition,
>> > > what will happen ? Does the "top level" transition will have the
>> > priority ?
>> >
>> > Yes, the one whose source state is closest to the FSM root will
>> > execute. If two or more at the same level are enabled, you have a
>> > conflict and the FSM becomes non-deterministic (i.e. it will take a
>> > random one (but don't rely on this being good quality randomness!))
>> > You can resolve this using guards or priority numbers.
>> >
>> > > _ if I come back to my composition above, what is the new initial
>> > substate ? is
>> > > it the last active, or the coded initial state ?
>> >
>> > Can you rephrase this question, please?
>> >
>> >
>> >
>> > Imagine I have two states A and B. I am in A which initial transition is
>> > to go
>> > to a1. Something happens I am in a2. Something happens, a transition
>> > from A
>> > to B is fired. I leave A.a2 state to B.initial state. Something happens,
>> > I
>>
>> An (the!) important property of a connector is that it is not a state,
>> hence you can not be in it. You can only be in states. The execution
>> of a transition (composite or not) is atomic.
>
> This is an important part to understand what's going on. I think you
> should add this to the doc.
> But I don't understand where you are in the example when this is triggered :
> rfsm.trans{src='software_err', tgt='recovered', events={'e_recovered'}},
>
> You leave software_err for the connector. But as you can't stay in the
> connector, I don't really see where you are.
>
>>
>> > transit from B to A. Which is the state ? A.a2 or A.initial or A.a1 ?
>>
>> If you are in some state in B and transition back to A, then A will be
>> entered via the initial connector and transition to the state
>> connected by that. I hope I understood you correctly, if not, please
>> try to specify the question using a textual rFSM model.
>
> that's it. thanks.
>
>>
>> > > > _ I find that the 4.1.2 paragraph (Particularities of the
>> > root
>> > composite
>> > > state)
>> > > > is a bit short. If I understood it is quite advanced stuff,
>> > so
>> > reader
>> > > don't
>> > > > need this at first glance but it stay misterious for me.
>> > >
>> > > It's a silly title: it should top-level FSM configuration or
>> > > similar. At the root state you can configure how
>> > errors/warnings are
>> > > printed and more importantly, supply the 'getevents' hook,
>> > which is a
>> > > callback invoked by the rFSM engine to retrieve the current
>> > list of
>> > > events.
>> > >
>> > >
>> > > I'd had love to see an example of this with few lines of code. It
>> > is
>> > always
>> > > great to be abble to copy paste the example use case for the first
>> > time
>> > you use
>> > > something. It's always reassuring.
>> >
>> > I'll try to update this soon. If you look at the example here:
>> >
>> > http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49
>> >
>> > You can see how first the fsm is loaded from a file:
>> >
>> > fsm = rfsm.init(rfsm.load("fsm.lua"))
>> >
>> > and little later the getevents hook is setup to a (generated)
>> > function
>> > that when called returns all events on the given port
>> >
>> > fsm.getevents = rfsm_rtt.gen_read_events(events_in)
>> >
>> > For example to direct the noisy rFSM dbg messages to the rtt logger
>> > you could do
>> >
>> > fsm.info=function(...) rtt.logl('Warning', table.concat({...}, ' '))
>> > end
>> >
>> > > > _ I don't understand the 7.- rfsm-sim end statement : "It
>> > requires
>> > an
>> > > image
>> > > > viewer which automatically updates once the file displayed
>> > changes.
>> > For
>> > > example
>> > > > evince works nicely." should it go in the 7.5 rfsm-viz
>> > section ?
>> > >
>> > > rfsm-viz only generates different types of figures of you fsm.
>> > >
>> > > rfsm-sim will simulate a fsm and offer you a simple command
>> > line
>> > > interface to run/step and send events. It can also draw
>> > graphviz
>> > based
>> > > figures. If you supply a viewer, it will open the file in that
>> > viewer
>> > > so you get sort of a real-time visualization.
>> > >
>> > > You should detail the call API of the rfsm-sim then. I don't see
>> > how I
>> > give him
>> > > the graphical editor, is it a parameter or an env variable ?
>> >
>> > Yes, you can try setting $RFSM_VIEWER to something like evince,
>> > okular
>> > that will automatically update when the file changes. Note that this
>> > is very primitive and likely not very useful to you, but has been
>> > valuable during early debugging.
>> >
>> > > What is the meaning of "all" in second position in the command
>> > line ?
>> > > tools/rfsm-sim all examples/ball_tracker_scope.lua
>> >
>> > It means generate "all" types of figures :-)
>> >
>> > This all needs an update. The problem is that I am working on
>> > replacing these primitive tools with something more powerful, but I
>> > am not there yet... Meanwhile they are there, because still useful
>> >
>> > > > _ in the RTT lua cookbook there is no C++ example to run an
>> > rFSM in
>> > RTT.
>> > > Is it
>> > > > possible ?
>> > >
>> > > I've not tried it, but it should not be a problem. Can you
>> > explain in
>> > > more detail what you want to do?
I'd like to do the same thing that the exemple in the Cookbook,
loading a state machine in the configureHook. But I'd like to do it
from the C++
>> > >
>> > > > I also need help to use the simu. Something seems to be
>> > wrong :
>> > > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
>> > tools/
>> > rfsm-sim
>> > > > examples/hello_world.lua
>> > > > lua: /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/
>> > rfsm-sim.lua:7:
>> > > > unexpected symbol near `#'
>> > >
>> > > Hmm, works here. Is you $LUA environment variable set to
>> > something?
>> > >
>> > >
>> > > Yes it should be :
>> > > ard@ard-host(9.0):~$ echo $LUA_PATH
>> > > ;/opt/ros_addons/orocos_toolchain/rFSM/?.lua;/opt/ros_addons/
>> > orocos_toolchain/
>> > > ocl/lua/modules/?.lua
>> > > ard@ard-host(9.0):~$ roscd rFSM
>> > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
>> > tools/rfsm-sim
>> > all
>> > > examples/hello_world.lua
>> > > lua:
>> > /opt/ros_addons-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:7:
>> > > unexpected symbol near `#'
>> > >
>> > >
>> > > Does running it directly as below work?
>> > >
>> > > $ lua -i tools/rfsm-sim.lua examples/hello_world.lua
>> > >
>> > >
>> > >
>> > > No, it's the same :
>> > > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -i
>> > tools/
>> > > rfsm-sim.lua examples/hello_world.lua
>> > > lua: tools/rfsm-sim.lua:7: unexpected symbol near `#'
>> >
>> > But what does
>> > $ echo $LUA show?
>> >
>> > and
>> >
>> > $ lua -v
>> >
>> > show?
>> >
>> >
>> > I add the dpkg to show youwhat's installed :
>> >
>> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -v
>> > Lua 5.0.3 Copyright (C) 1994-2006 Tecgraf, PUC-Rio
>>
>> This is most likely the problem. Your current Lua is 5.0, which is too
>> old for rFSM (which requires 5.1)
>>
>> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ dpkg -l | grep
>> > lua
>> > ii liblua5.1-0 5.1.4-5
>> > Simple, extensible, embeddable programming language
>> > ii liblua5.1-0-dev 5.1.4-5
>> > Simple, extensible, embeddable programming language
>> > ii liblua50 5.0.3-4
>> > Main
>> > interpreter library for the Lua 5.0 programming language
>> > ii liblualib50 5.0.3-4
>> > Extension library for the Lua 5.0 programming language
>> > ii lua50 5.0.3-4
>> > Small embeddable language with simple procedural syntax
>> > ii luatex 0.60.2-1
>> > next
>> > generation TeX engine
>> > ii texlive-luatex 2009-11
>> > TeX
>> > Live: LuaTeX packages
>> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
>>
>> You have both versions installed.
>>
>> > I have no lua prerequisite, so I can change anything about this
>> > installation.
>> > Should I use somehting like 'rosdep install' instead of manually doing
>> > this ?
>>
>> If you can I would just throw out the 5.0 versions (liblua50,
>> liblualib50, lua50). Alternatively you can switch your current Lua
>> using update-alternatives(8) or some gui frontend.
>>
>> Does this solve the issue?
>>
It's better, I apt-get removed all the lua5.0 stuff and add the
interpreter lua5.1.
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -v
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ echo $LUA
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
tools/rfsm-sim all examples/hello_world.lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
lua: /opt/ros_addons/orocos_toolchain/rFSM/rfsm2uml.lua:37: module
'gv' not found:
no field package.preload['gv']
no file '/opt/ros_addons/orocos_toolchain/rFSM/gv.lua'
no file '/opt/ros_addons/orocos_toolchain/ocl/lua/modules/gv.lua'
no file './gv.so'
no file '/usr/local/lib/lua/5.1/gv.so'
no file '/usr/lib/lua/5.1/gv.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
[C]: in function 'require'
/opt/ros_addons/orocos_toolchain/rFSM/rfsm2uml.lua:37: in main chunk
[C]: in function 'require'
...ns-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:4: in main chunk
[C]: ?
Now it seems like I miss some lua dependencies. So I added the
libgv-lua debian package. To sum up I had to apt-get :
liblua5.1-0
lua5.1
libgv-lua
Could we add this dependencies to the manifest, so that it is a
"correct" ROS package ? (I don't know how the Orocos toolchain manage
this king of package dependencies).
I then have a problem with the "all" statement :
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
tools/rfsm-sim all examples/hello_world.lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
rFSM simulator v0.1, type 'help()' to list available commands
lua: cannot open all: No such file or directory
stack traceback:
[C]: in function 'dofile'
/opt/ros_addons/orocos_toolchain/rFSM/rfsm.lua:220: in function 'load'
...ns-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:126: in main chunk
[C]: ?
So I suppressed it and it seems to work
ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
tools/rfsm-sim examples/hello_world.lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
rFSM simulator v0.1, type 'help()' to list available commands
INFO: created undeclared connector root.initial
>
Thanks for your time !
>> Best regards
>> Markus
Revised rFSM documentation
On Mon, Feb 20, 2012 at 02:45:21PM +0100, Willy Lambert wrote:
> 2012/2/20 Willy Lambert <lambert [dot] willy [..] ...>:
...
> >> > I add the dpkg to show youwhat's installed :
> >> >
> >> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -v
> >> > Lua 5.0.3 Copyright (C) 1994-2006 Tecgraf, PUC-Rio
> >>
> >> This is most likely the problem. Your current Lua is 5.0, which is too
> >> old for rFSM (which requires 5.1)
> >>
> >> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ dpkg -l | grep
> >> > lua
> >> > ii liblua5.1-0 5.1.4-5
> >> > Simple, extensible, embeddable programming language
> >> > ii liblua5.1-0-dev 5.1.4-5
> >> > Simple, extensible, embeddable programming language
> >> > ii liblua50 5.0.3-4
> >> > Main
> >> > interpreter library for the Lua 5.0 programming language
> >> > ii liblualib50 5.0.3-4
> >> > Extension library for the Lua 5.0 programming language
> >> > ii lua50 5.0.3-4
> >> > Small embeddable language with simple procedural syntax
> >> > ii luatex 0.60.2-1
> >> > next
> >> > generation TeX engine
> >> > ii texlive-luatex 2009-11
> >> > TeX
> >> > Live: LuaTeX packages
> >> > ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
> >>
> >> You have both versions installed.
> >>
> >> > I have no lua prerequisite, so I can change anything about this
> >> > installation.
> >> > Should I use somehting like 'rosdep install' instead of manually doing
> >> > this ?
> >>
> >> If you can I would just throw out the 5.0 versions (liblua50,
> >> liblualib50, lua50). Alternatively you can switch your current Lua
> >> using update-alternatives(8) or some gui frontend.
> >>
> >> Does this solve the issue?
> >>
>
> It's better, I apt-get removed all the lua5.0 stuff and add the
> interpreter lua5.1.
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ lua -v
> Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$ echo $LUA
>
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
> tools/rfsm-sim all examples/hello_world.lua
> Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> lua: /opt/ros_addons/orocos_toolchain/rFSM/rfsm2uml.lua:37: module
> 'gv' not found:
> no field package.preload['gv']
> no file '/opt/ros_addons/orocos_toolchain/rFSM/gv.lua'
> no file '/opt/ros_addons/orocos_toolchain/ocl/lua/modules/gv.lua'
> no file './gv.so'
> no file '/usr/local/lib/lua/5.1/gv.so'
> no file '/usr/lib/lua/5.1/gv.so'
> no file '/usr/local/lib/lua/5.1/loadall.so'
> stack traceback:
> [C]: in function 'require'
> /opt/ros_addons/orocos_toolchain/rFSM/rfsm2uml.lua:37: in main chunk
> [C]: in function 'require'
> ...ns-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:4: in main chunk
> [C]: ?
>
>
> Now it seems like I miss some lua dependencies. So I added the
> libgv-lua debian package. To sum up I had to apt-get :
> liblua5.1-0
> lua5.1
> libgv-lua
Exactly.
> Could we add this dependencies to the manifest, so that it is a
> "correct" ROS package ? (I don't know how the Orocos toolchain manage
> this king of package dependencies).
Yes, unless I manage to replace this old stuff with something better
quickly.
> I then have a problem with the "all" statement :
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
> tools/rfsm-sim all examples/hello_world.lua
> Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> rFSM simulator v0.1, type 'help()' to list available commands
> lua: cannot open all: No such file or directory
> stack traceback:
> [C]: in function 'dofile'
> /opt/ros_addons/orocos_toolchain/rFSM/rfsm.lua:220: in function 'load'
> ...ns-electric/orocos_toolchain/rFSM/tools/rfsm-sim.lua:126: in main chunk
> [C]: ?
"all" only works with rfsm-viz :-)
>
> So I suppressed it and it seems to work
> ard@ard-host(9.0):/opt/ros_addons/orocos_toolchain/rFSM$
> tools/rfsm-sim examples/hello_world.lua
> Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> rFSM simulator v0.1, type 'help()' to list available commands
> INFO: created undeclared connector root.initial
Looks good!
> Thanks for your time !
Thank you :-)
Markus
Revised rFSM documentation
Hello, I'm running into this same issue as Willy Lambert mentioned above, however installing the packages he mentioned: liblua5.1-0, lua5.1, and libgv-lua did not change anything. I've gotten the rFSM code fresh from the repo and straight out of the box, with those packages I mentioned, I still get the "module 'gv' not found" error on trying to run either the test scripts or the hello world. Anyone have any ideas?
Revised rFSM
Hi,
On Fri, Nov 09, 2012 at 09:04:29PM +0000, charles [dot] a [dot] claunch [..] ... wrote:
> I'm running into this same issue as Willy Lambert mentioned above, however
> installing the packages he mentioned: liblua5.1-0, lua5.1, and libgv-lua did
> not change anything. I've gotten the rFSM code fresh from the repo and
> straight out of the box, with those packages I mentioned, I still get the
> "module 'gv' not found" error on trying to run either the test scripts or the
> hello world. Anyone have any ideas?
What does
$ lua -l gv
output? What distribution and version are you using?
Markus
Revised rFSM
Hi Charles,
On Fri, Nov 9, 2012 at 10:04 PM, <charles [dot] a [dot] claunch [..] ...> wrote:
> Hello,
> I'm running into this same issue as Willy Lambert mentioned above, however
> installing the packages he mentioned: liblua5.1-0, lua5.1, and libgv-lua did
> not change anything. I've gotten the rFSM code fresh from the repo and
> straight out of the box, with those packages I mentioned, I still get the
> "module 'gv' not found" error on trying to run either the test scripts or the
> hello world. Anyone have any ideas?
Probably your LUA_CPATH environment variable is wrongly set. You can
first test this theory by doing:
unset LUA_CPATH
lua -l gv
(no errors should be printed)
Make sure that if LUA_CPATH is set, it starts with three ';' signs, ie
export LUA_CPATH=";;;/home/user/..."
';;;' means: search the default search paths as well.
Peter
Revised rFSM
Thanks Peter! Yes my LUA_CPATH had a hard set value from another project. Adding the ;;; to the front fixed my issue. Will have to get with our developers here to correct that.
Thanks again,
Chuck
-----Original Message-----
From: Peter Soetens [mailto:peter [..] ...]
Sent: Friday, November 09, 2012 3:35 PM
To: Claunch, Charles A. (JSC-ER4)[Jacobs Technology]
Cc: orocos-users [..] ...
Subject: Re: [Orocos-users] Revised rFSM
Hi Charles,
On Fri, Nov 9, 2012 at 10:04 PM, <charles [dot] a [dot] claunch [..] ...> wrote:
> Hello,
> I'm running into this same issue as Willy Lambert mentioned above,
> however installing the packages he mentioned: liblua5.1-0, lua5.1, and
> libgv-lua did not change anything. I've gotten the rFSM code fresh
> from the repo and straight out of the box, with those packages I
> mentioned, I still get the "module 'gv' not found" error on trying to
> run either the test scripts or the hello world. Anyone have any ideas?
Probably your LUA_CPATH environment variable is wrongly set. You can first test this theory by doing:
unset LUA_CPATH
lua -l gv
(no errors should be printed)
Make sure that if LUA_CPATH is set, it starts with three ';' signs, ie export LUA_CPATH=";;;/home/user/..."
';;;' means: search the default search paths as well.
Peter
Revised rFSM
2012/11/9 Peter Soetens <peter [..] ...>
> Hi Charles,
>
> On Fri, Nov 9, 2012 at 10:04 PM, <charles [dot] a [dot] claunch [..] ...> wrote:
> > Hello,
> > I'm running into this same issue as Willy Lambert mentioned above,
>
FYI, my project is sleeping a bit for some time, so I don't have the mean
to compare with my system :(
BTW, I'm reading all this with by emails and the "above" conversation is
not sent with the email. Is there any issue with the mail/forum system ?
> however
> > installing the packages he mentioned: liblua5.1-0, lua5.1, and libgv-lua
> did
> > not change anything. I've gotten the rFSM code fresh from the repo and
> > straight out of the box, with those packages I mentioned, I still get the
> > "module 'gv' not found" error on trying to run either the test scripts
> or the
> > hello world. Anyone have any ideas?
>
> Probably your LUA_CPATH environment variable is wrongly set. You can
> first test this theory by doing:
>
> unset LUA_CPATH
> lua -l gv
> (no errors should be printed)
>
> Make sure that if LUA_CPATH is set, it starts with three ';' signs, ie
> export LUA_CPATH=";;;/home/user/..."
>
> ';;;' means: search the default search paths as well.
>
> Peter
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>