Monday, July 25, 2011

Manifesto for a Robot Standard Interface Specification

This blog post could well turn out to be to be the most boring I've ever written - but I think it's important. I want to write about something that robotics desperately needs: an industry standard interface specification (see I told you it was going to be boring).

Let me explain what I mean by talking about a fantastically successful standard called MIDI, that has without doubt played a significant role in the success of music technology. MIDI stands for musical instrument digital interface. It provides an industry standard for connecting together electronic musical instruments, i.e. synthesisers, computers and all manner of electronic music gizmos. The important thing about MIDI is that it specifies everything including the physical plug and socket, the electrical signalling, the communications protocol and the messages that can be sent or received by MIDI connected devices. With great foresight MIDI's designers provided in the protocol both standard messages that all MIDI equipped electronic musical instruments would expect to send and receive - and recognise, but also customisable messages that manufacturers could specify for particular instruments and devices. In MIDI each instrument is able to identify itself to another device connected via MIDI; it can say, for example, I'm a Roland synthesiser model ABC. If the other device, a sequencer for instance, recognises the Roland ABC it can then access that instrument's custom features (in addition to the standard functions of all MIDI devices).

Robotics needs a MIDI specification. Let's call it RSIS for Robot Standard Interface Specification. Like MIDI, RSIS would need to specify everything from the physical plug and socket, to the structure and meaning of RSIS messages. Devising a spec for RSIS would not be trivial - my guess is that it would be rather more complex than MIDI because of the more diverse types of robot devices and peripherals. But the benefits would be immense. RSIS would allow robot builders to plug and play different complex sensors and actuators, from different manufacturers, to create new robot bodies and new functionality. Imagine, for instance, being able to take a Willow garage PR2 robot and fit a humanoid robot hand from the Shadow Robot Company. Of course there would need to be a mechanical mounting to physically attach the new hand, but that's not what I'm talking about here; I'm referring to the control interface which would be connected via RSIS. The PR2 would then, via the RSIS connection, sense that a new device had been connected and, using standard RSIS messages, ask the new device to identify itself. On discovering it has a handsome new Shadow hand the PR2 would then install the device driver (downloading it from the cloud if necessary) and, within a few seconds, the new hand becomes fully functional in true plug and play fashion.

Industry standards, and the people who create them, are the unsung heroes of technology. Without these standards, like UMTS, TCP/IP, HTTP or IEEE 802.11 (WiFi to you and me) we wouldn't have ubiquitous mobile phone, internet, web or wireless tech that just works. But more than that, standards are I think part of the essential underpinning infrastructure that kick starts whole new industry sectors. That's why I think standards are so critical to robotics.

Maybe a Robot Standard Interface Specification (or the effort to create it) already exists? If so, I'd very much like to hear about it.


  1. Not a boring topic at all. Maybe it just needs to be brought into the light to spark some ideas.

  2. Why thank you. I'm glad you agree this topic should be aired especially if - as you say - it results in new ideas.

  3. Thank you for this blog. That's all I can say. You most definitely have made this blog into something thats eye opening and important. You clearly know so much about the subject, youve covered so many bases. Great stuff from this part of the internet. Again, thank you for this blog.

  4. Wow. Thank you for your *very* kind comments. Much appreciated.

  5. Maybe USB could satisfy this?

  6. Creating an ontology of robot capability might be a good place to start software wise. There is some literature on multi-robot systems using ontological reasoning to work out how to form effective coalitions for a given task. There is no reason why the ontology can't cover hardware, software and behavioral capabilities. Such as a robot advertising it has the hardware "Laser Scanner X" (possibly with the relative location to the querying robot) using "Driver Y" and a behavioral ability "To Follow On Message Z". Then conceivably another robot asks what is possible and makes sure it maneuvers to the laser scanner and sends a follow command.
    In bioinformatics there are vast ontologies of this kind so that all biologists use the exact same vocabulary when annotating genomic data.

  7. Many thanks Roger.

    Yes I agree the USB standard has many required characteristics for RSIS and should be a candidate for consideration - as a starting point. However a possible drawback is that USB is based on a star topology with a central hub. Is that the best topology for robots where there may not be one central controller? Someone should do a study. You..? :-)

    Many thanks also Matt (good to hear from you).

    Yes you make a very good point Matt. A specification should start with an ontological analysis. In your comment you talk about multi-robot systems. I was not thinking here of MRSs, but single robots and the interface between the sub-systems in a single robot (sensors, actuators, communication modules, etc) and the robot's core control module(s). However, I don't see why your ontology approach shouldn't apply equally.

  8. The boring blogs are often the most interesting!

    Some thoughts...

    Two starting point for standards:
    1. Review existing standards
    2. Define requirements for a standard.
    ...and in practice it's mixture of both.

    Existing standards: potential candidates
    * CAN: Maybe not have high enough data rates? In which case: what's being used for in-car infotainment networks?
    * Firewire: like USB but daisychained and peer-to-peer; but not lowest-cost phys and cables, or widespread enough.

    Ideal requirements (strawman starting point):
    * Lowest-cost: low protocol and hardware overhead for (a) small FPGAs, (b) PICs, (c) Commercial off-the-shelf (COTS) 'controllers'; interfacing I/O already present on such devices or added with minimal cost (low-cost external phy). Handling trivially simple sensors as well as robot hands.
    * Data rate: ideally handle some video uncompressed - or accept that high bandwidth data will have to be compressed e.g. using a USB webcam chip.
    * Low pin count cabling.
    * Network size? 256-nodes, 12
    * Power: ability to supply power to sensors (what upper limit?) and feed power in (scavenged power).
    * +lots more

    On balance, I suspect something overlaid on top of USB could well be the best existing solution despite its many drawbacks.


  9. Something got lost in that last post above...
    * Network size? 256-nodes, 12

    Should have said...
    * Network size? 256-nodes, 12Mbps total throughput
    * Potential for wireless interconnectivity as well as wired: (a) wireless connectivity within robot; (b) potential for multi-robot. No distinction within standard between robot/multi-robot/environment.

    - Neil

  10. USB On-The-Go (OTG)( allows OTG devices to directly connect to one another. This may suit your requirements better than standard USB. In addition USB OTG includes power saving features which would benefit battery powered devices.

    Something else to consider,

  11. Hi Alan,

    Is there something special about robots that needs more than than (ethernet || 802.11) supporting TCP/IP and maybe Zeroconf for resource discovery? This stack has a lot of experience behind it.

    The PR2 has a gigabit ethernet network running around the robot, but not without some issues. One of the problems they had was finding cat6 cables in sheaths that don't degrade in contact with joint lubricants!

    For robot-specific protocols over TCP/IP, as you know but your readers may not, there has been quite a bit of activity over the last decade or so. Player and ROS are quite popular and both have Open Source implementations. ROS has dynamic resource discovery that enables the plug and play you describe. It's working right now.

    Combine ROS with TCP over ethernet using RJ45s and cat6, and I think you have a defacto standard version of much of what you describe. All cheap or free, too!

    - rtv

  12. Use Ethernet and the Raspberry Pi for the Individual nodes!

  13. Use Ethernet and the Raspberry Pi for the end nodes!

  14. Many thanks for these great comments Neil and Gary. Your suggestions for a spec Neil make great sense. And Gary I hadn't come across USB OTG before.

    Richard - thanks for your great comment. Yes I confess I don't know as much about ROS as I should, and I kind of suspected that it was TCP based. I really need to get up to speed with ROS!

    And thanks JG. I hadn't come across Raspberry PI - which does look very interesting.