Paper received: 28.2.2008 Paper accepted: 15.5.2008
Methodical Development of Innovative Robot Drives
Ralf Stetter1* - Andreas Paczynski1 - Michal Zajac2 'University Ravensburg-Weingarten, Germany 2University Zielona Gora, Poland
Strategies, methods, and tools which help design engineers in the development of complex mechatronic systems such as mobile robots are presented. The focus of this paper is a process for the interdisciplinary product development of these mechatronical systems. This process was developed and tested on the example of the product development of highly dynamic robot drives. The basis for this product development process is a streamlined (i.e. simplified) V-model, as it is known for managing software and mechatronical projects in official organizations. Advantages and disadvantages of a systematic procedure scheme are discussed and concrete recommendations are derived from the experience during the development of highly dynamic robot drives. The contribution of the paper is the reflection of a case study in the growing field of mechatronic design. The developed drive systems for mobile robots are aimed at a reduction of the complexity of drives for mobile robots. Such robots can be usedfor numerous tasks. The application of such mobile robots has already started with fully automatic lawn mowers and vacuum cleaners. © 2008 Journal of Mechanical Engineering. All rights reserved.
Keywords: product development, mechatronics, methodical development, robot drives
1 INTRODUCTION
The main characteristic of mechatronical products is the functional and/or spatial integration of subsystems from the engineering disciplines mechanical engineering, electrical engineering, and computer science. Innovative drive control systems for vehicles of all kinds have to combine the capabilities of subsystems of the different disciplines in order to achieve current performance objectives. However, even if the term mechatronics is now used for some years and even if elaborate methodologies for structuring the development of mechatronical products were generated, still little support is given to the individual engineer or manager. In this paper a product development process is analyzed in detail and concrete recommendations and hints for the content oriented planning and control of development processes of mechatronical products is presented. These recommendations and hints are based on the V-model for mechatronical products but their focus is on pragmatic answers and solutions for individual engineers or managers of small development teams. One type of vehicles with high market potential are mobile robots which have been developed and researched in academia for decades but which still have not be able to achieve the expected market
success. Such mobile robots could potentially influence and assist nearly every area of human life, starting from household tasks to the support of physically impaired persons. It can be hypothesized that a main obstacle for the success of mobile robot is still their complexity and susceptibility to external conditions. The content of the product development process that was analyzed in the presented research work is the development of a highly dynamic robot drive. This drive is aimed at simplifying mobile robots and by this to enhance their robustness.
2 BACKGROUND REVIEW
In this section the V-Model as the most prominent methodology for developing mechatronic products is discussed in detail.
2.1. Introduction
A process model can be defined as a flow model used by professionals such as engineers and design managers as a tool assisting the management and organization of their systems or processes. In the field of engineering, for example, process models have been extensively used by engineers for their product or system development in order
*Corr. Author's Address:University Ravensburg-Weingarten, Department of Mechanical Engineering, Postfach 1261, 486	88241 Weingarten, Germany, stetter@hs-weingarten.de
to achieve more manageable and organized development processes.
In a process model, the whole development process is decomposed into several single activities. Each of these single activities has its own logical sequences and the responsible person or department. Hence, the development process can be more transparent and controllable.
Many types of process models are available for engineering product or system development. The examples of these process models are like VDI 2221: "Methodology for development and design of technical systems and products" and VDI 2422: "Design procedure for mechanical devices with microelectronics control". For mechatronics system development, a process model called V-model is suitable and generally the recommended one.
2.2 The V-Model as Process Model for Mechatronics System Engineering
The V-model is a graphical representation of the system development lifecycle. It was adopted by Germany federal administration to regulate software development processes in 1997. After considerable adoption and modification, the V-model has been suggested by VDI Guideline 2206 as a "Design methodology for mechatronical systems" [34], [16] and [17]. Several researchers report current endeavors to apply and optimize this methodology for the product development of different mechatronic systems [1], [2], [6] to [9], [21] and [24]. Nowadays, the V-model has become a standard process model for mechatronic system development in many industrial companies.
The V-model was chosen to be used in mechatronics system or product development because of its structure. As stated above, mechatronics is an interdisciplinary engineering discipline that combines essential elements or knowledge of mechanical engineering, electrical engineering, and computer science.
In the mechatronics product or system development process, communication between the engineers is very essential in order to avoid misunderstanding in the product or system that is being developed. By using conventional process models for respective engineering disciplines, problems may occur in the last stage of the development processes since there is no interconnection between each section of the design.
So unlike the conventional process model for mechanical, electrical, and computer science that have their own approach, the V-model organizes the development process by first working in the system level before splitting it into the respective disciplines for further concretizing. The developed product or system then will be integrated level by level. The validation and verification processes are done simultaneously with the integrating process to make sure that the product or system for each engineering discipline is suitable and compatible with each other. Hence, the V-model helps each engineer involved in the development process to have a rough idea about the whole product or system that is being developed before the individual engineers start working in their domain-specific level.
2.3 The General Structure of a V-Model
Generally, the V-model can be divided into three main sections and is always described in V shape. It consists of the System Design at the left side, the System Integration at the right side and the Domain-specific Design at the tail of the V-model. Figure 1 shows the general structure of the V-model.
The first step in designing using the V-model is by providing the requirements list of the system as shown at the top left side. A requirements list provides the specification or information about that particular product or system that is being developed. A requirements list also forms the measurement basis on which the later product is to be assessed.
Based on the requirements list, a cross-domain principle solution that describes the main physical and logical operating characteristics is established. This stage of development is called System Design. At this stage, the overall function of that system is divided into several chunks called sub-functions. Each sub-function is assigned with a suitable operating principle or solution.
On the basis of this jointly developed solution, further concretization takes place in the Domain-specific Design stage which is generally done separately between the domains involved. A thorough calculation, drawing, analysis, or simulation is carried out at this stage according to the respective domain.
At the System Integration stage, results from the individual domains are integrated. Relations
Fig. 1. General structure of the V-model [34]
between sub-functions are taken into account as well as the verification and validation processes to assure product functionality, performance, quality, and economic value. The verification and validation processes are very important in order to make sure that the right product is being developed in the right way. The final result of the V-model is the mechatronical product of the developed system that is shown at the top right side.
2.4 Development Methodology of Mechatronics Systems According to the Guideline VDI 2206
The development methodology of mechatronical system according to the guideline VDI 2206 consists of two procedure schemes:
■	the general problem-solving cycle on the microlevel, and
■	the V-model on the macro-level.
In this regard micro-level can mean sequences of proceeding steps lasting from few hours up to some months. In any case these sequences do not reflect the complete design of a mechatronical product but a specific problem within this product development. The notion macro-level names sequences of proceeding steps aimed at the complete development of a product or at least a major sub-system.
Problem-Solving Cycle as a Micro-Level
The VDI 2206 provides a general procedure for process steps on the micro level or methodology
known as 'Problem-Solving Cycle'. It originates from systems engineering [13] as a guideline for a systems developer or engineer to be used during the problem solving processes along the development process of mechatronics system. This 'Problem-Solving Cycle' can be applied as a microlevel in the development process and is intended in particular to support the product developer engaged in the process to work on predictable, and consequently plan able subtasks, but also to solve suddenly occurring, unforeseeable problems.
Figure 2 shows the organization of the 'Problem-Solving Cycle' according to [13].
The 'Problem-Solving Cycle' contains several stages:
■	The stages 'situation analysis' or 'adoption of a goal' are the initial stages of the 'Problemsolving Cycle'. The procedure to be chosen is based on the situation whether an existing structure is taken as a basis or an ideal concept is at the forefront.
■	The aim of the stage 'analysis and synthesis' is to find out several alternative solution variants. This is achieved by an alternation between synthesis steps and analysis steps.
■	In the 'analysis and assessment' stage the properties of the individual variants of a part solution or an overall solution are analyzed on the basis of the requirements imposed on them. Furthermore the assessment of the solution variants takes place on the basis of the assessment criteria defined during the
Procedure based on actual state
(existing structure is taken as a basis)
initiation
Procedure based on desired state
(ideal concept is at the forefront)
initiation
Fig. 2. The Problem-Solving Cycle [13] and [34]
Fig. 3. Running through a number of macro-cycles [34]
formulation of a goal and search for a solution. The result of the assessment is a proposal or recommendation for one or more alternatives solutions.
In the 'decision' stage a decision is made for the further development process whether the solutions are satisfactory or not. In the case that the solutions are not satisfactory, prior stages
have to be repeated. ■ The planning the further procedure or learning is aimed at a continuous improvement cycle.
The V-Model as a Macro-Level
The VDI 2206 has recommended the usage of the V-model as a generic procedure (Macro-Level) for designing mechatronical systems. The general structure has already been discussed in Section 2.3. It is important to note that even on the macro level the V-Model does not necessarily represent the whole development process. On the contrary, a complete development process might consist of several re-runs of the V-model with increasing product maturity. This characteristic is highlighted in Figure 3.
3 DESIGN PROJECT
In the analyzed development of a mechatronical product an innovative drive system for mobile robots was to be developed and built. Mobile robots and their drive systems have been successfully developed and built for some years [4], [5], [14], [18], [30] and [36]. The distinctive quality of this design project is the highly dynamic drive system. The innovative drive system that is already registered as a patent is based on the concept to use the torque of drive motors (more exactly the torque differences between wheels) to steer four independent axes of a robot. The principal design of a mobile robot with the developed drive system is shown in Figure 4.
The example robot consists of four drive motors which are fastened on arms that may freely rotate. These arms have no drive or brake, only an angle encoder is attached at the end of each axle. These angle encoders measure the angle of the
Fig. 4. Principal Design
motor and the wheel with regard to the robot platform.
The distinct characteristic of the innovative drive system is the absence of dedicated steering motors. By means of angle encoders applied at the four steering axes and highly dynamic control algorithms it is possible to steer the robot only by means of the four drive motors (compare Fig. 5). Each of the wheels on the short axle can be directed into the desired position by means of the torque applied on the wheel. This could take place sequentially for each individual wheel but also simultaneously, if the control allows different torque on all wheels. This characteristic allows simpler and simultaneously more robust mobile robot concepts. It is also a main advantage of this concept that the resulting robot is able to drive directly in any direction without time and space consuming turning maneuvers.
Furthermore, a robot based on the dynamic drive system is able to turn around its own centre. This characteristic is very important if cameras or other equipment are mounted on the robot which can only be used in a certain orientation. The innovative dynamic drive system shares these advantages with Omni drive systems [5], but has reduced friction as well as easier controllability and offers the possibility to determine an exact position and orientation from an analysis of the angles of the steering axes and the angles of the drive wheels. Another intended characteristic of the developed prototype is the exclusive use of standard, state of the art components and interfaces, such as CAN Open.
An application example as service robot is shown in Figure 6.
The robot was realized in the University workshop and is currently being tested and improved (Fig. 7).
Fig. 5. Individual adjustment of the steering angle
Fig. 6. Dynamic drive robot (application example) 4 INSIGHTS
In this section, concrete recommendations in the form of strategies, tools, and rather mundane hints for the development of mechatronical products are derived from the experience made in the development of the dynamic robot drive. This section is structured according to the V-model described in section 2 (Fig. 1). The first subsection deals with the planning and control of the whole development process.
4.1. Planning and Control of the Process
Obviously, milestones and objectives on the system level can only be met, if the development process of a mechatronical product is planned and controlled on an interdisciplinary system level. This interdisciplinary planning and controlling can be considered the main challenge in mechatronical products. Theoretically, one could argue that the content of the tasks is not as important when planning and controlling those tasks on the abstract system level and that therefore the difference between a conventional product and a mechatronical, interdisciplinary system is not as important. However, in the project the sensible sequence of the different tasks of the different systems proved to be a difficult and crucial endeavor. In any product some subsystems influence many other subsystems (active subsystems) while other subsystems are mainly influenced by other subsystems (passive subsystems). This influence is not limited to the different disciplines. For instance, the decision for drive motors (brushless) required certain motor control systems. A well known method aimed at identifying the degree of influence of certain
Fig. 7. Prototype of the robot
		influence			
			on		
Which subsystems have an influence on which		E <u tn	2 E <u tn	CO E <u tn	E <u tn
subsystems?		tn .Q	tn .Q	tn .Q	tn .Q
					
<U o c	subsystem 1		0	1	1
	subsystem 2	1		2	0
™ u	subsystem 3	2	2		1
	subsystem 4	2	1	3	
	passive sum	5	3	6	2
Fig. 8. Influence matrix (example)
subsystems is the influence matrix. In the influence matrix all subsystems are listed in the rows and in the columns. It is now assessed how strong one specific subsystem is influencing another specific subsystem. The results are then added in rows as passive sum and in columns as active sum. Figure 8 shows an influence matrix.
The results of an influence matrix can be depicted in a portfolio. For different types of subsystems can be distinguished:
■	"buffering" subsystems which influence few other subsystems and are only influenced by few other subsystems,
■	active subsystems which influence many other subsystems, but are only influenced by few other subsystems,
■	passive subsystems which influence few other subsystems, but are influenced by many other subsystems, and
passive subsystems S1 •	critical subsystems S3 •
S buffering subsystems	2 • S4* active subsystems
active sum
Fig. 9. Influence portfolio (example)
■ critical subsystems which influence many other subsystems and are influenced by many other subsystems.
Figure 9 shows the result of an influence matrix - an influence portfolio.
It is crucial that the critical and active subsystems are defined initially in the development process of mechatronical products. Usually, for each subsystem a prominent discipline, i.e., the discipline that has the highest share in the development of this subsystem can be identified. Concerning the sensible development sequence of subsystems, no distinction between the disciplines may be made. For a successful system development, the most critical and active subsystems have to be developed first, no matter what is the prominent discipline. This presents a challenge for synchronizing the tasks. Frequently, one discipline virtually has to wait until the prominent disciplines for critical and active subsystems have finished their work. This is aggravated by the fact that engineers are usually only experts in one discipline. Consequently, the experts from disciplines concerned with less critical subsystems cannot be used for the critical subsystems. They can only sensibly be used in the development of buffering subsystems, as the work on passive subsystems might be virtually worthless, if the active subsystems are not yet defined.
An intelligent process control therefore initially has to focus on the disciplines concerned with the critical and active subsystems and has to make sure that the other disciplines meanwhile only work with buffering subsystems but not with passive subsystems.
In the project another important characteristic of mechatronical products with a
central subsystems	critical subsystems
buffering subsystems	innovative subsystems
low	Novelty	high
Fig. 10. Project sequence portfolio for mechatronic products
great influence on the sensible sequence of development steps was identified: the degree of novelty. In most products some subsystems are well known components while other subsystems are to be applied for the first time or at least are to be applied in different surroundings. For the planning and controlling it is important to identify the most innovative subsystems and to develop them first, as they carry the highest risk and may require the longest time span to be realized and optimized. It is important to note that even only one subsystem which is not ready at the delivery or launch date may endanger the whole project success. Therefore novel subsystems have to be identified early in the development. Possible criteria for identifying novel subsystems are (in a sense these criteria define the term "novelty" in this context):
■	degree of innovation: subsystems which include innovative functions or subsystems (innovative in the sense of "not applied earlier in similar products") have a high degree of novelty,
■	maturity of development methodology: subsystems for which a development methodology is not yet established or existing have a very high degree of novelty,
■	simulation possibilities: subsystems which functions and behavior cannot be calculated or simulated have a high degree of novelty,
■	variety: subsystems which are not yet available in many types have a high degree of novelty (e.g. piezoelectric actuators compared to electromagnetic actuators), and
■	customization potential: subsystems which cannot be easily customized, if deviations from a standard form are necessary because of other subsystems, have a high degree of novelty.
These criteria and the resulting degree of novelty are the basis for a risk oriented sequence of the development tasks.
The decision of the development order of different subsystems has to take two dimensions into account: the level of influence and the level of novelty. Figure 10 shows a portfolio - the project sequence portfolio for mechatronic product - that is proposed by the authors to be used in the development of mechatronical products.
It is an important prerequisite for the development of mechatronical products that critical subsystems are tackled first and with the necessary resources and that disciplines or single engineers which cannot contribute to this development only work on buffering or innovative subsystems.
4.2 Requirements
Research in mechanical design has frequently highlighted the importance of a conscious and extensive clarification of the task [22], [25] and [15]. It may be hypothesized that this is valid for all concerned disciplines. Accordingly, in current industrial practice large documents are generated (systems specification, performance specification, and contract specification).
Frequently, however no distinct requirements are highlighted in these documents, which can be tracked and against which the developed system might be validated. Very often, the most important performance parameters are hidden in long passages of text which are necessary (or are believed to be necessary) for instance for legal reasons in the collaboration of original equipment manufacturers and suppliers.
Furthermore, quite often these documents are generated in the beginning and are never updated. It lays in the nature of product development that the knowledge about the system to be developed is increasing while the system is maturing during the steps of the development process. This additional knowledge results, on the one hand, in new requirements which could not be identified in the initial stages. For instance, requirements which are connected with a specific material selection can only be identified after the materials have been chosen. On the other hand, frequently requirements have to be revisited and refined due to additional knowledge. For instance,
unexpected failure in a system test may lead to increased requirements. One cause for this might be an underestimation of external loads.
A promising approach that was used in the project is the usage of a requirements list. Such a list contains distinct requirements of objectives which are accompanied by a numerical value and tolerance. Each requirement is identified by a number and can therefore be updated and tracked throughout the development process.
The main specific problem in the treatment of requirements in the development process of mechatronical products is to identify which requirement is necessary for which discipline. For instance, the performance parameter "precision of steering" for the drive system for the mobile robot may influence the disciplines mechanical engineering, electrical engineering, and computer science, as well. The simplest possible answer is that any requirement is potentially important for any disciplines and that no distinction can be made. Consequently each discipline would have to deal with the complete set of requirements. This is possible in small projects but leads to time-consuming parallel tasks which are aimed at investigating whether some requirements are influencing the specific discipline. It is therefore proposed to include information in the requirements list which disciplines are presumably influenced.
Figure 11 shows the structure of the resulting requirements list for mechatronical products. Such a list can be part of a system specification or contract specification but should not be disseminated in formulated text due to the reasons mentioned above.
Current research is looking into structuring requirements and into integrating qualitative user desires (e.g. [23] and [29]). The integration of these approaches will be content of further research work.
No	Requirement/	Value and	Prority*	Dis- I
	Objective |	Tolerance |		cipline** 1
*) e.g. R requirement, W wish
**) e.g. A all, M mechanical, E electrical, H hardware, etc.
Fig. 11. Requirements list for mechatronical products
4.3 System Design
In the system design stage a cross-domain principle solution that describes the main physical and logical operating characteristics is established. The challenge in this stage lays in the interdisciplinary nature. All disciplines have to work together in order to achieve an optimum principle solution. The large danger that could be observed is that everyone is talking about components of their subsystem, their performance and behavior, the necessities for applying the components, and the potential problems with their components. This causes two kinds of problems:
■	It is never (and can never be) inquired, if the component which was "arbitrarily" (in the sense of not aware of the consequences on the system level) chosen by the specific expert is the optimum component in the cross-domain frame.
■	The experts of other disciplines do not (and cannot) know the component in detail and can therefore not comment, judge, and synthesize on the performance, behavior, and necessity of the component.
In most engineering disciplines measures to overcome the problems and obvious limitations with "component talk" were developed. These measures have in common that they construct descriptions of the product on a more abstract level than the component level. Some examples of these measures are "function structures" in mechanical engineering, "wiring diagrams" and "block diagrams" in electrical engineering, as well as "use case diagrams" and "class diagrams" in computer science. These product descriptions help engineers to understand complex systems and allow communication on an abstract level. From the limitations of "component talk" it can be concluded that communication on an abstract level is necessary in order to achieve an optimum result. The problem in the development of mechatronical products is that experts of the different disciplines are not able to understand abstract product descriptions of other disciplines. Therefore in the system design stage the experts and managers have to agree on a simplified abstract language which contains the following elements:
■	Input/Output: on an abstract level the performance and behaviors of each subsystem can be described by its input and output (compare black box method). E.g.: A motor
controller receives an input signal from the can bus and sends electrical power to the motor.
■	Aggregation/Decomposition: the (vertical) structure of each subsystem can be described with the terms: "is part of" and "consist of". E.g.: A mobile robot consists of a base plate, motor controllers, motors, encoders, and axes. The base plate is part of the mobile robot.
■	Function: the purpose of each subsystem (the horizontal or process structure) can be described by noun-verb-phrases. E.g.: An electrical motor "transforms energy" (from electrical energy to mechanical energy).
■	Generalization/Specialization: components can be a part of "classes" of components - in philosophy these classes are sometimes referred to as (abstract) ideas. No one knows how an "animal" looks like, as this term is the generalization of many animals. Similar a motor might be a combustion engine, an electrical motor, or even a steam engine. The term "is a" usually is a sign for a generalization, "can be a ... or" is a sign for a specialization.
In this paper no new language for the abstract modeling of mechatronical products is proposed, because all experts already know some abstract languages. They should be aware of the dangers and limitations of "component talk" and should know the central elements of any abstract language. It is important to note that current research is focusing on unified representations (e.g. [38] and [11]), but that a cross-disciplinary consensus is not yet visible. Further research has identified state transitions as an important characteristic of mechatronical products [39].
4.4 Domain Specific Design
It was found in the project that one of the most challenging parts is the concrete development of the domain-specific subsystems. There is a well known idiom that devil is in the detail. Probably, everyone engaged in product development processes can give examples to support this expression. In each disciplines powerful strategies, methods, and tools have been developed to assist the engineer in his enduring fight with the product detail. In this paper, only the importance and difficulty of the domain specific design is underlined, but for obvious reasons no specific methods and tools can be recommended.
4.5	System Integration
Successful system integration is strongly based on profound work in the system design stage. Additionally, the experience made in the example project underlined the fact that the system integration has to take place parallel to the domain specific design. Cross-domain functionality can only be achieved if the interfaces between the disciplines are clearly defined and are thoroughly tracked and negotiated during the product development process of mechatronical products. Besides the interface description methodology used in their own discipline, the engineers in the development process of a mechatronical product need to be aware about the common characteristics of any interface. The characteristics are:
■	Functional characteristics: The purpose of interfaces is usually the transfer of a "flow" of any kind. For instance, at the interface between a motor controller and an electric motor a flow of electric energy can be observed. This flow through any interface can be described by using the three types matter, energy, and signal. This classification is commonly used in functional modeling in mechanical engineering and allows describing the abstract, functional characteristics of any interface.
■	Compatibility: Interfaces usually need some common or accommodating features in order to function as interface. Such compatibility may be geometric compatibility, e.g., same form of male and female connectors, kinematical compatibility, e.g., identical movement during operation, or syntactic compatibility, e.g., a common protocol or language.
■	Common functions: frequently some functions, such as sealing functions, can only be realized if both parts of an interface provide certain properties, e.g., geometry. In the development process of mechatronical products for each common function at an interface one discipline needs to assume the responsibility. This discipline has to assure that both subsystems which build up an interface display characteristics that allow the common function.
4.6	Verification/Validation
In electrical engineering and computer science the "X in the loop" verification procedures
(e.g., hardware in the loop) are common practice. The development of competitive systems in limited time spans requires such procedure. However, in mechanical engineering such procedure is rarely applied. This might be caused by a prominence of analysis and simulation techniques. Still, if one is aware of the immense expenditures invested in physical prototypes, a reduction of these expenditures may seem possible by applying "X in the loop" verification procedures even for the subsystems or functions which are primarily located in the mechanical discipline. Such procedure is only feasible if the disciplines communicate actively at what time in the development process they can provide which subsystems or functions and, more important, if the disciplines inquire about simulation possibilities of their subsystems and functions. In a sense, each discipline needs to inquire about the possibilities to simulate the behavior of their subsystems in functions in order to allow other disciplines to verify their subsystems or functions. For instance, an engineer in charge of the development of the mechanical platform should provide simulation models of this mechanical platform so that the engineers in charge of electronic hardware and software can verify their solutions by using this simulation model. Cross-domain "X in the loop" procedures carry the potential to accelerate and streamline the verification and validation processes of mechatronical products. The integration of mechanical engineering in these procedures is a main challenge for further research and tool development for the design of mechatronical products.
5 SUMMARY AND OUTLOOK
Mechatronic products are characterized by a large number of interfaces. Functions are fulfilled by a combination of mechanical and electrical parts and software. This characteristic influences the product development process - mechatronic products have to be developed in cross-domain teams. It is an illusion that the procedures and tools of one of the domains can be adopted for steering and controlling the design process. It is a main challenge for research in product development to address the additional problems and chances.
In this paper a concrete product development process - the development of a highly
dynamic robot drive aimed at simplifying and enhancing mobile robots - was analyzed in detail. From this basis pragmatic tools and recommendations for a conscious planning and controlling of development processes of mechatronical products were derived. These tools and recommendations are structured according to the well-known V-model for mechatronical products. The tools and recommendations focus on pragmatic answers and solutions for individual engineers or managers of small development teams. For a successful application in industry these need to be adapted to the given situation and to consciously be implemented (compare [22], [32] and [33]). The research is meant to be one stone in the road towards a goal directed and pragmatic development methodology for mechatronic products.
The development of the dynamic robot drive is ongoing, as is the research in the methods and tools for the development of mechatronical products. Many challenges lay in this research area and the preliminary results presented in this paper need to be verified and optimized in industrial practice.
Acknowledgments
The described design projects are funded by the German federal ministry of education and research (BMBF) and by the study commission for didactics at universities for applied sciences in Baden-Württemberg in the scope of the project LARS. The authors also want to thank the University administration and workshop for the kind support.
6 REFERENCES
[1]	Albers, A., Brudniok, S. Methodische Entwicklung von hochintegrierten mechatronischen Systemen am Beispiel eines Humanoiden Roboter. VDI-Bericht 1971: Mechatronik 2007 -Innovative Produktentwicklung -Maschinenbau, Elektrotechnik, Informationstechnik. Wiesloch: VDI, 2007.
[2]	Albers, A., Deigendesch, T., Meboldt, M. Information integration and cooperation in product development by utilization of wikis. Horvath, I.; Rusak, Z. (Eds): Proceedings of TMCE 2008. Izmir, Turkiye, 2008.
[3]	Alciatore, D.G., Histand, M.B. Introduction to mechatronics and measurement systems. New York: McGraw-Hill, 2003.
[4]	Anderson, K., Jones, C. Autonomous robotic vehicle design. Proceedings of the Southwest Regional ASEE Conference, ASEE 2005.
[5]	Ashmore, M., Barnes, N. Omni-drive robot motion on curved paths: The fastest path between two points is not a straight-line. Proceedings of the Australian Joint Conference on Artificial Intelligence, Dec., 2002, pp. 225-236.
[6]	Bathelt, J., Jönsson, A., Bacs, C., Kunz, A, Meier, M. Conceptual design approach for mechatronic systems controlled by a programmable logic controller (PLC). Norell, M. (Ed.): Proceedings of ICED03 International Conference on Engineering Design, Stockholm, Sweden, 2003.
[7]	Bathelt, J., Jönsson, A., Bacs, C., Dierssen, A, Meier, M. Applying the new VDI design guideline 2206 on mechatronic systems controlled by a PLC. Proceedings of ICED05 International Conference on Engineering Design, Melbourne, Australia, 2005.
[8]	Bludau, C.; Welp, E. Semantic web services for the knowledge-based design of mechatronic systems. Proceedings of ICED05 International Conference on Engineering Design, Melbourne, Australia, 2005.
[9]	Bernardi, M., Bley, H., Schmitt, B. Integrating a mechatronics-oriented development process into a development department. Proceedings of CIRP, Budapest, 2004.
[10]	Braun, S., Lindemann, U. Multiplanare Vernetzungen - Abhängigkeiten zwischen Produktkonzept, Produkterstellungsprozess und Ressourcenverbrauch in der Mechatronik. Gausemeier, J., Ramming F., Schäfer, W., Trächtler, A., Wallaschek, J. (Hrsg.): 5. Paderborner Workshop - Entwurf mechatronischer Systeme, 22.-23.03.2007. Paderborn: Heinz Nixdorf Institut, p. 319-334.
[11]	Campbell, M., Cagan, J., Kotovsky, K. The A-design approach to managing automated design synthesis. Research in Engineering Design, 2003, 14, p. 12-24.
[12]	Czichos, H. Mechatronik. Wiesbaden: Vieweg, 2006.
[13]	Daenzer, W.F., Huber, F. Systems engineering - methodik und praxis, 1997.
[14]	Dillard, W. Revisting the autonomous robot. Finding the engineer within the student.
Proceedings of the 2004 AEE Conference, Salt Lake City, 2004.
[15]	Ehrlenspiel,	K.	Integrierte Produktentwicklung. München: Hanser, 2002.
[16]	Gausemeier, J., Lückel, J. Entwicklungsumgebungen Mechatronik. Methoden und Werkzeuge zur Entwicklung mechatronischer Systeme. Heinz-NixdorfInstitut, University of Paderborn, Germany, 2000.
[17]	Gausemeier, J., Möhringer, S. New guideline VDI 2206 - A flexible procedure model for the design of mechatronic systems. Norell, M. (Ed.): Proceedings of the 14th International Conference on Engineering Design (ICED), Stockholm, 2003.
[18]Hirose	S., Fukushima E.F. Development of mobile robots for rescue operations. Advanced Robotics, vol. 16, no. 6, 1 September 2002, p. 509-512(4).
[19]	Isermann, R. Mechatronische Systeme -Grundlagen. Berlin: Springer 2002.
[20]	Isermann, R. Modeling and design methodology for mechatronic systems. IEEE/ ASME Transactions on Mechatronics, vol. 1, no. 1, March 1996, pp. 16-28.
[21]	Jansen, S., Welp, E. Model-based design of actuation concepts: a support for domain allocation in mechatronics. Proceedings of ICED05 International Conference on Engineering Design, Melbourne, Australia, 2005.
[22]	Lindemann, U. Methodische Entwicklung technischer Produkte. Methoden flexibel und situationsgerecht anwenden. Berlin: Springer, 2007.
[23]	Maier, J., Ezhilan, T., Fadel, G., Summers, J., Mocko, G. A hierarchical requirements modeling scheme to support engineering innovation. Bocquet, Jean-Claude (Ed.): Knowledge, Innovation and Sustainability. Proceedings of the 16th International Conference on Engineering Design. Paris: Design Society, 2007.
[24]	Möhringer, S. Die neue Richtlinie VDI 2206: Entwicklungsmethodik für mechatronische Systeme. Presentation at the University of Applied Sciences Heilbronn, 08. and 09. May 2003.
[25]	Pahl, G., Beitz, W. Konstruktionslehre. Berlin: Springer, 2004.
[26]	Paczynski, A., Stetter, R. Hochdynamischer Antrieb für mobile Roboter. VDI Bericht 1963 „Elektrisch-mechanische Antriebssysteme Innovationen-Trends-Mechatronik. VDI: 2006.
[27]	Rahman, R., Pulm, U., Stetter, R. Systematic mechatronic design of a piezo-electric brake. Bocquet, Jean-Claude (Editor): Knowledge, Innovation and Sustainability. Proceedings of the 16th International Conference on Engineering Design. Paris: Design Society, 2007.
[28]	Roddeck, W. Einführung in die Mechatronik. Stuttgart: Teubner, 2003.
[29]	Stechert, C., Alexandrescu, I., Franke, H.-J. Modeling of inter-model relations for a customer oriented development of complex products". Bocquet, Jean-Claude (Ed.): Knowledge, Innovation and Sustainability. Proceedings of the 16th International Conference on Engineering Design. Paris: Design Society, 2007.
[30]	Steidley, R, Bachnak, W., Lochachit, W., Sadovski, C., Ross, C., Jeffress G. A remote controlled vehicle for interdisciplinary research and education. Proceedings of the 2004 AEE Conference, Salt Lake City, 2004.
[31]	Stetter, R., Paczynski, A., Voos, H., Bäuerle, P. Teaching "Coupling Competence" by means of interdisciplinary projects. Proceedings of the International Design Conference - Design 2006, Dubrovnik, Croatia, May 15 - 18, 2006.
[32]	Stetter, R.; Lindemann, U. Transferring methods to industry. Clarkson, P. J.; Eckert, C. M. (Eds.): Design process improvement. Springer 2005.
[33]	Stetter, R. Method implementation in integrated product development. Dissertation, TU München, 2000. Zgl. München: Dr.-Hut, 2000.
[34]	VDI 2206. Design methodology for mechatronical systems. Beuth, Berlin, 2004.
[35]	Voos, H., Stetter, R. Design and control of a mobile exploration robot. Proceedings of Mechatronics 2006. 4th IFAC-Symposium on Mechatronic Systems. Heidelberg, 2006.
[36]	Wang, J., Lewis, M., Hughes, S. Gravity-referenced attitude display for teleoperation of mobile robots. Proceedings Of The Human
Factors And Ergonomics Society 48th Annual Meeting 2004.
[37]	Plett, G.L., Kollar, I. Specification for common IEEE styles. IEEE Trans. on Instrum. Meas., vol. 46, no. 6, p. 1056-62, Dec. 1997.
[38]	Xu, Q.L., Ong S.K., Nee A.Y.C. Function-based design synthesis approach to design reuse. Research in Engineering Design, 2006, 17, p. 27-44.
[39]Yong,	X.; Huijun, Z. A function-oriented theoretical framework for mechatronic system design. Strojniski vestnik - Journal ofMechanical Engineering, 53(2007)4, p. 241-252.
[40]	Zajac, M., Paczynski, A., Stetter, R., Ucinski, D. Concept of a control system for a innovative mobile robot chassis. Proceedings of the 16th International Conference on Control Systems and Computer Science. Bucarest: 2007.
[41]	Zajac, M., Paczynski, A., Stetter, R., Ucinski, D. Konzept für ein Sensor/Aktor-Netzwerk für die robuste Steuerung eines mobilen Roboters mit Allradlenkung. VDI-Bericht 1971: Mechatronik 2007 -Innovative Produktentwicklung -Maschinenbau, Elektrotechnik, Informationstechnik. Wiesloch: VDI, 2007.