Design Pattern CatalogueDesign Pattern Application RulesDesign Pattern Application ExamplesPublications
Design Pattern Application Rules
The usage of different design patterns in a robot control algorithm can be facilitated by identifying Application Rules for modifying and combining the BDRML pattern representations. Compulsory Rules (C), represent a minimal set of steps for combining patterns and should always be applied. Other rules are optional, and include those for extending (EXT) and redefining (RDF) information processing routines of patterns, and those for concretising (CNC) the patterns.
Compulsory Application Rules
- C1. Relabel any elements of the selected design patterns that are ambiguous with respect to one another or to the control algorithm that is being created. For instance, identify any equivalences between design pattern elements that appear in more than one of the original design patterns (e.g., two design patterns may each involve reading the same external environmental data but allocate it a different identifier). Analogously, identify any distinctions between labels that appear in more than one of the original design patterns (e.g., two design patterns may each employ the identifier "Worksite", without this label necessarily referring to the same entity). Finally, rename primitives in order to better facilitate understanding of the control algorithm, especially if the original design patterns use general labels, such as "Worksite data".
- C2. Copy all sets of behaviours, Bi, from all patterns into a new behaviour set, B', i.e., B' = { B1 ∪ B2 ∪ ... ∪ Bn }.
- C3. Copy common data structures from design pattern data structure sets Di and De into new sets, Di' and De', i.e., Di' = { Di1 ∩ Di2 ∩ ... ∩ Din }, De' = { De1 ∩ De2 ∩ ... ∩ Den }.Choose appropriate data types if the design pattern data structures define multiple data type options.
- C4. Copy all relations between the primitives that belong to sets B', Di' and De', including their conditions. Unless it is otherwise specified by a relation condition, assume the or operator when combining conditions. All conditions with the or operator should be considered optional[1]. Additionally, when the "always" condition is combined with others, the "always" condition should be deleted[2].
Rules for extending information processing routines
- EXT1. Add additional data structures into Di' and De' from an included Information Transmitter pattern that have a read relation with a behaviour, or a copy relation with a data structure already present in Di' or De'. This allows one pattern to extend the list of information processing routines of another, while ensuring that Information Transmitter patterns play a decisive role in what data structures are used in the robot program.
- EXT2. Apply Rule C4.
Rules for redefining information processing routines
- RDF1. Delete all relations that belong to shorter relation paths between behaviours and data structures (but not between behaviours) that are of the same type (for example, send relations). A relation path specifies a set of relations that lead from a primitive V1 to a primitive V2, including those relations that pass through other primitives and create an indirect relation between V1 and V2.
- RDF2. If applicable, use conditions from deleted relation paths on the relation paths that are left over. For example, if relation between V1 and V2 with a condition c was deleted, and a new relation between V3 and V2 exists instead, it may be appropriate to add condition c to this relation.
Rules for concretising patterns
Patterns can be concretised in order to better describe the dynamics of an implemented robot control algorithm by using the following rule:- CNC1. Add additional specifications to write, send and update relations in order to identify how they change the values of their corresponding data structures.
Combining design pattern characteristics
Apart from a BDRML representation of the robot behaviour, other characteristics of design patterns should be considered together when design patterns are combined. The list of suitable applications becomes more specific when multiple patterns form a control algorithm. Or, from another point of view, a more detailed specification of the swarm’s environment and task allows a programmer to choose between design patterns with a higher confidence.The list of control algorithm parameters also grows when multiple patterns are combined. Therefore, in order to minimise the number of design decisions that need to be made, design patterns with a smaller number of parameters should be preferred where possible. Unless an exhaustive list of situations is considered during a control algorithm optimisation phase, or unless a suitable on-line parameter learning algorithm is implemented, each new parameter can lead to undesirable dynamics.
Examples
Have a look at some simple examples of combining design patterns.More complex examples are provided in Pitonakova et al. (2018) Information Exchange Design Patterns for Robot Swarm Foraging and Their Application in Robot Control Algorithms.
[1] An "or" condition defines additional situations in which a relation is applicable. In the most extreme case of the condition being empty, "or false" is aredundant expressions and can therefore be omitted.
[2] The "always" condition always returns "true" and it should therefore be combined with other conditions using the "and" operator, ensuring that the otherconditions are satisfied according to their specifications. Since "and true" is a redundant expression, the "always" condition can be deleted.
[2] The "always" condition always returns "true" and it should therefore be combined with other conditions using the "and" operator, ensuring that the otherconditions are satisfied according to their specifications. Since "and true" is a redundant expression, the "always" condition can be deleted.