Skip to content

B-Human User Shell

The B-Human User Shell (bush) accelerates and simplifies the deployment of code and the configuration of the robots. It is especially useful when controlling several robots at the same time, e.g., during the preparation for a soccer match.

An example screenshot of the bush

Configuration

Since the bush can be used to communicate with the robots without much help from the user, it needs some information about the robots. Therefore, each robot has a configuration file Config/Robots/<RobotName>/network.cfg which defines the name of the robot and how it can be reached by the bush.1 In addition, you have to define one (or more) teams, which are arranged in tabs. The data of the teams is used to define the other properties, which are required to deploy code in the correct configuration to the robots. The default configuration file of the teams is Config/teams.cfg which can be edited within the bush or with a text editor. Each team can have the configuration variables shown in this table:

Entry Description
name The name of the team.
number The team number.
port The port which is used for team communication messages.
color The team color.
scenario The scenario used when accessing configuration files (cf. this section).
location The location used when accessing configuration files (cf. this section).
compile Should the code be compiled before it is deployed?
buildConfig The name of the build configuration which should be deployed to the robot (cf. this section).
wlanConfig The name of the wireless profile (cf. this section). Can be NONE to turn off the wireless.
volume The audio playback volume to which the robots should be set to.
deployDevice The device which should be used to connect to the robots. Either an Ethernet or a Wi-Fi connection can be established. The default entry is auto. This chooses the best device, depending on ping times.
magicNumber The magic number for the team communication. Robots with different numbers will ignore each others messages. The special value -1 will set the last component of the deployer's IP address as magic number.
players The list of robots the team consists of. The list must have twelve entries, where each entry must either be a name of a robot (with an existing file Config/Robots/<RobotName>/network.cfg), or an underscore for empty slots. The first six robots are the main players and the last six their substitutes.

Commands

The bush supports two types of commands. There are local commands (cf. this section) and commands that interact with selected robot(s) (cf. this section). Robots can be selected by checking their checkbox or with the keys F1 to F12.

Local Commands

Command Parameter(s)
Description
compile [ <config> [ <project> ] ]
Compile a project with a specified build configuration. The default is to build the project Nao in the configuration Develop.
exit
Exit the bush.
help
Print a help text with all commands.
sim
Open the RemoteRobot.ros2 scene in the simulator.

Robot Commands

Command Parameter(s)
Description
deploy [ <config> ]
Deploys code and all settings to the robot(s) using the script deploy.
downloadLogs
Downloads all logs from the robot(s) and stores them at Config/Logs.
deleteLogs
Deletes all logs from the robot(s).
restart [ bhuman | robot ]
Restarts bhuman or the robot. If no parameter is given, bhuman will be restarted.
scp @<path on NAO> <local path> | <local path> <path on NAO>
Copies a file to or from the robot(s). The first argument is the source and the second the destination path.
show <config file>
Prints the configuration file stored on the robot(s).
shutdown
Executes a shutdown on the robot(s).
ssh [ <command> ]
Executes a command via ssh or opens an ssh session.

Deploying Code to the Robots

For the simultaneous deployment of several robots the command deploy should be used. It accepts a single optional parameter that designates the build configuration of the code to be deployed to the selected robots. If the parameter is omitted the default build configuration of the currently selected team is used. It can be changed with the drop-down menu at the top of the bush user interface.

If the Build checkbox is set, the deploy command checks whether the binaries are up-to-date before it copies code to the robots. If needed, they are recompiled by the compile command, which can also be called independently from the deploy command. Depending on the platform, the compile command uses cmake, xcodebuild, or MSBuild to compile the binaries required.

The deployment itself uses the deploy script (cf. this section). This will stop the bhuman software before copying all necessary files. On all selected robots in the first row, bhuman is started again after the deployment. Furthermore, the bhuman software can be restarted manually using the restart command. This command can also reboot robots when called with the robot parameter. To inspect the configuration files copied to the robots, you can use the command show, which knows most of the files located on the robots and can help with finding the desired files with tab completion.

Substituting Robots

The robots known to the bush are arranged in two rows. The entries in the upper row represent the playing robots and the entries in the lower row the robots which stand by as substitutes. To select which robots are playing and which are not, you can move them by drag&drop to the appropriate position. Since this view only supports twelve robots at a time, there is another view called RobotPool at the right side of the bush window which contains all other robots. The robots displayed there can be exchanged with robots from the main view. If a robot from the lower row is deployed, bhuman will be shut down. This is important because the robots should be operational to be replaced as fast as possible, but are not allowed to send and receive network packets. It is important to note that after rebooting the robot, bhuman will run again.

Monitoring Robots

The bush displays some information about the robots' states as can be seen in this image: wireless connection ping time, wired connection ping time, battery status, and number of logfiles stored on the robot. The color of the power status bar indicates whether the battery is charging: A green bar indicates that the battery is connected to a power supply while a red bar means that the battery is not charging.


  1. The configuration file is created by the script createRobot described in this section