Posted on Tuesday, February 12, 2008 by Steve Box
Well well, there was me thinking that my first set of exams that count towards the degree just couldn’t have gone better. My utmost effort went into 4 out of 5 modules (excluding People in Organisations unfortunately) that I actually enjoyed and found very interesting. I was rather surprised on results day to find that I was left sitting in a low end 2.1 having scored 59 and 57 in AI22 and DB21 respectively. I think it was natural for me to react with disappointment and to be very downhearted on the day, but after sleep I could see nothing but a valuable lesson coming out of my experience.
In a way this is very frustrating because I do not think the grades represent my ability or work ethic, yet now I realise just too much time was spent on coursework and not enough on time is spent reading around the module throughout the semester. In some cases this probably wouldn’t help and this is where most of my frustration comes from not having learnt that some exams require a thorough understanding of the module where as some are based on a generic set of past papers.
I could keep writing for a long time to express my argument about what I think of closed book exams and why I think I scored how I did. It would probably turn into a frustrated rant.
So no time to waste - I’ve changed my view on how I approach my study and manage my time. I wish we were given more than just 3 days (which was spent drunk, admittedly) to take the semester into consideration. Semester 2 certainly was slow to get started and that wonderful coursework rush is coming round again.
At least I am happy with the modules I have picked again this semester.
I’m more than ready to effect change and bump up that average.
Categories: Final Year Projects
, Mobile IPv6
Posted on Wednesday, February 6, 2008 by Anthony Sargeant
After my last supervisor meeting on Monday, Karim has asked for a working script so that we can move on to brainstorming scenarios for the experiments.
As I have mentioned before, the Mobiwan enabled ns-2 has certain problems. I’ve installed ns-2.26 and ns-2.27, both of which have been enabled for use with Mobiwan. These problems are:
- Lack of documentation: Thierry Ernst, the author of the Mobiwan code has provided documentation for ns-2.1b6. However, this was written in 2001 and appears to not exactly match up to the workings of ns-2.26.
- Lack of validation or example scripts: When Ernst produced the original Mobiwan, he included some scripts for the creation and management of topologies and also the validation of the installation. None of this has been provided for ns-2.26 or ns-2.27 with the added difficulty of scripts written for ns-2.1b6 not being compatible with ns-2.26 or ns-2.27.
- Lack of support: Thierry Ernst himself has said that all emails regarding Mobiwan will be politefully ignored. Furthermore, the ns mailing lists contains queries regarding the installation and creation of scripts for Mobiwan enabled ns, but most have no replies or follow-ups and all represent dead ends. In fact, it appears that the last known usage of Mobiwan from a Google point of view is about 2005.
- Age of the source code: This has been one of my biggest problems, resulting in my installing an older version of gcc and g++. The most recent version of Mobiwan was released in December 2004 so my confidence in Mobiwan wasn’t the best to being with! Just as a side, the Mobiwan patch for ns-2.27 hadn’t been tested according to Ernst so I don’t think using that version is a good idea.
- Limitations of the software: Mobiwan is missing some elements of the Mobile IPv6 protocols. It seems that not including elements that are not necessary for your simulations is a common occurence. Ernst himself even goes on to say that the software was designed for his purposes only and for anything else, you’re on your own. For example, my project was hoping to assess scalability with regards to numbers of nodes, including mobile nodes, but having multiple mobile nodes has not been implemented in Mobiwan.
With this in mind, I’m concerned that I’m not going to be able to deliver anything to my supervisor come Tuesday’s meeting. Using ns is very straight forward as the ns tutorial demonstrates, however Mobiwan seems to have changed the way ns works at some fundamental level. As a result, some elements exhibit different behaviour, i.e. throwing a TCL exception, with Mobiwan, and so it feels like I’m having to learn the software all over again. This is difficult given my TCL knowledge is very limited.
It is my intention now to go home and put these problems out of my mind for the evening. Hopefully, with a fresh head, I can make more progress tomorrow. But I am mindful of the fact that I have three other modules to work on this semester and are also important if I am to get a good degree.
If I still have no success, then I will have to discuss a contingency plan with my supervisor so that I can still meet my minimum requirements.
Categories: Final Year Projects
, Reading Roadsigns
Posted on Saturday, February 2, 2008 by Kieran O'Shea
Since coming back to university after the Christmas break and completing my January exams I’ve had plenty of time to continue my experimentation on the reading roadsigns project and thought I’d post a quick update on whats been going on.
Recently I’ve been running a number of experiments in Matlab using SIFT and attempting to get various roadsigns recognised by using a cropped training set for a particular sign and then matching it against keypoint descriptors found in a test image.
I’ve been gathering statistical data and dumping this out to a file for analysis and further work but I’ve also been generating match images for each roadsign tested against the most favorable image from the training set. To give people an idea with how this is progressing I include an example of a very successful result on a STOP sign below.
Its not all rosy though and I’ve been given food for thought after my interim report and some failures of the SIFT algorithm in recognising certian signs.
In my initial experimentation with actual roadsigns I decided to go for a simple sign as this would be less likely to be susceptable to noise. This was in fact quite an unwise decision as SIFT works by finding particularly unique points and I had effectively removed the possiblity of it finding such points by using a simple sign. I include below a matches image for a No Entry sign.
As you can see, its actually quite noisy. This is a problem which got me thinking about how I can make the whole process more robust and forced me to return to some of my early research on object recognition.
If I can use SIFT as a pre-processor then I can identify signs quickly and easily that have many descriptors such as STOP signs and then use a more basic system such a a template or colour match to identify the simpler signs such as the No Entry sign. I could also do it the other way around and will need to perform tests to decide what the best order is.
I’m currently working on an idea that SIFT could be used to detect the presence of any sign (not which one it is, but where it is) and then further tests could perform the recognition. In addition I’m researching examples of where SIFT has been modified to be used in colour and also how best to display experimental results. I’m also in the process of writing code to fully automate my training and testing process in Matlab so I should be able to run batch jobs and get results and test theories quicker.
Watch this space for more updates - its all go!