Robotics Business Review surveyed technical professionals whose companies develop robots or robotics technology. The results provide technology suppliers, developers and their managers, and others with an adoption profile for the tools, standards, and platforms used for the development of robotics systems.

Introduction
The development of robots and robotics technology requires the mastery of multiple disciplines—primarily software development and mechanical and electrical engineering. Robotics development is made even more difficult as it is limited by embedded and real-time constraints. But real-time concerns are only the beginning, especially as robots and robotics technology become more prevalent in the home, the workplace, in public places, and on the battlefield.

Commercial viability adds additional burdens for the robotics developer—the resultant systems must be innovative, robust in the extreme, work as advertised, and yet be competitively priced. It is clear that success for such an endeavor requires a thorough understanding of systems, systems engineering, design goals (and a clear delineation of those goals), a rigorous development process, and an adherence to both de jure and de facto standards whenever possible.

The next generation of robots and robotic devices must also be integrated with other systems in their environment. Solution providers have responded to these difficulties by providing a host of robotics design and development tools, as well as ready-made robotics “platforms” that dramatically simplify the job of designing, developing, testing, and manufacturing robots and robotics products.

In an effort to increase the pace of robotics development and advance the robotics industry as a whole, Robotics Business Review surveyed approximately 250 technical professionals involved with the production of robots and robotics technology, to determine how robotics design and deployment solutions are currently being used and will be used in the future. The resulting adoption profile provides solution providers, engineers, and the investment community with a basis for informed decision making.

Respondent Profile
Unlike earlier research untaken by Robotics Business Review, the Robotics Development Tools survey was directed at robotics professionals—specifically, those who could affirmatively answer the following qualifying question: “Does your company produce robots or robotics technology, or produce enabling technology used in robotics or robotics technology?” The survey instrument was emailed to the attendee list of Robotics Trends’ RoboDevelopment Conference and Exposition and RoboBusiness Conference and Exposition. Respondents who replied to the online questionnaire were placed in a raffle for an iRobot Create Premier Development Package. There were 253 completed questionnaires.

Survey respondents represented a wide variety of vertical market segments and business types (Fig. 1). The survey focused on robotics development. As such, it was expected that the majority of the respondent base listed “Robotics/Robotics technology” as their primary business (28%). Members of academia made up the next largest group (23.6%). After robotics companies and academics, the respondents to the survey were well distributed among various industries, with no one group representing more than 7.6% of the respondent base (Software Development/VAR/ISV).

Approximately 70% of survey respondents indicated that they are involved with research and development efforts, a figure that is in keeping with the large percentage of academicians represented in the sample, as well as with the fact that R&D is a primary task for commercial robotics developers (Fig. 2). The critical roles that “Software Engineering” and “Systems Engineering” play in the development of robotics systems were evidenced by the large percentage of respondents indicating these duties as being part of their respective company roles. Slightly more than 56% of the survey respondents indicated they had more than one development role to play in their company, with the average respondent responsible for more than three separate roles.

Although the defense industry was well represented, most survey respondents reported developing robots and robotics technology for research and academic markets (Fig. 3). Only 7.5% of the respondents indicated that they were developing products for markets other than research, defense, industrial robotics, consumer robotics, education, or healthcare. Fifty-one percent of the respondents noted that they develop for more than one market, while the average number of target markets was 1.9.

Survey respondents came from a wide range of companies, from small start-ups and growing midsize businesses to the largest global corporations. As you would expect from a nascent industry, such as robotics, most survey respondents work for small companies—approximately 59% come from companies with less than $50 million in revenue for their last fiscal year (Fig. 4). Large companies—those defined as enterprises reporting more than $1 billion in revenue—make up approximately 12% of the sample base, while 15% are midsize companies ($50 to $99 million). Approximately 13% of survey respondents listed “Other” as a revenue figure (unknown, academics, nonprofits, etc.). The average gross revenue among responding companies is $176 million.

STANDARDS AND REFERENCE MODELS
As described in Figure 5a, survey respondents ranked “PC Standards” and “COTS Technology” (commercial-off-the-shelf technology) as being more critical to their robotics development efforts than other forms of standards and reference models. The case for the criticality of PC standards and COTS technology for robotics development becomes even stronger when considering the percentage of respondents selecting “Critical” for a given standard or reference model (Fig. 5b). It can be seen that “PC Standards” is considered the most critical aspect (28% of respondents). “Generalized COTS Technology” is second, with approximately 14% of the survey respondents considering it to be critical to their robotics development efforts.

No governing body or consortium formally declares de facto standards. Rather, they grow to become standards through an increase in market share. “PC Standards” are the de facto standard hardware and software included in Windows-based PCs—for example, the Windows family of operating systems, the Win32 API, the Intel x86 family of processors, and USB connectivity as well as Bluetooth and 802.11 capability.

Implied in the definition of COTS is that the so-called standards have enough market share to earn a place on the shelf. In many cases, COTS technologies are de facto industry standards by virtue of their large market share—to illustrate, x86-based chip sets are both a COTS technology and a de facto standard. Therefore, for providers of robotics development technologies, the ideal COTS technology is both commercially available and commercially successful (shipped in volume).

As can be seen in Figure 5b, survey respondents ranked de facto industry standards “PC Standards” and “COTS Technology” as being more critical than the other standards listed in the survey. However, it should also be noted that only 28% of the respondents listed “PC Standards” as “Critical.” Other than “PC Standards” and “COTS Technologies,” all other industry standards received tepid overall rankings (Fig. 5a). This is a reflection of the nascent state of the commercial, nonindustrial robotics market(s), and the limited number of mature standards in place for robotics development.

In contrast to de facto standards, de jure standards are defined and ratified by official committees or governing bodies. The three standards following “PC Standards” and “Generalized COTS Technology” in Figures 5a and 5b are de jure standards largely used for military or noncommercial work. These include the message-based SAE Joint Architecture for Unmanned Systems (OpenJAUS) and NATO STANAG (Standardization Agreement) standards for unmanned aerial vehicles (UAVs) and unmanned ground vehicles (UGVs), respectively, along with the Autonomy Levels for Unmanned Systems (ALFUS)—a standard that describes autonomy levels for all classes of unmanned systems.

All the de jure standards, which were largely military standards, received a middling rating (Fig. 5a). However, as seen in Figure 5b, respondents deemed them more “Critical” to their work compared with:

Formal standards have the advantage of being able to rely on governing bodies to collectively work to modify the standard, or even combine standards, in order to improve efficacy and applicability. For example, there are discussions under way regarding OpenJAUS, which supports the command and control of unmanned systems, and whether it can be combined with STANAG 4586, which is focused on data from payloads on board UAVs, in order to create a single standard for unmanned systems. While a spirit of “co-opetition” is usually prevalent among providers of COTS and de facto standard technologies, and while technology suppliers must heed the will of the market, it is ultimately individual vendors that determine the fate of their respective de facto standard technologies.

For the most part, de jure standards are nonproprietary. De facto standards, on the other hand, are based on proprietary technology and could, therefore, result in vendor lock-in. However, as Figures 5a and 5b show, developers of robotics products believe the advantages of COTS and PC standard technologies outweigh concerns regarding proprietary technology. These advantages include:

Many robotics technologies available today are based on an open source software model. Open source is a software development and distribution model whereby the source code is freely available, subject to the terms of a licensing agreement. The source code may be modified and redistributed, again according to a licensing agreement.

Strictly speaking, “open source” does not equate to “standard.” However, it is closer to being a de jure standard than a de facto standard by virtue of the fact that open source software is not specific to a given product or company.

Open source software that is not based on open standards (de jure standards) is not “open” in the strict sense; you only have the ability to view and modify the code. Happily, most open source software does make use of open standards.

Regardless of standards support, the open source approach has many merits, particularly for robotics development, the least of which is the number of tools, libraries, frameworks, and system software currently available based on open source software. The Eclipse development environment, the Open Computer Vision Library, the Orca open source middleware, and the Carnegie Mellon Robot Navigation Toolkit (Carmen) provide just a few examples.

For all of their advantages, open source solutions often suffer from a lack of professional development and support, a particular concern when developing commercial robotics systems. However, while the source code is free, companies—as opposed to individuals—often lead the development of open source software using robust, commercial-class development methodologies. In the robotics space, one example is Willow Garage, a developer of open source solutions for personal robots that is supporting the development of ROS, a robot operating system first developed at Stanford University’s Artificial Intelligence Laboratory. Some companies also sell a distribution version of open source software, combining the free source code with proprietary utilities and a technical support package.

ROBOTICS DEVELOPMENT ENVIRONMENT FEATURES
All features of robotics development environments, with the exception of “Integrated Service Execution Architectures,” received a ranking from survey respondents of approximately 4.0 on a scale of 5, where 1 represented a feature that is not important and 5 represented a feature that is critical (Fig. 6a). The relatively high ranking by and unanimity of survey respondents demonstrates the importance of including “Hardware Drivers,” “Reusable Functional Components,” and “Integrated Simulation Environments” within an integrated development environment.

When the percentage of respondents selecting “Critical” for a given development environment feature was calculated (Fig. 6b), all features—with the exception of “Integrated Service Execution Architecture”—were approximately the same. As Figures 6a and 6b show, no feature dominated the others, although 30% or more of the respondents cited “Hardware Drivers,” “Reusable Functional Components,” “Integrated Simulation Environments,” and “Integrated Development Environment” as critical.

The embedded systems and information technology (IT) markets can boast of numerous mature, integrated development environments. For application development, toolsets in the IT space, database access, interapplication communications, graphical interfaces, hardware drivers, and other functions are provided through de facto standardized, reusable software objects, frameworks, and APIs that are included in and accessed through integrated development environments. In the embedded arena, similar—though functionally different—IDEs for software development also exist.

The development of robotics technology differs from both IT and embedded systems development efforts, but it does share the same requirements for mature, robust integrated development environments. It is through such tools that custom development and integration, which is slow, costly, and error prone, can be replaced by a more rigorous, productive, abstracted approach.

A number of comprehensive robotics development platforms, such as Microsoft’s Robotics Developer Studio and National Instruments’ LabVIEW, are available to designers. While both Microsoft and National Instruments are well respected by the development community and produce excellent engineering toolsets, these companies, like the producers of embedded systems development toolsets, are relatively new to the robotics market. Development tools for robotics platforms are maturing, but overall they are years behind the state of the art for traditional embedded software and IT development tools.

FUNCTIONAL SUPPORT IN ROBOTICS IDEs
When survey respondents were asked to rank functional support embedded in robotics development environments, it first appears that no single selection criterion dominated over any other (see Fig. 7a). Closer examination, however, reveals that functionality related to human-machine communication, such as “Speech Generation” and “Speech Recognition,” was deemed less critical than other capabilities. Functionality related to cognition and computation—the “think” in the classic Sense-Think-Act definition of robots—such as “Rule Interpreters,” “Machine Learning,” and “Neural Networks” also received a low ranking. The percentage of survey respondents who ranked these classes of functionality as “Critical” was relatively small (Fig. 7b).

Survey respondents indicated “Wireless Communication,” “Vision Processing,” and “Navigation” as the three types of functionality that they would most like to have embedded in robotics development environments (Fig. 7a). The case for wireless communication being the critical functional support incorporated in robotics integrated development environments (IDEs) is evidenced by the percentage of respondents selecting “Critical” for a given selection criterion as a percentage of the total respondent population (Fig. 7b). Vision processing and navigation also score well—higher, in fact, than they do in any other similarly framed question in the survey.

We are not at the stage of robotics development where multitasking, fully autonomous robotic systems are employed. Indeed, most products—whether they serve the military, civil, commercial, or consumer markets—are devoted to a single task or, at the very most, serve a limited purpose. Most are tethered in some manner and teleoperated (hence, the strong showing in the survey for teleoperation/remote control support—Fig. 7b). The next step in the evolution of these systems is to have them untethered, but still teleoperated. Moreover, simple robots will be given the ability to interoperate and cooperate with other simple robots in networked teams (or swarms) in order to perform more complex tasks, such as serving as mobile sensor networks.

Although the appearance and capabilities of robots can vary greatly, by definition all robots can sense their environment, move within that environment, and manipulate with objects within it. What differentiates the various types of robots and robotics technologies is the degree of autonomy they exhibit while sensing, moving, and interacting. “Increasing Autonomy” is an overarching theme for both individual and swarm bots, as well as across all robotics industry sectors, including such divergent markets as military robotics, healthcare robotics, industrial robotics, and even consumer robotics. The reason is clear—increasing autonomy acts to:

Wireless communication and vision processing is a requirement of both teleoperated and autonomous robots, particularly if those systems are to communicate with humans, sensors, and other robots or provide visual feedback to operators. Navigation, localization, and route planning/scheduling, along with wireless communication and vision processing are all functionality required for autonomous robots.

Producers of robotics development tools (or toolsets included with robots and robot platforms) should focus resources to add functionality that eases the development of teleoperated systems; networked, cooperative robotic systems; and autonomous systems—even if it comes at the expense of supporting advanced human-machine interaction. All three system types demand robust wireless communication, vision processing, and navigation support.

LANGUAGES
As Figure 8a shows, survey respondents deemed C and C++ as being the most critical languages for robotics development. The more esoteric 4GLs and specialized languages were considered less critical. When the percentage of respondents selecting “Critical” for languages for robotics development is graphed, it shows that C++ was far and away the leader (Fig. 8b). It should be noted that a number of languages—including PARSL, RoboML, XRCL , TcL, Perl, Ruby, and Scheme, as well as SmallTalk and SmallTalk variants, such as Squeak, and older languages, such as Forth and Ada—were not cited in the study, but it is doubtful that they would have scored any higher than those listed in Figures 8a and 8b.

C++ and, to a lesser extent, C are the de facto standard development languages for everything but Web development and certain classes of database-intensive, corporate application development, such as banking systems—here, “software development” is differentiated from “application development,” where the primary languages used included 4GLs, SQL, and even Cobol. C is the closest to a standard language for microcontrollers as well as vision processing (because it is fast). It is for this reason that “strong skills in C or C++” is a common skill requirement in robotics engineering job postings.

High Performance and Openness
Choice of software development languages typically involves many individual, weighed choices and trade-offs including:

C and C++ deliver high performance and the sense of security that an open standard provides. Depending on how the software was written, programs developed in C and C++ can be made very efficient. More important, C and C++ imply no technical limits. 3GLs, like C and C++, are the highest level of abstraction capable of building complete systems, offering all levels of functionality across all platform types. While C# probably is not too much slower than C/C++, it is somewhat proprietary.

Java, XML, and Python received middling ratings from survey respondents in terms of being “Important” and/or “Critical.” XML (Extensible Markup Language) is a simple description language that excels at storing data with a structure that uses tags. It is used widely on the Web, for which it was designed, and is well known to programmers. It is used as the basis for many robotics-specific languages, including PARSL, RoboML, and XRCL.

Java, an object-oriented language that is syntactically similar to C++, eliminates some of the more problematical features of C++ including gotos, operator overloading, and pointers, while adding support for automatic memory management and dynamic binding. Figure 8b shows that Java ranks third among respondents’ preferred languages, but trails C and C++ by a great deal.

A number of robotics developers speak well of Python as a language for robotics development. Like Java, this scripted, interpreted, object-oriented programming language comes with extensive standard libraries. The main advantages of Python for robotics development is that it easy to learn, increases developer productivity, and can be modified during runtime (it is interpreted; that is, with no compile step). The result is clear, maintainable code that can be produced and tested quickly.

While Java and Python have many advantages, they fall short of C and C++ technically for the advanced systems programming required for robotics development. Interpreted Java and Python cannot compete with C and C++ in terms of execution speed (neither can compiled Java). In addition, most of the robotics development frameworks and libraries—such as the popular Open Computer Vision Library and the Carmen robot navigation toolkit (see the Development Frameworks and Libraries section below)—are implemented in C and to a lesser extent C++. Other forms of software used for robotics development are also C/C++-based, including the Player/Stage middleware. Hardware interfaces, too, are typically accessed using C/C++. While Python, Java, and other languages do provide a mechanism for interfacing with C/C++ modules for speed and non-native functions, this adds another layer of complexity as well as the need to support multiple languages.

REAL-TIME OPERATING SYSTEMS
Real-time operating systems (RTOSs) are operating systems designed for use in real-time computer systems (such as robots)—that is, systems that guarantee specific functional actions (such as reacting to input) within a specific time period (deterministic timing behavior). RTOSs are typically multitasking, controlling a number of subtasks and supporting multiple execution threads and preemption at the kernel level. RTOSs are also defined by their small footprint, short latencies, and very fast response time compared with general operating systems such as Microsoft Windows or UNIX.

As described in Figure 9, developers indicated that they will be increasing their use of RTOSs for their robotics development efforts over the next two years. Presumably, this will come at the expense of general-purpose operating systems such as Windows, or any operating system at all. The percentage of developers who indicated that they will not be using RTOSs for development/deployment is expected to be halved over the next two years from approximately 28% to 14%.

From the survey, it appears that embedded Linux RTOSs are the future for much robotics development. More than 45% of the survey respondents indicated that they are currently using embedded Linux RTOSs, and this figure is expected to increase to over 50% in two years. Semiconductor RTOS distributions (internal RTOS), many of which are Linux-based, as well as independent commercial versions of Linux-based RTOSs from the likes of MontaVista and Wind River, are all expected to show increased use.

IDEs, TOOLKITS, AND SIMULATION TOOLS
When survey respondents were queried as to the types of IDEs, toolkits, and simulation tools that they are using and plan to use, four choices dominated (Fig. 10). These are:

It is important to note that each of the leading selections comes from well-established providers of development tools (The MathWorks, National Instruments, and Microsoft) or is supported by a large and enthusiastic open source community (Eclipse).

With the exception of the Eclipse IDE, the use of which is projected to increase, these leading choices are expected to maintain their respective levels of use over the next two years or decline slightly. This is somewhat perplexing as these products are sure to increase in functionality, robustness, and support for robotics development while, at the same time, commercial robotics development is certain to swell. The result becomes even more confusing when one considers the number of partnerships, levels of support, and growing interoperability these environments have with each other, various robot manufacturers, hardware vendors, and others that make up the robotics value chain. Robotics Business Review believes that the decline in Figure 10 is so small that it is likely due to statistical drift or a sampling error.

In contrast to the four leading selections, the remaining IDEs, toolkits, and simulation products are currently used by fewer survey respondents, but their use is expected to increase considerably in the next two years.

Approximately 75% of the survey respondents use at least one of the choices offered in the survey for robotics development, with this figure increasing to approximately 85% two years out. Respondents are currently using an average of 2.4 robotics development tools, and this number is expected to increase to slightly more than four products in two years. Robotics Business Review believes that developers are using market-leading, comprehensive IDEs in combination with niche toolkits for robotics development. As such, the number of niche products used in this manner is also expected to increase.

DEVELOPMENT FRAMEWORKS AND LIBRARIES
Many types of open source and proprietary robotics development frameworks and libraries are available for robotics development. Approximately 50% of survey respondents currently employ one of the development framework or libraries listed in the survey instrument for their robotics development efforts (Fig. 11). This figure is projected to increase to 56% in two years.

The framework/library most commonly used by survey respondents at this time is the Open Computer Vision Library (OpenCV), a cross-platform, open source computer vision library free for commercial and research use under a BSD license (23%, see Fig. 11). OpenCV consists of more than 500 algorithms and sample code for real-time computer vision. The library, first developed by Intel, includes the optimized Intel Integrated Performance Primitives for better performance. OpenCV comes with the content packages for ROS, an operating system for mobile robots that was originally developed in the Stanford Artificial Intelligence Laboratory, but is now being developed by Willow Garage, a robotics research incubator developing open source software and hardware for personal robots.

Eclipse is another notable platform. The popular open development platform consists of extensible frameworks, tools, and runtimes for building, deploying, and managing software (all available royalty-free via the Eclipse Public License). Surveyed developers indicated that they expect to increase their use of Eclipse as a development environment (Fig. 10).

Another open framework scoring well in the survey was Carmen, an open source collection of navigation software implemented in C. The OpenSLAM libraries from OpenSLAM.org, which solve the simultaneous localization and mapping problem (SLAM), along with OpenJAUS, an open source implementation of the JAUS standard for messaging between and within unmanned systems, are also well represented in the survey. They, too, are expected to find increased over the next two years.

Overall, proprietary frameworks and libraries are being used as much as their “open” counterparts, and their use is expected to increase over the next two years. Aware (iRobot), ERSP (Evolution Robotics), Karto (Stanford Research International), eVision (Braintech), Selectin (Energid), URBI (Gostai), and Skilligent (Skilligent) are representative products.

ROBOTICS DEVELOPMENT HARDWARE PLATFORMS
Most commercial service robots are little more than intelligent, mobile platforms dragging around some type of payload, such as a sweeper (iRobot’s Roomba), a machine gun (Foster-Miller’s MAARS Robot), medical specimens, tissue samples (CCS Robotics), and so on. The value-add that these vendors provide is not in the mobile platform per se, but the specific payload and vertical market expertise.

While some robotics companies have the financial and technical wherewithal to produce their own mobile platforms, many solution providers prefer to purchase existing platforms and modify them to suit their target market. This need has led to the development of a market for fully assembled mobile robotics platforms that can be easily modified for use in a wide range of industrial, educational, and research applications. By using these platforms, companies can speed product development and cut overall system development costs while focusing on their core competencies.

To avoid small sample sizes and to focus on the most common classes of commercial and research robots—namely, ground-based systems—both maritime and aerial robotics hardware platforms were left off the survey. Approximately 31% of the survey respondents make use of one of the hardware platforms listed in the survey instrument. This figure is expected to rise to 40% within two years.

As can be seen in Figure 12, the most common robotics development platform used at this point is Lego NXT, followed by the MobileRobots platform family, which includes PatrolBot, PowerBot, Pioneer, and others. Survey respondents are expected to make greater use of robotics development hardware platforms (with the exception of the Lego NXT platform, which is suited for prototyping and research, but not as a basis for commercial class systems). Interestingly, use of iRobot’s Aware platform, another prototyping and research platform—not to be confused with iRobot’s more robust PackBot and Warrior platforms—is expected to find increased usage over time.

Additional commercial-class robotics platforms that target commercial and academic markets are currently under development. For example, Coroware has recently released a ruggedized version of its Corobot platform—Explorer—that is designed for work in outdoor environments. Willow Garage’s PR2 personal robotics development platform, which is being readied for use by researchers, has recently completed a second milestone by traversing the Willow Garage office for 26.2 miles (four days) and locating 10 electrical outlets and plugging itself into them to recharge its batteries.

ROBOTICS DEVELOPMENT MIDDLEWARE
Middleware has a long history in the IT space as software that provides abstracted translation, integration, interoperability, and brokering services among applications, operating systems, and database management systems in distributed computing environments. Robotics middleware goes a step further, adding support for hardware integration and control in addition to traditional middleware services for systems, applications, and networked communications. The primary function of robotics middleware is to free the developer from the requirement of low-level programming to integrate each software, hardware, and communications module that together make up a given robotic system.

The primary takeaway from Figure 13 is the small percentage of survey respondents who actually use any given type of middleware for the development/deployment of their robots and robotics technology. No single middleware type is used by more than approximately 12% of the survey respondents. In addition, only 24% of the respondents indicated they use any type of middleware at all. This figure is expected to rise to 32% in two years.

Survey respondents indicated that they expect to reduce their use of many types of middleware, a prediction at odds with every other type of technology in the survey. The four types of robotics middleware cited in the survey as most commonly used are expected to drop over the next two years (Fig. 13).

Player/Stage, a popular TCP/IP-based middleware for robot device control that offers drivers to many types of hardware, is currently the most widely used robotics development middleware among survey respondents. Player, along with WURDE (a simplified, modular middleware), and Orca (open source middleware designed to support component-based development), are expected to see their level of use drop over the next two years (Fig. 13). The use of UPnP Robot Middleware, which is based on the universal plug-and-play standard, is also expected to decline. It should be noted that when Player/Stage was described as a type of IDE or toolkit (which is also true of the product), survey respondents expected its use to increase over the next two years (Fig. 10).

Among others, the University of Tsukuba’s (Japan) Sensory Data Processing Middleware, MARIE middleware, which emphasizes component reuse, and the object-oriented middleware Miro are all expected to show a slight increase in use going forward. However, as seen in Figure 13, in two years no more than 10% of survey respondents expect to make use of any one type of robotics middleware in their systems development efforts. The survey also suggests that, for robotics development, no middleware product, standard, or framework dominates the others in its category.

The relatively limited use of robotics middleware—both now and in the near future—begs the question: “What’s the problem with robotics middleware?”

As noted earlier, middleware is widely employed in the IT space as a means of integrating disparate hardware, software, and communications technologies. Robotics generally requires more integration between more complex technologies than the typical IT system, and it always involves real-time interaction. 

Robotics Business Review believes that the pace of commercial robotics development has been slowed by a lack of robust middleware or a lack of employing existing middleware solutions. That is, both the technology and the developers themselves are to blame. There appears to be a disconnect between the requirements for robotics development, what current robotics middleware provides, and what developers will use. Middleware issues include:

Robotics Business Review believes that the complexity of robotics systems, combined with the large number of robotics application types, makes it impractical to develop middleware solutions that can be applied to all (or numerous) robotics application types. Nevertheless, middleware solutions have been proven to speed the development and improve the quality of robotics systems and should be applied whenever possible.

One approach to creating middleware would be to design robotics middleware for specific classes of robotics applications and optimize the solutions for those applications while utilizing common interface abstractions whenever possible. By narrowing the range of application types, it would be possible to provide high-level, abstracted interfaces that are simple to use and actually work. In some respects, narrowing the functional scope of the middleware defeats the goal of a single abstraction level for multiple application types. Compared with the untenable levels of middleware use today, however, it would have a distinct advantage.

Under the scenario described above, middleware suppliers would be responsible for clearly stating the range of robotics applications suitable for their offerings. For their part, development managers would be obliged to compel their teams to employ middleware whenever feasible. They would also pressure their suppliers—academic, commercial or otherwise—to provide the support necessary to make their middleware offerings robust and easy to use.