IFAC Professional Brief Modelling Of Physical Systems . - Van Amerongen
Annual Reviews in Control 27 (2003) 87–117IFAC Professional BriefModelling of physical systems for the design andcontrol of mechatronic systemsJob van Amerongen , Peter BreedveldControl Engineering, Drebbel Institute for Mechatronics and Faculty of Electrical Engineering, University of Twente,P.O. Box 217, 7500 AE Enschede, The NetherlandsAbstractMechatronic design requires that a mechanical system and its control system be designed as an integrated system. This contribution coversthe background and tools for modelling and simulation of physical systems and their controllers, with parameters that are directly related tothe real-world system. The theory will be illustrated with examples of typical mechatronic systems such as servo systems and a mobile robot.Hands-on experience is realised by means of exercises with the 20-sim software package (a demo version is freely available on the Internet).In mechatronics, where a controlled system has to be designed as a whole, it is advantageous that model structure and parameters aredirectly related to physical components. In addition, it is desired that (sub-)models be reusable. Common block-diagram- or equation-basedsimulation packages hardly support these features. The energy-based approach towards modelling of physical systems allows the constructionof reusable and easily extendible models. This contribution starts with an overview of mechatronic design problems and the various ways tosolve such problems. A few examples will be discussed that show the use of such a tool in various stages of the design. The examples include atypical mechatronic system with a flexible transmission and a mobile robot. The energy-based approach towards modelling is treated in somedetail. This will give the reader sufficient insight in order to exercise it with the aid of modelling and simulation software (20-sim). Such a toolallows high level input of models in the form of iconic diagrams, equations, block diagrams or bond graphs and supports efficient symbolicand numerical analysis as well as simulation and visualisation. Components in various physical domains (e.g. mechanical or electrical) caneasily be selected from a library and combined into a process that can be controlled by block-diagram-based (digital) controllers.This contribution is based on object-oriented modelling: each object is determined by constitutive relations at the one hand and its interface,the power and signal ports to and from the outside world, at the other hand. Other realizations of an object may contain different or moredetailed descriptions, but as long as the interface (number and type of ports) is identical, they can be exchanged in a straightforward manner.This allows top–down modelling as well as bottom–up modelling. Straightforward interconnection of (empty) submodels supports the actualdecision process of modelling, not just model input and output manipulation. Empty submodel types may be filled with specific descriptionswith various degrees of complexity (models can be polymorphic) to support evolutionary and iterative modelling and design approaches.Additionally, submodels may be constructed from other submodels in hierarchical structures.An introduction to the design of controllers based on these models is also given. Modelling and controller design as well as the use of 20-simmay be exercised in hands-on experience assignments, available at the Internet (http://www.ce.utwente.nl/IFACBrief/). A demonstration copyof 20-sim that allows the reader to use the ideas presented in this contribution may be downloaded from the Internet (http://www.20sim.com). 2003 Elsevier Ltd. All rights reserved.Keywords: Mechatronics; Physical systems; Design and control; Modelling and simulation; Bond graphs; Energy-based modelling1. IntroductionMechatronic design deals with the integrated design of amechanical system and its embedded control system. Thisdefinition implies that it is important, as far as possible, thatthe system be designed as a whole. This requires a systems Corresponding author. Tel.: 31-53-4895791; fax: 31-53-4892223.E-mail addresses: J.vanAmerongen@utwente.nl (J. van Amerongen),P.C.Breedveld@utwente.nl (P. Breedveld).1367-5788/ – see front matter 2003 Elsevier Ltd. All rights reserved.doi:10.1016/S1367-5788(03)00010-5approach to the design problem. Because in mechatronics thescope is limited to controlled mechanical systems, it will bepossible to come up with more or less standard solutions. Animportant aspect of mechatronic systems is that the synergyrealised by a clever combination of a mechanical systemand its embedded control system leads to superior solutionsand performances that could not be obtained by solutions inone domain. Because the embedded control system is oftenrealised in software, the final system will be flexible withrespect to the ability to be adjusted for varying tasks.
88J. van Amerongen, P. Breedveld / Annual Reviews in Control 27 (2003) 87–117The interdisciplinary field of mechatronics requires toolsthat enable the simultaneous design of the different parts ofthe system. The most important disciplines playing a role inmechatronics are mechanical engineering, electrical engineering and software engineering. One of the ideas behindmechatronics is that functionality can be achieved eitherby solutions in the (physical) mechanical domain, or byinformation processing in electronics or software. This implies that models for mechatronic systems should be closelyrelated to the physical components in the system. It also requires software that supports such an approach. In an earlystage of the design, simple models are required to makesome major design decisions. In a later stage (parts of the),models can be more detailed to investigate certain phenomena more in depth. The relation to physical parameters likeinertia, compliance and friction is important in all stages ofthe design. Because specialists from various disciplines areinvolved in mechatronic design, it would be advantageous ifeach specialist would be able to see the performance of thesystem in his or her own domain. It should be possible tosee the performance of the mechatronic system in multipleviews. Typical views that are important in this respect are: Physical models Bond graphs Control engineering models Block diagrams Bode plots Nyquist plots State space description Time domain Animation C-code of the controllerOften modelling, simulation and identification is done forsystems that already exist. The design of a controller has tobe done for an already realised and given ‘process’. Whenwe talk about design the system does not yet exist, there maybe a lot unknown in the beginning, but there is also muchmore freedom to modify the system, not only the controller,but also the ‘process’, the mechanical construction itself.In a typical design, the following phases can be distinguished. This is an iterative process and it may be necessaryto go back to an earlier phase when problems arise in a laterphase of the design process:Phase 1: A concept is made of the system that has to beconstructed and taking into account the tasks that haveto be performed, the major components and their dominant dynamic behaviour are identified and modelled.Phase 2: Controller concepts can be evaluated on thissimple model. This requires that the model be available,e.g. as a transfer function, or a state space description.Phase 3: When the evaluation is successful, the differentcomponents in the system can be selected and a moredetailed model can be made. The controller designedin phase 2 can be evaluated with the more detailedmodel and controller and component selection can bechanged.Phase 4: When phase 3 has been successfully completedthe mechanical system can be built and the controllercan be realised electronically or in software. It is tobe preferred that the translation from the controllertested in simulations is automatically transferred to, e.g.C-code, without manually coding; not only because ofefficiency reasons, but especially to prevent coding errors.This professional brief will address these issues. In thefirst part some representative examples of mechatronic design problems will be treated, showing how modelling andcontroller design are closely interacting during the designprocess of a mechatronic system. This part is written fromthe perspective of a control engineer. These cases will makeclear that physical models are essential when besides the design of a controller also design of the mechanical part of thesystem is being considered. In the second part, port-basedmodelling of physical systems is introduced.Physical system modelling provides insight, not only inthe behaviour of systems that an engineer working on multidisciplinary problems wishes to design, build, troubleshootor modify, but also in the behaviour of the environment ofthat system. A key aspect of the physical world around usis that ‘nature does not know domains’. In other words, allboundaries between disciplines are man-made, but highlyinfluence the way humans interact with their environment.A key point each modeller should be aware of is that anyproperty of a model that is a result of the modeller’s choice,should not affect the results of the model. Examples ofmodeller’s choices are: CoordinatesMetricDomain boundariesSystem boundariesRelevance of time and space scalesSeveral attempts to unified or systematic approaches ofmodelling have been launched in the past. In the upcomingera of the large-scale application of the steam-engine, the optimization of this multi-domain device (thermal, pneumatic,mechanical translation, mechanical rotation, etc.) created theneed for the first attempt to a systems approach. This needfor such a ‘mechathermics’ approach was then named thermodynamics. Although many will not recognise the currenttreatment of thermodynamics as the first systems theory, itcertainly was aimed originally in trying to describe the behaviour of such a system independently of the involved domains. However, it required a paradigm shift or ‘scientificrevolution’ in the sense of Kuhn (1962) due to the fact thatthe concept of entropy had to be introduced for reasons ofconsistency, i.e. to be able to properly ‘glue’ these domainstogether with the concept of a conserved quantity called energy. The rather abstract nature of the concept of entropy
J. van Amerongen, P. Breedveld / Annual Reviews in Control 27 (2003) 87–117has caused that students have considered thermodynamicsa difficult subject ever since, resulting in only a relativelylimited number of engineers and scientists actively using thethermodynamic approach in modelling of behaviour.Despite the fact that the first evidence of the use of feedback dates back to 200–100 b. c. when water clocks requiredthe water level in a reservoir to be kept constant, followedby Drebbel’s thermostat and James Watt’s fly-ball governor, it was only in the late nineteen twenties that feedbackwas realised by means of electric signals (Harold StephenBlack’s 1927 famous patent that he wrote on a copy of theNew York Times). At first, electronic feedback was used internally, to reduce distortion in electric amplifiers but later,especially during World War II, this concept was used inradar control and missile guidance. One might say that themultidomain approach to feedback was transferred to a signal approach in which the external power supply did notneed to be part of the behavioural analysis. However, a moreimportant paradigm shift was still to come, viz. the idea thatthe use of feedback allowed the construction of components,viz. operational amplifiers, with which basic mathematicaloperations could be mimicked, leading to analogue computers. This gave a new meaning to the terminology ‘analoguesimulation’ that until then was conceived as mimicking behaviour by means of analogue circuits or mechanisms.Just after World War II, due to the rapidly increasingdemand for electric power, the USA was in great needfor power, in particular hydropower, plants that should beable to deal with large and sometimes rapid fluctuationsin the power grid. Obviously, the success of control theory(cybernetics) during World War II inspired many to applycontrol theory to the dynamic problems involved in electricpower production. One such a civil engineer by the name ofHenry Paynter (http://www.hankpaynter.com/) tried to usethe early analogue computers that he invented together withJames Philbrick, to simulate the dynamics of the powerplants to be built (http://www.me.utexas.edu/ lotario/paynter/paynterbio.html). He used the common descriptionof block diagrams that display the computational structure ofthe differential and algebraic equations being used, as thesemathematical operations were to be mapped directly on thebasic components of the analogue computer. However, forreasons that will become clear in the course of this contribution (viz. related to the concept of computational causality)he ran into formulation problems. At the beginning of thefifties, he realised himself that the concept of a ‘port’ introduced in electrical circuit theory by Wheeler and Dettinger(1949) a few years earlier, should be extended to arbitrarypower ports that can be applied domain-independently.Power ports include mechanical ports, hydraulic ports, thermal ports, electric ports, etc., i.e. everything Paynter neededfor the description of the dynamic behaviour of powerplants (http://www.hankpaynter.com/Bondgraphs.html).In the following decade, after moving to the MIT mechanical engineering department, he designed an efficientnotation based on the efficient representation of the relation89between two ports by just one line that he called a ‘bond’.This so-called ‘bond graph’ notation was completed whenhe finally introduced the concept of the junction in 1959(Paynter, 1961). Junctions not only make bond graph a powerful tool, but they are rather abstract concepts. Just likethermodynamics, bond graphs never became widely popular,although they spread over the whole world and are still aliveafter more than forty years. By contrast, signal processing,analogue and later digital computing, were not constrainedto physical reality. This allowed people to mimic virtuallyeverything, from physically correct or incorrect models to arbitrary mathematical relations that described imaginary systems. In the previous decennium, this even led to conceptslike a ‘cyber world’, etc. even though the level of physical modelling in most virtual environments is rather low, asdemonstrated by the unnatural features of much virtual behaviour.Nevertheless, the introduction of rapid and flexible machinery for production, assembly, manipulation (includingsurgery), etc. that has truly taken off in the nineties, introducing again the need for a systems approach. In theseapplication areas, physical constraints still limit imagination. The dynamics of such devices heavily leans on theapplication of digital electronics (microcomputers) andsoftware. But a domain-independent description of the partsin which power plays a role is crucial to make a designeraware of the fact that a considerable part of these systems isconstrained by the limits of the physical world. This mix ofmechanics, or rather physical system engineering in generalat the one hand and digital electronics, software and controlat the other hand has been named ‘mechatronics’.Obviously, a smooth connection is needed between theinformation-theoretical descriptions of the behaviour ofdigital systems and physical systems theory. From its introduction, bond graphs have allowed the use of signal ports,both in- and output, and a corresponding mix with blockdiagrams. As all digital operations can be successfully represented by block diagrams similar to mathematical operations, the common bond graph/block diagram representationis applicable. This graphical view supports a hierarchicalorganization of a model, supporting reusability of its parts.However, many systems that are studied by (mechatronic)engineers differ from the engineering systems that were previously studied in the sense that the spatial description ofcomplex geometries often plays an important role in the dynamic behaviour, thus including the control of these systems. This shows the need for a consistent aggregation of atthe one hand the description of the configuration of a mechanism and at the other hand the displacements in a systemthat in some way are related to the storage of potential orelastic energy.Another aspect of these systems is that only few realistic models can be solved analytically, emphasizing theimportant role of a numerical solution (simulation). Theaggregation of numerical properties in the representationof dynamic systems allows that a proper trade-off is made
90J. van Amerongen, P. Breedveld / Annual Reviews in Control 27 (2003) 87–117between numerical and conceptual complexity of a model.The approach discussed herein offers a basis for making atrade-off between numerical and conceptual complexity, resulting in both a higher modelling efficiency and numericalsimulation efficiency.Motivated by the problems encountered in the examples,the energy-based approach towards modelling is treated insome detail necessary for the description of simple mechatronic systems. This will give the reader sufficient insight inorder to exercise the approach with the aid of freely available demo version of the modelling and simulation software 20-sim. For more advanced issues the interested readeris referred to the references. The modelling and simulation tool 20-sim allows high level input of models in theform of iconic diagrams, equations, block diagrams or bondgraphs and supports efficient symbolic and numerical analysis as well as simulation and visualisation. It is based on anapproach to formulate mechanical constraints primarily interms of velocities, not displacements. Basic elements andgeneric domain-dependent components in various physicaldomains (in particular the mechanical and electrical domain)can easily be selected from a library and combined into aprocess that can be controlled by block-diagram-based (digital) controllers as demonstrated in the case studies of thenext sections.2. Context‘Mechatronic design deals with the integrated and optimaldesign of a mechanical system and its embedded controlsystem’. This definition implies that the mechanical systemis enhanced with electronic components in order to achieve abetter performance, a more flexible system or just reduce thecost of the system. In many cases the electronics are presentin the form of a computer-based embedded (control) system.This does not imply that every controlled mechanical systemis a mechatronic system because in many cases the controlis just an add-on to the mechanical system in a sequentialdesign procedure. A real mechatronic approach requires thatan optimal choice be made with respect to the realization ofthe design specifications in the different domains.In control engineering, the design of an optimal controlsystem is well understood and for linear systems standardmethods exist. The optimization problem is formulated asfollows: given a process to be controlled, and given a performance index (cost function), find optimal controller parameters such that the cost function is minimized (Fig. 1).With a state feedback controller and a quadratic cost function, solutions for the optimal controller gains can be foundwith standard controller design software, such as Matlab(Mathworks, 2001).Mechatronic design on the contrary requires that not onlythe controller be optimized. It requires optimization of thesystem as a whole. In the ideal case all the components inthe system: the process itself, the controller, as well as theFig. 1. Optimization of the controller.sensors and actuators, should be optimized simultaneously(Fig. 2).In general, this is not feasible. The problem is ill-definedand has to be split into smaller problems that can be optimized separately. Later on the partial solutions have to becombined and the performance of the complete system hasto be evaluated. After eventually readjusting some parts ofthe system this leads to a sub optimal solution.In the initial conceptual design phase it has to be decidedwhich problems should be solved mechanically and whichproblems electronically. In this stage decisions about thedominant mechanical properties have to be made, yieldinga simple model that can be used for controller design. Alsoa rough idea about the necessary sensors, actuators and interfaces has to be available in this stage. When the differentpartial designs are worked out into some detail, information about these designs can be used for evaluation of thecomplete system and be exchanged for a more realistic anddetailed design of the different parts.A mechatronic system consists by definition of a mechanical part that has to perform certain motions and an electronic part (in many cases an embedded computer system)that adds intelligence to the system. In the mechanical partof the system power plays a major role. In the electronicpart of the system information processing is the main issue.Sensors convert the mechanical motions into electrical signals where only the information content is important or eveninto pure information in the form of numbers (if necessary,through an AD-converter). Power amplifiers convert signalsinto modulated power. In most cases the power supply iselectrical, but other sources such as hydraulic and pneumaticpower supplies are possible as well. A controlled mechanical motion system thus typically consists of a mechanicalconstruction, one or more actuators to generate the desiredmotions and a controller that steers the actuators based onfeed-forward and sensor-based feedback control (Fig. 3).Fig. 2. Optimization of all system components simultaneously.
J. van Amerongen, P. Breedveld / Annual Reviews in Control 27 (2003) 87–11791Fig. 3. Mechatronic system.3. Integrated modelling, design and controlof a servo system3.1. ModellingDuring the design of mechatronic systems, it is importantthat changes in the construction and the controller be evaluated simultaneously. Although a proper controller enablesbuilding a cheaper construction, a badly designed mechanical system will never be able to give a good performance byadding a sophisticated controller. Therefore, it is importantthat during an early stage of the design a proper choice canbe made with respect to the mechanical properties needed toachieve a good performance of the controlled system. On theother hand, knowledge about the abilities of the controller tocompensate for mechanic imperfections may enable that acheaper mechanical construction be built. This requires thatin an early stage of the design a simple model is available,that reveals the performance limiting factors of the system.Still there is a gap between modelling and simulation software used for evaluation of mechanical constructions andsoftware used for controller design. Mechanical engineersare used to finite element packages to examine the dynamicproperties of mechanical constructions. It is only after reduction to low-order models (modal analysis) that these modelscan be used for controller design. On the other hand, typicalcontrol engineering software does not directly support themechatronic design process either; in the modelling processthe commonly used transfer functions and state space descriptions often have lost the relation with the physical parameters of the mechanical construction. Tools are requiredthat allow modelling of mechanical systems in a way that thedominant physical parameters (like mass and dominant stiffness) are preserved in the model and simultaneously providean interface to the controller design and simulation toolscontrol engineers are used to (Coelingh, 2000; Coelingh,de Vries, & van Amerongen, 2000).Simulation is an important tool to evaluate the designof mechatronic systems. Most simulation programs likeSimulink (Mathworks, 2001) use block diagram representa-tions and do not support physical modelling in a way that direct tuning of the physical parameters of the mechanical construction and those of the controller is possible as requiredin the design of mechatronic systems. Recently programsthat allow physical modelling in various physical domainsbecame available. They use an object-oriented approachthat allows hierarchical modelling and reuse of models. Theorder of computation is only fixed after combining the subsystems. Examples of these programs are 20-sim (ControllabProducts; Broenink, 1990), and Dymola (Dynasim).In this section, the modelling and simulation program20-sim (pronounce: Twente Sim) will be used to illustratethe simultaneous design of construction and controller inmechatronic systems. 20-sim supports object-oriented modelling. Power and signal ports to and from the outside worlddetermine each object (Weustink, de Vries, & Breedveld,1998). Inside the object there can be other objects or, onthe lowest level, equations. Various realizations of an object can contain different or more detailed descriptions aslong as the interface (number and type of ports) is identical. Modelling can start by a simple interconnection of(empty) submodels. Later they can be filled with realisticdescriptions with various degrees of complexity. de Vries(1994) refers to this as polymorphic modelling. Submodelscan be constructed from other submodels in hierarchicalstructures. Proper physical modelling is achieved by coupling the submodels by means of the flow of energy, ratherthan by signals such as voltage, current, force and speed.At the lowest level all models are described by equations.Signal models can be described at a higher level by blockdiagram elements that are coupled to other elements bymeans of signal ports. Models of physical components canbe described at a higher level by means of bond graphsand iconic diagrams. These submodels are coupled to othersubmodels by means of power ports. Actuator and sensorelements typically have a signal port and a power port andenable, e.g. the connection of signal-based controllers withpower-based physical parts of the mechatronic system.This way of modelling is well suited for mechatronic system design as will be illustrated with a few cases.
92J. van Amerongen, P. Breedveld / Annual Reviews in Control 27 (2003) 87–117Fig. 4. Simple DC-servo system.3.2. Modelling and design of a servo systemWe want to consider the design of a simple servo system,consisting of a current or voltage source, a DC-motor and amechanical load driven through a transmission (Fig. 4).For the time being the transmission is disregarded. Thebelt is considered as infinitely stiff and the transformationratio is taken care for by changing the motor constant. If apower amplifier driven by a signal generator describes thecurrent or voltage source, we can draw the iconic diagramof Fig. 5 . (All the drawings in the example have been madewith the modelling and simulation package 20-sim. The software and (most of) the examples can be downloaded fromthe Internet.) At this stage, the different components in thismodel are still empty. But all components have electricaland/or mechanical ‘ports’. With the proper interfaces (ports)defined, the components can be connected to each other.To derive equations, we have to fill in the details of thedifferent components. The first question is whether the motorwill be controlled by means of voltage or current. Let usassume for the moment that we will apply current steering. Inthat case the power amplifier delivers a current, proportionalto the input signal of the amplifier. If the input of the poweramplifier is assumed to be a constant, the power amplifiercan be modelled as a current source. The motor convertsthe electrical current into a torque. We will initially assumethat the dynamics of the motor (due to its electrical andmechanical parts) are negligible. The transmission is in itsmost simple form a transformation ratio. The load will havesome inertia and friction. This leads to the more detailedFig. 5. Iconic diagram of the simple servo system.model of Fig. 6, where the model is built up from a numberof ideal basic elements. ‘Ideal’ means that each elementrepresents only one single physical phenomenon, like inertia,friction, etcetera.From this diagram, the basic equations can be derived:Current source:i I0Motor:T Km i and u Km ωTransmission: Tmotor nTload and ωload nωmotorFriction:Tf fωInertia:TJ J dωdtwhere I is the motor current; Km is the motor constant; T isthe torque delivered by the motor; n is the transmission ratio(for simplicity assumed to be 1, such that Tmotor Tload T ); Tf is the torque loss due to friction; TJ is the torqueused to accelerate the load; J is the inertia of the load; f isthe coefficient of viscous friction; ω1 is the motor angularvelocity; ω2 is the load angular velocity; ϕ is the load angle.With T Tf TJ 0 it follows that:Kmdωi fω Jndtdϕω dtAfter Laplace transformation this system can be transferred into the following block diagram of Fig. 7 with:Km1/fKω un (J/f)s 1sτ 1Fig. 6. Schematic diagram modelled with basic elements.
J. van Amerongen, P. Breedveld / Annual Reviews in Control 27 (2003) 87–11793Fig. 7. Block diagram of a current controlled servo system.Fig. 10. PD-controlled model.orϕKm1/fK un s((J/f)s 1)s(sτ 1)with K Km /nf and τ J/f .When the parameters are known, standard controller design tools like bode plots, root loci and so on can be used todesign a controller for this system. A disadvantage is that inthe process of converting the ‘physical model’ in the formof an iconic diagram with physical meaningful parametersinto a block diagram with gain factors K and time constants,the relation with the physical reality is easily lost.Based on the model of Fig. 7, we can design a controller,e.g. by mean
Keywords: Mechatronics; Physical systems; Design and control; Modelling and simulation; Bond graphs; Energy-based modelling 1. Introduction Mechatronic design deals with the integrated design of a mechanical system and its embedded control system. This definition implies that it is important, as far as possible, that the system be designed as .
forms, and software for their members. Before reproducing, adapting, or translating the Guide in any of the ways illustrated in the following pages, IFAC member organizations and professional accountancy organizations must first seek permission from IFAC (see section
2 Member of the MONET European Network of Excellence (2003-). Member of the World Scientific and Engineering Academy and Society WSEAS (2003-). IFAC affiliate member and articles reviewer in IFAC AUTOMATICA (2003-). Member of the Association for the Advancement of Modelling and Simulation AMSE (2002-), AMSE representative for Greece, and articles reviewer in AMSE Advances in Modelling, Series .
accountants, and promoting the value of professional accountants worldwide; and speaking out on public interest issues. The Professional Accountants in Business (PAIB) Committee serves IFAC member bodies and professional accountants worldwide who work in commerce, industry, financial services, education, and the public and not-for-profit sectors.
and simplified method to describe masonry vaults in global seismic analyses of buildings. Fig. 1 summarizes three different modelling techniques for ma sonry modelling, respectively, mi cro- , macro- and simplified micro modelling. In the case a micro modelling approach is take n, the challenge is to describe the complex behavior of the
Agile Modelling is a concept invented in 1999 by Scott Ambler as a supplement to Extreme Pro-gramming (XP) [Source: Agile Modelling Values]. Strictly defined, Agile Modelling (AM) is a chaordic, practices-based methodology for effective modelling and documentation [Source: Interview with SA by Clay Shannon].
equately support part modelling, i.e. modelling of product elements that are manufactured in one piece. Modelling is here based on requirements from part-oriented applica-tions, such as a minimal width for a slot in order to be able to manufacture it. Part modelling systems have evolved for some time now, and different modelling concepts have
5. Who can grow the largest crystal from solution? Modelling crystals 15 . 1. Modelling a salt crystal using marshmallows 2. Modelling crystals using cardboard shapes 3. Modelling diamond and graphite 4. Modelling crystal growth using people. More about crystals 21 . 1. Crystalline or plastic? 2. Make a crystal garden. Putting crystals to use .
launch AutoCAD 2016. Opening an existing Drawing. This tutorial shows you how to add arcs and circles to the subdivision drawing provided with the datafiles that came with this guide. In Tuto-rial 3 you will finish the subdivision drawing so that the final drawing will look like Figure 2.1. Figure 2.1 . POND. N. 10. ECSTASY ROAD . CIRCLE. GARRET BRONWYN ROAD. 9 8 7 6 5 4 3 2 1. Wannabe Heights .
