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

The WISSE simulator

When I started to think about how I was going to simulate WISSE, I instantly though about NS2. Seems like the compulsory choice nowadays for anybody simulating wireless (and wired) networks. Of course there are other simulators out there, but they don't seem to have much flexibility and, since there are not many people using them, there are not enough extensions for the protocols I need such as the IEEE 802.15.4. But, how was I going to integrate the Gen2 protocols and the sensor node protocols and write on top of that my application?

Full of doubts, I probably took the reverse path that I should have and I started first with the implementation. I had the sensor nodes there, in the lab, and at that time we had (well, short of) the operating system ready, so theoretically I just had to take my algorithms in paper and write them into C using the EOS libraries. However, this path proved itself harder than expected, and not because the algorithms where all wrong, but because my inexperience with the OS libraries and the immaturity of the whole system (and myself) at the time. If I recall properly, I spent most of the Christmas trying to make the darn thing work, but it never really worked properly. Nevertheless I'm sure that the Eclipse plug-in I developed that fall saved me many headaches in debugging and downloading to the node. But that will be another story.
At some point I realized that it was impossible to get anything from analyzing the lines in the console that the nodes where outputting trough their serial port. First, it was already difficult to identify which piece of key information should be printed in the program to find out if the algorithm was working properly. But the most important limitation was that the WISSE protocol was distributed and analyzing individual nodes' output in terminal windows gave little information about what was actually going on in the network. Because the behavior of the algorithm changed according to when a node is turned on (and hence broadcasts its beacons), it was very difficult to predict was was supposed to happen and, even worse, it was almost impossible to find out why it was happening this thing or the other.

After some time thinking about it, I decided to code a monitoring software. For this purpose, I would attach a node to the monitoring machine with the radio chip turned to promiscuous mode, that would listen to anything going on and just print it out through the serial. Fortunately hacking the Chipcon's 2420 was easy (well documented). However, interpreting just line after line in a terminal, even if it was everything that was going on in the network rather than an isolated node, it was again quite confusing. Soon I decided that I would code some short of GUI that would paint each node and the packets they are exchanging (something like NAM in NS2) I was using Java, because well, is the high level language I know best and I could use it in my Linux and Windows boxes without re-codding. Unfortunately I'm a person that likes things that look good (even for self enjoyment) and not only I wasn't satisfied with plain circles for nodes, but I got stubborned in drawing fancy animated messages from one node to another. This, again, took a lot of time because I was unfamiliar with animation techniques in Java (and, still now, doesn't work as good as it should).

Finally I short of finished the monitor and I tried to debug the algorithms in the nodes to see if it could work. Unfortunately again, after all the effort I was not very lucky. The protocols wouldn't work properly, and to make things worse, I had a lot of problems with the libraries that implemented the timers because there were errors in the coding that nobody knew about because nobody really tried to use them before. After several weeks of struggle, at some point I thought that, well, if it was the algorithm the one that was flawed somewhere, why should I suffer implementing it in a limited and black-boxed sensor node instead of trying first a in higher level language in a regular computer? And, what is more, why should I do that in a foreign environment like NS2 while what I really needed is to see (and prove) that the algorithms were working as designed rather than show their performance? So, obvious now, I chose to reuse the GUI I created for the monitor and code a threaded software that would create nodes, control their life-cycle, show their interactions in real-time and collect statistics of what was happening. Finally I wrote the algorithm, found some flaws and made the whole thing work. And, of course, I ultimately proved my point that a double clustered architecture with dynamic representative election is more power efficient that other types of architecture.



Above, entity 6 sends a broadcast advertising the network. Well, it doesn't look so much sleek, but I like it better than NAM (NOTE: buttons were taken from Linux icon repositories)...