Our screencast is posted here

Links to a few other videos we’ve made:

Human controls

Another demo

Playing a game against last term’s team

Positive: Finally, I can experience working on a real, fully distributed team. Also, I learn a lot of technical stuff from this course. From programming in python to machine learning algorithms. I am also grateful to learn from my colleagues as this is more practical than learning from textbooks.

Negative: I couldn’t contribute to the team as much as I want to. There are various reasons for this but most notably is due to the complexity and difficulty of the project. As time goes by, I discover more stuff that can’t be done than stuff that can be done. There is certainly a way to fix it but given the fact that we are expected to work ~10 hours per week, we would end up fixing stuff rather than achieving our goals. Thus, sometimes hacking is the most appropriate (but not the best) way to do it. If I would do it again in the future, it would be very nice to have someone that is knowledgeable to tell us what could possibly be done by 50 hours of work per week over four months. Unfortunately, it is very hard to find such person in any project.

For the most part we are all trying to wrap things up. Here’s how we plan to divide the final work load.

Yulia + Ioana: Look into fixing coordinate system.

Chani: Will put together a skeleton of the document.

Patrik: Will write up an overview of the source code by Tuesday.

Alex: Plans to finish his passing improvements and contribute a write up of why we choose the python code.

Everybody: Contribute to the document and consider tweaks to improve overall performance.

Patrik

We had our weekly meeting yesterday (Nov 29th ‘09). The minutes and transcript are available here (http://chani.ca/robocup/minutes/nov29.txt).

Patrik

I worked on RoboCup and I have to say it didn’t turn out to be what I expected in the beginning. But I really enjoyed it despite the problems we had (just like any other team this term).

There isn’t a whole lot of bad things I can say about the csc494 experience. We pretty much lost that month before the Code Sprint because we couldn’t get an access to the repository. Also it took me personally few weeks after the Code Sprint to actually understand what is it that we were working on and how to approach it. It would have been nice to have a little more guidance, but on the other hand it was cool to be able to set our own priorities too.

Good thing, is that despite being geographically dispersed, my team did a pretty good job communicating with each other.

Overall, I think I got an invaluable experience working on RoboCup. It’s one of those things that look sort of easy on paper  but are overwhelmingly complex when you start implementing them. It also taught me not to be too optimistic when making plans and not to assume correctness of the code that wasn’t my own.

We had our meeting on Sunday, November 22. Here is what the team had been up to:

Alex

- worked on passing, now it takes into account players from the opposit team

- it is hard to make 100% accurate passing because of the noise added to the measurements

Next task:

- work on interception as it is related to passing

Chani

- fixed code so that now players are using data from the current tick

- fixed a bug in the debug ui

Next task:

- continue debugging

Ioana

- worked on dribbling

- found bug that causes a player to be stuck near the ball not making any actions

possible reason is that position of the player and the ball is not update properly

Next task:

- continue working on dribbling

Yulia

- rewrote chunk of code responsible for parsing the s-expressions from the server

- slightly improved the accuracy of statistics computed from the server data

but it seems that there is not much we can do to make it better because of the

server restrictions

Next task:

- continue debugging

Patrik

- did a merge of code from the dt branch into trunk

Next task:

- debugging kick/dribbling

Being a part of the Robocup UCOSP project has been an interesting experience.

First, I’ll discusses some of the issues with this project. It’s not actually an open source project, and it’s not really under development by anyone other then my group members. This is an issue because we didn’t really get to experience that side of an open source project (ie. being part of a larger picture and lending a hand). The code we decided to use as a base turned out to be worse then we expected which caused use to have to perform alot of maintenance work instead of adding features or extending the team capabilities. Also, the size of the source tree is actually fairly small which has caused us problems, basically it causes most of the things we do to affect everybody in the group hence greatly slowing down development.

I think it would have been interesting to see what would have happened if we decided to start from scratch and develop a client in C++ (which was an option to us because of the very large amount of freedom we were given). Arguably it would have been worse wrt to everybody depending on each other but at the same time it would have been an experience of the birth of a project.

Interestingly, all of the bad points I’ve made are also the good points. They’ve really taught me how to think about projects and that things are not always going to go as planned. It would have been nice to have more guidance but at the same time it’s nice to have been given the freedom to make decisions for ourselves and learn from the outcomes.

the good: Working with a good team. We’ve all had those projects where half the team is asleep or incapable of communicating or just doesn’t do their work. This was one of those rare group projects where I got to be in a group of students who *wanted* to be there. it’s something I’m more used to in the free software world but not in school.

the bad: The chaos. Having our team drop to 5 people threw off a lot of the plans we’d made at the sprint. The codebase wasn’t at all what we thought it was, so we spent more time fixing things than writing new things, which threw off the rest of our plans. Our teacher is on sabbatical, so the TA gets all our questions. I’m still not quite sure what we actually accomplished…

ThumbUp: Having meetings every week and posting status reports helped keep us on track.

ThumbDown: I think it would be good to have more variety in projects, in particular some that are less development-oriented and involve more research

alex:
-has been trying to improve passing by having the kicker shout out where the ball is going, but the other players don’t always hear it
-will try other ways to improve passing

chani:
-implemented ball and player decay
-found out that the code for updating object positions was never being called and fixed that
-is working on vision optimization
-improved the debug viewer a bit more
-may also experiment with changing minimum-confidence values

ioana:
-found a passing bug, and is looking into interception problems
-was trying to get the new human controller to work, no luck
-is working on ball interception

patrik:
-was working on merging all the branch stuff into trunk
-hardware issues corrupted all his work, so he has to redo it

yulia:
-found a problem with vision – only the first two flags are being used to determine position
-was going to fix it but ended up in hospital instead
-wrote a small gui for starting teams and server
-started modifying the on_see function
-rewrote sexpparser and made it faster

Minutes for Robocup’s Nov. 15th meeting

The minutes from this week’s Robocup meeting can be found here

Alex:

Status:
- submitted a patch to the robocup_dt branch that makes server parameters no longer hardcoded but instead they can be read from the server messages

Tasks for this week:
- finish up work on server parameters
- work on passing

Roadblocks:
-none

Chani:

Status:
- was away at a conference
- committed FindBall action

Tasks for this week:
- implement compensating for ball decay today
- work on vision timing optimzation.

Roadblocks:
- none

Patrick:

Status:
- looked into adding preemptive actions
- also wrote a FindBall action, that was replaced by Chani’s method

Tasks for this week:
- merge changes in the dt branch into trunck

Roadblocks:
- it would be helpful to get the wxpython human controls working

Yulia:

Status:
- has been working on fixing bugs discovered while working on the human controls
- fixed body turning issue

Tasks for this week:
- continue looking for bugs
- working on dribbling and kicking

Roadblocks:
-none

Ioana

Status:
- did some more work on the neck turning and looked into interception

Tasks for this week:
- look for more bugs related to the world view

Roadblocks:
- getting the wxpython human controls working would help with testing

Ioana

Status:

- did some reading on DT
- wrote a function that computes the last time a slice was seen (for
neck rotation)

Next steps:
- With Yulia, looking at the solution to body_angle bug

Roadblock:
None

Alex

Status:
- Looking at ways to improve passing

Next steps:
- Reading server parameters at the beginning of the game instead of hardcoding them.
- Improving passing
Roadblock:
None

Yulia

Status:
- Working on enhanced human controller

Next steps:
-

Roadblock:
- Bugs in body_angle

Patrik

Status:
- – Trying to figure out how to change role and actions to benefit from
multi-tick actions …
- – Commented role.py and gained an understanding of how all actions are
taken.

Next Steps:
- – Try to change role’s decisions to be based on multi-tick actions.

Roadblock:
None

Available on:

http://www.sfu.ca/~ann5/ucosp/meeting-minutes-nov1st.txt

We had an extra meeting on Thursday October the 29th to finalize the marking scheme.

The results of the meeting can be found in the blog, the minutes can be found here.

Also note that most of our minutes have now been uploaded to one location at http://chani.ccdevnet.org/robocup/minutes/.

Patrik

Team Grade: 40%

Performance of soccer team – 10%

• Fails to beat original team – 0/10
• Wins occasionally – 4/10
• Consistently wins by narrow margin – 8/10
• Consistently wins by large margin – 10/10

Report – 10%

Written report explaining everything that was accomplished, remaining problems, TODO for people who might be working with our code. Mark should reflect completeness, justifications and clarity of writing.

Documentation – 10%

Comments in code and design document.

Screencast Demo – 10%

Demo on YouTube or similar service showing a client running.

Individual Grades: 60%

• Participation – 10%
• Testing – 10%
• Completion of Tasks (Code Sprint, Individual Tasks) – 40%

Participation – 10%

• Writing requirements: blog posts, minutes, etc.
• Meeting attendance, communication skills, etc.
• Peer evaluations

Each team member had some tasks assigned. For this project it was hard to find completely non-overlapping problems for each member to work on, also tasks got reassigned occasionally for various reasons. Our individual grading schemes are taking that into account.

Testing/Performance – 10%

Note: RoboCup is a real-time running application, so for most of the functions it is impossible to create Unit tests. We use Debug UI and Human Controlled player to evaluate performance of the client.

Testing for people working on incorporating Machine Learning (ML) algorithms for high-level decision-making is a standard procedure which involves creating a test dataset and using it to assess how well the trained model generalizes to new data.

Tasks from code sprint weekend – 10%

• Ioana/Chani – Debug UI
• Patrik/Yulia – Human Controlled Player ver.1
• Alex – Java Monitor

Individual tasks – 30%

These are projects each person has been working on since Code Sprint. Since we all focused on different tasks, individual grading schemes reflect the amount of effort put into particular area.

Chani

• Basic Actions (-improvements to basic actions: kicking, dashing, turning, etc) – 15%
• Complex Actions (developing multi-tick actions, that are based on the basic actions and allow for more complex behaviour : dashing to position, following the ball, finding the ball when it hasn’t been seen for a while, etc) – 15%

Ioana

• Sight Improvements (integration of better vision algorithm into the complex actions)  - 15%
• ML (using Decision Trees (DT) or Neural Networks (NN) for better decision-making)- 15%

Alex

• ML (experiments with various parameters for DTs and bugfixes to parser) – 15%
• Actions (debugging and improving basic actions and multi-tick actions, in particular better passing) – 15%

Yulia

• ML testing and experiments  (creating dataset for evaluation of ML algorithm’s performance, various experiments with different training data and parameters) – 15%
• ML infrastructure  (parser for server logs, Human Client ver. 2, script to feed data to ML algorithm) – 15%

Patrik

• Basic actions  (debugging and improving algorithms for basic actions : kicking, turning, seeing, etc) – 15%
• Complex actions  (multi-tick actions, that are composed of basic actions and enable more complex behaviour: interception, dribbling to a position, chasing the ball, etc) – 15%

Available on:

http://www.sfu.ca/~ann5/ucosp/meeting-minutes-oct25th.txt

Here’s a list of tools I cast essential for carrying out my day-to-day business or I find otherwise useful.

Hardware (in no particular order)

• My primary workstation is a HP Pavillion Slimline, a pretty much standard, off-the-shelf PC on which I installed Ubuntu Linux. The hardware works reasonable well under Linux, but at some point I wish hardware vendors would just offer some models which work seamlessly with any major OS. Anyhow, the desktop has 3 GB of RAM and 500 GB hard disk. Nothing really special, it does it’s job and is about a year old, now. It is complemented by a 21” Dell LCD monitor and the other usual peripherals. By the way, once you’ve used laptops for your daily work for so long that you don’t even realize how small your screen actually is, you will appreciate the decently sized monitor of your new desktop.
• Other than my desktop computer, I use an Asus eeePC netbook when traveling or at my office at work or at university and sometimes my old Toshiba laptop I run Debian on. The netbook has very decent Linux compatible hardware. Mainly because it came with some Linux preinstalled – I guess is was some weird Xandros. That wasn’t quite it for my netbook – I found it very limiting – so I installed Ubuntu on it using the array.org custom kernel and the netbook remix software package. This works reasonable well for me.

Software (in no particular order)

• Linux (and the various standard *NIX tools): I like open-source and I like to have the opportunity to debug my OS, so I’m using Linux (Debian and Ubuntu) for the most part. I found it frustrating at times when I was a Windows user and something stopped working from one day to the next. Although it was mostly me why things broke, I still had no reasonable way of undoing/fixing things. Well, at least not nearly as nicely as I can fix and analyze things on my Linux boxes. My mind wanders…
• Gnome Terminal: Bash to be precise. I’m using Bash on a daily basis and I don’t want to live without it anymore. It just helps getting your work done.
• Screen: A quite handy tool for multiplying your screen when working remotely on a machine via SSH.
• Mozilla Firefox: The first thing I’m starting once logged on to my computer is a Web browser. No matter if I’m debugging some CSS or asynchronous HTTP request or if I’m just reading my favorite paper, Firefox is the tool of choice.
• Firebug: Number 1 Web developer tool. I haven’t seen a better tool, yet.
• Ad-block Plus: The online world is just not bearable without it.
• It’s all text!: This one is also a quite handy add-on if you were to write text/code in HTML textareas a lot. By using It’s all text! you can load the content of any textarea into your favorite text editor (GVIM in my case), edit it and save it back into the appropriate textarea of the Web page.
• Vmplayer and qemu: These tools are just nice for the occasional boot into a clean Linux sandbox or testing some IE stuff on Windows. I use qemu to create the bare vmdk disks and use vmplayer to play them. VirtualBox is also a nice alternative.
• Eclipse (with RadRails, and other plugins): When doing some programming in Java, Python, Rails or C I use Eclipse for the most part augmented with quite a few VIM here and there.
• VIM: For writing Latex, BASH scripts, code  or for any other use of plain text processing, VIM is my tool of choice.
• XChat: My preferred X IRC client
• Evolution: A quite reasonable choice for doing all my email work. I chose Evolution, since it has a calendar integrated, but I’m not sure if Mozilla Thunderbird with Google Calendar wouldn’t work quite as well.
• Latex: Either for writing articles, assignments, theses. It’s simply a nice layout.
• Inkscape: Sometimes when there some vector drawings to create (such as the MarkUs logo )
• GIMP: For my very basic image manipulation needs.
• OpenOffice.org: For the occasional word processing or spreadsheeting.

I think these are (most of) my all-time-favorite tools. What are you using? What do you find helpful?

Here are some links what other people wrote about this topic: Mike Gunderloy and 1, 2, 3, 4, 5, 6, 7, 8, 9, and counting…

[Erik] and [Heni] have been using soccer as a way to improve code development techniques in robotics. Their soccer playing robots won first prize in the development competition at the 2007 RoboCup competition. They are using a teaching method they call Kinesthetic Bootstrapping to program the motions of the Bioloid robotic platform. The robots are moved by hand and those motions are recorded twenty times per second. The recorded data is then optimized in software and ready for playback in the robot.

After the break you’ll see a video of the robots playing soccer against each other. They receive commands from a computer via zig-bee with Nintendo Wii remotes as the user interface. That’s all fine and dandy, but perhaps you should try your own hand at a game. [Erik] and [Heni] developed a web interface that allows you to control the bots over the internet. We tried it out yesterday and had quite a bit of fun. We set the video stream to “Spectator” and “Jpeg Server Push” to get an image. You’ll have to wait until next week to play because the bots need someone to pick then up when they fall over. Live play is scheduled for Mondays and Wednesdays from 4-6pm GMT+2. That should give you plenty of time to program your Arduino to say “Gooooooooooaaaaaaaaaaaaaalllllllllll!!!” when you score.

[Thanks Richard]

Alex

Status:
- Tried to tweak to Java client to produce data file for Decision Tree. However, it was cancelled since we might not need it due to Yulia’s work to parse server log file.
- Training a goalie with the human controller to produce a convincing data file.

Next tasks:
- Testing Yulia’s log parser.
- Finding the right parameters to build Decision Tree.

Roadblocks:
- It is very difficult to get a high-quality of training data for building a good Decision Tree. Training a goalie properly with the human controller is very hard as we can’t move it as fast as we want.

Yulia

Status:
- Finished logparser for .rcg and .rcl log files. Now it extracts all attributes that user wants and dumps them all into .data file that can immediately be used for c4.5
- Made some progress on compiling the human controller

Next Tasks:
-more work on decision trees

Roadblocks:
-None

Chani and Patrick

Status:
- Worked on adding meta-actions: the action class can support multi-tick actions now

Next tasks:
- start implementing some of the actions in the Actions class

Roadblocks:
- None

Ioana

Status:
- Made some changes to the debug gui
- Looked into the neckrotator algorithm used by the Java client

Next task:
- Start implementing neck rotator
- Look into vison quality mechanism that Chani mentioned

Roadblocks:
-None

Summary of our weekly meeting and log from IRC channel #robocup.

Ioana

Status:

• Working on the debug GUI

Next tasks:

• When the ball is lost during dribbling, look towards where it was instead of spinning wildly.

Roadblocks:

• None

Chani:

Status:

• Have been busy with other course assignments

Next Tasks:

• Make multi-tick actions possible instead of always choosing an action from scratch every tick (which should make Ioana’s next task easier too).

Roadblocks:

• None

Patrick

Status:

• Finish up his human-client code.

Next Tasks:

• Helping Chani with her next task (make multi-tick actions possible instead of always choosing an action from scratch every tick).

Roadblocks:

• None

Yulia:

Status:

• Implementing a prototype of Goalie Decision Tree on the current code.

Next task:

• Trying to tweak server log files to get “free” training data

Roadblocks:

• None

Alex

Status

• Researching about Decision Tree and learning Yulia’s prototype of Goalie Decision Tree.

Next tasks:

• Experimenting with a lot of games to determine the appropriate attributes to build Decision Tree.

Roadblocks:

• None

Here is the meeting minutes for Robocup team on Oct 3rd, 2009.

http://www.sfu.ca/~ann5/meeting-minutes-oct3rd.txt

Well, saturday night was fun. We all went out to a chinese restaurant and had lots of yummy food. Then some of us went back to the hotel and played cards for a while. I learnt a new game, but I have no idea how to spell it.

Sunday was the last day – checked out of the hotel, did a little hacking, and we had a post-mortem meeting with all the students. I got lost in my laptop after that, plus my mind was not liking the lack of sleep, so I never got around to having lunch… oops. There was pizza at the airport, at least. Our group divided up again, into two groups – for the rest of the semester we’ll be working on different features for the robocup client, competing to see which improvements are more helpful, then merging them into trunk (oh god I wish we were using git now instead of svn).

four of us were on the same flight back to vancouver, so we got seats all in a row, which was nice. mostly we just wanted sleep, though. god it was nice to get home and sleep in… I didn’t go to any classes today, I need to recover.