"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"

These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.

Questions? Praise? Blame? Feel free to contact me.

My old blog (pre-2006) is also still available.

Sun Mon Tue Wed Thu Fri Sat
2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Tag Cloud
&
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, entries_index, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
/ Blog / Uni / BaRef
Exporting figures from Matlab to LaTeX

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!

Related stories

/ Blog / Uni / BaRef
BaRef: (good) results

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 ...

/ Blog / Uni / BaRef
Bachelor Referaat: Introduction

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.