Fawkes for the RoboCup Logistics League

  • Tim NiemuellerEmail author
  • Sebastian Reuter
  • Alexander Ferrein
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 9513)


Autonomous mobile robots comprise a great deal of complexity. They require a plethora of software components for perception, actuation, task-level reasoning, and communication. These components have to be integrated into a coherent and robust system in time for the next RoboCup event. Then, during the competition, the system has to perform stable and reliably. Providing a software framework for teams to use tremendously eases that effort. Even more so when providing a fully integrated system specific for a particular domain.

We have recently released our full software stack for the RoboCup Logistics League (RCLL) based on the Open Source Fawkes Robot Software Framework. This release includes all software components of the RoboCup 2014 winning team Carologistics (in cooperation with the AllemaniACs RoboCup@Home team). It specifically also includes the parts of the software which are domain or platform specific or which we consider our competitive edge and were kept private until now. We think that this will make the league much more accessible to new teams and might help existing teams to improve their performance.

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

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.

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

2 Fawkes Robot Software Framework

At the core of the public release for the RCLL is the Fawkes Robot Software Framework1 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 AllemaniACs2 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 Carologistics3 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, 15, 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.

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

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.4
Fig. 3.

The RCLL 2014 in real and simulation.

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.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.

Behavior layer separation

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.

CLIPS production process rule

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.


  1. 1.
  2. 2.

    Website of the AllemaniACs at

  3. 3.

    Website of the Carologistics at

  4. 4.

    Simulation is available at

  5. 5.



T. Niemueller was supported by the German National Science Foundation (DFG) research unit FOR 1513 on Hybrid Reasoning for Intelligent Systems (

The Carologistics team members in 2014/2015 are: D. Ewert, A. Ferrein, S. Jeschke, N. Limpert, G. Lakemeyer, K. Leonardic, M. Löbach, R. Maaßen, V. Mataré, T. Neumann, T. Niemueller, F. Nolden, S. Reuter, J. Rothe, and F. Zwilling.


  1. 1.
    Niemueller, T., Beck, D., Lakemeyer, G., Ferrein, A.: Design principles of the component-based robot software framework fawkes. In: Ando, N., Balakirsky, S., Hemker, T., Reggiani, M., von Stryk, O. (eds.) SIMPAR 2010. LNCS, vol. 6472, pp. 300–311. Springer, Heidelberg (2010)CrossRefGoogle Scholar
  2. 2.
    Beck, D., Niemueller, T.: AllemaniACs 2009 team description. Technical report, KBSG, RWTH Aachen University (2009)Google Scholar
  3. 3.
    Ferrein, A., Steinbauer, G., McPhillips, G., Niemueller, T., Potgieter, A.: Team ZaDeAt 2009 - team report. Technical report, RWTH Aachen University, Graz University of Technology, and University of Cape Town (2009)Google Scholar
  4. 4.
    Schiffer, S., Lakemeyer, G.: AllemaniACs team description RoboCup@Home. Technical report, KBSG, RWTH Aachen University (2011)Google Scholar
  5. 5.
    Ferrein, A., Niemueller, T., Schiffer, S., G.L.: Lessons learnt from developing the embodied AI platform caesar for domestic service robotics. In: Proceedings of AAAI Spring Symposium, 2013 - Designing Intelligent Robots: Reintegrating AI (2013)Google Scholar
  6. 6.
    Niemueller, T., Ferrein, A., Jeschke, S., Ewert, D., Reuter, S., Lakemeyer, G.: Decisive factors for the success of the carologistics RoboCup team in the RoboCup logistics league 2014. In: Bianchi, R.A.C., Akin, H.L., Ramamoorthy, S., Sugiura, K. (eds.) RoboCup 2014. LNCS, vol. 8992, pp. 155–167. Springer, Heidelberg (2015)CrossRefGoogle Scholar
  7. 7.
    Srinivasa, S.S., Berenson, D., Cakmak, M., Collet, A., Dogar, M.R., Dragan, A.D., Knepper, R.A., Niemueller, T., Strabala, K., Vande Weghe, M., Ziegler, J.: HERB 2.0: lessons learned from developing a mobile manipulator for the home. Proc. IEEE 100(8), 2410–2428 (2012)CrossRefGoogle Scholar
  8. 8.
    Niemueller, T., Abdo, N., Hertle, A., Lakemeyer, G., Burgard, W., Nebel, B.: Towards deliberative active perception using persistent memory. In: Proceedings of the Workshop on AI-based Robotics at the International Conference on Intelligent Robots and Systems (IROS) (2013)Google Scholar
  9. 9.
    Zwilling, F., Niemueller, T., Lakemeyer, G.: Simulation for the RoboCup logistics league with real-world environment agency and multi-level abstraction. In: Bianchi, R.A.C., Akin, H.L., Ramamoorthy, S., Sugiura, K. (eds.) RoboCup 2014. LNCS, vol. 8992, pp. 220–232. Springer, Heidelberg (2015)CrossRefGoogle Scholar
  10. 10.
    Ferrein, A., Lakemeyer, G., Niemüller, T.: A lua-based behavior engine for controlling the humanoid robot nao. In: Baltes, J., Lagoudakis, M.G., Naruse, T., Ghidary, S.S. (eds.) RoboCup 2009. LNCS, vol. 5949, pp. 240–251. Springer, Heidelberg (2010)Google Scholar
  11. 11.
    Niemueller, T., Ewert, D., Reuter, S., Ferrein, A., Jeschke, S., Lakemeyer, G.: RoboCup logistics league sponsored by festo: a competitive factory automation benchmark. In: RoboCup Symposium 2013 (2013)Google Scholar
  12. 12.
    Niemueller, T., Lakemeyer, G., Ferrein, A., Reuter, S., Ewert, D., Jeschke, S., Pensky, D., Karras, U.: Proposal for advancements to the LLSF in 2014 and beyond. In: ICAR - 1st Workshop on Developments in RoboCup Leagues (2013)Google Scholar
  13. 13.
    Gat, E.: Three-layer architectures. In: Artificial Intelligence and Mobile Robots (1998)Google Scholar
  14. 14.
    McIlroy, M.D.: ‘Mass Produced’ Software Components. Software Engineering: Report on a Conference Sponsored by the NATO Science Committee (1968)Google Scholar
  15. 15.
    Brugali, D., Scandurra, P.: Component-based robotic engineering (Part I). IEEE Rob. Autom. Mag. 16(4), 84–96 (2009)CrossRefGoogle Scholar
  16. 16.
    Brugali, D., Shakhimardanov, A.: Component-based robotic engineering (Part II). IEEE Rob. Autom. Mag. 17(1), 100–112 (2012)CrossRefGoogle Scholar
  17. 17.
    Quigley, M., Conley, K., Gerkey, B.P., Faust, J., Foote, T., Leibs, J., Wheeler, R., Ng, A.Y.: ROS: an open-source robot operating system. In: ICRA Workshop on Open Source Software (2009)Google Scholar
  18. 18.
    Ferrein, A., Schiffer, S., Lakemeyer, G., Jacobs, S., Beck, D.: Robust collision avoidance in unknown domestic environments. In: Baltes, J., Lagoudakis, M.G., Naruse, T., Ghidary, S.S. (eds.) RoboCup 2009. LNCS, vol. 5949, pp. 116–127. Springer, Heidelberg (2010)Google Scholar
  19. 19.
    Niemueller, T., Lakemeyer, G., Ferrein, A.: Incremental task-level reasoning in a competitive factory automation scenario. In: Proceedings of AAAI Spring Symposium 2013 - Designing Intelligent Robots: Reintegrating AI (2013)Google Scholar
  20. 20.
    Wygant, R.M.: CLIPS: a powerful development and delivery expert system tool. Comput. Ind. Eng. 17(1–4), 546–549 (1989)CrossRefGoogle Scholar

Copyright information

© Springer International Publishing Switzerland 2015

Open Access This chapter is licensed under the terms of the Creative Commons Attribution-NonCommercial 2.5 International License (, which permits any noncommercial use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Authors and Affiliations

  • Tim Niemueller
    • 1
    Email author
  • Sebastian Reuter
    • 2
  • Alexander Ferrein
    • 3
  1. 1.Knowledge-based Systems GroupRWTH Aachen UniversityAachenGermany
  2. 2.Institute Cluster IMA/ZLW & IfURWTH Aachen UniversityAachenGermany
  3. 3.MASCOR Institute, Aachen University of Applied SciencesAachenGermany

Personalised recommendations