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. |
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.
-
The configuration file is created by the script
createRobot
described in this section. ↩