Journal of Software Engineering for Robotics 5(2), September 2014, 42-49 ISSN: 2035-3928 A middle way for robotics middleware Paul Fitzpatrick Elena Ceseracciu Daniele E. Domenichelli Ali Paikan Giorgio Metta Lorenzo Natale iCub Facility, Istituto Italiano di Tecnologia, Via Morego, 30, 16163 Genoa, Italy Abstract—Robotics is changing. The amount of software available (and needed) is growing. For better or worse, the glue that holds that software together, the middleware, has a big impact on its viability. YARP is a middleware for robotics, with over a decade’s continuous use on various humanoid robots. YARP was designed to help code survive changes, to easily experiment with new code and integrate with other systems. In a world of constant transition, with a steady stream of hardware and software upgrades, YARP helps code last long enough to make a real impact, and avoid premature loss of good code through middleware muddles. We review the features of YARP that support this flexibility, describing those situations in which they have been practically useful. We argue that there are practices that any middleware author can adopt that benefit users of other middleware and raise costs to those users when neglected. Altruism is not required: we also argue a middleware’s own users will benefit from such practices right now (when collaborating) and in the future (when upgrading to a new version of the middleware). These concerns are not usually the first things on a user’s mind when choosing a middleware, but a responsible middleware author will foresee them and prepare a happy ending rather than a trap. Index Terms—Robotics, middleware, interoperability, component-based software. 1 INTRODUCTION find themselves trying to collaborate with others or trying to continue using their software in the future. HERE is growing attention in robotics to software mid- Middleware is a mixed blessing. In the short term it helps a T dleware, some specific to robotics (Player [1], ROS [2], system scale up, but in the long term it can hold it back. Like YARP [3], [4], OROCOS [5], Urbi [6], MIRO [7], LCM [8] operating systems, middleware is “sticky” – developers have and MIRA [9]), others more general (ICE [10], CORBA [11], to make a special effort to make their software usable in other ØMQ [12]). There are several attempts in the literature to platforms. In the short term, for an individual developer, this is compare middleware based on the perspective of its users, no big deal, since other platforms are irrelevant. However, in looking at features and performance [13], [14], [9]. This is the longer term or on larger teams, this is a real cost, paid for adequate for projects that operate on short time scales of a through collaborations that never happen or that get bogged few months or years. For longer time scales, it is useful to down due to platform fragmentation. external also consider the middleware from an perspective. A possible solution is for everyone to get together and When users enter in collaboration with a partner who favors agree to use a common platform. Even with the best of a different middleware, and neither party is interested in intentions, a single platform can become a trap, as more changing, then suddenly a new set of desirable properties and more components come to rely on fragile quirks of that surface. When users of a middleware are faced with a breaking platform, increasing the cost of any changes, even positive upgrade of that middleware, again there is a new set of ones. This is a problem not just because it raises barriers to desirable properties. Properties of a middleware that have new middleware entering a community, but also raises barriers no impact on a user of that middleware when evaluating it to future versions of the middleware itself. Either there will for performance may have an enormous impact when they be a “big bang” change of infrastructure and all the pain that goes with that, or development of the platform will slow to a Short paper – Manuscript received November 11, 2013; revised September 10, 2014. crawl. • The research leading to these results has received funding from the There is a middle way between fragmentation and mono- European Community’s Seventh Framework Programme (FP7 ICT) under culture. We argue that fragmentation and monoculture are grant agreements No. 270273 (Xperience) and No. 611832 (WALK-MAN). problems only if interoperation is made too expensive. As • Authors retain copyright to their papers and grant JOSER unlimited the cost (in terms of complexity) of interoperation is re- rights to publish the paper electronically and in hard copy. Use of the duced, then fragmentation creates less waste, and monoculture article is permitted as long as the author(s) and the journal are properly creates fewer barriers. When thinking about interoperation, acknowledged. standardization and Request For Comments (RFCs) are the www.joser.org - c 2014 by Paul Fitzpatrick et al. P. Fitzpatrick et al./ A middle way for robotics middleware 43 first approaches that come to mind. Standardization definitely is not controlled by your middleware. They may not know for has a role to play, and should be encouraged. Nonetheless, sure what protocol we are speaking. Just as it is helpful for the coordination it requires between middleware developers files lying around in a file system to have a “fingerprint” or is most practical for “solved problems” rather than aspects “magic number” comprising a recognizable pattern of bytes of robotics that are still in flux (of which there are many). early in the file, it is helpful if TCP connections do the same. In this paper, we would like to demonstrate that there are For example, HTTP responses begin with “HTTP/”, and many actions that middleware developers can take unilaterally YARP’s native protocols start with variants of “YA....RP” or to reduce the cost of interoperation. We would also like to other identifying byte sequences. This makes these types of encourage middleware evaluators to take these aspects into messages easy to identify. In contrast, TCPROS begins with consideration, and ask proper questions. For example: does two 4-byte integers representing lengths, which in principle a middleware assume that the entity on the other side of a could have any value. A quick fingerprint up front would network socket is using the same middleware? This would be be very valuable for simplifying interoperation. If one is unfortunate, since sockets are a key opportunity for interoper- expecting a TCPROS connection from a native ROS source, ability. Elaborating further, since this is actually a question it is possible to verify its nature by communicating with the of degree, it could be rephrased as: how complex are the rosmaster name server, so the lack of a fingerprint is not steps an external program needs to take to communicate with an insurmountable obstacle, but we can report that it did raise a middleware-using program without using the middleware’s the cost of interoperation between YARP and ROS. own libraries or utilities? The simpler this is, the lower the There are situations in which a middleware should plan to cost of interoperation. Further examples: does the middeware speak many protocols. Here are situations end-users hit that lay claim to the main thread of a program? Does it dictate the middleware developers do not see: tooling needed to build/compile a program? Two middleware • You need to use a novel kind of network not broadly making such claims will conflict fundamentally. And so on. available. Again, this is not a call for standardization and elaborate RFCs, • You badly need to interoperate at the network level with just individual developers bearing the world outside their software from a different community. middleware in mind, thus benefiting their community today • You have a problem with some aspect of the current (by facilitating collaborations) and in the future (by reducing behavior, and the middleware developers just shrug. the pain of upgrades, and so making radical improvements • You have a network-aware piece of hardware and you more practical). would like to talk to it without bridging. Our goal in this paper is to draw attention to opportunities Indeed, we are not arguing that every middleware should and best practices for middleware developers to reduce inter- support every protocol present and future. We do however operation costs, or to avoid unwittingly increasing interoper- believe that middleware authors have a unique opportunity to ation costs. We focus on steps that can be taken unilaterally, foster collaboration without formal standardization, by treat- without a standardization process. To be clear, we do not claim ing network protocols as something their user communities these steps are more important than standardization, or good will choose and, optionally, contribute rather than something practices by middleware users. They are simply useful steps defined by the middleware. Every middleware supports certain that can be taken as well, and that we have seen omitted models of data flow, but it is worth being flexible about often enough to merit mentioning. To be concrete, we draw how that flow gets expressed concretely on the wire (or on examples from YARP (“Yet Another Robot Platform”), a even on which kind of wire). Of course, it is reasonable middleware for robotics that has been in continuous use on for a middleware to provide default protocol implementations humanoid robots for more than a decade. Those examples suitable for various scenarios. Yet, it is very helpful if new should not be read to imply that YARP is the only middleware protocols can take their place easily and without disruption. to have ever implemented the example feature.