## 6 Implementation and Validation
### Implementation
#### 6.1.1 Iterative Components and Activation Trees  
In Section 2, we explained that a component was the building block of an activation tree. In this section, we show the properties and requirements of the components. One of the main problems was that any component could disappear silently and return to life at any time. In this section, we are going to show how it can be implemented.  
We use ROS as middleware, mapping a component to a ROS node. The identifier of a component matches the name of the node. We will use two of the communication paradigms that ROS provides us with: services (synchronous 1: 1 communication) and publication/subscription (asynchronous N:M communication). ROS also allows introspection of the computation graph, which contains the running ROS nodes.  
A component has a step() method that is called at a configurable frequency. This method is the entry point of a component's execution. It also has an addDependency() method to declare its dependencies, namely the components that must be active if this component is active. A component starts inactive, and is only active in the following cases:  
* At least one active component has declared it as a dependency.
* It is the root of an execution tree and has been marked as active by default.  
In each iteration, a component also manages its active state and that of its dependencies behind the scenes. Each component maintains two lists to keep track of the components it activates, and another for the components that activate it.  
* In each iteration, the active components send a heartbeat to a topic/active. All nodes publish and subscribe to this topic.
* For each component in the activator list, it is checked whether they continue to send a heartbeat. If not, it is considered inactive and is removed from the activator list. For the activated node, there is no difference between a component that no longer exists, and one that is not active.
* For each component in the dependency list, it is checked if it exists (the ROS node is part of the computation tree) and is active since it is sending heartbeats. In this case, the component uses a service to request the dependency to be active. The dependency adds the component to its list of activators.  
To implement FSM, we have added another removeDependency() method, which allows you to remove a dependency declaration. This method allows the activation tree to be dynamically modified. This functionality is only recommended when using FSM, where states can have different dependencies.  
We use Visual Component Editor (VICODE) to facilitate the development of FSMs. This editor, shown in Figure 8, allows to define state machines graphically. VICODE generates the skeleton of a state machine, which already manages dependency activation/deactivation. The programmer only has to fill in the code of the states and their transitions. The generated skeleton is a base class that contains methods that can be redefined:  
* Transitions: For each transition, a method is created that returns true if the transition should be carried out. In the base class, the method returns false.
* States: For each state, two methods are created that are empty in the base class. One is called each iteration, and another only once per state. Depending on the desired behavior in this state, this method is redefined.