Chapter 2. Robot middleware

Table of Contents
2.1. Introduction
2.2. Requirements of the robot middleware
2.3. Existing robot middleware
2.4. Comparison of Robot middleware the point of view of developers
2.4.1. Creating a new project
2.4.2. Component development
2.5. Services for end-users
2.6. Summary for robot middleware
2.7. References for robot middleware

The primary goal of this chapter is to find a robot framework in this environment that is easy to use, reliable and also easy to extend. After the different robot middleware concepts are detailed the most popular ones will be compared.

2.1. Introduction

RT-middleware (Robot Technology Middleware) is a technology that implements several key concepts needed for the development of complex robot systems, even in geographically distributed environments. Through a useful API, reusable standardized components and communication channels, and some degree of automatization, RT-middleware helps the user to build easily reconfigurable systems. The behavior of the components and the manner of interaction among them are standardized by the Robot Technology Component (RTC) specification. Until now there have been two implementations of the specification. OpenRTM.NET is written in .NET, while the other implementation, called OpenRTM-aist.

Within the robotics area, the task of robot systems can change quickly. If the job and environmental circumstances change frequently, reusable and reconfigurable components are needed, in addition to a framework which can handle these changes. The effort needed to develop such components depends on the programing language, the development environment and other frameworks used. Many programming languages can be applied for this process, however developing a brand new framework is a difficult task. Applying an existing framework as a base system, such as the OpenRTM-aist in the case of this chapter, the associated development tasks can be dramatically simplified.

Frameworks and middleware are gaining popularity through their rich set of features which support the development of complex systems. Joining together any robot framework and robot drivers can form a complex and efficient system with relatively small effort. In many cases, the task of the system designer is reduced to the configuration of an already existing framework.

On the other hand, when an existing framework requires only a set of completely new features, it can simply be extended with them. Improving an existing framework is an easier job than developing a new one because the design and implementation of such a system requires specialized knowledge and skills (design and implementation patterns). In most cases, the missing functionalities can be simply embedded into the existing framework, nonetheless there are some cases when this is hard to achieve. An existing framework can be improved simply only in case it is well designed and implemented. In spite of this, building a brand new system from is a much longer process that requires much effort.

In the area of robotics, there are many robot parts that share similar features, so the concept of robot middleware as a common framework for complex robot systems is obvious. Probably there is no framework which can fulfill all of the above requirements entirely.

2.2. Requirements of the robot middleware

In this section, I explore the requirements of robot middleware technologies in general and examine some existing robot approaches such as YARP, OpenRDK, OpenRTM-aist and ROS.

Robot middleware is a software middleware that extends communication middleware such as CORBA or ICE. It provides tools, libraries, APIs and guidelines to support the creation and operation of both robot components and robot systems. Robot middleware also acts as a glue that establishes a connection among robot parts in transparent way.

First of all, we should define the requirements and the actors of robot middleware. Generally, two actors use such technology: end-users and developers. Every robot middleware has to provide tools and mechanisms to facilitate the work of these actors.

Main use cases of robot middleware
Figure 2.1.  Main use cases of robot middleware

The main use cases of robot middleware are shown in 21. ábra. After the analysis of these use case we can define some functional requirements. The component developers design and implement components. For this development procedure, many programming languages and operating systems should ideally be supported. Tools are needed for the generation of skeletons and semi-working components for quicker development. The main activity of the developer actor should be the generation of semi code, the filling out of business logic, the compilation of binary code and the execution of test cases. Developers also create robot parts as components using their knowledge about programming languages, robot middleware and the specification of the given robot system. Moreover, the person who develops the component has to validate it as an end-user. In summary, from the developer's point of view, the main requirements for robot middleware are as follows:

  1. Support for a variety of programming languages: in most cases the members of research and development teams who develop various robot parts will be familiar with different languages depending on the trend at any given time.

  2. Support for a variety of operating systems: nowadays Windows and Linux operating system support is mandatory, as heterogeneous systems may rely on other libraries as well that are specific to these systems.

  3. Skeleton generation and other tools for components: The framework should be able to generate skeleton code for component development in order to speed up the development process. For this reason, robot middleware technology should include templates and tools (preferably graphical tools) to aid component development. Although developers will have to learn how to use the tools to generate source code, this requires less effort than starting component development from the scratch.

As opposed to the developer actor, an end-user is someone who has no knowledge about programming languages, as is not interested in developing components. End-users simply want to use components for their own work. In their case only a minimum number of system parameters should be visible, which are sufficient for the creation and operation of the robot system. Nice graphical interfaces and visual aid features are useful to end-users in allowing for the straightforward operation of the robot system. End-users have two main tasks. First, they often create complex robot systems using existing robot parts, and second, they often want to run previously created robot systems. The creation of a robot system can include a search for available robot parts during which the user obtains information about the accessibility of available components. This accessibility information can depend on the specific robot middleware which is applied for the task, and may include IP numbers, or any internal identifiers or symbolic names. Unfortunately, most robot middleware systems only support online components. For this reason, robot parts have to be available during the robot system creation process, i.e. have to be already running and must be registered.

End-users want to register their components in order to share functionalities with other end-users. After registration, the component can be found by all other participants. Usually end-users create custom robot systems using available components, so the second task is to find out which of the components are running. Once the robot systems are running, users will want to control them, i.e. activate/deactivate any or all of the components, and run them with various different parameter sets.

In summary, from the end-user point of view, the main requirements for robot middleware are as follows:

  1. The overall change in the applications and general software components running on workstations in a research group should be minimal. In most cases the operation of any system that is relied on by end-users on a daily basis requires a special software environment. The installation of new software components may result in outage periods in terms of existing services.

  2. User-friendly graphical interface the graphical interface of robot middleware should be as user-friendly as possible.

  3. Like developers, end-users would like to use Windows or Linux systems, therefore Windows and Linux operating system support is a strong requirement. End-users will not replace their familiar workstation environment with a new one just to accommodate the requirements of a new robot middleware.

In summary, the key consideration for a robotics middleware system to be useful is that it should provide an efficient API and as much automatization as possible. Additionally, middleware systems also have to support as many operating systems and programing languages as possible. If a framework is applied for a specific task, some efforts will always be needed to understand the relevant concepts and application details.

2.3. Existing robot middleware

One distributed environment for robot cooperation is OpenRDK. The concept is detailed by Calisi in [1] . The user’s robot system can be developed using a set of Agents, through a simple process. A Module is a single thread inside an agent process. Every module has a repository in which a set of internal properties are published. Inter-agent (i.e., inter-process) communication is accomplished by two methods: through property sharing and message sending. RConsole is a graphical tool for remote inspection and management of modules. It can be used as both the main control interface of the robot and for debugging while developing software. It is just an agent that happens to have some module that displays a GUI. The framework can be downloaded from [2] .

Alternative important robot middleware platform is Yet Another Robot Platform (YARP). Communication in YARP generally follows the Observer design pattern (for more details see [3] ). Every YARP connection has a specific type of carrier associated with it (e.g., TCP, UDP, MCAST (multi-cast), shared memory, within-process). Ports can be protected by SHA256 based authentication. Each port is assigned a unique name and it is registered into a name server. The YARP name server, which is a special YARP port, maintains a set of records, the keys of which are text strings (the names of the ports). The remainder of each record contains whatever information is needed to make an initial connection to a given port.

The third important robot middleware technology is OpenRTM-aist (documentation about it can be found [4] ), which is a convenient modular system also built on the Common Object Request Broker Architecture (CORBA). This concept uses the distributed components approach, where the components have to be registered into central naming service. (The openRTM-aist uses the name server of CORBA system.). The whole concept is detailed by Ando et al in [5] , [6] and [7] . The components can contain modules what can be loaded any time. The framework is implemented using design patterns, robust software system, which provides huge feature set, more than previously mentioned ones. The components of robot system have same rights no central logic (except the naming service). Each RT-Component has an interface (a "port") for communication with other components. The RT system is constructed by connecting the ports of multiple components to each other in order to aggregate RT-Component functions. The advantage of OpenRTM-aist is that it provides a simple way to create and co-operate various robot parts. Two kinds of port can be used the service port and the data port. The data ports provide the asynchronous messages and the service port establishes the synchronous communication. The usage of service port is complicated because we have to know the CORBA technology that is an out of date system. The connection among components has to be established at runtime by the end-user using a graphical interface. A comfortable state machine concept is provided i.e. the developer has to override the appropriate methods only. More programing languages and mostly used operating systems are supported. This is the second popular robot framework in the world. (The most popular in Japan.)

The final investigated robot framework is the ROS (Robot Operating System), that seems a basic operating system, but it provides similar features as previously mentioned (available at [8] ). The concept is detailed by Quigley in [9] . The items of robot system have to be registered a central server as well, but this component is called ROS node in this case. This node is the basic structure that can not be divide more parts in official ROS, but a 3rd party component exists called nodelet which support run more algorithm in one process (node). A central process has to be run (one roscore file creating a ros master and rosout nodes) providing the central log opportunity and a distributed parameter set. The connections among node are established automatically, i.e. if a component is running that advertises the topic and the other which subscribe to the topic, then the two nodes store information about the other using the roscore API. The developers' work is assisted completely, but only few tools are available end-user. This is the most popular robot middleware all over the world.

In the case of all investigated robot framework a concept is handled as distributed entity that is an agent or a port or a component or a node. The YARP provides more communication possibility nevertheless it has poor set of tools. Unfortunately the development of YARP and OpenRDK is broken. Only two robot frameworks are used nowadays, the OpenRTM-aist and the ROS, which is in progress so in the later part these robot system will be compared and detailed.

2.4. Comparison of Robot middleware the point of view of developers

In this section the ROS and the OpenRTM-aist robot middleware are investigated in point of view of developer. The complexity of significant procedures are compared and additionally the helper tools.

2.4.1. Creating a new project

In the case of ROS the new package can be generated by a tool named catkin_create_package that creates a folder containing a CMakeList.txt and a package.xml. These files have to be modified if another package is needed or a new executable file is necessary. If a simple message sending or receiving is should be used then the official tutorial can be modified easily and the business logic can be placed into a single function. It doesn’t generate any file or class, but it is not necessary for usage of ROS. The structure of beginning project is very simple, understandable. The basic features of ROS can be accessed only via three classes and the implementation of business logic not requires serious knowledge of ROS system. C++ and Python programming languages are supported officially. A custom creation tool is presented called catkin_make that is an extension of the platform independent CMake build system. More Integrated Development Environment (IDE) can be used that are supported the CMake, because the CMake can export it (at the moment CodeBlocks, Eclipse, Xcode, KDevelop, and Visual Studio).

For project creation, the OpenRTM-aist middleware also contains a command line tool (rtc-template) and graphical editor, called RTC Builder (the graphical interface is shown in 22. ábra.

The graphical interface of RTC Builder
Figure 2.2.  The graphical interface of RTC Builder

The definition of each RTC component is stored in a programming language independent xml file, and the source codes are automatically generated by the robot middleware framework using this XML file. Four source code files are created. One header and one C++ file for class definition, one C++ source file containing the main function and a makefile for building process. The developer has only to fill out the body of each skeleton member function and to insert other external classes. After building our system using these generated source we get a minimal working system, but it is hard to understand and to modify because substantial knowledge is needed about OpenRTM-aist system and the RT-specification. In the generated files the class is a subclass containing overriding methods and codes of design patterns. The knowledge of 5-10 classes are necessary for beginners. The generation process of a beginner project requires a lot of parameters at least 10, but in a complicated case can be 20-30 parameters too. C++, Java, Python programming languages Eclipse and Visual Studio are supported.

2.4.2. Component development

More than 2000 3rd party components are available for ROS that can be used freely for own robot system. Using these components the development period of the new robot system can be quick and easy. If our system is well designed i.e. the workflow of the components and the interface among them are designed precisely then the development process can be done in parallel due to available ROS tools. A message to a topic can be sent an easy way by rostopic from command line or listening to arriving messages to a specified topic. The construction of the component is not block the development of another component. Sharing a new functionality needs only a new method and variable definition and a simple function call.

The architecture of RT component
Figure 2.3.  The architecture of RT component

In case of OpenRTM-aist approximately 1000 components are available. Some of them can be used in Windows operating system only and the others restrict us to Linux. Unfortunately the documentation of the most components written in japan only and we have to trust the result of any language translator. The Debug and test tools are missing that helps to developer, we have to implement dummy components for this reason. In most cases the correct usage of the system services requires deep knowledge about CORBA technology that increases the full time of development. If a behaviour of any component can be used remotely we have to do more steps in the provider and consumer side also. In this case the usage of CORBA can not be omitted. The developer has to create a class containing methods of state machine and the business logic. The architecture of the component is show in the 23. ábra.

2.5. Services for end-users

The OpenRTM-aist robot framework is responsible for more services for the end-user than other ones. It supports the substitution of component, robot system creation, change of parameters of the robot, and the control of the component. Some command line tools are presented in rtc_shell package which are Python scripts. In addition, a graphical system editor is shipped as Eclipse plugin. The size of this system editor (and the Eclipse itself) is too large and the graphical capabilities are limited, but it is an effective supervisory interface of the system (the graphical interface is shown in the 24. ábra.)

The graphical interface of the System Editor of the OpenRTM-aist
Figure 2.4.  The graphical interface of the System Editor of the OpenRTM-aist

In the left side of the window the end-user can browse the online components in the middle part the actual robot system is shown. In the right side the main parameters of the component are shown. The end-user can start or stop the robot system or any component of the system at any time. If this GUI is not sufficient, than a new tool should be created. Unfortunately, the detailed documentation of OpenRTM-aist system is missing so the source code investigation is needed.

Exiguous amount of tool exist in ROS aiding the end-user. Some graphical tools are implemented in qt helping to view the log messages and draw the structure of robot system. Moreover, we should mention a promising tool that runs in a browser called Robot Web Tool. This is a Java script collection communication to the Python server application (a bridge to ROS) but additional development is necessary.

2.6. Summary for robot middleware

The OpenRTM-aist contributes more features to end-users via graphical interface, but more knowledge is needed for developer. In the case when the researcher would like to try more solutions i.e. varying the component the OpenRTM-aist is better than ROS.

It supports more programming languages and operating systems also, so it is easy to integrate it into the existing topology and easy to develop the new system. Unfortunately, the documentation is poor and some of them are exist in japan only which is not popular except in Japan. The support of more operating systems is mentioned as advantage, but it is drawbacks also, because it can lead to complicate and heterogeneous robot topology. If our robot system requires components which are found, however that components can be run only different operating system, it requires additional PC-s. The OpenRTM-ais provides more tools and features to developers, but more knowledge and experience are needed, nevertheless the documentation of the system is poor. More useful code can be found in the sample projects complementing the missing documentation, however the developer has to search it and has to try it with different parameters. An active community of OpenRTM-asit exists in Japan, nevertheless the questions and the replies are presented in Japanese language only in most cases.

The ROS is suggested in the case of autonomous system when the connection of robot parts is mandatory. In this case the graphical editor is not necessary. Because of huge number of existing components, probably one or more component exists which fulfil our requirements which are small, so the understanding and the modification are an easy task. It is easy to create a new project from the scratch (easier than OpenRTM-aist) because the creation of classes is optional we have to use existing classes and methods only. The development of the ROS core is continuous by a community, the seventh version is in progress. There are a lot of information about it and a lot of questions and answers on the web page.

2.7. References for robot middleware


D. Calisi, A. Censi, L. Iocchi és D. Nardi, „OpenRDK: a modular framework for robotic software development,” in Intelligent Robots and Systems, 2008. IROS 2008. IEEE/RSJ International Conference on, 2008.




„OpenRTM-aist robot middleware official web page,” [Online].


N. Ando, S. Kurihara, G. Biggs, T. Sakamoto, H. Nakamoto és T. Kotoku, „Software deployment infrastructure for component based rt-systems,” Journal of Robotics and Mechatronics, %1. kötet23, %1. szám3, 2011.


N. Ando, T. Suehiro és T. Kotoku, „A software platform for component based rt-system development: Openrtm-aist,” in Simulation, Modeling, and Programming for Autonomous Robots, Springer, 2008.


N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku és W.-K. Yoon, „RT-middleware: distributed component middleware for RT (robot technology),” in Intelligent Robots and Systems, 2005.(IROS 2005). 2005 IEEE/RSJ International Conference on, 2005.



M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler és A. Y. Ng, „ROS: an open-source Robot Operating System,” in ICRA workshop on open source software, 2009.


K. Saito, K. Kamiyama, T. Ohmae and T. Matsuda, "A microprocessor-controlled speed regulator with instantaneous speed estimation for motor drives," IEEE Trans. Ind. Electron., vol. 35, no. 1, pp. 95-99, Feb. 1988.


A. G. Filippov, "Application of the theory of differential equations with discontinuous right-hand sides to non-linear problems in autimatic control," in 1st IFA congress, 1960, pp. 923-925.


A. G. Filippov, "Differential equations with discontinuous right-hand side," Ann. Math Soc. Transl., vol. 42, pp. 199-231, 1964.


Van, Doren and Vance J., "Loop Tuning Fundamentals," Control Engineering. Red Business Information, July 1, 2003.


C. Chan, S. Hua and Z. Hong-Yue, "Application of fully decoupled parity equation in fault detection and identification of dcmotors," IEEE Trans. Ind. Electron., vol. 53, no. 4, pp. 1277-1284, June 2006.


F. Betin, A. Sivert, A. Yazidi and G.-A. Capolino, "Determination of scaling factors for fuzzy logic control using the sliding-mode approach: Application to control of a dc machine drive," IEEE Trans. Ind. Electron., vol. 54, no. 1, pp. 296-309, Feb. 2007.


J. Moreno, M. Ortuzar and J. Dixon, "Energy-management system for a hybrid electric vehicle, using ultracapacitors and neural networks," IEEE Trans. Ind. Electron., vol. 53, no. 2, pp. 614-623, Apr. 2006.


R.-E. Precup, S. Preitl and P. Korondi, "Fuzzy controllers with maximum sensitivity for servosystems," IEEE Trans. Ind. Electron., vol. 54, no. 3, pp. 1298-1310, Apr. 2007.


V. Utkin and K. Young, "Methods for constructing discountnuous planes in multidimensional variable structure systems," Automat. Remote Control, vol. 31, no. 10, pp. 1466-1470, Oct. 1978.


K. Abidi and A. Sabanovic, "Sliding-mode control for high precision motion of a piezostage," IEEE Trans. Ind. Electron., vol. 54, no. 1, pp. 629-637, Feb. 2007.


F.-J. Lin and P.-H. Shen, "Robust fuzzy neural network slidingmode control for two-axis motion control system," IEEE Trans. Ind. Electron., vol. 53, no. 4, pp. 1209-1225, June 2006.


C.-L. Hwang, L.-J. Chang and Y.-S. Yu, "Network-based fuzzy decentralized sliding-mode control for cat-like mobile robots," IEEE Trans. Ind. Electron., vol. 54, no. 1, pp. 574-585, Feb. 2007.


M. Boussak and K. Jarray, "A high-performance sensorless indirect stator flux orientation control of industion motor drive," IEEE Trans. Ind. Electron., vol. 53, no. 1, pp. 614-623, Feb. 2006.


D. C. Biles And P. A. Binding, „On Carath_Eodory's Conditions For The Initial Value Problem,” Proceedings Of The American Mathematical Society, %1. kötet125, %1. szám5, pp. 1371{1376 S 0002-9939(97)03942-7 , 1997.


Filippov, A.G., „Application of the Theory of Differential Equations with Discontinuous Right-hand Sides to Non-linear Problems in Automatic Control,” in 1st IFAC Congr., pp. 923-925, Moscow, 1960.


Filippov, A.G., „Differential Equations with Discontinuous Right-hand Side,” Ann. Math Soc. Transl., %1. kötet42, pp. 199-231, 1964.


Harashima, F.; Ueshiba, T.; Hashimoto H., „Sliding Mode Control for Robotic Manipulators",” in 2nd Eur. Conf. On Power Electronics, Proc., pp 251-256, Grenoble, 1987.


P. Korondi, L. Nagy, G. Németh, „Control of a Three Phase UPS Inverter with Unballanced and Nonlinear Load,” in EPE'91 4th European Conference on PowerElectronics, Proceedings vol. 3. pp. 3-180-184, Firenze, 1991.


P. Korondi, H. Hashimoto, „Park Vector Based Sliding Mode Control K.D.Young, Ü. Özgüner (editors) Variable Structure System, Robust and Nonlinear Control.ISBN: 1-85233-197-6,” Springer-Verlag, %1. kötet197, %1. szám6, 1999.


P.Korondi, H.Hashimoto, „Sliding Mode Design for Motion Control,” in Studies in Applied Electromagnetics and Mechanics, ISBN 90 5199 487 7, IOS Press 2000.8, %1. kötet16, 2000.


Satoshi Suzuki, Yaodong Pan, Katsuhisa Furuta, and Shoshiro Hatakeyama, „Invariant Sliding Sector for Variable Structure Control,” Asian Journal of Control, %1. kötet7, %1. szám2, pp. 124-134, 2005.


P. Korondi, J-X. Xu, H. Hashimoto, „Sector Sliding Mode Controller for Motion Control,” in 8th Conference on Power Electronics and Motion Control Vol. 5, pp.5-254-5-259. , 1998.


Xu JX, Lee TH, Wang M, „Design of variable structure controllers with continuous switching control,” INTERNATIONAL JOURNAL OF CONTROL, %1. kötet65, %1. szám3, pp. 409-431, 1996.


Utkin, V. I., „Variable Structure Control Optimization,” Springer-Verlag, 1992.


Young, K. D.; Kokotovič, P. V.; Utkin, V. I., „A Singular Perturbation Analysis of High-Gain Feedback Systems,” IEEE Trans. on Automatic Control, %1. kötet, összesen: %2AC-22, %1. szám6, pp. 931-938, 1977.


Furuta, K., „Sliding Mode Control of a Discretee System,” System Control Letters, %1. kötet14, pp. 145-152, 1990.


Drakunov, S. V.; Utkin, V. I., „Sliding Mode in Dynamics Systems,” International Journal of Control, %1. kötet55, pp. 1029-1037, 1992.


Young, K. D., „Controller Design for Manipulator using Theory of Variable Structure Systems,” IEEE Trans. on System, Man, and Cybernetics, %1. kötet, összesen: %2Vol SMC-8, pp. 101-109, 1978.


Hashimoto H.; Maruyama, K.; Harashima, F.: ", „Microprocessor Based Robot Manipulator Control with Sliding Mode",” IEEE Trans. On Industrial Electronics, %1. kötet34, %1. szám1, pp. 11-18, 1987.


Sabanovics, A.; Izosimov, D. B., „Application of Sliding Modes to Induction Motor,” IEEE Trans. On Industrial Appl., %1. kötet17, %1. szám1, p. 4149, 1981.


Vittek, J., Dodds, S. J., „Forced Dynamics Control of Electric Drive,” EDIS – Publishing Centre of Zilina University, ISBN 80-8070-087-7, Zilina, 2003.


Utkin, V.I.; „Sabanovic, A., „Sliding modes applications in power electronics and motion control systems,” Proceedings of the IEEE International Symposium Industrial Electronics, %1. kötetVolume of tutorials, pp. TU22 - TU31, 1999.


Sabanovic, A, „Sliding modes in power electronics and motion control systems,” in The 29th Annual Conference of the IEEE Industrial Electronics Society, IECON '03, Vol. 1, Page(s):997 - 1002, 2003.


Siew-Chong Tan; Lai, Y.M.; Tse, C.K., „An Evaluation of the Practicality of Sliding Mode Controllers in DC-DC Converters and Their General Design Issues,” in 37th IEEE Power Electronics Specialists Conference, PESC '06. Page(s):1 - 7, 2006.


Slotine,J.J., „Sliding Controller Design for Non-Linear Systems,” Int. Journal of Control, %1. kötet40, %1. szám2, pp. 421-434, 1984.


Sabanovic A., N. Sabanovic. K. Jezernik, K. Wada, „Chattering Free Sliding Modes,” The Third Worksop on Variable Structure Systems and Lyaponov Design , Napoly, Italy, 1994.


Korondi, H.Hashimoto, V.Utkin , „Direct Torsion Control of Flexible Shaft based on an Observer Based Discrete-time Sliding Mode,” IEEE Trans. on Industrial Electronics, %1. szám2, pp. 291-296, 1998.


Boiko, I.; Fridman, „ L Frequency Domain Input–Output Analysis of Sliding-Mode Observers,” IEEE Transactions on Automatic Control, %1. kötet51, %1. szám11, pp. 1798-1803, 2006.


Comanescu, M.; Xu, L., „Sliding-mode MRAS speed estimators for sensorless vector control of induction Machine,” IEEE Transactions on Industrial Electronics, %1. kötet53, %1. szám1, p. 146 – 153 , 2005.


Furuta.K. , Y.Pan, „Variable structure control with sliding sector,” Automatica, %1. kötet36, pp. 211-228, 2000.


Suzuki S, Pan Y, Furuta K, „VS-control with time-varying sliding sector - Design and application to pendulum,” ASIAN JOURNAL OF CONTROL, %1. kötet6, %1. szám3, pp. 307-316, 2004.


Korondi Péter, „Tensor Product Model Transformation-based Sliding Surface Design,” Acta Polytechnica Hungarica, %1. kötet3, %1. szám4, pp. 23-36, 2006.


Vadim Utkin, Hoon Lee, „The Chattering Analysis,” EPE-PEMC Proceedings 36, 2006.


Koshkouei, A.J.; Zinober, A.S.I., „Robust frequency shaping sliding mode control” Control Theory and Applications,” IEE Proceedings, %1. kötet147, %1. szám3, p. 312 – 320, 2000.


HASHIMOTO, H., and KONNO, Y., „‘Sliding surface design in thefrequency domain’, in ‘Variable Structure and Lyapunov control’,ZINOBER, A.S.I. (Ed.) (),,” Springer-Verlag, Berlin, pp. 75-84, 1994.


Koshkouei, A.J.; Zinober, A.S.I., „Adaptive backstepping control of nonlinear systems with unmatched uncertainty,” in Proceedings of the 39th IEEE Conference on Decision and Control, pp. 4765 – 4770, 2000 .


Kaynak, O.; Erbatur, K.; Ertugnrl, M., „The fusion of computationally intelligent methodologies and sliding-mode control-A survey,” IEEE Transactions on Industrial Electronics, %1. kötet48, %1. szám1, p. 4 – 17, 2001.


Lin, F.-J.; Shen, P., „H Robust Fuzzy Neural Network Sliding-Mode Control for Two,” Axis Motion Control System IEEE Transactions on Industrial Electronics, %1. kötet53, %1. szám4, p. 1209 – 1225 , 2006.