Posts Tagged wirelesssensornetworks
Q&A: TOSSIM
I’ve been pretty busy lately to post much, but I think I’ll try something new. Since, I receive a lot of questions regarding TinyOS, I’ll post my responses here instead of via email so that more people can benefit (if I’ve got time). The first question:
When using python (tossim) to test the application code written using nesC, how did you make nesC code and python dependent on each other or how did you control the nesC code from python? Did you use swig to export the interfaces from C to python or ran the application code directly on nesC by hard-coding them thus making nesC and python independent?
The TinyOS tutorial for TOSSIM does a pretty good job of explaining this. The idea is to write your TinyOS application code as if for a real mote. Then you can compile it for TOSSIM:
$ make micaz sim
This will automatically create the wrappers needed for your TinyOS program to interact with Python. You don’t need to do anything with SWIG yourself, the TinyOS makefile does this all for you.
My goal here is to compute throughput, packet delivery ratio, end-to-end delay for an arbitrary number of nodes say 10 to 50.
You can access nesC variables directly from a Python script that runs your simulation. You can easily access a sequence number variable or a variable that tracks the number of retransmissions of a specific node in the simulation. Again, the TinyOS TOSSIM tutorial explains this in greater detail, but in your Python script you can have something like:
m = t.getNode(0)
v = m.getVariable("MyAppC.seq")
Wall Computing
Recently, I picked up Ray Kurzweil’s The Singularity is Near, which depicts an inevitable merge of man and machine. Within 20 years, he predicts that computing power and algorithmic capability will exceed that of a human brain. Well before the end of the century, Kurzweil claims that humans will be able to download their consciousness into a machine and exist as a cyber entity. I have my doubts if these predictions will come true as quickly as Kurzweil claims, but one of his predictions for the short term future caught my eye.
In the book, Kurzweil says that soon computers will be everywhere, even in the walls. Within the sensor network community, I’ve heard similar arguments dozens of times. The real question is: why do we need computers in the walls? What is the underlying motivation for having computing intelligence in your clothes, in your desk, or in your dishwasher? What can sensor networks do to improve your life? Right now, it’s really hard to say.
Another researcher in the sensor network community likened sensor network research ideas as “hammers looking for nails.” That is, solutions are invented before the problems are defined. With emerging technologies, its hard to say immediately what their benefits are. An interesting quote from a guy in the augmented reality community depicts how a new technology can sound cool but has little practical value:
“The first movies that ran could show anything, like an elephant in the zoo,” Meier said. “100 years ago it wasn’t about the elephant, it was ‘that thing is moving!’ Eventually it became more about the content…”
I would say that the current state of sensor networks is much like the above movie analogy. Computing in the walls sounds cool, but what can small, networked devices in your walls do that really matters? Few research papers offer any practical applications, since most sensor network papers focus on small fundamental problems: radio interference and MAC protocols, routing issues, and primitive event detection with sensors. The few applications that exist in research papers aren’t exciting: activity recognition with body sensor networks (e.g. sitting, standing, walking), vehicle detection and tracking, and human health monitoring.
A few of these sensor network applications have made it into the mainstream media. Lightweight health monitoring sensors may sound boring, but could provide motivation to stay in shape when your daily living habits are compared online with your peers. Another project aims to put health monitoring sensors in soldiers’ underwear, with the aim that the underwear can release drugs and treat wounds. One idea from IBM promises to have a computer at road intersections notify cars to turn off their engines and save fuel at lights. Lastly, the smart home concept promises to network household appliances together to notify users of energy usage and to reduce energy consumption during peak time periods.
Whether the above ideas are really exciting or constitute the limits of sensor network capability is another matter. I’m hoping that some really cool stuff will emerge in the future. My bet is on participatory sensing and peer to peer collaboration with mobile phone-based systems, but like most people, I don’t have any specifics.
Low Level Serial Control in TinyOS
Posted by Matt in development on March 30, 2010
It’s been awhile since my last TinyOS post, but a new project required me to return to programming motes. In this case, we needed to send ASCII characters over the serial port to the PC, bypassing the default TinyOS serial stack.
The TinyOS serial stack is designed to work with Active Messages so that packets received over the radio can be easily forwarded on to the PC. To that end, the high-level serial and radio components provide the same interfaces. The TinyOS serial stack has layers for packet formatting, error checking, and a read/write buffer. However, for our project, we wanted to simplify the PC side so we didn’t have to use the TinyOS JNI libraries to receive TinyOS Active Message packets. A simple program to read ASCII characters over the serial connection would suffice for our purposes — Minicom does this quite well and is easily installed on Ubuntu Linux and can be configured to read from attached USB devices.
The goal was to produce a TinyOS component that provided a command for transmitting ASCII character strings over the serial connection to a PC. The implementation is very similar to the Pulse Oximeter code I wrote for Atmel-based devices, however this time I targeted MSP430-based devices, such as the TelosB or Tmote Sky. The implementation uses the Msp430Uart1C component for accessing the serial connection. This component provides the UartByte or UartStream interfaces for reading and writing and the Resource interface for gaining control of the UART. Msp430Uart1C also provides the Msp430UartConfigure interface for setting the baud rate.
The control flow for writing a character string is as follows: First, request the UART resource. Second, when the resource has been granted, call UartStream.send() to transmit the string. Lastly, when UartStream.sendDone() is signaled, signal the higher level application that the character string has been sent or an error message if something went wrong. In my SerialAscii module, I have the following command to send a character string:
command error_t SerialAscii.sendAscii(char *str)
{
bufferLength = strlen(str);
if(bufferLength > BUFFER_SIZE)
return FAIL;
memcpy(strBuffer,str,bufferLength); // copy string into a buffer
call Resource.request(); // request access to the UART
return SUCCESS;
}
I copy the string into a buffer to keep the application from modifying it before being transmitted. When the resource request is granted, I transmit the string:
event void Resource.granted()
{
error_t result = call UartStream.send(strBuffer,bufferLength);
if(result == FAIL)
post sendDoneFailTask(); // return failure message to the user if something bad happened
}
Lastly, when the string is sent, I release the resource and signal the higher level application:
async event void UartStream.sendDone(uint8_t *buf, uint16_t len, error_t error)
{
// call Resource.release() in each of these tasks
if(error == SUCCESS)
post sendDoneSuccessTask(); // signal SerialAscii.sendAsciiDone(SUCCESS);
else
post sendDoneFailTask(); // signal SerialAscii.sendAsciiDone(FAIL);
}
I’ve made my code available here. Let me know if you find any bugs or have any comments or suggestions.
No longer the Vickers, but still holding up
Posted by Matt in general, microfracture on December 16, 2009
Quite a bit has happened in the past few months since I’ve written anything substantial. With school picking up, it’s hard to write since both activities draw from the same energy source.
Today marks the first time since my knee surgery, nearly a year and a half ago, that I’ve run for seven consecutive days. The last time I ran six days in a row was at the beginning of September, and I felt awful by the end of that streak. From mid-August to the beginning of September, I ran about five or six days in a row and then took the other days on the bike to try to alleviate the completely trashed feeling from running. By the end of September, I had been running about six miles on the days I ran and started to feel more smooth doing it, but I was still pretty beat up.
Part of the beat up feeling was more than likely due to me favoring my non-surgery leg when running. I had been fighting an adductor strain on my right leg that gradually got worse until I was unable to walk without limping. While my left knee felt fine, my right leg hurt just about everywhere. At first, I thought it was just the humidity, but as the summer ended, the problems persisted, and I was forced to stop running at the beginning of October. From then until the beginning of December I spent most of the time on the bike, with a few botched attempts at running once my thigh problems calmed down. However, within the last few weeks I’ve been able to restart running while keeping everything under control. With the introduction of cold weather, it’s a lot easier to run than bike, despite buying warmer clothes to ride in the cold and rain.
At this point, I’m certain that I’ll never feel as good running as I did when I was on my college team. On the team, even on the worst days after a race or hard workout, I still felt light on my feet and able to cruise through a 10-15 mile run without thinking. Today, each step I take is a considerable effort, like I have to drag myself through five or six miles. Comparing how I felt when running on the team with how it feels now reminds me of a passage in Neal Stephenson’s Cryptonomicon. A character in the book compares the power of a bandsaw to other saws and a Vickers machine gun to other firearms:
[T]he most noteworthy thing about the bandsaw was that you could cut anything with it and not only did it do the job quickly and coolly but it didn’t seem to notice that it was doing anything. It wasn’t even aware that a human being was sliding a great big chunk of stuff through it. It never slowed down. Never heated up.
Guns could fire bullets all right, but they kicked back and heated up, got dirty, and jammed eventually. They could fire bullets in other words, but it was a big deal for them, it placed a certain amount of stress on them, and they could not take that stress forever. But the Vickers in the back of this truck was to other guns as the bandsaw was to other saws. The Vickers was water-cooled. It actually had a fucking radiator on it. It had infrastructure, just like the bandsaw, and a whole crew of technicians to fuss over it. But once the damn thing was up and running, it could fire continuously for days as long as people kept scurrying up to it with more belts of ammunition.
Before my surgery and when I was on the team, it was as if I could just go forever and chew through any workout or race, “firing continuously for days.” I never slowed down and rarely heated up. There were limits, of course, but reaching them required hundred mile weeks, punishing pace runs, and draining interval workouts. Like the Vickers, there was also quite the support infrastructure of coaches, trainers, and teammates. But now only running a few miles is “a big deal” for me. It places quite a bit of stress on me, though it is easier than in the late summer. I’m quite sure I’ll have to spend a lot more time on the bike, but maybe I’ll get to the point where I’ll want to run a race.
With respect to school, I’ll be travelling to Stockholm in April to present a paper at RTAS. I’ve been working on several projects related to event detection with accuracy guarantees, which will probably form the basis for my thesis. I also went to RTSS in Washington, DC two weeks ago, but only a few tracks were on wireless sensor networks, but most were about job scheduling and cache replacement policies with the latest multi-core architectures. I’ll also be starting a project with mobile phones with a few other students in our department, which should be interesting. The traditional concept of wireless sensor networks entails small devices with cheap sensors and the processing power of a scientific calculator. However, mobile phones have considerably more power as well as onboard sensors and have more potential for practical applications that people would actually use.
It’s interesting that I spend much of my time writing, creating presentations, and sketching out designs and high-level solutions. About half of my time is actually spent programming. It’s probably a good thing since it gives me a balance between different tasks. Writing papers and creating presentations can be tedious since it can be difficult to cram in months of work into a short paper or presentation. It’s also difficult to create a good balance of high-level descriptions and details to keep people interested but not get confused. When working with a small group of people on a project for a long time, it’s easy to get stuck in a box and not consider things that outsiders would see as obvious. Working with a few other students on my next project should help with this.
It’s when I run into my old teammates that I realize that despite being in the same town and same school that things are really different. One of my teammates got married a few weeks ago and at the wedding, it really hit home that I’m living in a new era. We’re no longer kids. School has taken on a whole new meaning. My relationship with my longtime girlfriend has also taken on a new meaning. Many of the people and the places are the same, but life is different.
Going Mobile: Network Neutrality
The traditional approach for implementing solutions in wireless sensor networks is to use academically designed sensor motes, which provide an open hardware and software platform. Such devices have been good for addressing fundamental problems, like radio irregularity, routing, data aggregation, and power savings, all of which require fine-grained control (open source) over the software and hardware. While sensor motes provide a good proof of concept solution to some problems, more practical solutions are needed that are more attention-grabbing than a collection of weak, low power devices with limited sensing capabilities. Basically, there aren’t a whole lot of applications for sensor motes that would be useful to most people. A more recent approach is to use cell phones, which are increasingly becoming equipped with GPS, accelerometers, and microphones, providing a platform for interesting and practical wireless sensor solutions. However, the hardware and software of most cell phones are extremely restrictive, clamped down by manufacturers and wireless providers, effectively limiting the research possibilities. For example, one can’t just perform a clear channel assessment using a cell phone’s WiFi radio without less restrictive or open source drivers (even with Android). Such restrictiveness is hindering improvements in mobile devices and many of these improvements would be welcomed by everyday consumers.
Like landline phones, Internet users will eventually drop wired ISP connections in favor of wireless. This shift towards mobile and ubiquitous computing emphasizes that wireless infrastructure and usage policies will be critical in the coming years. With few exceptions, ISPs have followed the principles of network neutrality with respect to wired networks, permitting wired customers to use any device with any software using any communication protocol. However, such openness is not reflected in wireless networks with ISPs placing heavy restrictions on devices, software, and means of communication. To ensure competitive pricing, hardware innovations, exciting software applications, and available bandwidth for the surge in wireless traffic, wireless providers must follow the principles of network neutrality. Since wireless providers are hesitant do do so, the FCC’s decision to enforce network neutrality is a step in the right direction. The enforcement of the FCC’s network neutrality principles will allow researchers to push mobile computing to new and exciting levels and will allow consumers to get more functionality at lower prices.
The openness of the wired Internet has seldom been encroached upon by ISPs and rarely regulated by government, making the Internet the world that it is today. This freedom has been defined by the FCC’s four principles of network neutrality:
- A user can access any content over the network. All who access the Internet are provided access to everything on the Internet, whether it be an AP news report or the Unabomber Manifesto. No ISP restricts content: everything is available, even if it may be morally objectionable or illegal.
- A user can run any application or use any service over the network. Anyone can use any web service or application (Google, Mapquest, Facebook) without restriction from an ISP. No ISP prevents users from making Skype calls even if that ISP also sells landline telephone service.
- A user can connect any device to the network, given it does no harm. An Internet user can connect with any hardware, whether it be with a ten year old piece of junk running Linux or with a $10,000 top-of-the-line quad core processor running the latest Windows 7 beta. No ISP restricts a user’s Internet access because his or her computer is a piece of junk. Nor do ISPs force users to connect only with proprietary computers sold by the ISP.
- Competition among network, content, and application providers. A user is open to choose from one of several ISPs (if more than one are even available), and also has choice over competing web services and content providers.
This freedom has not always been maintained, even with the wired Internet. Two years ago, Comcast deliberately throttled the bandwidth of peer-to-peer protocols, limiting the upload and download speed of file sharing applications. With peer-to-peer using customers enraged over this finding, the FCC forced Comcast to abandon this policy. Other than this incident and a few others, the Internet has always been delivered equally to all who have access.
Unfortunately, such open policies of the wired Internet are not followed by wireless providers. From the very birth of cell phones, wireless providers have controlled everything:
- Unrestricted content. Wireless providers block (through restricted software) bandwidth-heavy content, such as streaming videos, voice/video communication, as well as file sharing. Such restrictions are in place to limit or prevent wireless network congestion. Improvements in wireless infrastructure could alleviate such congestion, but wireless providers have decided to restrict, rather than improve.
- Use of any application or service. Nearly all providers restrict the operating system and applications available on connecting mobile devices. Apple blocks the use of Skype when the phone is not connected to a WiFi network. Similarly, the Google Voice application was also removed by Apple and AT&T. Both applications provide features that could be seen as subversive to standard cellular voice calls. Instead of providing competing applications (maybe with better features), the ISP and application providers just block any competition.
- Connection of any device. Verizon’s network may be good, but their phones are terrible. A customer cannot just build their own tricked out phone and connect it to Verizon’s network. Instead, users are forced to choose from a handful of phones with menial features (only sold by Verizon, of course).
- Competition. Since content, applications, and hardware are restricted on most wireless networks, competition is limited. Only a handful of wireless providers offer large coverage areas, especially for data communication. Since the United States pays more for wireless than any other western country, it is clear that less restriction would provide more options and more competition for consumers.
Despite the crackdown on allowable hardware, software, and access, wireless executives somehow manage to argue that their industry is “perhaps the most competitive consumer market in America.” While unregulated competition would be great for consumers in terms of increasing wireless freedom, there simply isn’t enough competition to go around. There are only four major carriers in the United States, effectively forming a cartel that can set prices artificially high and extensively limit consumer freedom. With barriers to entry so high (infrastructure), few new carriers are likely to emerge. In cases like these, government intervention is the only solution. Fortunately, the FCC is investigating the lack of competition in the wireless market with respect to insane billing rules and lack of consumer freedom in comparison to the wired Internet. Of course, their latest decision to enforce network neutrality will also provide a strong push.
The end result should allow anyone to build their own phone, install a custom operating system, and connect it to the wireless provider of their choice without issue. Such a user should be allowed unrestricted access to the entire Internet without throttling or restriction of streaming video, large file downloads, or VoIP calls. Ultimately, text messaging and voice calls will be merged into wireless data plans, removing such unreal and confusing costs like $.25 to send a 160 byte message or “anytime” minutes, which are anything but anytime. Unrestricted hardware, software, and access will bring increased competition among existing wireless providers, fostering the development of better mobile hardware and cool applications.
“When you control the mail, you control information”
Newman had the right idea: with a communication infrastructure, the end users aren’t alone in leveraging control over the information they communicate. Intermediaries have just as much control as the creators and the intended recipients. This might be true for mail, and it’s increasingly becoming an issue with the internet.
The most visible privacy issues have been raised with the introduction of social networking: Facebook’s Beacon being one of the most infamous, with Facebook secretly collecting your online activities to generate targeted advertisements. More recently, software designed to control and monitor children’s internet usage was revealed to actually transmit all internet activity, including instant messages, back to the companies that designed the programs. The list of abuses and potential abuses goes on and on and will only get worse. The introduction of cloud computing and the shift to thin clients mean that third parties are handling more and more personal data. The more opportunities others are given to handle our personal information, preferences, photos, browsing habits, and documents, the more opportunities exist for the abuse of that control.
Social networking and the monitoring of internet habits is only the tip of the iceberg. The social networking concept is quickly moving beyond the confines of the Internet and integrating itself with the physical world. The concepts of participatory sensing, body sensor networks, and smart homes/offices will see the introduction of internet-linked sensors placed everywhere. Cameras and microphones will soon be on every street corner. Temperature, humidity, and other energy monitoring sensors will be commonplace in every home, all linked to the internet. Even now, most cell phones come equipped with GPS, accelerometers, and microphones, allowing for activity recognition and localization. This “information saturation” will allow any developer to design an application that makes all kinds of weird discoveries: with body sensor networks and smart phones, rush hour traffic can be monitored in real time, local nightlife hotspots can be easily discovered, and suggestions can be made on how to save energy based on water and electricity usage in your home.
While the integration of the internet into the real world sounds cool, imagine what someone could do if your sensing information got into the wrong hands. Would you really want your health insurance company to know your heart rate or blood pressure at any time of day? Would you really want everyone to know that you waste the most water out of everyone who lives on your block? Would you want a crazed stalker to know where you were at any moment or to learn your daily activities or routines?
Privacy and security is going to be an increasing concern as sensor networks become more commonplace and integrated with the internet. While I was at UVA two weeks ago, Prof. John Stankovic mentioned that security and privacy in sensor networks is a huge problem and unfortunately, little is being done in this area.
A recent article by a UCLA student illustrated some of the problems with participatory sensing and presented some general solutions. Disclaimer: as part of the lead-in on her article, she says: “the developers I work with might say [my research area] is about telling them what they should be doing—which I must admit is the goal of this article.” When someone says they know better than you, it’s time to run, not walk, to the nearest exit. That said, I do agree with some of the things she says. The author argues that a general framework should be designed for all participatory sensing applications that allow for user privacy management. The frameworks should allow a user to easily understand how the systems work and how to control the release to the outside world of personal sensor data and inferences. Ultimately, the author argues that data generated by a sensor network that you own is yours to control and distribute. Third parties must respect the wishes of the content generators.
The author doesn’t go into fine-grained detail about how to ensure the preservation of an end user’s privacy wishes. I could imagine some kind of CA could help verify that those third parties which access a user’s content/sensor data are who they say they are. Some kind of feedback mechanism could allow a user to see where his or her sensor data went and how it was used. If a third party abused a user’s data, the CA certificate could be revoked, effectively tarnishing the reputation of that third party. Most likely, encryption would have to be introduced to ensure nobody but the permitted third parties could access a user’s data. Unfortunately, encryption is very energy and bandwidth heavy for low power wireless sensors.
We all know the wrong way to go about privacy with the experiences of Facebook and its tacked-on privacy measures. Initially, Facebook provided little privacy controls with no framework at all to allow a user to control access to his or her information. Even now, the privacy controls for Facebook are hard to access and even harder to understand what they do. A user has no fine-grained control over adjust who can access what content and exactly how your information is being shared with third party applications and advertisers. A comprehensive and user-oriented privacy framework installed from the ground up would help stop the mishaps that are common with social networking. Such a framework would come into its own with the increase in participatory sensing.
On that note, it’s time to get a few cell phones and start a participatory sensing application of my own to provide motivation for some research problems. The possibilities are limitless and I can throw privacy to the wind (for now). Unfortunately, as the author of the ACM article mentioned: researchers and developers don’t think about privacy, they think about research problems and cool applications. In a small-scale research environment, the information is mine to control since I control the sensors, the application, and the release of any data or inferences from the data. But, if anything were to be released into the wild and become popular, a framework for end user privacy control would be indispensable. I certainly don’t want some nutcase knowing when and where I’m sleeping.
Another whirlwind tour
I’m glad to say that my second segment of travel this summer is over. While I like the concept of going somewhere different for awhile, I don’t handle it well. When I travel, I tend to have trouble sleeping and also usually have trouble with the food. If I was in one place for more than a day or two, I would adjust and it would probably be better, but the trips as of late have been too fast to allow me to get used to a new environment. I still feel like I’m recovering from last week.
That said, it was an interesting trip, or sequence of trips, covering Boston for a paper presentation and then to Charlottesville for a Wireless Sensor Networks “retreat”. The first thing that happened started several days before I left to Boston, tripping on a downed branch in the street which nuked my ankle and plantar fascia, as I later found out. I got up when it was still dark out the morning I left for Boston and went running only to find my foot in incredible pain. It was the worst plantar fascia pain I’ve ever had, despite having trouble in that area plenty of times. So after getting back I found myself unable to walk without searing pain in my heel and barely able to limp around. This, right before a day of airports, subways, and walking around Boston.
Fortunately, the flights did go well this time around. Everything was basically on time going out and coming back from Boston. I left last Monday morning, connected through Washington, and took a shuttle flight to Boston. I had to take a bus from the terminal to the T station which was tricky since there were several buses that all looked the same but went to different places. The subway was straightforward but I did have to change trains once. It dumped me out two blocks from the hotel and I just walked limped from there.
In an effort to save the department some money, I went a day late. It turned out that when I got to the hotel in Boston on Monday afternoon that there were no sessions scheduled for the rest of the day. I had hoped to sit in on a few to see what everyone else was doing and to be sure that I had about 20 minutes to present. Since nothing was going on, I dropped off most of my junk at the hotel and went outside to walk around, despite my heel pain. I figured I might as well take advantage of being somewhere else besides school for a change.
Clearly, people in Boston know a good day when they see one and get out when it’s nice. This was the first time in awhile that I had been there when it wasn’t winter. The previous times, the Charles was iced over, snow piled up, and winds whipped through the streets. Not many people were out then. This time, I walked through Boston Common and it was packed. I didn’t realize there was a pond that you could swim in. I went up and down the streets near the hotel, found some food, and went back to the hotel to crash. As tired as I was, I didn’t sleep.
My presentation was first thing Tuesday morning so I practiced the night before and hoped that the length would be about right. I wanted to get up early and run in Boston before I presented, but I realized that my heel pain was too great to do that. When I got to the conference room where I was to present, there was only one guy in there in charge of the projector. Nobody else came, not even the session chair, until five minutes before I was to start. After I got going more people showed up including another professor from William and Mary who also had a paper. Fortunately, everything went well and I handled the questions without any real issues.
The next trick was getting back since I had to go to UVA the next day. I was booked on a 3 PM shuttle flight from Boston to LaGuardia, but that would give me less than an hour to connect. If there were delays, I could miss the connection and get stuck, as I experienced little more than a month ago. I wanted to get on an earlier shuttle flight but when I booked the ticket, the system wouldn’t let me. Interestingly, the book I was reading had a character that took a shuttle flight to LaGuardia and then was able to return anytime without charge since it was considered an “open” ticket. I’ve also heard elsewhere that you could just change your ticket on shuttle flights if there was room. Since the flight out had few people on it and the Boston shuttle terminal was nearly empty when I arrived, it seemed that changing my ticket wouldn’t be limited because of full flights. I got the subway and bus back to the airport and got there early to see if I could leave sooner. Nope, the gate agent demanded 50 bucks. So much for all the hype over “open” tickets. Another guy asked the same question, but apparently arriving an hour or two early was worth the money to him.
I sat in the empty Boston airport for several hours while two other shuttle flights left for New York, both with very few passengers. Finally, when I got on my plane, I was assigned an exit row where the seat in front of me was removed. I had double legroom. I guess I was rewarded for waiting. The flight back to Norfolk was a little late and I managed to get home at 8 that Tuesday night. This time I really did crash and slept for over 11 hours. Yet another big day was coming up.
On Wednesday I left home for Charlottesville and picked up the other student in our group, Zhen, from Williamsburg. We got there Wednesday night and stayed at a hotel that was hopefully within walking distance of where the meeting was the next day and Friday. Since I couldn’t run and was still in pain, I took my bike with me so I could explore Charlottesville in the early morning hours before everything started. Biking was interesting since it was dark and there were a lot of big hills compared to Williamsburg. On Thursday morning, my headlight came off its mount and shattered all over the pavement. I had to get a new one.
My adviser told us that the retreat was to be held in the rotunda, which motivated the choice of hotel since it was within walking distance. I had been to the rotunda before and it seemed weird since it was only really one room where tours were given. I asked him several times if that was where it was, but when we got there Thursday morning the doors were locked and nobody was around. I had the number of a UVA grad student which told us that it was at the business school, which was nowhere near the rotunda or the Computer Science building. He couldn’t say where in the business school it was, and after looking at a map, the business school complex was huge. We might never find where we were to go. Somehow we managed to find the right room and building after running into a knowledgeable receptionist right after we walked in the door of the first business school building we found. We got to the right room 45 minutes late. Other UVA students laughed when I told them that my adviser said the meeting was in the rotunda.
The retreat was more or less an informal series of conference-style presentations. Most everyone was a UVA student presenting on a work in progress. There were lots of unsolved problems which led to all kinds of nasty questions. It appeared as though some students didn’t practice since they went way over time or were cut off entirely with zillions of slides left. The few that finished early were given plenty of discussion to fill in the gaps. There were lots of interruptions, especially from the professors, and usually the adviser of the student would cut in with some difficult question about something that hadn’t been fleshed out yet.
The retreat went all day Thursday and then Friday until just after noon. There were a lot of demonstrations, including that of a fall detection system for the elderly where the user would wear several accelerometers and gyroscopes. One of the students with sensors taped to his shirt and legs fell down on the floor five or six times, which was pretty amusing, especially since the system didn’t indicate a fall until the last attempt. There was a breakout session where my group discussed future applications and system designs. An interesting thing that came out of that was the release of more iPhone/Google Maps-style APIs for third parties to make use of the deluge of data from sensor networks. Someone commented that very soon you’ll find a microphone, panoramic cameras, among other sensors on every street corner, essentially providing a live Google Street View. Imagine what someone could do with that: follow people remotely as they go about their day or generate a tag cloud of things people are discussing the most and break it down by location. When I got home, I noticed that Google Maps now has a traffic congestion tool that uses GPS and speed readings from mobile users to determine if a road segment is congested. Stuff like this that people currently consider to be invasive is going to be more commonplace and acceptable.
After all that I managed to get back home last Friday afternoon. Since the traffic was such a mess in the tunnels, I wound up going through some nasty parts of Portsmouth to get around everything, something I hadn’t done before. It took me as long to get from Charlottesville to Williamsburg as it did to get from Williamsburg back home.
Overall, the trip was probably worth some of the fatigue and heel pain since I gave a conference presentation and got a fair amount out of the retreat. With the start of the fall semester, most the travelling is done for awhile and it’s time to get going on work that I haven’t been able to get to since I was gone.
Rise of the Machines? I think not.
Using machine learning in the realm of wireless sensor networks, I have been able to improve sensor node localization and provide event detection. Since I found the concepts of machine learning interesting, my adviser provided me with a book to get an overview: Machine Learning, written by Tom Mitchell of Carnegie Mellon. Most machine learning techniques are equivalent to function approximation and most also require a significant amount of human intervention to work properly. A machine learning model can be trained to take a set of inputs (such as sensor readings) and provide an output (a tank is hauling butt towards my base). However, the model has to be trained to know what the correct outputs are (tank is present or not present), so a human must provide a limited set of training data where the correct output is known.
Given the state of the art in machine learning, there is no way for an AI to learn on its own. There is reinforcement learning, but even in this case a human must decide the conditions and the amount of a reward or penalty for each AI decision or output. This is why AI in games is terrible: when there are a large number of non-deterministic game states and a large number of non-deterministic actions to take, it is almost impossible to determine the correct action to take at every decision point. This means that it is difficult or impossible to provide the AI with labeled ground truth or a reward for training. More to the point, labeling each output with the correct value would be a real headache. Instead, game developers resort to a rule-based system that still has trouble covering every possible scenario. As a result, NPC characters still wind up doing something weird, like running into walls.
I’ve been working with this stuff for awhile, realizing its capabilities and especially its limitations. Then, this weekend I see a headline reading: “Scientists Worry Machines May Outsmart Man.” Overblown media hype at its best. The article concerns a conference on machine learning attended by the aforementioned Tom Mitchell and futurist Ray Kurzweil. From what I gather, the conference dealt with mostly philosophical issues with respect to advancing technology and its integration with everyday life. There wasn’t much about strong AI taking over the world, yet it was plastered all over the news that a Skynet-esque entity would rise from the Internet and doom us all. In some ways, simpler systems have already taken over our lives: GPS tells us where to drive, automated tools read MRI scans and provide diagnoses, and viruses wreak havoc on our personal computers. However, strong AI has quite a ways to go, with most machine learning research peaking decades ago. As one Slashdot commenter on the NYT article writes:
Any computer scientist who is worried about AI taking over no longer deserves to be referred to as a computer scientist. The state of “artifiical intelligence” can be best described as “a pipe dream.”
All of this comes on the heels of a TED talk on the development of a brain simulator. The speaker indicates his current brain “implementation” is running on a 10,000 core Blue Gene system. The article gives few details, but it sounds like a large scale artificial neural network, which still needs supervised training data to learn properly. 10,000 nodes is still way too small, since the average human brain has 100 billion neurons with 7,000 connections each. Maybe in ten years the requisite computing horsepower will be in place, but I’m guessing the algorithms and the intelligence will not.
In a similar light, a team of scientists recently used DNA computing to solve the NP-Complete Hamiltonian Path problem. Instead of using some artificial construct or model, billions of DNA sequences, each representing a possible path, were randomly constructed such that those having a correct solution would glow a different color. While massive parallelism makes this a relatively fast solution to an NP-Complete problem, this approach really isn’t a doomsday AI either.
While specific solutions continue to be discovered for our technological problems, development of strong AI (and the development of Skynet) will sit on the back burner. Until then (and it’ll be awhile), everyone can take off their tinfoil hats.
BCI Pulse Oximeter in TinyOS 2.1
Posted by Matt in development on June 15, 2009
After days of getting lost in TinyOS 1.1 and 2.1 low level hardware abstractions, the Harvard design BCI pulse oximeter now works in TinyOS 2.1.
Prior to writing the driver/interface code, I had to procure the pulseox hardware. Detailed descriptions of hardware, software, and applications are found at the Harvard CodeBlue website. I first ordered a Smiths Medical OEM Digital Micro Power Pulse Oximeter Board. I was able to get in contact with sales staff by emailing Smiths Medical. The pulseox board comes with a finger sensor and runs about $200.
Next, I needed an interface board to connect the BCI pulseox board to the 51 pin connector on the Crossbow IRIS. The Harvard CodeBlue source code has documentation for a PCB layout and suggests that you order the PCB from an online manufacturer. You also have to purchase some other components that must be soldered onto the interface board. Fortunately, I was able to “skip” this step with the help of Leo Selavo, who graciously supplied me with two interface boards. He emphasized that soldering the components onto the interface board requires a lot of skill and experience and if I were to try on my own that I would most likely break the PCB or components several times until I got it right. The setup with pulseox board, interface board, IRIS mote, and finger sensor is illustrated below:
Pulse Oximeter on IRIS
With the pulseox board, interface board, and of course IRIS mote, I was ready to get my heart rate. The biggest challenge still lay ahead: writing code to interface with the pulseox. The CodeBlue pulseox code was written in 2005 for TinyOS 1.0. All of the low level UART and mote hardware interfaces have changed drastically since then, so the old code wouldn’t just work right out of the box. I had seen plenty of posts on the CodeBlue mailing list about implementations for the pulseox in TinyOS 2.x, but nobody had bitten the bullet and actually written anything.
What I wanted was to be able to use the pulseox like a sensor on the MTS300/310 sensorboard: call a Pulse.read() or Oxygen.read() command and get back a uint16_t with pulse or blood oxygen saturation. This is fairly straightforward since I had experience modifying the MTS310 sensorboard code to power on the sensors manually. I created configurations PulseC and OxygenC to provide SplitControl and Read interfaces to power on the sensor and read, respectively. I then wired PulseC and OxygenC to a PulseoxP, which functioned as an intermediary between the application and the low-level pulseox driver code. Like in the original CodeBlue source, I created a BciC configuration and BciP implementation to communicate with the pulseox directly through the UART and return data back to PulseoxP.
The key changes between the CodeBlue TinyOS 1.0 code and my implementation are all found in BciP (or BCIM.nc in the original CodeBlue source). Two issues come to mind. First, setting the mote hardware pins is done differently in TinyOS 2.1. Calls like TOSH_SET_PW0_PIN() are replaced by abstractions. I had to wire MicaBusC.PW0 to the GeneralIO interface in BciC and then call GeneralIO.set() in BciP.
The second difference is with the UART. TinyOS 1.0 uses the HPLUART interface for low level UART communication, but this has been replaced by Atm128Uart0C for the Atmel 1281 architecture. The CodeBlue source code initializes the low level UART to its default state, turns it off, and then sets the hardware registers to the desired UART configuration so that the mote can communicate with the pulseox board. After figuring out what the CodeBlue UART configuration code did, I can’t believe that you can actually write to the registers directly! Imagine if you could do that with user-level code on a PC! To enable transmissions and reception along with interrupts for the UART in TinyOS 1.x, you had to do the following:
// Enable tx/rx interrupts and tx/rx
outp(((1 << RXCIE) | (1 << TXCIE) | (1 << RXEN) | (1 << TXEN)) ,UCSR0B);
TinyOS 1.0 uses the outp() macro to set bits of a given register, but this macro does not exist in TinyOS 2.x. Instead, the UART register bits are configured in a struct with fields for each bit in the register. For the above example in TinyOS 2.1, the following union represents the control register in Atm128Uart.h:
/* UART Control Register */
typedef union {
struct Atm128_UCSRB_t {
uint8_t txb8 : 1; //!< UART Transmit Data Bit 8
uint8_t rxb8 : 1; //!< UART Receive Data Bit 8
uint8_t ucsz2 : 1; //!< UART Character Size (Bit 2)
uint8_t txen : 1; //!< UART Transmitter Enable
uint8_t rxen : 1; //!< UART Receiver Enable
uint8_t udrie : 1; //!< USART Data Register Enable
uint8_t txcie : 1; //!< UART TX Complete Interrupt Enable
uint8_t rxcie : 1; //!< UART RX Complete Interrupt Enable
} bits;
uint8_t flat;
} Atm128UartControl_t;
The flat uint8_t is a real slick way to convert all the elements in the struct to a single word, which can then be written to the register. Following the code that initializes the UART in tos/chips/atm128/HplAtm128UartP.nc, I was able to configure the UART to run with the pulseox board requirements: 4800 baud, double rate, transmission and reception interrupts enabled, no parity checking, 1 stop bit, and 8 bit word size. So, with the previous example to enable transmissions and reception, you do the following in TinyOS 2.x:
Atm128UartControl_t ctrl;
ctrl.bits = (struct Atm128_UCSRB_t) {rxcie:1, txcie:1, rxen:1, txen:1};
UCSR0B = ctrl.flat; // ctrl.flat
I ran my concerns by the CodeBlue mailing list, which elicited a reply from Prof. Matt Welsh that I was headed in the right direction. I finished my implementation, worked out some compile errors, and loaded the new pulseox and general data collection code onto a mote to see what would happen. Almost never does my TinyOS code run correctly on the first try — usually I spend hours or days debugging, but this time it was magic. A number jumped onto the screen in the data column of my PC Java application, which was connected wirelessly though a base station mote to the pulseox mote. The sensor readings seemed reasonable for a heart rate, for jumping up and down and breathing hard made it go up and laying down and trying to breathe slowly made it slow down.
Pulse Oximeter Reading
I have made my code available here and any feedback, suggestions, or questions are encouraged. To use it, place the pulseox directory into the tos/sensorboards directory in TinyOS 2.x. In the makefile for your application, add the line “SENSORBOARD=pulseox”.
The Coast Guard and location prediction using Monte Carlo simulation
In the paper this morning, the front page article was on debris tracking and prediction for Air France Flight 447. Software developed by the Coast Guard in Portsmouth is being used in the recovery effort to predict where debris is located. Ocean currents are used along with the last known location of the plane to predict the most likely places where debris will be found. A density map of location probabilities is shown in the article and I knew without reading it they were using Monte Carlo simulation. This was confirmed in the article.
Using water current and Monte Carlo simulation to predict object positions in water? This sounds really similar to our Sidewinder paper. It’s strange enough that the people who did this debris location prediction practically live right down the block.
There are plenty of differences, though. I would bet that the Coast Guard’s current model is much more advanced than a general group velocity with random deviations for all objects involved. Instead of predicting debris location, we use Sequential Monte Carlo simulation to predict the location of a sink node in a mobile wireless sensor network. The prediction is refined over multiple hops to make routing more reliable and efficient in a highly mobile environment, such as floating sensors routing data in a flood tracking application. A similar density plot to the one provided in the paper is created at each hop for the estimated sink location. This density plot becomes darker and smaller with each hop as the refinement occurs. I’m guessing that the Coast Guard doesn’t use such sequential refinement.
So where’s my front page newspaper article on SMC prediction and flood tracking?
Recent Comments