These are common questions I have gotten of over the last few months. The answer is a minor TFCC issue. I suspect the issue is due (in part) to too much use of multitouch devices in awkward spaces (e.g., airplane seats, cars, various coffee shots). Thus, I have been referring to myself as a “victim of multitouch.” This situation has required me to wear some form of brace for the past few months, which greatly restricted my ability type and answer messages for extended periods of time. Not to mention, I get too much email anyway. I was finally able to stop using the brace this week, just in time for ICRA and ROSCon.

Steven Chu, secretary of the Department of Energy, won a Nobel Prize in 1997 for his work at Bell Labs in the early 1980s. He once said that working in an environment of applied science like Bell Labs “doesn’t destroy a kernel of genius, it focuses the mind.” At Bell Labs, even for researchers in pursuit of pure scientific understanding, it was obvious that their work could be used.

As an undergrad looking towards research, working at Bell Labs would have been a dream job for me, as it epitomized the science-engineering innovation culture. Tangentially, it was a huge honor to meet Jim West, who did pioneering work at Bell Labs as co-inventor of the electret microphone, during the February 2011 ScienceMakers event. I wish places like Bell Labs existed today, or maybe the vision of Bell Labs I had as a newcomer to computer science.

We are screwing up in our design of robot software internet protocols by violating the principle of layering. Specifically we are trying to use ROS TCP to do three two things: serve as an open marketplace of robotic data formats, serve as a robot data transport host level end to end protocol, and to serve as a robotics software packaging and development environment an internet packaging and routing protocol. These three two things should be provided in a layered and modular way. I suggest that a new distinct internetwork protocol is needed, and that ROS TCP be used strictly as a server for back-end robot functionality host level end to end protocol.

– Chad Jenkins, 2012 Jon Postel, IEN 2, 1977

I was inspired being at the NITRD symposium last week and hearing about how realization of the Internet. Luminaries, such as Vint Cerf, often referred to interoperability and increasing accessibility of heterogeneous computing systems as crucial features, as well as a common vision to create digital libraries. The following quote from this interview with Jon Postel hits the point squarely:

Well, certainly the key thing was the transition from the ARPANET to the Internet, and coming up with the TCP and IP protocols that are network technology dependent. The early ARPANET protocols knew a lot about how IMPs worked, and therefore, we not generalizable across the system…you know, from ARPANET to Internet to satellite networks and so on. So the idea that there was going to be several networks of different kinds of physical technology and different kinds of layers really drove this creation of an Internet protocol. And making this Internet protocol so simple that essentially any physical network could do it was really very important, in that… So now we have an Internet that originally ran on ARPANET and Ethernet and back to satellite networks. And the ARPANET is gone, the satellite network is gone, we have Ethernets, but they’re somewhat different than those original ones, and we have new kinds of hardware networks –and the Internet keeps rolling along. There’s nothing changed there. So I think that was a key step in the network evolution…

In this regard, I am further convinced that robotics has yet to learn the lessons of the Internet and network computing. Robotics lacks an applications-layer protocol analogous to TCP/IP for the Internet and HTML/HTTP for the World Wide Web. These protocols provide the level of interoperability that caused the Internet and computing to flourish, enabling legions of applications developers and users. While I am a huge fan of ROS and similar robot middleware/software, it is not the complete answer. I consider ROS and other robot servers to analogize to Apache as the back-end server that does a lot of critical work in the background to provide content to users through a plethora web browsers. It is protocols and standards set by HTTP and HTML that provide this level of interoperability that we have come to enjoy and rely upon.

Even though I can be a broken record about rosbridge, I think it is a good first step towards an applications-layer robotics protocol. If successful, rosbridge should be like the old IMPs that got interoperation between computing systems going, but then faded out as routers became mainstream technologies. Similarly, new and better robot software will continually come and go (with or without Alot of ROS), but the basic interoperability should remain the same.

About a year ago,Monica Anderson were reflecting on these same thoughts a position article we put together (included below) that I hope is a bit more eloquent.

A TCP/IP for Robotics?: Towards Interoperable and Reproducible Robotics

Monica Anderson and Odest Chadwicke Jenkins

Reproducibility and interoperability are crucial for a thriving ecosystem of robotics research and development. In addition to being the cornerstone of the scientific method, reproducibility enables the community of roboticists to validate and build upon the works of others, continually expanding our body of knowledge and technology. Interoperability allows technology to develop faster through common reuse of robotic components across the community. Unfortunately, robotics software and algorithms all too often lack one or both of these properties. Published algorithms, often implemented within one of many frameworks, are not easily made available outside of the original architecture. As a result, much of robotics consists of one-off systems that are difficult (or impossible) to reproduce and reuse, greatly hampering the scientific dissemination of robotics research and fostering a continual “reinvention of the wheel.” Facilitating reproducible and interoperable robotics has been infeasible in the distant and recent past of robotics for many good reasons. However, with the growing emergence of off-the-shelf robot platforms and plentiful network connectedness, the time has come for our community to put our respective pieces together through common and stable infrastructure, towards the germination of robotics applications markets. Think “Robot App Store” [Gerkey 2009].

We argue that robotics needs a standard application-layer messaging protocol to facilitate interoperability between robotics software, through the robotics equivalents of the IETF or W3C. Robotics can be seen as an “extension of the Internet into the physical world” that goes beyond management of digital information and virtual worlds into perception and action in the real world [Christensen et al. 2009]. Similar to our aspirations for robotics, the Internet enjoys widespread levels of interconnectedness, interoperability, and utility that has enabled an evergrowing range of applications that have fundamentally transformed societies across the world. In this regard, robotics has yet to benefit from the lessons of the Internet. The power and prevalence of the Internet is due in large part to having a universal underlying “language” that every device connected to the Internet can “speak”. This universal language is embodied by the Internet Protocol suite and, specifically, its unifying transport and addressing layers, commonly known as TCP/IP. Through TCP/IP, computer networks are now an assumed reliable, transparent media for communication between applications, where the intricacies of the network’s infrastructure are abstracted away through socket interfaces. As such, developers can focus on creating applications at the ends of the network pipe without worrying about the details of the pipe itself, or even the developer of the application on the other side of the pipe.

By focusing on the applications layer, our intent is to highlight the need for common structures and procedures for exchanging data for robotics applications. Many current robotic systems use and even rely upon TCP/IP for transporting data (e.g., perceived objects, environment maps, robot poses, motor velocities, planned paths) between software processes or other robots. Once transported, however, there are no guarantees or standards in place to ensure this data can be understood, analogous to hearing someone speaking a foreign language. As such, data generated by components from different developers often cannot be used within a single application. Although a more accurate title for this piece would “The HTML/HTTP of robotics,” our basic argument remains that a standard protocol will lead to interoperability. Continuing the Internet analogy, the World Wide Web allows applications, such as web browsers, to interoperate using established content formats, such as HTML, with application-layer transfer protocols, such as HTTP, and giving rise to cloud-enabled web services. The prospect of robots serving as and using web services has great promise [Kuffner 2010, Osentoski 2011], but requires application-layer interoperability.

One might ask: doesn’t existing robot middleware already provide interoperability and reproducibility. Answer: Somewhat. Middleware suites provide a software development framework and can be considered the complement to a robotic messaging protocol. Development frameworks are essential for the actual implementation of robotic applications. There are a plethora of robotic middleware environments all with their own relative strengths and weaknesses. Much like with the selection of an operating system, selection of a middleware environment often relies upon the requirements of the robotic environment. However, in order to enable truly wide-scale usage without reimplementation robotic applications should adhere to a particular message structure
and interaction protocol.

Despite the technical capabilities of current middleware systems, there are several shortcomings in these middleware systems that can only be addressed by a consensus of the robotics community for a well-defined, non-proprietary, published, and agreed upon standards for protocols. First, there is no fixed protocol and messaging that applications can rely upon. Typically the protocol is defined only in its implementation. Thus, as the middleware implementation changes, the protocol also changes. Second, core design decisions for middleware systems and their protocols are typically decided
solely by a single research group or company. No single group or company should have the sole power to decide and dictate the standards for robotics. Lastly, there is a significant amount of overlapping functionality between middleware systems. Reinventing or building bridges between overlapping sets of messages and functionality among fragmented systems is both inefficient and messy. A common robotics protocol makes for cleaner code organization and, more importantly, presents a unified interface to applications developers.

Though we have taken a provocative stance in this position paper, we are truly excited about the progress of robotics and emergence of the robotics research and development ecosphere. To make this a reality, our community must come together to provide standards that encourage interoperability and reproducibility in robotics software, potentially through organization that are a robotics version of the IETF/W3C.

[Christensen et al. 2009] H. Christensen, CRA/CCC Robotics Roadmap Committee, “A Roadmap for US Robotics: From Internet to Robotics”, http://www.us-robotics.us/reports/CCC%20Report.pdf

[Gerkey 2009] B. Gerkey, “Towards a Robot App Store”, http://www.scribd.com/doc/17384278/Towards-a-Robot-App-Store

[Kuffner 2010] J. Kuffner, “Cloud Enabled Robots”, http://www.scribd.com/doc/47896204/James-Kuffner-Humanoids2010

[Osentoski et al. 2011] S. Osentoski, G. Jay, C. Crick, B. Pitzer, C. DuHadway, and O. Jenkins, Robots as Web Services: Reproducible Experimentation and Application Development Using rosjs, ICRA 2011.

It was probably the endless viewings of Cars or too much Comedy Central that had me gravitate to this phrase. This statement is now the standard response when someone needs to up their game or does something really cool. When especially awesome, I might use “void main() {r=done;}”

I was never really a fan of the cache memory millionaires, but they did have a hook in one of their songs that was catchy. Going away from common connotations, this condition expresses that that we should produce strong results that impress people.

Additionally, I am also starting to use this statement when I do not understand a point someone is trying to express:

This landed me in the “Joe Normal” category, just near the decision boundary of “Computer Savant” (Computer Science gets such a bad rap):

This is not to say that you don’t have some Nerd, Geek or Dork inside of you–we all do, and you can see the percentages you have right above. This is just to say that none of those qualities stand out so much as to define you. Sure, you enjoy an episode of Star Trek now and again, and yeah, you kinda enjoyed a few classes back in the day. And, once in a while, you stumble while walking down the street even though there was nothing there to cause you to trip. But, for the most part, you look and act fairly typically, and aren’t much of an outcast.

However, Judging from the description of “Computer Savant”, this would have been right on target:

People confuse you with a Nerd all of the time. You aren’t some genius, like some people have said, and didn’t/don’t really like school all that much (and you especially hated some of the social aspects, like getting mocked). It’s just that you have some passions and interests that you’re extremely into/good at, and this has placed you in circles with other social outcasts, some of whom are exceptionally bright.

The awesome thing about being where you are is that you get to hang out with an elite group (though you’d probably rather be alone, or with only the closest friends and family) and you can make quite a good career for yourself in your particular specialities. Common to this group are people who are highly into electronics/computers as that is where the money lies, today.

Just for clarification, “dork geek nerd” is the first entry that shows up in Google’s filter bubble for me.

A special treat that reminds me of undergrad. It brings memories of with 1am episodes of “Law and Order” or “Star Trek: TNG” during kernel compiles, large downloads (by mid 90s standards), working on various programming assignments. However, at 55g of sugar per serving, it is another reminder that I am long past my ugrad days.

My wife just passed along the news that Don Cornelius just passed away. Soul Train has been around a long as I can remember. As a kid, Soul Train was the signal that Saturday morning cartoons were ending, and I had to wait another week for my fix of Spider-Man and Dungeons and Dragons, but grew to appreciate it more as I grew older.

Maybe things would have turned out differently if I had just posted this video a few days earlier:

… or if Eek! the Cat was still around:

Lions-Saints inflight ATL-PVD

One of my New Year’s resolutions is to be better about posting updates. It is a great time to be a roboticist. I am privileged to be a part of a number of great projects. The trouble is that this leaves little time for posts, as well as my many other responsibilities. However, life is short… and so are the NFL playoffs and time to write NRI proposals. Fortunately, Delta’s inflight entertainment and Gogo wifi was a great help during our recent return to Providence from California. One our first leg, I was able to work on a proposal while watching the Bengals-Texans game. Thankfully, this game was on NBC (and not CBS or FOX), or I would have been out of luck. I really like Delta, but they could do better for the playoffs. The second leg did not feature inflight entertainment for the Lions-Saints game, but NBC was great to provide streaming video of the game through Microsoft’s Silverlight plug-in. It was totally awesome to get live video of the game through my browser inflight. While I was highly pleased with my internet connectivity though Gogo, it was not quite up to the task for streaming the game, even at the lowest quality. I caught about every fifth play. After halftime, I switched over the Detroit sports radio that allowed me to at least listen to the game.