Development of a Design Method for Conceptual Design with Application on the Design of a Drone / eingereicht von Michael Mayrhofer

(1)

Eingereicht von Michael Mayrhofer Angefertigt am Institute for Mechatronic Design and Production Beurteiler

O. Univ. Prof. Klaus Zeman Mitbetreuung Priv.-Doz. Peter Hehenberger November 2017 JOHANNES KEPLER UNIVERSIT¨AT LINZ Altenbergerstraße 69

Development of

a Design Method

for Conceptual Design

with Application on

the Design of a Drone

Masterarbeit

zur Erlangung des akademischen Grades

Diplom-Ingenieur

im Masterstudium

(2)

(3)

Abstract

In product development projects, especially in large ones, good coordination of the involved engineers’ work is important to improve the quality of the results and the effectiveness of the development process. Best practices from successful development projects are formalised to create design methods. These are applied to improve future projects. The cheap availability of computing power promises to speed up development processes, but by now the conceptual phase of product development is not supported well by software tools.

During this thesis, a concept for a badminton playing drone has been developed relying heavily on software support to explore possible designs. This design project has then been analysed for strengths and weaknesses of the tools and methods used. A design method has been developed which retains those strengths and avoids the weaknesses. In the last part of the thesis, this method was then applied to a second design project targeting the optimisation of an existing drone design.

(4)

(5)

Foreword

A good writer possesses not only his own spirit but also the spirit of his friends.

Friedrich Nietzsche

I do not want to strain the above quote to express any superiority of my writing skills. My way of reading is, that support from others is a great help to realise dreams and ambitious goals. This definitely holds true for this thesis, consisting of two research projects on conceptual design which would not have been possible without kind support from the following organisations:

• The Institute for Mechatronic Design and Production (IMDP) at Johannes Kepler University • The Austrian Competence Center in Mechatronics (ACCM)

• Flanders Make, a belgian research center evolved from the enterprises Flanders Mechatronic Technology Center (FMTC) and Flanders Drive

• The Linz Center for Mechatronics (LCM)

Thank you for the opportunity to work on these topics, it has been an enthralling time which offered new points of view and new targets to pursue in the professional life.

(6)

(7)

Sworn Declaration

I hereby declare that the thesis submitted is my own unaided work, that I have not used other than the sources indicated, and that all direct and indirect sources are acknowledged as references. This printed thesis is identical with the electronic version submitted.

Michael Mayrhofer

Eidesstattliche Erkl¨

arung

Ich erkläre an Eides statt, dass ich die vorliegende Masterarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe.

Die vorliegende Masterarbeit ist mit dem elektronisch ¨ubermittelten Textdokument identisch.

(8)

(9)

List of Figures

1.1. Systematic Design according to Pahl and Beitz ([Pah+07]) . . . 1

2.1. Conceptual Design in the Scope of Systematic Design by Pahl and Beitz ([Pah+07]) 5 2.2. Example of a Function Structure: Checking Bottles in a Filling Plant . . . 6

2.3. Example of an Allocation of Functions to Realisable Systems: Checking Bottles in a Filling Plant . . . 7

2.4. 3D Assembly of a Conveyor Belt with Panels to Guide Bottles . . . 10

3.1. Development of a Computational Model According to Duffy and Andreassen [DA95] 19 3.2. Sketch of a Portal Robot . . . 20

3.3. The Portal Robot in Modelio . . . 21

3.4. The Portal Robot in Papyrus . . . 22

3.5. Feasible and Infeasible Solutions in the Design Space . . . 23

4.1. A generated polynomial path from hover regime to horizontal flight with different path parameters sE . . . 31

4.2. One trajectory of the controlled system . . . 33

4.3. The rotor thrusts on this trajectory . . . 33

4.4. A sketch of an UAV, Image Courtesy of Flanders Make . . . 34

5.1. Function Structure for a Badminton Drone . . . 39

5.2. A simple algorithm to divide the volume of a sphere into points . . . 44

5.3. Four Promising Badminton Drone Layouts . . . 48

5.4. Simulation Results for Drone Layouts . . . 49

5.5. Optimal Thrust Distributions for Four Axes of a Quadrotor . . . 50

5.6. Setup to Find the Optimal Rotor Distance . . . 51

5.7. Impacts of Angled Rotors . . . 53

5.8. Impact of Distance Propeller to Center on the “Maximum Angular Acceleration in the Worst Direction” . . . 55

5.9. Good Rotor Configurations Regarding their “Maximimum Angular Acceleration in Worst Direction” . . . 56

5.10. Structure of Rotor Measurement Data . . . 57

5.11. Hitting Strategies . . . 59

5.12. Basic Problem Structure . . . 60

5.13. Basic Software Structure . . . 61

5.14. Evenly Random Placement of Rotors in an Octocopter . . . 63

5.15. Transformation from Absolute to Relative Angles . . . 65

5.16. Resulting Design Algorithm . . . 67

6.1. Modular Simulation Generation . . . 70

6.2. A Simulink Skeleton . . . 75

(12)

6.4. Loaded Nodes and Edges . . . 78

6.5. Hierarchy built from Nodes and Edges . . . 79

6.6. Nodes with Types Identified . . . 79

6.7. Final Decision Tree . . . 80

7.1. Project Schedule . . . 85

7.2. Drone Model with Wing Segments of Fixed Length, like Introduced by Flanders Make . . . 86

7.3. The Drone Model in SimScape . . . 87

7.4. The Logical Structure of the Drone Model . . . 88

7.5. Control Scheme of the Drone Model . . . 88

7.6. Visualisation of the Drone Simulation . . . 89

7.7. The SysML Representation of the Drone Design Space . . . 91

7.8. Some examples of invalid drones . . . 92

7.9. A Two-Parameter Bar Chart Demo . . . 95

7.10. A Two-Criteria Scatter Demo . . . 96

7.11. Comparing Peak-to-Peak Amplitudes for the States of the First Two Wing Segments 99 7.12. Comparing Peak-to-Peak and RMS values . . . 100

(13)

Listings

6.1. Internals of the SysML File . . . 77

6.2. Parts of the Subsystem Extractor in Coco/R . . . 82

6.3. The Exploration Results Generated by the Matlab Script . . . 83

7.1. Memory Management for SimScape Models . . . 89

7.2. Filter Definition for the UAV showcase . . . 92

7.4. Additions to the Model Execution Script Before Evaluation . . . 96

(14)

(15)

1. Introduction

I can’t understand why people are frightened of new ideas. I’m frightened of the old ones.

John Cage

Engineers try to satisfy users’ needs with technical means. For simple problems, an ad hoc solution can be sufficient, but usually deep insight into the problem and into solution principles is necessary to guarantee a succesful development. The goal of the research field of Engineering Design (for a full discussion see section 1.2 of [Pah+07], ) is to guide engineers’ work with meth-ods which ensure that the development process is efficient, fruitful and satisfies the requirements of the design problem.

Best practices in product development have been formalised into process models like Pahl and Beitz’ systematic design, allowing for a common approach. Figure 1.1 shows the top-level struc-ture of systematic design, and which phases have been investigated in this thesis. Altshuller illustrates in the first section of [Alt07] that inventing and developing ideas involves taking deci-sions on how to solve problems (e.g. whether to travel to a destination by train or plane) without sufficient insight into the impact (e.g. is a train accident or a plane crash more likely?). Or, using a more “technical” question from a design example used in this thesis: How should a drone, a flying robot, hit a badminton shuttle? Copy the sweeping motion of the racket with the drone’s flight? Or better imitate human players by installing a robotic arm? Are these solutions feasible? Which is the best realization regarding energy consumption, or hitting accuracy, or playing speed? An efficient development process (developing good solution possibilities instead of bad ones) re-quires decisions based on reliable sources to answer such questions long before enough information for a rational selection is available.

This thesis discusses how to model systems in the phase of conceptual design and implements two methods to retrieve information for concept selection from these models. The underlying structure is as follows:

• Chapter 2 sums up the terminology from conceptual design and method design used in the scope of this thesis and analyses existing methods, pointing out their advantages and drawbacks.

• Chapter 3 discusses available information of the system under consideration available during concept design and proposes a model for concept design to capture this information.

(16)

• Chapter 4 introduces two design problems that have served as test subjects for the ap-proaches proposed later in this thesis.

• Chapter 5 describes the development of a conceptual design for a badminton drone. The development process is then analysed for the methods and tools used.

• Chapter 6 develops a framework to enable the distributed treatment of design space mod-eling, component modeling and system evaluation.

• Chapter 7 solves a second design problem, the optimal configuration of flaps and actuators for a winged drone by means of the freshly developed framework.

• Chapter 8 both reflects and compares the two approaches, and gives an outline of possible extensions and research topics to proceed with.

(17)

2. Early Design Phases and Design

Methods

The tree is more than first a seed, then a stem, then a living trunk, and then dead timber. The tree is a slow, enduring force straining to win the sky.

Antoine de Saint-Exup´ery: The Wisdom of the Sands

Human history is full of discoveries and inventions, starting from the use of fire and tools. Hu-manity’s prosperity of today can be seen as a product of collaboration, hard work, and intelligent design, which is often referred to as the solution of problems by technical means.

In my belief, better tools supporting an engineer’s design ability will lead to better solutions.

The Design Problem

According to [Pah+07], ”designing is the optimisation of given objectives within partly conflicting constraints.”

The US Accreditation Board for Engineering (see page 3 of [CHW13] for the quote) defines design as ”The process of devising a system, component, or process to meet desired needs. It is a decision-making process (often iterative), in which the basic science, mathematics, and engineering sciences are applied to convert resources optimally to meet specified requirements. Among the fundamental elements of the design process are the establishment of objectives and criteria, synthesis, analysis, construction, testing and evaluation.”

Chris Paredis’ school ([Moo12]) defines design problems as optimisation tasks, searching for the solution with e.g. highest performance or lowest costs. As total exploration of the search space with limited resources and in finite time is usually impossible, Paredis et al. ([Moo12] p.3ff) aim to find a ”sufficiently good solution that can be achieved at reasonable design process costs”.

2.1. Design Approaches

There is no ’best’ way to solve problems. Several schools have proposed diverse ways of designing a product, each with their strengths and weaknesses, suitable for some, but not all kinds of, products.

1. Creative design

Altshuller dedicates the first section of [Alt07] to describe the ’standard’ way of inventing. Starting from the problem description, one tries to solve the problem by having good ideas and performing experiments. According to Altshuller it is the strategy with the highest

(18)

possibility that a novel solution is found, but also a strategy very likely to fail or at least waste ressources on implementing infeasible solutions.

2. Systematic design

Pahl and Beitz develop a systematic design approach in [Pah+07]. The method structures the design process in typical phases and supports the handling of huge projects while maintaining control of time and costs. Imposing this structure on a workflow will require some effort for planning, controlling, and project management.

3. Axiomatic design

Axiomatic design reduces the number of criteria for a good design to two axioms. The method was developed by Nam Pyo Suh. The main concept is to translate requirements into solutions in a way, that parts of the solutions influence other solution parts without loops (Independence Axiom). The second concept is to minimize the information content (Information Axiom). It requires experience to apply the abstract axioms and the defini-tion of informadefini-tion content, i.e. the “logarithmic probability of satisfying the funcdefini-tional requirements” ([Suh98]), to concrete problems.

4. Dialectic design

Developed by Genrich Altshuller in [Alt07], dialectic design solves the design problem by defining an (abstract) ideal solution and by iteratively resolving problems interfering with this ideal solution. The final step is the concretisation of the solved ideal solution. Altshuller formalised dialectic design into the TIPS (“theory of inventive problem solving”, original russian acronym: TRIZ) design method, comprising more than hundred tools to solve complex problems. It requires learning effort and experience to use the right tool in the right way for a specific problem. Important methods of this school were developed based on analysis of patents. Their scientific foundation and their effectiveness are not proven. Nevertheless, many innovations based on TRIZ are reported, even if it remains still unclear whether it is a new method or a mere accumulation of existing and working methods. [SD15]

The current thesis focuses on systematic design, which is topic of the next section.

2.2. Systematic Design

Systematic design, in the classic point of view, consists of several consecutive phases, which have to be executed again if the current solution fails certain requirements or in case of changing requirements. Each phase results in a system description with increasing level of detail as the phases progress. Each phase’s description serves as a starting point for the next phase. Pahl and Beitz use in section 4.2 of [Pah+07] the following structure of design activities, which is also depicted in figure 2.1:

1. Planning and task clarification

[Pah+07]: “The purpose of ... task clarification is to collect information about the require-ments ... and also about existing constraints and their importance. The activity results in the specification of information in the form of a requirements list ...”

2. Conceptual design

During conceptual design the essential problems are extracted from the requirements and are translated into a principle solution by means of suitable working principles.

(19)

2.2. Systematic Design

Figure 2.1.: Conceptual Design in the Scope of Systematic Design by Pahl and Beitz ([Pah+07])

3. Embodiment design

Embodiment design is the systematic translation of the principle solution into a feasible architecture or layout according to the technical and economic criteria.

4. Detailed design

During detailed design the specifications of all components get prepared for the further phases such as production, use, or recycling.

In this sequence, conceptual design is seen as the specification of the principle solution.

2.2.1. Conceptual Design

Starting from a problem description and a list of requirements, the main tasks during this phase, as identified by Pahl and Beitz, are shown in figure 2.1. They are explained as followed and illustrated with the example of a bottle filling plant:

1. Identify essential problems

By abstracting and reformulating the problem description, in the scope of the requirements, the goal of this task is to broaden the view on the problem. This relieves the problem description from unnecessary details and helps to identify the core of the task. It also detaches the engineers’ mindset from existing solutions and preconceptions, which frees them to find innovative solutions.

For a bottling plant, the fundamental problem is that liquid needs to be distributed from producers to consumers. Additional requirements regard hygiene or an equal distribution of liquid - no one wants to get less than the neighbour when buying a bottle for the same amount of money.

2. Establish function structures

In this step, functions are established that allow for a solution of the problem. Functions describe which atomic tasks are needed to solve the overall problem. Functions can be represented by combining a verb with a noun. Functions are devoted to flows of energy, information and mass (products, liquids, solids, gases, etc.).

Figure 2.2 shows a detail from a function structure of a bottling plant, where images are taken from the filled bottles to detect erroneous bottles.

• A sufficiently large amount of bottles needs to be stored, as not all bottles can be filled at the same time. The same applies to the liquid.

• Bottles and liquid flow to the filling function and result in a steady flow of filled bottles.

(20)

Figure 2.2.: Example of a Function Structure: Checking Bottles in a Filling Plant

• These bottles’ filling levels are then measured and the results are reported to a distri-bution.

• Whenever a bottle leaves the measurement, a clock signal is generated, together with the information if the bottles’ filling levels deviate too much from the valid level (“isJunk”).

• The bottles then are moved on to further packaging if they are filled correctly, or stored separatly, to serve as a refreshment for the workers. These further steps are not included in the function structure, as the example would grow too big for the page. (Or the zoom level would render it unreadable.)

• To model that function structures can be used to describe a system’s function with increasing level of detail, I zoomed in on “measure level”. At this level, the assumption, that image processing is used to determine the filling level, has a strong impact on the functions used and their link pattern.

3. Search for working principles and working structures

The identified functions are an abstract representation of the solution. Working principles are needed to realise them in physical systems. For a function or group of functions, several possibilities exist.

In the above example, bottles can be transported with a conveyor belt, a manipulating robot, or hover on an air cushion while being navigated by air streams, to mention only a few principles. The measurement of the filling level was assumed with image processing, but could also be carried out by e.g. determining the weight of the bottle.

4. Combine and firm up into concept variants

Promising working principles are arranged to solution concepts, and they are grouped to realisable systems, e.g. modules. By this, also an allocation of the functions to realisable systems takes place. Many possible allocations exist, resulting in a multitude of concept

(21)

Figure 2.3.: Example of an Allocation of Functions to Realisable Systems: Checking Bottles in a Filling Plant

variants for further investigation.

Figure 2.3 shows one possible implementation to realise the measurement of the filling level. Again, other realisable solutions will exist, each with its benefits and drawbacks.

5. Evaluate against technical and economic criteria

As not every solution concept can be developed to a product because of limitations of time and resources, the most promising concepts need to be identified. The most promising concept would be that with the highest potential to satisfy the requirements. In some cases, more than one solution is developed further, too, which may increase the insight into the problem. Still, the final decision needs to be taken at some point in the development process.

In the example case, the system using image processing was chosen, as it measures filling levels contact-free, which allows for high throughput. For transportation, the conveyor belt is a reliable and cheap solution.

The final result of the conceptual design phase is the principle solution or concept. Pahl and Beitz [Pah+07] point out the difficulty of validating and evaluating concepts at this level of detail. They also underline the necessity of transforming principle solutions into more concrete descriptions to be able to determine technical and economic properties important to stakeholders.

2.2.2. Embodiment Design

Embodiment design describes all the way from the principle solution to a concrete selection of components and their arrangement. Many tasks during this stage are split into smaller

(22)

assign-ments and transferred to specialists of different technical fields, e.g. mechanical design, power electronics or control engineering, employing their respective, very specialised competences, meth-ods and tools.

According to Pahl and Beitz, embodiment design comprises the following steps - the headlines are taken from Pahl and Beitz [Pah+07], and explained further in additional lines.

1. Identify embodiment-determining requirements.

The goal of this activity is to determine all requirements that have a huge impact on the embodiment design. Examples for such parameters are those measuring the system performance, any constraints on position and orientation of connectors or any environmental hazards like corrosive or explosive media.

2. Produce scale drawings of spatial constraints.

Gathering all spatial constraints helps to get an idea of the final sytems’s dimensions and results in a central document containing all geometric restrictions.

3. Identify embodiment-determining main function carriers.

When requirements are defined, it is possible to create a first layout containing the assem-blies and components fulfilling the main functions, the so-called main function carriers. 4. Develop preliminary layouts and form designs for the embodiment-determining main

func-tion carriers.

Preliminary layouts already contain rough implementations of the final components. This task can be seen as a first step of a series of product development with increasing level-of detail. As always in product development, now several layouts may seem promising. 5. Select suitable preliminary layouts.

The remaining concept variants are evaluated against the requirements. Based on the evaluation results, the most promising preliminary layout(s) are selected for further devel-opment.

6. Develop preliminary layouts and form designs for the remaining main function carriers. At this stage of development, the main layout and components are settled and the design team can start to define the remaining layouts and to form designs.

7. Search for solutions for auxiliary functions.

Auxiliary functions are not primarily needed to solve the problem, but improve performance on the longer run - examples might be supportive structures for maintenance and lubrication, cooling or enclosing critical parts from dirt.

8. Develop detailed layouts and form designs for the main function carriers ensuring compat-ibility with the auxiliary function carriers.

Now the forms, dimensions and materials for the main function carriers can be chosen in detail to exactly meet the requirements, spatial constraints and additional restrictions posed by the auxiliary functions.

9. Develop detailed layouts and form designs for the auxiliary function carriers and complete the overall layouts.

This development step defines the auxiliary function carriers in detail. At this point all design decisions for the main function carriers are taken, and the auxiliary function carriers may not interfere with those.

(23)

Figure 2.4.: 3D Assembly of a Conveyor Belt with Panels to Guide Bottles

10. Evaluate against technical and economic criteria.

After the development defined by the above steps is done, it is necessary to check the solution against the criteria formulated for the conceptual design, as the solution properties might have changed with the decisions taken during the design process.

11. Optimise and complete form designs.

If the evaluation discloses any weak spots in the design, the design or the requirements need to be altered until the design meets the requirements. In the worst case, the layout or even concept needs to be changed, requiring to step back and to iterate the design process. 12. Check for errors and disturbing factors.

The whole design is checked for errors in the functional and physical domain. The effects of disturbing factors are taken into account. After this check, the design is settled and should definitely meet the requirements.

13. Prepare preliminary parts list and production documents.

Pahl and Beitz [Pah+07] use the term “part list”, which is usually referred to as “bill of materials” (BOM). The design is documented with part lists and all models needed in the detailed design phase.

From the embodiment design phase, a very clear definition is resulting, which components to use in which place in order to realise the required functions. An example for such a result is the 3D assembly design of a conveyor belt which is given in figure 2.4. The end of embodiment design marks the point of no return regarding development costs, as the detailed design phase with construction and production planning is the most labour intensive, with only small margins to further influence the product costs. Still it remains difficult to determine the best layout of main function carriers, especially in coupled designs, regarding technical and economic criteria.

(24)

Although Pahl and Beitz give a comprehensive explanation what needs to be done to develop a definitive layout from the principle solution, they leave the transition from conceptual design to embodiment design open. In case of paper-based documentation this transition is realised by handing over a copy of the principle solution. If the design process is to be carried out with computer aid, models exist in the virtual domain. Transitioning these models to the next design phase requires a translation step between e.g. a conceptual design tool to an embodiment design tool, or the integration of both models into one tool.

2.3. Review of Recent Research

The previous sections clarified which tasks are necessary in early and mid product development. The next step was scanning ongoing and finished academic work by searching for and studying related papers. Those found most important are listed below. Their main ideas are explained and discussed.

• In [Seo+01], Seo et al. describe a design flow based on bond graphs and genetic pro-gramming. An initial graph is extended by adding or altering elements in fixed sequences. These sequences make up the genomes for the genetic program. The design method is applied to three problems of similar structure. First, optimizing the layout of resistors and capacitors to achieve certain eigenvalues for the resulting circuit. Second, laying out the components of an analog filter to optimize a fitness criterion. And third, optimize the step response of a mechanic oscillator. All of these examples allow automated analysis of system behaviours based on concentrated components with fixed parameters. The method was only applied to the design of simple systems. The spatial dimension is not considered at all. The bad readability of especially the mechanical models is a drawback of this method.

• Dohr develops in his thesis ([Doh14]) a design method which integrates simulations into the conceptual design and detailed design phases. Dohr addresses the selection of tools and the design of experiments, but still leaves the designer with all decisions on system architecture or design parameters.

• Kerzhner’s approach in [Ker12] implements a workflow to optimise architectures. The SysML language is used to describe the design problem and transforms it into a Mixed-I nteger Linear Program (MMixed-ILP), a subclass of optimisation problems, which contains only linear equations and linear inequalities. The decision to use MILPs allows for fast problem solving, but also limits the optimisation to systems that may be linearised with small errors and at little effort.

• Hoburg and Abbeel use geometric programming to optimise the design of an aircraft (see [HA14]). Like Kerzhner’s approach, this method still allows fast computation. Geometric programs take more time to solve than MILPs, but allow a wider range of mathematical tools to model the system (namely, polynomials). Hoburg and Abbeel do not specify a way how to retrieve the geometric program from a design problem.

(25)

2.4. Research Questions

• In [DS94], D’Albano and Suh sketch a framework for architecture generation and introduce a clear distinction between domain-specific modules for design and evaluation of subsystems and one domain-independent module containing the method to guide through the design process. The approach ensures that the generated architectures satisfy the indepence axiom and evaluates the information content. According to Suh’s axiomatic design theory, the indepence of functional requirements and the minimisation of information content guaran-tees the optimal architecture. Still, the approach relies on a database of previous solutions, limiting the quality of the generated solution to the experience provided to the system.

• From [FM14], two papers are of interest for the thesis. In chapter 1, Claudio Bonivento et al. present how simulations can be used to verify a system’s functions during the design phase. However, they do not offer tools to derive computational models from existing models, and their mathematical models are too detailed for conceptual design.

In chapter 17 of [FM14], Silva embeds a simulation run into optimisation using genetic algorithms by including simulation results to calculate fitness functions. The optimisation works on components with concentrated parameters using a predefined simulation model, but is not optimising architectures, hence it is only of limited use for conceptual design.

• Wyatt et al. ([Wya+12]) define a language which allows the specification of a problem through solution elements and constraints. A synthesis algorithm then creates possible architectures. The method delivers good results for small problems, but evaluation time grows exponentially with increasing number of components. Modeling the design problem requires experience with abstraction and UML-like languanges.

• Paredis et al. ([DPK99], [DPK98]) describe how to assemble system level simulations from component models which allow detailed evaluation of system behaviour at almost no addi-tional work for simulation building. Considering the huge amount of possible configurations evaluated during conceptual design, such detailed evaluation takes up too much time to deliver results. In addition, simulation models are not available during conceptual design for newly designed compents.

It can be concluded that many approaches exist to solve design problems automatically. Most of them lack tools to conveniently input a design problem into the method. SysML seems to be a good language to describe design problems (like in [Ker12]). Still, in [Ker12] the restriction to mixed-integer linear problems poses a strong restriction to problems that can be modeled, as the biggest part of nowadays’ products involves nonlinear characteristics.

Another weak point of the approaches discussed above is, that at the time of publication no transitions existed to translate the optimised results to be used in the embodiment design phase.

2.4. Research Questions

1. How can system architectures be compared to one against another without existing imple-mentations or detailed simulations of the system under consideration?

(26)

3. How can architectures and systems be modelled in a fast and readable way, for both engineers and the evaluating computer?

4. How do architectures need to be modelled in order to interconnect them with engineers’ tools?

5. How to enrich these models with detailed knowledge as development progresses? Can the models be used beyond conceptual design?

6. In which way is this framework used best to solve a design problem?

2.5. Steps supported and integrated by the developed

design method

The method designed in chapter 6 bundles support for the following activities from Pahl and Beitz’ systematic design. Again, headlines are taken from [Pah+07], with short explanations added.

1. Combine and firm up into concept variants.

The developed software tool allows to model all possible solutions (the design or solution space), based on the possibilities for each subsystem and then uses algorithms to explore the feasible combinations of those possibilities.

2. Evaluate against technical and economic criteria.

For the feasible combinations, the software creates simulation models and checks their response to certain test cases. The responses serve as the base for the technical evaluation. 3. Identify embodiment-determining requirements.

With the opportunity to test huge numbers of possible solutions, the evaluation results can be used to identify e.g. requirements that are always met.

4. Identify embodiment-determining main function carriers.

From the correlation between input parameters and evaluation results it is possible to identify input parameters with little input on the evaluation results, which can then be discarded from the list of main input parameters.

5. Develop preliminary layouts and form designs for the embodiment-determining main func-tion carriers.

The developed framework also allows to generate and test different architectures of sub-systems, which allows to evaluate the impact of chosen architectures.

6. Select suitable preliminary layouts.

With information on the different layouts available, the architecture can be selected. Still, the spatial constraints need to be satisfied manually.

With support for these steps, the developed method allows a quick selection of good principal solutions, optimized layouts and provides seamless transfer of information from concept design to embodiment design. But before stepping into the details of the newly developed method, an introduction on modeling during conceptual design will define terms and concepts used in the following chapters.

(27)

3. Modeling in Conceptual Design

The purpose of models is not to fit the data but to sharpen the questions.

Samuel Karlin

Modeling is a major task in any engineering discipline. It is a tool to focus on the relevant aspects of a problem.

In [SV03] Krzysztof Czarnecky defines (in the foreword) a model as an “abstraction of a system and its environment”, whereas Stahl himself ([SV03] p.18) sees a model as “an abstract rep-resentation of a system’s structure, function or behavior”. Evans ([Eva03]) describes a model as a “system of abstractions that describes selected aspects of a domain that can be used to solve problems related to that domain”, with a domain being “a sphere of knowledge, influence or activity”. Stachowiak ([Sta73] p.129) defines a model as a representation of an original. Ac-cording to Stachowiak (the translation was taken from [mod12]) a model comprises three main properties:

• Mapping

Models are always models of something, more precisely mappings from or representations of natural or artificial originals. The originals can be models themselves.

• Reduction

Models in general do not capture all properties of the original represented by them, but rather only those seeming relevant to their model creators and/ or model users.

• Pragmatism

Models are not uniquely assigned to their originals per se. They fulfill their replacement function

– for a particular subject

– within particular time intervals

– restricted to particular mental or actual operations.

These definitions seem to me broad and not very applicable when developing a design method. Vajna et al. [Vaj+09] give an elaborated definition of models used in computer aided methods, and the components of such models. According to [Vaj+09] models are “abstract, material or immaterial constructs (e.g. visualisations, prototypes, technical drawings, circuit diagrams, as well as mental models, imaginations, pictures, etc.), which are created through modeling, to represent an original for a particular purpose. Models can be seen as simplified mappings or replications of originals.”

For this thesis, the main interest lies on models of technical systems. Ehrlenspiel uses the following definition of a system in [EM13]: “A system is a set of elements (subsystems), which are characterised by properties and linked through relations. A system is separated by a system

(28)

border from its surroundings and relates to its surroundings through in- and outputs. ... A system’s function can be described by the part of transformations from inputs to outputs which corresponds with the system’s purpose.” (This definition is also used by [Vaj+09].) The following sections will have a closer look on the nature and use of models during the conceptual design stage.

Referring to the dimensions proposed by Stachowiak [mod12] (Mapping, Reduction, Pragmatism), the following can be stated:

• In conceptual design, the original usually is not built yet, it is only an idea.

• The amount of information available during conceptual design is low compared to detailed design, and its nature is rough and diffuse. Hence, the models give a very reduced view on key properties. Possible modeling errors have to be kept in mind when making decisions. • The purpose of models in conceptual design is to evaluate solution principles for their

viability and performance limits, and later to identify the advantages and drawbacks as well as the tradeoffs in certain designs.

A modeler has to balance a model’s level of detail between two poles. On the one hand, it has to be detailed enough to take into account all important properties of the system under consideration to be able to derive significant answers and predictions. On the other hand, increasing complexity decreases the model’s usability - computation times increase, mathematical solving becomes more complicated and it is harder to identify the key parameters (for performance or costs) and their dependencies.

3.1. Definition of Systems and System Descriptions

Systems play an important role to describe models of technical objects. Vajna [Vaj+09] and Ehrlenspiel [EM13] use the following definition: “A system consists of a set of elements (sub-systems), which own properties, and which are linked through relations. A system is separated from its sourroundings by a system border, and is in relation with its surroundings by inputs and outputs. The function of a system can be described by the (desired) transformation from inputs to outputs. Subsystems can be systems themselves again, consisting of elements and relations. Nam P. Suh et al [FS16] model systems from two viewpoints, which describe two very different system natures. Both are hierarchical, ergo cover coarser and more abstract levels, as well as they branch out (possibly even over multiple levels) to a fine-grained description.

• Functional Description

The main question is: “Which functions are able to perform the system’s tasks?” The main elements of a functional description are called “Functional Requirements” (short FR). FRs represent what is necessary to enable the designed system to perform its tasks. Starting from the usually very rough requirements from stakeholders (e.g. the customer wants “the system to be able to play badminton”, or a safety agency requires, that “the drone lands immediately when it leaves the playing area”) the relevant criteria for designing the system (“The system is able to hit a badminton shuttle”, “The system moves automously”, “The system reaches each point in a badminton field in 1s” etc.) are derived. This refinement process is continued up to the point where it is clear to the designer which components are needed to design the system. Part of the refinement process is also to determine, if and

(29)

3.2. Properties, State Variables and Parameters

how FRs can be quantified, in order to compare different components’ abilities to satisfy such FRs.

The resulting functional description or functional decomposition is the first result in the solution process of a design problem. Satisfying FRs at the detailed levels is crucial to fulfil the designed system’s overall function, but not sufficient: The overall function is also dependent on the concrete realisation of functions and the relations between these realisations.

• Structural Description

The counterpart to the functional description is representing the structure of the product’s physical implementation. In conceptual design, the structural description is mostly built top-down by asking “How is my product built?” or “What does it consist of?”. This does not imply, that posing the opposite question, “What can I build from a set of components?”, does not lead to structural descriptions. Here, important elements are “Design Parameters” (short DP). DPs represent the properties that can be directly accessed and chosen. The biggest impact arises from the selection of working principles, as each principle introduces its own set of properties, like geometric dimensions, electric resistance, or density and viscosity of a fluid. Each selection on the DP side can have an influence on the overall system’s capability to satisfy one/several/many FRs.

Suh et al. [FS16] capture the relations between DPs and FRs with a matrix of zeroes and ones ~F R = M · ~DP . To perform deeper analysis, Scheidl [SD15] prefers to use a nonlinear function ~F R = ~f ( ~DP ) to express the influence of the numeric representation of concrete choices for DPs on the numeric representations of the FRs. In both versions, DPs act as inputs, FRs as outputs.

A product designer is highly interested in how the mapping from DPs to FRs looks like, as it allows to check whether the current design fulfills the requirements. Even if this analysis problem can involve heavy computation, it is more or less straightforward. The inverse problem, the synthesis of a working (or even optimal) system would mean to invert this mapping, or mathematically: solving a huge set of usually nonlinear, partial differential equations, which is generally a task impossible to solve at once. To avoid searching for a good design only by trial and error, experience and design methodologies may be of great help.

Even with experience in the problem domain, and knowledge how to guide design processes, the search for good and optimal solutions requires time and manpower. Software support for modeling and evaluating larger sets of solutions has the ability to increase the development speed.

3.2. Properties, State Variables and Parameters

Another important view of a system was already mentioned in the definition of a system: “A sys-tem consists of elements, which own properties...” ([Vaj+09]). A syssys-tem is characterised by its properties. For mechatronic systems, properties of interest may range from dimensions (length, diameter, etc.), materials and their properties (density, conductivity, resistance to environmental hazards etc.), time-varying properties (temperature, currents, stored information, etc.) to prop-erties describing the system’s function, structure and behaviour (also see Hubka [Hub84]). The relations between properties are of key interest to engineers, as a main intent in product development is the modification of some properties in order to realise a desired change in proper-ties. As engineers make heavy use of calculations to evaluate systems and their properties, there

(30)

Figure 3.1.: Development of a Computational Model According to Duffy and Andreassen [DA95]

is a strong need to quantify properties. For the quantification of most physical properties, like length, electric conductivity, pressure, temperature, mass etc. physical units and measurement principles exist, which makes physical properties easy to measure and evaluate [Vaj+09]. Alas, there exists a wide range of qualitative properties like ergonomics, aesthetic appeal, usability, reliability or safety, which cannot be omitted in a system’s evaluation, but are hard to “measure” and quantify [Hub84].

Another important defintion used in the analysis of systems is the system’s state: According to Hubka [Hub84], the state of a system at a given point in time, is the set of quantifications of the system’s properties at this point in time. The transition between states can happen in discrete steps or gradually. Fulfilling certain properties (e.g. safety, stability, controllability, etc.) may impose constraints on states, and as well on values derived from states and their development over time.

3.3. Modelling Languages

During the development stages sketched by Pahl and Beitz [Pah+07], models play a central role to exchange and express ideas and information. Vajna et al. [Vaj+09] outline which classes of models exist in the development of a computational model, which is necessary for numeric evaluation. The original schematic has been taken from [DA95] and was redrawn in figure 3.1. The model languages that were used in this thesis are mentioned below and arranged according to Vajna et al.’s model classes.

• Phenomena models – Verbal descriptions

(31)

3.3. Modelling Languages

– Sketches • Information models

– Mathematical models – Transfer functions

– Domain specific languages for information exchange, e.g. SysML • Computer models and tools

– Source code – Executable code

– Domain specific languages with execution environment, e.g. Matlab/Simulink

3.3.1. About SysML

SysML is a modelling language which was developed to support the development of complex systems. According to its designers (see [FMS15]: it also contains a good overview of the modeling capabilities of SysML) it aims to serve for system engineers as does the UML (Unified Modeling Language) serve for software engineers, which is also expressed by the close relation between these two languages - SysML was developed on the foundation of UML version 2. SysML was designed to be able to capture every aspect of a system. To do so, it features a series of diagram types which allow to model different aspects of technical systems. The diagram types are:

• The package diagram type is used to create an overview of large projects by grouping diagrams belonging to one e.g. project team, business area, or subsystem etc.

• A requirement diagram links requirements to a system, and expresses how they are trans-lated from the overall system to component levels.

• Activity, sequence, state machine and use case diagrams serve to describe the behaviour of systems and subsystems.

• The block definition diagrams specify which block types [similar to classes in object-oriented programming (OOP)] are used in the project. Internal block diagrams detail, what certain blocks (comparable to class instances in OOP) consist of. Examples of block definition diagrams are given in figures 3.3 and 3.4 using two different open source SysML modeling suites.

• Finally, the parametric diagram allows to capture parametric constraints and relations be-tween blocks, as well as bebe-tween their properties.

Many UML modeling tools offer support for SysML, amongst them the open source Modelio and Papyrus software suites. As a benchmark to test the two suites, a portal or gantry robot, which is commonly used in pick-and-place applications, was modelled. The system sketched in figure 3.2 consists of a moveable structure B, the tool support, which is mounted on a moveable beam A, the portal or gantry. For the benchmark it was assumed, that A and B can be actuated by either a small, medium or big drive with different masses and maximum powers.

(32)

Figure 3.2.: Sketch of a Portal Robot

Modelio

Modelio [Mod17] is a modeler for UML with plugin support for SysML. It is developed by Mod-eliosoft in France. Modelio itself is free and open source, but documentation is scarce. Mode-liosoft’s business model is to offer training and consulting services.

After studying the available documentation for about a week, it was possible to parse SysML diagrams with a Java environment. The extension mechanisms are documented well enough to develop new functionalities. Testing and debugging gets painful soon, as Modelio uses its own runtime. This means, that plugins need to be compiled in Java, loaded into the Modelio runtime and executed there. This results in cumbersome testing (which has to be executed often during software development). Moreover, support for debugging is limited, as the only way to check variable values during execution is in log files and prompts.

The representation of the gantry robot is given in figure 3.3. In the top line, the portal robot is modeled as a SysML block (the small square in the top right corner), and in addition, as a “design problem” (the letters DP next to the square). The stereotype (the little icons represent existing SysML datatypes, or extensions created by me using stereotypes) of a design problem was introduced, to distinct the block containing the overall evaluation description from the remaining systems. The “portal robot” contains two properties subject to optimisation. Both the measured overshoot when moving the gantry following a step trajectory, as well as the energy necessary to run the trajectory, should be kept as small as possible. This was captured by the stereotype “min” in the diagram.

The four lines with the black diamonds indicate, that a portal robot consists of four subsystems: two rigid bodies for the movable arms and two drives. The meaning of the 1’s (called multiplici-ties or cardinalimultiplici-ties) on both ends of these lines is that one portal robot owns e.g. one drive for axis 1 and the drive of axis 1 belongs to one portal robot. The meaning of the lines with the empty triangles is, that both the drives of axis one and two are of the type “Drive” with the properties that are stored there. The bottom line contains three possible realisations of “Drive”, a small, medium and big drive with concrete and distinct values for each of their properties. This is captured by the bullet list icon in the top right corner, linked to a “Selection” stereotype. Note that any system containing simulation code (Body and Drive) are marked with the type of simulation tool. In the example, “S” was used for Simulink.

Properties not depending on the drive selection, like the movement damping due to friction in bearings, and the transmission ratios from rotational to linear movement for each axis, were stored in the top level block.

Papyrus

Papyrus [Fou17] is part of the Eclipse runtime environment. It is driven by the Papyrus Interna-tional Consortium and Polarsys, the industrial working group of Eclipse.

(33)

3.3. Modelling Languages

(34)

Figure 3.4.: The Portal Robot in Papyrus

The documentation can be considered worse than Modelio’s in the way that Papyrus reuses al-ready existing software available in the Eclipse framework, most important the Eclipse Modeling Framework. Because of this, only the modeling capabilities are part of Papyrus’ documentation. The knowledge on extracting data from the models has to be extracted from the documentation on EMF and Ecore, and the information on building custom functionality for the Eclipse runtime has to be taken from the Eclipse platform documentation.

The representation of the gantry robot in Papyrus SysML is given in figure 3.4. One can see that the differences are mostly graphical, because the SysML language itself is standardized. The model rendering is similar to UML, where blocks are replaced by classes. Hence, the compart-ments “properties” and “operations” are always displayed, as they exist on practically every class. The tight integration with the Eclipse Modeling Framework (EMF) also comes with advantages, namely access to SysML diagrams with all applied stereotypes in a class structure that can be pregenerated and used throughout coding. This allowed to introduce a stereotype on generalisa-tions (“Implementation of”) to make modeling of selecgeneralisa-tions more natural.

Nevertheless, after two weeks of searching I was able to parse Papyrus diagrams. At this point the Papyrus environment shows its strengths, as the integration with the Eclipse development environment allows a wide range of debugging options, most important, the opportunity to in-terrupt program execution at any time with breakpoints. Then, every variable at these specified points can be accessed.

Overall, the bulkier representation and the additional time spent on learning how to access the models in Papyrus diminish next to the pay off of extensive debug tools when it comes to the development of a serious application.

(35)

3.4. The Design Space

Figure 3.5.: Feasible and Infeasible Solutions in the Design Space

3.4. The Design Space

The design or solution space of a design problem is the manifold of possible solutions [SD15]. It is spanned by the decisions that are to be taken, be it choices from binary, discrete or continuous sets.

Product development can be seen as a journey through the design space [SD15] like it is visualised in figure 3.5. On this journey, one searches feasible, good and optimal solutions. Every triangle indicates one solution encountered in this process. Each physical restriction detected and each decision that is taken during this process cuts away an area of the overall space, until, at the end of development, a set of feasible solutions is found. From this subset (drawn in white) one or more single points, the solution(s) with highest probability to optimally satisfy the requirements is/are chosen as starting point(s) for the detailed design phase. Besides grouping design decisions by their domain (binary, discrete, continuous), also a more practical approach to structure by the nature of decisions can be followed:

• Select the realisation of a (sub-)system.

The realisation of a (sub-)system has several effects on the functionality of the product: – Chosing the realisation defines the main physical interactions with the other system

parts.

– It defines which and how many components are needed. – The interfaces into, within and out of the system are settled.

Of course, the realisation also has huge influence on planning, costs, production and as-sembling complexity of the system.

• Select the multiplicity of subsystems.

As most systems show nonlinear behavior it will have an impact whether e.g. one bigger system or two smaller systems are chosen to realise a certain functionality. [Zem15] gives a

(36)

good overview how mechanical properties change with the scaling of a system, e.g. inertial moments grow with the power of five, whereas volume forces (for example magnetic forces in an electric drive) only grow with a power of three. From this it can be estimated, that a bigger drive will react slower than two drives with half the power each.

• Define the connectivity of subsystems.

If a function is realised by a bigger number of subsystems, the pattern of their connections has an impact on their behavior. A simple example is a network of electric resistors: operating them in parallel will decrease the overal resistance, connecting them in series increases it.

For a system built from the interconnection of more complex systems, the behavior can create new functionalities (e.g. swarm intelligence of robots [Via+10]) or can cause even chaotic behavior (e.g. an inverted pendulum with more than two joints [AKW07]).

• Select properties of a (sub-)system.

Of course, any physical property that can be selected in type and quantification will have an influence on the behavior.

3.5. Possibilities to Model Design Spaces

To get an overview of recent research in the field of design space modeling, a literature research was conducted. It is possible to identify two major directions of research.

1. The first field focusses on design methods for a technological field which are well-understood and clearly defined. Here the modeling of design spaces is more or less omitted by replacing it by a small catalogue of functional blocks and a behavioral description. The functional blocks are selected in a way to guarantee that they are capable of realising every desired behavior. The functional description is then modeled for example in Ptolemy [like in the PeaCE project in [Ha04], where FPGAs (field programmable gate array) are synthesized from the behavioral description], or in SystemC ([Hau+08]), which allows the generation of chips based on FPGAs, too.

2. The second field deals with generic representations of the design space. [NC93], [RM04] and [CMR90] represent the design space as an n-tuple of decisions. The size of n needs to be decided, as well as the contents of the tuple. Selecting continuous variables can be an element of a tuple, as well as picking from a discrete set of values, implementations or functions.

At the institute for software integrated systems (ISIS) at Vanderbilt university, a generic modeling environment (named “GME”) was developed (see [Led+01] for an overview) which is a tool support for graphical modeling intended to support any design method by giving a toolset to specify the grammar and object set for this method.

A grammar is the set of rules that defines a valid model (e.g. properties have to belong to a system). The object set contains all possible values that can be used in a model. Possible values can either be listed (e.g. in a given project, valid dimensions for a screw might be M8, M10 and M12), or declared by sets and constraints (e.g. all screw dimensions d should be integers with d = 2 ∗ n, n > 3, n < 7, n also from the set of integers).

[Nee+03] apply GME to build an automotive controller. For small design projects, like those developed in the scope of this thesis, this framework is of little use because its approach

(37)

3.6. Modeling the Design Space in SysML

is too complex. Moreover, I could not find a way to access the information stored in the models to use it with handcrafted algorithms.

Although SysML was not designed to model design spaces in the first place, it makes a good starting point for doing so. Being a language to describe technical systems gives it a look and feel that eases modeling. Tools with both open source software and open access to stored models’ contents are available. The next section details how SysML can be used to model design spaces and which additions to the meta-model are necessary.

3.6. Modeling the Design Space in SysML

The existing language elements of SysML make it easy to model a clearly defined system [GP06][MMP08][VD15], where all decisions on architectures and realisations of functions have already been taken. Yet, functions can be realised with different (combinations of) working prin-ciples, which I found impossible to express with the existing SysML language elements.

To use SysML to model design spaces, I invented a new way to interpret certain language ele-ments. Together with the introduction of two small elements this allowed a very straightforward way of modeling design spaces, using internal block diagrams. The first is a specialisation of the native SysML block which adds information on its implementation. The second is an additional type of relations which I called “Implementation”. In fact, section 3.3 and section 3.4 already use these extensions. The following bullet points give a closer explanation of the usage of SysML and the extensions added (“Implementation” blocks and the relation “ImplementationOf”).

• Block

Blocks are used to model systems, parts of systems, classes of systems and implementations of classes. In each design space model, one block contains information about the overall system and the optimisation problem. It is defined by not having parent nodes and is referred to as the root (block).

• Implementation Block: Extension of Block

Adds information about the realisation of a block. The term “implementation” was chosen to be consistent with the object oriented paradigm from software development. The infor-mation on the block’s implementation can be stored also outside SysML. Any block can additionally be an implementation block. To allow the system represented by the root block to be evaluated, an evaluation model needs to be provided, e.g. by a link to a Simulink model.

• Property

Properties are used in the root block to model the optimisation criteria. In all other blocks, properties are used to declare properties of the (sub)system.

• Constraint

An equality constraint fixes properties of its owning block. All properties not fixed are avail-able as variavail-able properties for the optimisation algorithms. Pairs of inequality constraints on a property represent an interval of possible values for this property.

• Directed Composition

Directed compositions hierarchically refine the structure of a block. Any block can consist of subsystems attached to it through compositions. Compositions may have cardinalities

(38)

of 1 or x..y with x and y being natural numbers.

If there is a range on the cardinality of a system, then the respective subsystems may exist or may not. To be able to take care of this in practical applications, it needs to be defined how such “non-existent” systems affect the overall system. One way to deal with this issue is to introduce an inert “null” or “dummy” system.

• Generalization

Generalizations express, that certain (less general) blocks share properties. To reduce modeling effort, and to increase the readability of models, these shared properties are stored in a (more general) block. The more specific blocks are related to the general block by generalizations.

When, during the model creation, several subsystems of the overall system arise to be identic, their information can (and should) be extracted into a block, like in object-oriented programming, where classes inherit common information from a super class.

• Implementation Of: Extension of Generalization

For discrete choices of realizations (e.g. choosing working principles or build sizes), the respective blocks are linked via an “ImplementationOf” relation to the realised block. In case of working principles, the realising blocks must provide their own evaluation models, hence, have to be “Implementation” blocks. If the realisations only differ by their property values (like in different build sizes), it is sufficient if one block provides the evaluation model.

It is not compulsory to use SysML to model the design space, but it sure helps to structure bigger problems and makes the information readable to software. The advantages of such models get clear in chapters 6 and 7.

(39)

4. Introduction of the Benchmark

Problems

Man must rise above the Earth, to the top of the atmosphere and beyond, for only thus will he fully understand the world in which he lives.

Socrates

When designing a method for product development it is part of the process to test it at least against one reference project [BC09]. In this thesis two projects dealing with drone design were used. They are introduced in this chapter to separate between project-specific and the approach-specific topics which are subject of the next chapters.

The first problem was to investigate the question of the feasibility of a flying badminton-playing robot. The development of a working conceptual design was chosen to prove the feasibility, and this is discussed in chapter 5. The development was carried out following Pahl and Beitz’ system-atic design approach [Pah+07]. In the reflection of this development task, tools were proposed to support the conceptual design process. These were developed in chapter 6.

The second problem targeted the optimisation of a winged drone’s layout to reduce vibrations. Modeling and evaluations were carried out with a new tool developed in chapter 6. The devel-opment of the design project using this framework is then discussed in chapter 7.

4.1. The Badminton Drone

The question sounds simple: ”Is it possible to have an airborne drone (also: unmanned aerial system, UAS) play badminton for at least 15 minutes?”. To answer this question with a solid argumentation based on physical and technical evaluations is a bigger project. The basic modeling of a quadcopter and similar systems with more rotors will be discussed here. How this model was used to answer the question is discussed in chapter 5.

4.1.1. Badminton Sport

Badminton is a highly dynamic sport. Andrei Bartic from Flanders Make gathered in [Bar09] a very comprehensive compilation of facts and numbers on this sport. In order to let a robot play this game, high accelerations (3g and more, see section 4.1.4 on how this requirement was calculated) as well as high hitting speeds (some 30m

s) are necessary. Beside the design of the

actual robot, the challenging tasks also involve disciplines like computational perception to detect the shuttle (in case of a smash, a reaction is needed in as little as 0.2s), optimal path planning to intercept the shuttle at the right time with right speed and position and finally a control problem, to stabilize the robot along this trajectory and during hitting the shuttle.

(40)

At Flanders Make, a vision system to detect shuttles was already available from earlier projects on badminton, so the work of this thesis focusses on the development of an UAS able to hit a shuttle. Based on earlier experiences of my supervisor Bruno Depraetere I focused on quadcopters (or quadrotors, which is used also used in literature) and their brethren with higher number of rotors, as they allow for high accelerations and agile turns.

It has to be pointed out, that for the different functions numerous working principles exist -highly agile quad-copter platforms, multi-rotor arrays, rotors with variable blade pitch, tiltable rotors, multi-copters with multiple rotor dimensions, or rotors with adjustable propulsion angles and maximum thrust. The big question now arises as how to find the optimal (or at least a very satisfying) solution combined from these solution elements without having to prototype each and every robot manually.

4.1.2. Requirements to a Badminton Drone

Some important facts for a badminton game, taken from [Bar09] are listed below:

• The playing area for the robot is 7.6m long and 6.1m wide.

• In the fastest shot in badminton, the smash, the badminton shuttle travels at an average speed of 30m_s and is targetted to hit the ground close after the net. In a smash, the shuttle hits the floor after 0.2s.

• The shuttle needs to be accelerated to 40m/s to pass the net.

• The shuttle weighs less than 10g.

• On average, a badminton player hits the shuttle every two seconds.

• Thus, the maximum allowed reaction time for gameplay without smashes is 1sec. Reaction time is measured between detecting the shuttle and hitting the shuttle.

Some more requirements arose for a robot playing badminton. • The robot should not be bigger than 1m in any direction.

• The robot should not leave the playing are - too far.

This information cannot be used directly to design a drone. The following requirements are of greater use:

• Linear and angular accelerations

• Acceleration forces and torques

• The necessary hitting forces

To gain better insight into quadcopters and to refine above requirements into evaluatable criteria, a model of a simple quadcopter was set up and simulated along a three dimensional path. How I came up with such a model is explained in the next sections.

Development of a Design Method for Conceptual Design with Application on the Design of a Drone / eingereicht von Michael Mayrhofer

Development of

a Design Method

for Conceptual Design

with Application on

the Design of a Drone

Masterarbeit

Diplom-Ingenieur

Abstract

Foreword

Sworn Declaration

Eidesstattliche Erkl¨

arung

Contents

List of Figures

Listings

1. Introduction

2. Early Design Phases and Design

Methods

The Design Problem

2.1. Design Approaches

2.2. Systematic Design

2.2.1. Conceptual Design

2.2.2. Embodiment Design

2.3. Review of Recent Research

2.4. Research Questions

2.5. Steps supported and integrated by the developed

design method

3. Modeling in Conceptual Design

3.1. Definition of Systems and System Descriptions

3.2. Properties, State Variables and Parameters

3.3. Modelling Languages

3.3.1. About SysML

3.4. The Design Space

3.5. Possibilities to Model Design Spaces

3.6. Modeling the Design Space in SysML

4. Introduction of the Benchmark

Problems

4.1. The Badminton Drone

4.1.1. Badminton Sport

4.1.2. Requirements to a Badminton Drone