Robotics suffers from an unresolved issue - as a community, we tend to hate the idea of standardization. This isn't a problem in itself, but it can cause issues when programming. Until recently, we were always reinventing the wheel. In this post, we look some good reasons for robotics to avoid code reuse and how we could have the best of all worlds using a familiar concept.
Until quite recently, the robotics community seemed to hate the idea of reusable code. Neither industrial roboticists nor researchers wanted their code falling into the hands of the competition. The result of this was that robotic programming involved a lot of “reinventing the wheel”. If you wanted to implement something in code, you'd have to start from scratch.
Thankfully, this has started to change over the past decade.
Why Robotics Avoided Software Reuse
There are three distinct software approaches which you can find, to differing degrees, in robotics:
- Custom Software: This has been the norm in industrial robotics for a long time. It means that you develop the entire software system for your robot. The advantage is that the software is completely tailored to the system and application. The disadvantages are that it takes a long time to develop, the program is often very "buggy" and the code can be almost impossible to reuse.
- Standard Software: You buy a complete software solution from the marketplace. The advantages are that all of the software is already developed, tested and has support behind it. The disadvantages are that everybody has access to the same software and there may be little innovation as a result. If the software doesn't exactly suit your application, you might just have to live with it.
- Component Software: The software is split up into components, which can be reconfigured to suit your particular application. It has advantages over both the custom and standard software approaches, because using standard software components means more reliability and less development time. You can also program your own software components if the existing options don't suit your application exactly. The disadvantage is that sometimes component pieces don’t match very well.
For a long time, robotics stuck mostly to proprietary custom software, because everyone developed their own custom robots. Nothing was standardized within the community, so nothing could be reused. However, even when more standardized robotic hardware started to appear, the software remained proprietary and often very specific to the robot and its application.
Doesn't ROS Allow Reusable Code?
This changed a bit when ROS came along. Suddenly, programmers realized that it might be okay for others to reuse their code. ROS is the closest thing we've had so far to a "standardized" software. However, as Professor Bill Smart said: "it is vital to realize that we are never going to convince researchers to use a common software architecture, since everyone has strong (conflicting) opinions on this issue." This is also true for industrial roboticists.
ROS is one component based software architecture, but it's not the only one. The problem with this type of architecture is that it can sometimes be overly bloated, especially in industry. It requires a good grasp of programming, takes at least a week to learn initially and ROS even has the restriction that it must be run on a Linux machine over a network.
For some people, this might be more than they need. Is there another way to have the advantages of code reuse without using a whole software architecture?
What About Software Libraries?
For programmers who don't want to run a whole robotic network, there are still ways of reusing useful bits of code. Some of the most useful software libraries use component based concepts. The OpenCV computer vision library, for example, is available in ROS, but it's also a standalone library. You can compile it into your own program and use its advanced functionality very easily.
Software libraries can be useful, but they are hardly plug-and-play. They tend to require more programming, even more than some ROS applications. In fact, all the options mentioned above still require users to write, compile and debug code. What if there was a way to reuse functionality with little or no programming?
The Rise of Plug-ins
Have you ever downloaded a plug-in for a software package? Chances are that you have. It might have been for your web browser, an audio/video editor, your email client or any other popular software. Plug-ins allow developers to add specialized functionality to an existing piece of software. They make it really easy to reuse code. "Plug-in development" is now even a viable business model in some sectors, just not quite yet in robotics.
Plug-ins are a type of component based programming, which generally run using event driven interactions between software components. They allow you to focus all your effort on making one piece of functionality work really well, and then 'plug it in' to the rest of the software through a predefined interface.
For example, in the past if you wanted to program a kinematics calculator for a robot, you would have to go back to the mathematics and program all the equations yourself. With software libraries, you could use an existing kinematics solver, but you would still have to debug your code and interface it with the robot yourself. With a plug-in, however, you could configure the solver for your robot and then use the output to directly control the robot - no coding required.
Could Plug-ins Work for Robotics?
As an industry, robotics is not yet at the plug-and-play level with its software. Several other industries are already there, so there's not far for us to go. Think about software like Photoshop or Wordpress, where someone can develop a plug-in and even turn the plug-in itself into a product. The move towards precompiled (or interpreted) plug-ins is allowing end users to easily access really advanced functionality. We're not there yet in robotics, but we’re working on it, so watch this space.
What plug-ins would you like to see in robotics? Do you think component based architectures are good for robotics, or could there be something better? How do you program your robot systems? Tell us in the comments below or join the discussion on LinkedIn, Twitter or Facebook.
Leave a comment