IRIDIA - Supplementary Information (ISSN: 2684-2041)

Supplementary material for the paper:

AutoMoDe-Cedrata: Automatic design of behavior trees for controlling a swarm of robots with communication capabilities

Jonas Kuckling, Vincent van Pelt, and Mauro Birattari (July 2021)


Table of Contents
  1. Code availability
  2. Statistical data
  3. Typical designs
  4. Extended results

Code availability

AutoMoDe and its dependencies can be installed from its GitHub repository
The DEAP library and PonyGE2 are also available on GitHub.
The ARGoS3 mission files and the parameter files for DEAP and PonyGE2 can be downloaded here.

.

Statistical data

All data is available to download from here.

Typical Designs of Cedrata

Foraging

This is an example of a typical tree generated by Cedrata for the mission Foraging. The left figure shows a representation of the behavior tree. On the right is a run of that behavior tree on a swarm of 20 e-puck robots in simulation.

Marker Aggregation

This is an example of a typical communication-less tree generated by Cedrata for the mission Marker Aggregation. The left figure shows a representation of the behavior tree. On the right is a run of that behavior tree on a swarm of 20 e-puck robots in simulation.

This is an example of a typical communication-based tree generated by Cedrata for the mission Marker Aggregation. The left figure shows a representation of the behavior tree. On the right is a run of that behavior tree on a swarm of 20 e-puck robots in simulation.

Stop

This is an example of a typical tree generated by Cedrata for the mission Stop. The left figure shows a representation of the behavior tree. On the right is a run of that behavior tree on a swarm of 20 e-puck robots in simulation.

Extended results

In [1], we have presented an automatic modular design method Cedrata and two variants, Cedrata-GP and Cedrata-GE. We tested the design methods on two missions and compared them against manual designs within the same constraints.
We performed additional experiments with AutoMoDe-Maple [2] another automatic modular design approach that automatically produces behavior trees. These experiments were done in the two missions described in [1] and a third mission. Maple uses a different reference model (RM1.1) than Cedrata, however. The main differences between the two reference models are that RM1.1 provides access to sensor readings of the ambient light, but not to explicit communication. These differences imply that a comparison of performances is not meaningful as the two design methods target robotic platforms with different capabilities. Nevertheless, these additional experiments with Cedrata and Maple allowed us to gain additional insights.

Foraging

In the mission Foraging, the robots are tasked to perform an abstracted foraging task. That is, the the robots must bring as many items from the black sources inside the white nest. As the e-puck robot does not have gripping capabilities, we assume it picks up an item when it enters a black area and that it deposits a carried item when it enters the white area. In order to help the robots navigate the enviromnent a light source is placed behind the nest, outside of the arena. The objective function for this mission is the number of recovered items: FFor = #items.
This mission has been conceived for robots with capabilities according the reference model RM1.1. Maple, as well as other design methods using RM1.1, have shown in the past to solve this mission satisfactorily. Cedrata, on the other hand, is using RM2.2, which for example does not provide any information about the ambient light. This makes the mission Foraging significantly harder, as the robots cannot use the light to navigate the arena. We believe that there is a possibility, that Cedrata could make use of its communication capabilities to mitigate this disadvantage.

The above figure shows the performance of all considered design methods in the mission Foraging. As expected, Maple generates control software that makes use of the light in the arena to navigate between the food sources and the nest. All design methods based on Cedrata, are using strategies based on randomly exploring the arena. Prior research had already shown that the Exploration module was a relatively adequate solution for the mission Foraging. Furthermore, neither the automatic design processes nor the manual designers were able to conceive a behavior tree making use of the communication module to outperform the simple Exploration-based behavior. This is an indicator that our hypothesis, that communication might offset the disadvantage of not having access to the light, was wrong.

Marker Aggregation

The mission Marker Aggregation is described formally in [1]. In short, the robots must aggregate inside of an area that is imperceivable to the robots, save for a black spot at the center of the aggregation zone. Unlike Foraging, this mission has been conceived for the RM2.2. We predict that in order to perform satisfactorily in this mission, the robots will need to make us of the communication strategy. This means that Maple will be at a disadvantage in this mission as it has no communication capabilities at its disposal.

The above figure shows the performance of all considered design methods in the mission Marker Aggregation. As described in [1], Cedrata produces a mix of strategies that are either communication-based or without communication. As expected, the communication-based strategies perform better than those without communication. Cedrata-GP and Cedrata-GE, however, only produce behavior trees that do not make use of the communication modules. Their strategies often rely only on the Meeting or Grouping behavior to aggregate quickly, regardless wether this is in the target area. Maple on the other hand generates behavior trees that explore the arena until they find the black spot at which point they try to vacate the spot before stopping. The performance of Maple shows that not having access to communication is clearly a hindrance in a mission where the ideal strategy requires communication. Furthermore, the solutions found by Maple are containing more effective modules than the non-communicating solutions generated by Cedrata, Cedrata-GP and Cedrata-GE. There are two possible explanations for this observation. It could be that the more restricted architecture of Maple enables the design process to design sequential behaviors more easily than the less restricted architecture of Cedrata. The design process of Cedrata and its variants could therefore prematurely converge on the simpler to discover strategies that only use one behavior effectively. Alternatively, it could be that the implementation and parameters of genetic programming and grammatical evolution that we used, favors solutions that perform well under certain circumstances, at the expense of robustness to different starting positions. Thus, behavior trees that can quickly aggregate if all or most of the robots are close to the target area are favored over solutions that might reliable bring all robots within the target area, but that require more time to do so.

Stop

The mission Stop is described formally in [1]. In short, the robots must explore the arena until they find the white stop, afterwards they must stop as quickly as possible. This mission has been originally conceived for the RM2.1, another reference model that allowed communication [3]. In order to perform satisfactorily in this mission, the robots must make us of communication. This means that Maple will also be at a disadvantage in this mission as it has no communication capabilities at its disposal.

The above figure shows the performance of all considered design methods in the mission Stop. Cedrata produces control software centered around the Isolation behavior (see the typical behavior tree further up). Cedrata-GP and Cedrata-GE discover similar strategies. Maple discovers a strategy where the robots explore the arena and stop when they perceive enough neighbors. Surprisingly, this strategy performs better than the strategy discovered by Cedrata, Cedrata-GP and Cedrata-GE, although all three design methods could have been able to discover the same strategy as they have access to the same modules: Exploration, Neighborhood Count and Stop. This might be a further sign that Cedrata, Cedrata-GP and Cedrata-GE prematurely converge to a too simplistic solution.

Bibliography

[1] Jonas Kuckling, Vincent van Pelt, and Mauro Birattari. Automode-Cedrata: Automatic design of behavior trees for controlling a swarm of robots with communication capabilities. SN Computer Science, 2021.
[2] Antoine Ligot, Jonas Kuckling, Darko Bozhinoski, and Mauro Birattari. Automatic modular design of robot swarms using behavior trees as a control architecture. PeerJ Computer Science, 6:e314, 2020.
[3] Ken Hasselmann and Mauro Birattari. Modular automatic design of collective behaviors for robots endowed with local communication capabilities. PeerJ Computer Science, 6:e291, 2020.