Mechatronics (Mechanical System Control): It’s The …bramlambrecht.com/tmp/me230/01 -...

Post on 10-Mar-2018

232 views 3 download

transcript

Copyright (c) 2007, D. M. Auslander 1

Mechatronics (Mechanical System Control): It’s The Software!

David M. AuslanderMechanical Engineering

University of California at Berkeley

Copyright (c) 2007, D. M. Auslander 2

Preamble

1. Don’t take the name “Mechatronics” too literally2. The biggest value-added in mechatronics is in

software3. Mechanical system control:

Then: Striving for complexityNow: More complexity than we can handle!

Copyright (c) 2007, D. M. Auslander 3

Mechanical Systems

A long history of complexity in mechanical devicesModulation of power for delivery to a targetBroadly applied to physical systems

Motion, thermal, fluid, chemicalThesis: Software has made this into a new game!

Copyright (c) 2007, D. M. Auslander 4

A Little History

Computation in control of early machinesDelivery of power – steam enginesComplex pattern generation – Jacquard loomBrushed DC motor

Copyright (c) 2007, D. M. Auslander 5

Fairbottom Bobs

Newcommenengine(~1760)http://www.ashton-under-lyne.com/bobs.htmAshton under LynePumped water from coal pitsPhoto ~1880

Copyright (c) 2007, D. M. Auslander 6

Newcomen Engine Control

www.technology.niagarac.on.ca/courses/tech238g/newcomen.htmAtmospheric steam engineUsed water spray to condense steam in cylinderControl of valve based on walking beam position1712, invented first usable steam engine

Copyright (c) 2007, D. M. Auslander 7

The Watt Governor

http://www.vintagesaws.com/library/steam/steam.htmlFor cotton mill1856100 HP, 30 RPMNote flyball (Watt) governorSmithville, Texas, USA

Courtesy of Vintage Saws

Copyright (c) 2007, D. M. Auslander 8

Closeup of Governor

Note link that connects flyballto steam valveMajor limitation of all classically controlled mechanical systems

Courtesy of Vintage Saws

Copyright (c) 2007, D. M. Auslander 9

Jacquard Loom

http://www.digidome.nl/history.htmPunch card driven1804Used to weave very complex patterns in silk

Copyright (c) 2007, D. M. Auslander 10

Silk Woven on a Jacquard LoomSilver and gold threads used for the pattern

Copyright (c) 2007, D. M. Auslander 11

Still In Use …

Copyright (c) 2007, D. M. Auslander 12

Classical Mechatronics – Brush vs. Brushless Motors

Brush motor –classic mechanical systemRotor – coilsStator – permanent magnetsCommutatorcomputes

Amplifier

+

-

Magnets

N S

Coils/Commutator Brushes

Copyright (c) 2007, D. M. Auslander 13

Complexity Limitation in Classical Mechanical Systems

No separation of sensing, computation, and powerExample: flyball governer

Power to operate steam valve comes from flyballMust have low-impedance path from main shaft all the way to the steam valveCommon physical medium (mechanical)

Example: Brush motor, commutator

Copyright (c) 2007, D. M. Auslander 14

Enter Mechatronics

Yaskawa Electric coined the term around 1970 to describe brushless motor technology

Trademark, then releasedAdding electronics made a completely different class of systemInconceivable in prior era

Copyright (c) 2007, D. M. Auslander 15

Brushless Motor

Brushless –invert rotor and statorMeasurement of rotor position needed to properly excite stator coils

Multi-channelAmplifier

Computation

Stator(coils)

Wires

Wires

Rotor (magnet)

Positionsensor

Copyright (c) 2007, D. M. Auslander 16

Modern Mechatronics

Add economic, compact computation“The synergetic integration of mechanical engineering with electronics and intelligent computer control in the design and manufacturing of industrial products and processes.” (IEEE/ASME Transactions On Mechatronics, 1996)Or, “The application of complex decision-making to the control of physical systems”

Copyright (c) 2007, D. M. Auslander 17

What’s Unique?

The shorter definition focuses more strongly on the uniqueness of software-driven mechanical systemsThey can have control complexity beyond the wildest dreams of pre-computer engineersControl – interpreted broadly, not just feedback control

Copyright (c) 2007, D. M. Auslander 18

Enabling Technologies - I

AmplificationVacuum tube, Lee De Forrest, 1906Flapper nozzle valve, pneumatic and hydraulic

Enabled isolation of measurement, computation and actuation

Impedance mismatch vs. impedance matchOptimization of medium

Copyright (c) 2007, D. M. Auslander 19

Enabling Technologies - IIThe Emergence of Software

Process control was initial applicationCould afford very expensive, large hardwareImproved productivity, reliabilityMicroprocessor invention dramatically lowered cost-of-entryNow – cheapest way to control power modulation

Copyright (c) 2007, D. M. Auslander 20

Real Time Software

Software is data reproducibleSuccessive program operation with same input data produces same output

This is a defining property of computation and software – no error propagation!

Essence of digital systems: no complexity limitHowever, it is not generally time reproducibleExample – timed loop with histogram

Copyright (c) 2007, D. M. Auslander 21

Same Program, Run Twice

Time (sec) # less than2.0E-6 04.0E-6 26401028.0E-6 169721.6E-5 463.2E-5 3486.4E-5 2411.28E-4 1972.56E-4 915.12E-4 123

Time (sec) # less than2.0E-6 04.0E-6 26342228.0E-6 169681.6E-5 653.2E-5 3626.4E-5 2301.28E-4 2142.56E-4 1005.12E-4 160

Copyright (c) 2007, D. M. Auslander 22

Real Time for Mechatronic Control

In brief, specifications (tolerances) for time reproducibilityEach module of control software will have its own specs“Hard” (deadline) real time is not usually requiredMuch of the activity is asynchronous preventing deterministic scheduling

Copyright (c) 2007, D. M. Auslander 23

Design Principle

If any mechanical components are present to convey information consider replacing them with software (first choice) or electronicsExamples

Brushes brushless motorCarburetor fuel injectionKinematic linkages, cams motion profilesAir dampers variable speed motors

Copyright (c) 2007, D. M. Auslander 24

Design Context: The Unit Machine

Domain of applicabilityEstablish appropriate design methodology“The elements of a unit machine exchange physical power with each other or exchange material with little or no buffering”Unit machine too big can’t handle complexityUnit machine too small can’t optimize

Copyright (c) 2007, D. M. Auslander 25

Example: Semiconductor Mfg

Courtesy of Berkeley Process Control, Inc

Redefinition of the “unit machine”improved throughput by 3.5 times for a system similar to this!

Copyright (c) 2007, D. M. Auslander 26

Control Software for a Unit Machine

Must have rapid access to all internal informationSensors, actuators, states, commands, etc.Rapid: fast enough to use in control loopsCan be used to optimize operation

Information between unit machines usually simple commands, limited scope, slow

Copyright (c) 2007, D. M. Auslander 27

Unit Machine Examples

Wafer handling robotCommercially defined as unit machineOften too simple

Denver airport baggage handlingToo complex to be treated as unit machineDefeated by complexity (my opinion!)

Dynamic definition of unit machine in biologyHuman gait change from walking to running

Copyright (c) 2007, D. M. Auslander 28

Industrial Experience: Complexity is the Problem

Control (read software) is the largest cause of failure in complex manufacturing machinesFailure to understand the consequences of complexity lead to unreliable operation, poor performanceMechanical engineers – don’t understand softwareSoftware engineers – don’t understand machines

Copyright (c) 2007, D. M. Auslander 29

Design Language

A means of describing and documenting solutions; map easily to softwareMore abstract than code

Most code is unreadable – even by the person that created it!

Communication vehicle among all stakeholdersEngineering, manufacturing, marketing, maintenance, etc.

Copyright (c) 2007, D. M. Auslander 30

Tasks and State Machines

Tasks – Simultaneously executing modules“A task is a well-defined responsibility” (American Heritage Dictionary)Suitable for complexity levels associated with unit machinesHierarchical organizationLowest level maps to mechanical system hardwareHigher levels are goal oriented (next slide …)

Software

HardwareActuator InterfaceActuator Interface Sensor Interface

Actuator Sensor

Target Object

Actuator SignalProcessing

Sensor SignalProcessing

Feedback Control

Supervisory Control

To other targets

Goal Seeking

To other subsystems

External Communication Operator Interface

Control Software

Outside World

OperatorFacility Network Internet

Copyright (c) 2007, D. M. Auslander 32

Finite State Machines

Internal task structure is finite state machineStates consist of three sections

Entry – executed only after a transitionAction – execute alwaysTransition test

Tasks and associated state machines provide a design model that is widely accessible as well as translatable into functioning software

Copyright (c) 2007, D. M. Auslander 33

Implementation Languages

Desired properties in implementation languagesPortabilityClean syntaxEfficient footprint and operationWell documented

Copyright (c) 2007, D. M. Auslander 34

Software Portability

Primary factor in productivity/economicsDevelopment stagesProduction upgradesProcessor generation time: 18 months or lessMechanical generation time: 5 – 20 years

Copyright (c) 2007, D. M. Auslander 35

Computational Implementation

Clean separation between design and software implementationFocus on mapping design to software

Easily connect sections of software with design elements

To the extent possible, weaken the dependence on language, OS, environment, hardware specifics

Copyright (c) 2007, D. M. Auslander 36

Cooperative Multitasking

Most portable form of multitaskingRequires one major stylistic restriction:

All code must be non-blockingState machine fits this model very well

“Universal” real time model –If computer is fast enough, can meet all specsOften true

Otherwise, interrupts, priorities, etc. involve resource shiftingSee plenary talk by Michael Pont on this subject

Copyright (c) 2007, D. M. Auslander 37

Low/Medium Level Languages

Object-oriented approach“Implementing two motors for position control within the program was a rather straightforward approach …” (Berkeley student)C, C++ and Java Java easier to learn, cleaner syntax, much better portability, but has performance problemsC still the most widely used

Copyright (c) 2007, D. M. Auslander 38

High Level Languages

Programming productivity – lines/day, regardless of languageTherefore, use language requiring fewer linesCode generator (as in Matlab/Simulink) or embed into processor (e.g., Labview)More practical as processors get fasterStill used more for development than production

Copyright (c) 2007, D. M. Auslander 39

Simulation

Crucial step in design process but often skippedConceptual and execution errors much more easily found than in real environmentTakes initial effort to set up simulation

Engineers don’t want to spend the time!Dilemma: How to avoid rewriting control code for simulation?Major portability challenge

Copyright (c) 2007, D. M. Auslander 40

Simulation Environments

C, C++, JavaLimited mathematical and plotting support

Matlab/Simulink and other mathematical environments

DLL for control code or use code generatorCh

C for control code; C and limited C++ for simulation with rich math and graphics – easy to integrate C

Copyright (c) 2007, D. M. Auslander 41

Implementation Environments

From lab to production, PC to microcontrollerReal time

General purpose OS (Windows, etc.) ~1 second (can be used faster for demo, debug, but not reliable)Real Time OS (RTOS - QNX, VxWorks, etc) sub-millisecond for regular tasks, microsecond for interruptsLabview-RT – sub millisecond, shell must be LabviewBare processor – microsecond

Cooperative multitasking improves portability

Copyright (c) 2007, D. M. Auslander 42

Multiprocessor and Networking

Networking becoming ubiquitous even in control systemsMany network “standards”Ethernet gaining ground, but no winner yetThree network levels (at least!)

Sensor and actuatorControl processorFactory (sometimes a cell level also)

Copyright (c) 2007, D. M. Auslander 43

Networking and Control Software

Portability again the keyTreat tasks as indivisible network componentsAbstract intertask communication

That is, custom application layer for intertaskcommunication

Allows for isolation of actual network protocols

Copyright (c) 2007, D. M. Auslander 44

Future Directions

Moore’s law still holds, but direction has changed

Multi-core processors rather than more powerfulOnly likely to impact high-end systems in near future

FPGA (field programmable gate array)New processor frontierFully parallelUsually viewed as circuit element but complexity has increased so now looks like processor with software

Copyright (c) 2007, D. M. Auslander 45

Lessons Learned

Managing complexity is the challengeModularity is the primary tool

Unit machine for hardware designTasks, state machines for software design

Too much modularity limits the amount of global optimization that can be doneToo little leads to unpredictable behavior and costTherefore, err on the side of too much modularity