Subscribe
You’ve seen the introduction video; now its time to get down to business. This episode is for anyone who wonders what Sensorpedia is, how it is innovative, and how it fits into The Internet of Things. Jason Frank films himself and fellow team members David Resseguie, Tim Garvin, and Ashley Dailey in this behind-the-scenes look at Sensorpedia.
It’s hard to believe 10 weeks have already passed, but the summer internships at ORNL wrapped up today. I big Thank You! is in store for all the hard work this summer from Ashley Dailey, Jason Frank, and Tim Garvin. All three played a critical part of making this a very successful and productive summer for Sensorpedia. I realize that not much has changed on the Sensorpedia web application during the initial beta (alpha?) release. But we haven’t been sitting still either. We’ve actually been using the Sensorpedia software (primarily the backend services) on a number of other projects here at ORNL for our government customers. Ashley, Jason, and Tim have played a big role in incorporating much of the lessons learned from these other projects back into Sensorpedia proper. Stay tuned for several blog posts from the team that I’ve got queued up to explain several of the latest changes. And you won’t want to miss the latest video that’s in the works either…
You’ve been waiting for it… now view the Teaser, Opening Scene, and Opening Credits in this first installment. Jason Frank films himself and fellow team members David Resseguie, Tim Garvin, and Ashley Dailey in this riveting (or use your own cliche word) behind-the-scenes look at Sensorpedia. Enjoy.
In many ways, it was just another day of class. But as I sat there awaiting the final exam of my first graduate computer science course, Advanced Algorithm Analysis and Design, I wondered if my studies had prepared me to succeed at this level. Most of the students surrounding me were PhD students, and their experience in this subject was greater than mine. For a moment my mind flashed back to a time three years earlier. It was the day I told my wife that I wanted to go back to school, starting over in a new subject, to get a Masters degree in computer science. Then I plotted a course to make it happen.
Unlike the degree that I completed nine years earlier, there were no liberal arts or elective classes in my plan for this new degree; it was all math and computer science. I wasn’t sure how well I would fair since the last math class I had taken was when I was a junior in high school. But I moved forward with my plan and one by one, I received an “A” in all of the undergraduate math and computer science courses that led to me sitting in that classroom surrounded by fellow graduate students. Would this class end in the same manner?
Two weeks later, I was walking across the campus of the Oak Ridge National Laboratory. I was starting my second summer internship with Sensorpedia, so I was heading to over to meet up with my mentor and lead developer of Sensorpedia, David Resseguie. After catching up on what we’d been up to the past several months, David told me that one of my first tasks of the summer was to write a blog post. He said to write about something I had learned this past school year. For those of you that don’t know David, that might sound a little silly… to just write about something that I learned. For those of you who do know David, you know that learning is very important to him. He knows that good ideas can come from a wide variety of sources, and a great way to facilitate that is to continue to learn new things.
For those of you still hanging on to my opening story about my Advanced Algorithms class, I can happily report that my 4.0 GPA in this subject remains intact. So the question was now before me: Of all the things I learned this past school year, what did I feel was worthy of writing about for this blog? A quick thought back revealed several possibilities. Should I write about the inner workings of the proof of Rice’s theorem from Theory of Computation class (which gives us the fact that only trivial properties of programs are algorithmically decidable)? Or should I write about the mangled NP complete proof for the Hamiltonian Cycle problem (where we transform an instance of Vertex Cover to an instance of Hamiltonian)? Perhaps the topic should be more programming related. I could write about the nights spend debugging my bipartite network flow program. Or just as easily I could tell of my experiences implementing Unix pipes. Which topic truly deserves the honor?
To answer this question, I will ask one of my own. Why do we ask our kids to clean their rooms? Is it to rid ourselves of the feeling the chaos? Sure. But isn’t another main reason that, as adults, we understand the importance of having the things we need access to accessible when we need them? We know that the investment of time to clean one’s room pays off. Now, how does this relate to my past semesters of math and computer science studies? As I reflected over these months of study, it dawned on me that the things that I truly learned were things that I had already learned before: the power of preparation, hard work, and in particular, organization. Of all the things that I’ve studied in this journey of my new degree, it is these simple, timeless qualities that I have again learned to be priceless. It’s true that I might not have the raw intelligence of some of my classmates. But I have found that I can make up that difference with these other qualities. I found that if I spent the time necessary to organize complex issues, I could perform at a high level. I found my investment of organization paid off.
Others also know the power of organization. When Bryan Gorman and David Resseguie started Sensorpedia, they knew the potential of organizing the world’s sensor data. Sensor data was somewhat available, but not organized. One type of sensor data was often times not compatible with other similar types of sensor data. There was one proprietary format after another. It was harder to have access to certain data when you needed it. Sensorpedia seeks to fix these problems. It seeks to organize complex issues and data sets, so that our users can perform high level tasks. How ironic is it that my lesson learned has been a core goal of Sensorpedia all along?
Just before leaving for the Christmas holidays, I got some good news! Our application for an Apple iPhone development license was approved. The process took much longer than I had hoped, primarily because a national lab is not a typical “business” and the usual application process didn’t exactly fit. But I’m happy that we’re all set now. I’ve got the SDK installed and will begin actual development soon.
I’m excited to build on the outstanding work that Chris did this past summer in building a prototype Sensorpedia app. Chris focused primarily on submitting observations from the phone. Be sure and click through his presentation on “enabling citizen sensors” and read the related blog post. I’m working now to add a mobile viewer component to allow you to search for and view nearby sensor data.
Hopefully we’ll get the details worked out soon and you’ll find us in the app store! Of course, you’ll be the first to know by following us here on our blog and on Twitter.
As we move Sensorpedia from a limited beta (with a sneak peek) to an open beta, we have an important decision to make. We are currently evaluating multiple authentication options for Sensorpedia. Some of the options we are currently evaluating include:
Each of these options has pros and cons. We need to consider both technical issues (ease of implementation, robustness, networking/firewall limitations) and functionality (features, user base, flexibility). Our original plan for Sensorpedia was to simply use OpenID to offload the authentication process by supporting a number of (all?) OpenID providers. That is valuable in and of itself, but we’d still have to develop and maintain all social networking functionality ourselves. That certainly offers a lot of flexibility, but it’s hard to ignore the benefits one gains from leveraging the existing social networking capabilities of APIs from companies like Google, Facebook, and Twitter. Each of these company’s offerings have some real strengths. Google Friend Connect is easy to use and has a wide variety of widgets available. It also doesn’t tie you to a specific social network. Facebook Connect is attractive because of its size (currently 300+ million users!) and you immediately get the benefit of users’ existing social graphs for sharing and managing groups for access control requirements. Twitter is also nice because of its popularity, asymmetrical connections, and because it’s used more for non-personal communication (which probably fits Sensorpedia’s user base better). The situation is further complicated now that Google and Facebook both support OpenID and Facebook even allows you to log in with your GMail credentials.
So which path should we take? We need a solution that we can implement quickly and also gives our users the greatest set of features for sharing information, managing their social graph, and supporting data mashups. We also want to keep in mind the desire to open source the Sensorpedia software and make it available to run within an enterprise and on secure networks. (Think Wikipedia / Intellipedia.) Would the social networking functionality provided by Google, Facebook, or Twitter have to be reimplemented anyway for such scenarios? These are all issues that we are discussing internally on the Sensorpedia team. We’d love to get your input as well. Please share your thoughts in the comments or get in touch with us on Twitter, Facebook, or LinkedIN.
As we move forward in this area, we’ll begin consolidating our discussion and documentation on the Sensorpedia Developers Wiki.
We value your input and look forward to hearing from you!
Besides automatically discovering new sensor data, I’m also interested in what to do after we get the data into Sensorpedia. Right now users interact with Sensorpedia via the web mapping tool. Users type in a search term that matches the title, textual description, or user-supplied tags and generates a list of geo-indexed placemarkers. This is pretty useful (and cool to view), but there are limitations.
Unfortunately, the data in Sensorpedia is mostly formatted to be consumed by human viewers. Click on one of placemarkers and you may find an HTML table, an XML file, or a png file of a graph. This can make interacting with the actual data a bit difficult. However, if we are able to parse the data, then we may be able to do more interesting and dynamic things with the data.
What sort of tool might we use? In previous (and ongoing) research, I developed Tables, a spreadsheet-inspired programming tool for sensor networks. Tables supports flexible data querying, local computation that executes on individual sensor nodes, and collective functions that can aggregate data from multiple nodes. I thought that this may be a useful tool for Sensorpedia, so I began porting a basic version.
I began by first writing scripts that parse the pages provided by the DASMet weather towers at ORNL. (search for “dasmet”). Next, I wrote a Java interface for a virtual “sensor node” that stores this data and implements an interpreter for the Tables spreadsheet language. Finally, I linked up the Tables interface to this virtual sensor network.
The first video shows different ways of querying the sensor network using a tool called a “pivot table”. The user is instructing the virtual sensor network to display the URLs associated with each DASMet tower with the unique ID of each virtual sensor node. Next, the user is constructing a more useful query asking for the Temperature values associated each tower. The video progresses through several more queries that includes additional metadata visually organized in different ways. The final query shows the user correlating two different sensor data.
In the second video, the user constructs a query to view the Temperature data again. Afterwards, the user writes a function that records whether the sensor node has any Temperature values greater than ‘60′. This function is executed on each sensor node and is automatically executed whenever the node gets new Temperature values. Now the user can construct a query to view which sensor nodes exceeded the threshold value. Although our example does this immediately (and so we don’t have any surprises), we could leave the sensor network running longer to accumulate these values.
Afterwards, the user types in another function to average the Temperature values. Unlike the previous function, this function is typed into the “t = 1″ sheet. This makes it so that the function collects data from multiple sensor nodes (instead of executing over a single node). Whenever a sensor exceeds the Temperature threshold, it will contribute data to the average.
So we see how using a combination of pivot tables, local functions, and collective functions the user can write some interesting and dynamic code that runs over both real and virtual sensor networks. The key, of course, is actually creating the virtual sensor network. Currently Tables only works with the DASMet towers. In the future, I hope to find a scalable way to get Tables to work over more of the Sensorpedia data. This will be difficult since different data sources present data in a different way, but we may be able to extend the virtual sensor node concept so that users can submit “scripts” for each sensor source that converts the native data format to a more structured format.
Well enough for this post. Like always, feel free to leave suggestions, comments, and results…
Summer 2009 was great time for the Sensorpedia program. I’m very thankful for the all the new ideas, innovation, and enthusiasm shown by our seven summer interns. We had a great team that was very productive. (And we had a lot of fun too!)
Sensorpedia 2009 Summer Interns
If you’ve not already done so, please take a few minutes to check out the student’s blog posts detailing their efforts on everything from an iPhone application to a Sensorpedia Python library. By the end of the summer we had over 3,000 sensors registered with Sensorpedia monitoring everything from weather to volcanic activity. The guys had a great impact on improving how we (collectively) share information. Thank you!
The students also gained experience and sharpened skills that will be valuable to them throughout their career. I have started encouraging interns to read several books as part of their learning experience at the lab. My recommended reading list contains books in categories that I think are important for Computer Science interns to read. In this list you won’t find the typical CS related titles, but rather a number of books designed to stretch your thinking a bit. If you are a student or are working in this area, I highly recommend you check out some of these titles. Contact me if you’re interested in learning more about internship opportunities at ORNL.
Looking forward…
Stay tuned for more updates on where we’re heading with Sensorpedia. We’re looking to build on the momentum of this summer as we move soon from private to open beta. Sign up to be notified when we make the switch. We’ll also be announcing here on the blog and on Twitter.
The sun has set on my first summer internship with Sensorpedia. What was I involved with during these ten fast weeks? It was a summer filled with learning unexpected topics, using the Sensorpedia API to register new sensors, filming a new Sensorpedia video (and in turn, showing my ability for gaffes), helping Sensorpedia advance through its beta stages, and creating a new application for registering sensor data.
This new application is called addSensor. As this blog title states, it is a new interface that allows users to register their sensor data to Sensorpedia without needing to learn anything about our Application Programming Interface. My addSensor application takes care of all the required programming tasks behind the scenes for the user. For more detailed information about addSensor (including screen shots and why it is important), check below this text to see the poster that I created for the 2009 ORNL summer student poster session on August 5, 2009. In the remainder of this blog, I will make two main points about this application.
First, it is dynamic. Focus was paid to creating an interface that didn’t overwhelm the user, yet had all the features necessary to create full fledged, data-rich sensor feeds. This was accomplished by making only the minimally required data fields immediately accessible, with the other fields dynamically accessible as the user’s needs dictated. It also has lots of tools (and tooltips) to help the user along the way. For example, a map can appear if requested, with a draggable marker that generates the associated latitude and longitude. Also, various preview options provide immediate confirmation of successful entry by the user. Smaller interfaces within the addSensor interface, such as calendar and time tools, help round out the overall functionality.
Second, it is a work in progress. There is an old saying in the video production field that says, “With enough time and money, you can create almost anything.” I’ve found that this saying holds true in computer science as well. Creating all of the dynamic options of addSensor certainly took some time and means that there are some parts of the application that still need attention. However, I believe that the application as a whole represents strides in the right direction toward a great tool for Sensorpedia.
Sensorpedia Poster - Jason Frank
I have many people to thank for my internship. First, thank you to those who wrote letters of recommendation for me regarding this internship. Second, thank you to the organizations that fund Sensorpedia. Thank you also to the organizations that funded my internship (ORNL, ORISE, DOE CCI). Finally, thank you to the people that I worked with at ORNL: the other summer interns, project leader Bryan Gorman, lead Sensorpedia developer David Resseguie, and everyone else around the Sensorpedia lab and the CSED. Your guidance and camaraderie made it a fantastic experience!
The word “iteration” is used a lot in certain fields like computer science, mathematics and music, where a repetition of steps is often necessary. An iteration is often a new or different version of something. Whether you’re 
already familiar with this word or not, you know about it in a basic human sense. Take for example the phrases, “A second chance”, “Learn from your mistakes”, and “There’s no substitute for experience”. These all speak to the truth of what new iterations can bring. But before new iterations can come, there has to be a first time. This summer at Sensorpedia there were several first iterations going on. Several of them were first times for me, and some of them were first times for Sensorpedia.
What kind of first times? For me, it was my first time interning in a major research environment. Also, the new addSensor application that I developed underwent its first iteration (although Chris Tomkins-Tinch first created an early predecessor to it). Sensorpedia’s first times included reaching new registered sensor milestones, advancing its main web application, and collaborating with its first group of private beta testers.
The important part about having finally done something for the first time is realizing what the next iteration can hold. The leaders of Sensorpedia are figuring out ways to formalize existing technologies to create a powerful web 2.0 site for sensor data and other types of information sharing. Now having many of their first iterations underway, their position reminds me of an event that occurred a little more than one hundred years ago.
It was the year 1900 when two brothers from Ohio left their bicycle shop and headed to the breezy dunes of Kitty Hawk, North Carolina. They were thought to be crazy for their belief that controlled, powered flight was possible- but even crazier for going to actually do it. Wilbur and Orville Wright’s first iteration of their “flying machine” that autumn was with a glider. Flying only as a kite not far above the ground, Wilbur rode the glider while testing wing-warping and other control techniques. This led to follow up iterations in the summer of 1901 and the fall of 1902. Through persistent experimentation with their gliders, they discovered that only three keys existed to controlled flight: pitch, roll, and yaw (the three axes). Armed with that important discovery, the Wright brothers set out the following year on their next iteration. It was then that they added another element to their flying machine- a single speed aluminum-cast motor. They paired the motor with a new kind of propeller (inspired by what they had seen on ships) to create the means to power the plane. Then on December 17, 1903, the brothers successfully flew their new machine four times.
Those first controlled, powered flights weren’t much by today’s standards. The longest of those four flights that day was a mere 852 feet- and if we were witnesses that day we might have said that “controlled” was stretching it. But after that day, it took less than 66 years to put men on the moon and return them safely. It all started with Wright brothers’ first iteration flying machine.
Like the Wright brothers before us, we now look toward the next iterations of Sensorpedia’s projects. What can we learn from this summer’s first iterations?
