Glider
"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"
About this blog

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

Most content on this site is licensed under the WTFPL, version 2 (details).

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

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

See also my Mastodon page.

Sun Mon Tue Wed Thu Fri Sat
8
       
Powered by Blosxom &Perl onion
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
/ 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.

 
0 comments -:- permalink -:- 19:32
Copyright by Matthijs Kooijman - most content WTFPL