Today's video blog post on the Trossen Robotics System was fascinating -- well worth watching end-to-end. Thank you for putting this online!
I strongly agree that the hobby community needs _basic_ standards for interoperability, not middleware designed to lock us in to particular vendors and/or languages. (To continue Matt's analogy to the PC era, CP/M (and later MS-DOS) provided just enough to keep pace with hardware innovation, while forcing few design decisions that would frustrate software innovation. Contemporary vendor or language-specific OSes were more comprehensive and thus easier to use, but did not succeed. UCSD p-System anyone?)
Anyway, I was disappointed during the Q&A that nobody asked about the Player Project (also known as Player/Stage). It is one of my favorite efforts similar to TRS. Like TRS, it is intended to be OS and language neutral, and tries to provide a kind of 'device API' that allows software to be easily ported from robot to robot.
Judging from the documentation, Player adheres more to the Unix philosophy of character messages exchanged via pipes, whereas TRS adheres more to the 'web' philosophy of XML files and object models.
Besides cosmetics, what are the differences between the two? Does TRS handle things that Player fundamentally doesn't? Will TRS someday support Player as a back-end for its API?
OMG is also trying to be a robot object model. From my reading of their spec, they seem very focused on shoehorning robotics concepts into OMG's existing taxonomy (think CORBA and UML) and not as focused as Player and TRS on real working robots. There are some interesting ideas there, and a ton of conceptual overhead. I don't imagine it spreading to hobby robots very fast.
What other competition is there? What are some reasons that TRS is the one we should be throwing our energy into?