Last week, my Master's thesis was awarded with the ENIAC Thesis Award 2010. This is is an award for the best-written and most scientific Master's thesis for Computer Science (and related masters). The prize is awarded by ENIAC, the alumni club for computer science.

This award came quite unexpected to me. Apparently my thesis (together with Christiaan's thesis, which discussed the same subject) was nominated by our graduation comittee. I had also not actually expected to win, so that was quite cool.

The award consisted of a nice certificate and a cool sculpture by Lei Hannen. As an extra surprise, it turned out there is also a €500 money prize associated wit this award.

According to the jury rapport, our thesis were awarded because of the novelty and the new research area they open up. Additionally, my thesis was commended for the excellent use of English. Cool :-D

Last monday, I've had my graduation presentation. After working on my final assignment and Master's thesis for just over a year, I'm finally finished!

The topic of my thesis has been Cλash (pronounced just "Clash"), the Haskell-to-VHDL compiler I created together with Christiaan Baaij, a co-student who has graduated simultaneously. It allows for describing hardware (i.e. chips) using the Haskell functional language. This is new research at the University of Twente, so we started pretty much from scratch (though we've reused large parts of the Glasgow Haskell Compiler.

Anyway, the result was a working compiler, a 100 page report (also see Christiaan's report) and a nice presentation (which could have been a bit more technical according to my supervisors, but I was rather content with it).

So, next up is some rest and picking up all the projects I have been procrastinating because of my graduation work (Setting up drsnuggles, my server, packaging OpenGFX and OpenSFX, getting started with GTD, etc.). I've got a flexible job at Brevidius to make some money, while I find out what the next step is (finding a job, start a PhD somewhere, move out of Enschede, etc.).

XKCD, a briljant online "webcomic of romance, sarcasm, math, and language" (which has a lot of nice geeky comics), had a comic titled "The map of the internet".

While the comic is primarily for fun, it actually contains factual information, so it was used in my course "Telematics Networks". Nice.

I've been struggling away on exporting figures generated by Matlab for use in LaTeX. First attempts using the "Save as..." dialog looked promising and even listed SVG. Unfotunately, trying that resulted in the cryptic error "the svg device option is only supported for simulink systems", while I was trying to export a simulink generated figure... Oh well...

After some fiddling around with the eps option and the File->Export options... menu, which also allows exporting to eps but with some more options, I did a few exports. Unfortunately, doing these by hand every time (File->Export Options, Load the settings, apply to figure, Zoom to the correct scale, press Export, type filename, select EPS, click save, click ok, close window) was a little too much for my commandline-oriented brain.

Looking around in the help found me the print function, which one can use as follows:

print -f1 -deps Filename.eps

This, as expected, prints figure 1 to Filename.eps in the (black and white) eps format. If you want to print another figure, say figure 3, use -f3. If you want to have coloured eps output, use -depsc instead.

The only thing that still needs to be done by hand is zooming the figure, if appropriate, and closing the window (but IIRC a close all command at the end will close all figure windows).

Now, let's get to actually putting my exported .eps figures into my paper!

It has been a while since my last post on this subject, unfortunately this is related to my own lack of activity in this area. I've been too busy with other courses and non-study related stuff in the past weeks.

Since the deadline for the peer reviews of my paper is next Friday, I have put my Bachelor Referaat at the top of my priority list, very lonely. With good results. So far I've made a structure with some general content (Introduction, something about LocSim, etc). I've been finishing up on the obstacle thing in LocSim. Most algorithms should now work with obstacles. I've implemented my improvement and got actual, measurable, results!

See more ...

I've finished both of my exams for this quarter: Signals & Transformations and Circuit Analysis. The first is a master's course on mathematical models of (electrical) signals and performing (theoretical) transformations on them, involving a lot of complex numbers. The second is performing analysis on simple electrical networks with resistors, capacitors and inductors. Not too hard to grasp, but juggling around with hands full of different resistor values tends to get messy after a while. Also, the last part of the course involves, you might guess, complex numbers! Both these exams went pretty well, probably 7+ (out of 10 marks).

During the circuit analysis I've learned that electrical engineers have nasty habits. They have the tendency to not conform to the standard mathematical conventions that the rest of the world does (this view might be a little biased, though ;-p). The best example of this is the way they write complex numbers. Some time back, a bunch of mathematicians agreed that there was need to calculate with the square root of -1 (). While everybody agrees that this number is called i, they insist to call it j, since i conflicts with their symbol for electrical current. Anyway, I think I managed to do both exams without switching them, but I've been mixing them up all the time so far...

Besides these minor inconveniences my electrical engineering minor is starting out OK. Since I've already done Circuit Analysis, which I expected to be next quarter, this leaves only 15 ECTS in my minor. Since that is enough to fill two quarters (which was the original plan), I'll probably try to squeeze in instrumentation for embedded systems, a mandatory masters course, which should not cost too much time. Only problem is that it's given at the same time as another lab course, but I should be able to get away with that...

For my Bachelor referaat, a third year course, I have to write a paper about scientific research performed by me. I started out with this course last year, but do to lack of time, I never actuall started the research.

I did however write my research proposal already. Instead of having to start all over with a new research topic this year, my teacher allowed me to finish my existing paper and present it on the next Bachelor referaat conference instead. So, I made a brand new planning and am now continuing my work.

Wireless Sensor Networks

In short, the goal of my research is to let nodes in a wireless sensor network improve their localization, in particular in the face of signal obstructions. These nodes are small electronic devices designed to perform all kinds of functions, communicating through radio signals. For most functions to be able to work, a node needs to know its physical position. To be able to determine this position, a small number of nodes needs to be told their position in advance. We call these nodes 'anchor nodes', since they are anchored on a know position.

There are a number of algorithms available to perform this localization, some of which work pretty effective. At least, in theory. In practice, these algorithms do not work as effective as we would hope. A significant part of the errors observerd is due to signal obstructions, such as walls, windows or cabinets. Take for example an anchor node and a normal node on opposite sides of a wall. Since the wall obstructs the signal, the normal node might not 'hear' the anchor node, even though they are well within transmitting range. If it performs localization, it will think it is much further away from the anchor node than it actually is (It should have heard the anchor node if it was close, right?). This is an example of the problem, obstacles pose for localization.

I have some ideas on how to improve this, but more on that later (or you should read my research proposal). To properly use my ideas for real research, I need some way of testing them. The obvious strategy would be to find myself a wireless sensor network and teach it my algorithms. Now, even though we have a WSN available at uni, I will not use it. Using real sensor nodes is a lot of work and it is hard to do ceteris paribus comparing. Also, the WSN is not just available all the time for me to play with. So, instead, I will be using a simulator called LocSim. It's implemented using Matlab and Simulink and was written by Stefan Dulman, who also helped me with my research subject initially.

Matlab

Up until now, I have been experimenting with Matlab a little, since I've never used it before. The locsim library is composed of a lot of building blocks, each modeling a small part, such as a block generating node positions, a block performing centroid localization or a block that shows the position of the nodes and the results of localisation. Each of these blocks is powered by pieces of Matlab code, a programming language that makes extensive use of matrices and other mathematical concepts, allowing one to write down these algorithms and other calculations pretty concise.

But, to properly be able to use this library, it needs simulate obstacles in the field, which it currently does not. So, my first goal is to make locsim support obstacles. Some initial toying around showed that obstacles are indeed a big problem: I created a block that inserts a big obstacle, splitting the room in two and that provides a signal obstruction of about half the transmission range. When running with this block inserted, average localization error doubled!

originally, I created a new block that inserts an obstacle into the 'connectivity matrix', ie the matrix that specifies which nodes can hear eachother. This idea was good, but it would not work with all localization algorithms. Some algorithms base their results completely on a given connectivity matrix, but some others need the actual node positions themselves and calculate their own connectivity matrix (or distance matrix).

Modifying loc_dm

To make this work, I would need to modify all the algorithms to work differently and everything would become real messy real soon. Currently I'm trying another route: Modify the distance matrix block (that turns node positions into a matrix with distance between each node). This still requires that I modify all algorithms to add an extra input: The list of obstacles. But, I only need to connect this input to the distance matrix module inside the localization block.

For this to work, I will need some way to describe obstacles to the distance matrix module. For this I have chosen something similar to how nodes are described: A matrix with 5 columns and n rows. Every row represents a single obstacle, in the form [x1, y1, x2, y2, d]. This represents an obstacle that starts at (x1, y1) and runs to (x2, y2). It has no thikness (only signals crossing this line will get obstructed, but it has a 'density' d, which is the length added to the distance (symbolizing the reduced signal strength).

Implementing this was fairly easy using the polyxpoly matlab function for checking intersection between the obstacle and all signal lines. For now, I've done this using a couple of nested for loops, but it should be possible to combine some of these to reduce the number of polyxpoly calls.

Next steps

Currently, my code supports generating obstacles, applying the effects of obstacles to the connectivity matrix and displaying obstacles. The only part that is still missing, is to make the localization algorithms support them too (which is mostly a trivial addition of an obstacle input port).

After this is done, I can start experimenting with the effects obstacles have on the localization effectiveness and try to improve the effectiveness of the various localiation algorithms in the face of obstacles.

This morning's CLP exam went pretty well. Despite the high voodoo-level of promela, the language used, the exam was easier than I expected. Now let's hope I did well enough.

As I was hanging around at Bas' place to chill and discuss the exam, we noticed something at Inter-Actief breaking (both nerding away on our respective laptops). Within 10 minutes we were on the site to see why our (Windows) domain controller had stopped responding. We discovered that it had decided that the windows update it had just installed required a reboot and just went ahead with rebooting. Rebooting that machine is a bad idea anyhow, since it takes more than 15 minutes, during which half of Inter-Actief becomes useless, ICT-wise. Better yet, it had managed to hang itself somewhere between shutdown and boot, so a reset was required. Go Windows!

Anyway, I'm off to Harderwijk now, sailing course tonight, and opening of my fathers new sailing school this weekend. Since I'm planning on becoming a sailing instructor there, that means plenty of sailing this weekend :-D

I'm following a course called "Concurrent and Distributed Programming" (CDP). It concerns programs that run at the same time in a multiprocessor, multiprogrammed or multiple device environment. The main part of the course is proving correctness of such programs. In layman's language: If multiple things happen at once (such as lots of cars driving on a crossing), how do you prevent certain things from happening together (cars driving in perpendicular directions) without the risk of waiting forever (always letting one direction first).

Pretty interesting stuff, actually. Quite a different mindset from normal programming. I've already had some experience with this in other courses (Operating Systems, Programming), but this is more formal and actually proves that algorithms are correct. Something I like :-)

The nasty side of it is that the classes are pretty chaotic. The teacher doesn't really do a good job at explaining the stuff. Add to that that a lot of her sheets (containing very formal, non-trivial to understand code) contain stupid errors and you get a pretty lousy class.

Anyway, I've been installing spin, the validation tool used for this course. I have yet to understand what it can do, though. For now, I was able to do the first (easy) assignment by clicking around in the graphical front-end, xspin. Both are pretty easy to install. Spin is written in C and needs a simple compilation, xspin is TCL/TK and works out right away (if you follow instructions).

The bigger challenge was to make a screenshot of the application showing the simple Promela model, the output and my name. After doing the necessary resizing and converting (I had to hand in the screenshot in PDF format...), I got it done. Let's hope the classes will improve a little and this might turn out to be a fine course.

I've been studying graph theory all night, mainly reading at first. Since I have only little time until my exam tomorrow afternoon, I don't have the time nor the concentration to fully comprehend and prove the correctness of all that I read (which I normally tend to do). Also, I have barely done any exercises, apart from a practice exam just now.

It's not hard given the appropriate definitions and theorems, but since they are not given and I do not know all of them by heart, we'll see what happens tomorrow. I'll try to remember some more definitions in the morning and hope they'll stick... First some sleep, though.