Survey of Robot Programming Languages
Total Page:16
File Type:pdf, Size:1020Kb
Survey of Robot Programming Languages Seminar Report Submitted in partial fulfilment of the requirements for the degree of Master of Technology by Anirban Basumallik Roll No : 09305008 under the guidance of Prof. Kavi Arya Department of Computer Science and Engineering Indian Institute of Technology, Bombay April 2010 Abstract At the present moment the field of Robotics is extremely varied. The nature of tasks that robots can perform are very distributed and hence controlling or programming different robots need different methods. Many vendors have tried to provide a common platform by abstracting out the differences. In this report we carry out a survey of the different Robot Programming Languages available in the market and assess their pros and cons. Finally, we come up with the needs of a desirable robotics platform that can ease the task of programmers in programming a class of robots more succinctly and effectively. 1 CONTENTS CONTENTS Contents 1 Introduction 3 1.1 Robot Programming Platform . 3 1.2 Need for a Platform . 3 2 Microsoft Robotics Developer Studio 3 2.1 DSS . 4 2.2 CCR . 5 2.3 VPL . 6 2.4 VSE . 7 2.5 Others . 8 2.6 Pros, Cons and buzz . 8 3 Player/Stage 9 3.1 Player Goals and Design . 9 3.2 Stage simulation environment . 10 3.3 Working . 11 3.4 Pros, Cons and buzz . 12 4 URBI 12 4.1 Design philosophy . 12 4.2 URBI Technology . 13 4.3 Pros, Cons and buzz . 14 5 OROCOS 15 5.1 Design philosophy . 15 5.2 Pros, Cons and buzz . 15 6 Comparative Study 16 7 General Requirements of a Platform 17 8 Conclusion 18 References 19 Appendices 20 A MSRDS Example 20 B Player/Stage Example 28 2 2 MICROSOFT ROBOTICS DEVELOPER STUDIO 1 Introduction This report primarily studies two major robot programming platforms. The first is Microsoft Robotics Developer Studio and the other one is the Player/Stage/Gazebo platform. Their general architecture, popularity in the industry, advantages and disadvantages have been closely studied. There is a brief report on two other platforms, namely, ORoCoS and URBI, which are promising and upcoming platforms. We then attempt to outline the qualities of a desirable robot programming language and suggest how we might go about building it. 1.1 Robot Programming Platform What we mean by a Robot Programming Platform is:- • Uniform programming syntax and commands • Large support for hardware • Abstraction from differences in hardware • Availability of libraries for basic and common robotic tasks like joint control, image pro- cessing, and navigation. Apart from these, the facilities for debugging through simulation and re-usability of compo- nents should be also available. 1.2 Need for a Platform The need for a Robot Programming Platform arises from the fact that a lot of money needs to be invested in the software part of a Robotics project. Statistically [10], 80% of a project cost goes into software development. The main aim of a Robot Programming Platform is to reduce the project cost by reducing the software development cost. Rather the cost can be redirected to software development in the domain of algorithms and Artificial Intelligence. Having understood the basic needs behind a robotic platform let us now move into studying our first case study, Microsoft Robotics Developer Studio. 2 Microsoft Robotics Developer Studio Microsoft launched their own Robotic programming platform, Microsoft Robotics Developer Studio (alias MSRDS) which can address a lot of the issues prevalent in the robotics industry. Powered by the strength of the C# programming language and the rich .NET framework, the MSRDS is a good platform for users. With a well laid out architecture, separate co-ordination library, and user-friendly GUI and simulation support, it makes this product quite a complete package on its own. MSRDS comprises of the following:- • DSS: Decentralised Software Services • CCR: Concurrency and Co-ordination Runtime • VPL: Visual Programming Language • VSE: Visual Simulation Environment 3 2.1 DSS 2 MICROSOFT ROBOTICS DEVELOPER STUDIO Figure 1: MSRDS in action of Appendix A It has also got other features which ensure security of data, generation of log messages and detailed research diagnostics. Let us have a look at them one by one. 2.1 DSS DSS [5] stands for Decentralised Software Services. It is a lightweight runtime environment that sits on top of the CCR. It is a state-oriented service model that helps in developing scalable and high performance applications by integrating features like, isolation of services, composition of services, event driven notifications, message passing, and structured state modifications. It combines the notion of REpresentational State Transfer (REST) and Decentralised Software Services Protocol (DSSP) alongwith HTTP as the basis of interaction amongst services. DSSP is a Simple Object Access Protocol (SOAP) based protocol which provides a clean state transfer model which can manipulate states and an event model driven by state changes. DSS [5] provides robustness by providing advanced error-handling features. Partial failures in sub-part of a system can lead to a complete halting of the whole system. Two types of isolation is needed for a robust system. Data needs to be isolated, as corrupted data can corrupt a service and execution isolation is needed, as one service depending on another service for execution may become unresponsive. A robust system always demands loosely coupled components. Such a system has additional demands of identifying, locating, synchronising, and composing them into one runnable unit. Unlike traditional systems which run as a single unit, DSS provides arrangements for creating, managing, and deploying loosely coupled systems. It has definitions of dependency of services which are verified at the initiation of the service. Having so many individual components running in parallel just adds to the problem of debugging. Locating the source of errors becomes a challenging task. Thus, the notion of observability has been integrated into the core of DSS by assigning a unique identifier for each service and observing the state changes that each service goes through as a part of its internal execution as well as external interaction. 4 2.2 CCR 2 MICROSOFT ROBOTICS DEVELOPER STUDIO Figure 2: A Service Module[5] Service A service [6] is the basic building block of DSS. A service is an abstraction over computation, it is a logical module. An entity or service has the following:- • Service Identifier: Unique identifiers for locating an instance of a service. They are just identifiers and does not convey information about context or nature. • Contract Identifier: These are condensed descriptions of implementations describing the behaviour. These are used to generate proxy dlls to which other services link against rather than directly linking to them. • State: The state represents the internal states/current status of the service. • Partners: The system maintains a list of partners who are dependent on the service or on whom the service depends for its proper functioning. • Handlers: They handle the subscriptions and takes actions on an event occurring. • Main Port: The main port is the central pipe of communication with all external entities. It is a CCR Port. Partnering of Services Services declare each other as partners to work together. Partnering terms also exists which define the extent to which one partner can interact with the other. The following operations are available to interact with one another:- • Create Services • Query Services • Manipulate services • Subscribe to services • Terminate Services 2.2 CCR CCR [4] stands for Concurrency and Coordination Runtime. It addresses the need to manage asynchronous operations, deal with concurrency, exploit parallelism and deal with partial failure. It encourages the design of loosely coupled components which can be developed independently and make minimal assumptions about other components in the runtime. This approach changes 5 2.3 VPL 2 MICROSOFT ROBOTICS DEVELOPER STUDIO how the user thinks of a program from the the designing process, dealing with concurrency, failure and isolation in a consistent way. Applications which use CCR needs to coordinate through messages, deal with complex failure scenarios, or in other words has to deal with asynchronous programming. This model is also very similar to how heterogeneous hardware and network is built. It is operative in a way such that the whole system is responsive, scalable and efficient in dealing with failure. Some of the major features to mention about it are:- • It is basically a dll, accessible from any language targeting the .NET Common Language Runtime (CLR). • It has a data dependent schedule. • It abstracts out the need to create threads or use semaphores. • It acts as the glue between the runtime and the services. • It takes care of load balancing, scheduling and coordinating. Communication All the services interact through protocols and by exchanging messages. Network protocols are centered around http at the application layer and tcp in the network layer. The network protocols are e-secure. The system is also capable of communicating with enterprise web service architectures. The communication port maintains two different queues. One is for the data and the other is for the list of recipients. High level structures like Arbiter makes complicated queue logic look very simple. Messages The messages exchanged are human readable, serialized into XML over the network. The content of the messages directly correspond to the impact of the message. They are of the following types: modification, query, get, drop. As a matter of statistics, which gives an idea about the efficiency of the system, on an Intel Dual Core, 3.0 GHz machine, 50,000 messages could be exchanged per second and about 3,000 messages per second could be exchanged over distant machines. 2.3 VPL VPL [8] stands for Visual Programming Language. As the name suggests, it is a GUI based programming logic system.