About this Journal Submit a Manuscript Table of Contents
Advances in Mechanical Engineering
Volume 2013 (2013), Article ID 969304, 15 pages
http://dx.doi.org/10.1155/2013/969304
Research Article

A General Framework of Mechatronic Modular Architecture

School of Mechanical Engineering and Automation, Beihang University, Xueyuan Road No. 37, Haidian District, Beijing 100191, China

Received 10 April 2013; Accepted 22 May 2013

Academic Editor: Hongxing Wei

Copyright © 2013 Ying Zou et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

The independent designs guided by domain technologies of mechatronic system lead to the problem of hard compatibility and the difficulty to reuse resources between the systems. This paper presents an approach based on the reuse for modular mechatronic system, and a general framework for modular mechatronic system is designed. After the analysis of related characteristics of the mechatronic system, the modular principle of mechatronic system is proposed. Secondly, a general framework (F-Model) based on reusability of software and hardware in mechatronic system is developed. Following is to elaborate in details on the parts of software, hardware, and infrastructure of mechatronic system. Finally, 6-DOF industrial robot arm and medical accompany robot are taken as our experiment platform to design system based on F-Model. Results in practical application confirm the value of F-Model for reusing modules in designing mechatronic systems.

1. Introduction

Depending on the abundant application technology in mechatronic system (MS) developed over the past decades, such as motion control, path planning, position, trajectory tracing, visual processing, and trajectory interpolation, various kinds of mechatronic systems have been developed. Design approaches for MSs guided by the domain technologies above presented are independent and hard to be compatible mutually, so the problems faced by the people in the fields of study and development in the processing of designing MSs are that how to apply those technologies more easier, how to simplify design process, how to lower design difficulty, how to reduce repetitive work, and so forth. In order to have more time for researchers to study further more on the basis of previous work, it is very important to collect the valuable study achievements contributed by previous researchers for freeing them from repetitive work. The key problem in the MS design is to reuse software and hardware.

Monolithic programming is a common method adopted for software design in traditional MSs. The diversity of application domain of MSs would like to create very different architectures on software and hardware. So it is hardly realized not only to use general approach to design MSs and to reuse software and hardware but also to guarantee quality of MSs.

To solve these problems, researchers and institutes have started to research the reuse approaches of mechatronic system, which focus on some aspects as below.

Shield the differences from different hardware using universal network middleware, such as RT-Middleware [1, 2] and MIRO [3]. Due to the huge cost of the resource and the diversity of the hardware in MSs, it is difficult to transplant universal network middleware on the different platforms. Universal middleware taken up a large number of resources may have an effect on the implementation of RT-task in system with less resources and low processing speed.

Researchers and institutes have proposed some hierarchical architecture models of robot software system, such as K-Middleware [4] and ORiN [5], which are used to solve the heterogeneity between the modules building up MS. But these models are aimed to shield heterogeneity from hardware level, and the generalized reuse model is still not established now.

MS software architectures based on Component-Based Software Engineering (CBSE) are gradually accepted while some theories, such as OROCOS [6], RT-Middleware [7], MSRS [8], emphasize the reuse of partial software models, but the structural reuse method is not concerned when the hardware platforms have changed.

On the basis of the theory of software architecture and CBSE, Davide Brugali summarized the current study achievements and presented challenges faced by the design to robot software, called 4Cs [9, 10]: Computation, Configuration, Communication, and Coordination.

Additionally, some studies solved partial problems on compatibility while the software architectures based on component were not adopted and the reuse model of software and hardware in MS was not considered at all. These studies include Open-R [11], uPnP [12], ASEBA [13, 14], and CLAWER [15].

In fact to construct the hardware-independent software for MSs is really quite difficult. Though the researches above have considered the differences among different hardware levels, the differences are so great that the meaningful reuse of MS resources is not realized between the hardware. The MS controllers can be simple as MCU or be complex as industrial server, and thus their corresponding software system can hardly be the same. Designing the software taking MS features themselves into no account can cause that the reuse difficulties are concentrated to platform-independent software framework. This is not suitable for the MSs which usually have more changing hardware and less systematic resources.

Based on CBSE approach we have presented robot modular architecture based on functional component [16] and its software framework [17, 18]. In this paper, the general framework for modular MS is summarized based on software and hardware separation approaches and the MS model characteristics. The framework is expressed by the view of software and hardware reuse.

The principle is presented in this paper for MS modularity reuse and the general framework for MS is designed, and, based on the framework, two kinds of mechatronic instances are constructed. Firstly, the characteristics of mechatronics are analyzed and the modularity principles are presented. Secondly, a model and its framework are presented based on software and hardware reuse in mechatronics modular architecture. Thirdly, the software part, hardware part, and systematic infrastructure of the framework are discussed. Finally, based on the framework, two kinds of system instances, 6-DOF industrial robot and medical robot, are implemented.

2. Modularity Analysis of Mechatronic System

2.1. Modular MS Model Analysis

Traditional MS hardware module includes mechanical part and electronic part. The mechanical part decides the system physical motion, while the electronic part decides the information flow. The relationship of the two parts lies in the following: the motor transforms the information into the physical motion of the motor axis, which realizes the transformation from the information world to the physical world. The sensor transforms these quantities such as the sound, light, force, and heat in physical world into the information data, which realizes the backtracking from the physical world to the information world. The physical world is complicated and various, and the information representation can be unified by computer information processing. As a specification aiming to share and communicate information, the software and hardware reuse of MS is typical information subject of Domain-Specific Software Architecture (DSSA), and should be based on the connotation of information transfer and data flow.

Take MS computer control for instance, the core control part of MS mainly contains digital computer, signal amplifier, sampling holder, and so forth, and it mainly includes the digital information output to motor and sampling from the sensors; the controlled part mainly includes mechanical bodies, transmission devices, motors, and sensors, and through the information transforming, the controlled subsystem expresses the physical motions and state changes in overcoming the external force, self-gravity, kinematic pair damping, and so forth. Additionally, the generalized controlled object also includes the external environments where the MS is located. The environments are influenced by the controlled subsystem and re-act to it. There is a classical control loop between the control system and the controlled object (Figure 1).

969304.fig.001
Figure 1: Control model of MS.

For the computing capability is enhancing, traditional control system is gradually replaced by computer control system, and control functions are implemented by computer software procedures and run on the way of miniaturization, integration, and embedded application. The computer system has the standardized I/O feature, and thus the transfer function modules in traditional control model are packaged to these computer I/O modules, such as driver output module and the sampling holder module, while the control algorithms and other functional requirements are designed in computer software. Hence the modularity of MS control part is essentially the modularity of system software and electronic parts.

The research [19] shows that connecting the advantages of the top-to-bottom design approach based on the domain model and the component design approach is effective in DSSA design. The mechanical part and electronic part of MS reflect different views of domain (Figure 2) and have their respective modular model approach. Based on the function separation and the open system requirement MS software model should not couple the kinematics model and control model. For once some coupling produced, its design ideas would be backtracked to the traditional design road which is led by some domain professional technology, and thus the reuse capability and compatibility of the systematic resources would be decreased. In the other side, the MS software model limited by systematic resources cannot be the same with the universal computer software model but should be the simplification or new construction in some dimensions.

969304.fig.002
Figure 2: Different views of modular mechatronic control system.
2.2. MS Modular Software and Hardware Separation Principle

In the architecture based design the software usually follows the CBSE development specifications, encapsulates every reusable software module using component, and supplies standard mechanism for visiting and operating. However, for it is quite hard to be compatible with different MS hardware platforms, if the component based run-time framework is designed without considering the hardware level, the software scale will be very large, and the difficulties from software reuse will be concentrated to the framework and then it will be quite difficult to design a platform-independent run-time framework. Plenty of researches above have discussed this hardware and software compromise and concluded that there are difficulties in running the traditional software middleware in these MSs.

The origin problem in MS reuse is the various software and hardware, and hence the core point for modular reuse is decoupling the MS software and hardware. To encapsulate the domain feature module and to define the standard interfaces for the communicating, are the reuse conditions of MS modules.

Therefore, the MS software and hardware modularity should follow the basic principles as below.

(a) Structure Separation Principle (Software and Hardware Separation). Considering the MS design’s labor division and efficiency, the structure separation of hardware and software should be implemented. As the MS has strong specificity, the holistic design based on the domain technology is applied. Structure separation can concentrate the domain technologies and decrease the coupling degree between software and hardware, and then the displacement between different modules can be implemented.

(b) Function Separation Principle (General and Special Separation). Function separation refers to the separation of function connotation which the MS module represents. For the function is the external characteristic expressed repeatedly by module or unit, the function separation must be based on the determination and stability of module function characteristics.

In MS the function bound is usually determined. Therefore, these functions can be extracted and abstracted and furthermore the abstracted results can be classified into universal function and special function based on the domain characteristics. The function stability decides the stability of architecture style, thus it is suitable to apply clear architecture pattern in MS.

(c) Combination Principle (Classification). MS function has the features of combine and cluster; for example, some servo motors have the position detection function, and some manipulators can combine the perception sensor function. Therefore, function modules of modular MS should have the combined capability based on the granularity expansion. And the functional component modules should have the similar interfaces and install rules with the original single component.

(d) Open Principle (Extension). About the MS structure, in order to improve the reuse capability, source code opening, resources sharing, and the function resource extension support are critical. In fact, to open the system design is also are important method to improve the quality of software, and many researchers have already researched the connotation of openness.

The principles above settle the main points of this paper.

2.3. Granularity Choice

Granularity is the opposite conception of coupling degree, and it is a relative conception but not an absolute conception. Granularity is data unit refinement or comprehensive degree level. The higher it is refined, the smaller granularity is; inversely the lower it is refined, the larger granularity is. The data granularity is a design subject; and granularity choice in different level will influence the information interaction or combined efficiency between the data modules [20].

In the MS modular design it is suitable to choose the large granularity in order to make some flexibility for module design and interface install. In other words, as the software and hardware are various, it is not suitable to describe the MS by tiny granularity and large-scaled and detailed specifications. Additionally, if the tiny granularity is chosen for the new hardware device, the component combined form in the system design will be complex and special, and the designers will be trapped into massive detailed design constraints, which will greatly increase the design difficulties and workloads.

Take the modular separation of a mobile robot system, for example, (Figure 3), to depict the system by Sonar Sensor, and so forth, is small granularity design, while to depict the system by Sensor Group, and so forth, is large granularity design. It is seen that the large granularity approach simplifies the system design work and decreases the difficulties.

969304.fig.003
Figure 3: Modular separation instance of a mobile robot.
2.4. Network Structure of Modules

There are different comprehensions in academic researches between the modular MS conceptual models. The researches on module reuse problem mainly focus on the modular modeling of mechanical modules, modularity of software system, modularity of control system, and so forth. However, the modular modeling problem of swarm-based or cell-based robotics is not the decoupling and reusing problem of the module; thus this paper does not discuss this issue.

In domain engineering the modular modeling researches of mechanical part and control part have gotten some progression, for example, modelling of modular MS and building approach based on spinor [21, 22], modular reconstruction or reconfiguration of control system [23, 24], and so forth. These domain engineering researches solved the modularity problem within the domain, thus when considering the information dataflow and the module reuse problem in the design, these models can be encapsulated in modules and meanwhile fully play the domain role. For example, the mechanical module problem can be transformed into information problem as motor control module, motion control module, kinematics software module, and so forth, which can accommodate the modular model of mechanical motion.

From the view of information model, traditional control structure can be expressed as different groups formed by subdivision network node (Figure 4). The MS control structure has three types: centralized structure, distributed structure, and hybrid structure. As the physical structures are different, system software and hardware resources are distributed in the network.

fig4
Figure 4: Network structures of modules.

In Figure 4  Network Node expresses distributed application. In the computer control system, the essence of these three structures is the centralization and distribution of control application procedures, and thus the control function application is organized as an analysable network structure between the MS modules. In this way, the complex network connection model is expressed and the connection can be handled in the MS control.

The network node connections form the logical topology relationship. However, it is not the same as the topology from the physical connections. The implementation of data interaction between the modules has no relation with the topology itself, because the network communication protocols usually support multiple topologies. In MS the logical topology expresses the control structure, and in the software modules of control algorithms or simulation model, it is the important configurable information for system structure.

The topology independent characteristic of network protocol determines that wherever a device module in the network located, it can be visited from allopatry limitedly. In fact, the network topology formed by the network nodes is always limitedly “transparent” in front of the device modules, and hence the device module in the whole system should be managed in an unified way, in order to ensure that every application procedure can finally limitedly visit the device modules via the network.

2.5. Brief Summary

From the analysis above, a brief summary can be given for modular MS framework.(a)MS modular architecture model should not couple with modular kinematics model and modular control model and should independently design and encapsulate these domain functions as domain modules.(b)Although the decoupling of software and hardware adds system resource cost to a certain degree, it will improve the flexibility and maintenance of the system design. The adding resource cost cannot be too much, for the MS resource limit mentioned above. The decoupling is the necessary method to realize the module reuse and to choose the mature modules can greatly improve the quality of the design.(c)The large granularity is chosen for the scale of modules and the architecture framework should have loose connecting relationship and more compatibilities. The detailed processing should be settled into the modules, and the necessary communication channels should be reserved between the modules. (d)Considering characteristics and resources of the run-time platform, the traditional software architecture should be clipped, simplified, and modified necessarily. Within this process, it is important to specially consider the design of the MS concurrent, real-time, and priority capabilities and implement the corresponding structures and infrastructures.

3. General Framework

3.1. F-Model Conception

Based on the MS characteristics analyzed above, the modular architecture model, F-Model, is presented to construct kinds of MSs. Differing from other approaches to solve software reuse problem, F-Model is constructed in MS information model to reuse systematic resources with the approach of hardware and software separation and interface standardization. F-Model system mainly includes the software structures by CBSE theory, hardware structures based on functional classifications, and the systematic infrastructures to provide standard visiting interfaces. When designing system with reusable resources, software components and abstracted hardware modules can be invoked by application procedures in different robots.

F-Model can be expressed as hierarchy model with robot application layer, service layer, component layer, middleware layer, device driver layer, and hardware layer (Figure 5).(1)Application Layer realizes MSs’ control and basic interactive application by associating and organizing function components.(2)Service Layer is to provide some basic services for application, such as management service, error handling, and power management.(3)Component Layer includes basic components and programs that are necessary to modular MS, and they are materialized in the upper layer through the abstraction of special function.(4)Middleware Layer includes a middleware core that can continually monitor dynamical process of components, find the abstraction form up to down, and shield the difference in device layer. (5)Device Layer mainly provides hardware device driver program compatible with operating system (OS) and device protocol, and so forth.(6)Hardware Layer defines the correspondence for MS electrical modules and expresses the transformation from physical quantity to information data quantity in system.

969304.fig.005
Figure 5: Architecture and hierarchy model.
3.2. Componentization and Separation of Software and Hardware in F-Model

In the architecture defined by F-Model, the separation of software and hardware applies the abstraction for decoupling. Following the information path, the system hardware part is abstracted and classified by the module kinds, while the software is decoupled by resource functions and characteristics. The module interfaces are encapsulated. A unified infrastructure and framework are applied to load the modules and a manager module is constructed to manage the hardware and software modules.

That is, in F-Model, the reusable granules include architecture, applications, components, manage procedures, and hardware device modules, while the granules, such as universal data package, common protocol, and common objects, will be treated as basic system resources and will not be encapsulated specially in order to keep the flexible developing room. The design considering of F-Model is to reserve the MS core control model and then to separate the hardware and software; thus the problem is solved that the reuse difficulties are concentrated to software framework, which is caused by the hardware differences.

3.3. Modular MS Based on F-Model

The construction process of modular system is the process of module assembling. It is supported by a resource manager, software components, hardware abstract classes, the real-time services provided by the real-time system scheduling, and so forth, and finally a series of application is released, as shown in Figure 6.

969304.fig.006
Figure 6: Modular system by F-Model.

The control structure of modular MS is settled; that is, the core domain model is considered. Based on this, the MS is decomposed by the functions and the independent applications to be implemented are divided into domain application and universal applications. As the application is decoupled with the hardware, it is easy to know that these applications can be reused in different platforms.

Based on the system requirement the respective priorities are settled for application procedures and the real-time tasks and non-real-time tasks are chosen. Domain applications usually have high requirements of running priority and resources.

Design the application, respectively, and then, the design considering is how to choose the relative components and hardware classes and the interface timing and mode between them, and how to handle the data coordinating and sharing within the process.

Finally, the system is assembled in the component cabin based on the framework and the final system is released.

4. Software Modularity Structures

4.1. Software Module Conception

In CBSE system component provides settled services and follows the Producer-Consumer pattern, and the consumers need not concern the implementation details of the components. In MS, as the hardware modules in lower layer are usually domain-dependent, the component after separating will be domain-dependent, while the applications for users in upper layer are usually non-domain-dependent. Therefore we separate the applications and the resource components in F-Model, and set the decoupling in the component layer to domain and not domain. And then a holistic resource manager is designed to manage the components. When assembling the MS based on Figure 6, the different components can be chosen to implement the Model-Based-Design (MBD) domain applications and Component-Based-Design (CBD) non-domain applications (Figure 7 and the Control Domain frame expresses domain application). This design joins the advantages of MBD and CBD. Thus these components follow the advantages of CBSE design in reuse and decrease the difficulties of application design, and the quality can be guaranteed in the domain characteristics design.

969304.fig.007
Figure 7: Software modularity structure.

For example, the MS control algorithm is complex, and some algorithms are not the simple combination in time or space with software and hardware modules. Encapsulating the algorithm as a single domain module can be used without influencing other modules.

Therefore the systematic component resources include multiple types such as the classes, monolithic procedures, and library procedures; to use such settings it is more flexible and more effective than to encapsulate the software to classes. This is critical in the MS platforms which have limited resources. To be simple, in following sections we will not specially discuss the domain component.

4.2. Real-Time Support for Application Node

The separation of application nodes is good for real-time and non-real-time distributions, and the MS real-time application is definite domain designing which can be formally analyzed. Based on the definition of real-time capability and influenced factors, the real-time task is critical link for the real-time application requirement. Within the full data flow, as long as the real-time capability of every link is guaranteed, the real-time capability of the whole control logic chain is guaranteed. Typical data flow is as shown in Figure 8.

969304.fig.008
Figure 8: Dataflow instance of real-time node.

In Figure 8, the rectangles express the components, the ovals express the buffer data structures in the producer-consumer process, and there are no direct invocations between the producer and the consumer. The fillet rectangles express the relative hardware modules. The directed thick lines express the systematic real-time data path. The directed graph formed by the components and connectors is the typical Pipe-Filter pattern, and the sequential structure between components is formed. There are no loop locks in the graph; thus the real-time capability of flow executing results can be ensured by this structure.

By the model analysis above of MS information model, the transfer process from the Sampler via the Controller to the Driver is necessary in MS domain model, and then the real-time chains in the graph will be formed. Each link of the chains can be distributed in multiple real-time tasks, even though the real-time network is distributed in real-time tasks in different network platforms. The advantage which lies in this structure is platform-independent, even as the single loop chip such as MCUs, the efficient real-time application and distributed application can be constructed.

4.3. Distributed Structure of Application Node

F-Model provides the data chain structure of real-time guarantee and provides the real-time capability by the RTOS task scheduling. The multiple OSs supplying tasks in different levels can simultaneously run in the system.

Suppose there are the real-time application node A and the non-real-time application node B, and based on the running platform kinds and the network distribution situation, the node allocations of A and B have several kinds as follows: A and B run on one RTOS on one platform; A and B run on different OS and different platforms with network connection; A and B run on different OS of one multicore platform; A and B run on the hybrid structure of the above three.

(a) A and B Run on One RTOS. Node A and node B create the real-time tasks using the task creating method of RTOS (Controller B in Figure 9). It is known from the real-time research that the efficiency will be decreased when real-time task of B runs.

969304.fig.009
Figure 9: Distributed network and real-time capability.

(b) A and B Run on Different OSs of Network Platform. Node A and node B run on the different hardware platforms and via the real-time network connection (Controllers B and C in Figure 9). The several RTOS and non-GPOS, respectively, run on different platforms in network and nodes A and B are implemented by respective system tasks.

(c) A and B Run on Different OSs of the Same Platform. Many MSs usually have single computer or controller platform and the MS nodes need to run on the same platform. This means that GPOS and RTOS should simultaneously run on the platform. The common method is adding real-time modifications such as RTAI [25], to construct a new real-time core to meet the requirement.

We apply the hybrid OS framework RGMP [26] to provide the integrating real-time services on the multicore platform. The clients of nodes are ported to the real-time OS to provide the distributed real-time services.

RGMP is a software framework that can run in multiple OS and it is mainly for multicore processors. Different OSs run on the different cores of one multicore processor, and the real-time task and nonreal-time task are supplied by different cores using RGMP; the illustration is in Figure 9 Controller A.

(d) Hybrid Structure. In the hybrid structure (Figure 9 Controllers A, B, and C) the RGMP, RTOS, and GPOS can be used simultaneously for different controllers.

It is seen that by the RGMP and the F-Model real-time framework, the complex structure of lower layer is abstracted and standardized into an operation framework that can provide the real-time and non-real-time tasks. The corresponding parts coupled by the OS and task properties are separated and the platform-dependency is lowered.

5. Hardware Modularity Structures

5.1. Basic Principle

By the principle of F-Model, the abstraction and classification of hardware modules should be constructed in MS information model.

In Figure 10, the hardware device modules have multiple electrical interfaces, and the modules are loaded to operation system with corresponding device driver procedures; the unified device operation interfaces are allocated by the OS, the device open, read and write, configure, reset, and so forth, and these device operations are implemented. The resource manager reads the registry and configuration information from the devices, and then classifies them to corresponding hardware class.

969304.fig.0010
Figure 10: Hardware modularity structure.

The application in the upper layer can visit the resource manager to look up and enumerate the classes encapsulated by the hardware modules if necessary, and then the operating interfaces will be obtained. These classes can be reflected to the user state in the OS and show their feature interfaces by deriving. The application operates the hardware by the classes and after the system compiled, the high executing efficiency can be ensured. Encapsulating the hardware as class will lower the efficiency in a certain degree, however, the reusing and inserting of devices will be possible the device reuse is possible and it is easy for the inserting of the new devices.

The resource manager is an independent software module that can be transported between different OSs, and it is not coupled with device manager in OS; thus applications in different MS can visit the hardware module resources in the same classification.

5.2. Module Classification

Based on the MS information model the hardware modules are simply classified and these classifications are, respectively, encapsulated as the systematic universal components that are supplied to the real-time framework.

Driver Module (Information Output): Common MS driver module includes amplifiers, servos, and modular joints. The corresponding component is Driver Class.

Sensor Module (Information Input): Common MS sensor module includes sensors, resolvers, encoders, and various position switches. The corresponding component is Sampler Class.

Control Module (Information Input and Output): Includes various controllers, control boards, and cards. The corresponding component is Controller Class.

Another module includes external communicating module and HMI module. They also have their own corresponding components.

To be noticed, the module kind has totally different meaning from the electronic interface kind. The module output stands for the MS logical information output, and in output module can have electronic input data interface; for example, common amplifier has the bidirectional communication interfaces with the controller for configurations.

In Figure 11, we take Driver Class, for instance, and give its members and universal operating interfaces.

969304.fig.0011
Figure 11: Driver class.

The hardware classifications express the abstraction of hardware modules and meanwhile they constrain the usage and configuration of the hardware resources, in order to implement their decoupling and reuse. Information, such as hardware identifiers, manufactures, hardware types, and electrical interface kinds is managed in the resource manager. The applications visit the resource manager for the necessary hardware modules.

The hardware is abstracted and encapsulated to classes, and this is the decoupled process between the device data and the application nodes and is also the decoupled process between the data and the model. In the OS, the existing devices are classified into stream device, block device, and so forth. However, the devices operate the hardware data without marking the device kinds in model. Devices in one classification may have different interface types; for example, there are motors with analog interface and motors with field bus interface, and hence if the classification based on the MS model is designed, the hardware decoupling can be implemented.

Also take the Driver Class, for instance, (Figure 12), in the application design, the output from the application node to the driver module is the velocity value of wheel rotation. It is a modular data which is not concerning what kind and what interface of motor is used in lower layer, and what data format is applied. The hardware abstract class encapsulates the model specifications and uses standard device interfaces of system in its methods, after deriving Driver Class the corresponding driver data operations can be implemented. If the new driver module is necessary, the corresponding driver procedures of OS should be added and then the abstract class is derived to implement the new interface operations. There is no need to change the application procedures and the decoupling is implemented.

969304.fig.0012
Figure 12: Hardware abstract class instance.

To manage the hard modules the resource manager stores the property information and when a new module is inserted into the system, these information should be updated. The information format is as follows.

Identifier: 64 bits, includes 5 parts:Class: 8 bits, to mark the module classification.Function: 8 bits, to mark the module function.Subclass: 8 bits, to mark the module’s subclass.Protocol: 8 bits, to mark the module protocol for electrical interfaces.Des Code: 32 bits, is the manufacture information and defined by the manufactures.

5.3. Considerations for Hardware Module Compatibility

As the classes can be derived, the decoupled hardware modules can be in various changing, and then the devices can be inserted into system flexibly. The added device can be either local device or network device and the exact protocol should be included for compatibility.

As the MS controllers are various and their processing capabilities are different, essentially speaking, they are all computer units in different levels, and the network protocol levels to run on the controllers are also different. In the ample resource controller, such as industrial computers and industrial servers, the full IP protocol or TCP/IP protocol can run well, while in the resource limited controller such as MCUs and DSPs, though the IP protocol stack can not be loaded, the proxy method [27] can be used and then the controller can be connected to the network in larger range by the identifier specification.

6. Infrastructures

6.1. Light-Weight Middleware

To the middleware in the framework, the support for different MS platform kind should be considered and the simple structures and better capability and system transporting capability should also be held. Common middleware is not suitable for the MS applications, for they are based on the TCP/IP and the middleware package is great with low efficiency. Based on researches of Magnenat et al. [13], the system cost of TCP/IP is usually more than Mbytes. Therefore, the common middleware has great difficulties applying in memory or storage resources limited systems. The middleware for MS should have the basic structure to load MS modules and should also have conveniently porting, clipping, and extending capabilities.

Additionally, common middleware is from the universal network middleware and its support for network is simple, and the support for common buses used in MS is not good. And the smooth route between the networks of multiple buses is hard to handle.

It is mentioned above that to apply a settled software middleware platform in various MS hardware will meet the problems of porting and supporting. And the MS middleware is suitable to apply the easily flexible and compatible structures and apply the simple interface in the modules’ interactions. In this paper we use the identifier based interaction mechanism and standard client/server socket method based on IP protocol and then construct the communication between the modules.

6.2. Resource Manager

Resource manager is the important manage unit for modular MS, and it includes the resource manager and configuration function of software and hardware modules. For the visit rules is settled for the system modules each other, the resource manager can be considered as a simplified middleware module.

Resource manager includes the parts of resource manage core, component library, module address decoder, and parameter and configuration manager. It maintains the identifier of components and nodes and then the resources manage is implemented. Each identifier has a corresponding software component or hardware class in the component resource library. The user can visit these resources by the identifier without considering whether the component or node is local; in other words, resource manager redirects the visit operations to the real locations of the resources which are masked to applications.

New module needs to be registered to resource manager and then added to F-Model. Meanwhile the unique module identifier name will be confirmed and stored. Then all the application can search and visit the module by the identifier. After the application design is completed, the resource configuration of the current design can be saved to files by the resource manager.

6.3. Interaccession Mechanism between Modules Based on Identifier

Firstly, the component or node registers to the resource manager and asserts its identifier. Then the registered identifier is the unique identifier of components or nodes, and its identity can be identified by all components or nodes in the whole system. Identifier follows the subscribe-publish pattern; that is, one node gets another node’s communication interfaces and parameters by subscribing the identifier and furthermore communicates with it using the provided service interface by settled protocol (Figure 13).

969304.fig.0013
Figure 13: Communication approach between modules.

When the communication is established, the node can supply the settled services and standard socket for communications. The modules are decoupled and the simplified middleware mechanism by resource manager can meet the MS application’s network requirements.

7. Implementations

7.1. Industrial Application—Welding Robot Arm

(a) Introduction of Welding Robot Arm. Modular Welding Robot (MWR) is standard 6-DOF joint robot (Figure 14). It can do settled operating task by human teaching and its end can track the lines, arcs, and free curves trajectories. With the welding machine and tools the MWR can repeat the welding workpiece task.

969304.fig.0014
Figure 14: Modular Welding Robot (MWR).

Applied hardware modules in MWR are the following: Modular Robot Controller Module, Modular Robot Joint Module, Sensor Modules, I/O Device Module, and so forth.

Applied software modules are the following: Robot Solution Module, Robot Type Configuration Module, Decoding Module, Rough Interpolation Module, Fine Interpolation Module, Axis Control Module, Debug and Error Handling Module, Human-Machine-Interaction Module, Logical Control Module, and so forth (Figure 15).

969304.fig.0015
Figure 15: System structure of MWR.

Other distributed modules: Teaching Module, Simulation Module, Remote Monitoring Module, and so forth.

The system resources are the following: Processor: Marwell PXA270A 520 MHzMemory: 128 MBStorage: 128 MB FlashOperating System: uCOS II.

(b) Structure of MWR. As common industrial 6-DOF joint robot system is not open, considering the structure characteristics of 6-DOF joint robot, the general method is to bind the 6-DOF joint robot body as a single part. Its servo drivers and motors are packaged and locked within the entity and they are hard to separate since the control and solution of robot are coupling. The reuse cannot be implemented until the package is broken.

The robot joints are separated from the robot structure logically, that is, setting the isolated information to every joint. Then by reading the bus servo driver module, the single joint information is asserted.

The robot configuration formed by the joint connection can be expressed as D-H parameters matrix. Since the robot solution of 6-DOF joint robot is only influenced by D-H parameters, the D-H parameters are picked up as configuration file to support the configuration component.

(c) Implementation of MWR System. 6-DOF joint robot is a common industrial robot, and the overall system design has been more mature. However, its hardware and software do not use a unified system, and thus the compatibility with each other is quite bad. Current 6-DOF joint robot is generally designed and developed separately from scratch. The 6-DOF joint robots are composed of various of system structures, such as PC controller + motion control card, and an embedded controller + DSP, but for the open reusable software considering, the 6-DOF joint robot system structure should be single controller with pure software.

The single controller with pure software means that with the enough CPU capability, a single controller can process motion control, kinematics solver, and path interpolation functions entirely by software, and real-time OS running on the CPU will guarantee the real-time control of the underlying system. With this structure, system software and hardware can be reused in the best way; therefore here we design 6-DOF joint robot in this pure software structure.

The modular WMR system in this paper mainly includes 6 joint bodies, controller, joint drivers, decentralized control card, and system source and appendix. To be decoupled, the controller outputs the real-time motor control messages such as position and velocity, and so forth; then the messages are sent to the joints via the decentralized control card, and motion control card such as P-MAC is not needed additionally.

In software the design requirement of 6-DOF joint robot in this paper is to track the robot end’s trajectory. The system applies the real-time OS, which can ensure the hard real-time capability of the task operations, and the non-real-time modules, such as teaching, computing, and simulating, are distributed in network. As Figure 16, the user inputs the working task to the MWR system and interacts with the Teaching Module and Simulation Module, and then the working procedure is settled. The code handle node loads the decoding component, interpolation component, logical control component, data process component, and so forth. The logical task node executes the logical task, and meanwhile the axis control node executes the task of robot end’s trajectory. To be clearly expressed, some data structures are simplified in the figure.

969304.fig.0016
Figure 16: Dataflow chart of MWR.

The thick lines with arrows express the hard real-time dataflow. With the scheduling of real-time system, the servo cycle time of axis position is settled 4 ms, and this can meet the requirement of automation workshop. In the design of this paper, Teaching Module, Simulation Module of MWR have been decoupled by network and the code handle node, logical task node, and axis control node are decoupled in software. The MWR hardware modules are reusable; in this design the axis can be replaced by different manufacture.

7.2. Service Application—Medical Accompany Robot

(a)  Introduction of Medical Accompany Robot. Medical Accompany Robot (MAR) is a differential wheeled service robot (Figure 17), and it is used for patients medical accompany, medical information interaction, and so forth.

969304.fig.0017
Figure 17: MAR system.

MAR’s hardware modules include Camera Module, Medical Sensor Module, Laser Senor Module, Infrared Sensor Module, Sonar Sensor Module, Robot Controller Module, Motor Driver Module, Monitor Module, and Operating Module.

Applied software modules include Video Processing Module, Control Algorithm Module, Position Perception Module, Human-Machine-Interaction Module, and Motor Control Module.

Applied system resource situations are the following: Processor: Intel Atom Processor Z510 1.6 GHzMemory: DDR2 1.0 GBData Storage: 8 GB CF CardOperating System: Hybrid system RobOS [28] with RGMP

(b) Modular System Implementation of MAR. In F-Model framework, the MAR system is designed. Firstly MAR system is decoupled into hardware and software modules described in Section (a) and then register the Camera Module, Medical Sensor Module, Laser Sensor Module, Infrared Sensor Module, Sonar Sensor Module as Sensor Class, register the Motor Driver Module as Driver Class, register the Robot Controller Module as Controller Class, and register the Monitor Module and Operating Module as Other Class. The layer of hardware is simple, and the centralized structure is applied; that is, all sensor modules and motor driver modules are directly connected to the controller module, and all the medical accompany functions are implemented by software procedures running in controller module.

The sensor data process, Main Control, and Motor Control are settled as real-time nodes, while the Video Process and HMI are settled as non-real-time nodes. They run in the different areas of RobOS (Figure 18): the Motor Control Node and the Position Percept Node control the real-time device motor and sensors and run in the real-time OS area, while the Video Process Node and the HMI Node, respectively, connect to the Camera Module and Monitor Module and run in Linux area. The parts illustrated by thick lines form the real-time control chains of F-Model. To be clearly expressed, some data structures are simplified in the figure.

969304.fig.0018
Figure 18: Dataflow chart of MAR.

The communication between nodes is specified, and if the requirements are changed, the device modules need not to be changed, and the developer is to choose or design the necessary control algorithm node based on the requirement. The robot IDE supplies functions of choosing the MS software modules, developing control node procedures, setting real-time OS services, and so forth.

It can be seen that using F-Model, the MAR applications, system components, and hardware modules are decoupled, resulting in that the reuse is implemented. Based on the requirements of MS control, the real-time working chains are reasonably arranged. MAR system runs well.

8. Discussion

Although a preliminary modular framework has already been constructed, there are some points to be discussed for the modular MS.

Firstly, the neat application node design depends on plenty of implementations of component or modules. If the various designs can follow the whole or the part of the same framework, these components will increase greatly. Future researchers should guarantee that the package of the valuable research results should be provided to others for reuse.

Secondly, uPnP is ideal future design requirement. MS requirement is various, thus the reasonable uPnP mechanism based on the specified interfaces needs further research. In this problem, the hardware module classification is primarily presented and the meaningful exploration is done for the further module specification.

Thirdly, the thoroughly automotive design is not implemented. Automotive design tool is the development aim of modular system; however, common automotive design tools’ comprehensions for modular MS are inconsistent. These tools are not mature in automotive design and are hard to form complete modular design system.

Finally, F-Model does not limit the relationship between the MS itself and the surrounding devices and does not consider the module adjustment for that the system resource is extremely limited. It is just a preliminary exploration and further research and development are needed.

9. Conclusion

In this paper the core guidance for modular MS reuse and based on this a general framework is presented, which includes software structure, hardware structure, and infrastructure; then two different kinds of modular MS instances are designed to establish the effectiveness of the framework. The MS modular design should follow the MS control information model, decouple the software and hardware, and assemble the MS applications with software engineering technologies.

Acknowledgments

This work is supported by Natural Hi-tech Development Program (“863”) of China under the Research Project 2012AA041400. The authors greatly appreciate the researchers and engineers staffs of the ITR Laboratory in Robotics Institute of Beihang University for their tremendous help and kind assistance for them. This work was supported in part by the 863 Program of China under Grant 2012AA041400.

References

  1. N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, and W.-K. Yoon, “RT-Component object model in RT-Middleware—distributed component middleware for RT (Robot Technology),” in Proceedings of the IEEE International Symposium on Computational Intelligence in Robotics and Automation (CIRA '05), pp. 457–462, IEEE, Piscataway, NJ, USA, June 2005. View at Scopus
  2. N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, and W.-K. Yoon, “RT-Middleware: distributed component middleware for RT (Robot Technology),” in Proceedings of the IEEE IRS/RSJ International Conference on Intelligent Robots and Systems (IROS '05), pp. 3555–3560, IEEE, Piscataway, NJ, USA, August 2005. View at Publisher · View at Google Scholar · View at Scopus
  3. H. Utz, S. Sablatnög, S. Enderle, and G. Kraetzschmar, “Miro—middleware for mobile robot applications,” IEEE Transactions on Robotics and Automation, vol. 18, no. 4, pp. 493–497, 2002. View at Publisher · View at Google Scholar · View at Scopus
  4. D.-H. Choi, S.-H. Kim, K.-K. Lee, B.-H. Beak, and H.-S. Park, “Middleware architecture for module-based robot,” in Proceedings of the SICE-ICASE International Joint Conference, pp. 4202–4205, IEEE, Piscataway, NJ, USA, October 2006. View at Publisher · View at Google Scholar · View at Scopus
  5. M. Mizukawa, S. Sakakibara, and N. Otera, “Implementation and applications of open data network interface ORiN,” in Proceedings of the SICE Annual Conference, pp. 1340–1343, IEEE, Piscataway, NJ, USA, August 2004. View at Scopus
  6. H. Bruyninckx, “Open robot control software: the OROCOS project,” in Proceedings of the IEEE International Conference on Robotics and Automation, pp. 2523–2528, May 2001. View at Scopus
  7. N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, and W.-K. Yoon, “Composite component framework for RT-Middleware (Robot technology middleware),” in Proceedings of the 2005 IEEE/ASME International Conference on Advanced Intelligent Mechatronics (AIM '05), pp. 1330–1335, Monterey, Calif, USA, July 2005. View at Scopus
  8. J. Jackson, “Microsoft robotics studio: a technical introduction,” IEEE Robotics and Automation Magazine, vol. 14, no. 4, pp. 82–87, 2007. View at Publisher · View at Google Scholar · View at Scopus
  9. D. Brugali and P. Scandurra, “Component-based robotic engineering (part I),” IEEE Robotics and Automation Magazine, vol. 16, no. 4, pp. 84–96, 2009. View at Publisher · View at Google Scholar · View at Scopus
  10. D. Brugali and A. Shakhimardanov, “Component-based robotic engineering (Part II): systems and models,” IEEE Robotics and Automation Magazine, vol. 17, no. 1, pp. 100–112, 2010. View at Publisher · View at Google Scholar · View at Scopus
  11. SONY. SONY Open-R Specification, http://www.aiboworld.tv/_download/common/OpenR.pdf.
  12. S. C. Ahn, J. H. Kim, K. Lim, H. Ko, Y.-M. Kwon, and H.-G. Kim, “UPnP approach for robot middleware,” in Proceedings of the IEEE International Conference on Robotics and Automation, pp. 1959–1963, Barcelona, Spain, April 2005. View at Publisher · View at Google Scholar · View at Scopus
  13. S. Magnenat, V. Longchamp, and F. Mondada, “ASEBA: an event-based middleware for distributed robot control,” in Proceedings of the IROS Workshop of the IEEE/RSJ International Conference on Intelligent Robots and Systems, (IROS '07), San Diego, Calif, USA, 2007.
  14. S. Magnenat, P. Rétornaz, M. Bonani, V. Longchamp, and F. Mondada, “ASEBA: a modular architecture for event-based control of complex robots,” IEEE/ASME Transactions on Mechatronics, vol. 16, no. 2, pp. 321–329, 2011. View at Publisher · View at Google Scholar · View at Scopus
  15. G. S. Virk, “CLAWAR: modular robots for the future,” in Proceedings of the 3rd International Workshop on Robot Motion and Control (RoMoCo '02), pp. 73–76, 2002.
  16. Z. Ying, W. Tianmiao, W. Hongxing, L. Chengcheng, and L. Shiyi, “F-Model: model of modular robot based on functional component,” in Proceedings of the 15th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA '09), pp. 91–96, August 2009. View at Publisher · View at Google Scholar · View at Scopus
  17. H. Wei, S. Li, Y. Zou, L. Yang, and T. Wang, “A middleware based control architecture for modular robot systems,” in Proceedings IEEE/ASME International Conference on Mechatronics and Embedded Systems and Applications (MESA '08), pp. 327–332, December 2008. View at Publisher · View at Google Scholar · View at Scopus
  18. W. Hongxing, D. Xinming, L. Shiyi, T. Guofeng, and W. Tianmiao, “A component based design framework for robot software architecture,” in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS '09), pp. 3429–3434, St. Louis, Mo, USA, October 2009. View at Publisher · View at Google Scholar · View at Scopus
  19. M. Törngren, D. Chen, and I. Crnkovic, “Component-based vs. model-based development: a comparison in the context of vehicular embedded systems,” in Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA '05), pp. 432–440, September 2005. View at Publisher · View at Google Scholar · View at Scopus
  20. T. J. Van Beek, M. S. Erden, and T. Tomiyama, “Modular design of mechatronic systems with function modeling,” Mechatronics, vol. 20, no. 8, pp. 850–863, 2010. View at Publisher · View at Google Scholar · View at Scopus
  21. I.-M. Chen and G. Yang, “Inverse kinematics for modular reconfigurable robots,” in Proceedings of the IEEE International Conference on Robotics and Automation, pp. 1647–1652, May 1998. View at Scopus
  22. J. Lei, T. Wang, and Y. He, “The modular approach based on functional components division for modular reconfigurable walking robot,” in Proceediongs of the ASME/IFToMM International Conference on Reconfigurable Mechanisms and Robots (ReMAR '09), pp. 540–544, June 2009. View at Scopus
  23. M. Khalgui, O. Mosbahi, Z. Li, and H.-M. Hanisch, “Reconfiguration of distributed embedded-control systems,” IEEE Transactions on Mechatronics, vol. 16, no. 4, pp. 684–694, 2011. View at Publisher · View at Google Scholar · View at Scopus
  24. C. Zongyan and Y. Xinmin, “Reconfigurable controller for re-configurable manufacturing system,” Computer Engineering and Applications, vol. 39, no. 5, pp. 148–150, 2003.
  25. P. Mantegazza, E. L. Dozio, and S. Papacharalambous, “Rtai: real time application interface,” Linux Journal, vol. 2000, no. 72, p. 10, 2000.
  26. RGMP project for RTOS and GPOS on Multi-Processor, http://rgmp.sourceforge.net/.
  27. Y. Tsuchiya, M. Mizukawa, T. Suehiro, N. Ando, H. Nakamoto, and A. Ikezoe, “Development of Light-weight RT-component (LwRTC) on embedded processor-application to crawler control subsystem in the physical agent system,” in Proceeding of the SICE-ICASE International Joint Conference, pp. 2618–2622, kor, October 2006. View at Publisher · View at Google Scholar · View at Scopus
  28. M. Liu, Z. Shao, M. Wang, H. Wei, and T. Wang, “Implementing hybrid operating systems with two-level hardware interrupts,” in Proceedings of the 28th IEEE International Real-Time Systems Symposium (RTSS '07), pp. 244–253, Tucson, Arizona, USA, December 2007. View at Publisher · View at Google Scholar · View at Scopus