2024¶

Getting Started¶

macOS¶

Make/macOS/generate now creates Xcode projects with reproducible GUIDs. The tool Util/SimRobot/Make/macOS/pbxgen replaces the random GUIDs created by cmake by ones derived from the project structure. As a result, Xcode does not create a new set of precompiled headers anymore whenever the project file was regenerated. In addition, Make/macOS/generate is much faster now.

Architecture¶

Team Communication¶

We improved our communication and decision-making to determine when robots should send packages to their temmates. Previously, once our budget limit implementation allowed for one message to be send, all robots would be able to send. This caused a deficit of up to six messages and therefore for no more messages to be send for the next 6 seconds. This caused a lot of problems with multiple robots wanting to play the ball and not being capable to resolve this situation for a long period of time. We added a restriction to prioritize sending messages from robots playing the ball. In addition, a delay for robots further away from the ball is now included. With those adjustments, we do not overshoot our own budget anymore and allow for a smoother communication.

Perception¶

Ball and Penalty Mark Perceptor¶

We combined the ball perceptor network and the penalty mark classifier network to a unified model (see this section).

CNN-based Goal Posts Detection¶

We developed a method that finds candidate regions for goal posts and then uses a convolutional neural network to either confirm or reject those candidates (see this section).

Improved Line Intersection Classification¶

The classification of intersections of field lines was split into two modules and the classification network was retrained. In addition to our previous approach, the network now gets the distance to the intersection candidates as an additional input (see this section).

Modeling¶

Whistle Detection¶

B-Human's WhistleRecognizer was replaced by the WhistleDetector developed by the Nao Devils. We adapted their module to our code base and modified it to better work with our team-wide acceptance of the whistle. We also added a minimum confidence required for both individual detection methods (physical model and neural network) to accept a whistle.

Behavior Control¶

CABSL 2¶

The per-robot behavior control (SkillBehaviorControl) consists of high-level actions and skills. Before 2024, the high-level actions were implemented as so-called options in the C-based Agent Behavior Specification Language (CABSL). Skills were written in a specialized skill framework, either as plain C++ code or also as CABSL options. This is now consolidated into a new version of CABSL, implementing everything as options. In comparison to CABSL 1, CABSL 2 adds the ability to split the behavior into multiple compilation units, it uses a different syntax for passing arguments, and it adds constant definitions as well as state variables. The standalone version of CABSL 2 is described here. However, the version integrated into the B-Human framework differs in a few aspects from the standalone version:

Rather than using the iostream framework from the C++ standard library for streaming arguments and reading configuration files, the B-Human streaming framework is used.
In addition to referring to options by their names as strings, the B-Human version also creates an enumeration type Option within the behavior. It overloads methods such as execute and select_option to also accept this type.
Per-option definitions can be read and changed using the modify mechanism.
The SkillBehaviorControl is a module and its options inherit all representations that it requires and they can set all representations that it provides.

Handling the Standby State¶

For detecting the referee signal in the Standby state, we use the same approach as last year (see this section), but we extract a smaller patch from the top of the upper camera image. The patch is smaller, because the referee appears a lot smaller in the image if robots have to look at him/her from the opposing touchline. The robots look at the assumed position of the referee in a way that he/she should appear in the upper part of the upper camera image to minimize blooming effects from the ceiling lights.

As misdetections cannot be out-ruled, a single robot starts to enter the pitch after the signal was detected, giving the referee enough time to penalize that robot before the rest of the team walks in, which it would not if the pawn sacrifice is penalized. The robot walks in from the side where the referee stands, which means that even if it were removed, the same number of robots can still look at the referee afterwards. There is a maximum of two pawn sacrifices before the robots just wait for the GameController to announce the Ready state.

If the team missed the referee signal and receives the delayed Ready signal from the GameController, the robots enter the pitch with maximum speed. Most of them will still reach their kick-off positions within the time window of 15 seconds.

Indirect Kick¶

To implement the indirect kick rule, each robot shares the timestamp of the last kick it performed with its teammates. If any of the timestamps received from teammates is more recent than the last set play, a robot is allowed to kick at the goal. The first robot that kicks the ball after a set play sends this information as a priority message (see B-Human Team Report and Code Release 2022 Section 3.2.1) to ensure that its teammates know that they can score. To preserve the message budget, further kicks are only announced as a byproduct of the regular team communication.

If a robot is not allowed to kick at the goal, it will pass to a teammate or dribble instead, just as it would do if the way to the goal is blocked or the goal is too far away.

Calibration¶

The calibration procedure got a handful of fixes. It can now be aborted at any time and restarted by simply bringing the robot back into the unstiff state with the head sensors. For two full calibrations back to back, a restart of the software is still necessary.

Motion Control¶

Walk Stability¶

We did smaller adjustments and improvements in the already existing balancing features:

The step adjustments velocity, which is used to determine how fast the feet are allowed to be moved to the corrected position, is drastically reduced once the current step time exceeds the step duration.
The side hip shift was improved with more suitable parameters.

Walk Planing¶

Our step planning modules WalkToBallEngine and WalkToPoseEngine and the used step planing utilities WalkUtilities got multiple bug fixes to reduce the occurrence of steps, which just let the robot stand still and waste up to 500 ms (two walking steps) of walking time.

In-Walk Kicks¶

We improved the stability, accuracy and speed of execution.

The decision, whether a kick will be unstable based on the previous step size, was improved and a WalkDelayPhase is used to improve kick stability.
In combination with the stable walk, the execution time of the kicks could be reduced by increasing the deviation thresholds.
The accuracy was improved by updating the kick after being calculated in the first few frames after the kick started.
We added dynamic diagonal kicks. Those are an interpolation between the forward and side kicks and are dynamically calculated based on the ball center position and the closest point of the edge of the kicking sole. This allows for a fast play of the ball near other robots.

Intercepting¶

We changed our intercepting for the dynamic ball handling challenge in 2023. This version was refined and used for the normal games. It replaces the simple intercepting by side steps requested by the behavior. This new version plans directly in the Motion process. It places the robot in the middle of the ball path and optimizes the translational step size of the rotational part. This automatically creates large side steps when the specific leg is the swing foot that is closer to the ball path and large rotational steps in the other case. In case there is not much time left, a step is calculated that only places one sole on the ball path. Also a back walking step is requested to ensure not walking into the ball, but a more smooth stopping of the ball.

Additionally we added the possibility to overwrite the current executed walking step to execute an intercepting step for a rolling ball. Previously, if the robot just started a walk step with the same side the ball would intercept the own y-axis, the robot needed to wait two full steps to start intercepting. This is a waste of up to 500 ms. Now the robot can start intercepting, even if the step is close to being finished.

Goalie Jump¶

We changed the decision for when the goalie can jump while walking. This reduces the chance of a buffered jump when the robot still needs to finish its walking steps. Also more intercepting by walking is used to allow the goalie to be more active with the ball afterwards.

Technical Challenges¶

B-Human participated in the only technical challenge that was held this year:

Shared Autonomy Challenge

Last update: October 6, 2025