Skip to content

Architecture

The B-Human architecture1 is based on the framework of the GermanTeam 20072, first adapted to the Aldebaran NAO and now to the Booster robots. This chapter summarizes the major features of the architecture: binding, threads, modules and representations, communication, and debugging support.

Binding

On the robot, the B-Human software includes a single binary and several configuration files in /home/booster/Config. When launched, the program typically forks: the parent acts as a watchdog while the child runs the main robot control program. Both share a memory block for execution traces. If the main robot control program fails, the watchdog shifts the robot to the damping mode and saves the trace. The watchdog also manages mode changes overall. On the Booster K1, it responds to F1 button presses to toggle between damping mode and custom mode (see this section). Only the watchdog handles mode shifts; the main robot control program does not. On the T1, it monitors the robot's status and switches states similarly. Consequently, pressing F1 on the K1 can counter software issues in the main robot control program, much like the T1’s emergency switch.

The watchdog starts the child process right away and waits for the robot to provide the low state, meaning sensor readings. Once received, it attempts a switch to custom mode to verify that Booster’s software has launched. If successful, it returns to damping mode. This sequence supports starting B-Human during boot while other components still load. If the link fails immediately, the robot reports “Waiting for robot body.” If no link appears within one minute, it announces “Failed to connect to robot body. Terminating.” and ends the program. After connection, the watchdog signals the child process to begin the main robot control program.

In the main robot control program, the module BoosterProvider exchanges data with the robot through Booster's SDK. In addition, it observes the current mode to know whether it is currently in control or not, i.e. whether the system is in emergency mode.

The BoosterProvider uses blocking communication, i.e. the whole thread Motion (cf. this section) waits until a packet from the robot is received before it continues. However if it does not receive new data within 50 ms, it will consider this to be an emergency mode as well.

Threads

Most robot control programs rely on concurrent processes and threads, but we use only threads to maintain a single shared memory context. The number of parallel threads aligns with external demands from the robot or its operating system. The robot delivers camera images at 60 Hz and receives joint angle commands at 500 Hz. We also record audio from the robot’s microphones, where the frame rate varies with the sampling rate and the volume of data gathered before processing. A separate thread integrates the results from these three threads to handle world modeling and behavior control. Finally, another thread manages TCP communication with a host PC for debugging.

The threads used on the robot The B-Human system relies on five threads: Color, Motion, Audio, Cognition, and Debug. The Color thread gathers camera images from the X5 camera and receives world-model data from Cognition alongside sensor input from Motion. After processing images, it sends detection results to Cognition, which combines them with Motion sensor data for world modeling and behavior control before issuing high-level commands to Motion. That thread carries out these instructions by setting targets for the 22 joints of the Booster K1 or the 23 joints of the Booster T1. It also collects sensor readings such as joint angles, body acceleration, and gyro measurements, while reporting motion details such as dead reckoning. The Audio thread handles whistle detection when the game state demands it and returns results to Cognition. The Debug thread exchanges data with the host PC, distributing incoming information to other threads and forwarding their output back; it remains inactive during actual games.

  1. Thomas Röfer and Tim Laue. On B-Human's code releases in the Standard Platform League – software architecture and impact. In Sven Behnke, Manuela Veloso, Arnoud Visser, and Rong Xiong, editors, RoboCup 2013: Robot World Cup XVII, volume 8371 of Lecture Notes in Artificial Intelligence, pages 648–656. Springer, 2014. ↩

  2. Thomas Röfer, Jörg Brose, Daniel Göhring, Matthias Jüngel, Tim Laue, and Max Risler. GermanTeam 2007. In Ubbo Visser, Fernando Ribeiro, Takeshi Ohashi, and Frank Dellaert, editors, RoboCup 2007: Robot Soccer World Cup XI Preproceedings, Atlanta, GA, USA, 2007. RoboCup Federation. ↩