Entry and exit actions for States about rafcon

[sebastian-brunner]

Hi @amitabhn,

thank you for all those interesting questions! We went through most of those when we started to build RAFCON. For a general explanation of many concepts please refer to: https://elib.dlr.de/112067/

I am trying to build a state machine for a reactive system which can have asynchronous external events to trigger state transitions, based on the principles explained in Miro Samek's book Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems.

RAFCON can be used both for goal-oriented and reactive behavior.

Flowcharts strongly influenced RAFCON's design. A state in RAFCON is not a state in a classical FSM, in which a certain condition holds, but in which a certain action is executed. We employed RAFCON for many goal-driven scenarios (e.g. in space use cases like https://www.youtube.com/watch?v=wCTkSxcna8o or https://www.youtube.com/watch?v=UeuNnpJMWKE). In goal-driven scenarios (in contrast to reactive ones) all changes of the environment are an effect of the robot's own actions. There a only a few "external events" the robot has to react to (low voltage, bad signal).

As stated out, RAFCON can be used to build reactive systems as well. Classical state machines or state-charts are just another way to do so. Behavior trees are also a very powerful concept (which could also be programmed in RAFCON; if you are interested I can write a tutorial about that).
RAFCON uses the HPFD formalization (again see https://elib.dlr.de/112067/). We don't have the concept of events in RAFCON, so the 'state machines' we build are different to Harel's Statechart or classical FSMs (Moore, Mealy). We employ observers to take care of certain external or internal events. To implement these you have to use (preemptive) concurrency states. E.g. you set up a preemptive concurrency state with 5 observers, the first one who fires decides the course of action. You can place different observers on different hierarchy levels. Thus, you can define the scope of your 'event' and your 'event handler'.

Some of the concepts mentioned are very helpful in state machine design, notably state entry and exit actions (especially for safety aspects), state specific actions of async events, propagation of async events to superstates till it is not handled, trigger specific actions, event deferral, pseudostates, etc.

Concerning:

• entry action: use an execution state directly after the income
• exit action: use an execution state before each outcome (if you have the same exit action for each outcome this may be a little bit redundant as you have to place the same (library) state in front of each outcome; in our experience exit actions are most of the time outcome-specific except for the preemption and abortion case; for these two you can easily write event handlers for the whole hierarchy as unhandled preemption or abortion outcomes are directly connected to the parental outcome, see https://rafcon.readthedocs.io/en/0.12.25/concepts.html#outcomes)
• state specific actions of async events, propagation of async events to superstates till it is not handled: choose the scope of your hierarchies and observers properly
• trigger specific actions: please be more concrete
• event deferral: this is a hot topic! e.g. see https://amturing.acm.org/p558-lamport.pdf ; technically you could implement it by using concurrency states to set up observers, that do not interrupt the current behavior but just place a signal into a queue (or another appropriate data structure). At certain points (where you would actually react to your deferred event) you would check the queue and handle the event. Another possibility would be to design your preemption handling in a way, that the system does not immediately react to the event, but after the (arbitrary complex) preemption handling behavior.
• pseudo-states: there exist an equivalent for every type of pseudo-state in RAFCON; feel free to ask more specific questions

I was hoping to find an intuitive implementation for the same in python ...

If you want to use the statechart formalization itself, RAFCON is the wrong tool for you. However, if you want to control your robot in different (dynamic) environments, RAFCON is worth having a look at. Personally, I worked with boost statechart (https://www.boost.org/doc/libs/1_53_0/libs/statechart/doc/index.html) a lot during Robocup (see: https://link.springer.com/chapter/10.1007/978-3-642-39250-4_5)).

• Advantage: You can solve medium sized problems (up to 100 states) very elegantly
• Disadvantage: It does not scale

and which also preferably supports easy integration with ROS.

RAFCON is middleware-agnostic (in fact we interfaced RAFCON with already four different middle-wares: ROS, links_and_nodes, sensornet, DDS). Concerning ROS have a look at these examples: https://github.com/DLR-RM/RAFCON-ros-state-machines

Not sure whether this approach would be compliant with the transition execution sequence of an HSM (evaluation of guard condition; exit actions of all nested states; trigger action; entry actions of nested states)

• guard conditions: the RAFCON alternative would be a proper outcome and observer design; feel free to post questions concerning concrete examples here
• entry and exit actions of all nested states: see above
• trigger action: I am not quite sure want you mean here (the link you posted is not secure); if you mean the actions related to transitions => they are modeled differently in RAFCON i.e. they have their own states

Feel free to post more questions or doubts ;-). In any case I would be very interested in your concrete, robotic use case.

[franzlst]

Hi @amitabhn,

despite a very early version of RAFCON included entry and exit scripts for HierarchicyStates, we decided to remove these purposely.

In our experience, most of the time those scripts are not needed, as HierarchyStates often only fulfill a (semantic) grouping purpose.

If you still need these scripts, you can realize them via ExecutionStates at the beginning and end of the HierarchyState.

May I ask you what your purpose is?

[amitabhn]

Hi @franzlst , thanks for your reply.

I am trying to build a state machine for a reactive system which can have asynchronous external events to trigger state transitions, based on the principles explained in Miro Samek's book Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems.

Some of the concepts mentioned are very helpful in state machine design, notably state entry and exit actions (especially for safety aspects), state specific actions of async events, propagation of async events to superstates till it is not handled, trigger specific actions, event deferral, pseudostates, etc.

I was hoping to find an intuitive implementation for the same in python and which also preferably supports easy integration with ROS.

If you still need these scripts, you can realize them via ExecutionStates at the beginning and end of the HierarchyState.

Not sure whether this approach would be compliant with the transition execution sequence of an HSM (evaluation of guard condition; exit actions of all nested states; trigger action; entry actions of nested states)

[franzlst]

One general issue that might arise for your problem together with RAFCON is that RAFCON is not event-driven. If you are interested in the details behind some design decision, I can recommend you our paper about RAFCON.