Attending DECOI 2009

From February 23 until February 27, another researcher and me attended the 2009 International Workshop on Collective Intelligence and Evolution (DECOI). The main reason to participate in DECOI 2009 was too gain some more insight in multi-agent systems regarding the SAHNE project in which we are both involved. The venue for this year's workshop was in the Lorentz Center in Leiden, The Netherlands. Leiden is a beautiful small town around 30 Km from Amsterdam. Unfortunately, the work was such that we couldn't make it to see the town in day light.

DECOI is more a “school” than what is traditionally understood as a workshop. The program was distributed in key-note presentations and work in projects. The project details were given on the first day of the workshop, and each group of 4-6 people had to choose one of such projects to work on for the rest of the week. My group chose the project titled “Learning, communication and establishment of norms in pedestrian crowds”. This project was first introduced by Anders Johansson and, for the time being, the slides can be found here. In his lecture, Dr. Johansson introduced a basic model of pedestrian behaviour in crowds. The objective of the project was to incorporate “smarter” behaviour in the pedestrians so they would negotiate better how to avoid getting stuck in groups of pedestrians that are trying to get to the same place at the same time. The project involved first to theorise how this intelligent behaviour could be accomplished, and then to develop a simulation that showed how smarter pedestrians (agents) could obtain better results.

The simulations were developed with NetLogo, which is a Java-based multi-agent simulation tool that deploys its own language. None of the team members had used this tool before, so we not only faced the challenge to first write the simplistic model that Dr. Johansson presented in order to build on top of it, but also how to do this using a programming tool that we didn't know. For this reason, we spent 3 days learning and building this basic model, and the last two days writing the new smart features and gathering results. The features that we implemented were:

• A grouping factor, that encourages groups of “friends” to get closer to each other on the search for the goal.

• A learning factor, that tries to remember which direction worked best in the past and use it in the decision making

• A rumour factor, which is spread by those pedestrians which are stuck in a crowd and that tries to prevent other pedestrians to go towards the direction of the crowd

The simulation takes place in a room with two entries and one exit. The entries and the exit are separated by doors whose position and size can be varied. The objective of every pedestrian in the simulation is to get to the exit door as soon as possible. In order to avoid overlapping with walls and other pedestrians, a set of “forces” in the form of vectors are implemented and sum to the gradient force that attracts pedestrians towards the exit. A naïve approach would generate a crowd that tries to approach the exit through the shortest path, getting stuck in the intermediary door. All the smart features that we implemented helped one way or another to increase the performance of the system. A summary of the strategies and results can be found here . A Java applet accessible here allows you to play the simulation directly from a web browser.

Aircraft management with multi-agent systems

Here at DIAL we have a project sponsored by The Boeing Company to develop a multi-agent system for emergent behavior in aircraft configuration control. In this project, codenamed SAHNE (Self-serving assets for higly networked environments), agents are the virtual counterparts of aircraft spare parts, and are autonomous in terms of decision making regarding their life-cycle. In SAHNE, we put special emphasis in the process of part replacement, and develop a fully autonomous system in which the agents detect when the parts need to be replaced (e.g. expiration date on life bests, worn out of mechanical components, etc) and initiate and coordinate the parts procurement. This later process involves finding suppliers, ask for quotes on the replacements and decide which supplier will better supply the needed part for an specific aircraft.

My main role in this project is to assess the integration of sensor data into the agent decisions. Until now, the development of the platform focused on creating a certain degree of functionality based on static data and software agents. For the second year of the project, we will use actual spare parts and capture technologies to feed real-time data into the software agents. The project is scheduled to run until 2010.

RFID and Caterpillar

I recently participated in the development of a demo scenario for a project proposal with Caterpillar. The idea of the project is to use RFID tags into CAT engine parts to ease the maintenance of the machines. When the engine of the vehicle is turned on, the ID of all the engine installed parts would be collected by means of RFID readers inside the engine casing. The installing time of the parts and its the number of hours of operation would be stored in a engine master-tag (EPCglobal Gen2 tag with extended user memory bank). The life part information at the vehicle start-up would
be compared with the information stored in the master tag. When a part is replaced, a discrepancy would be detected and the operator would be warned. A history of replaced parts would also be stored on the master tag. By means of this mechanism, we expect for vehicle maintainers to be able to know when parts have been replaced and how long the operation of a certain part has been. This mechanism is aimed to replace the current manual practices that are prone to human error and inaccurate information. Furthermore, even if the engine block is replaced, we still carry the information on the master tag, wherever that engine goes. That can help end-of-life part management. For example, we can know exactly which parts can be reused and which ones should be disposed.
To demonstrate these ideas, I helped to develop a software that simulates the engine start and then reads parts and mater tag. It then compares the information and warns the user about new parts installed, removed or replaced. It also updates the engine master tag. We then had a one-day field trip to a CAT research and development site nearby Cambridge (UK). There we installed tags and readers and tested the software in a real CAT tractor.




I must say that the trickiest part of all was to program the master tag update, because the tags we were using didn't have much memory to play around with.

Eclipse plug-in for WSN

Spring last year (2006) I was given the job to make an Eclipse-based IDE to program, download and debug Wireless Sensor Network nodes. At that time, I didn't know very well what Eclipse was. Well, to be fair, I had used it several times before, and I was starting to use it for my research for other things (a middleware monitor, which I will talk about in some other occasion). Anyway, I had certainly no idea about the Eclipse plug-in system. You see, the whole Eclise IDE is based on plug-ins that use and create extension points. With this extension points, you can do things such as adding an icon to the tool bar, creating a new code editor or just adding a new view with pretty much whatever you like.
Back then, other people have already done similar things. However, since we were (and are) building our own platform, prof. Kim felt that we had to have our own programming software to complement the kit (and, anyway, is not that the guys at ETRI were going to borrow us the Java code). The most interesting of all is that our laboratory did participate in 2004 in building this other platform. But anyway, that's another story. Nevertheless, it seems that prof. Kim also felt that I was the best option for coding the new IDE and make it look "good".
Summer past and I really didn't do much. I was into my research, and although I read some documentation to understand how the plug-in system works, I didn't really code anything. Eventually, pressure from some exhibition and others (such as prof. Kim :) made me take it seriously, and in less than one month and built a prototype that could do just that (well, more or less): program in C (CDT plug-in) and compile (winavr), download to the target board (avarice) and debug using a JTAG-ICE (also avarice and gdb). It looked (and still pretty much looks) like this:



It was quite tricky to get some of the functionality, and even now, the IDE is basically a prototype which just works with one kind of micro-controller and only downloads with a JTAG-ICE. I think I should mention that I was not free to do whatever I liked with the OS source (the WSN operating system that we are also developing), and whatever I did to the source tree, it had to be compatible with the "old" way of coding (namely, make a source file and use the command line to compile/upload the image to the sensor board) After the initial version, I tried to make some improvements. The first concern was that the current module selection system was based on a specific version of the OS. This is bad, because new boards and new chips bring the need for new drivers and the like. Also improvements on old modules need sometimes to be offered as a choice (eg. for testing). So my solution was to build a XML file for each main board and sensor board that we developed, specifying the name of the module and where the drivers in the source tree are located. Then, in the "new project" wizard, a user could choose first the main board, which will open the choice of associated sensor boards and so on. Unfortunately, although I began coding this, I had other more urgent things to do and finally I never completed it. Now it seems that a new post-Doc student will take care of my "creation". I hope he can understand my coding :)

Summer of Projects

Unlike previous summers that we were encouraged to produce academic related results, this summer we are encouraged to get some work done: the RESL is undertaking around 10 different projects to be distributed among our lab members and SNR workers. The aim of the projects are very various although all of them are, of course, are related with Wireless Sensor Networks, that is what we are doing in the laboratory. Unfortunately there is a certain secrecy about the development of those projects, so what I can tell here about them is rather limited. But I'll try to give some general description about few of them that at least allows to make an idea what they are about.
Two of our laboratory members have a military background and entered RESL to help us with the increasing interest of the Korean military on the WSN technology. We have already had previous projects and research involving military applications, such as detecting moving troops, send unmanned vehicles to enemy territory, etc. One of the current projects, codenamed u-Army, involves similar work with sensor networks such as borderline intrusion detection and others.
If something Korea has as a nation is a thirst to invest in new technologies to show the world they are at the crest of the IT wave. For this purpose, they don't just poor money into research institutions to build their projects on the labs, but generally they require pilot deployments to prove that the things work as promised. For this reason, most of our projects require such deployments of WSN into the real world. For example, the School Zone project aims to distribute sensor nodes around school areas to prevent car over-speeding and illegal parking. In the Bulkuk Temple project, we must deploy a ring of wireless sensor nodes around an ancient Korean temple to detect fires and prevent the wooden building to burn down. In another project, we will install sensors in a couple of islands to measure tide levels and river flooding.
Other projects aim to test the capabilities of the new technologies rather than providing an specific deployment scenario. For example, although sensor nodes have been used before for localization, they use techniques like ultrasound that are only usable on the lab but that can not realistically be implemented in the real world. To this regard, RESL is also investigating localization techniques using only several aspects of the RF signal, measurement values that are not affected by line-of-sigh restrictions and the like. Finally, on the RFID side of our research, this summer we will implement a prototype of the EPC Sensor Network for merging the RFID EPC Network Infrastructure with sensor data.

Be careful with what you install

I just passed through one of those Linux episodes of "be careful what you install", caused as always due to deficient dependency management. Well, to be fare, I can't blame my distribution for breaking applications, because the broken apps where 3rd party installations (namely mozilla products). And all because I wanted to finally install hangul (Korean language characters) support in my Kubuntu box.
Lesson learned: Don't install scim and uim packages if you are going to use Firefox, Thunderbird and Adobe Acrobat reader. Apparently there is conflict with binaries compiled with different branches of the glibc library. There are some workarounds, but since I'm not sure about all the programs that are using that library, I'd rather uninstall the whole thing that having some problem in a couple of weeks once I forget the issue. I might try those solutions some other time. For now, I had enough time wasted finding out what was the problem (for which, by the way, was rather handy to have Opera installed when I couldn't run Firefox)

My affair with IT drawing

I'm not a designer. I never studied art, although I liked to draw things when I was a kid, like many other kids I suppose. Nevertheless, I guess is fair to say that I like to make things look good. Probably that's what people notices, and when there is something to do that should look good, they sometimes ask me to do that for them.
As I was saying, I'm not a professional or anything. But, of course, there are no professional designers in a lab of CS and EE graduate students. It seems I made things look good enough for being labeled the "official" lab picture-maker. So along my 3+ years in the RESL laboratory, I was asked many times to draw pictures about the IT field we are working on: Wireless Sensor Networks. Of course, pictures must be done with the computer, so a lot of times I basically combined smaller existing pictures to create the concept I was asked. I started just drawing them in MS's Power Point, and then moved to MS's Visio. Microsoft products are good because they have a large database of vector images than can be searched withing the program and modified to fit your requirements. However, Visio files, as all MS Office files, have a proprietary format. Moreover, they don't export properly to SVG (Standard Vector Graphics). When I moved to Linux, I refused to change to Windows every time to use Visio, so I tried to use other programs that could provide me similar results. Software such Dia and Kivio are good to draw vector-based flowcharts and block diagrams, but they are not what I need to make things look good. The answer is general SVG drawing programs (such as Inkscape) combined with online SVG databases, such as the Open Clipart Project (apparently currently moving to a new server). SVG images can look really good, but they are more cumbersome to produce and normally take longer time. However, the SVG format is a true standard that I feel good about using, not like MS proprietary formats.

Many of my early pictures have been lost. Nevertheless, here is a small sample.
By the way, sometimes I do logos too...