[Trac] [AllemaniACs] #59: Lua state machine

AllemaniACs trac-notifications at lists.kbsg.rwth-aachen.de
Mon Jun 16 10:42:50 CEST 2008


#59: Lua state machine
---------------------+------------------------------------------------------
 Reporter:  tim      |        Owner:  tim     
     Type:  feature  |       Status:  assigned
 Priority:  major    |    Milestone:  RC2008  
Component:  Fawkes   |   Resolution:          
 Keywords:  FSM      |  
---------------------+------------------------------------------------------
Changes (by tim):

  * status:  new => assigned

Old description:

> For reactive behaviours, a reactive agent and challenge applications in
> the !RoboCup at Home league a generally usable Lua (finite) state machine
> (FSM) is necessary.
>
> The state machine should obey the following criteria:
>  - minimum amount of code overhead for the state machine
>  - allow for hierarchical usage, this does not mean that it needs
> explicit API support, but for example that it does not use a global
> variable that prevents us from instantiating several state machines
>  - Allow for the usage of our usual design patterns, like executing code
> on the entry to a state and not (necessarily) on the transition to the
> state. This allows for easier recycling of states, like driving to a
> standby position from different states does not need the very same code
> in every transition, which is more likely to be defined for the outgoing
> state
>  - Allow safe state transitions. An example from the AtHome league: the
> robot is grasping a cup. Now the time is up and to get the points for
> exiting the arena it should abort the current action. This would mean to
> retract the arm and ''then'' leave, and not drive with the extended arm.
> So if the "leave arena" transition is executed by a trigger, the state
> machine should make it simple for this safe behaviour.
>
> Desired but not required features:
>  - Visualization of the state machine (offline)
>  - Visualization of the current FSM state and flow (online)

New description:

 For reactive behaviours, a reactive agent and challenge applications in
 the !RoboCup at Home league a generally usable Lua (finite) state machine
 (FSM) is necessary.

 The state machine should obey the following criteria:
  - minimum amount of code overhead for the state machine
  - allow for hierarchical usage, this does not mean that it needs explicit
 API support, but for example that it does not use a global variable that
 prevents us from instantiating several state machines
  - Allow for the usage of our usual design patterns, like executing code
 on the entry to a state and not (necessarily) on the transition to the
 state. This allows for easier recycling of states, like driving to a
 standby position from different states does not need the very same code in
 every transition, which is more likely to be defined for the outgoing
 state
  - Allow safe state transitions. An example from the AtHome league: the
 robot is grasping a cup. Now the time is up and to get the points for
 exiting the arena it should abort the current action. This would mean to
 retract the arm and ''then'' leave, and not drive with the extended arm.
 So if the "leave arena" transition is executed by a trigger, the state
 machine should make it simple for this safe behaviour.

 Desired but not required features:
  - Visualization of the state machine (offline)
  - Visualization of the current FSM state and flow (online)

 No decisions made, yet.

Comment:

 Up to now I've read a few papers about Computer Game AI. The examples are
 usually at a very basic level and do not give much new information. An
 interesting thing which we might want to use is "Goal Driven AI", which
 basically means defining a policy which is then executed. After the FSM is
 implemented there might be a way to safe some code with this.

 I had a closer look at the [http://smc.sourceforge.net/ state machine
 compiler (SMC)]. The SMC can create code for a number of languages,
 including Lua. However, this also means that it cannot exploit all the
 features available in a particular language. The major problem is, that it
 is not meant to be used with our typical usage patterns. Although
 supported, it is discouraged in the
 [http://smc.sourceforge.net/SmcFaq.htm#TransQueue FAQ].

 I'm currently working on the Lua side determining if we want an own custom
 FSM language or if we want to have it a plain Lua API. Pros for the custom
 language include:
  - FSM domain specific language can make the code simpler
  - From the code it should be easy to generate a graph, for instance using
 graphviz
 Cons for this are:
  - A parser has to be written
  - Inside a state or transition we would like to allow arbitrary Lua code.
 This means that a full Lua parser needs to be used and makes is somewhat
 big (there is an [http://www.inf.puc-rio.br/~roberto/lpeg.html LPeg]-based
 parser called [http://leg.luaforge.net/ Leg]).

-- 
Ticket URL: <https://lechuck.informatik.rwth-aachen.de:2342/trac/ticket/59#comment:1>
AllemaniACs <http://robocup.rwth-aachen.de>
AllemaniACs Trac


More information about the fawkes-trac mailing list