Changes in 2023¶
Support for Linux on ARM¶
On the PC, the B-Human system can now also be compiled and used on Linux for ARM, i.e. the architecture
aarch64 is fully supported. Some compromises are made similar to the support for
arm64 on macOS, i.e. our library CompiledNN is replaced by the ONNXruntime and x86 intrinsics are mapped to native instructions by the header-only library
Message queues are B-Human's means to transmit and store sequences of typed data (basically bags). They were reimplemented with a more compact interface, which is now based on iterators rather than message numbers. Some specialized functions were moved to the only places in our code that actually use them to keep the implementation of the message queue compact.
The log player was rewritten as well. Log files mainly consist of a streamed message queue and some additional information. They can be rather big (> 3 gb for a typical half of a game). The new log player opens such a file as a memory mapped file to avoid that the whole log is read into memory all at once. Since our code uses some information that would usually require to read through the entire log to compute it, some indices are created when a log file is first opened and then appended to the log file. When the log file is opened again, the indices are read from the file, instead of recomputing them. Thus, instead of reading more then 3 gb, only less than 2 mb have to be read when opening a log file, which significantly speeds up the process.
Our robotics simulator SimRobot got a graphical overhaul, in particular on macOS (see screenshot in this section). The support for floating windows was removed.
In addition, the library that connects SimRobot to B-Human's robot code was improved in several ways:
Data views allow to display and edit data that is published by the macro
MODIFY in our robot code. The appearance of these views was streamlined and they now only exchange data with the robot code when they are visible. This allowed to change their creation completely. In the past, they had to be manually added using the console command
vd. The command was removed. Instead, views corresponding to all data made available through
MODIFY macros in the code are immediately available under the category
data of a robot in SimRobot's scene graph, grouped by the threads they are defined in. As the hierarchy suggest, the data is now shown per thread, i.e. there are different views available, e.g. for a
BallPercept from the thread
Upper and the one from the thread
Commands per Thread¶
This per-thread handling is now also available for console commands. The prefix command
for allows to specify the threads a certain command is meant for. For instance,
for Upper Lower mr BallPercept BallPerceptor defines that in both the threads
Lower a module called
BallPerceptor should provide a representation named
BallPercept. Under certain conditions that vary between different commands, it is still possible to omit the command prefix
for (see this section).
Message ID Mapping¶
When SimRobot is connected to a real NAO through a network connection, information is exchanged through message queues. While it was already possible to exchange data in the past if SimRobot and the robot code did not have exactly the same version, such a connection was not possible if the number of message ids (i.e. the constants that encode the message types in queues) differed. Now, the number of data message ids is exchanged between SimRobot and the NAO when the connection is established, which allows to map the relevant message ids correctly in most cases.
In the past, B-Human had two different graphical frontends to deploy the code to the robots: On the one hand, a dialog could be displayed after having built for the NAO. It allowed to specify the parameters for the script
deploy that actually copies the data to the robot. On the other hand, the B-Human User Shell (bush) could be used to deploy the code to a whole team of robots. However, the layout of the bush made it difficult to increase the maximum jersey number that could be deployed without making the window overly wide. In addition, the software structure was rather complex. Therefore, a new deploy dialog was developed, which replaces the bush and is integrated as part of the build process for the NAO. It is described in this section.