*** 1/23/2007 I installed 30-day trial of the Webots simulator to see what it could do. It has a aibo_ers7_.wbt and aibo_ers7_soccer.wbt files that are given. When you open aibo_ers7.wbt you see a model of one white AIBO on a soccer field with a pink ball. There's also a window that shows what the AIBO robot sees. I started reading the Webots 5 User Guide. *** 1/24/2007 I spent time with Ryan showing him the www.openr.aibo.com website where one can download the OPEN-R SDK, the correct versions of gcc, cygwin, etc. I also pointed out the our logs directory, and the downloads I have there. I explained some things about the rUNSWift code based, how to compile it, etc. --- I played with the aibo_ers7_soccer.wbt Webot simulation. I found that you can double-click on a dog to bring up a control panel where you can move the dog's lets, ears, tail, etc. It seems that you can wirelessly control the robotic dogs by putting some remote control code on the AIBO. I still need to figure out if we can simulate the entire UNSW code. There's a tutorial section in the User Guide that I need to go through. *** 1/29/2007 I started reading about the rUNSWift vision module. The thesis is the north05-subsampled.pdf file located at http://www.cse.unsw.edu.au/~robocup/2005site/reports05/. It's very long! I'm hoping that after reading this that I will have a better understanding of UNSW's approach to vision. Maybe this will help determine why the robotic dogs cannot seem to localize themselves or find the ball. I will probably have to understand this in order have the dogs recognize the new soccer goals as well. *** 1/30/2007 I spent a short period of time with Shaun telling him about websites, the SDK, etc. --- Continued reading about rUNSWift's Vision module. The thesis refers to different vision techniques such as color segmentation, blobbing, and subsampling. UNSW has chose to use the subsampling technique. Instead of focusing on color which changes according to lighting conditions, subsampling focuses on the differences between colors in the environment. It has less dependency on lighting and cuts down on processing time by focusing only on "important" parts of the picture. Sub-sampling does not focus on the image in its entirety, it "makes intelligent estimates of the information content of regions in the image and samples those areas likely to be of importance." Where should images be sampled? Regions of the image close to the horizon (artificially calculated from the geometry of the robot's limbs) should be sampled with higher frequency than areas further from the horizon. "A scan-line is constructed from the center of the horizon line and perpendicular to it to the lower edge of the image. Scan lines are then constructed parallel to this first line on either side of it at a fixed spacing of 16 pixels; scan lines continue to be constructed at this fixed spacing until such lines lie entirely outside the image frame. Between each pair of these 'full' scan lines a parallel line segment is constructed from the horizon line with a fixed lnegth of 64 pixels. These 'half' scan lines are thus eight pixels from each of their neighboring full scan lines. Between each of these half scan lines and their adjacent full scan lines is a 'quarter' scan line with a fixed length of 48 pixels, spaced four pixels from the scan lines on either side. Finally, beginning 16 pixels below the horizon and doubling this gap for each line, scan lines are constructed parallel to the horizon line until such lines lie entirely below the image frame." *** 2/1/2007 & 2/4/2007 I finished reading the rUNSWift's Vision Module Thesis, north05-subsampled.pdf. It seems that rUNswIFT still uses some sort of color classification despite their use of sub-sampling and saying that they don't need to depend on color classification in the Theory section of the document. Color classification is performed at runtime using a lookup table. The table is approximately 2MB in size and it maps the seven most significant bits of Y, Cb, & Cr components of a pixel to one of 10 symbolic colors. "The table is constructed before run-time by a generalization from a number of hand-labelled images. Two approaches are used to generate this table: Ripple-Down-Rules classifier & a Simple Weighted Kernel Classifcation. For each a large number of images are captured to the PC from a robot via a wireless connection. %%%We need to figure out how to generate this table. This is most likely the reason the dogs cannot seem to localize themselves. *** 2/5/2007 I directed Ryan & Shaun to the openr.aibo.com website to download the open-r SDK and all needed development tools. I think Ryan & Shaun are both going to try to compile on the Linux side. --- I spoke to Dr. Challinger for a bit about color segmentation in order to understand vision better. --- I found a "colour" directory under rUNSWift's trunk/base directory. There is a colour/classify/cluster.txt file that looks suspiciously like a color table of sorts (Y,U,V,Class). I'm continuing to look into how to generate the needed color table. --- I took some time in the evening to email the AIBO team about the items we should be working on this semester. I also made a couple of assignments. *** 2/6/2007 I emailed Dr. Will Uther at UNSW. He is the advisor to several of the students who wrote theses on the soccer dogs. I'm hoping that they may have some documentation on the calibration of the dogs or the generation of the color table. I found an nnmc.cal file that is generated by the build. It is not quite 2MB. This file is made by combining a loosennmc.cal & tightnnmc.cal that are given in the codebase. I'm not sure how these files were generated. *** 2/7/2007 I spent today ensuring that the build works on Linux since Shaun & Ryan are using Linux. I found many of the Makefiles reference OPEN-R directories in all lowercase and that the directories when extracted (and even files) are in all uppercase. I corrected a handful of Makefiles to use uppercase. I also removed the mountms & umountms scripts from the scripts. Now everyone is required to have the Sony Memory Stick Reader mounted to /mnt/ms prior to running the scripts (os & ins). I found that we must ensure to umount /mnt/ms prior to removing the memory stick so that the cached data is flushed to the stick. That's probably why they had the mount & umount called in the scripts. However, not everyone's memory stick reader will be mounted from the same place (e.g. /dev/sda1 or /dev/sda2....). *** 2/8/2007 Shaun and I made sure all the scripts were running and I helped step him throuh some steps. He got the code onto the dogs and it ran as expected. *** 2/12/2007 I worked with James to make sure that we can access Subversion. I created a trunk under svn+ssh://turtle.ecst.csuchico.edu/var/svn/aibo/runswift containing the original runswift code. Then I created a branch under /var/svn/aibo/runswift/branches called spring2007. Here I checked in my modifications to code, scripts, Makefiles, etc. in order to make it compile. I also checked in my modification to Indicator.py file. --- I received emails from Andrew Million & Alex North from rUNSWift. Andrew pointed me to the 2003 report which is supposed to explain calibrtion. --- " Yes, it would keep trying to find the ball in play mode. If the ball already being placed in the field, then you could be right, it needs some calibration. If I remember correctly, we used RDR tool in the base/colour directory to calibrate the colours. On top of my head, steps: 1. Take a lot of photos with ball in it. (using the dogs of course... ) 2. Use the colour calibration tool (base/colour/ic ..) 3. Use the tool to manually calibrate the range of each colour. 4. copy the nmc to robot\cfg 5. make More detail on calibration, can be read in 2003 thesis document." --- Alex North, the author of the 2005 Vision Thesis about Sub-sampling, also emailed: --- "Everything you've said is right. To generate the colour table there are a number of tools under the base/ directory. The one we used for the competition is /trunk/base/colour/rc/ It loads images, lets you classify colour regions, and can save an nnmc.cal lookup table. You need to load a bunch of BFL image files into it. I think there might be a photo-taking behaviour file you can load onto the robot, which takes a photo when you touch its head. We usually got them remotely though. Run to program under trunk/base/robolink/ - it acts as a multiplexing gateway between applications on your machine and data providers on the robot. Run the tool in /trunk/base/subvision/ and instruct it to receive data from your local robolink. Then if I recall correctly you need to run SimpleRoboCommander, which has a button somewhere to instruct to robot to take a picture and send it back via robolink. I can't quite remember, but you may need to run trunk/base/client/ to help SimpleRoboCommander communicate with the robot. Phew! There's a lot of details I'm skipping or have forgotten - I haven't looked at the code for about 18 months. I'm sorry it's not more of a one-click operation. Under the pressure of the competition there wasn't a lot of motivation to make things easy to use if they were "easy enough"." --- I will try to start on this tomorrow. *** 2/13/2007 I finished updating the files checked into Subversion so it works on the Linux side. I also made some great aliases to make checking out code from Subversion easy as well as setting my RS_CLASSPATH (that rUNSWift scripts/makefiles now use). Got Shaun up and running on Subversion so he has files checked out from turtle now. See my logs/Paulene/mybashrc for useful aliases. I read some in the robot2003.pdf file that Andrew Million directed me to. It didn't have the "How-To" I was looking for. It still talked about calibration in a very vague way. I'll try to run the tools to see if they are self-explanatory, but I will probably have to contact Alex North. *** 2/14/2007 I had a hard time trying to follow the instructions for creating the color table sent to me by the Australia dudes. I need to understand what each program is intended to do, how to run it, and what order to run them in. Following is the email I sent back to Alex: --- "Hi Alex, Thanks for replying. I have some questions: What is the difference between ic & rc? Andrew Million pointed me to use ic and you told me to use rc. Are these the two approaches to table generation you refer to in your thesis? (RDR & Weighted Kernel Classifcation) Which one is which? Does ic/rc correct the chromatic distortion or is there yet something else I need to do? There are a lot of directories under base that I don't know what they're used for. What pieces do I really need to worry about? Are there any READMEs other than those in the codebase? I seem to be at a loss for where to start. The thesis papers, although interesting from a high level or theoretical point of view, do not give any how-to kind of instructions. Do you have to install the behavior file to gather *remote* pictures? I'm assuming that the behavior file is a Python file used as input to the spip script--is that the case? I've tried looking for it, but I can't find it. What would it be called? So, Andrew said I should take the nnmc.cal file that is the output of ic and stick it in the robot/cfg directory. What about the nnmc.cal file that is created during the build from the tightnnmc.cal & loosennmc.cal files? Should I be producing these files instead? If so, what different technique would I use to produce each of these? I looked at SimpleRoboCommander. It seems to be python code. The Makefile in the directory cd's into CPlaneClient to build, but there is no Makefile there. Are you speaking of this "client"? Or are you talking about base/client? I ran base/client to get the usage. I'm *really* confused now. What I really need is a quick README for the base directory that defines what each of the directories in base is. I also need some step-by-step instructions for producing this color table like "Run this program by typing this command, click on these things, run this program by typing this command,..." etc. This will allow me to run the programs in the correct order and tell me what I'm trying to do. I don't expect a huge document, just a README that allows new programmers for the project to get going. Could you do this for me? Or is there someone who could? In case you don't want to download the codebase and browse through it. Attached is a quick find on the 2005 codebase. Thanks, Paulene" --- Let's hope I hear back soon. *** 2/15/2007 I read and re-read the email I received from Alex North. We need to use the SubVision module to connect to robolink that connects to the dog. I spent the day trying to make the SubVision module compile. There was a file named TYPE_QMAKE_THEN_MAKE_TO_BUILD. I had to download some qt3 libraries to get qmake. Qmake creates a Makefile in the directory. When I typed 'make' there was bunch of errors dealing with a "DEBUG" variable. It seems qmake has defined DEBUG to be nothing. However, the code uses it as a boolean. Several files had a #define DEBUG 0 // or 1--one or more were commented out. All of these files included the same header file that contained a "static const bool" DEBUG variable as well. I ended up with a #define DEBUGGING 1 that I put in the header file, removed the bool variable and commented out the #define DEBUG's in the other cpp files. Eventually it compiled and Shaun and I started it up after we started robolink. By using the File->Connect menu item in SubVision with the default localhost:9000 it seemed to connect to robolink. We're getting closer to being able to retrieve pictures from the robotic dog. We just need to figure out how to run SimpleRoboCommander now. I'm having trouble removing files from one of the Sony memory sticks. The files appear to be locked. There is an unknown entity named "pos" which is supposed to be a directory but seems unrecognizeable for the file system. Is this memory stick done for? I'll see how it behaves for Windows. ***2/19/2007 Shaun told me that the ClientServer.py file started the SimpleRoboCommander app. In order to get it to work he said that he needed the Unix EOLs in the python files. So, I ran dos2unix over all the *.py files and checked them in. Running the ClientServer.py file did bring up the GUI, but we don't know how to use it. I couldn't find a button to tell the dog to snap a picture. Since I didn't hear back from Alex North, I forwarded my email to the 2005 rUNSWift email list: --- "Here's an email I recently sent to Alex. I haven't received a response yet. Now that I've used qmake to generate a Makefile for subvision, it builds. So, all of the programs that Alex has mentioned run now. But, I'm not sure how to run them together. I did the following: ./robolink (in base/robolink) ./SubVision (in base/subvision), then I use File->Connect to localhost:9000, then robolink seems to see the client ./ClientServer.py (in base/SimpleRoboCommander). The SimpleRoboCommander prompts me to listen on an ip and port. I'm not sure what to put here. Now where is the button to send the command to take a picture? Where/when do I run base/client? When I run ./client r (from base/client), SimpleRoboCommander says "New Client" 4 times. Is this all connected properly? Could you explain what each one of these programs is doing? Here are my remaining questions: *What is the difference between ic & rc? Andrew Million pointed me to use ic and you told me to use rc. Are these the two approaches to table generation you refer to in your thesis? (RDR & Weighted Kernel Classifcation) Which one is which? Does ic/rc correct the chromatic distortion or is there yet something else I need to do? *Do you have to install the behavior file to gather *remote* pictures? I'm assuming that the behavior file is a Python file used as input to the spip script--is that the case? I've tried looking for it, but I can't find it. What would it be called? *So, Andrew said I should take the nnmc.cal file that is the output of ic and stick it in the robot/cfg directory. What about the nnmc.cal file that is created during the build from the tightnnmc.cal & loosennmc.cal files? Should I be producing these files instead? If so, what different technique would I use to produce each of these? Thanks, Paulene" --- So, one of the memory sticks is "hosed". So, I reformatted it with a "mkfs -c -t vfat /dev/sda1". I copied all the files back on to it and started the robot up. Everything seems fine now. *** 2/20/2007 I received responses to my emails. I spent some time trying to correlate them (since I'm corresponding with one person from the 2005 code base and one from the 2006 code base). I'm going to start a new file for runswift correspondence, so I won't detail it here. But, here's what I ended up running today: base/robolink 192.168.1.114 bin/sendData 114 3 (3 is for RLINK_YUVPLANE, do I need anything else? Like 6 for RLINK_SUBVISION or something?) base/subvision/SubVision (Then I did File->Connect localhost,9000) After these commands SubVision started receiving data. From there I don't know what I'm supposed to do. The GUI is full of things I don't understand. I did, however, notice that I can load the .rlog file produced by a previous run of robolink & sendData. NOTE: 1) As Alex seemed to be implying, I don't think offvision in the 2005 codebase seems to work. I can't compile it due to some missing files. 2) There is no pPhotoTaker.py file in the codebase. I found base/colour/rlog2bfl. I ran it over the .rlog file produced by robolink and it produced *.BFL files. When I opened the directory full of *.BFL files from rc, I see photos. YAY! I must have done something right. I need to look at rc further to see if I have any questions about it. --- I sent an email to Shaun & Ryan to get an update on initial tasks. *** 2/21/2007 I looked at the rc tool today. The rc tool allows you to read in a directory full of *.BFL files. You can then choose an image and a color (Orange, Blue, XXXX, Yellow, Pink, Blue robot, Red robot, Green Field, Grey, White, Black), then click on pixels in the image that match the color you have chosen. After you have gone through and identified all the colors by choosing matching pixels in the image, you can click on the "Save NNMC" button to save your nnmc.cal file. You can then put your nnmc.cal file into the robot/cfg directory where the robot/ins script will copy it to the memory stick when run. Be aware that the nnmc.cal file may be overwritten by the build of robot directory or specifically robot/cfg directory (the tightnnmc.cal & loosennmc.cal files are merged during the build to create a default nnmc.cal file). So, keep a copy of it elsewhere that you can pop back into the cfg directory prior to running the robot/ins script. I set up a "mini" field on the table in the lab and brought out one of the field lights to brighten the field. This helped produce some brighter pictures to use for producing the nnmc.cal file. After I finished this, I loaded the new file onto one of the dogs and tried it. The dog still moved in circles, but it still could be lost due to the lack of beacons, and other landmarks. We'll be setting up the actual field this weekend to produce a better nnmc.cal file and try the dogs again. Hopefully, this will allow us to move on. ***2/22/2007 I worked with the rc program a little more. I tried to save an RDR xml file so that I could reload it later. However, when I try to load the file there's a great big java exception complaining about parsing the file. Bummer. I'm not sure that we really need to do this. But, I thought it would be nice to visually see what we configured for colors on a previous run. I also tried to see if I could hook up to multiple dogs at once. But, since robolink appears to try to use the same port every time, only one instance can be running at a time. But I can easily run robolink on one dog for a short time, then robolink on another dog. However, you must move the rlog file to a different directory and/or name so that the rlog file is not overwritten by the program. ***2/24/2007 We set up the soccer field today in room 254. We spent quite some time calibrating the dogs' vision by taking pictures through the dogs' cameras. We made sure to get pictures from different dogs from different angles in order to get all beacons, goals, dogs, the field and lines into the pictures. I gathered all the .rlog files from the robolink program and ran them through rlog2bfl to produce the *.BFL files that I loaded into the rc program. From the rc program I clicked around on the different pictures to classify the colors. Sometimes when you click certain pixels to classify them as a color, other pixels in some other part of the picture are also classified as that color when you don't want them to be. For instance, if you highlight most of the pixels on the blue goal to be "Blue", some pixels in the green field are also classified as blue because they have the same YUV value. Some of this "mis-classification" is all right and the code should compensate for it. However, I don't think you should over-do it. The ball is the one item that I did classify almost all pixels as "Orange"--except the white shine on it. Even though some of the pixels in the yellow goal and on the red dogs will be seen as "Orange", I think it is better that way. The code does check for some shape assumptions about the ball--that it must be somewhat round. I think the yellow on the beacons needs to be a bit brighter like the yellow goal is. The yellow on the beacons is quite light and looks white in the pictures taken by the dogs. We also found that the blue color on the dogs appears almost black. I thought maybe the *official* team uniforms might be better (they're certainly less shiny), but they seem even darker to the naked eye. With the first nnmc.cal calibration file put on all the dogs, we found that the dogs could find their way around on the field and no longer ran around in circles. YES!!!! We took a few more pictures and calibrated some more, then put this new calibration file on the blue dogs and left the old one on the red dogs-- except the red goalie who appeared to be having problems. The Blue dogs won the game (or the half, actually) 8 to 5. The new calibration file was made from additional pictures of the yellow beacons where I classified more (lighter) pixels as yellow. This appeared to help the red goalie and the blue dogs find their way around better. ***2/27/2007 I spent today finishing reading about branches, tags, and merging in Subversion. This should be useful later. Tomorrow I will work on finding the Goal Recognition code in the Vision module. ***2/28/2007 I spent some time looking over robot/vision directory. Through some grepping I found SubVision.cc & SubObject.cc. These seem to be some of the main files I'll probably be modifying in order to recognize the new goals & beacons. SubVision.cc appears to do the "feature identification" and SubObject.cc appears to do the "object recognition" referred to in the north05_subsampled.pdf thesis written by Alex North. SubVision.cc creates the scanlines and creates the initial "VisualFeature" objects that are used and filtered by SubObject.cc. ***3/5/2007-3/8/2007 I spent the whole week still trying to understand the vision module. SubVision Vision->VisualCortex-[ SubObject -> SanityChecks VisualCortex calls subvision.sampleImage() which creates scan lines (vertical below the horizon & horizontal above the horizon to find the goals and beacons), then calls testPixel to create the VisualFeatures. VisualFeature is essentially a location of a pixel and its associated type (color). The VisualFeature that is kept in a list is one with the greatest ddy+ddu+ddv (difference in color? from some previous pixel). Next, VisualCortex calls subobject.findVisualNonBallObjects() & subobject.findVisualBallObject(). findVisualNonBallObjects() calls functions such as findBeacons() & findGoals(). I want to focus on findGoals() and the functions it calls such as groupFeatures() & SanityChecks::checkGoalSanity() to make sure I understand how features are recognized as goals. I know that checkGoalSanity() checks the aspect ratio to ensure that the feature is of some "sane" shape. ----- I've also been helping Shaun understand the Behavior code. Vision->Behaviours->pythonBehaviours.DecideNextAction()->PyBehaviours::processFrame() which calls the Python code Behaviou.py. Behaviou.py decides whether to call pReady.py, pSet.py, or Player.py. (Note that Player.py calls the correct pForward.py/pGoalie.py depending on what was passed in the spip script.) ***3/13/2007 findGoals() (in SubObject.cc) uses groupFeatures() to group VisualFeatures that can be bisected by a vertical line (from the horizontal?) that are of the same type (color). According to my understanding of groupFeatures(), it should group all of the portions of the scanlines that are associated with a goal into one group. After that, findGoals() will find the width and height of the goal according to the greatest width of a feature and the tallest height of a line through a blob given by searchLine() at the middle of the feature ((x+endx)/2). The height and width are then used in SantiyChecks::checkGoalSanity() where it will check the actual aspect ratio against a desired aspect ratio. If the aspect ratio is within tolerance, the position of the goal (mid-point) is above the horizon, and the goal is not "floating" the goal is interpretted as "sane". All of this may mean that the new goals may be recognizable without any code changes. I would like to try the existing code with the new soccer goals to see how well it works. I would also like to attach SubVision to one of the dogs to see the visual features that are being seen by the dog. I should also telnet to the dog to see what messages are being output. Tomorrow I need to look at the "Gap" code inside findGoals() to see what it is. ***3/14/2007 The "gap" code inside SubObject::findGoals() appears to find the largest areas of the goal to the left and right that are accessible. These gaps are used by the VisionLink_getHeadingToBestGap() method inside PyEmbed.cc. The PyEmbed method is called indirectly by scGrabDribble.py, sGrabDribble.py, & sGrabTurnKick.py in the PyCode directory. Tomorrow I want to look at this year's goal dimensions versus the old goals to see if we should changed the expected dimensions in the code. ***3/15/2007 The old goal dimensions were (HxWxD): 300mm x 812mm x 300mm. The new goal dimensions are: 300mm x 912mm x 300mm. The additional 100mm in width is due to the cylindrical piping on each side (each pipe is 100mm in diameter, but only 50mm on each side will extend out from the wood panneling that rounds around the inside of the goal. I may have to change the GOAL_WIDTH constant in order to accommodate this. I started looking at the findBeacons() method in SubObject.cc. I should be able to change this to recognize the new beacons. There may have to be some extensive changes to the code in order to use the new beacons since there are sets of 4 constants used in many files. I think I'll create another branch in subversion in order to carry out this work. That way I can still work with our current changes and the new changes on my machine. **03/26/2007 - 03/27/2007 I edited the files listed above as well as others in order to support 2 beacons with changed coloring. I also added ChicoFieldDef.h to change the position of the beacons on the field. We may have to change the Goals dimensions slightly to accommodate the "poles" on either side. A couple of the main things I changed in SubObject.cc were pruneFeatures() and classifyBeacon(). pruneFeatures() separates features into separate lists like beaconFeatures, goalFeatures, wallFeatures, fieldLineFeatures, etc. It used to search for features of type VF_PINK and put them in the beaconFeatures list. However, there are no features of type VF_PINK anymore. Now I place all features of type VF_BLUE in both beaconFeatures and goalFeatures. The VF_BLUE VisualFeatures that were potentially beacon lines were always put in the goalFeatures list to be filtered out later. However, now they are also put into the beaconFeatures list as well as potential blue goal features. Sometime after findVisualNonBallObjects() calls pruneFeatures() it calls findBeacons() which in turn calls classifyBeacon(). classifyBeacon() determines the high and low points of the grouped VisualFeatures (which used to be pink). Then it would look below the pink, then above the pink for either yellow or blue pixels within a specified radius. Now the original grouped features are blue and the method looks for yellow first below then above the blue. If it doesn't find so many yellow pixels within a specified radius it throws out the group of features since it can't be a beacon. Otherwise, it sets the appropriate beacon variables accordingly. Many of the other files I edited had to change because they depended on some "pink" beacon variable or having four beacons as parts of arrays, etc. ***03/28/2007 I checked into the OSAKA #define that was in the OsakaFieldDef.h that was being used. It's only used in a couple of spots and I think we should keep it for now just in case. I left it in ChicoFieldDef.h. I spent the rest of the day troubleshooting the rc tool. There's Load RDR & Save RDR buttons on the side that are used to load and save color configurations that you've created. I had tried this before and received a XML ParseException when loading a file that I had saved. I thought it would save a lot of time if color configuration if we could start with our last saved one. After browsing the code I found that the save does not output in XML format (even though the fileChooser dialog defaults to a XML filter. Sure enough, when I checked my "xml" file I found it was binary. However, the method that does the load checks for a .xml file extension and then reads it in as if it were xml. With all other file extensions it assumes the binary format. It seems that they used to use an xml file, but now they output it in another format. So, if I save the file with another file extension such as ".colour", I can load it with no problem. Then I have my previous color configuration for my current set of BFL image files. ***03/29/2007 Yesterday, Shaun found a file called hTestLandmark.py in the PyCode directory. It looks like it displays different facial LEDs depending on what landmarks have been identified in the environment. This should be useful in testing the vision/localization changes made for the new 2007 beacons. In the file it used a method on the visual object called getConfidence(). The file determined whether to display an LED change for a landmark if getConfidence()>0. Shaun asked me about this and I couldn't quite remember what that was. When I traced it to the vision code I found it was referring to the cf variable in the VisualObject class. This variable is the count of features (portions of scanlines of a certain color) grouped as a single VisualObject (goal/beacon/ball). If cf==0 then that VisualObject was not found in the image. I spent some more time today figuring out SubVesion's svn log command in order to better find my changes on the several branches of code we have (trunk/spring2007/beacons2007). BTW, these are all the files changed so far for the beacons2007 branch: ***03/31/2007 We had the field set up today. For some reason the old color table didn't do well this time around. We created a new one, but the dogs still seem to be having a hard time. I found that the dogs as well as my laptop were losing connection to the network. This probably caused the dogs some trouble with communication. Next time we'll bring the access point with us to the field. We had other "technical difficulties" as well. We replaced two burnt out light bulbs where we had to shut off the lights to let them cool down. We also had to shut them off when we found the rubber piece in the lamp had fallen in front of the light and started to burn. Aside from the code (without the beacon changes) seemed to recognize the new goals. However, the code with the beacons changes could no longer recognize the blue goal-- it did recognize the new beacons (although not very well). We found this out by using hTestLandmark.py for our Player (input to robot/spip script). After a long, hot Saturday in the building, I took the code home and found the problem with the recognition of the blue goal. I had added the VF_BLUE VisualFeatures to both the beaconsFeature & goalFeatures lists. However, during the classifying of the beacons (which happens prior to classifying the goals), the feature that was actually a goal was tossed out of the beacon list (which is appropriate) *and* marked the type as VF_NONE (uh oh). The VF_NONE made the findGoals() method think that the feature was VF_YELLOW and when it looked around for other yellow pixels it couldn't find any. This through off the hole findGoals() method. I also found VF_BLUE VisualFeatures were not created unless the # of blue pixels exceeded TH_GOAL_BLUE pixels (12) while the old beacon code would create VF_PINK VisualFeatures when the number of pink pixels exceeded TH_BEACON_PINK (5). I changed it to use TH_BEACON_BLUE (4) which should help in recognizing the beacons. I also decided to change the TH_GOAL_* thresholds to 10 vs. 12. ***04/02/2007 I set up a small test field just outside the lab with 3 small rolls of the green carpet and swapping out the goals. I added to the color table to allow for the test lighting, then I used the hTestLandmark.py file and found that the code now recognizes the blue goal. YAY! I made a SubVersion tag, prebeacons2007, which represents the spring20007 branch prior to merging my beacon changes from the beacons2007 branch. I then merged the beacons2007 branch to spring2007. I downloaded the 2006 GameController--there doesn't appear to be a 2007 version yet. I integrated 2006 GameController code with our codebase in the spring2007 branch. I tested it (after some problems due to the RoboCupDataStruct.h difference) and it seems to work. --- UH OH! I'm missing some log entries here.... --- ***04/07/2007 We set up the soccer field again in Room 254 to test my changes. The red team seemed to localize fine in the "Ready" state. However, the blue team would turn to the right corner near their goal and keep running into the wall. When in "Play" mode the blue dogs would chase the ball if it caught sight of it; however, they would resume running toward the right wall otherwise. Shaun ran the SubVision tool to see the features and objects generated by the vision module one a particular dog. It had not been changed to accommodate the fewer number of beacons that are now different colors as well. I went home to find out why the blue dogs might not be able to localize whereas the red ones could. I found this in the original robot/vision/gps.cc file: // Possible coordinates for the vobs static const long coordRedBased[6][2] = { {FIELD_WIDTH / 2, FIELD_LENGTH}, //far goal {FIELD_WIDTH / 2, 0}, //close goal {BEACON_LEFT_X, BEACON_FAR_Y}, //far left beacon {BEACON_RIGHT_X, BEACON_FAR_Y}, //far right beacon {BEACON_LEFT_X, BEACON_CLOSE_Y}, //close left beacon {BEACON_RIGHT_X, BEACON_CLOSE_Y} //close right beacon }; static const long coordBlueBased[6][2] = { {FIELD_WIDTH / 2, 0}, //close goal {FIELD_WIDTH / 2, FIELD_LENGTH}, //far goal {BEACON_RIGHT_X, BEACON_CLOSE_Y}, //close right beacon {BEACON_LEFT_X, BEACON_CLOSE_Y}, //close left beacon {BEACON_RIGHT_X, BEACON_FAR_Y}, //far right beacon {BEACON_LEFT_X, BEACON_FAR_Y}, //far left beacon }; My changes showed the following: // Possible coordinates for the vobs static const long coordRedBased[4][2] = { {FIELD_WIDTH / 2, FIELD_LENGTH}, //far goal {FIELD_WIDTH / 2, 0}, //close goal {BEACON_LEFT_X, BEACON_Y}, //left beacon {BEACON_RIGHT_X, BEACON_Y} //right beacon }; static const long coordBlueBased[4][2] = { {FIELD_WIDTH / 2, 0}, //close goal {FIELD_WIDTH / 2, FIELD_LENGTH}, //far goal {BEACON_LEFT_X, BEACON_Y}, //left beacon {BEACON_RIGHT_X, BEACON_Y} //right beacon }; Note that the original code lists the left beacon then right beacon for the red dog and lists the right beacon then left beacon for the blue dog. My changes did left beacon then right beacon in both the red and blue dog coordinates. I think this would really screw up the blue dog localization. I would think this would cause the blue dogs to try to keep the right beacon on its left side (if I understand this correctly) which is exactly what it was trying to do. We'll have to test this new fix. I also worked on changing the SubVision tool to only expect 2 beacons. I had to do some GUI editing and some other code changes for this. ***04/09/2007 Today I worked on testing my changes to SubVision. I set up a little test field in the lab to use the SubVision module (I used bin/sendData to get SubVision and SubObject messages through robolink). The beacons were easily recognized (after a new test color table) and displayed with the correct colored lines (Blue-Yellow & Yellow-Blue) in the tool. ***04/12/2007 We moved the soccer field over to Yolo Rm 116 ***04/13/2007 Set up the soccer field in Yolo. Shaun and I put together two new lights. We spent time setting up a new color table for the new lighting in Yolo. The dogs still don't seem to be localizing correctly. Even the red ones which seem to be OK last time were having trouble. The goalies don't stay within the goals and the forwards are all over the place. Shaun had to leave for class and Ryan soon after. So, we had to pack up. I can't debug the localization code without the field being set up. However, the setup and tear-down time doesn't leave us with much time to debug. Hopefully we can set up Thursday evening this week and debug on Friday & maybe Saturday if someone else can come in. I spent several hours after tear-down looking through the code that I changed for the new beacons. So far, I haven't found anything. ***04/14/2007 I poured through the vision code again looking for something that could cause these localization problems. I did find one problem. It seems that the YellowBlue dist2 & dist3 variables were not being set. This led to the head & elev variables to not be set either. I'm hoping this is the localization problem I've been looking for. ***04/17/2007 Checked in bug fix and looked through the vision code again. ***04/21/2007 Shaun & I set up the field in Yolo again. We were prepared to do some debugging but found that my bug fix seemed to have resolved the localization issues we saw last week. Shaun took some footage of the dogs as they played. I hope to get some pictures from these for my Master's paper. ***04/23/2007 Wrote the rUNSWift section of the Review of Literature in my paper. ***04/24/2007 Made to more SubVersion tags: runswift2005 & postbeacons2007. The runswift2005 tag is the original runswift 2005 code before any script or code changes. This is currently what is on trunk. The postbeacons2007 tag is a copy of the spring2007 branch after all of the beacon changes. I started writing the Methodology section of my paper. I helped Shaun pull the spring2007 branch in Subversion onto his new laptop.