Strive3D Team Description 2011

Tongluan Chen, Junjun Qu, Zhengliang Liu, Yan Pan, Yuan Yao

Shanghai University, China

Abstract This paper simply describes the history, background and its solutions of achieved and implemented in RoboCup 3D Soccer Simulation League. Beginning with the introduction of the Strive3D team, the paper firstly describes its history and background. Secondly, it briefly introduces its main technical features including agent architecture and basic individual skills. Conclusion and vision are illustrated in the 3rd part.

I. Brief Introduction of The Team

The RoboCup soccer simulation 3D league has taken a big step forward to the RoboCup's ultimate long-term goal Since the 2007. The simspark with humanoid robots was used in RoboCup-2007. In 2008, the development of simulation 3D is heart-stirring. The better agent model, called Nao, has been used in the competition. In RoboCup-2008, 3Vs3 has been tested, and the competition of 4Vs4 is also actualized in China Open 2008. The simspark is an experimentally platform for researchers of humanoid robots behavior. Comparing with real humanoid robots, humanoid simulation environment has advantage in costs and convenience, so we can experiment on methods and algorithms for humanoid soccer behaviors in order to optimize them and apply results in real humanoid robots finally.

Founded in 2005, Strive3D team started to explore in the frontier of 3D simulation with the ultimate aim to apply its solution to real humanoid robots. After the reorganization of Strive3D team in 2006, it participated in the 1st RoboCup China Open and did not get great achievement in 3D Simulation League. In order to catch up the change from Sphere Agent Model to Humanoid Agent Model happened in 2007, the focus of the team immediately shifted to the research on biped humanoid agent locomotion. Grasping a rough command of controlling the humanoid agent, it attended Iran Open 2007 in which biped humanoid agents premiered in the RoboCup competition. In Latin America Open 2007, it got the 3rd places. In 2008, strive3D team obtained advancement. It became the Top 8 of Iran Open 2008, and gained the qualification of RoboCup-2008 which was held in Suzhou, China. In 2009, strive3D team also gained the qualification of RoboCup-2009 which was held in Graz, Austria. In 2010,strive3D won the runner-up in the Iran Open 2010,got the 3rd places in the China Open and got the 3rd places in the AUTCUP 2010.

II. Technological Features

This section describes the technological features of Strive3D team.

1. Agent Architecture

More modules have been added The Strive3D's agent architecture. It makes the agent architecture more flexible. Control layer is necessary for the humanoid agent. For flexible group the action, programming layer is added between the control layer and the cooperation layer. When more agents cooperate in the match, cooperation layer will deal with the relationship between them. Here is the simple map of Strive team's architecture.

2. Basic Individual Skills

The Nao humanoid model is used in 3D simulation. It was derived from the Aldebaran Robotics model. So, the basic individual skills will be essential to the further development of the 3D simulation. For instance, biped locomotion is considered to be a very complex task, as it implies controlling a very large number of degrees of freedom (DOFs), the non-linear dynamics of the humanoid body and a wide range of interactions with the environment (gravity, force, collision, perturbations, etc.). The main difficulty is to achieve dynamical stability, and particularly resistance to unexpected perturbations.

In Stive3D agent, several kinds of actions have been created such as walking, rotating, bestraddling, countermarch or the action consisting of any two of them. Walking is the most important one. Strive3D develop the gait which is planned based on the ZMP off-line. If the actual humanoid model and the environmental conditions are the same as those of the planned gait, then the humanoid can walk stably only if following the planned gait. If there are unexpected factors in the actual environment, the planned walking pattern is modified automatically by real-time control based on sensor feedback. The trajectory of the leg's joints is periodic, when agent is walking, turning, etc., we calculate the ZMP based on the information from the force preceptor. Depending on the ZMP, we can judge agent whether it will tumble.

From the force preceptor, we can get the force and coordinate:

$$\begin{cases} F_{L} = \begin{bmatrix} f_{Lx}, & f_{Ly}, & f_{Lz} \end{bmatrix}^{T} \ F_{R} = \begin{bmatrix} f_{Rx}, & f_{Ry}, & f_{Rz} \end{bmatrix}^{T} \ P_{L} = \begin{bmatrix} p_{Lx}, & p_{Ly}, & p_{Lz} \end{bmatrix}^{T} \ P_{R} = \begin{bmatrix} p_{Rx}, & p_{Ry}, & p_{Rz} \end{bmatrix}^{T} \end{cases}$$

Then, the coordinate of ZMP can be calculated:

$$p_{x} = \frac{p_{Rx} f_{Rz} + p_{Lx} f_{Lz}}{f_{Rz} + f_{Lz}}$$

$$p_{y} = \frac{p_{Ry} f_{Rz} + p_{Ly} f_{Lz}}{f_{Rz} + f_{Lz}}$$

3. Head Control for restricted view field

Humanoid vision system, such as restricted view field of the robot and decrease of indicative signals is a trend, which has been gradually applied to Robot contests including RoboCup 3D Simulation League since 2009. The environment of contests feels like more real with the development of vision as said. However, self localization and strategy-making are more difficult for Robot agents. Therefore, humanoid head behavior shall be adopted as one of ideal solution to such an issue. Our team designs and proves useful modules of head control, which well fulfill the requirements brought by restricted view field.

3. GUI Debugger Tool

Before creating this tool, we have tried many method to improve the efficiency of developing our agent. But the traditional ways such as a plain text logger file is proved to be very hard to read and analysis because the developers cannot get continuous pictures of what had happened when the server and agents are running. So we decided to develop a new tool that can overcome those inconveniences and make developing a easier work to do.

The original goal of this tool is to give developers an animated or real-time looking of information provided by Strive3D agents, such as how they plan the "way-point", what kind of decision they made under current circumstance and even how they communicate with each other. Later, we found it's also a good idea to use the debugger to create a training scenario for the agents. Parts of the goals are achieved already.

The picture above is a simple illustration of how the debugger works. The debugger works as a server, and the agents send messages to the debugger describing what is happening to the field and itself. All Strive3D agents can send messages to the debugger, so the debugger decides whose information to display on the field canvas by the selection list beside the canvas. The current selected agent is player 3 of Strive3D, and this agent is painted as a red circle. It tells debugger the position information about teammates, opponents and ball, so debugger draw an opponent as a green circle(two yellow points in the circle indicate his feet), and ball as small white circle. This picture is obviously much clearer than simspark can provide if the developers consider 2D position as priority. This can be really useful when we adjusting team's formation and examine our WorldModel module, etc.

The debugger also provides the GUIs to control our agents in two modes: Mouse Click Mode and JoyStick Mode. In Mouse Clicked Mode, we control the agent just as we do in some games. In JoyStick Mode, we can make the agent move forward, backward, left and right by clik the buttons.

Fig.5 shows the Mouse Click Mode of the debugger. The mouse clicked at position(3.44, 0.32). The agent got commands from the debugger and began to move to the position.

If the debugger is to create a training scenario, it need to send message to tell the players about the scenario, for example, the obstacles' or other players' position, etc. Of course, all objects, both real(other players) and virtual(indicated as blue circles), will be drawn on the field.

Fig.6 shows the agent's abstract thinking result. Two teammates were so close to each other that the agent considered these teammates as a bigger obstacle and wrapped them with a convex hull for obstacle avoidance.

Fig.7 shows the agent's path planning. There were four virtual obstacles in the agent's path to the destination. So he planned his new path as the red line.

Yet we are planning to extend its usage. We think it would be great if the debugger can provide some useful view port for basic action debugging. We also plan to create some virtual players for tactics planning.

III. Conclusion and Vision

With the development and enhancement of the 3D Simulation worldwide, it will strive for making a great forward to more sophisticated individual skills and strategy. For instance, the research on faster and steady walk, smooth transition between actions, etc. Meanwhile, a perfecter development tool will be anther focus of its planning.

References

1. Shuuji Kajita, Hirohisa Hirukawa, Kazuhito Yokoi, and Kensuke Harada. Humanoid Robots. Ohm-sha, Ltd, 2005
2. Yariv Bachar. Developing Controllers for Biped Humanoid Locomotion. Master thesis, Science School of Informatics, University of Edinburgh, Edinburgh, 2004.
3. J. Pratt. Exploiting Inherent Robustness and Natural Dynamics in the Control of Bipedal Walking Robots. PhD thesis, Computer Science Department, Massachusetts Institute of Tehcnology, Cambridge, Massachusetts, 2000.
4. Q. Huang, S. Sugano, and K. Tanie, "Stability compensation of a mobile manipulator by manipulator motion: Feasibility and planning," Adv.Robot., vol. 13, no. 1, pp. 25–40, 1999.
5. K. Hirai, M. Hirose, Y. Haikawa, and T. Takenaka, "The development of Honda humanoid robot," in Proc. of ICRA, 1998, pp. 1321–1326.
6. F. Pfeiffer, K. L¨offler, and M. Gienger, "The concept of jogging johnnie," in Proc. of ICRA, vol. 3, 2002, pp. 3129–3135.