Austrian Kangaroos
Our drop-in AI is based on the one used for regular games. We take team communication into account. However, as we can’t assume reliability of all team mates, we added functionality for world model fusion and team consensus. The player’s behavior is primary determined by its role, which is either assigned due to its static number, or due to suggestions from team mates (in case of received suggestions, we perform a weighted vote). Our behaviors can be summarized into defensive behaviors that guard a position or the ball, as much as offensive behaviors that go for the goal or open space in the opponent’s half. The player’s role specific intention is determined by locally calculating and comparing utility- and accessibility-functions for each player of the team based on a fused world model. The world model is derived from a local one and information received from team mates (positions, roles/actions of team mates, predicted utility for each team mate). Our intentions can be classified into active and passive ones, where active intentions are typically chosen if the player claims possession of ball, while passive intentions are selected if the player tries to support or cover the active team mate. Finally, the player’s action is selected w.r.t. its before calculated intention as much as to the predicted ones of all team mates.
Berlin United – Nao Team Humboldt
In the Drop-In competitions our players use the same code and behavior as in regular games. Whether the robot should go to the ball is decided only based on the communicated distance to the ball, i.e., if the robot is closer to the ball than any other player it immediately becomes striker and goes to the ball. If the robot is not the one closest to the ball, then it returns to it’s strategy position, which depends on it’s number. We rely on obstacle avoidance to resolve conflicts in going to the ball simultaneously with other teammates or to the same strategy position.
B-Human
The Drop-In Player Competition games are mainly played with the same software as the regular games. Significant adaptions concern only communication and behavior. Some of the information that is usually exchanged between B-Human players is not part of the standardized section of the SPL standard message. We cope with that fact by constructing the needed information locally and handling it separately. As some information given by other players might be imprecise, wrong, or even missing, the reliabilities of all teammates are estimated during a game. This is done in the same way as in 2014. Our drop-in robot always suggests roles for its teammates based on their reported positions on the field. In addition, we accept suggestions by our teammates, if a majority of the trusted teammates agrees on a role for our robot. Overall, we try fill all fields of the standard message (including the ones that are not mandatory) with reasonable values and try to consider all information from our teammates, if possible. As passes are rewarded with positive scores, our drop-in player tries to pass to teammates that report an adequate target position. For normal games, passes are not activated. If the vision system reports a teammate close to the ball, we do not try to play the ball. As we believe that our robot can better contribute to the overall team performance when being a field player, the goalkeeper role is avoided.
Camellia Dragons
The strategy is fully based on the action priority whose concept is described in the team description paper. If an action priority value of our robot is higher than those of other teammate robots, the robot approaches a ball to dribble or shoot it. Otherwise, the robot selects other actions, e.g. receiving a pass or defending a goal. To calculate the action priority value, we use the positional information of other teammate robots based on a self-localization system which is obtained through the team communication.
Cerberus
In previous year, we let other robots to take control of the ball if they are closer to the ball then our robot. However, this year we choose more dominant strategy. If our robot percepts the ball, he wants to take the control of the ball and score a goal. If the robot does not percept the ball, he sends the intention as “nothing particular” and searches the ball.
HULKs
Currently our Drop-In Strategy is very basic and simple. Our first goal this time was to minimize our leaving the field count. Our second goal was to search for the ball and shot it in the direction of the goal without pushing. At the moment we do not use the information from SPL Messages from our team mates.
JoiTech-SPL
The JoiTech-SPL players employ the same behaviors or strategies of ordinary games for drop-in games. Currently we are not yet doing a processing of the localization information of other players. Our strategy in the drop-in challenge is mostly offensive. The robot looks for the ball and tries to kick it towards the opponent goal while avoiding to collide with other players.
Linköping Humanoids
Our team, Linköping Humanoids, does not do anything specific to handle the drop-in challenge. We decided to do a simple defender that would help protect the goal. Basically covering the goal and clearing the ball. Unfortunately we had issues with our game controller implementation, which were solved in time for our last drop-in game. However, in the rush we didn’t update our start-up procedure so the module sending the SPL standard messages was not started. The short time we were on the field, until it was detected that we didn’t send the SPL standard messages, the robot performed as expected guarding the goal.
MRL-SPL
We use a very fundamentals that we employ in the main competition with some strategy modifications. This includes following parts: task selection, high level behavior modelings (role assignment and pass planning modules), and high level behavior modelings feed-in modules (such as ball models of drop-in teammates, etc.). Beside mandatory fields of the SPLStandardMessage we provided other fields like shootingTo, ballAge, ball and ballVel. In contrast we only use our teammates pose and their intention without any filtering or estimation of truthfulness which is a drawback for us too. Our strategy in drop-in games is as following: (1) Our intention is always to be a goal keeper unless someone has become one. It is indicated based on the position that teammates broadcast. (2) “play the ball” role is chosen by solving a distance optimal problem. Whose closest to the ball is supposed to play with it. Otherwise a default position on the field previously defined in configuration files during code deployment process is taken. A closed-form defender positioning can also be used. Choosing between a static default position or closed-form defender positioning is made by a flag during code deployment process as well. As a conclusion there are number of enhancements and pitfalls that should be covered by us in the future. First, we are not playing with all conscious but hoping to give a chance to other teammates by providing most of the data. Second, no validation is performed on the received teammate data which makes it difficult to act based on a right judgement. Third, our strategy is not as dynamic as our main competition one for the drop-in games. And last but not least, our results in drop-in games owe to the low level behavior very much which we hope with a better coordination and high level decisions it will be a better couple for future drop-in games. Our future efforts is going to focus on “whether a good player in a heterogeneous team can be a good one in a homogeneous team as well or not”.
Nao Devils Dortmund
If our robot is placed near to our goal at initial, then we will be goalie, otherwise field player. If we don’t detect another team robot, we will go to the ball if we are not goalie. Otherwise, we will let other teams approaching the ball, and position as a supporter. We also look whether the communicated models match with ours. If this is the case, we trust them, otherwise we discard them.
Nao-Team HTWK
Our strategy in the drop-in challenge since last year changed, that we use dynamic positions on the field, based on our tactic. To achieve good points we try to hold the position behind the center circle and wait for passes of our teammates, but also we take free space as Striker, to get a pass to the goal or hold Position as the Goalie. Often we realize that the situation is dire and we can’t determine that any of our teammates is going for the ball, we become active and dribble into the goal.
Northern Bites
This year’s drop-in player was simply a modified version of one of our normal players. However, rather than associating the role of the robot with the player number as we normally do, we gave ourselves the option of choosing which role the player would adopt independent of its player number. More often we opted to begin the game with an offensive role, but we have also chosen to play defensively in selected games.
NTU RoboPAL
NTU RoboPAL conformed the SPL standard message during the drop-in player competitions. Except the “suggestion” field, NTU RoboPAL provides all other useful information defined in the SPL standard message such as the robot’s pose and the ball position as well as the walking to and shooting to information to our teammates. However, we wouldn’t suggest any particular strategy to our teammates. We wouldn’t use other teammates’ information for our own decision making. In fact, we used the strategy same as the regular soccer competition while no network communication was available. Our intention would be “want to play the ball” and would be less likely to avoid other robots no matter the ones were teammates or opponents while the ball had been seen. Otherwise, the avoidance would take place and tried to seek for the ball.
Philosopher
For the drop in competition we use a modified version of our defender behaviour. The robot is allowed to play in his zone, which for the drop-in has been defined as whole our half of the field (plus ~10% of the opposite half). Robot constantly checks whether it is well localized, whether it is in the correct zone and if the ball is also in this zone. If all aforementioned checks pass, robot is allowed to go to the ball, aim to the opposite goal and kick. Otherwise robot is either scanning for observations(when localization check fails), scans and turns(when looking for the ball) or goes to the center of his zone(when the zone check fails). In case when robot is well localized in his own zone, but ball is on the opposite side of the field, robot takes the position on the field near the center line, with intention to be closer to the ball.
RoboCanes
The RoboCanes drop-in game strategy is almost the same as our regular behavior. The own belief always has priority over information received from teammates. The role and position is selected based on the positions of other players relative to the ball. The positions are assigned from the front starting with the striker, a supporter position next to the ball and defenders behind the ball. Since we trust all teammates, our player is sometimes too defensive if another player sends that he is close to the ball. Detecting which robots send correct information and are localized correctly is one of the most important skills for the drop-in games. Ignoring all positions received from teammates makes our player look much better and get to the ball more often, but obviously that would not work for an entire team. We are planning to be able to detect messages with wrong information next year, since that can also be used in regular games to detect if a robot is not localized correctly.
RoboEireann
We listen to team communications from team-mates but do not trust it and hence disregard most of it. We communicate all mandatory information and include both our intentions and suggestions for team mate positioning. Since we expect that many team mates will ignore this anyway, our current suggestions are based only on player number. In ready state we try to adopt a field position that is related to the position on the sideline from which we started rather than a specific location on the field. Once play starts we search for the ball using our standard search pattern (which eventually selects random field locations from which to search if the ball is not found). If we find the ball we approach it and attempt to play it. In general if one of our team mates is closer we allow obstacle detection to resolve the conflict and we back up a few steps. If we get access to the ball we follow our normal striker behaviour which chooses among available kick types in a stochastic manner (influenced by distance to goal and orientation to the goal).
TJArk
1. Strategy of roles select In Drop-in competition, according to the communication with other teammates, if there are more than two teammates intend to be defender or striker, our drop-in player will play different roles from them to avoid all robots playing the same role. 2.Strategy according to a certain circumstance or role Ensuring the direction of the ball is to the opposition half, at the same time, our robot will kick the ball more to the direction where there are more teammates and less opponents;Besides , our drop-in player will position to receive a pass and intercept an opponent’s shot under certain circumstances.
UnBeatables
Our strategy consisted on the use of the framework provided by the German team B-Human where modifications were made especially on the state machine responsible for behaviour control. The basis of our approach on developing strategy was to take a defensive stand, where we focused on avoiding obstacles, such as other robots. For goal detection, we implemented a routine that identified the white goal post, as well as eliminated the false points detected when analysing the image with white robots. For ball detection we implemented the strategy of turning around, first looking down to see if the ball was close, then our robot turned its head up to look if the ball was farther away, and if it was still not detected it moved around on the field and repeated this procedure.
UNSW Australia
We tell all our teammates of our intentions, including where we are, where we are moving, where we are kicking, what intention we have. We don’t believe what our teammates tell us about where they are and do not attempt to tell them what to do. We search the field for the ball, moving closer to the centre of the field if we can’t find it. If we perceive another teammate closer to the ball, we remain stationary and let them play the ball. If we can’t see a teammate closer to the ball, we will attack the ball. If we are close enough to goal we will shoot, if not, we will try to pass towards the goal. If there is no teammate in a reasonable upfield position, we pass vaguely towards the goal area. If we are player 1, we play goalie. Here we position to defend the goal and clear the ball upfield once it gets closer than our own penalty spot.
UPennalizers
We use a very basic strategy for a drop-in player. There are only two states for the drop-in player; attacking and defending. The player will act as attacker if the ball is closer to the player than other team members. This is determined comparing the information received from other team members and the ball distance from the robot itself. That is, if the robot is closer to the ball than the distance provided by other team members, the player will start chasing the ball(i.e. it becomes attacker). Similarly, if the ball is far away from the player or doesn’t see the ball for more than 10 seconds, it will act as a defender. The robot will keep seeking the the ball in defending area while maintaining its defending position. If the ball comes closer to the robot, it will kick the ball away and/or chases the ball again.
UT Austin Villa
UT Austin Villa used mostly the same software for the drop-in player competition as we use in our main competition games. We sent valid information that was correct to our best estimation for all fields in the standard message. We completely trusted the information sent to us by teammates (and converted it to a format that our main competition codebase can understand), and chose our intended role based on the intended roles of each of our teammates (ignoring fields such as kick distance and walking speed). We preferred defensive positions, but if there was no one playing the ball, we would play the ball. Likewise, if a teammates was playing the ball, but there was no keeper, we would play keeper. When suggesting roles for teammates, we suggested a teammate’s intended role unless either (1) many other teammates were also intending this role or (2) our robot wanted this role. We calculated and sent new intention and role suggestions once per second in ready, set, and playing (and adopted what we sent, which sometimes caused some thrashing especially in ready and set).
WrightOcean
In the drop-in contest of this year, our strategies consider both the attacking and defending. We can play the role of both striker and defender. When our team-workers are attacking violently, we play a role of a defender, and walk back and forward in our half field, and our responsibility is cleaning the ball entering in our field. In other times, we play a role of a striker, and in this time, our responsibility is scrambling for the ball and ticking back it to the other half field. The standard information sent by the partners is not used adequately, and thus the cases of collision may happen. Our hope is that we can use the standard information adequately in the next step, and provide a more successful drop-in contest.
Z-Knipsers
Our drop-in player took an offensive role on the pitch, trying to score a goal when close to the ball. Our robot broadcasted all the allowed information to his team, but did not use the received information of the teammates’ messages as we are currently still working on communication issues. This also contributed to non-optimal self-localization and ball-detection, the two main challenges we faced during the RoboCup 2015.