Skip to content

Getting Started

This chapter describes how to use our code on Windows, macOS, and Linux. The code can be built for our simulator and for the actual robot (NAO\(^\mathsf6\) only). We first show how to compile the code before we describe how to setup a NAO robot to be used with our software. If you want to setup a NAO and run our code, you will need access to a NAO operating system image in version (called nao-, which is not publicly available. The RoboCup Standard Platform League Technical Committee can give you access if you already joined the league or plan to do so. Without that special version of the operating system, generating our own image will not work.

All paths mentioned in this description will be relative to the main directory of the working copy.

Targets and Configurations

The B-Human project consists of the main build targets SimRobot, Nao, and Tests (cf. this table). These targets can all be built in three different configurations (cf. this table). The general idea is that Debug contains all debugging support, but is slow, Release sacrifices debugging support for speed, and Develop is a reasonable compromise between the two. The actual selection of features depends on the platform.

The following table lists the top-level build targets of the B-Human system.

Target Description
SimRobot The code is built to run in simulation. The whole build consists of our simulator SimRobot together with its libraries SimRobotCommon, SimRobotCore2, SimRobotCore2D, and SimRobotEditor and the robot control program SimulatedNao.
Nao The code is built to run on the NAO.
Tests Some unit tests. On macOS, this target is available by selecting SimRobot and then switching to Xcode's Tests Navigator.

Effects of the different build configurations are shown in the following table. SimRobot represents everything in the simulation except for SimulatedNao.

without assertions (NDEBUG) debug symbols (compiler flags) debug libs1 (_DEBUG, compiler flags) optimizations (compiler flags) debugging support2
  SimulatedNao ✗/✓ ✗/✓ ✗/✓

In Debug, the code compiled for the robot (target Nao) is actually too slow to be used, i.e. motions will stutter. In Release, that code does not support debugging, which means that SimRobot cannot connect to a robot running it. In Develop, the library SimulatedNao is a mixture of debug and release code. The interface code for the simulator is optimized, while the robot code generally is not. However, some of the robot code would run extremely slow without optimization. Therefore, a few parts are also optimized and cannot be debugged.

Setting up the Development Computer

This section describes which software must be installed on a computer to run the B-Human software. The version numbers of software that we specify are the ones we currently use. That does not mean that newer or older versions will not work, but it is not guaranteed that they will.

  • Microsoft Windows 10 64 bit Version 21H1
  • Microsoft Visual Studio Community 2022 Version 17.0.0. Installing the workload Desktop development with C++ (including the packages MSVC v143 - VS 2022 C++ x64/x86 build tools, Windows 10 SDK 10.0.19041.0, and C++-ATL for latest v143 build tools (x86 & x64)) is sufficient.
  • CMake 3.21.2
    • Use a Windows x64 installer from here. Visual Studio's integrated CMake support does not work.
    • Select the option "Add CMake to the system PATH for all users".
  • Windows Subsystem for Linux (WSL). The required steps change occasionally and also depend on the previous state of the system and whether the WSL is used for other purposes. You should therefore consult Microsoft's documentation whenever you set up WSL for B-Human on a new Windows installation.

    • Ubuntu 22.04 must be selected as default distribution. Currently, Ubuntu 22.04 must be installed via the Microsoft Store.
    • That distrbution should use WSL version 1 due to frequent Windows file system access (see here and here).
    • In that distribution, root must be the default user account. This can be achieved by pressing Ctrl+C when being prompted for a user name during installation of the distribution.
    • Packages need to be installed using the following commands in a Windows Command Prompt:

      wsl apt update
      wsl apt -y install astyle ccache clang cmake llvm mold net-tools ninja-build pigz rsync xxd
  • macOS 12.6 (Intel or ARM)
  • Xcode 14.1
    • Xcode must be executed at least once to accept its license and to install its components.
  • CMake 3.24.2
    • Use a "macOS 10.13 or later" .dmg from here or install a cmake that can be found in the $PATH (e. g. via Homebrew).
  • A 64-bit Linux, e.g. Ubuntu 22.04 LTS
  • The following packages (here for Ubuntu 22.04 LTS):

    sudo apt install ccache clang cmake git graphviz libasound2-dev libbox2d-dev libgl-dev libqt6opengl6-dev libqt6svg6-dev llvm mold net-tools ninja-build pigz qt6-base-dev rsync xxd
  • (optionally) CLion 2019.3 or newer

Setting up the Working Copy

Cloning the Repository

As the B-Human repository uses submodules, it must be cloned using git clone --recursive. Downloading it as zip or tar.gz does not work.

On macOS, the working copy must be either located outside of folders protected by macOS (e.g. Desktop, Documents, Downloads, etc.), or you have to grant full disk access to /bin/bash.3

Creating Project Files / Compiling the Code

Run Make/Windows/generate.cmd and open the solution through the link Make/Windows/B-Human.lnk in Visual Studio. Select the desired configuration (Develop is a good start) and build one of the targets mentioned in this section4.

Run Make/macOS/generate and open the Xcode project Make/macOS/B-Human.xcodeproj. The schemes in the toolbar allow building the targets mentioned in this section in different configurations.

On ARM machines, there is also the option to run Make/macOS/generate -r to generate an Xcode project that will still compile Intel code, which runs via Rosetta 2. A reason for doing so is that our library CompiledNN to efficiently compute neural networks does not work on ARM machines yet. As a replacement, the ONNX runtime is used. It is significantly slower than CompiledNN and requires the neural networks to be present in a second format (i.e. .onnx). Therefore, in some situations it might be more convenient to still use Intel code on ARM machines.

When building for the NAO (always Intel code), running the target will open a dialog to deploy the code to a robot (cf. this section). This will only work if the robot was already set up to work with our software (cf. this section), unless creating an installation image is selected as target.

Support for Xcode

Calling the script Make/macOS/generate also installs various development supports for Xcode:

  • Data formatters. If the respective file does not already exist, a symbolic link is created to formatters that let Xcode’s debugger display summaries of several Eigen datatypes.

  • Source file templates. Xcode’s context menu entry New File... contains a category B-Human that allows to create some B-Human-specific source files.

  • Code snippets. Many code snippets are available that allow adding standard constructs following B-Human’s coding style as well as some of B-Human’s macros.

  • Source code formatter. A system text service for formatting the currently selected text is available in the menu Xcode→Services→AStyle for B-Human.

B-Human uses UTF-8, no trailing whitespace, no tabulator characters, and an indentation width of 2:

  • Activate Xcode|Preferences|Text Editing|Editing|Automatically trim trailing whitespace
  • Activate Xcode|Preferences|Text Editing|Editing|Including whitespace-only lines
  • Xcode|Preferences|Text Editing|Editing|Default text encoding|Unicode (UTF-8)
  • Xcode|Preferences|Text Editing|Indentation|Prefer indent using|Spaces
  • Xcode|Preferences|Text Editing|Indentation|Indent width|2
  • Xcode|Preferences|Text Editing|Indentation|Re-Indent on paste must be disabled if the service AStyle for B-Human is used.
  • Activate Edit|Format|Spelling and Grammar|Check Spelling While Typing

Run Make/Linux/generate to generate CMake caches.

Run Make/Linux/compile [<configuration>] [<target>] to compile the code (using a configuration and target from this section, Develop is the default configuration).

Run Make/Linux/generate -c to generate CLion project files.

Open Make/Linux/CMakeLists.txt in CLion as project (not the one in Make/CMake). Targets and configurations are preconfigured and can be selected in the run manager.

Setting Up the Git Hooks (Optional)

For contributing members of the B-Human team, it is recommended to use the provided hooks as part of their Git workflow.

Make/Hooks/installHooks[.cmd] can be used to install Git hooks that will automatically call the script Make/$<$os/ide$>$/generate after most Git operations to update the project files.

Additionally, the B-Human project offers pre-commit hooks that require a Python 3 installation. These scripts can run automatically before every commit to the repository to detect and fix some incorrect code formatting.

Run pip install pre-commit to install the framework for pre-commit hooks.

Run pre-commit install --install-hooks inside the root folder of the B-Human repository to install the Git hook scripts.

Setting Up the NAO

In the Standard Platform League, each team is assigned a unique team number. This number is used to identify the team in the GameController application, but it is also used to avoid conflicts in IP addresses and UDP ports. In the B-Human system, the team number must be entered into the file Config/settings.cfg.

IP Configuration

All NAOs will be set up to use specific subnet addresses for wired and wireless communication. The default values are configured in Install/createRobot and are 192.168.<team>.<robot> for wired and 10.0.<team>.<robot> for wireless communication (usually the setup used at RoboCup events). You have to edit this file if you want to use different subnets before you create configurations for individual robots.

The IP addresses that unknown robots (i.e. robots that are not created ahead of time using createRobot, e.g. at a remote event) get are set in Install/createHomeArchive. The code release does not support multiple unknown robots to be deployed with different IP addresses.

Wireless Network Configuration

Wireless configurations are stored in Install/Profiles as snippets of a netplan configuration file within the access-points mapping (see here). The profile that is active after the first boot can be set using the -w option of the deploy script when creating the image. The special empty profile NONE will turn off wireless. Other profiles can be selected later, when deploying the software to the robot. The profiles will not only be copied to the NAO during its initial setup, but also be updated while deploying our software, i.e. the contents of the directory can be changed later.

Creating a Robot Configuration

Only once for each NAO and while being connected to that NAO, run

Install/createRobot [-t <team>] -r <robot> -i <ip> <name>

The NAO must be running the original Aldebaran operating system (nao- for this. <team> is your team’s number (the third number of the robot’s target IP address). If omitted, the team number from the file Config/settings.cfg is used. <robot> is the number of the robot (the fourth number of its target IP address). <ip> is its current IP address. <name> is the name you will use to refer to the NAO in the future (it must be a valid host and directory name). The script will create files in Config/Robots/<name> and update some existing configuration files.

If the NAO is already running a different operating system or a network connection is not possible, the alternative form

Install/createRobot [-t <team>] -r <robot> -s <head> -b <body> <name>

can be used, where <head> and <body> body are the serial numbers of the head and body, respectively (20-character-strings starting with P).

Creating a Root Image

In order to run the B-Human software on a robot, it must be flashed with a B-Human-specific operating system image. This image contains two parts: An .ext3 image of the root file system that contains the basic operating system and a tar.gz archive that is extracted on the /home partition. While the latter is automatically created as part of the deploy script with the -i option (cf. this section), the former must be done manually. It only needs to be done once (or whenever some of the included files change or you want to install different packages) and you can redistribute the resulting image among your team members. The process only works on Ubuntu for x86_64 and requires the original Aldebaran operating system image (nao- and the following additional packages:

sudo apt install bzip2 debootstrap patchelf

The following command creates the root image, which will download a lot of packages and can take a few minutes:

sudo Install/createRootImage <path to original Aldebaran OPN>

This results in the file Install/root.ext3.

Flashing the Robot

Using the root image created above, each robot must be flashed with an operating system image before it can be used. See the description of the -i option in the next section.

Deploying the Software

Deploying the software to a NAO means copying the directory Config (without the subdirectories Images, Logs, and Scenes) together with the executable bhuman to /home/nao/Config on the robot. In addition, the network profiles in Install/Profiles are copied to /home/nao/Profiles. The latter does not automatically update the current network profile.

The software is deployed by executing the script Make/Common/deploy that is also linked from some other subdirectories under Make:

usage: deploy [Release|Develop|Debug] [<ipaddress>|(-r <playernumber> <ipaddress>)*] {options}
    -b                       restart bhuman
    -c <field player color>  set field player color to blue, red, yellow, black, white, orange, purple, brown, or gray
    -d                       delete logs or add timestamp to image
    -g <goalkeeper color>    set goalkeeper color to blue, red, yellow, black, white, orange, purple, brown, or gray
    -h | --help | /h | /?    print this text
    -i                       create image instead of deploying
    -k                       keep ip address for remote connection
    -l <location>            set location
    -m <magic number>        set magic number for teamcomm (0-255). Set -1 for random.
    -nc                      never compile
    -nr                      do not check whether target is reachable
    -p <player number>       set player number
    -r <n> <ip>              copy to <ip> and set playernumber to <n> (one -r per robot)
    -s <scenario>            set scenario
    -t <team number>         set team number
    -u                       check for a USB drive before starting bhuman (only when creating an image)
    -v <volume percent>      set NAO's volume
    -w <wireless profile>    set wireless profile
    ./deploy Develop -p 1
    ./deploy Release -r 1 -r 3
    ./deploy Release -i -nc -v 50 -w SPL_A

Without the option -nc, deploy will build the code before deploying it.

With the option -i, an installation image (.opn) is created instead of copying the software to an actual robot. In that case, no IP address has to be specified. The image will be stored in the directory Build/Image/<configuration>/ and can be used to install the robot following these instructions. Before flashing the image for the first time, the NAO must have run the original Aldebaran image nao-, as otherwise the firmware of the embedded boards may not be compatible.

The standard method for deploying our software to the NAO is the Deploy Dialog (see this chapter). It is a graphical frontend for deploy with a lot of additional functionality.

Working with the NAO

After pressing the chest button to turn on the NAO, it takes about 25 seconds until our software runs. It is important not to move the NAO while it is booting up, because it calibrates its gyroscopes during this time. Our software will give an acoustic alarm if the gyroscope was not calibrated correctly. In that case, the robot has to be rebooted.

To connect to the NAO, the subdirectories of Make contain a login script for each supported platform. The only parameter of that script is the IP address of the robot to login. It automatically uses the appropriate SSH key to login. In addition, the IP address specified is written to the file Config/Scenes/Includes/connect.con if the option -k is specified. Thus a later use of the SimRobot scene RemoteRobot.ros2 will automatically connect to the same robot.

There are several scripts to start and stop bhuman via SSH. Those scripts are copied to the NAO upon installing the B-Human software.

  • bhuman executes the bhuman executable in the foreground. It handles selection of the logging device and redirecting output to a logfile. Press Ctrl+C to terminate the process. Please note that the process will automatically be terminated if the SSH connection is closed. bhuman -d starts a gdb session for the bhuman executable. bhuman -b option disables output to the console and is used by the bhuman systemd service.

  • setprofile changes the wireless profile.

  • setvolume changes the sound volume.

Other relevant commands are:

  • systemctl --user start|stop|restart bhuman.service starts, stops, or restarts the bhuman executable as a background service. The script Make/Common/deploy always stops bhuman before deploying. If deploy is started with the option -b, it will restart bhuman after all files were copied.

  • sudo systemctl poweroff shuts down the NAO. If bhuman is running, this can also be done by pressing the chest button longer than three seconds (until the robot's eyes turn blue or it starts to sit down).

  • sudo systemctl reboot reboots the NAO.

Working with SimRobot

On Windows and macOS, SimRobot can either be started from the development environment or by starting a scene description file in Config/Scenes5. In the first case, a scene description file has to be opened manually, whereas it will already be loaded in the latter case. On Linux, just run Build/SimRobot/Linux/<configuration>/SimRobot, either from the shell or from a file browser, and load a scene description file afterwards. When a simulation is opened for the first time, only the scene graph is displayed. The simulation is already running, which can be noted from the increasing number of simulation steps shown in the status bar. A scene view showing the soccer field can be opened by double-clicking RoboCup. The view can be adjusted by using the context menu of the window or the toolbar. Double-clicking Console will open a window that shows the output of the robot code and that allows entering commands (cf. this section). All windows can be docked in the main window.

After starting a simulation, a script file is automatically executed if it exists, setting up the robot(s) as desired. The name of the script file is the same as the name of the scene description file but with the extension .con. Together with the ability of SimRobot to store the window layout, the software can be configured to always start with a setup suitable for a certain task.

Although any object in the scene graph can be opened, only displaying certain entries in the object tree makes sense, namely the main scene RoboCup, the objects in the group RoboCup/robots, and all other views, which can be found under the tree roots that are marked with the B-Human logo.

To connect to a real NAO, open the scene Config/Scenes/RemoteRobot.ros2. A prompt will appear to enter the NAO’s IP address.6 In a remote connection, the simulation scene contains a robot which mirrors the joint positions of the connected real robot, but otherwise experiences the dynamics of the simulation. All the other views work as usual.

Directory Structure

Main Directories

Directory Contents
Build All files created during builds are located in this directory. The directory structure follows the pattern Build/<os>/<target>/<configuration>. Deleting the directory will remove all build files. The directory initially does not exist.
Config All configuration files are located in this directory. Some of the subdirectories are described in this section. Config/Scenes contains the simulation scenes (.ros2) together with the console scripts that are executed when the simulation is started (.con)
Install Scripts and other files for setting up the NAO robot.
Make Scripts and project files for software development. Make/<os/ide> contains project files for a specific IDE or build system. Make/Common contains the shared part of the build system. It also contains scripts for deploying the code and downloading log files that are used by other tools.
Src All source files of the B-Human system.
Util 3rd-party code that is not part of the B-Human system.

Configuration File Search Path

All configuration files are searched along a path that contains directories that can depend on the name of a robot (separately for head and body, so mixing those is possible), the location where the robot is used (e.g. outdoor field vs. indoor field), and the scenario in which it is used (e.g. normal game vs. technical challenge):

  • Config/Robots/<head name>/Head
  • Config/Robots/<body name>/Body
  • Config/Robots/<head name>/<body name>
  • Config/Locations/<location>
  • Config/Scenarios/<scenario>
  • Config/Robots/Default
  • Config/Locations/Default
  • Config/Scenarios/Default
  • Config

In simulation, the name of both head and body is Nao. The current location and scenario are defined in the file Config/settings.cfg. They can also be changed while deploying the code to an actual NAO (cf. this section). Simulated robots will use the Default location and scenario unless they are changed in the scene description file (cf. this section).

  1. On Windows, see this website 

  2. See this chapter 

  3. This is only relevant for the deploy dialog, which cannot be run directly from Xcode otherwise. 

  4. Instead of Nao, you can also build Utils/deploy, which allows to directly deploy the code to a NAO robot, if it is already set up for deploying our software. 

  5. On Windows, the first time starting such a file the SimRobot.exe must be manually chosen to open these files. Note that both on Windows and macOS, starting a scene description file bears the risk of executing a different version of SimRobot than the one that was just compiled. 

  6. The script might instead automatically connect to the IP address that was last used for login or deployment. 

Last update: September 20, 2023