Bardia's log book

Primarily, I did some research about what Nao is, how it works, and what the standard platform field of the robocup competition is. In this manner, the Standard Platform League is a RoboCup robot soccer league, in which the robots operate completely autonomously. In addition, the ball used is an orange no bounce hockey balls which is 65mm in diameter and it weighs 55g. Besides, Nao is an entirely programmable 60cm high robot. The robot's platform is linux, but it can be programmed by different programming languages on different platforms (Windows, MacOS, etc.) via cross-platform tools such as Choregraphe, Gostai, and even Microsoft Robotics Developer Studio.

Choregraphe includes all graphic interfaces, behavior libraries needed to create movements. It accepts Urbi and Python language, so it can directly call C++ modules developed separately. Gostai is developing Urbi, and also fully interfaced with C++, Java and Matlab.

Moreover, I read the report of B-Human team. So, I found out that b-human's code also included a simulator by which the sensors' data and behaviors of the robot could be examined. Therefore, we decided to read the b-human team's report plus to try to understand the applied algorithms and to compile the code. In this case, I tried to compile the code on my computer both in Windows Vista and Linux Kubuntu.

First, I tried to install the needed packages according to the report. However, in some cases, the version said in the paper were not available, and I had to install the new versions of them. After that, there were a lot of errors in compiling. The primary errors were because of the fact that a number of packages like g++ had not been installed properly. In this matter, I used the command below to solve the problem:

sudo aptitude install build-essential

However, there were still a number of errors that I could not solve. Therefore, I switched to Windows and tried to follow the report's steps to install the required packages. I installed Microsoft Visual studio, and downloaded "bhuman-cygwin.tar.bz2" and "opennao-academics-1.3.13-nao-geode.rar" packages from the aldebaran and b-human's websites. I also tried to install Cygwin version 1.5, but its mirror servers installed it in the way of the newer version. I mean that its "opt" folder consisted of a folder named "gcc-tool" instead of "crosstool"; according to some forums, this difference in the construction was due to the mirror server from which the cygwin had been installed. Moreover, their contents were also different from each other. So, I just copied the packages from the "bhuman-cygwin.tar.bz2" file to the mentioned locations. Finally, I added the path of the Cygwin folder to the environment variable. Thereafter, I could compile the code and run the simulation, but two essential packages "libbhuman" "_Nao" were not compiled. The problem was reported as below for example:

1>------ Rebuild All started: Project: libbhuman, Configuration: Release Win32 ------

1>Performing Makefile project actions

1>make: /bin/sh: Command not found

1>make: *** [clean] Error 127

1>Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"

1>Build log was saved at "file://d:\E-Books\UVA\AIProject\UvaProj\Build\libbhuman\Linux\Release\BuildLog.htm"

1>libbhuman - 1 error(s), 0 warning(s)

========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

 

I tried to figure out any solution on the Internet; all of the suggestions were about fixing the PATH variable, like:

export PATH=.:/home/yap/bin:`printenv PATH`

setenv PATH=.:/home/yap/bin:/bin:/usr/local/bin

However, none of them worked with my cygwin. In detail, the command "setenv" was not known for the cygwin, and the first line, although, seemed to work, it was not effective because by restarting the console, the PATH was also reset to the former addresses. Thus, modifying the PATH did not help me solving the problem.

Since dealing with the German code plus overcoming the compiling issue was very time consuming and fell us behind the schedule, we switched to the Choregraphe environment. In fact, because special actions in the code are hardcoded, it is much easier and faster to work with Choregraphe to figure out motions like kicking.

After installing the Choregraphe, we faced a problem. Some motions like walking or turning around did not work on the robot; the error alerted pointed to the lack of a package called "almotion". Finally, we figured out that this problem was because the robot's software version (bleu , 13.8) was older than our simulators' versions (13.13 and 13.17). Therefore, by connecting to the new robot (Rouge), we could run all the available motions on the robot.