Postdoc openings on the RoboBees project

The Harvard RoboBees project (which I blogged about previously) has postdoc openings in the areas of wireless sensor networks, embedded computing, swarm robotics, and biologically-inspired multiagent systems. Check out the job posting here for more details.

Welcome to Stephen Chong and Krzysztof Gajos

Last year was a huge success for faculty hiring at Harvard CS -- we added three new faculty members to our ranks, two of whom are starting this fall. (Yiling Chen started last year -- she works at the intersection of Computer Science and Economics.) Fortunately, we managed to do the search before the present economic unpleasantness; so I'm pleased to welcome Stephen Chong and Krzysztof Gajos to Harvard.

Stephen got his Ph.D. from Cornell and works in the area of programming languages and security. His work on the Swift system (published in SOSP'07) allows one to build secure Web applications where the client- and server-side code are automatically partitioned from a single, unified program written using the Jif variant of Java, which incorporates support for information flow in the programming model. This is a very practical approach to providing information flow support in a real system.

Krzysztof got his Ph.D. from University of Washington and is the first HCI person that we've hired at Harvard. Actually we've been looking to hire in this area for some time, but never found someone we really liked -- until Krzysztof. He is a great match for the kind of multidisciplinary work that we do here. Among other things, he developed the SUPPLE system, which automatically generates user interfaces for users with motor disabilities -- a nice combination of HCI and machine learning work.

Harvard grad students can look forward to the fact that Stephen and Krzysztof are both teaching graduate seminars this term.

(On a related note, I am delighted to have a new name-spelling challenge on my hands. It took me a couple of years to learn how to spell Mema Roussopoulos' surname without looking it up -- I am resisting the urge to create a macro for Krzysztof. This reminds me of my colleague from Berkeley, Rob Szewczyk, who once cheekily explained to me that his name is spelled exactly as it is pronounced.)

WhiteFi: Wi-fi like networking in the UHF White Spaces

This week our paper, joint with Microsoft Research, on White Space Networking with Wi-Fi Like Connectivity was presented at SIGCOMM 2009, where it actually won the best paper award. This paper lays the foundations for the first Wi-Fi like network operating in the UHF white spaces (that is, the portions of the TV spectrum unoccupied by TV channels, wireless mics, and other devices). There's been some press on this work from Technology Review, Engadget, and other sites. My student, Rohan Murty, gave the talk. He is pictured to the right, apparently wearing the UHF antenna on his head -- I am not sure whether this improves his mental capacity or not. (Update 8/24/09: The slides are now available.)

By way of background, in 2008 the FCC issued a ruling allowing unlicensed devices to operate in the UHF white spaces, under certain restrictions. Opening up this spectrum for unlicensed wireless networks is a huge opportunity -- for example, UHF devices would achieve much longer range than networks operating in the 2.4 GHz and 5 GHz ISM bands. There's been a lot of recent research on establishing individual links in the UHF white spaces, but to our knowledge nobody has proposed a network design allowing multiple clients to communicate via an access point. That's where WhiteFi comes in.

Networking in the UHF white spaces raises a number of interesting challenges. The first is that the spectrum is fairly fragmented, and we can make use of variable-width channels (unlike the standard 5 MHz channels used by existing 802.11 networks). This makes AP discovery more difficult since there are many combinations of center frequencies and channel widths that would require scanning.

The second is that, by FCC mandate, a white space device must avoid interfering with any "primary users" of the spectrum. TV channels are relatively easy to avoid, given that they don't tend to come and go (although a mobile device would need to determine when it is coming in range of a new station). It turns out that wireless microphones also operate in this band, and of course you can't predict when one might be turned on. This requires the use of channel sensing to rapidly determine the presence of a wireless mic and mechanisms for switching an access point and any associated clients over to a new channel when interference is detected.

In WhiteFi, the key idea is to use a software-defined radio to scan the physical RF channel and use an efficient algorithm for performing AP discovery without performing a full decode on the signal. The SIFT technique (described in the paper) is a simple time-series analysis of the raw samples from the SDR that quickly determines if there is an AP operating at the chosen center frequency, as well as its probable channel width. The SDR is also used to detect incumbents. WhiteFi also includes algorithms for assigning channels to APs based on spectrum availability, as well as for handling disconnections due to interference or station mobility.

Going forward, we are continuing to collaborate with Microsoft Research and are developing a white space testbed here at Harvard that will allow us to experiment with these ideas at larger scales. Ranveer Chandra, Thomas Moscibroda, and Victor Bahl from the Microsoft Networking Research group are all involved in this effort.

RoboBees - A Convergence of Body, Brain, and Colony

I'm part of a team that was recently awarded a $10M NSF "Expeditions in Computing" grant for a project to develop an autonomous colony of robotic bees. This is a big effort headed up by Prof. Rob Wood at Harvard and includes a team of 11 researchers in Computer Science, engineering, and biology. The project title is RoboBees: A Convergence of Body, Brain, and Colony, and you can check out the preliminary project website here. I'm very excited about this project as it will open up a lot of research directions for programming complex behaviors in a coordinated swarm of tiny aerial robots.

The press release from Harvard describes the project as follows:

A multidisciplinary team of computer scientists, engineers, and biologists at Harvard received a $10 million National Science Foundation (NSF) Expeditions in Computing grant to fund the development of small-scale mobile robotic devices. Inspired by the biology of a bee and the insect’s hive behavior, the researchers aim to push advances in miniature robotics and the design of compact high-energy power sources; spur innovations in ultra-low-power computing and electronic “smart” sensors; and refine coordination algorithms to manage multiple, independent machines. [...]

Now, what is interesting is that the release never explicitly mentions the central theme of the project -- that is to build a colony of robotic bees -- nor the title of the project ("RoboBees"). Apparently the PR machine at Harvard got nervous about some aspect of this and, despite the NSF's large investment in our project, decided it was better to tone down the language. Baffling.

Cutting through the PR fog, you can read the full description of the project on our website, as well as the award description from the NSF, which makes it pretty clear what we plan to do.

Sensys 2009 PC meeting

The Sensys'09 PC meeting was held here at Harvard a couple of Saturdays ago. I meant to post about this earlier, but a little something got in the way.

This year we had 119 full paper submissions (down a bit from last year) and accepted 21 papers, for an acceptance ratio of 17.6%. This is similar to the acceptance ratio for previous years, and I think it represents a healthy level of competition for the conference. Personally, I would have preferred that we accepted closer to 25 papers, but at some point there's only so much pressure one can put on the program committee to make that happen. The full list of accepted papers is here. It is a very strong program and Jie and I are both extremely appreciative of the program committee for all of their hard work.

Overall, I was very happy with the reviewing process this year. The model we used for Sensys was similar to other top-flight systems conferences: PC members do the reviewing themselves (rather than farming out to external people or students); they write detailed reviews; and everyone has to attend the PC meeting in person. The program committee did a fantastic job and worked very hard to make this happen. On average each PC member reviewed 22 papers. We reviewed papers in two rounds. All papers were assigned three reviews in the first round. Roughly 50% of the papers were considered in the second round and got at least two additional reviews, sometimes more.

During the PC meeting, we grouped papers roughly by topical area, rather than simply ordering them globally by score. This made it possible to directly compare multiple papers on, say, time synchronization during the discussion. I think this worked very well as it provided more context for the discussion on a given paper and often some of the same PC members were involved in reviewing papers in a given area. At the end of the first pass we had roughly 15 papers in the "accept" list and about the same number in the "maybe" category. We then went through a second pass on the "maybe" papers to come up with the final list. The PC was generally very positive during the discussion; and in a few cases a reviewer with an initially negative reaction to a paper was able to reconsider as the rest of the program materialized.

One thing I am mindful of is that it is sometimes harder to accept a paper when it has "too many" reviews. At SIGCOMM, NSDI, and other conferences, I've seen papers get 7 or more reviews in the final round. My concern is that beyond a certain point enthusiasm for a good paper tends to wither with more reviewers weighing in on it. We recognize that no paper is perfect and the question was which papers were both technically sound and interesting enough to constitute a good program. The two-round process seemed to strike the right balance. I did not feel that we were accepting or rejecting papers based on not enough information.

We also had a fairly diverse program committee this year, including some folks representing areas not traditionally associated with Sensys. Part of our goal here was to ensure that the PC was not too insular and that we got a broad range of opinions. We also wanted to broaden the scope of the conference to encompass non-conventional sensor networks. We have a few good papers involving application case studies as well.

It should be an exciting conference - hope to see you in Berkeley in November!

Going Green with Electronic Proceedings

We're looking into the options for publishing the proceedings for SenSys 2009 (which I'm co-chairing with Jie Liu). Sensys is an ACM conference and traditionally has had a printed proceedings. I'm interested in what people think about an all-electronic (that is, online) proceedings, with no printed copies or CD-ROMs. The idea would be to put the PDFs on the conference website and ensure that they are archived by the ACM Digital Library. (Assuming, of course, that ACM would allow this -- I haven't looked into their policies.)

SenSys is an ACM conference, and has traditionally had printed proceedings. As anyone who has been a conference organizer knows, this can often be a cumbersome and slow process, requiring many weeks of lead time from the publisher, and quite a lot of work on the part of the authors and the publications chair. This also shortens the time available for paper shepherding. Going the traditional route also incurs a nontrivial cost which is passed down to every conference attendee, whether they want the printed book or not. Finally, there is an environmental cost to all those dead trees that never get read, and to physically ship out the proceedings to all of the SIG members.

Personally, I don't have a need for printed proceedings. I get my papers online, through Google or the ACM DL. I realize there are still plenty of people who want to hold a physical paper in their hands, which is what printers are for -- indeed, if we put the PDFs online a week or so before the conference, anyone who wants to flip through the papers physically could print them out themselves and bring them to the conference. Printed proceedings seem to me to be a holdover from the time when scientific literature was chiefly distributed through printed books and journals archived in libraries. That is not the reality today. Many journals have now gone all-electronic, so it seems odd to me that a conference could not go the same route.

At the same time, I realize there are some (real or perceived) downsides to electronic-only proceedings. There is a question about whether it really constitutes a "publication," and I have heard that some institutions in Europe and Asia expect a printed proceedings in order for a paper to "count." (I have no hard evidence of this so would like to learn more.) The copyright issue becomes a little sticky, but I think that it would work fine to allow authors to retain copyright in their papers but require that they release them under a Creative Commons license permitting the conference organizers, and ACM, to distribute them. Finally, do electronic-only proceedings diminish the gravitas of a paper being accepted into a major venue? I would hope that those bulky yellow-spined books alone do not impart validity to a conference paper, but you never know.

So, I'm curious to know what others think about going all electronic.

Learning to write

The Chronicle of Higher Education has a great article on the importance of writing skills for graduate students. (Thanks to Jitu Padhye for the pointer.) Though nothing in the article surprises me, the article highlights a widespread concern about the lack of formal writing training for grad students. Learning to write effectively is one of the most important skills you need as a grad student, and, of course, as a researcher or faculty member later in life. But we don't actually teach this skill. Most faculty (myself included) seem to expect students know how to write, or will somehow pick it up in the course of their research -- and, presumably, having enough conference papers rejected. Even worse, most students don't realize how bad their writing is. This becomes a real problem if you're a new faculty member trying to get funding, and people can't follow your papers or are unconvinced by your grant proposals. Good writing is everything.

I'm not sure how to solve this problem. Putting my grad students through dry technical writing classes doesn't seem to be the answer. Good scientific writing involves a great deal of subtlety. It is not just about being grammatically correct, but conveying ideas in a convincing manner. This is especially true in computer science, where the goal of most conference papers is to persuade -- to seduce the reader with a Big New Idea, not just to report on the results of a study or new finding. Many courses on scientific writing fail to meet the needs of CS, focusing instead on the dry presentation of methods and data. That is important in CS, of course, but if you compare the structure of your typical Nature or Science article to, say, an SOSP paper, the differences are stark. (On the flip side, I often find CS papers tend to fluff up a fairly simple idea with a lot of marketing to make the ideas seem more earth-shattering than they really are. Seriously, how is a minor tweak to the 802.11 MAC protocol going to change the way we think about the nature of human communication?)

Any suggestions on better ways to teach our grad students how to become great writers?