Skip to content

Setting Up the Robot

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 robots 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 robot 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-2.8.5.11_ROBOCUP_ONLY_with_root.opn) 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).

Only once for each Booster T1 or K1, run

Install/createRobot [-t <team>] -r <robot> -m <model> <name>

<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). <model> is either t1 or k1. <name> is the name you will use to refer to the Booster robot 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.

Setting Up the Robot

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-2.8.5.11_ROBOCUP_ONLY_with_root.opn) 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-<year>-<month>-<day>.ext3. The actual name must be patched into the assignment of rootImage in Install/createOPN and committed (while making the generated image available), so that all team members use the same version of the image.

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.

Booster robots are set up using a script while the PC is connected to that robot through an ethernet connection. The script assumes that the robot will have the ip addresses 192.168.10.102 (T1 and K1) as well as 192.168.10.101 (T1 only). To set up the robot, run

Install/installBooster <name>

<name> is the name that was assigned to the robot when running createRobot. After the script is finished, the robot has to be rebooted once. Please refer to Install/BoosterFiles/install to see which changes are made on the robot. Please note that the installation is experimental, in particular because the existing installations seem to differ between different Booster robots.

Deploying the Software

Deploying the software to a robot means copying the directory Config (without the subdirectories Images, Logs, and Scenes) together with the executable bhuman to /home/<model>/Config on the robot (<model> is either nao or booster). In addition, the network profiles in Install/Profiles are copied to /home/<model>/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}
  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 robot's volume
    -w <wireless profile>    set wireless profile
  examples:
    ./deploy Develop 192.168.5.14 -p 1
    ./deploy Release -r 1 10.0.5.14 -r 3 10.0.0.2
    ./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-2.8.5.11_ROBOCUP_ONLY_with_root.opn, as otherwise the firmware of the embedded boards may not be compatible.

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

Working with the Robot

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.

After pressing the power button to turn on the robot, it takes up to two minutes until our software runs. The robot will say "waiting for high-level services" while waiting for the first high-level call to succeed, "waiting for low-level services" while waiting for the first sensor data to arrive. If everything booted correctly, the robot will say "body ready".

When the emergency stop on the T1 or F1 on the K1 is pressed, the robot will unstiff for the T1 or return into the damping mode for the K1. Additionally the word "emergency" is said to confirm this switch. The same button can be pressed again to return the robot into the normal unstiff state called PlayDead, which takes a few seconds and is confirmed by a "body ready" message.

Connect to the Robot via Console

To connect to the robot, the directory Make/Common contains a login script. 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. Thus a later use of the SimRobot scene RemoteRobot.ros2 (T1/BoosterRemote.ros or K1/BoosterRemote.ros2 for a Booster robot, respectively) 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.

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

Connect the robot via SimRobot

To connect to a real robot, open the scene Config/Scenes/RemoteRobot.ros2, Config/Scenes/T1/BoosterRemote.ros2, or Config/Scenes/K1/BoosterRemote.ros2 in SimRobot, depending on the robot model. A prompt will appear to enter the robot’s IP address.1 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.

Final words

Congratulations, you are now able to execute our software both on your computer and on the robot. Now it is time to experiment and create your own code. To learn more about the existing code, refer to the corresponding pages in this documentation!

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

Last update: October 15, 2025