Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Over the past eight years, we have developed the Fawkes Robot Software Framework [1] as a robust foundation to deal with the challenges of robotics applications in general, and in the context of RoboCup in particular. It has been developed and used in the Middle-Size [2] and Standard Platform [3] soccer leagues, the RoboCup@Home [4, 5] service robot league, and now in the RoboCup Logistics League [6]. The frameworks or parts of it have also been used in other contexts [7, 8].

The Carologistics are the first team in the RCLL to publicly release their software stack. Teams in other leagues have made similar releases before. What makes ours unique is that it provides a complete and ready-to-run package with the full software (and some additions and fixes) that we used in the competition in 2014 – which we won. This in particular includes the complete task-level executive component, that is the strategic decision making and behavior generating software. This component was typically held back or only released in small parts in previous software releases by other teams (for any league).

In the RCLL all teams use the same hardware platform “Robotino” by Festo Didactic. This means that there is no hardware barrier that prevents teams from using the software effectively and quickly. Even more so, with the 3D simulation environment based on Gazebo which we have developed [9] and provide, teams can immediately start using our software system for their own development. We provide extensive documentation and are expanding it continuously.

The public release, documentation and videos are available at https://www.fawkesrobotics.org/p/llsf2014-release.

In the following we will briefly describe the framework, some major components, and our simulation environment in Section 2 with a high-light on the task-level executive in Sect. 3. We conclude in Sect. 4.

Fig. 1.
figure 1

Robots running (parts of) Fawkes which were or are used for the development of the framework and its components.

Full size image

2 Fawkes Robot Software Framework

At the core of the public release for the RCLL is the Fawkes Robot Software FrameworkFootnote 1 which is Open Source software.

Fawkes was initially started in 2006 as an effort to build a capable and faster software platform for a new generation of Mid-Size league robots of the AllemaniACsFootnote 2 RoboCup Team (cf. Fig. 1). It was used for the first time at RoboCup 2007 in Atlanta. Since then it was also used on our domestic service robot Caesar [5] in the RoboCup@Home league winning the RoboCup in 2006 and 2007, placing second in 2008, and winning the German Open 2007 and 2008 [4]. From 2008 to 2010 we participated as team ZaDeAt [3], a joint team from University of Cape Town (ZA), RWTH Aachen University (DE) and Technical University of Graz (AT), in the Standard Platform League. During this time we developed the Lua-based Behavior Engine [10], a component which was ported to ROS in 2010 and used, for example, on HERB at CMU [7]. Since 2012 we participate in the RoboCup Logistics League as the CarologisticsFootnote 3 joint team consisting of the Knowledge-Based Systems Group, the Institute Cluster IMA/ZLW & IfU (both RWTH Aachen University), and the Institute for Mobile Autonomous Systems and Cognitive Robotics (Aachen University of Applied Sciences). In 2014 we won both, the World Champion title and the German Open, including the technical challenges. Fawkes is also used in combination with ROS on a PR2 in a project on hybrid reasoning [8]. The Carologistics have been driving the development of the RCLL with active members in the Technical and Organization Committees. We developed the referee box of the competition [11] and proposed the use of physical processing machines [12].

The overall software structure is designed as a three-layer architecture [13] and follows a component-based paradigm [14–16]. It consists of a deliberative layer for high-level reasoning, a reactive execution layer for breaking down high-level commands and monitoring their execution, and a feedback control layer for hardware access and functional components. The communication between single components – implemented as plugins – is realized by a hybrid blackboard and messaging approach [1]. Fawkes has adapter plugins to integrate it with the ROS [17] ecosystem. On the Carologistics and AllemaniACs robots, we use it for visualization purposes.

Fig. 2.
figure 2

Machine signal detection used in the RCLL 2014. The markings denote the detected lights.

Full size image

Software Components. Fawkes already contains a wide variety of more than 125 software components and more than two dozen software libraries, many of which are used in the RCLL. These cover a wide range of functionalities, from plugins providing infrastructure, over functional components for self-localization and navigation, and perception modules via point clouds, laser range finders, or computer vision, to behavior generating components. In the following we describe some examples with a particular focus on the RCLL. The behavior components are explained in more detail in Sect. 3.

Navigation. Fawkes comes with an implementation of Adaptive Monte Carlo Localization which is an extended port from ROS. In the RCLL, we use a pre-specified map and a laser range finder to determine and track the position of the robot on the field. For locomotion path planning we use a layered structure. A component called navgraph has a graph overlay over the playing field, where nodes specify travel points or points of interest like machines, and edges are passages free from static obstacles. When moving to a specific point the navgraph plugin determines a path on this graph to reach the goal. It then instructs the colli [18], a local path planner and collision avoidance module we have developed. Based on the next (intermediate) goal on the path it plans a collision free path on the grid. It may divert as much as necessary from the global path, sometimes resulting in bypassing whole parts of the planned path, for example if it is blocked by an obstacle like an opponent robot. The navgraph recognizes this and skips the bypassed intermediate nodes.

Perception. Another important component is detection and recognition of the light signal of a machine as shown in Fig. 2. While it might seem like a routine task for computer vision, it is complicated by several factors. Since the lights can be on and off, the brightness of the image varies significantly. Additionally, the field contains green walls in the area of the delivery gates (upper left corner in Fig. 3(a) and (b)). A full search for the light signal in an image therefore results in many false positives and negatives. Thus we use a laser cluster detection of the light signal to reduce the search space.

Simulation. The RCLL game emphasizes research and application of methods for efficient planning, scheduling, and reasoning on the optimal work order of production processes handled by a group of robots. An aspect that distinctly separates this league from others is that the environment itself acts as an agent by posting orders and controlling the machines (environment agency).

Therefore, we have created an open simulation environment [9] to support research and development. There are three core aspects in this context: (1) The simulation should be a turn-key solution with simple interfaces, (2) the world must react as close to the real world as possible, including in particular the machine responses and signals, and (3) various levels of abstraction are desirable depending on the focus of the user, e.g. whether to simulate laser data to run a self-localization component or to simply provide the position.

In recent work [9], we provide such an environment. It is based on the well-known Gazebo simulator addressing these issues: (1) its wide-spread use and open interfaces already adapted to several software frameworks in combination with our models and adapters provide an easy to use solution; (2) we have connected the simulation directly to the referee box, the semi-autonomous game controller of the RCLL, so that it provides precisely the reactions and environment agency of a real-world game; (3) we have implemented multi-level abstraction that allows to run full-system tests including self-localization and perception or to focus on high-level control reducing uncertainties by replacing some lower-level components using simulator ground truth data. This allows to develop an idealized strategy first, and only then increase uncertainty and enforce robustness by failure detection and recovery.Footnote 4

Fig. 3.
figure 3

The RCLL 2014 in real and simulation.

Full size image

We have recently joined effort with the BBUnits team of TU Munich and DLR to generalize the simulation further and establish a simulation sub-league.Footnote 5

The released software package contains all of these components which will reduce the initial development and integration effort especially for new teams.

Framework Interoperability. The ability to interact with other robot software frameworks is essential, as it allows to build on already available packages, and to integrate into an existing system. Fawkes has been used in both contexts, for example with ROS [17]. Several generic integration plugins allow for the exchange of data like point clouds or coordinate transformations. Additionally, there is a ROS node that embeds a Fawkes instance into the ROS ecosystem.

Fawkes has also been integrated with, e.g., reasoning systems by means of a remote middleware access library. This is useful for software components that are not based on a specific framework but which provide independent run-times with, for example, a plugin mechanism to integrate with execution systems.

3 Task-Level Coordination and Execution

Task coordination is performed using an incremental reasoning approach [19]. In the following we describe the behavior components, and the reasoning process from the rules in 2014. For computational and energy efficiency, the behavior components also coordinate activation of the lower level components.

Behavior Components for the RCLL. Tasks that the reasoning component of a robot in RCLL LLSF must fulfill are:

Exploration. Gather information about the machine types by visiting them and reporting on the recognized light signal.

Production. Complete the production chains as often as possible dealing with incomplete knowledge.

Execution Monitoring. Instruct and monitor the reactive mid-level Lua-based Behavior Engine.

Three robots perform these steps cooperatively as a group, that is, they communicate information about their current intentions, acquire exclusive control over resources like machines, and share their beliefs about the current state of the environment. This continuous updating of information suggests an incremental reasoning approach. As facts become known, the robot needs to adjust its plan.

Fig. 4.
figure 4

Behavior layer separation

Full size image

Lua-Based Behavior Engine. In previous work we have developed the Lua-based Behavior Engine (BE) [10]. It mandates a separation of the behavior in three layers, as depicted in Fig. 4: the low-level processing for perception and actuation, a mid-level reactive layer, and a high-level reasoning layer. The layers are combined following an adapted hybrid deliberative-reactive coordination paradigm with the BE serving as the reactive layer to interface between the low- and high-level systems.

The BE implements individual behaviors – called skills – as hybrid state machines (HSM). They can be depicted as a directed graph with nodes representing states for action execution and monitoring. Edges denote jump conditions implemented as Boolean functions. For the active state of a state machine, all outgoing conditions are evaluated, typically at about 15 Hz. If a condition fires, the active state is changed to the target node of the edge. A table of variables holds information like the world model, for example storing numeric values for object positions. It remedies typical problems of state machines like fast growing number of states or variable data passing from one state to another. Skills are implemented using the light-weight, extensible scripting language Lua.

Incremental Reasoning Agent. The problem at hand with its intertwined world model updating and execution naturally lends itself to a representation as a fact base with update rules for triggering behavior for certain beliefs. We have chosen the CLIPS rules engine [20]. Incremental reasoning means that the robot does not create a full-fledged plan at a certain point in time and then executes it. Rather, when idle it commits to the ‘then-best’ action. This avoids costly re-planning (as with approaches using planners), it allows to cope with incomplete knowledge, and it is computationally inexpensive. As soon as the action is completed and based on its knowledge, the next best action is chosen. High priority tasks can also interrupt running tasks. In Fig. 5 we show a simplified rule for the production process. The game is in the production phase, the robot is currently idle and holds a raw material puck \(S_0\) or no puck: (phase PRODUCTION) (state IDLE)(holding NONE|S0). Furthermore there is a T5-machine, with matching team-color, has no produced puck, is not already loaded with an \(S_0\), and no other robot is currently bringing an \(S_0\). If these conditions are satisfied and the rule has the highest priority of currently active rules, the rule fires proposing to load the machine appropriately.

Fig. 5.
figure 5

CLIPS production process rule

Full size image

There is a set of such production rules with their conditions and priorities determining what the robot does in a certain situation, or – in other terms – based on a certain belief about the world in the fact base. This simplifies adding new decision rules. The decisions can be made more granular by adding rules with more restrictive conditions and a higher priority.

After a proposed task was chosen, the coordination rules of the agent cause communication with the other robots to announce the intention and ensure that there are no conflicts. If the coordination rules accept the proposed task, process execution rules perform the steps of the task (e.g. getting an \(S_0\) from the input storage and bringing it to the machine). Here, the agent calls the Behavior Engine to execute the actual skills like driving to the input storage and loading a puck.

4 Conclusion

The integration of a complete robot system even for medium-complex domains such as the RCLL can be tedious and time consuming. We had made the decision early in 2012 when joining the RCLL to go for a more complex, but then also more robust and flexible system. In 2014 this was finally rewarded by winning the RoboCup 2014 RCLL competition.

The public release of a fully working and thoroughly tested integrated software stack lowers the barrier of entry for new teams to the league and fosters research and exchange among members of the RoboCup community in general, and in the RoboCup Logistics League in particular.