In preparation for Istanbul, we’ve begun overhauling the sensor filtering pipeline of our motion engine. Currently (see the graph) things are pretty insane, with three layers of filtering before any data makes it into the control algorithms. With any luck, we’ll be able to tune the early stages of filtering to reduce any unnecessary delay.
Hey dawg I heard you like filters so I put a filter on your filter so you can filter after you just filtered...
Joho’s post from a little while ago about commits and code changes in SVN got me interested. So today when I came across a very cool and very extensive utility appropriately called StatSVN I immediately downloaded a copy of the code. Running it on the trunk took quite a bit of time and ultimately outputted over 480 html and png files, to make a nifty web page on my box. I’ve put some of the files up and I’ll be looking at maybe setting up some of the information for view here on the site.
Here was my favorite picture (with a close second going to the fact that our lowest amount of code change comes around lunch time).
LOC [Lines of Code] and Churn shows the usual LOC with the amount of code touched per day. Hopefully this should go decreasingly towards a release.
In July 2006, after our first world robocup competition in Bremen, we ran David Wheeler’s SLOCCount on our codebase, when our SLOCCount was 33K. Today, I ran the script again, and our SLOC readings are nearly twice as high.
The big changes come from another 10K lines of C code for recognizing lines and the new goals, and 16K lines of Python code that define the behaviors we used to win last summer:
Total Physical Source Lines of Code (SLOC) = 60,496
Development Effort Estimate, Person-Years (Person-Months) = 14.85 (178.25)
Estimated Average Number of Developers (Effort/Schedule) = 9.95
Total Estimated Cost to Develop = $ 2,006,571
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
I’d be curious to know what the SLOCCount of other Aibo teams is – especially the GermanTeam, and the NUBots.
What is SLOC? It means Source Lines of Code–and we’ve generated a lot of them. So we ran this program called sloccount on our bulky our entirely fresh, brand-spanking new code base as of last fall. It came up with some interesting numbers:
Total Physical Source Lines of Code (SLOC) = 33,716 –Ed.: 10,000 of this is Python 2.3 source code (and not ours)
Development Effort Estimate, Person-Years (Person-Months) = 8.04 (96.48)
Schedule Estimate, Years (Months) = 1.18 (14.19)
Estimated Average Number of Developers (Effort/Schedule) = 6.80
Total Estimated Cost to Develop = $ 1,086,099 (average salary = $56,286/year).
I can only conclude that I have been vastly underpaid over the last year.
Here’s how it broke down in terms of languages:
cpp:Â Â Â Â Â Â Â Â Â 16838 (49.94%)
python:Â Â Â Â Â Â 10995 (32.61%)
ansic:Â Â Â Â Â Â Â Â 5421 (16.08%)
sh:Â Â Â Â Â Â Â Â Â Â Â Â 462 (1.37%)
So overall we’ve done quite a lot of work. Roll, nBites!
*generated using David A. Wheeler’s ‘SLOCCount’.*
The Age of Python is Nigh: weeded down UNSW’s code to the bare Python essentials. Both the python code and the C++ hooks now compile. They crash the dog on boot-up, but they compile!
OK–
I’ve just completely redone the way the team gets its code to the memory sticks. It’s heavily influenced from the open-source rUNSWift code, who know OPEN-R and Makefiles way better than I. The code is insanely modular which will allow our team to easily port among various platforms, code, and computer configurations.
We now use rsync to more efficiently copy files over, and use Makefiles instead of shell scripts. Moreover, I’ve added a lot more compiling flags to make our analysis of bad code easier.
This takes us a significant step closer to python integration.
.flickr-photo { border: solid 2px #000000; }
.flickr-yourcomment { }
.flickr-frame { text-align: left; padding: 3px; }
.flickr-caption { font-size: 0.8em; margin-top: 0px; }
Meet the newest member of MY family–though I’m sure he’ll be spending plenty time grooving in the Bowdoin Lab.
This is a iDog. I will not program it to play Soccer.
On the development side, I’ve spent a couple of hours in the past few days getting to know the vision system–and I now actually understand the new techniques we use as well as the old compression we use for AiboConnect.
The only issue is getting me and Yi Zhuang, our vision guru, on the same page: China to Maryland via email discussing code that is stored at Bowdoin–tricky! Thankfully we have Subversion.
The hectic days of exams are over and the winter has begun. I am home now and ready for a big push in developing for Northern Bites (Trademark forthcoming).
My goals for developing over the break are two-fold: creating a Python layer for the majority of the code-base, and really getting started with finer ball control.
I’ve snuck (or was given full permission) an Aibo home and have gotten the wireless to work on my home network. A two-thousand dollar robot is a great excuse to buy a forty-dollar wireless router.
The good news is the wireless is pretty fast: aiboConnect was able to maintain a fast framerate sending over the non-compressed images. However, the thresholded configuration from the lab is horrible in my low-lit basement. This won’t matter with great new vision system Yi’s implemented this fall (details later), but I may still need some basic hand-done thresholding for aiboConnect’s sake. Or maybe I’ll figure out how to compress the new vision system the same way the old one does (bytes and chars and ints-bleh).
Regardless, I’m going to take a few days off from active development and focus on drafting some research guides for the independent study dudes. Their only task this winter is to catch up to speed on their various areas of research. Dudes: I’ll be sending them out soon.
