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.
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. |
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 fourteen 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 seven robots are the main players and the last seven 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 (the last two substitutes cannot be selected this way). Commands are executed by clicking the respective button in the tool bar.
Local Commands¶
Command | Description |
---|---|
compile |
Compiles the Nao target with the selected build configuration. |
simulator |
Opens the RemoteRobot.ros2 scene in the simulator. |
Robot Commands¶
Command | Description |
---|---|
delete logs |
Deletes all logs from the robot(s). |
deploy |
Deploys code and all settings to the robot(s). |
download calibration |
Downloads calibration files from the robot(s). |
download logs |
Downloads all logs from the robot(s) and stores them at Config/Logs . |
restart |
Restarts the bhuman service on the robot(s). |
reboot |
Restarts the robot(s). |
shutdown |
Executes a shutdown on the robot(s). |
ssh |
Opens an ssh session on the robot(s). |
Deploying Code to the Robots¶
For the simultaneous deployment of several robots the command deploy
should be used.
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 ninja
, xcodebuild
, or MSBuild
to compile the binaries required.
The deployment itself calls the deploy
script (cf. this section) in parallel for each selected robot. 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.
Substituting Robots¶
The robots that are in use for a particular scenario 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. All other robots are contained in the so-called RobotPool at the right side of the bush
window. 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 log files 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.
-
The configuration file is created by the script
createRobot
described in this section. ↩