FSM Nodes & Transitions

1. FSM Nodes & Transitions Robotics Seminar CSI445/660 Spring 2006 Robert Salkin University at Albany, SUNY

2. Finite State Machines • Def: • An abstract machine that defines a finite set of conditions of existence (called “states”), a set of behaviors or actions performed in each of those states, and a set of events that cause changes in states according to a finite and well-defined rule set [1.1]. • A knowledge representation that makes different states in a process explicit, and connects them with links which specify some transition condition that specifies how one traverses from one state to another [1.2].

3. Say Again? • Explanation: • FSMs are an efficient way to specify constraints of the overall behavior of a system [1.1]. • Being in a state means that the system responds only to a subset of all allowed inputs, produces only a subset of possible responses, and changes state directly to only a subset of all possible states. [1.1] • FSMs allow programmers to decompose large, complex systems into modules called states (or nodes), where transitions handle flow control.

4. Finite State Diagram start Obstacle (IR < 350 mm) Walk Forward Turn at angle 2 second timeout Explore Machine transition node

5. StateNode • Tekkotsu partially employs its FSM architecture through the “StateNode” class. • A StateNode is: • a Behavior • “state machine controller as well as a node within a state machine itself”. • what does this mean and why do we want it? • So for each task that we define for the system, there must be a node (inherited from StateNode) that can carry it out. • Tekkotsu comes with some of the most common needs: • WalkNode : Walks at a given velocity (WalkMC) • GroupNode: Allows a one-to-many node activation (not deactivation) • PlayMotionSequenceNode< SIZE > : Run a motion sequence (or posture)

6. Framework StateNode : BehaviorBase{ public: ... DoStart() DoStop() addTransition(Transition *) // add a transition from this node to another addNode(StateNode *) // add a node to a network from which this // node is the controller setup() // functioning as a controller, define the // network here teardown() // undo setup … protected: std::vector<StateNode *> nodes; //nodes in our machine std::vector<Transition *> transitions; //”registered” transitions }

7. StateNode Life-Cycle • Recall the original Behavior life-cycle… • Constructor -> DoStart -> [processEvents ->] DoStop -> Destructor • Each StateNode now flows like this… • Constructor -> setup -> DoStart -> [processEvents ->] teardown -> DoStop -> Destructor • setup is called by StateNode::DoStart. • teardown is called by StateNode::DoStop. • Remember that all nodes are inherited from StateNode.

8. Defining Nodes in the Network • Recall that a StateNode can be a node in a network, or the controlling node over a network. • The design is done in the setup() method of the controlling node. • Coding for the FSM diagram a few slides back… virtual void setup(){ //... //add and allocate two nodes that we want as part of our network start=addNode(turn=new WalkNode(0,0,0.5f,this)); addNode(move=new WalkNode(150,0,0,this)); //set the names for consistency’s sake turn->setName(getName()+"::turn"); move->setName(getName()+"::move"); //… } • This creates two walk nodes; one to go forward, and one to turn

9. Transitions • Now that we have an idea about how, why, and what nodes are about, Transitions tie them together. • The Transition class: • is “smart” • “they are behaviors in and of themselves and can listen for events and use the standard DoStart/DoStop interface. Based on the events they receive, they can fire() themselves and cause a state transition.” • Once defined properly, a transition activates and deactivates itself without any further code. • Can activate more than one node • Used in place of if/else statements (and possibly complex/messy logic)

10. How does it work ? • Remember that a transition is also a behavior… • The (overloaded) constructor of the class adds the destination node to a protected STL vector through a call to the base constructor. • other comparison values are stored “locally” by need • an event to be used for comparison is included as an argument. • DoStart and DoStop function to register/forget the above event. • processEvent monitors as usual, makes the appropriate comparison, and runs fire() when the target condition is satisfied. • fire is defined in Transition, and need not be overridden. • fire calls doStop on each source node, and calls doStart on each destination node.

11. More Trans • Like Nodes, Tekkotsu comes standard with the most common transitions: • SmoothCompareTrans< T > : This template takes a number of different values and keeps a running average of the values based on a given gamma value (hence the “Smooth” compare). Once a certain threshold is reached for comparison, it causes the transition. • Most commonly used so far • TimeOutTrans : Wait for a specified amount of time (ms), then transition • also fairly common • VisualTargetCloseTrans : causes a transition when a visual object is "close" . • When would this be beneficial? • See classes that inherit from Transition… • http://www-2.cs.cmu.edu/~tekkotsu/dox/classTransition.html

12. Implementing • Like node definitions, transitions are defined in the network inside the setup() method of the controlling node. • Continuing with the ExploreMachine example: • move->addTransition(new SmoothCompareTrans<float>(turn,&state->sensors[IRDistOffset],CompareTrans<float>::LT,350,EventBase(EventBase::sensorEGID,SensorSourceID::UpdatedSID,EventBase::statusETID),.7)); • transition from the “move” node to the “turn” node when the IR sensor is less than 350. • turn->addTransition(new TimeOutTrans(move,2000)); • transition from the “turn” to “move” node after 2 seconds. • Note the order which node / transitions are declared is unimportant. DoStart of the controlling node starts initial node in the network (move in this case). Well defined transitions handle everything else from there. • start->DoStart(); • this assumes that you’ve created a StateNode * called start and assigned it to your starting node.

13. Some Notes • Take a look at: • http://aquarius.ils.albany.edu/robotics/Shawn_Tekkotsu.doc • This gives an overview (with example and more detail) like this lecture. • Keep in mind the following: • When a transition is activated, doStop of the source node is run, and doStart of the destination node is also run. • So variables and structures are not persistent (torn down by doStop). • Keep dynamic memory and object instantiation to a minimum in these nodes as they get continually started and stopped. • Object creation is relatively expensive • If a primitive can do it, let it. • The controlling node is active as so long as the Automata is running • keep bulky objects here • There’s nothing that says you can’t create nodes with extra parameters for pointers and such • Behaviors share address space, this is OK. • Let’s walk through ExploreMachine… • http://www-2.cs.cmu.edu/~tekkotsu/dox/ExploreMachine_8cc-source.html

14. Customization • Clearly there are many tasks which can be performed using the tools (nodes & transitions) that are supplied with the framework. • There may be times when more intense tasks or more discriminative transitions are needed. • It is therefore necessary to be able to write custom nodes or transitions. • If one has a clear understanding of how behaviors and the FSM construct work in Tekkotsu, this is really pretty straightforward. • Take a look at the tekkotsu API for those new virtuals that need to be overloaded and what data members need to be updated in order for new nodes / transitions to be effective. • Look back at the earlier node and transition slides (and Tekkotsu documentation) for a conceptual look at how they work.

15. Design Thoughts • Keep the transitions / nodes as simple and straightforward as possible. • Maintain flow control (in a way you and others can understand) • Test each node separately before adding it to your network

16. Summary • Finite State Machines are a way to decompose large systems into clear, well-defined submodules. • Each module is called a node • Conditions connecting nodes are called transitions • FSMs are achieved in Tekkotsu through subclasses of the StateNode and Transition class. • Each StateNode (and Transition) is a Behavior. • Each Tekkotsu node can either be a module of a system, or the controlling node of a larger system. • Each network is defined in the virtual method setup • Likewise, teardown is called on the way out. • We use the addNode and addTransition methods of the StateNode class to clearly define our Automata. • Behaviors written using the FSM architecture are required to “manually” start the machine by calling DoStart of the starting node. • A well formed Architecture should then be automatous. • Transitions activate / deactivate themselves from there.

17. IMPORTANT Links • Tutorial • http://www.cs.cmu.edu/~dst/Tekkotsu/Tutorial/state.shtml • Storyboard Tool • Visualizes your FSM based Behavior • http://www.cs.cmu.edu/~dst/Tekkotsu/Tutorial/storyboard.shtml

18. Term project • At this stage in the semester, you should be thinking about possible topics for your term project. • Next class – we’ll discuss your project ideas and present other possibilities. • HW5 is the last formal homework. • The remaining portion of the class will be dedicated to you term project, discussing more in-depth topics (as requested), and possibly exploring current robotics research.

19. References • Google Dictionary Search (FSM) • www.quantum-leaps.com/glossary.htm • www.uhnres.utoronto.ca/ehealth/html/glossary/eh_glossary.shtml • Shawn Turner