Upload
hadang
View
241
Download
3
Embed Size (px)
Citation preview
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