***9/26/2006 Jeremiah showed me the German Team website (www.GermanTeam.org), the codebase, and the simulator. I downloaded GT2005.zip, GT_Install.zip, and GT2005.pdf. ***9/27/2006 I spent time reading a large document from the GermanTeam website (GT2005.pdf) and most of Lindsey's logs at http://www.gotbots.org/DOCS/Logs/Lindsey_Logs/AIBO/. ***9/28/2006 I compiled the GermanTeam 2005 code without issues. Then I checked that the dog started up as it was supposed to. Everything looked good. I found the penalized.yabsl file which Lindsey indirectly referenced in her logs (http://isl.ecst.csuchico.edu/DOCS/Logs/Lindsey_Logs/AIBO/Changing_existing_code). The penalized.yabsl file resides here: /GT2005/Modules/BehaviorControl/GT2005BehaviorControl/Options/GameStates/penalized.yabsl. The file looks like the following: /** The behavior when the robot is penalized */ option penalized { initial state stand { action { sent_game_state = penalized; head_control_mode = look_between_feet; stand(); } } } I changed look_between_feet to look_to_stars as is seems Lindsey did. Both of these (look_between_feet & look_to_stars) are found in other yabsl files such as: Modules/HeadControl/GT2005HeadControl/basic-behaviors.yabsl Modules/HeadControl/GT2005HeadControl/symbols.yabsl Changing this line in the penalized.yabsl did not change the behavior of the dog when I picked it up (supposedly when the penalized code would be called). I verified that when compiled that the penalized.yabsl produces a /Build/Xabsl/Modules/BehaviorControl/GT2005BehaviorControl/Options/penalized.xml file which contained my change. However, I do not yet know how to tell if a corresponding change was made on the Memory Stick when I run MemStick.exe. So, either the the penalized.yabsl/.xml do not change the behavior I anticipated or the change is not making it to disk. ***10/3/2006 I spent a short time catching up on my log writing. I found that the /opt/html/htdocs/isl/DOCS/Logs is owned by islweb (juliano, renner). I told this to Dr. J. who created us each our own log directories within "Logs". These subdirectories were changed to the 'isl' group. I still had trouble ftp'ing my log to the server, so I spoke with Elbert. After some poking around he said he thought that the ftp client I was using may be having trouble following the link from /opt/html/htdocs/isl/DOCS/Logs to Dr. J.'s web directory. I downloaded WinSCP and found that I could use that to ftp my files over. --- I spent some time reading documents from Hamburg (see the Hamburg subdirectory in my logs directory): TeamReportHDB2004.pdf TeamReportHDB2005.pdf I skimmed the 2004 document which talked about how the Hamburg team originally started coding with 2 teams--one on the 2003 GermanTeam code & one developing its own codebase. It told about how they divided the teams and what they worked on. It was fairly short and not a whole lot of detail. The 2005 document is *much* longer. It got into a whole lot of detail that I don't think I am prepared to read. I think I should read the Open-R SDK tutorial and the R-Code tutorial before reading anything else in depth. --- I downloaded Carnegie Mellon's codebase... Note the following from their readme: "This code was developed to run under Linux. The code itself can be compiled and used under Windows by using Cygwin, or under OS-X, but most of the tools will not work because of the visual libraries required. Under Linux the following libraries must be installed on your system to successfully compile the code and tools: gcc ruby (needed to compile) perl (needed for most scripts) FLTK (used by vision tools) GTK and Glade (optional, used by old tools) ImageMagick++ (needed by vision tools) Fluid (needed by vision tools)" So, if we went with CM's codebase I think we would have to switch to Linux to work smoothly. --- I downloaded UPenn's codebase... UPenn's code is in Perl. As stated on UPenn's introduction on their perl tutorial website (http://www.cis.upenn.edu/robocup/tutorials/perl_tutorial.html): "The fundamental way to write software to control an AIBO is by using Sony's OPEN-R API, a free download from the OPEN-R website. OPEN-R is an object-oriented, C++ API that provides the bare minimum in order to get started with programming the AIBO. Writing code for OPEN-R can be a frustrating experience. It can be arcane and confusing at times, and documentation ranges from sparse to nonexistent. Writing the code, of course, is only half the difficulty in any software project; debugging is always an issue. Debugging binary code on the AIBO is far more tedious than you are probably accustomed to, for a number of reasons with which I won't bother here. It is for this and other reasons that we decided to take a novel approach to controlling the AIBO: write as little C++ code as possible. The result is a fast, minimalist, stable core written in C++ underlying a Perl interpreter that controls all high-level behavior. The upshot of this is that it's very simple to write basic programs to control the AIBO. All that's required is a basic knowledge of Perl, though this tutorial does not assume it. I would recommend either Learning Perl or Programming Perl, both published by O'Reilly. Hint: if you are on Penn's campus, try Safari." I think that UPenn's code would be interesting to look at further. --- I looked at the rUNSWITFT website http://www.cse.unsw.edu.au/~robocup/2006site/index.phtml. I didn't find a download for their code. But, I will look again. --- I read a portion of an rcode tutorial (I've uploaded a version to my logs directory). I was wondering about the difference between r-code and open-r code. According to the tutorial: "R-Code is a scripting language for programming AIBO robots....Think of R-code instructions like macros and the OPEN-R programs like the code of those macros." --- Found this website: http://openr.aibo.com/openr/en/ I should go through the Open-R SDK tutorial ***10/4/2006 I spoke to Birget Koch today. She advised looking for a codebase from a school that finished somewhere in the middle of the pack. She said the top schools have put intentional bugs in their code. She also said that the GermanTeam's code is exceptionally difficult to understand. Her team took 6 months to understand any of it. She mentioned that her team may start using the rUNSWift code. But, they've found very little documentation for it and she does not recommend that codebase. I tried to set up times that we could set up the robo soccer field in rm 254-- work still in progress. Birget may be able to meet with us next Friday at 3pm (10/13). I hope to have the room reservations worked out tomorrow. I skimmed the R-Code tutorial (rcode_tutorial_1v2.pdf) and played with creating/editing an R-CODE.R file located under /OPEN-R/APP/PC/AMS on the Memory Stick. I got the dog to sit, lie, turn, walk, and kick. The parameters for the kick action were confusing (degree and distance). The leg always seemed to kick outwards instead of forward despite my value for "degree". Anyway the R-CODE is not used in any of the codebases to play soccer since it does not give enough options. Specifically, the dog can look for a pink ball, but there is no known way to make it look for a different colored ball. Tomorrow I'll start looking through the OPEN-R tutorial and possibly find the UT-Austin codebase. ***10/5/2006 I sent out some emails pertaining to Logs and the reservation of room 254. I got half way through the OPEN-R tutorial. ***10/10/2006 I read chapter 3 in the OPEN-R tutorial. It talked about how to retrieve sensor readings and send commands to the joints, etc. I had to reset A1B0 router since it didn't have the given username/password in order to change the WEP key or any of the other settings. After that I had trouble with internet access. Elbert told me that the 244 lab is static ip only and that he thinks that the person who set up the router originally had borrowed/stolen an ip address to use. He gave me an ip address/gateway/dns server to use and even gave me the dns name "aibohive". I've put this information in the aibo_info file on one of the desktops and will print out a version for the lab. I experimented some more with changing the LAN settings on the AIBOs. I found that every time I manually edited the file /open-r/system/conf/wlanconf.txt that the AIBOs would not star up properly anymore. After a little more experimentation I think that whatever piece of code reading it may be depending on a specific EOL character differing from the one that gets put in when I edit it. I'll try to get this worked out tomorrow. *** 10/11/2006 So, the problem with my editing the /open-r/system/conf/wlanconf.txt file was not the EOL character. The problem occurred every time I changed the WEP key in the file. The hexadecimal WEP key must be preceded by "0x". This is documented in the OPEN-R SDK Installation guide. I played with the wireless connection of the AIBO. It appears that with the LAN switch turned on and the wlanconf.txt file configured correctly that the AIBO automatically connects to the network. I'm not sure why there is a special procedure for connecting the AIBO to the network. Maybe I'm missing something. I tried to make the AIBO--with the GermanTeam's 2005 code installed--work with the UNSW 2006 GameController. I think I read that they may not be compatible. I'll look into this further. I started reading the OPEN-R SDK Documentation after skimming most of the OPEN-R Tutorial. *** 10/18/2006 and 10/19/2006 I compiled the UPenn code on Windows via Cygwin. The README said that it has only been tested on Linux and MAC, but it compiled all right. I can't seem to get it to run though--even when copying the OPEN-R base code first and then copying the open-r directory result from the build. From what I've seen of the UPenn documentation and READMEs, I don't see anything that is helpful in this matter. It is possible that I need to compile this on Linux, but I'm sure that can't be the only problem. I plan to spend more time reading the OPEN-R SDK this weekend and install Linux on my laptop. *** 10/23/2006 I installed Linux on my laptop over the weekend, but didn't get to read any more of the SDK. I got the UPenn code to work on the dogs. I found I wasn't copying the correct open-r directory (I must have been using the R-Code base instead of the OPEN-R SDK. I used the WCONSOLE/open-r directory from the OPEN-R SDK as base, then copied the open-r directory built from the UPenn code. The dog starts up and works. Mike and I put 2 dogs on the floor--one with the GermanTeam code and one with UPenn. We threw the orange ball out and found that the GermanTeam dog repeatedly found the orange ball and the UPenn dog just danced around in circles. I was surprised that the GermanTeam dog found the ball since we had not set the dogs up on the actual field so there were no markers or familiar turf for them to use. I think we should set up the field again with 2 different codebases to watch them play. *** 10/24/2006 I spent some time trying to build the rUNSWift code. I'm finding that none of these codebases we look at have build instructions. rUNSWift seems to be harder to build than the UPenn. It does not have a main Makefile. It has makefiles in subdirectories. I looked through some of their documents and didn't find much. *** 10/25/2006 I spent more time with the rUNSWift code. The directory structure contains python, C++, and Java. The "robot" directory wouldn't build at first since some .cc & .h files referenced header files locally that weren't in the same directory. I changed the files to reference "../share/" so that it built. I tried copying the WCONSOLE OPEN-R SDK base and then the output of the build. That didn't work. I realized that the dog needs the python code on it. I spent time putting a python directory in my cygwin (that I'm assuming that the build of another directory needs in order to copy to the memory stick with the rUNSWift python code). One of the directories needs JOGL (OpenGL library access through Java). I downloaded that and will try to set it up properly. I'll spend one more day trying to make the rUNSWift code work. Currently, Jeremiah is trying to get the Carnegie Mellon code to build on Linux and Nalaka is trying to change a behavior in the GermanTeam code by looking at my logs and the GermanTeam Manual. Our date to decide which codebase to use was November 1st. However, Dr. Renner said that we could have one more week. I hope this will give us a chance to get one more codebase to run and to determine whether we can figure out how to change a behavior in the GermanTeam code. *** 10/26/2006 I got the RoboCommander and SimpleRoboCommander stuff (the portion of the rUNSWift code that uses JOGL) to compile. I also got the portion of the code used on the dog (the "robot" directory) to run on the dog. I had to do some manual steps like copying an older version of the OPEN-R SDK (since the README specified an older version and I have the newer one installed). The "ins" script still errors out due to a missing file "pychecker" which I need to find out more about. So, I called the "make prep" manually. If we decide to go with this codebase, I'll clean up the scripts and do some more documentation. I'd like to try using the newer SDK next week to see if the dog still works. I got the Carnegie Mellon code to compile after downloading several libraries to my Linux installation including Ruby. I did not get the chance to try to make it run on the dog. *** 10/31/2006 I configured both teams of AIBOs. I put the UPenn code on the blue team of AIBOs and rUNSWift code on the red team. All dogs are configured with non-conflicting ip addresses and are set to use the A1B0 ssid. UPenn code appears to configure their team by the HOST_NAME parameter in the wlanconf.txt file. HOST_NAME=robot1...robot4 configures for the red team so I've configured the dogs as HOST_NAME=robot5...robot8. I believe is the robot5 is the blue team goalie. rUNSWift has a "spip" script which sets each dog's player (e.g. pGoalie/pForward) type, ip address, and team number. *** 11/1/2006 I recompiled the Carnegie Mellon code (2004) and put that code on a dog. It behaves much differently than the other codebases. The buttons on the dogs back affect the way the dog walks and tapping the head only seems to put it in a ready mode of some sort. The Carnegie Mellon code seems to be the hardest codebase to *initially* deal with since you must download several Linux libraries and I'm not sure how to put the dogs in the read/set/play modes. I didn't get far enough to figure out how CMU configures its player modes. Note that we only have the 2004 CMU code so that there would have to be more changes than the 2005 codebases. *** 11/2/2006 I read the XABSL/YABSL & behavior sections of the GermanTeam document. The document is very long and complex. I'm leaning away from the GermanTeam code as well as Carnegie Mellon. I played with the 2005 official (rUNSWift) game controller. It works by default with the 2005 rUNSWift codebase. I tried to put it on the UPenn codebase by following the sample code that rUNSWift has. It appeared to change the LED use of the dogs but I did not figure out how to change the mode of the dog from "Initial" to "Ready"->"Set"->"Play". Something still seems disconnected. *** 11/3/2006 We set up the AIBO soccer field. We had UPenn code on the blue dogs and rUNSWift on the red dogs. We had trouble with getting all the dogs to be "ping"-able. Only one UPenn dog seemed to be on the network at a time. All but the goalie for the rUNSWift dogs were ping-able. So, the game controller was usable for the 3 rUNSWift dogs. I asked Nalaka to determine why the UPenn dogs were not on the network. I also suggested he try playing with the "APMODE" in the wlanconf.txt file. I had the APMODE set to "2" on all the dogs. This is the automatic mode. Maybe if we set it to "1" we will have better luck. "1" means that we are telling the dogs that we have an Access Point and "0" means an Adhoc network. I asked Jeremiah to look into why the rUNSWift goalie was not on the network. I will need to get him the changes I made to the code so that it compiles and runs. *** 11/7/2006 I read the majority of the 2006 Soccer Rules for the 4-Legged Soccer competition. According to the rules, the dogs must be able to be set to the Ready, Set, & Play modes manually in the same manner (tapping the head sensor on the ERS7). I also found that the middle back button with the amber light is supposed to denote which team is kicking off. If the middle amber light is lit than that is the team that is kicking off. I set the "APMODE" in the wlanconf.txt file to "1" (for the access point) on all the rUNSWift dogs. In this state I was able to bring all the rUNSWift dogs up on the network at once. This may have been the issue with the rUNSWift goalie. I also remember when we had the soccer field set up that I was only able to ping 2 of the 3 dogs that were being controlled by the GameController. I think that the 3rd dog may have been in some Ad Hoc mode so was still able to receive the messages from the GameController. I set the "APMODE" in the wlanconf.txt file to "1" on all the UPenn dogs. I tried all sorts of troubleshooting but was not able to get more than one dog on the network at a time. *** 11/8/2006 I looked through the rUNSWift code trying to find where the C++ code calls Python and vice-versa. There's a file PyEmbed.cc that seems to do a lot of the "glue" work. I need to look more into which part of the code is receiving messages from sensors, etc. I'll start sifting through the "connect.cfg" file and also figure out what all those classes are. I tried to help Nalaka get up and running with the rUNSWift code. He can't seem to run some of the scripts. I think it may be because he has the wrong version of Cygwin. I found that I couldn't run some of the GermanTeam scripts with a newer version of Cygwin. I asked him to reinstall Cygwin. *** 11/9/2006 I read/skimmed the last couple chapters in Mike's Python book. It dealt with Python exntensions (Python code calling c/C++ code) and Python Embedding (C/C++ code calling Python). This confirmed my findings that the PyEmbed.cc file is the center of this "glue" code. *** 11/14/2006 I spent time perusing more of the OPEN-R SDK. I'm now looking into the actuatorControl module which seems to send/receive messages to the joints and LEDs using the OPEN-R OVirtualRobotComm.Effector service. *** 11/15/2006 I showed Nalaka how to reinstall cygwin with the correct binaries from a local drive. There still seems to be some problems with cygwin and/or some other dlls on his laptop. I spent time working on plugging in a fuzzy algorithm extension into WEKA. I had to peruse some WEKA code and change the way it read in the extensions. I also found that the fuzzy jar file was not usable by Java's JarURLConnection. I just re-jarred the file and that seemed to do the trick. *** 11/16/2006 The OPEN-R Level2ReferenceGuide shows the following OVirtualRobotComm services (that send and receive messages): -OVirtualRobotComm.Effector.OCommandVectorData.O This is a service that receives joint and LED commands. The receiving data structure is OCommandVectorData. You can reserve a shared memory for OCommandVectorData with OPEN-R::NewCommandVectorData(). After the output of the received OCommandVectorData is completed, a READY EVENT is sent. -OVirtualRobotComm.Sensor.OSensorFrameVectorData.S This is a service to send all of the sensor data available in a robot. The sending data structure is OSensorFrameVectorData. Four frames of data (32ms) is sent by one transmission. -OVirtualRobotComm.FbkImageSensor.OFbkImageVectorData.S This is a service to send the image data captured through the camera. The sending data structure is OFbkImageVectorData. Three sheets of YCrCb and a sheet of CDT are included in the image data. --- Note that the connect.cfg file shows that the actuatorControl module interfaces with the Effector service as stated on 11/14/2006. I'm exploring some of the actuatorControl module. I also started looking for the code that seeks the orange ball. I will talk more about that later. *** 11/28/2006 I didn't find out the message that is passed or the exact file that contains the code that deals with this. However, in the Python code (where most of the Behavior code exists) I found files pReady.py & pSet.py in the PyCode directory. These files are called from Behaviou.py: # Ready state - let me move to my correct position. if Global.state == Constant.READYSTATE or Debug.mustReady: pReady.readyMatchPlaying() hTeam.sendWirelessInfo() # Set state - I can't move my legs, but I can move head to look for # ball. elif Global.state == Constant.SETSTATE: pSet.DecideNextAction() hTeam.sendWirelessInfo() elif Global.state == Constant.FINISHEDSTATE: hTeam.sendWirelessInfo() else: profileFunc(Player.player.DecideNextAction) The last line will be called if Global.state -- Constant.PLAYINGSTATE. This probably calls the DecideNextAction in pGoalie.py & pForward.py. We should verify this. * I found this in the Abstract of north-5-subsampled.pdf: "...previously successful approaches to robot vision systems have focussed on colour recognition, classification and blobbing, which provide for relatively fast and simple object recognition algorithms. However, such methods require processing of every pixel in each camera frame, regardless of its information content, creating a high lower bound on processing time. In addition, colour-based methods respond poorly to variations in lighting conditions and are plagued with problems in distinguishing colour blobs representing valid objects from those caused by noise and background information. This report moves towards an alternative image processing system for robots based on minimal sampling of each frame. Interesting features are extracted from information-bearing regions of each image based on relationships between neighbouring pixels, and object recognition is performed over these features. This method has many advantages, including efficient implementation and a reduced dependency on finely tuned colour classifications. These lead to robustness to changes in lighting conditions and a much reduced calibration time compared with previous methods. Sub-sampling methods were successfully implemented for the UNSW/NICTA team rUNSWift, which placed third at the RoboCup1 Legged League2 World Championships in 2005." This leads me to believe that the codebase we chose from rUNSWift may not need color tables to be changed because of their approach to vision. Further investigation is needed. *** 11/29/2006 I spent time playing with the Indicator.py file. Since Indicator.py file implements the DecideNextAction() method, "Indicator" for the playerModule (1st) parameter to the robot/spip script that sets the player module, ip, team number, & player number for the dog. So, when the dog is in play mode (3rd tap to the head sensor) it will call the DecideNextAction() method in the Indicator.py file. The DecideNextAction() method calls "superDebug()" which called many methods in the file. I commented this out and called my own "smallDebug()" method to test some of the methods. Specifically, I "tinkered" with using the showHeadColor() method. I could only make the 2 lights on the dog's head light with the RGB_GREEN & RGB_YELLOW constants. The yellow looked light blue. I'll need to look into this. These head lights are supposed to indicate the dog's "role" because showHeadColor is called within the showRoleIndicator: if Global.myRole == Constant.SUPPORTER: showHeadColor(RGB_PURPLE) elif Global.myRole == Constant.ATTACKER: showHeadColor(RGB_YELLOW) elif Global.myRole == Constant.WINGER: showHeadColor(RGB_BLUE) elif Global.myRole == Constant.DEFENDER: showHeadColor(RGB_GREEN) elif Global.myRole == Constant.STRIKER: showHeadColor(RGB_WHITE) else: showHeadColor(RGB_NONE) I did notice that the showWirelessDownIndicator flashes all 3 back buttons in white one at a time. This along with the other LEDs that are used should be useful in debugging. *** 11/30/2006 I read part of the "RobocupThesis2005_weiming.pdf" thesis. It talks about Odometry. There are bits a pieces of useful information in each of the theses. I need to sit down one day and read them all. The "north05-subsampled.pdf" thesis I referenced on 11/28 talks about rUNSWift's alternative subsampling technique for vision. This information may come in useful for when we change the code to recognize the new goals (which just have a top & side "bars" instead of a solid back. I continued to work with the Indicator.py file. I found out why only the green and "yellow" (that looked like white) ear lights worked. There's a variable onlyLegalIndicators = True determines whether the framePostset() method allows "illegal" values for the ear lights or other settings for the finalValues[] that deals with the LEDs. I need to read the rules again to see if these values are actually illegal or not or if they're just not allowed by the rUNSWift code. When I changed the value of onlyLegalIndicators to False, all colors of the ear lights flashed in the testEarLights() method I created. I found that the BackRearWhite/Color and the BackFrontWhite/Color constants seem to be switched (at least by my interpretation of "front" and "rear". (I think "front" should be the button on the back nearest the dog's head yet it seems to refer to the button nearest the dog's tail.) I may swap the constants if I don't find any problems with doing so. I also tested changing values of finalValues[HeadColor] & finalValues[HeadWhite]. Setting finalValues[HeadColor] = LED2_ON makes the light near the top head sensor turn amber. Setting finalValues[HeadWhite] = LED2_ON makes the light near the top head sensor turn white. The ModeRed, ModeGreen, & ModeBlue constants that refer to finalValues[] together create the ear light colors and are used by showHeadColor(). I still need to figure out how the LED face patterns work. *** 12/5/2006 & 12/6/2006 I made calls to the showBlueEyes/showGreenEyes/showRedEye methods in Indicator.py. I found that showBlueEyes & showGreenEyes were "shut off" by a return statement near the top of the methods. I removed these return statements in order to see how the method behaves. It seems that the "eyes" differ in location depending on their color. The color and location is changed by the use of a LED3_MODE_B constant that can be bit or'ed with whatever is in the Led14 array position in finalValues[]. finalValues[Led14] = LED3_INTENSITY_MAX | LED3_MODE_B # produces blue eyes finalValues[Led14] = LED3_MODE_B # produces green eyes finalValues[Led14] = LED3_INTENSITY_MAX # produces red eyes finalValues[Led13] = LED3_INTENSITY_MAX # widens the eyes for red and blue eyes showGreenEyes() uses different Led constants: e.g. finalValues[Led1] = LED3_INTENSITY_MIN finalValues[Led2] = LED3_INTENSITY_MAX Originally showGreenEyes() used this: finalValues[Led14] |= LED3_MODE_B which bit or'ed LED3_MODE_B with whatever value was already in the array at Led14. This tended to vary the color so I changed it to an '=' instead of the '|='. --- Using the finalValues[] I found that I can move the dog's ears, mouth, and tail (although I only verified the last two). *** 12/7/2006 As I'm writing this I am testing the showBatteryStatus() method. It shows a white facial pattern something like this: WW WW = 100% W W WW = 80% W W W = 60% W W = 40% W = 20% W showBatteryStatus() uses a method called showFacePattern() which uses this array: FACE_LED_COLUMNS = [(Led7, Led3, Led1), (Led9, Led5), (Led12, Led11), (Led10, Led6), (Led8, Led4, Led2) ] Note that showBatteryStatus calls: if current >= 100: showFacePattern([1,1,1,1,1]) elif current >= 80: showFacePattern([0,1,1,1,1]) elif current >= 60: showFacePattern([0,1,1,1,0]) elif current >= 40: showFacePattern([0,0,1,1,0]) elif current >= 20: showFacePattern([0,0,1,0,0]) else: showFacePattern([0,0,0,0,0]) So a '1' in the first slot will turn on Led7, Led3, & Led1 and those represent the first "W" in the 100% facial pattern I described above. ---- I also cleaned all the dogs feet tonght! :)