Analysis, Design, and Control for Robots in
Temperature-Restricted Environments
MASSACHUSETTS INS1TIOi
OF TEC OLOGY
by
4121:111
Ethan B Heller
B.S.M.E., Tufts University (2007)
I
LBRAI
Submitted to the Department of Mechanical Engineering
in partial fulfillment of the requirements for the degree of
Master of Science in Mechanical Engineering
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
June 2013
©
Massachusetts Institute of Technology 2013. All rights reserved.
A u th o r .................................. . . r ........ ................
Department of Mechanical Engineering
May 10, 2013
Certified by ........
Kamal Youcef-Toumi
Professor of Mechanical Engineering
Thesis Supervisor
...
David E. Hardt
Professor of Mechanical Engineering
Graduate Officer
A ccepted by ...........................
2
Analysis, Design, and Control for Robots in
Temperature-Restricted Environments
by
Ethan B Heller
Submitted to the Department of Mechanical Engineering
on May 10, 2013, in partial fulfillment of the
requirements for the degree of
Master of Science in Mechanical Engineering
Abstract
In this thesis, the problem of controlling the internal and external temperatures of
a robot operating within a temperature-restricted environment was addressed. One
example of a temperature-restricted environment is the interior of a holding tank
for Liquefied Petroleum Gas (LPG), which is the focus of the analysis in this work,
but not the only possible application. This gas is stored at sub-zero temperatures
to maintain its liquidity, and any significant rise in temperature can cause the gas
to vaporize, posing a safety hazard. The tank in which the gas is stored must be
periodically inspected for defects. Using robot inspectors while the tank is in service
would reduce the cost due to lost productivity during human inspection. A thermal management system (TMS) was designed to maintain the robot's electronics and
components within operating limits, while preventing the external environment from
increasing in temperature above safe levels. A detailed model of the system was constructed for simulation, and the results indicate that the system performs as intended,
but requires closed-loop control to maintain robot operation for extended periods of
time. A control system based on system model linearization and model predictive
control was implemented for the TMS. The results of the closed-loop simulations indicate that the control system enhances the operation of the TMS, maintaining robot
operating temperatures for extended periods of time, while avoiding an unsafe rise in
the temperature of the external environment.
Thesis Supervisor: Kamal Youcef-Toumi
Title: Professor of Mechanical Engineering
3
4
Acknowledgments
I would first like to thank my advisor, Kamal Youcef-Toumi, and my labmates at
the Mechatronics Research Laboratory (MRL) for their help and support throughout
the time it took to finish this thesis. Without the guidance of Prof. Youcef-Toumi
and the other students in the MRL, none of this work would have been possible.
In particular, my thanks go to Dimitris Chatzigeorgiou and Amith Somanath, who
have been in the lab with me since the beginning, and have always provided help and
advice when asked.
I also would like to thank GE Aviation, whose financial support and time consideration was instrumental in my work here at MIT. I would specifically like to thank
my patient managers and coworkers, who were understanding of my dual role.
The Qatar National Research Fund has generously supported the robotic inspection project in progress both at MIT and Qatar University. I would also like to thank
Prof. Uvais Qidwai of Qatar University for helping me understand their end of the
project, and Tunde Yusuf of the RasGas Company for answering my questions about
LNG and LPG storage.
In the course of my studies I received help from many people, but there are a few
who I would specifically like to thank. Dan Burns, a former member of the MRL,
and Chris Laughman, both of the Mitsubishi Electric Research Laboratories, were
always patient with my Dymola questions. John Batteh and Jesse Gohl of Modelon
were even more patient with my questions on Dymola and everything Modelica, and
invaluable in helping me make my simulation work.
Finally, Leslie Regan in the
graduate office forever has all the answers.
Last, and most importantly, I would like to thank my family. My ever-patient
wife, Krystin, for putting up with the final few months of this endeavor, and my
parents, who kindly managed not to ask every day how the thesis was coming along.
Without you, I would not have made it this far.
5
6
Contents
1
1.1
1.2
1.3
1.4
2
15
Introduction
M otivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.1.1
LPG and LNG Storage . . . . . . . . . . . . . . . . . . . . . .
15
1.1.2
Inspection of Gas Storage Tanks . . . . . . . . . . . . . . . . .
16
1.1.3
Robotic Inspection
. . . . . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.2.1
Robot Design in Qatar . . . . . . . . . . . . . . . . . . . . . .
18
1.2.2
Need for Electronic Temperature Regulation . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.3.1
Heat Storage for Electronic Cooling . . . . . . . . . . . . . . .
19
1.3.2
Robots Operating in Space.
. . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . .
20
Background
Prior Work
Thesis Structure and Scope
23
Design
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.2
Design Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . .
25
2.3
2.2.1
Restricted Waste Heat Rejection
2.2.2
System Design Objectives
. . . . . . . . . . . . . . . . . . . .
27
2.2.3
Overview of the Thermal Management System . . . . . . . . .
27
2.2.4
The Thermal Management System Used for Initial Analysis
28
A nalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.3.1
Actuator Heat Generation
. . . . . . . . . . . . . . . . . . . .
31
2.3.2
Thermal Transfer Fluid . . . . . . . . . . . . . . . . . . . . . .
32
7
2.4
3
Thermoelectric Conversion . . . . . . . . . . . . . . . . . . . .
33
2.3.4
Thermal Rejection Convection . . . . . . . . . . . . . . . . . .
34
2.3.5
Thermal Resistor Model Results . . . . . . . . . . . . . . . . .
35
2.3.6
Total System Power Generation . . . . . . . . . . . . . . . . .
36
2.3.7
Thermal Storage Volume . . . . . . . . . . . . . . . . . . . . .
37
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Modeling
39
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2
Modeling of the TM S components . . . . . . . . . . . . . . . . . . . .
41
3.2.1
Component Construction . . . . . . . . . . . . . . . . . . . . .
41
3.2.2
Component Verification Testing . . . . . . . . . . . . . . . . .
48
System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.3.1
Assembly
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.3.2
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.3
3.4
4
2.3.3
Control
61
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.1.1
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.2.1
Closed-Loop Control Construction
. . . . . . . . . . . . . . .
65
4.2.2
Model Modification for Control
. . . . . . . . . . . . . . . . .
67
4.2.3
Input and Output Choices . . . . . . . . . . . . . . . . . . . .
68
4.2.4
Choice of Linearized States
. . . . . . . . . . . . . . . . . . .
70
4.2.5
MPC Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.3.1
Controller Testing . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.3.2
Tuning Simulations . . . . . . . . . . . . . . . . . . . . . . . .
75
4.2
4.3
4.4
Results.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.5
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
8
5
83
Conclusions and Recommendations
...............
5.1
Summ ary
5.2
Future Work .................
.. . . . . . . . . . . . . . .
83
.. . . . . . . . . . . . . . .
86
87
A Modelica Code and Graphical Models
.. . . . . . . . . . . . .
A.1 System Model ................
A.2 M otor Unit
87
97
..............
A.3 DC M otor ...............
100
A.4 Heater ....................
103
Backward Hysteresis . . . . .
105
A.5 Fluid Block . . . . . . . . . . . . . .
106
. . . . . . . . . . . . . .
109
A.7 HC-50 Medium . . . . . . . . . . . .
110
A.8 PCM Block . . . . . . . . . . . . . .
114
A.8.1
PCM Interior Unit . . . . . .
119
A.8.2
PCM Edge Unit . . . . . . . .
121
A.8.3
PCM Corner Unit ........
123
A.4.1
A.6 TE Module
.........
125
LPG Medium .........
129
A.9 External Convection
A.9.1
B Modelica Verification Testing and Simulink Comparison Testing
B.1 Verification Testing . . . . . . . . . . . . . .
B.2 Simulink and Dymola Comparison Tests
. . . . . . . . . .
133
133
138
C Matlab Code
145
D Closed-Loop Simulation Test Results
153
9
10
List of Figures
17
.................................
..
1-1
Neptune II........
2-1
Comparison of the components
2-2
Layout of analyzed Thermal Management System
. . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . .
29
2-3
Thermal resistance model without PCM energy storage . . . . . . . .
30
3-1
Fluid block thermal resistance data-fit results
. . . . . . . . . . . . .
42
3-2
Fluid block m odel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3-3
Dymola model of PCM block
. . . . . . . . . . . . . . . . . . . . . .
45
3-4
Fluid block verification test results
. . . . . . . . . . . . . . . . . . .
49
3-5
TE module verification test model . . . . . . . . . . . . . . . . . . . .
50
3-6
TE module verification test results
. . . . . . . . . . . . . . . . . . .
51
3-7
PCM block verification test results
. . . . . . . . . . . . . . . . . . .
52
3-8
External convection verification test results . . . . . . . . . . . . . . .
53
3-9
Heater verification test results . . . . . . . . . . . . . . . . . . . . . .
54
. . . . . . . . . . . . . . . . . . . . . . . .
55
3-11 System responses for three levels of fluid flow . . . . . . . . . . . . . .
58
3-12 Dymola results to a trapezoidal velocity input . . . . . . . . . . . . .
59
. . . . . . . . . . .
67
3-10 TMS system model layout
4-1
Illustrations of two time window implementations
4-2
Comparison of the heat flow to the PCM block or ambient
. . . . . .
68
4-3
Simulation velocity results with poorly-shaped output reference values
73
4-4
Dymola motor temperature results to a trapezoidal velocity input
74
4-5
Example of simulation output results with poorly-shaped references
11
.
75
4-6
Closed-loop velocity results . . . . . . . . . . . . . . . . . . . . . . . .
77
4-7
Closed-loop output results comparison: measured vs. linearized
. . .
78
4-8
Closed-loop motor temperature comparison: measured vs. linearized .
79
4-9
Closed-loop velocity comparison: measured vs. linearized . . . . . . .
80
4-10 Velocity results for the end of the simulation . . . . . . . . . . . . . .
80
4-11 External temperature results for the end of the simulation
. . . . . .
81
Dymola graphical model of the TMS system . .
. . . . . . . . . .
88
A-2 Dymola graphical model of the motor unit . . .
. . . . . . . . . .
97
. . .
. . . . . . . . . .
100
A-4 Dymola graphical model of the heater . . . . . .
. . . . . . . . . .
103
. . .
. . . . . . . . . .
106
A-i
A-3 Dymola graphical model of the DC motor
A-5 Dymola graphical model of the fluid block
A-6 Dymola graphical model of the PCM block . . .
. . . . . . . . . . 114
A-7 Dymola graphical model of external convection .
. . . . . . . . . . 125
Fluid block verification test model . . . . . . . .
. . . . . . . . . .
134
B-2 PCM block verification test model . . . . . . . .
. . . . . . . . . .
135
B-3 External convection verification test model . . .
. . . . . . . . . .
136
B-4 Heater verification test model . . . . . . . . . .
. . . . . . . . . .
137
B-i
B-5 Dymola model of the TMS system used for Dymola/Simulink comparison tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
138
B-6 Simulink model of the TMS system used for Dymola/Simulink comparison tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
139
B-7 Dymola results for the external heat flow . . . . . . . . . . . . . . . .
140
. . . . . . . . . . . . . . .
140
B-9 Dymola results for the PCM average temperature . . . . . . . . . . .
141
B-8 Simulink results for the external heat flow
B-10 Simulink results for the PCM average temperature . . . . . . . . . . . 141
B-11 Dymola results for the fluid block heat flows . . . . . . . . . . . . . .
142
. . . . . . . . . . . . .
142
. . . . . . . . . . . . . .
143
B-14 Simulink results for the system temperatures . . . . . . . . . . . . . .
143
B-12 Simulink results for the fluid block heat flows
B-13 Dymola results for the system temperatures
12
D-1
Closed-loop calculated control commands . . . . . . . . . . . . . . . .
153
D-2
Closed-loop output predictions of the MPC . . . . . . . . . . . . . . .
154
D-3
Closed-loop output reference values . . . . . . . . . . . . . . . . . . .
154
13
14
Chapter 1
Introduction
The components of a robot generate waste heat during operation, which must be
removed or those components may cease to work properly. In most cases, that waste
heat is rejected to the ambient environment, but in some cases the environment cannot
tolerate the rejection of waste heat.
It is for these circumstances that a Thermal
Management System (TMS) is proposed. This system incorporates several additional
components in the robot construction, in order to safely transport the heat away from
the generating components, store the heat, and reject the heat to the environment.
The proposed design was modeled in Dymola and simulated in MATLAB/Simulink
with both open-loop and a proposed closed-loop control. These simulations illustrate
the usefulness of the TMS for robot operation in a refrigerated environment, but use
of this system is not limited to those cases.
1.1
1.1.1
Motivation
LPG and LNG Storage
Once retrieved and processed, Liquefied Petroleum Gas (LPG) and Liquefied Natural
Gas (LNG) are often stored in large, above-ground tanks. The interiors of these tanks
are kept refrigerated, in order to keep the gasses in their liquid state. When stored
at atmospheric pressure, LPG is chilled to -45 'C and kept below -42 'C to prevent
15
vaporization. The typical storage temperature of LNG is even colder at -162 'C, and
it must be kept below -158 'C to avoid vaporization. [45]
[58]
The storage tanks typically have diameters of roughly 100 m and heights of 50 m.
[43] These tanks can be constructed in a number of styles. The most common tank
style is double-walled, with insulation sandwiched between two steel walls. Regular
inspection of the tank walls is necessary to ensure that the steel does not contain
any flaws, such as corrosion, cracks, or weld defects. Inspection specifications and
intervals for refrigerated tanks vary depending on what type of liquefied gas is being
stored. [44] [3]
1.1.2
Inspection of Gas Storage Tanks
The outer surface of the tank can be inspected for defects while the tank is in operation
with no loss of productivity. Interruption in the operation of a tank represents a very
large loss of productivity, so tank inspection is ideally performed with the tank still
in service. However, the current inspection process for the inside of a liquefied gas
holding tank is to drain the tank of all the gas, bring the interior temperature up
to human-survivable levels, and to manually inspect the interior surface. This entire
maintenance cycle, including re-refrigerating the tank and refilling it with gas, can
take up to eight months, at the cost of approximately $10 million per day in lost
productivity. [58] It is therefore clear that a solution for in-operation inspection is
immensely beneficial. One such solution is the use of robotic inspectors.
1.1.3
Robotic Inspection
There are great advantages to operating robots as inspectors inside liquefied gas holding tanks versus using human inspectors. These robots can perform necessary inspections on the tanks without the environmental restrictions that human inspectors have.
This allows the robots to perform the inspections while the tank is still in service,
saving significant money for the tank operator during the inspection. Additionally,
removing the need to place a person within an enclosed hazardous environment signif16
icantly increases operational safety, regardless of whether the inspection is performed
with the tank in or out of operation.
Figure 1-1: Neptune II used with permission from http://www.frc.ri.cmu.edu/
-hagen/samplers/figures/neptuneon-rustyplate . gif
Robots for inspection of petrochemical holding tanks have existed as a commercial
option for many years. There are many examples of robots that inspect the outer
walls of holding tanks using either magnetic treads or wheels, or suction-tipped limbs
to climb the sides of the tanks, such as those presented in [37], [38], [50], [51], [60],
and [25]. Fewer robots inspect the tank interiors. Two examples of current in-tank
inspection robots-for products stored at room temperature-are the Neptune system
and the TechCorr On-Stream Tank Inspection System (OTIS). The Neptune system
is capable of performing floor and wall inspections to American Petroleum Institute
(API) standard 653. The robot uses both vision and ultrasonic sensors to gather
inspection data. The Neptune II robot is shown in Fig. 1-1. [52] Similarly, OTIS
also performs API 653 inspections on the floor of storage tanks. TechCorr operates
OTIS on a commercial basis, with several systems in operation. As of March 2011,
OTIS has inspected over 175 tanks. [56] However, these two robots are still limited
to operation within gasses stored at room temperature.
17
1.2
1.2.1
Background
Robot Design in Qatar
One project in progress to design a robotic inspector for use in refrigerated liquefied
gas holding tanks is out of Qatar University. Their design incorporates safety features
such as brushless motors to avoid any potential sparks that can be ignition sources,
and an insulated compartment for the robot's electronics. Two types of sensors are
incorporated into the design: magnetic flux leakage sensors and visual sensors. The
current choice for the magnetic flux leakage sensor is the Silverwing Handscan. Using
these sensors in combination allows the robot to identify defects in the interior wall
of the holding tank. [6]
1.2.2
Need for Electronic Temperature Regulation
Though the electronics in the Qatar robot are insulated against the refrigerated environment, there are no active or passive controls over the temperature of those
electronics.
As the inspection takes place, the electronics will generate heat, and
when kept inside an insulated compartment, will eventually saturate their environment with this heat. Once the compartment is saturated with the electronics' waste
heat, the internal temperature of the electronics will increase, leading to overheating,
and shutting down the robot. Some method must be employed to remove the waste
heat from the electronics in order to maintain proper robot operation during inspection. This method must also be actively monitored to ensure that the waste heat
leaving the robot does not pose a safety risk in the ambient environment of liquefied
gas.
18
1.3
Prior Work
1.3.1
Heat Storage for Electronic Cooling
One method of removing the waste heat from the electronics without rejecting that
heat to the ambient environment is to store most of the heat energy. Phase-change
materials are already used commercially to store thermal energy when that energy
cannot be dissipated. One application of this use is to maintain the temperature of
electronics operating in heated ambient environments. As described in [41], a heat
sink incorporating heat storage in the form of phase-change material (PCM) is utilized
in firefighting as a method of keeping infrared cameras cool within the environment
of a building fire. In this case, the PCM absorbs the heat generated by the camera
when the ambient temperature is above the temperature of the electronics, increasing
the running time of the camera before overheating.
Other works, such as
[55]
and [16], address the design of PCM-filled heat sinks
as a method of maintaining temperatures of electronics in the face of peak usage,
where the design of a cooling system capable of dissipating the peak heat generation
does not fit with the usage of the electronics (such as in mobile devices).
Both of
these works specifically focus on increasing the operating time of electronics before
overheating, and mention the need to include heat spreaders in the PCM to evenly
distribute the heat through the PCM due to the poor thermal conductivity of the
material.
1.3.2
Robots Operating in Space
Although the use of PCM can help ensure that the electronics do not overheat, being
too cold for operation is also a concern. When operating in very cold environments,
the electronics must be maintained above their lower operating temperature limit.
Most of the prior work in the heating of electronics for applications in cold environments relates to the operation of robotic craft in space. The most obvious parallel to
draw is to the robotic rovers used in the Mars missions. These rovers (including the
19
latest, Curiosity) house their main electronics in a Warm Electronics Box (WEB).
[33] [34] This box provides an insulated, temperature-controlled environment for the
rover's non-hardened electronics.
NASA provides some of the heating to the WEB
through electronic heaters, and the remaining heating requirements are met by radioisotope heating units, which are used to conserve electrical energy. [35] The WEBs
of the Mars rovers are insulated to reduce the heating requirements. The insulation
used in the WEBs is based on silica aerogel, a very lightweight material with extremely
low thermal conductivity. [36]
1.4
Thesis Structure and Scope
The body of this thesis is structured into three chapters, each of which defines a
distinct stage in the development of the Thermal Management System. The chapters
contain background information on the concepts used in that particular stage of the
TMS development and relevant discussion.
Design of the TMS
This chapter details the development of the TMS concept
and outlines the components that could be included in the configuration of the TMS.
Descriptions of the individual TMS components and their purposes are given. The
initial calculations that were performed show that the proposed concept will work
with commercially-available components.
Modeling of the TMS
This chapter describes the detailed modeling of one con-
figuration of the proposed TMS using the Modelica modeling language. The system
model is constructed of both standard and custom component models. Verification
testing confirmed that the component models behave as expected to simple inputs.
Several open-loop control simulations show that the TMS system behaves as intended,
and does indeed maintain robot component temperatures within operational levels
for a longer time than without the TMS. However, closed-loop control is necessary to
maintain robot operation for extended periods of time.
20
Control of the TMS
This chapter covers the development of the closed-loop con-
trol for the TMS in the MATLAB/Simulink environment.
The Modelica model is
exported to Simulink, where MATLAB functions are used to create a control system
for the TMS to ensure that system constraints are not violated during operation, even
for long durations.
21
22
Chapter 2
Design
This chapter proposes one design of a thermal management system for robots to meet
the challenges detailed in Chapter 1. Initial calculations show that this concept can
be implemented for an ambient environment of refrigerated LPG, maintaining the
components of the robot within operating temperatures and limiting the surrounding
temperature rise to safe values.
2.1
Introduction
Though robots are commonly deployed in a wide array of settings, one environment
that has not received much attention yet is one in which the robot surface temperature
cannot exceed a certain value. These environments include surroundings where safety
or an operational constraints limit the release of waste energy, such as areas that
are refrigerated.
Examples of cold environments that robots currently operate in
are space or on other planets, and underwater.
However, venting waste heat into
these environments is not typically an issue, unlike the interior environment of a
liquefied gas holding tank, where the product inside must be maintained at very cold
temperatures to prevent vaporization and avoid safety hazards.
Typical waste heat rejection
The waste heat generated by a robot's systems
is rejected from the systems using different methods, depending on the robot's op-
23
erating environment.
For a robot operating on land in a thermally-unconstrained
environment, rejection of generated waste heat is typically performed by either passive or active convection of the heat to the surrounding air inside the robot chassis or
conduction through the component housing. The air within the chassis is then circulated with the surrounding ambient environment. Rejection of waste heat underwater
substitutes the circulation of air for convection of heat from the chassis or housing to
the ambient environment. When the ambient environment is a vacuum, radiators are
deployed alongside active heat collection systems that reject waste heat into space. In
all of these conditions, the rejection of waste heat is dependent on the requirements
of the robot components, and the amount of heat rejected or rejection rate is not
considered. With the additional constraint of the environmental requirements, the
heat rejection system of the robot must incorporate components and controls that
provide sufficient component cooling, and govern the amount of heat rejected from
the robot.
Robots operating in cold environments typically control the temperature of their
electronics. For the robot to operate in a very cold environment, the on-board electronics must be heated to operating temperatures.
Typical electronics operate at
temperatures warmer than -40 'C, and electronics that operate in colder environments are either too costly for commercial use or still being researched.
[49]
[19]
Most of the prior work in heating electronics for this application is related to the
operation of robotic craft in space applications. The closest parallel to draw is to the
robotic rovers used in the Mars missions, which house their electronics in an insulated
warm electronics box. This WEB must also maintain the electronics below the upper
operating limits and incorporate methods for venting the.excess heat when necessary.
[35]
Liquid cooling designs
The use of fluid loops as a carrier for waste thermal energy
is currently employed in many existing systems. Computers and cars are two examples of everyday items that may use liquid cooling loops to maintain proper system
temperatures. These systems can be obtained commercially with numerous options
24
available. Most of the commercial offerings are not designed to work at freezing temperatures, however, and are not made of suitable materials for this application. [62]
2.2
Design Concept
The thermal management system proposed actively removes the generated waste heat
from the robot sub-systems and safely vents some of that energy into the ambient
environment.
The removal of waste heat in this situation requires additional sub-
systems in the robot compared to a typical robot. These sub-systems must maintain
the operational temperatures of the robot components and safely reject the excess
heat into the surrounding environment. These new systems require active controls to
optimize robot performance and maintain operational safety. The concept detailed
in this work is based on current commercial technologies for thermal management,
implemented for an LPG environment.
2.2.1
Restricted Waste Heat Rejection
Robots operating within thermally-constrained environments require additional special sub-systems for proper waste heat management. Figure 2-1 shows a comparison
of the general components in a typical robot and the components of a robot using the proposed thermal management system. This system incorporates a thermal
carrier that collects and transports components' waste heat to a thermal rejection device, which interfaces with the surrounding environment. Optionally, the system may
contain heaters that maintain components within operational temperatures, thermal storage devices that can absorb the waste heat instead of rejecting it to the
environment, thermo-electric (TE) conversion devices that convert the temperature
differential between two components of the thermal management system into usable
electric energy, and insulation covering the robot. All of these components may be
singular, plural, or distributed within the robot.
25
Typical Robot Components
Electronics
Power Supply
Actuators
Sensors
-
-
A
Proposed Robot Components
Thermal Rejection
(Thermal Storage
Actuators
Sensors
TE Conversion
Heaters
Thermal Insulation
B
Figure 2-1: Comparison of the components in a typical robot (A) and the proposed
system (B)
26
2.2.2
System Design Objectives
Operating in cold and hazardous environments also requires control of the temperature of the robot's electronics. In conjunction with the electrical heaters, the on-board
electronics create their own waste heat, reducing the load on the heaters once robot
operation is underway. Since this waste heat will be trapped within the insulated
WEB, a method of maintaining the electronics' temperatures is required to ensure
that operational temperatures are not exceeded. In order to safely reject the heat as
needed to the surrounding environment (comprised of LPG for this implementation)
a controllable device for venting will be incorporated in or on the robot. This heat
sink is fed the collected waste heat of the robot's electronics, sensors, and actuators.
The components are insulated against the ambient environment to prevent unsafe
heat loss.
Robots operating in cold and hazardous environments must not only control the
temperature of their electronics, but also the temperature of their external surfaces.
To prevent uncontrolled heat loss and reduce the amount of heating of the electronics
required, the interior of the WEB is insulated against the environment. The insulation
covering the proposed WEB, and the other electronics on the robot not housed in
the WEB, is based on silica aerogel, the same insulation used on the WEBs of the
Mars rovers.
[36] This insulation provides a very high thermal resistance versus
density ratio, compared with other commercially available insulations. In addition,
several commercial variants of silica-based aerogel insulation can be obtained in easilyinstalled sheets. [21] [48] [57]
2.2.3
Overview of the Thermal Management System
The thermal management system may contain multiple zones to obtain optimal system performance.
The system may have to maintain different robot sub-systems
at different maximum temperatures to satisfy the sub-system operating conditions.
Each of these zones contains an independent thermal carrier system, but may share
any of the other thermal management system components. Additionally, each of the
27
optional components of the system need not be incorporated into all zones.
Using multiple zones for components of different thermal requirements allows for
optimal tuning of the thermal management system. Allowing some sub-systems to
retain more heat reduces the amount of heat rejection necessary. Each of the zones
in the thermal management system may be controlled separately, with a supervisory
control that maintains communication with each zone and enforces the environmental constraints, or all zones may be controlled together. The control systems set and
maintain the thermal management system effort on the active sub-systems, and potentially reduce the robot sub-system operation levels below the commanded levels
to maintain acceptable thermal conditions. The supervisory controller uses a performance index based on the error between the robot component command levels and
actual operating levels, and the effort expended by the thermal management system
to maintain acceptable thermal conditions.
2.2.4
The Thermal Management System Used for Initial Analysis
The proposed thermal management system, analyzed as a feasibility study in this
chapter, considers only one zone in the system. The analyzed system was based
on the design of current liquid-coolers, but optimized for cold environments. This
thermal management system, shown in Fig. 2-2, spans the robots actuators, sensors,
and other electronics, and is designed to function in a similar manner to liquid-coolers
used in high-performance desktop computers. The primary difference between this
system and a commercial solution for a desktop computer is the use of materials that
are suited to the temperature range required in this application. Because this system
operates mainly within the freezing range of most standard liquid-cooling solutions, a
different type of fluid is required. After comparison of several potential heat-transfer
fluids that maintain liquidity to -50 0 C, Dynalene@HC-50 was chosen as the liquid for
use in the initial calculations. [23] Care was taken in choosing the pump and tubing
components for material compatibility with both the HC-50 and the cold environment.
28
heat sink /PCMV hybrid
TE device
fluid pump(s)
sensor(s)
system electronics
actuator with insulation covering
Figure 2-2: Layout of analyzed Thermal Management System
For weight and ease of installation, a polymer is chosen as the preferable material for
the tubing. Several polymers exhibit glass transition temperatures within the desired
range and are compatible with HC-50, such as ethylene propylene rubber. [1] [24]
If the robot's systems at full power consumption can produce more heat waste than
is safe to discharge at once, some heat must be absorbed. The heat sink attached to
the thermal management system may be designed to absorb some of the waste heat.
Thermal waste absorption can be accomplished via the inclusion of Phase-Change
Material (PCM) within the heat sink. As the energy from the thermal transfer fluid
is passed into the heat sink, the PCM will absorb the energy, and release a portion to
the heat sink fins. The preferential absorption of energy into the PCM is accomplished
via the internal interfaces between the PCM, the heat sink base, and the heat sink
fins. With this method, the rate of energy transfer to the ambient environment will
not exceed safety limits.
2.3
Analysis
The thermal analysis presented for the thermal management system is an initial
numerical assessment of one potential system to evaluate its suitability for full simulation. The system is constructed primarily of commercially-available components,
utilizing the thermal management system detailed in this paper. This initial study
is based on the power consumed by a typical actuator system and by the robot elec29
L
Tactuator
Ractuator mountmn
TCF
Rfluid bkok
bWW,
cold
lfluid block hot
t
THF R
~~~~powersupypoieenrytt actuator
T e
,
hc
heatsink
odcstehaTamb
hog
h
Figure 2-3: Thermal resistance model without PCM energy storage
tronics. Figure 2-3 shows a representation of a possible implementation of the robot
heat. The
components that are involved in the generation or transportation of waste
heat through the
power supply provides energy to the actuator, which conducts the
actuator mount to the fluid blocks of the thermal management system. The TE conversion device feeds electrical energy back to the power supply, and reduces the heat
load that is either stored or directly rejected to ambient.
A simple thermal-resistance model of the system was developed and analyzed.
the representation of
Figure 2-3 shows the thermal resistance model used overlaid on
the thermal management system proposed. The model analyzed considers only the
heat transfer from the actuator through the actuator mount and two heat-transfer
fluid blocks, which is released to the ambient environment via a finned heat sink,
with a TE conversion module placed between the second fluid block and the heat
sink. This model makes the following assumptions:
" The external ambient environment is at temperature Te.,t.
" The thermal properties of the thermal transfer fluid in the system are invariant.
" The thermal transfer fluid experiences no heat loss or gain within the system
except at the specific heat transfer blocks.
* The fluid pump does not require cooling.
" The properties of the TE module are constant.
30
e All system components have zero thermal capacity.
Additionally, the following conditions of the system were chosen:
" The robot actuators are motors generating waste heat.
" The heat sink is Lh, per side, cubed, with N fins of Nth thickness.
For this analysis, the ambient environment is chosen to be liquid propane maintained
at -45 'C with properties found in
[4],
and the thermal transfer fluid properties are
based on is Dynalene HC-50 fluid at -40 0 C. Additionally, the actuators are assumed
to generate 25W each, and the physical properties of the heat sink are as follows: Lh,
= 10 cm, N
2.3.1
10, and N
= 5 mm.
Actuator Heat Generation
The robot actuator considered in this analysis is a motor that would typically provide
power to the drivetrain. Though typical robots contain as least two of these actuators,
only a single motor was considered for this analysis for simplicity, with the energy generated by multiple motors addressed later. This type of actuator can generate waste
heat from both its electronics and the electrical resistance from the motor windings.
To avoid any potential sparks that could present a hazard in the working environment,
a brushless motor was chosen for use in the design of the robot. The motor chosen to
represent this typical drive motor is a Maxon electronically-commutated brushless DC
motor, number 283872. As indicated in [5], the normal operating ambient temperature range of this motor is between -40 and 100 0 C; therefore very little supplemental
heating will be required when operating within LPG, though significant heating will
be necessary to reach operating temperature when inspecting LNG tanks. The temperature of the single actuator is determined based on its power consumption, which
is determined from the torque generated, using calculations from [26]. The actuator's
temperature is calculated from the torque generated, which determines power draw.
The actuator's power consumption is calculated in Equ. (2.1) and used in Equ. (2.2)
31
to determine the actuator temperature:
P =
T2
2*
R
(2.1)
kt
(2.2)
Tmotor = P * Rth + Tmount
where P is the electric power dissipated by the motor,
T
is the motor torque, Re
is the electrical resistance of the motor windings, kt is the motor torque constant,
Rth
is the thermal resistance of the motor windings, and Tmotor and Tmount are the
motor and motor mount temperatures, respectively. The values of Re and kt are
temperature-dependent.
The heat generated from the actuator passes through the actuator mount, which is
connected thermally to a fluid block. The capacitance of the mount is not considered,
but the thermal resistance of the mount is modeled and added to the total system's
thermal resistance.
2.3.2
Thermal Transfer Fluid
The thermal transfer fluid carries the waste heat generated by the actuator to the
heat sink via the fluid blocks. After conduction of the heat through the actuator
mount, the heat is conducted through the fluid block and convected to the thermal
transfer fluid. The mass transport of the heat transfer fluid in this proposed system
is assumed to take place within insulated tubing, and as such, no heat transfer from
the fluid is calculated in-between the two fluid blocks.
At each fluid block (connected to the actuator mount and the TE module) the
heat convection to the thermal transfer fluid is calculated based on parameters for
forced flow within a square cross-section. This type of convection has a constant value
for the Nusselt number,
NUFB,
and the value of the heat transfer coefficient, hFB, is
calculated as
hFB-
NUFB * kFB
D(23
Dh
where Dh is the hydraulic diameter of the fluid block and kFB is the thermal conduc-
32
tion of the fluid. The Nusselt number used in Equ. (2.3) is a dimensionless parameter
that represents a ratio of the convective to conductive heat transfer at a surface based
on the Prandtl number (Pr), another dimensionless parameter, which is a ratio of
fluid momentum and thermal diffusivity. [30] The convection is then modeled as a
thermal resistance, which is counted in the system's total thermal resistance. [27]
2.3.3
Thermoelectric Conversion
The heat passing from the fluid block through the TE conversion module results in
electricity generation from the Seebeck effect, converting some of the waste heat back
into usable power. Equation (2.4) shows the power generation in the TE module as a
function of the temperature difference between the two sides of the device. Equation
(2.5) defines the temperature difference, relating it to the thermal resistance of the
TE module. [63]
I a2 AT 2
)
QTE = -( 'e
2 Reiec,total
AT =
(THF - THS) =
(in
-
(2.4)
(2.5)
QTE)RTE
In these equations, QTE is the rate of heat flow removed from the system by the
generation of electrical power in the TE module, ase is the Seebeck coefficient of the
TE module, AT is the temperature difference over the TE module, and
Qin is the rate
of heat flow entering the TE module. Reiec,total is the total electrical resistance of the
TE module (module electrical resistance plus load-with the load resistance taken as
equal to the module resistance). RTE is the thermal resistance of the TE module,
THF
is the hot fluid block temperature, and THS is the heat sink temperature. For
this analysis ase is set to 2.2*10-4 V/K, and Reiec,totai is chosen to be 2Q.
Equations (2.4) and (2.5) are solved iteratively with the equations in Section 2.3.4
to determine the value for QTE. The resulting power generated by the TE module,
equal to the power removed from the thermal circuit, is very small, 0.55 P W. This
small power output from the TE module is due to a calculated dT across the module
of only 6.8 'C. The calculated value of RTE is counted in the system's total thermal
resistance.
33
2.3.4
Thermal Rejection Convection
Thermal rejection in this system is performed by a finned heat sink. To simplify the
initial analysis, a thermal storage component is not included in the model. Thus, free
convection from a standard finned heat sink is modeled for the thermal rejection of
the system. To model the energy flow, the value of the heat transfer coefficient, h, for
free convection at the heat sink is calculated in Equ. (2.6). This calculation requires
determining Nu in Equ. (2.7), which in turn is solved from the calculation of the
Rayleigh number from fluid and system properties in Equ. (2.8).
The following is a list of the notation used in Equs. (2.6)-(2.8): oz is thermal
diffusivity of LPG, 3 is the volumetric expansion coefficient of LPG, V is the kinematic
viscosity of LPG, g is the acceleration due to gravity, k is the thermal conduction of
LPG, Pr is the Prandtl number, and T, is the surface temperature.
h=
Nu
=
Na * k
L
0.670Ra/ 4
0.68 +
Ra = g(Ts
-
(2.6)
0.492 )9/16)4/9
(2.7)
Text)L 3
(2.8)
The Rayleigh number, used in Equ. (2.7), is another dimensionless parameter. The
Rayleigh number is the ratio of the buoyancy and viscous forces in the fluid multiplied
by the Prandtl number. [28] Solving Equs. (2.6)-(2.8) for the free convection from
the heat sink to the liquid propane requires iterating though the value of T, for the
heat sink fins.
The thermal resistance of the heat sink, R, is calculated in Equ. (2.9), based on
the overall surface efficiency in Equ. (2.10). The fin surface efficiency used in Equ.
(2.10) is calculated in Equ. (2.11), based on the parameter m calculated in Equ.
(2.12), which is determined using the value of the heat transfer coefficient in Equ.
(2.6).
R
mo * h * At
34
(2.9)
ro=
NAf
At
(2.10)
*(1 -)f
tan m * L2.11)
m
m =
M
*c
h * Pf
h *Af
(2.12)
k * A,
The following is a list of the notation used in Equs. (2.9)-(2.12):
Ac is the cross-
sectional area of the fin, Af is the surface area of the fin, At is the total surface area
of the fin, L is the length of the fin, L, is the fin length plus half the fin thickness,
and Pf is the perimeter of the fin.
These equations thermally connect the cold side of the TE module to the ambient
(2.9), which is added to the
environment through the thermal resistance in Equ.
system's total thermal resistance.
2.3.5
Thermal Resistor Model Results
From the thermal resistance analysis, a final value for the temperature rise of the
actuator can be determined, in addition to the required thermal transfer fluid mass
flow. The analysis assumes that the amount of heat generated from the actuator,
minus the power recovered by the TE module, is safe to vent to the environment
and is completely rejected to ambient. The rejected heat can used with the total
system thermal resistance, RTotaI, to calculate the total temperature difference, ATyS,
between ambient and the actuator. The value of RTotal is obtained by summing each
component's thermal resistance, like that calculated by Equ. (2.9).
ATsys = (Tmotor - Text) = (Qgen
-
QTE)RTotal
(2.13)
The generation of waste heat by the operation of the actuator results in an actuator
temperature within operational limits. The temperature difference in Equ. (2.13) is
calculated to be 65 'C. The resulting actuator temperature of 20 0C is within the
actuators' operating temperature range.
[5] [29] [31] For the single actuator waste
heat elimination, the heat-transfer fluid will have to be pumped at a rate under 0.3
35
mL/s to maintain the heat transfer rate assumed. [23]
2.3.6
Total System Power Generation
The above analysis considers only a single source of heat generation, but robots will
have many sub-systems that all generate heat. The previous calculations assume that
the thermal management system can safely dispose of all the waste heat generated
by the system, otherwise, some energy must be stored for venting when the thermal outputs of the sub-systems are reduced, and capacity remains in the ambient
environment to absorb the stored energy.
The total robot power consumption is determined based on the following conditions for total energy production:
" Four actuators generating a total of 100 W waste heat, peak.
" PCM is paraffin technical grade 5913 (C13-24).
" The robot electronics (not including actuators and sensors) generate 13 W waste
heat, peak.
" The robot-mounted non-destructive testing sensor generates 33.6 W waste heat,
peak.
The electronics' waste heat generation is based on the waste power output of an
Intel® AtomTM D525 processor. [32] The sensor waste heat generation is based on
the power consumption of the Silverwing Handscan magnetic flux leakage sensor. [54]
The total generated power is calculated to be 146.6 W.
The thermal power capacity of the LPG environment is calculated and compared
to amount of thermal power generated by the system. To determine the amount power
the LPG can absorb without vaporizing, a mass of liquid propane corresponding to a
volume 1 mm thick, the width of the heat sink, and as long as the distance traveled by
the robot in 1 s (assumed to be 0.25 m) is considered as the heat absorbing medium.
Limiting the rise in LPG temperature by 4 'C, this mass can safely absorb 130.8
J (using the calculation Esafe = pV * (cpATLPG) for properties for LPG at -45 'C,
36
obtained from [41), while the robot's systems produce 146.6 J (based on the total
generated power of 146.6 W for 1 second). The difference of 15.8 J per second must
therefore be stored within the heat sink.
2.3.7
Thermal Storage Volume
In systems that generate more waste heat than can be safely absorbed by the environment, the excess energy must be stored on-board the robot. One method of storing
thermal energy is to utilize a PCM to absorb the energy, which requires a relatively
small volume of material versus using a single-phase material storage solution.
Based on the properties of solid paraffin (C13-24)
[151,
a heat sink with 10 cm
3
of
PCM could absorb the 15.8 J per second excess heat generation for 82.5 seconds before
it is completely melted. The energy stored by the PCM, denoted by E, is shown in
Equ. (2.14), where c is the heat capacity of the PCM, ATPcm is the temperature
difference between the PCM and the heat source, V is the volume of PCM, and A is
the latent heat of fusion of the PCM. [41]
E = pV * (cATPCM + A)
2.4
(2.14)
Discussion
A possible thermal management system for robots in temperature-restricted environments is detailed that utilizes thermally-conductive liquid to cool multiple robot
electronic components, and incorporates a control system to limit the thermal output
of the system. Initial calculations for an ambient environment of LPG, where the
thermal output must be regulated to ensure safe operation, show that the system
can be implemented with commercially-available components. This system is shown
to be able to maintain a single actuator at 20 'C within an ambient environment of
LPG with a required thermal fluid flow rate of only 0.3 mL/s. For four actuators,
some storage of the waste heat generated will be required to avoid an unsafe increase
in the LPG temperature. A heat sink with 10 cm 3 of solid paraffin was calculated
37
to be able to absorb the excess peak waste heat output of the robot for 82.5 seconds
before being completely melted. The next chapter will present a detailed model of
the proposed system.
38
Chapter 3
Modeling
This chapter details the construction and simulation for a detailed model of one
possible implementation of the proposed TMS. The modeling was performed in the
software package Dymola, which uses the Modelica language for multi-physics modeling, and simulates models numerically. The TMS system model was constructed
from standard, built-in component models whenever possible, but some of the TMS
components required custom models to represent the physics of the component. The
behavior of each component model and the system model was simulated with openloop inputs, and the models were verified to respond as expected. Open-loop simulations of representative inspection scenarios show that closed-loop control is required
to maintain all system states within operating limits.
3.1
Introduction
Background of Dymola and Modelica
Development of the modeling language
Modelica was first started in 1996 by Hilding Elmqvist, seeking to apply the principles
of object-oriented programming to modeling multi-physics systems. This concept allows for the drop-in re-use of models within a system, simplifying the user-generated
code. The first industrial use of Modelica occurred in 2000. In the same year, the
Modelica Association was founded.
[47]
Since then, the language has been devel-
oped and improved on, and currently is in version 3.2. [2] The language is released
39
open-source, and many different open-source and commercial programs exist that use
Modelica for modeling.
Native usage of Modelica is via text-based object-oriented programming, but the
language allows for annotations that define icons, which can be used in a graphical
interface. Additionally, the Modelica language does not assign causality during model
definition, but rather assigns relationships between states of different components.
These relationships are later assigned causality for numerical simulation at the time of
model compilation. Modelica describes the physics and interactions of the components
as sets of Differential Algebraic Equations (DAEs). The constitutive equations of all
objects are described in these DAEs, which are used to evaluate system state values
during the model compilation into assigned, causal code.
Dymola is a commercial program offered by Dassault Systemes, AB, that uses the
open-source Modelica language to model systems, and that provides several different
solvers to simulate those models.
In addition to the Modelica Standard Library
(MSL), which contains pre-constructed models of components for electrical, magnetic,
mechanical, and thermal-fluidic systems, as well as pre-defined mediums for use in
the thermal-fluidic systems, Dymola is compatible with any Modelica-based library.
Several open-source and commercial libraries exist for specialized modeling purposes,
such as the Modelon Liquid Cooling library used later in this work, which focuses
on the modeling of fluids to which heat is being added or subtracted, often in closed
loops. Additionally, Dymola offers the user a graphical interface for interacting with
Modelica, allowing a model to be constructed via the connection of icons representing
system components. In the definition of a model, system states need not be assigned
a strict start value for simulation. In the case of a linear system, these values are
calculated at the time of simulation, but for nonlinear systems, Dymola employs
an iterative method to determine the start values for the system states. In many
component models, these initial states can be constrained through the use of options.
This capability becomes very important in this work during the control of the TMS
model.
In constructing the model of the TMS, the acausal nature of the Modelica language
40
simplified the design of the model to a great extent. Specifically, for components such
as the TE module, determination of the driving side for heat flow was not required at
the time of model construction. This is compared to using causal modeling languages,
which would have required additional determinations of heat flow characteristics of
the system for model construction.
3.2
Modeling of the TMS components
The TMS component models were constructed largely from existing MSL models,
modified only by setting parameters and the connections between models to form a
sub-system. Several of the TMS components could not be realized by standard MSL
models however, and for these components custom models were constructed with the
appropriate physics. The Modelica definition of the models used in this work can be
found in Appendix A.
3.2.1
Component Construction
Five component models were created to assemble the TMS model.
These models
represent the system motors as the heat generators, which are connected to the fluid
blocks, allowing for heat transfer between the motors and the heat-transfer fluid. A
PCM block is modeled as the heat storage device, a TE module as the heat recovery
device, and there is a model of heat convection to ambient over a moving plate,
representing the heat release device. With the exception of the motors, each of these
main components required some sort of custom modeling.
Fluid blocks
This component model was designed to model the behavior of a
Priatherm PT Zed 1518 with Dynalene HC-50 flowing through it. [23] [8] To create
this model (and the fluid loop in the system), the HC-50 medium first had to be
defined in the Modelica language. Since HC-50 starts to phase transition into a vapor
at 118 'C
[17],
the medium was limited in scope and execution between -50 and 110
'C to ensure that the single-phase medium in the simulation would not represent the
41
thermal fluid when it is in a two-phase state. (It is also worth noting that the thermal
carrying capability of HC-50 drops significantly when it has become a vapor.)
10-
6
s
2
s
temperature (C)
flow (1pm)
Figure 3-1: Fluid block thermal resistance data-fit results
The second custom component of the fluid block model set the value of the thermal
resistance (Rth) of the fluid block from the liquid to the surface. This component
acted as a function of two variables, and output the Rth of the PT Zed 1518 based
on the medium temperature and volumetric flow rate. The function used to calculate
Rth was based on data from the PT Zed 1518 data sheet for the thermal resistance
of the block using a 50% volumetric mix of water and Ethylene Glycol at 40 0 C.
[8] From this
Rth versus volumetric flow data, a grid of Rth values over volumetric
flow and temperature was determined for HIC-5O using interpolations based on the
difference in properties between the two media and the change in medium properties
with temperature. This grid of Rth values was then imported into Matlab, where
a polynomial function was used to fit a surface over the data within the operating
points of the fluid. The resulting surface-fit function matches the calculated Rth data,
as shown in Fig. 3-1, with enough accuracy to use in the Modelica model of the fluid
block, representing the value of the thermal resistance of the fluid block from the
fluid to its surface. The plot shows that the thermal resistance of the fluid is highest
when there is low flow and the fluid temperature is high. This result aligns with the
expectation that increased fluid flow results in more heat being convected to the fluid
42
because of higher fluid velocities, and thus an increased convection coefficient.
portal
thermal conductance calculation
thermal mass of fluid block
temperatureSensor
degC
TA 0
volume flow meter
Figure 3-2: Fluid block model
The model of the fluid block, shown in Fig. 3-2, consists of a fluid pipe with heat
transfer to the convection model, where the Rth calculated is used to determine the
heat flow to a thermal port. This thermal port is where the fluid block connects
to another component model in the system. Finally, the thermal capacitance of the
aluminum wall of the fluid block is taken into account in the model with a capacitance
based on the mass of the block itself. Though some sources, such as [22], have
constructed fluid blocks for cooling electronics using element-based models similar to
the construction of the PCM block in Fig. 3-3, this simulation is more concerned
with the absolute temperature of the fluid in the block rather than the temperature
distribution, and thus this model uses only a single element for representing the flow
and heating of the fluid within the block.
Thermo-electric modules
The TE modules are modeled in Dymola using only
the constitutive equations for the thermo-electric generation, and no sub-models.
These equations calculate the heat flow across the module from equations based on
the generation of electricity within the module:
dQhoIt= Se * Thot * I + K * dT - 2
43
2
R,
(3.1)
dQcold= Se *Tol
1
2
I+K*dT+ - * I 2* Re
I = Se(Tot -TcId)
2Re
(3.2)
(3.3)
where K is the thermal conductance of each module half, Se is the Seebeck coefficient of the thermocouples, and I is the current across the TE module. dT is the
temperature difference across the module and Re is the electrical resistance of the TE
module, and the electrical resistance of the load on the module. [63] These equations
make the following two assumptions: the properties of the TE module are constant in
time, where typically the value of Se is dependent on temperature, and the electrical
resistance of the load is equal to the electrical resistance of the TE module itself, to
provide the most efficient power generation. Additionally, the thermal conductance
of the module is assumed to be a known constant. The properties for the TE module
used in this simulation come from the properties of the TE module simulated in [63].
Because the electrical supply of the robot in the TMS simulation is not modeled,
the power generated from the TE module is also not modeled, though the generated
current can be observed.
PCM block
The construction of the PCM block, the thermal storage in the system,
is most complex of the TMS component constructions. The PCM block is modeled as
a two-dimensional array of PCM masses enclosed in an aluminum case, with aluminum
fins spaced between the masses to act as heat spreaders. The model is shown in Fig.
3-3. Three types of PCM mass models were constructed for the component, for each
of the center, edges, and corners of the block. All three of these models have the core
PCM mass in common, which is a modified version of the MSL thermal capacitance.
The PCM capacitance has a variable value dependent on the temperature of the mass
in order to emulate the effects of the latent heat of melting for the PCM. Previous
work in [20] has shown that using an arc tangent function to represent the heat
capacity of the PCM allows for a series expansion calculation of the value of the
thermal capacitance, which yields accurate and computationally quick results. Other
options, such as using programmatic if statements, require a greater computational
44
port~b
PCM unit
PCMunit mass
I
0-
I-
k-PCM-m/9
I
A
M
-
A
-A T
7T
I
0-I-
k~LfhO
thicnes
I I
7~~i
I
-
I
.1.
II
i
A,
A
I
imm~
i
I
heat
spreader fin
I---
7,I
k=tick
pofla
I
i
Figure 3-3: Dymola model of PCM block
load without increased accuracy. The thermal capacitance of the PCM mass is thus
modeled as:
Ci(((T -
htransitin
Ttransition)CMR)2 + 1)
+ C
(3.4)
(
where c, is the effective heat capacity, htransition is the latent heat of melting, T is
current PCM mass temperature,
Transition is
the temperature of melting, CMR is the
melting range coefficient, used to adjust the width of the melting range, and cp* is
the sensible heat of the PCM. The temperatures are assumed to be in Kelvin. The
thermal capacitance is surrounded by standard thermal resistance blocks to mimic
45
the heat flow of a mass of PCM with a two-dimensional area. The edge and corner
models add thermal masses and resistances of the aluminum case sides to the PCM
block. All these components are assembled into the PCM block with the spreader
fins attached to the input edge of the block, extending throughout the array of PCM
masses.
This is the only sub-system modeled in discrete elements, rather than a lumped
element, though the mesh of the model is coarse. The choice to use nine discrete
PCM masses, rather than one mass, comes from the high thermal resistance of the
PCM. Although PCM makes a good thermal sink, it is a poor thermal conductor, and
a model of a single element very poorly represents the thermal distribution within
an area of PCM. [41] Initial models without the heat spreader fins showed almost no
temperature rise in the PCM masses along the top of the block, near the output. All
the heat was trapped in the first layer of PCM masses, and was not being spread out
throughout the block. Localizing the incoming energy to a small portion of the PCM
effectively negated the benefit of having any PCM above the first layer. This led to
the introduction of the spreader fins, to better distribute the heat coming into the
block and to take advantage of the full mass of the PCM.
The total mass of the PCM block used in this implementation of the TMS was
determined a-priori through calculation based on the desired component size (10 cm 3 )
and the density of the solid PCM. Dymola testing of the TMS confirmed that this
mass was sufficient for the energy-absorption needs of the system.
External convection model
The thermal rejection component of the TMS has
been identified previously as a finned heat sink, but for this component model it was
constructed as a heat sink consisting of a flat plate only. The fins of the typical heat
sink were not included for two reasons: to reduce computational complexity of the
model and to reduce the overall amount of heat energy convected to the system.
The use of a flat plate as the convection surface simplified the convection equations
to a forced flow over a plate, with the magnitude of the velocity of the stream equal
to the speed of the robot. Given this input, and assuming constant properties for the
46
ambient environment of LPG at -45 'C, the convection equations used to determine
the heat flow became:
Z
Nu
A
P * cp
(3.5a)
Re = vel * L
(3.5b)
Pr
(3.5c)
-
0.664Re1 /2Pr'/3
h=
L
gc = h * A
(3.5d)
(3.5e)
(3.5f)
where a is the thermal diffusivity of the LPG, A is the thermal conductivity of the
LPG, p is the LPG density, vel is the velocity of the robot in the LPG, L is the
length of the heat sink, and A is the area of the heat sink. The Dymola-specific term,
gc, is the thermal conductance of convection, in W/K. [30] The resulting thermal
flow is connected to a Modelon Liquid Cooling Library fluid system that models the
effect of LPG passing over the plate. This LPG is assumed to come from an ideal
-45 'C source and is passed back into the ambient at whatever temperature it has
reached. Modeling the heat flow to the fluid medium is done with a model of a fixed
fluid volume. The parameters of the volume have been chosen to align closely with
the actual heated surface of the flat plate, assuming an actively heated volume of 1
mm of LPG is in contact with the plate. The fixed volume models the fluid inside
as a lumped mass, mixing the incoming fluid properties with the properties of the
medium already contained in the volume, and expelling the appropriate amount of
fluid to maintain the pressure and volume of the medium inside the fixed fluid volume
component. The layout of the external convection model can be seen in Appendix A.
Heater model
The heater component model replicates the effects of a self-controlled
electrical resistance heater. This component senses the temperature of the port to
which is it connected, and either turns on or shuts off its resistance heater based on
47
a backward hysteresis of the temperature. The backward hysteresis component was
modified from the MSL hysteresis model to reverse the logic direction, turning on
the heater when the temperature drops below a minimum value and off when the
temperature rises above a maximum value. The power for the heater is a built-in
ideal power source, for which the amount of power consumed is a variable set at the
start of a simulation. The code for the backward hysteresis and heater models can
be found in Appendix A.
Motor unit
The detailed models available in Modelica of brushless DC motors are
highly complex and require significant computation time to simulate a simple input.
Efforts to construct a simplified model of a brushless motor either did not contain
the detail necessary to properly represent the motor or were again highly complex
and computationally demanding. To keep the model complexity down and maintain
a reasonable simulation time, the brushless DC motor was replaced in the simulation
by a standard, brushed, DC motor, also from Maxon, part 218012
[7].
In the motor
model, components other than the armature or core are assumed to not contribute
to the thermal generation of the motor, and frictional losses are not considered.
This motor was combined with a rotating mass to represent the load inertia and
with a quadratic resistive force on the shaft to represent the resulting forces resisting
the motion of the motor. The motor set was combined with a fluid block and thermal
masses to represent a complete motor unit, which consisted of the motor mounted to
a fluid block with a representative load. The code for the motor unit can be found in
Appendix A.
3.2.2
Component Verification Testing
The component models that were constructed required testing to ensure that the
components and sub-systems would simulate the intended behavior, especially the
components constructed from custom models.
48
Fluid blocks
The behavior of the fluid blocks was tested using a closed fluid loop
with a heat input. Variation in the fluid flow and input heat flow was used to confirm
that the heat transfer to the fluid was properly influenced by these variables. Testing
confirmed the expected behavior of the model. Figure 3-4 shows the results of the
verification test. As expected, the thermal resistance of the fluid (B) decreases with
an increase in the fluid flow (C), and increases as the fluid increases in temperature.
The decrease in the temperature plot (A) occurs because the increased flow of the
fluid starts to circulate un-heated fluid past the temperature sensor. Once the fluid
has made a complete loop within the closed circuit, the temperature increases again.
The model for this test can be found in Appendix B.
-
Fluid Temperature
105-
100A
95-
900
-
100
30
200
400
0
000
Thermal Resistance
45.
40-
B
3s.
30-
25~
0
-
10
20
300
400
000
60
0
Fluid Volume Flow
2.0t.o-
C
0.5-
0
40
3
200
4
50
time (s)
Figure 3- 4: Fluid block verification test results
49
0
60
ramp
drabonI
TE mdulei
fixedTemperature
prescribedHeatFlow
T-233
S
Figure 3-5: TE module verification test model
Thermo-electric module
In this simulation model, the TE module dissipates
some of the heat flux entering the module into electrical energy, and passes the remainder through to the other side of the module. The amount of this dissipation
depends only the temperature difference between the two sides of the module. The
verification test fixed the temperature on one side of the module and varied the heat
flux on the other, as shown in Fig. 3-5. This test configuration was chosen to illustrate the behavior of the TE module under an imposed heat flux on one side, which
could be experienced when attached to a fluid block, and a fixed temperature on the
other side, which could be experienced when attached to a motor unit. The electrical
generation of the module increased with increasing heat flux, as expected. Figure 3-6
shows the results of the test, with the electrical current generated in (A), the temperature difference across the TE module in (B), and the heat flow in and out of the
module in red and green, respectively, in (C). Figure 3-6(D) shows the temperatures
of the two sides of the TE module.
PCM block
The PCM block is a numerically-complex thermal capacitor model
with variable capacitance based on the current temperature of the block. Accordingly,
the temperature along one edge of the block was set to a value greater than the melting
point, and simulated over an extended time span (the thermal time constant of the
block is very long because the PCM has a low thermal conductivity, despite the heat
spreader fins). The resulting PCM mass temperatures showed the expected shape
in time, increasing in temperature until the melting point is reached, flat until the
50
-
TE module electrical current generated
A
2550
75
100
75
100
Temperature difference across the module
-
40
0
--
prescribed
Q flow
0
-
so
25
port A
Q flow
TE module port
50
25
port B temp
--
75
8 Q flow
10
0
TE module thermal port A temperature
-
-36-
D
_34-39-
0
25
time (s) so
7s
100
Figure 3-6: TE module verification test results
mass has melted, and then increasing in temperature again. Figure 3-7(A) shows
the average temperature of the nine PCM masses in the block, (B) shows the heat
flow into the block from the perspective of the block and the temperature boundary,
and (C) shows the variation in heat capacity of one of the PCM masses in the block.
Figure 3-7(C) clearly shows the increased thermal capacity of the PCM during the
melting phase, corresponding with the flat portion of the temperature plot in (A). The
rapid leveling-off of the heat flow into the PCM block seen in (B) can be attributed
to the large difference in the starting temperatures of the PCM block and the fixed
temperature. As the PCM warms up, melts, and starts to reach the same temperature
as the set value, the heat flow between the two models decreases. The model for this
51
test can be found in Appendix B.
PCM block average
-
temperature
A
-
I
-
Qflow of PCM block
C
Qflowoffixed temp
Q
masheat capacitance
5
EE
OM
4.
25
im4)SSE
2 i,
time
(s)
'4
55
3
x
SS
4
%
Figure 3-7: PCM block verification test results
External convection model
The rate of heat flow in the external convection block
depends on two inputs: the robot speed and the temperature of the convection plate.
Each of these two inputs was varied independently to show that the convection heat
flow and the fluid temperature respond correctly to the variation in the inputs. Figure
3-8 shows the results of the test. In (A) the heat flow of the model is shown, the
values of which correspond to the fluctuating values of the LPG temperature shown
in (B). Figure 3-8(C) shows that the convection thermal conductance increases with
increasing robot velocity, as expected, and explains the initial dynamics seen in (A)
and (B), when the test had not yet reached the steady-state velocity. The model for
this verification test can be found in Appendix B.
Heater model
The verification test model for the heater varied the temperature of
a thermal mass connected to the heater above and below the on-off set points for the
heater, causing the connected heater to turn on and off as the mass drops and rises
in temperature, as intended. The results of the test are shown in Fig. 3-9, where (A)
52
external cony tem.convection.Qflow
40
20 -
-20 -
0
-
20
60
40
so
100
externaLconv.temp.tMpertureSenorT
-44.8-
B
\
-45,2-
0
-
20
qxternLconvteMpgC
60
40
-
80
100
exttrn*l cnv.ntm.v*4 [m/s]
C
0
20
40
time
(s)
60
80
100
Figure 3-8: External convection verification test results
shows the temperatures of the variable temperature boundary and the thermal mass,
(B) shows the the heat flux from the heater (the negative value indicates that the
heat flow is leaving the heater), and (C) shows the logical switch state for the heater.
The model for this verification test can be found in Appendix B.
3.3
System Model
With all of the TMS component models constructed and tested, the TMS system
model was assembled. This model combined all of the components into a TMS similar
to the one outlined in the preliminary analysis, but with four heat generators and the
heat storage taken into account as well.
53
-
resareeoeratut*7T
te*CspactorT
-30-
A
-50-
10
0
-
20
30
40
50
60
70
80
90
50
60
70
80
90
100
coPheaterHeat_oUtQflow
0-
-10-
0
10
2
30
100
C
20
10
30
40time
(s)
6
7
9
Figure 3-9: Heater verification test results
3.3.1
Assembly
The system model was constructed from the components discussed and from other
basic component models contained in the MSL or other Modelica libraries. Because
the detailed electrical circuits of the robot were not modeled as part of this simulation,
the heat generated from the robot electronics was modeled instead as an ideal heat
flux source, with the output based on the total power consumption of the electronics
of the
(as determined in the previous chapter), and an assumed 75% overall efficiency
electronics. The layout of the system model can be seen in Fig. 3-10.
Several results from the component verification tests informed the assembly of the
system model. Initial system testing showed that the temperature difference across
the TE modules was not large enough to produce significant electrical current during
normal operation, so the modules were placed at every fluid block to maximize the
amount of energy reclaimed. As the TE module model has a low computational load,
this did not represent an increase in numerical complexity to the system.
Some of the system assembly was dictated by the needs and limitations of the
Modelica modeling environment. Because the thermal fluid used in the closed loop is
54
...
......
.
-.....
.....
...........
......
..
............
....
........
.........
....
. ....
...
................
-"
daKkearR2T
eadSensor
t
ezpaeionAie"e
b~lb-
extT
PCM block
I
fluifT
oso
Motor unit
mtrT
Electronic heat
generator
uid block
Fl
TE mnodule
I
L
spd
Heater
Figure 3-10: TMS system model layout
incompressible, an expansion volume, consisting of an enclosed tank with some of the
volume occupied by compressible gas, was required to prevent numerical issues when
the fluid increased in temperature. Additionally, because the flow of the fluid is set
by the pump model, certain parameters in the component models required settings
to make it clear to the solver that the mass flow is the independent variable, not
the pressure drop across a pipe. Finally, the inclusion of the fluid loop resulted in
a nonlinear set of equations for the system constraints. This led to the use of the
Dymola solver Radau II, which is a stiff solver, to improve simulation time. [9] [14]
[61]
The pump model used is a simplified concept that acts as an ideal fluid mover,
without imparting any heat energy to the fluid. This represents a small loss of fidelity
55
to the model of the fluid temperature, but greatly simplifies the complexity of the
fluid-loop model. If included, a model of a real pump would require analysis of the
pressure drop across the pump. It was decided that this detail was not necessary, as
the pressure in the fluid system is not a focus of this simulation.
It is also important to note that the construction of the overall system model does
not take into account the internal robot environment. All system components are
considered insulated from the robot chassis cavity and free to transfer heat only to
and from other TMS components. This insulation is not modeled in this simulation;
however, the aerogel insulation previously discussed should be effective enough that
the perfect insulation of this model approximates the interior of the robot with the
insulation installed. This additionally means that a model of the interior of the robot
is not required, including insulation of the robot chassis to the ambient environment.
3.3.2
Analysis
The verification testing on the components was extended to the full system model, and
simple input simulations were performed to confirm that the ensemble of components
would respond as expected. Though the numerical results are somewhat different
than those previously calculated in Chapter 2, the results indicate that the system
model is behaving as expected and desired.
One item of note was that the PCM block was extremely slow to respond to the
heat output of the system. Though it absorbed much of the generated energy and
did not release much to the ambient, the temperature rise in the PCM block did not
reach the 8 0 C needed to initiate melting in nearly all of the simulations performed.
Increased simulation time or improved conduction of the heat through the PCM
block would be necessary to initiate melting during the simulations. Additionally,
simulation diagnostics indicated that the component models within the PCM block
were among the most computationally demanding. This result is important in the
next chapter, when the block is removed from the system model for the sake of
computational simplification.
In order to confirm that the TMS was having a positive effect in reducing the com56
ponent temperatures, open-loop system simulations were run that varied the steadystate value of the fluid volume flow.
This series of simulations clearly show that
increased fluid flow results in a longer acceptable run time for the motors. This is
the desired result, as it clearly indicates that the liquid cooling concept of the TMS
is effective at reducing the temperature of the heat generators. Not surprisingly, increased fluid flow also results in increased heat rejection from the system, as more of
the heat generated is made available to the heat sink via increased transport. Figure
3-11(A) shows the resulting motor temperature, (B) the fluid temperature, and (C)
the external ambient temperature of the system for simulation flow levels of 3 (blue),
7 (red), and 11 (green) 1pm.
Although the simulations indicate that the TMS concept is effective at cooling
the components of the robot, because the heat is not released at the same rate as it
is generated (and because the PCM is extremely slow to absorb the heat), the motor
components do eventually overheat during simulations of longer, four-hour, inspection
scenarios, as seen in Fig. 3-12(A). Merely running the fluid pump at the highest level
is not sufficient to maintain motor temperatures within the acceptable operating
range (between -40 and 150'C). [7] It is apparent that the closed-loop control concept
discussed in Chapter 2 is necessary for this system to maintain proper robot operation.
It is important to note that at no point in these simulations did the LPG reach unsafe
temperatures (greater than or equal to -42
0
C).
With a closed-loop control clearly necessary, step-input testing with long time
spans was performed to determine the thermal time constant of the system in order
to properly tune the controller. The heat flow from the motors was determined to
have a time constant of approximately 3,000 seconds. Although other components of
the system have longer time constants, this was taken as the overall system thermal
time constant of interest for the closed-loop control.
Knowing that the system would have to be simulated in a MATLAB/Simulink
environment for closed-loop control, additional testing was performed in Simulink to
confirm that the two software environments would return the same numerical results.
For this purpose, a simplified model was constructed and simulated in both Dymola
57
n*T-3o
-
-
tTjmwi
Motor temperature
n*T11m
f0fl.
500-
A
300-
s m -.. ....
....
- ,
0.0E0
I
20E3
-- ovr_3vm
--
I
*
8.0E3
6.0E3
4.0E3
12E4
14E4
1.6E4
I
1.8 E4
w1riinom Fluid temperature
-
_rjx
1.0E4
an.0
40L)
B
0-
-40i
0.0E0
exT_3pm
-
8.0E3
6.0E3
4.0E3
2.0(3
extrjm --
ewxr
10E4
1. 2E4
14E4
1.6E4
1A
E4
LPG temperature
om
-44.85-
.44.90-
C
~~T44.95-
-45.0045.050.0 E0
nameI
2.0E3
*
I
4.0(3
*
I
8.0E3
*
I
8.03
10E4
1.2E4
1.4E4
16E4
1 8E4
time (s)
Figure 3-11: System responses for three levels of fluid flow
and Simulink under the same input conditions. Comparison of the results show that
the differences between the two software simulations are very small, and are likely
due to minor numerical differences between the simulations and solvers. The models
used in this testing and the plots of the results can be found in Appendix B.2. To
export the model to Simulink, the model was modified in Dymola to include top-level
inputs and outputs for the system. This model was translated into a Model-Exchange
Functional Mockup Unit (ME-FMU) file. [46]. The Model-Exchange standard used
in this comparison exports the model without the solver, so the Simulink simulations
58
fluid temperature
external temperature
--
velocity
motor temperature
120 -
40A
0__
-40
01E0
20E3
6013
4.0E3
80E3
1
0E4
1,24
14E4
20-
B
01
O
Z0E6
6. 3
416
&,
3
fluidflow
11 4
4
1.0E4
1 24
1 4E4
1,0
0.0--0.0E0
velocity reference
203
--4013
measured
6.01
velocity
time (s)
8013
1414
Figure 3-12: Dymola results to a trapezoidal velocity input
were run with the built-in ode 15s solver (also stiff) and a variable time-step. The use
of the two different solvers was likely the reason for the minor numerical differences
between the simulations. Although the FMU standard includes a Co-Simulation type
(CS-FMU) that exports the solver with the model, Simulink does not support variable
time-steps with this exported solver, so only a fixed time-step simulation could be
performed using a CS-FMU file export. Unfortunately, this meant that the simulation
run-time was prohibitively long (on the order of days) when using a proper time step
for simulation.
3.4
Discussion
Through modeling and simulation, the concept TMS proposed has proven successful
in a full four-motor model of the system. However, the implementation of the TMS
59
hardware is not sufficient to maintain acceptable component operation beyond three
and a half hours, and a closed-loop control must be created around the hardware to
monitor system levels and maintain safe operation for longer periods of time.
60
Chapter 4
Control
Having reached the conclusion in the previous chapter that a closed-loop control
method is necessary for the TMS to maintain proper robot operation for the extendedtime scenario, the model was prepared for import into Simulink, so that the expanded
control capabilities of MATLAB could be used to implement the controller. A control
loop was constructed so the nearly four-hour scenario could be performed without
violating any of the operating constraints of the robot or the environment.
4.1
4.1.1
Introduction
Background
Choice of control method
Model Predictive Control (MPC) is a method of control that utilizes a built-in descriptive model of a system to predict the behavior of the system to the optimized
control commands. These predictions are used to refine the optimization, anticipating
future system responses. In addition, MPC incorporates the ability to set constraints
on the input and output values in the calculation of the control commands.
This
feature was a major reason for the choice of using an MPC to control the TMS, because of the physical limitations on some of the system states. The ability to predict
the system outputs over a window of time and apply control to avoid violating the
61
constraints, even in the future, is an important factor to maintaining safe system
operation without incurring large changes in the control commands.
There are other optimal solution control methods available that incorporate bounds
on the system states, such as MATLAB's bvp4c or fmincon, but these methods require knowledge of the constitutive equations for the system. [10] [12] Although a
detailed model of the TMS exists, the descriptive equations of the system are not
transparent from the model, and these methods could not be used without some sort
of system identification into constitutive equations.
MPC also requires some knowledge of the system, in the form of a state-space
model. General MPC methods are capable of using nonlinear models to predict the
optimal control commands, but because the system's equations of state are unknown,
a method must be employed to determine the system model for use with the MPC
on-line with the control. 1 Therefore, the input and output data from the system is fed
into a system identification algorithm that produces a reduced-state, linearized, model
of the system for use as the controller model. This concept of on-line linearization and
control is implemented in MATLAB using the system identification function n4sid
and the functions of the MPC toolbox.
Model Predictive Control
The Model Predictive Control Toolbox in MATLAB solves an optimization problem for determining the next control commands in a manner similar to the Linear
Quadratic Gaussian (LQG) optimal control method, but with constraints on the values of the inputs and outputs, and with the control optimization performed over a
finite window of time.
The MATLAB MPC uses linear state-space models for state estimation to calculate the error between the system output reference values and the predicted system
response to the input. The goal of the control is to determine the control commands to
'Input/output only control methods do exist, such as Extremum Seeking detailed in [39], but
these methods require some signal superimposed on the inputs to identify the response of the outputs
with respect to the inputs. For the highly coupled TMS, the identification of the effect of this
superimposed signal on each output would be an arduous task, and is not necessary with MPC
available.
62
minimize these errors using a weighted penalty function, along with weighted penalties for output motion magnitude. The system model can include unmeasured inputs
and outputs, as well as measured disturbances on top of the measured inputs and
outputs. For the model used in this controller, the disturbances were assumed to be
zero, as none were included in the Modelica model.
The optimization problem is solved as a minimization of the weighted penalty
function, which sums the squares of the output errors and the change in the control
command:
min{Zwglj(y(k
+
i=O
where
()j
is the
wA j(k + 1k)}
+ Ilk) -rj(k + Z 1))2+
(4.1)
j=1
j
component of the vector, and (k+iIk) is the predicted value at time
k + i. The system outputs are y, the output references are r, and the system inputs
(the control commands) are u. The weights on the inputs and outputs in the function
are designated by w, and p is the prediction horizon of the MPC. This problem is
solved over the range of the predictive window of p steps, obtaining m number of
optimized control solutions for each sampling step, where m < p. However, only
the first control solution, the one for the current sampling step, is retained.
The
next solution recalculates the states of the system over p and the optimized control
inputs over m. If the model does not contain disturbances, white noise is added to
the measured outputs to guarantee asymptotic rejection of output disturbances. The
state observed is then constructed using Kalman filtering methods on the extended
model with the unmeasured white noise disturbances.
With constraints, the optimal control solution is obtained using Quadratic Programming (QP) methods.
The solution is calculated by solving the cost function
augmented with the constraints. The cost function is derived from the penalty function in Equ. (4.1). The function is converted to the general QP form, and solved using
a KWIK algorithm, specifically QPKWIK detailed in [53]. For a detailed explanation
of the MPC implementation in MATLAB, the reader is referred to Chapter 2 of [18].
63
Linearization with n4sid
The Numerical algorithms for Subspace State Space System Identification (N4SID)
method was primarily introduced by Peter Van Overschee and Bart De Moor, and
it makes use of QR and Singular Value Decomposition (SVD) to estimate a linear,
time-invariant state-space system from a series of input and output data. The method
requires knowledge of the system order, though that value can be determined during
the calculations. Subspace methods are non-iterative, estimating the system parameters from the solution of a linear least-squares equation.
However, despite the name, the MATLAB System Identification Toolbox command n4sid uses either the Multivariable Output-Error State Space (MOESP) or
Canonical Variate Analysis (CVA) weighting methods for solving the SVD. [42] Both
of these weighting methods are also subspace identification methods based on the
work in
[59]
and [40], respectively. In the n4sid implementation used, either of these
methods is automatically chosen by the function at execution. Both of these algorithms produce a state-space model of the form:
i(t) = Ax(t) + Bu(t) + Ke(t)
y(t) = Cx(t) + Du(t) + e(t)
(4.2)
where e is the noise in the model. [11] For identification of the TMS system, the
noise matrix K has been set to a zero value, since there is no noise introduced in the
system model.
The n4sid function returns more than a single state-space model of the identified
system. The output of the function also returns information about the estimation performed, including information on the input and output data used in the linearization,
which is used by MATLAB in constructing the MPC controller.
64
4.2
4.2.1
Design
Closed-Loop Control Construction
Using a multi-input multi-output (MIMO) nonlinear model in Simulink for control
purposes would have meant that some of the closed-loop control functions available in
Simulink could not be used. The desired control method, MPC, is one of the control
functions available in Simulink that is limited to linear system models, which cannot
be modified on-line during the simulation. To handle nonlinear systems, the Simulink
function includes the capability to linearize the system model about an operating
point.
However, the TMS nonlinear system runs over a large range of operating
points during the simulation, so a single linearized model about one operating point
would not accurately represent the system for use in an MPC control. For systems
with multiple operating points, Simulink offers an MPC that can incorporate many
linearized models, and switches between them as necessary. Developing a full set
of linearized models for the TMS system about all possible operating points would
require an impractical number of linearized models for the combinations of input and
output states, however. It was for this reason that on-line linearization of the system
was chosen as the method of implementing an MPC using the tools in MATLAB.
In order to execute the n4sid system identification function to obtain the linearized model for MPC execution, the input and output data of the simulation had
to be generated for a window of time. The ideal time window implementation for
linearization is a sliding window, where the linear plant is re-calculated and the MPC
optimization problem is solved for each simulation step. However, no method was
found to access the data from an actively running Simulink simulation and place it
in the MATLAB workspace. Therefore, the simulation had to complete before the
linearization and control movement could be calculated. A sliding time window can
be achieved by running the simulation one step at a time and saving the results in a
cycling memory, but the computational overhead and memory requirements of initiating the simulation for each step of the simulation prohibited this method from being
65
used.2 Instead, a jumping time window was used, where the simulation was run for a
set amount of time, and then the linear system was calculated for the resulting data
and used to compute the control movement for the next time window. Figure 4-1(A)
shows the sliding time window concept, where the results of multiple simulations are
used for system identification, and (B) the jumping time window concept, where only
one simulation result is used for system identification. In this figure, each vertical
black line represents a simulation step, where many small simulations are performed
by the sliding time window concept, and fewer, longer simulations are performed by
the jumping time window concept. Each of the double-sided arrows represents a system linearization and control calculation. By choosing the correct time window for
the jumping method, the linearized system used in the MPC is a good enough approximation of the system for the next time window. One drawback to this jumping
time window method is that as the MPC calculates the control commands for the
next time window, the linearized system becomes less and less accurate when the
current time of the controller calculation becomes farther from the end time of the
last simulation window. Reducing the size of the time window decreases this error,
but it also decreases the total simulation length possible due to computer memory
constraints.
The MATLAB example presented in [13] executes an MPC control for a nonlinear
system using the sliding time method, but linearizes the plant about an operating
point rather than using input/output data. This method of linearization is accurate
as long as the simulation time is small, so that the expected change in the system will
not greatly exceed the magnitude of the perturbation about the operating point used
by the linearization method. However, when using a simulation iteration time that
is large enough, the expected system output will deviate greatly from the operating
point, requiring the use of a linearization that can predict the system behavior over
a wider set of the responses with greater accuracy, such as the input/output-based
linearization. Because the Simulink model of the plant uses an exported FMU block,
When initializing many iterations, MATLAB exhausts the available computer memory because
the exported FMU file is executed from a .dll file.
2
66
I
sliding time window for linearization and control calculation
simulation results
time
jumping time window for linearization and control calculation
simulation results
time
Figure 4-1: Illustrations of two time window implementations
the typical methods of retrieving data from Simulink could not be used. Instead, the
functions from the FMI toolbox were used to retrieve and set the system states for
iteration. This method required a listing of the continuous states of the model, which
was obtained from the translation output of Dymola when building the fmu file.
4.2.2
Model Modification for Control
To prepare the Dymola model for closed-loop control in MATLAB, some modifications
were necessary to set system state start values, and remove some of the computational
complexity of the model to reduce the simulation time.
In order to properly re-
initialize the model for each simulation iteration, a number of start parameters had
to be inserted into the model so that the components would start at the correct
temperatures when the simulation initialized at a non-zero time. In the process of
67
inserting these parameters, the PCM block was removed from the model in order
to reduce the computational cost of system simulation. Open-loop simulation of the
system with and without the PCM block shows that the heat flow from the system
to the ambient is greater without the PCM block (see Fig. 4-2), indicating that
the system without the PCM block included is a more strenuous test for the ambient
environment, but more forgiving on the system components. It is important note that
FB.out.Q_flow.PCM
FBoutW-flow
0-2-4-
-12
0.0E6
4.OE3
8.OE3
time (s)
1.2E4
1.6E4
Figure 4-2: Comparison of the heat flow from the system to the PCM block (blue),
or convected to the ambient environment (red)
it was at this point that the fluid loop in the model was modified from using MSL
components to the Modelon Liquid Cooling Library components. This changeover
was necessary because the complexity of the MSL fluid components prevented proper
initialization of the medium with each iteration. These components had the additional
benefit of reducing the number and size of the nonlinear systems in the compiled
simulation.
4.2.3
Input and Output Choices
The system control inputs were limited to the two components that have externally
controllable attributes: the motor speed demand and the fluid pump volume flow
demand. These two inputs were matched with four outputs, which were chosen based
68
on their impact on the desired system behavior. The actual velocity of the robot (as
measured from the motor speeds) was one of the outputs chosen so that the motor
speed demand could be controlled in a closed-loop manner, maintaining the desired
velocity during operation. The motor, fluid, and external temperatures were also chosen as outputs. The motor and fluid temperature outputs allow the control system
to ensure that the operating limits of the components are not violated, keeping the
system running smoothly without damaging the components. The external temperature output allows the control to monitor the state of the ambient environment and
shut down the heat production if necessary to maintain safe operation.
The measurement of motor speed, motor temperature, and fluid temperature could
take place at multiple points in the system, but only one point of each was sampled
as the output value. Each of the four motors runs at a different temperature, and
consequently, speed. This variation in temperature occurs because the motors are
connected in series to the thermal fluid, and the downstream motors experience a
reduced cooling effect from the increased temperature of the thermal fluid as it passes
by each motor. For the motor speed, the shaft speed of the motor from the third
motor unit was used to represent the system speed. This particular motor unit was
chosen as representative because it runs at a temperature and speed in the middle of
the four-motor set, and proper positioning of the motors and fluid loop in the robot
will allow the cooler, faster motors to offset the warmer, slower motors for a resultant
robot speed of roughly the average of the four motor speeds, which is close the speed
of the third motor. The motor temperature output was measured from the fourth
motor, which is the motor running at the highest temperature. This choice was made
to ensure that none of the motors exceed the maximum operating temperature. The
same logic was used to choose the measurement location for the fluid temperature.
The fluid temperature output is measured at the electronics fluid block, since that
block is furthest downstream in the fluid loop, and has the highest fluid temperature
measured within the loop.
69
4.2.4
Choice of Linearized States
The MATLAB function n4sid requires an input of the number of states in the identified linear system. Although the nonlinear system is known to have 34 continuous
system states in the model (not to be confused the number of physical states in the
model, which may be dependent on other state values), MATLAB has difficulty processing that many states in both the system identification algorithm and the MPC
functions. Several different sets of input/output data were processed with the linearization algorithm to determine the best-fit linearized system for different numbers
of states. The resulting linear output predictions were compared against the nonlinear data, and it was found that 10 system states best fit the output data for most of
the data sets.
4.2.5
MPC Setup
The MPC used in MATLAB is set up with static constraints and weights for every
simulation. Each simulation iteration has a unique linear plant that the MPC is based
around, and updated reference values for the system outputs. Both the inputs and
outputs are constrained, but with varying weights on the constraint violation penalty
values. The pump input is constrained to 11.98 1pm, in order to not violate the 12 1pm
limit in the model's computation of the fluid block thermal resistance. The velocity
demand is limited to 0.6 m/s in order to prevent the system from sending a command
that would result in the robot traveling too fast for the scanner to properly operate,
and therefore potentially miss a defect. Though the scanner's operating limit is 0.5
m/s, the demand limit is set higher to take into account the speed loss of the motors
as they heat up, so that the system can still achieve 0.5 m/s if requested.
The output limits are also based on physical constraints of the system.
The
velocity output is limited to 0.5 m/s, again so that the control will prevent the robot
from traveling above the maximum scanner operating speed. The motor, fluid, and
external temperature limits are all set based on the component limits. The motor's
operating temperatures, the fluid's liquid temperature range, and the boiling point
70
of LPG are used as constraints on those outputs, with some modifications to provide
a factor of safety on each limit. Some of these limits, such as the LPG boiling point,
are assigned hard constraints, so that the control will not violate those limits for
any reason. Other limits, such as the velocity, have softer constraints that allow the
control more freedom to momentarily exceed those limits in order to provide the best
control performance.
Choice of the system time window and sampling rate
Based on the results of the system's thermal time constant from the Dymola simulations, the length of the simulation iteration (designated tau) was set to 300 seconds,
or one-tenth the thermal time constant. This value proved not to be compatible with
the four-hour simulation time due to computer memory limits, so the value of tau
was modified to 375 seconds. This value is one-eighth of the thermal time constant,
so under-sampling of the thermal responses should not occur when creating the linear
fit of the system behavior. Using a time window this long means that the linearized
system used by the MPC to predict system responses can be off-point during the
calculation of the control commands, particularly when calculating the control for
the time points furthest from the end of the last iteration.
The maximum simulation time step used by the variable solver in Simulink is set to
1 second in order to correspond with the chosen MPC time step, and to prevent undersampling of the control command. Using the 1 second time step resulted in a more
accurate MPC control command than using the default for the maximum simulation
time step. Though this control sampling rate is much larger than the mechanical
time constant of the motor (4.15 ms) [7], there is no concern for lost motor dynamics
in the output measurement or control, because precision motor speed control is not
necessary for this system as the relatively large inertial masses will damp out small
motor variations, and high precision speed or position control is not necessary or
desired in this application.
71
Tuning
To best illustrate the efficacy of the MPC when following a given velocity reference
and maintaining the system constraints, a trapezoidal velocity reference input was
constructed and used to tune the controller. In the course of tuning, it was discovered
that the nonlinear system is highly coupled, and changes to one tuning value tended
to produce a change in the entire system response.
During tuning of the MPC, it was found that the initial input data, used for the
first simulation iteration when there is no input/output data from which to generate
a linear system, had a large effect on the response of the first MPC control movement.
This effect is expected from the control method. In the case where the first responses
of the system dictate the model used for prediction, the response of the control will
be highly dependent on providing the right data for the system identification tool.
Similarly, the reference values for the temperatures had a very large impact on
the efficacy of the MPC in following the velocity reference. Though the values of
the temperatures in-between the operating limits are not a concern from a control
standpoint, the MPC implementation within MATLAB does not return stable results when the weights for the output values are reduced to zero. Subsequently, the
temperature outputs were given small, non-zero MPC weights in comparison to the
velocity output. However, it was found that assigning small weights was not enough,
and the temperature references needed to be shaped properly in order to prevent
unwanted velocity motions. Both the external temperature and fluid temperature
outputs approximate a linear rise during the simulation, so linear reference values
were developed for those outputs, and found to be acceptable. Figure 4-3 shows the
velocity error, measured value, and reference for a simulation where the motor temperature reference was poorly fit to the natural response of the motor. The initial
velocity demand (green) is calculated to be much higher than desired, because the
motor temperature value is well below its reference value, resulting in the measured
velocity overshoot between 375 and 500 seconds.
Using a constant or linear value for the motor reference resulted in large mo72
tor temperature output errors, which interfered with the velocity reference following.
These errors were of large enough magnitude, compared to the velocity reference error, that the weights in the controller could not be tuned high enough for the velocity
or low enough for the motor temperature to maintain proper velocity reference tracking without causing numerical instabilities in the control. The motor temperature
naturally follows a more non-linear shape, so effort was made to fit an s-curve to the
natural motor temperature response. After tuning the motor temperature reference
using a hyperbolic tangent function, the motor temperature results in a low error
value for that output throughout the simulation, reducing its interference with the
velocity reference tracking.
0.6
024..
. .. .
-0.6 ..
...
7
................
. ... ...
- 0 .2 ..
.... ..
....
....
.....vel
.....
.................
..
error
output Val
ref vel
0
1000
2000
3000
4000
5000
Simulation time (s)
6000
7000
900
Figure 4-3: Simulation velocity results with poorly-shaped output reference values
This control method can be incorporated into a hardware system without having to
construct a detailed model of the system equations beforehand. However, significant
effort is required in tuning the controller, as new velocity and temperature profiles
require changes to optimize the system response. Therefore, using this control method
shifts the effort from constructing an accurate model of the hardware to tuning the
controller for the specific hardware and output references.
73
4.3
4.3.1
Analysis
Controller Testing
To confirm the long-term efficacy of the control, tests were run based on the same
trapezoidal velocity reference input used for tuning the MPC, but for a longer simulation time. Using the Dymola model to determine that the motor operating temperature is exceeded for a simulation time of 14,000 seconds when using the trapezoidal
input (see Fig. 4-4), the same test profile was used in MATLAB testing.
10-
-
1s0-
U0
fluid temperature
external temperature
velocity
motor temperature
40
0__
-40
hOEe FEg 2.0st
4d
6, 34
3
1TmE4
4
1sam
I
wE4
time (s)
Figure 4-4: Dymola motor temperature results to a trapezoidal velocity input
During one of the tuning tests it was noticed that when the velocity of the robot
reaches zero, the temperature of the external environment starts to rise, as seen in
the last seconds of Fig. 4-5. This plot comes from the same simulation shown in Fig.
4-3, where near-zero velocity can be observed for the final 400 seconds. That zero or
near-zero robot velocity results in a rise in the external temperature is an important
fact: once there is no fluid flow over the external convection heat sink plate, the
temperature of the now-static external fluid will start to rise, even though there is
no longer any active heat generation. Convection still occurs to the fluid from the
hot heat sink plate, because the temperatures inside the robot are still significantly
warmer than the external environment. This informs an inspection path requirement
limiting the robot from slowing significantly or stopping for any length of time, except
74
.. .........
......................
.............
.
.. ..........
. -
at the point when and where it is to be retrieved from the tank at the end of the
inspection. However, the original velocity profile ending with zero velocity continued
to be used for the purpose of testing the control system, in order to observe the
response of the control to rising external temperatures.
fluid T ( C)
20
-----
-
-
extemalT(C)
0
0
1000
200030
4000
6000
6000
7000
8000
9C000
Simulation time (s)
Figure 4-5: Example of simulation output results with poorly-shaped references
4.3.2
Tuning Simulations
A series of shorter simulations was used to tune the response of the controller to
determine the best weights and output reference shapes to obtain the best system
response. These short runs used the same velocity reference shape as the final simulations, but with a shorter run time of 9,000 seconds, and keeping the time window
size of 375 seconds. During these simulations, the control weights, prediction window,
and constraint relaxation values were tuned to achieve the best performance of the
controller. The initial, open-loop, system inputs, used during the first iteration of the
simulation, were also tuned to achieve the best possible system linearization for the
controller, for use in the subsequent iteration.
The control weights were chosen based on the expected error of the output value
to the reference and the desired impact of this error on the control command. The
75
weights on the constraints, which ordered the importance of the constraints within the
controller, were set based on the importance of those constraints to the safe operation
of the system. The external temperature constraint weight was set to be the most
important, followed by the motor temperature. The velocity constraint and the fluid
constraint were set to lower levels of importance, as these constraints do not prevent
the robot from safely operating within the ambient environment.
During tuning, it was found that the size of the control window cannot exceed
a small portion of the size of the prediction window. Tests indicated that the control window was best set at roughly 1/10 the length of the prediction window, in
order to avoid numeric problems with constructing the Kalman filter for the control.
Additionally, the predication window could not exceed the length of the simulation
time window in order to avoid similar numeric problems. The final results for the
prediction window size was 200 steps, and the control horizon was set to 20 steps.
4.4
Results
When simulating the full-length scenarios, the reference temperature shapes had to
be re-tuned from the shorter simulations to match the changed natural response of
the motor temperature when run at 90% speed for a longer time. The results from the
open-loop simulations in Dymola provided some knowledge of the expected temperature shape, but additional tuning was necessary to achieve the desired closed-loop
performance. The hyperbolic tangent function for the motor temperature reference
was refined so that the reference value would closely match the temperature response
when the velocity reference was closely followed by the controller.
The final reference shape and weight combination yielded a controller response
that successfully matched the velocity reference to within 11% during the constant
velocity reference of the scenario. The error was greater during the dynamic velocity
reference, but the error did not exceeded 0.1 m/s, except at the end of the test, a
response that is explained later. Most importantly, the controller maintained the
system constraints and never exceeded 150 'C for the motor temperature, or -42 0 C
76
.........
.....
..
.............
..........
........
......
.1..
..........
.
for the external temperature. As expected, the system input calculated by the control
quickly maximizes the pump fluid flow, and only minor variations in the pump demand
are seen afterward. The main method of temperature control used by the MPC is
the velocity demand on the motors. As illustrated in Fig. 4-6, at 12,000 seconds
into the simulation the velocity demand starts to decrease in response to rising motor
temperature, preventing an overheating of the motors like that seen in Fig. 4-4. Plots
of the control commands calculated by the MPC, the MPC predictions for the outputs,
and the reference values can be seen in Appendix D. To confirm that the linearization
0.5
04
-0.1
---.-
- __------- _
vet error
-- -output
- -ref
0.
200
400
00
val
vet
0
Simulation time
1000
1200
1400
100
(s)
Figure 4-6: Closed-loop velocity results
and control concept was working properly, the linearized system output values were
plotted as dashed lines, overlaid on the solid lines of the measured output values.
The resulting plot, shown in Fig. 4-7, shows that the system linearization method is
quite effective at generating linear approximations of the system outputs. A detailed
plot of the motor temperature output values, shown in Fig. 4-8, indicates that small
variations in the linearized output (dashed line) exist versus the measured output
(solid line), but the difference in the temperature values do not impede the controller
performance. A closer look at the linearized (dashed) versus measured (solid) velocity
77
-
...
..
..............
- _ .... . ........................
.........
.....
---------------------
values in Fig. 4-9 indicates a number of numerical peaks in the linearized velocity
values. Inspection of these peaks reveals that they occur at the start of iteration time
windows, indicating that the linearization of the velocity tends to incur numerical
faults over the first few data points. Nonetheless, these variations do not have a large
effect on the control commands made by the MPC.
150
velocity (m/s)
4
motor T (C)
-
110
-lin
10
-
velocity
---
-
inmotor T
lin uid T
in external T
10 S 10
-...
-..
-
-o
-
o
940
-
-10
-
-----
-20
(I 110]
213]
3XU
4ID)
510)
SI0t
70)0
Simulation time ()
S
90U
ilil]
0l
110)
121l
l3X
1410
15111
Figure 4-7: Closed-loop output results comparison: measured vs. linearized
As previously mentioned, the trapezoidal velocity reference used in these tests
commands zero speed for the robot at the end of the simulation. This situation
has already been shown to result in an unsafe increase in the temperature of the
ambient environment. However, in this simulation the controller did not allow the
external temperature to violate its constraint, and increased the velocity demand on
the robot to maintain safe operation. Figures 4-10 and 4-11 show the velocity (plotted
with velocity error in blue, measured velocity in green, and the velocity reference in
red) and external temperature at the end of the simulation, respectively.
As the
external temperature rises and starts to reach unsafe levels, the controller deviates
from the desired velocity in order to lower the external temperature and avoid an
unsafe condition.
78
.................
............
101
. .
--
C 1005 - >
4
100 -
-
-.-..
-
---
--
-
--
-
-
-
-
-
--
---
95 si..
97 .......... .....
...............
1.359
1.36
1.361
1.362
1.363
1.364
1365
1366
Simulation lime (s)X10
th
TM S
m otor T
n motor T
..--.----
rder.t.......w
he sy te...ant..sf..eat
.....
1.367
..
1368
.....
..
.
1.369
o .. her
bo
it
Figure 4-8: Closed-loop motor temperature comparison: measured vs. linearized
4.5
i
Discussion
A closed-loop control method was designed, tuned, and implemented to work with
the TMS in order to allow the system to maintain safe operation of the robot within
the ambient environment for mission lengths longer than would be possible with
open-loop control. The control method was two part: linear plant identification from
input/output data, and control command calculation. The plant identification was
performed using subspace methods built into MATLAB, which was then used by the
MATLAB MPC functions. Each of these built-in functions required inputs that were
tuned for the best system response of the controller.
The tuning process of the linearization and controller was performed by observation and correction of initial a-priori settings. It was found that the initial input
shape had a large effect on the first MPC control command, and much effort was
placed into determining the correct initial input for the pump. Additionally, though
the system constraints demand only that the temperatures of the motor, fluid, or
external environment conform to a set of upper and lower bounds, the references
for each of these outputs needed to be properly shaped in order to ensure that the
controller output resulted in the desired system response.
79
.....
..
.................
.......
.I."
.....
..............
.
. .............
.
2
OCK
elocity
..........-
..........
y
1.5
- -.
-.
...
.......
......
..
-.
..
....
-. ...
..-..
...-.
S
0
0
- .-.
- ...
-.
0.5
-. -...-.-.-.-.
..
-..
..-.
.--.-- .- .-..
-0.5
-1
A00
20D
140
12000
80f 10000
6
16U0
Simulation time (s)
Figure 4-9: Closed-loop velocity comparison: measured vs. linearized
0.25
----
- -- '--
-
-
- -_--- -- _- -
--.....
.......
-.....-.-..-.--.....
0.2
- -.
....
0.15
-......
..
0.1
-.
-
.....
-.
-0.05
-
..
...
...-..-. .
-
...
-.
. . ..
-......-...
-....
- ..-.-..
-.-..
-.
...7 -..
-.
-. ...
...
-.
..... ..-.
-. ..
- ......
.. -.
- -.
-- ..-.
--..
-.
*...........-
-
0.05
0
....
vet error
vel
vel
- -output
-_--ref
.. -
..
... ....
. -.
....
-0.1
1.3
1.32
1.3
1.34
Simulation time (s)
138
1.4
1.42
x 10
Figure 4-10: Velocity results for the end of the simulation
80
......................
.....
........
....
..
...........
. . ...
................
.
-4U
e -43 . .........
.......
.................
............ ......
........
........................
.......
... ........
-4 2 . ... ..
..........
.......... ...... ....
.........
....
..
-4 1 - ***....
...............
..........
V
CL
E -4 4 ..
.....
....... ...
.................
................
. .....
E -45
.......
...........
.............
..
ul
47
-48
........ ...
.......
46 ............
........ ........
.........
1.3
1.32
....... ...................
...... ......
......
....................
...........
1.36
Simulation time (s)
134
.........
1.38
1.4
...... -
1.42
Xle
Figure 4-11: External temperature results for the end of the simulation
81
82
Chapter 5
Conclusions and Recommendations
5.1
Summary
In this work a thermal management system was proposed for use with robots that
operate in temperature-restricted environments. This TMS is designed to allow the
robot to maintain the temperatures of its components within operating limits, while
avoiding excessive heat rejection to the ambient environment, which could cause unsafe conditions. The proposed system was designed with the robotic inspection of
LPG and LNG holding tanks in mind, though the system could be used in any other
situation where uncontrolled waste heat rejection is undesirable or unsafe. Robotic
inspection of LPG and LNG tanks is an extension of current robotic inspection technology, but the robots must be adapted to safely work within the cooled, liquefied
gas. The gas cannot be heated above its vaporization temperature without causing
unsafe conditions within the tanks, so current inspection protocol requires removing
the gas from the tank and taking the tank out of service during inspection.
The
period during which the tank is out of operation is very costly in lost productivity.
In-service tank inspection would represent a significant savings over standard inspection methods.
However, some form of thermal management system is required in
order to allow robots to operate safely within the operational holding tanks.
The TMS design is comprised of several sub-systems that remove the waste heat
generated by the robot's components and then convert that heat energy to electrical
83
energy, store some of the heat energy, and reject the remainder to the ambient environment. Each of these systems may have multiple instances in a specific design
of a TMS, or may be left out entirely. One potential implementation of the TMS
was discussed in detail. This implementation uses a thermal fluid to transport the
waste energy from the robot's components to thermo-electric modules that convert
some of the energy into usable electricity. The remaining heat energy is then routed
through a PCM block, which absorbs much of the thermal energy as the material
inside increases in temperature, a'nd eventually melts. The remaining heat energy is
rejected to the ambient environment through a heat sink.
This system was first analyzed as a thermal circuit, with an ambient environment of LPG. This analysis showed that commercially-available products could be
used to construct this implementation of the TMS, with the exception of the PCM
block. (The PCM block as imagined in the TMS would require custom construction, but the materials for this component are commercially available.)
Based on
the success of the initial analysis, a detailed model of the TMS implementation described was constructed in the Modelica modeling language. This model incorporated
all of the potential TMS components. Each of the components was constructed in
Modelica from basic models provided in the standard library when available, but several components required custom models to represent less-common physics, such as
the thermo-electric modules. The component models were tested to ensure that the
simulated model behavior agreed with the expected behavior of the components.
The detailed model of the full system was simulated with open-loop control of
the motor speed and the thermal fluid pump speed. As expected, increased motor
demand resulted in increased heat generation, and increased fluid flow decreased
the temperature of the motors. However, at 90% motor speed, the TMS could not
maintain the motor temperatures below their operating maximum for longer than
roughly three and a half hours, even at maximum fluid flow. It was therefore decided
that the closed-loop controller was necessary for the TMS to allow safe operation of
the robot performing a tank inspection within an LPG environment.
A control scheme for closed-loop control was proposed and implemented in MAT84
LAB using the TMS model from Modelica as the simulated system. A model predictive controller was chosen for its ability to incorporate constraints on both the
control commands and the system output values. However, no direct formulation of
the nonlinear system model was available for use in the MPC, so the input/output
data from the simulation of the system was used to construct a reduced, linear statespace model of the system with the MATLAB system identification function, n4sid.
Using a jumping time-window method to simulate a portion of the total time, the
linearized system was determined from the results of each simulation window. That
linear system was then used to calculate the control commands for the next simulation window. Though small time windows are preferred to reduce the error inherent
in the linearized model versus the nonlinear model as the system progresses further
away from the linearization points, computer memory limitations prevented the implemented simulation from using time windows smaller than approximately 2-3% of
the total simulation time.
The system outputs tracked by the MPC were chosen to be the motor velocity,
the motor temperature, the thermal fluid temperature, and the external ambient
temperature. In this system, the output of the motor velocity represents part of the
desired performance of the control system, the motor and fluid temperatures represent
component constraints, and the external ambient temperature represents the safety
constraint for operation of the robot. For this implementation, only the limits on the
values of the constraints were considered critical to the operation of the controller, and
therefore initially little thought was given to the reference values for these outputs.
Only the motor velocity tracking error was assigned a high importance. However, it
was found during simulation of the controller that despite the low importance assigned
to the constraint output tracking errors, these errors had a significant impact on the
velocity response of the system, degrading the performance. Therefore, more care was
given to the shaping of all the reference values, particularly for the motor temperature,
to improve the controller performance. The resulting temperature reference inputs
closely follow the natural response of the temperature outputs in order to obtain
the desired velocity reference.
The final closed-loop control response successfully
85
maintains the robot components and the ambient environment temperatures within
their constraints for a time longer than three and a half hours at 90% motor speed.
5.2
Future Work
Future work on further developing this TMS and control system should focus on
improving the control implementation, creating more detailed system simulations,
and testing the system hardware. Though the final control implementation provides
acceptable system performance, and enforces the component constraints and ambient
environment safety requirements, significant effort was required to tune the controller
to achieve the demonstrated level of performance. The system output reference values
had to be carefully tuned to align with the natural behavior of those outputs for
the desired velocity profile in order to obtain good tracking to that velocity profile.
Adapting the MPC used in the control such that some of the tracked system outputs
do not require reference values would greatly improve the usability and portability
of the control over multiple hardware implementations. Additionally, any further
system simulation should occur on a computer with improved memory capacity so
that the time window of the simulations can be reduced (this would require that more
memory be allocated to running MATLAB specifically, rather than just an expanded
memory capacity of the computer).
Additional simulations should be constructed with models that include the interior
air of the robot as a component, to determine the impact of the robot chassis cavity of
the performance of the TMS. These models could also include the chassis insulation,
and add the effect of the convection from the rest of the robot chassis to the ambient
environment.
Finally, the system should be tested with hardware under realistic, refrigerated
conditions to confirm the performance of the TMS. This testing, even if done as a
scaled test, will require significant resources to maintain the cold ambient environment, unless such tests are performed in a naturally cold location.
86
Appendix A
Modelica Code and Graphical
Models
The Modelica code used to simulate the TMS is presented here, along with the graphical representations of the code in Dymola. The Modelica code for the annotations
that define the graphics has been removed for legibility of the code.
A.1
System Model
87
idealGearR2T
ralo=15000.5
mxtw
speedsensor
fextT
exMv~cff*
14000
heat sink
plate
M
seV-0~
t
thermal
capacitor
fluidT
jUM
mtrT
Fluid block
dur
>e0s1
W
spd
TE module I
cLa,+rr~ni,~c tkcrn,2I
capacitor
Heater
c 0t(
Figure A-1: The Dymola graphical model of the TMS system used in the control
simulations, without the PCM block. A thermal mass is substituted in place of the
PCM block to represent the mass of the heat sink plate.
88
"I'll,
..........................
..............
.
-
I'll, ...........
.
. ......
.....
model System-model-final-Sim6F "System model with 4 generators"
parameter Modelica.SIunits.Temperature sCPcE=228.15;
parameter Modelica.SIunits.Temperature sCPpTE=228.15;
parameter Modelica.SIunits.Temperature sCPcO=228.15;
parameter Modelica.SIunits.Temperature sCPpTO=228.15;
parameter Modelica.SIunits.Temperature sMcpcl=228.15;
parameter Modelica.SIunits.Temperature sMcptl=228.15;
parameter Modelica.SIunits.Temperature sMcl=228.15;
parameter Modelica.SIunits.Temperature sMdccl=228.15;
parameter Modelica.SIunits.Temperature sMdcal=228.15;
parameter Modelica.Slunits.AngularVelocity sMdcwl=O;
parameter Modelica.SIunits.Angle sMdcpl=O;
parameter Modelica. SIunits . Current sMlail=O;
parameter Modelica.SIunits.Temperature sMcpc2=228.15;
parameter Modelica.SIunits.Temperature sMcpt2=228.15;
parameter Modelica.SIunits.Temperature sMc2=228.15;
parameter Modelica.SIunits.Temperature sMdcc2=228.15;
parameter Modelica.SIunits.Temperature sMdca2=228.15;
parameter Modelica.SIunits.AngularVelocity sMdcw2=0;
parameter Modelica.SIunits.Angle sMdcp2=0;
parameter Modelica. SIunits .Current sMlai2=0;
parameter Modelica.SIunits.Temperature sMcpc3=228.15;
parameter Modelica.SIunits.Temperature sMcpt3=228.15;
parameter Modelica.SIunits.Temperature sMc3=228.15;
parameter Modelica.SIunits.Temperature sMdcc3=228.15;
parameter Modelica. SIunits . Temperature sMdca3=228 .15;
parameter Modelica. SIunits .AngularVelocity sMdcw3=0;
parameter Modelica.SIunits .Angle sMdcp3=0;
parameter Modelica . SIunits . Current sMlai3=0;
parameter Modelica.SIunits.Temperature sMcpc4=228.15;
parameter Modelica.SIunits.Temperature sMcpt4=228.15;
parameter Modelica.SIunits.Temperature sMc4=228 .15;
parameter Modelica.SIunits.Temperature sMdcc4=228.15;
parameter Modelica.SIunits.Temperature sMdca4=228.15;
parameter Modelica.SIunits.AngularVelocity sMdcw4=0;
89
parameter Modelica.SIunits.Angle sMdcp4=0;
parameter Modelica.SIunits.Current sMlai4=0;
parameter Modelica.SIunits.Temperature sExtT=228.15;
parameter Modelica.SIunits.Temperature sExpT=228.15;
parameter Modelica.SIunits.Pressure sExpP=101300;
parameter Modelica.SIunits.Volume sExpV=0.0005/2;
parameter Modelica.SIunits.Temperature sElCap=228.15;
parameter Modelica.SIunits.Temperature sExtCap=228.15;
External-conv-temp3aLC
external-conv
L=0 .10,
A=0 . 10 2,
redeclare package medium = BasicModels.LPG,
lamda=0 .1312,
rho=584.55,
cp=2237.5,
nue=3. 493e-7,
boil-pt=231.15,
sExtT=sExtT)
CP-scratch3F
;
cP-scratch-out
sCPc=sCPcO,
sCPpT=sCPpTO,
redeclare package medium
=
LC-HC50)
;
Modelica.Blocks.Math.Gain lpm_2-m3ps(k=1/60000) ;
Modelica.Blocks.Math.Gain mtr-volts (k=48)
TE-hack2
tE-hack2-out
Se=2 .2e-4,
Re=2,
t.cond=3. 663,
startT=sCPcO);
CP-scratch3F cP-scratch-elc
sCPc=sCPcE,
sCPpT=sCPpTE,
redeclare package medium = LC-HC50) ;
90
.....................
Modelica.Thermal.HeatTransfer.Sources.PrescribedHeatFlow
prescribedHeatFlow-elc (Tref=233.15)
Comp-heater
;
comp-heater-elc
T-lo=-40,
Heater-Pwr=5,
T-hi=-38)
;
Modelica.Thermal.HeatTransfer.Components.ThermalConductor
Eleccond(G=61.558);
Modelica.Thermal.HeatTransfer.Components.HeatCapacitor
ElecCap(C=896*0.5, T(
fixed=false, start=sElCap))
Modelica.Blocks.Sources.Ramp elect-input (height=46.6, duration=1);
TE-hack2 tE-hack2-elc
Se=2 .2e-4,
Re=2,
t-cond=3. 663,
startT=sCPpTE);
Motor-unitBF motor-unitAl
sMcpc=sMcpc1,
sMcpt=sMcptl,
sMc=sMc1,
sMdcc=sMdcc1,
sMdca=sMdcal,
sMdcw=sMdcwl,
sMdcp=sMdcpl,
sMlai=sMlail)
Motor-unitBF motor-unitA2
sMcpc=sMcpc2,
sMcpt=sMcpt2,
sMc=sMc2,
sMdcc=sMdcc2,
sMdca=sMdca2,
sMdcw=sMdcw2,
sMdcp=sMdcp2,
91
................
........
sMlai=sMlai2) ;
Motor-unitBF motor-unitA3
sMcpc=sMcpc3,
sMcpt=sMcpt3,
sMc=sMc3,
sMdcc=sMdcc3,
sMdca=sMdca3,
sMdcw=sMdcw3,
sMdcp=sMdcp3,
sMlai=sMlai3)
Motor-unitBF motor-unitA4
sMcpc=sMcpc4,
sMcpt=sMcpt4,
sMc=sMc4,
sMdcc=sMdcc4,
sMdca=sMdca4,
sMdcw=sMdcw4,
sMdcp=sMdcp4,
sMlai=sMlai4)
Modelica.Blocks.Interfaces.RealInput pump ;
Modelica.Blocks.Interfaces.RealOutput fluidT ;
Modelica.Blocks.Interfaces.RealOutput mtrT ;
Modelica.Blocks.Interfaces.RealInput vDem(min=0, max=1)
"Input signal connector"
Modelica.Blocks.Interfaces.RealOutput extT
Modelica.Blocks.Math.Gain elc-eff(k=l -
0.75) ;
LiquidCooling.Volumes .ExpansionVolume expansionVolume(
N=2,
redeclare package Medium = BasicModels.LC-HC50,
k-ht=l 0,
steadyState=false,
V(displayUnit="ml") = 0.0005,
V-gas-start=sExpV,
T-start=sExpT,
p-start=sExpP) ;
LiquidCooling.FlowModifiers.SetLiquidFlowRate
92
...
..............
...........
.........................................
.... I........
. ........
..
.........
...................
........
........
.......
........
.....I - -
setFlowRate (useflow-in=true,
redeclare package Medium = BasicModels.LC-HC50
;
Modelon.ThermoFluid.Sensors.DensitySensor
densitySensor (redeclare package
Medium = BasicModels.LC-HC50)
;
Modelica.Blocks.Math.Product productl ;
LiquidCooling.Pipes.Generic.LiquidPipe pipe(
L=1,
A=0. 005,
redeclare model Friction
=
Modelon.ThermoFluid.FlowChannels.
PipeResistances.DetailedWallFriction,
useHeatTransfer=false,
from-dp=false,
redeclare package Medium = BasicModels.LC-HC50,
T-start=sExpT);
LiquidCooling.Pipes.Generic.LiquidPipe pipel(
A=0
.005,
redeclare model Friction
=
Modelon . ThermoFluid. FlowChannels.
PipeResistances.DetailedWallFriction,
useHeatTransfer=false,
f rom-dp=false,
L= 0.5,
T-start=sCPpTE,
redeclare package Medium = BasicModels.LC-HC50)
;
Modelica.Blocks . Interfaces .RealOutput spd ;
Modelica.Mechanics.Translational.Components.IdealGearR2T
idealGearR2T (ratio=150
/0.5)
;
Modelica .Mechanics . Translational. Sensors . SpeedSens.or
speedSensor ;
Modelica.Blocks.Math.Gain vdem2pct (k=2) ;
Modelica. Thermal . HeatTransfer . Components . HeatCapacitor
93
..............
. ...............
plate(C=896*0.135, T(
fixed=false, start=sExtCap))
equation
connect(ElecCap.port, comp-heater-elc.T-in) ;
;
connect(ElecCap.port, comp-heater-elc.Heat-out)
connect (Elec-cond.port-a,
prescribedHeatFlow-elc.port)
cP-scratch-elc.port-al)
connect(tE-hack2_elc.port-b,
connect (Elec-cond.port-b,
connect (mtr-volts.y,
;
ElecCap.port)
connect (prescribedHeatF1ow-elc.port,
tE-hack2-elc.port-a)
;
motor-unitAl.u);
connect (motor-unitA2.u,
mtr-volts.y);
connect (motor-unitA3.u,
mtr-volts.y);
connect (motor-unitA4 .u, mtr-volts.y) ;
connect (cP-scratch-out.port-al,
fluidT
tE-hack2-out.port-a) ;
= cP-scratch-elc.temperatureSensor.T;
mtrT = motor-unitA4 .dC-Motor-system.armature. T;
connect(pump,
lpm_2-m3ps.u)
connect (externalhconv.amb-t,
;
extT)
;
;
connect (elc-eff.u,
elect-input.y)
connect (elc-eff.y,
prescribedHeatFlow-elc.Q-flow)
initial equation
ElecCap.T = sElCap;
cP-scratch-elc.heatCapPTZ1518.T
= sCPcE;
cP-scratch-out.heatCapPTZ1518.T
= sCPcO;
motor-unitAl.cEP-scratch.heatCapPTZ1518.T
motor-unitAl .MotorMountCap.T
= sMcpcl;
= sMcl;
mot or-unitAl .dCMotor-system. core. T = sMdccl;
motor-unitAl .dC-Motor-system.armature.T
= sMdcal;
motor-unitAl .dC-Motor-system.dcpm.ia.i = sMlail;
motor-unitA2.cP-scratch.heatCapPTZ1518.T
motor-unitA2.MotorMountCap.T
= sMcpc2;
= sMc2;
motor-unitA2 .dCMotor-system.core.T = sMdcc2;
94
;
;
...
.. ...
.....
....
.....
.....
..
.....
mot or-unitA2 .dCJMot or-sy stem. armature. T = sMdca2;
motor-unitA2 . dC-Mot or-sy stem. dcpm. la. i = sMlai2;
= sMcpc3;
motor-unitA3.cP-scratch.heatCapPTZ1518.T
motor-unitA3.MotorMountCap.T
= sMc3;
motor-unitA3. dC-Motor-system. core. T = sMdcc3;
motor-unitA3. dC-Motorsystem. armature. T = sMdca3;
motor-unitA3.dC-Motor-system.dcpm.la.i
= sMlai3;
= sMcpc4;
motor-unitA4 .cP-scratch.heatCapPTZ1518.T
motor-unitA4.MotorMountCap. T = sMc4;
motor-unitA4 . dC-Motor-system. core. T = sMdcc4;
mot or-unitA4 .dCMotorsystem. armature. T
motor-unitA4 .dC-Motor-system.dcpm.1a. i
sMdca4;
=
=
sMlai4;
equation
connect (setFlowRate.portB, pipe.portA) ;
connect (setFlowRate .portA, expansionVolume.portA[11);
connect (productl.y,
setFlowRate.m-flow-in)
;
connect (densitySensor.y, productl.ul) ;
connect (product 1.u2, lpm-2_m3ps.y)
;
connect (densitySensor.port, setFlowRate.portB) ;
connect (tE-hack2-out .portb,
external-conv.port-a)
;
connect (idealGearR2T.flangeR,
motor-unitA3 .dC-Motor-system. loadInert ia. f lange-a);
connect (speedSensor.v, external-conv.vel) ;
connect (idealGearR2T.flangeT, speedSensor.flange) ;
connect(speedSensor.v, spd) ;
connect(vDem, vdem2pct.u) ;
connect (vdem2pct .y, mtr-volts .u) ;
connect (plate.port, external-conv.port-a)
connect (pipe.portB,
motor-unitAl. liquidFlowPort);
connect (motor-unitAl
.
liquidFlowPortl,
motor-unitA2 . liquidFlowPort) ;
connect (motor-unitA2
.
liquidFlowPortl,
95
..
................
..............
...
......
..............
motor-unitA3. liquidFlowPort) ;
connect (motor-unitA3. liquidFlowPort1,
motor-unitA4. liquidFlowPort) ;
connect (motor-unitA4 liquidFlowPortl,
cP-scratch-elc. liquidFlowPortin);
connect(expansionVolume.portA[2],
cP-scratch-out. liquidFlowPortout);
connect (cP-scratch-elc.liquidFlowPortout,
connect (cP-scratch-out.liquidFlowPortin,
end Systemrmodel-finalSim6F;
96
pipel.portA);
pipel.portB);
....
......
. .......
....
................................
A.2
Motor Unit
quidFWiPert
DC motor
TE module
4-
Motor
Va"
20
fluid block
I
;4"
0-
motor mount thermal
capacitor
ti
Figure A-2: Dymola graphical model of the motor unit
97
Ui
model Motor-unitBF
parameter Modelica. SIunits . Temperature sMcpc;
parameter Modelica.SIunits.Temperature sMcpt;
parameter Modelica. SIunits .Temperature sMc;
parameter Modelica. SIunits . Temperature sMdcc;
parameter Modelica. SIunits . Temperature sMdca;
parameter Modelica.SIunits.AngularVelocity sMdcw;
parameter Modelica.SIunits.Angle sMdcp;
parameter Modelica.SIunits.Current sMlai;
CP-scratch3F cP-scratch(
sCPc=sMcpc,
sCPpT=sMcpt,
redeclare package medium
Comp-heater
=
LC-HC50) ;
comp-heater2
T-lo=-40,
HeaterPwr=5,
T-hi=-38)
;
TE-hack2 tE-hack2
Se=2.2e-4,
Re=2,
t-cond=3.663,
startT=sMcpt)
DC-Motor-system2
dCMotor-system(
sDCc=sMdcc,
sDCa=sMdca,
sDCp=sMdcp,
sDCw=sMdcw,
loadInertia(phi(start=sMdcp, f ixed=true),
w(start=sMdcw, fixed=true)),
sDClai=sMlai)
Modelica . Thermal . HeatTransfer . Components . ThermalConductor
Rmm-cond(G=61.558)
;
Modelica. Thermal.HeatTransfer.Components.HeatCapacitor
MotorMountCap(C=896*0.224,
98
........................................................
-...
.................
. ........
;
T(fixed=false, start=sMc))
Modelica.Blocks.Interfaces.RealInput u;
Modelon. ThermoFluid. Interfaces .ApplicationSpecific. LiquidFlowPort
liquidFlowPort (redeclare package Medium = BasicModels.LC-HC50);
Modelon . ThermoFluid. Interfaces .ApplicationSpecific. LiquidFlowPort
liquidFlowPortl (redeclare package Medium = BasicModels. LCHC50) ;
LiquidCooling.Pipes.Generic.LiquidPipe pipel(
A=0 .005,
redeclare model Friction
=
Mode lon. ThermoFluid. FlowChannels.
PipeResistances .DetailedWallFriction,
useHeatTransfer=false,
from-dp=false,
L=0.5,
T-start=sMcpt,
redeclare package Medium = BasicModels.LCHC50)
;
equation
connect (tE-hack2.port-b,
cP-scratch.port-al)
;
connect (comp-heater2.T-in, MotorMountCap.port) ;
connect (comp-heater2 . Heat-out,
MotorMountCap.port)
;
connect (MotorMountCap.port, Rmm-cond.port-a) ;
connect (Rmm-cond.port-b,
tE-hack2.port-a)
connect (Rmm-cond.port-a,
dC.Motor-system.y)
connect(u,
dCJMotor-system.u)
;
;
;
connect (cP-scratch.liquidFlowPortin,
liquidFlowPort)
connect (pipel.portB, liquidFlowPortl) ;
connect (cP-scratch.liquidFlowPortout,
end Motor-unitBF;
99
pipel .portA)
;
;
............
-......................
..........................
--................
...............................
..............
..
.......
....................
A.3
Li
DC Motor
rotational inertia
voltage source
10-
r
.
-- rotational load
dc
DC motor
y
armature
and core
V
thermal masses
re
8mnile
Figure A-3: Dymola graphical model of the DC motor
100
..............
-.......................
-
........................
model DC-Motor-system2
parameter Modelica. SIunits .Temperature sDCc;
parameter Modelica. SIunits .Temperature sDCa;
parameter Modelica.SIunits.AngularVelocity sDCw;
parameter Modelica.SIunits.Angle sDCp;
parameter Modelica.SIunits.Current sDClai;
Modelica.Electrical.Machines.BasicMachines.
DCMachines . DCPermanentMagnet
dcpm(
useThermalPort=true,
VaNominal=4 8,
IaNominal=0 .909,
wNominal(displayUnit="rpm") = 158.12683023069,
Ra=15.7,
alpha20a(displayUnit="1/K") =
Modelica.Electrical.Machines.Thermal.Constants.alpha20Copper,
la(i(start=sDClai)),
La=4.14e-3,
Jr=121e-5) ;
Modelica.Electrical.Analog.Sources.SignalVoltage
armatureVoltage ;
Modelica.Electrical.Analog.Basic.Ground groundArmature;
Modelica.Mechanics.Rotational.Components.Inertia loadInertia(
J=0.1,
phi(fixed=true, start=sDCp),
w(fixed=true, start=sDCw))
;
Modelica. Thermal . HeatTransfer . Components . HeatCapacitor
armature(C=430*0.05, T(
fixed=false, start=sDCa))
"copper winding";
Modelica. Thermal. HeatTransfer.Components . ThermalConductor
armatureCore (G=1/1 .9);
Modelica.Thermal.HeatTransfer.Components.HeatCapacitor
core(C=380*0.1, T(
fixed=false, start=sDCc))
"iron core"
Modelica. Thermal . HeatTransfer . Components . ThermalConductor
coreCooling(G=1/4.7);
101
..........
..................................................
Modelica.Thermal.HeatTransfer.Sources.FixedTemperature
;
fixedTemperature(T=273.15)
Modelica.Mechanics.Rotational.Sources.QuadraticSpeedDependentTorque
load(
useSupport=false,
tau-nominal=-192e-3,
w-nominal(displayUnit="rpm") = 158.12683023069);
input Modelica.Blocks.Interfaces.RealInput u
"Voltage between pin p and n (= p.v -
n.v) as input signal" ;
output Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-b.y
protected
Modelica.Electrical.Machines.Interfaces.DCMachines.ThermalPortDCPM
thermalPort;
equation
connect(dcpm.flange, loadInertia.flange-a) ;
connect(armatureVoltage.n, groundArmature.p) ;
connect(armatureVoltage.p, dcpm.pin-ap) ;
connect(armatureVoltage.n, dcpm.pin-an);
connect(armature.port, armatureCore.port-a) ;
core.port)
connect (armatureCore.port-b,
;
connect(core.port, coreCooling.port-a) ;
connect(dcpm.thermalPort, thermalPort) ;
connect(armature.port, thermalPort.heatPortArmature);
connect(core.port, thermalPort.heatPortCore) ;
connect(fixedTemperature.port, thermalPort.heatPortStrayLoad) ;
connect(fixedTemperature.port, thermalPort.heatPortFriction) ;
connect(fixedTemperature.port, thermalPort.heatPortBrush);
connect(fixedTemperature.port,
thermalPort.heatPortPermanentMagnet);
load.flange)
connect (loadInertia.flange-b,
connect(armatureVoltage.v, u);
connect(coreCooling.port-b,
y
end DC-Motor-system2;
102
;
...
............................
.. ..........
- ..............
....
. .
A.4
......
Heater
Heat out
II
ht atingResist r
T-in
temperatur.
backwardHy.
0
-jde~gC
ConstAntVokL
ground
Figure A-4: Dymola graphical model of the heater
103
......
..............
.......
....................................................
-
model Comp-heater "10 W heater switched by temp"
parameter Real Tlo=-42 "backward hysteresis lower Temp";
parameter Real T-hi=-35 "backward hysteresis upper Temp";
parameter Modelica.SIunits.Power Heater-Pwr=10
"Heater power consumption";
Modelica.Thermal.HeatTransfer.Celsius.TemperatureSensor
temperatureSensor;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
Thin;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-b
Heat-out;
BackwardHysteresis backwardHysteresis (uLow=T-lo, uHigh=T-hi)
Modelica.Electrical.Analog.Basic . HeatingResistor
heatingResistor(alpha=0.00393,
R-ref=constantVoltage.V^2/Heater-Pwr) ;
Modelica.Electrical.Analog.Basic.Ground ground ;
Modelica.Electrical.Analog.Sources.ConstantVoltage
constantVoltage(V=28) ;
Modelica.Electrical.Analog. Ideal. IdealClosingSwitch
idealClosingSwitch;
equation
connect (temperatureSensor.port, T-in)
;
connect (temperatureSensor.T, backwardHysteresis.u) ;
connect (constantVoltage.n, ground.p) ;
connect (constantVoltage.p, idealClosingSwitch.p) ;
connect (idealClosingSwitch.control, backwardHysteresis.y) ;
connect (idealClosingSwitch.n, heatingResistor.p);
connect (heatingResistor.n, constantVoltage.n);
connect (heatingResistor.heatPort, Heatout);
end Comp-heater;
104
....
....
....
.... ..
................
.-..........
..........
..........................
.........
-
A.4.1
........................
..........
Backward Hysteresis
block BackwardHysteresis
"Transform Real to Boolean signal with Hysteresis"
extends Modelica.Blocks.Interfaces.partialBooleanBlockIcon;
parameter Real uLow(start=O)
"if y=true and u<=uLow, switch to y=false";
parameter Real uHigh(start=1) "if y=false and u>=uHigh, switch to y=true";
parameter Boolean pre-y-start=false
"Value of pre(y)
Modelica.Blocks.Interfaces.RealInput u;
Modelica.Blocks.Interfaces.BooleanOutput y;
initial equation
pre(y) = pre-y-start;
equation
y = u < uHigh and (u <= uLow or pre(y));
end BackwardHysteresis;
105
at initial
time";
A.5
Fluid Block
port al
thermal conductance calculation
I0
thermal mass of fluid block
I~
OD)
thermalConductor
OC
temperature Sensor
degC
iqui<
II
- -- <
volume flos
.. Ir
-~~~~#P
Figure A-5: Dymola graphical model of the fluid block
106
....
....
....
............
........
....
..........
.............................
::.
.........................
....
model CP-scratch3F
parameter Modelica
. SIunits . Temperature
sCPc
"fluid block starting temp";
parameter Modelica. SIunits . Temperature sCPpT
"fluid block starting temp";
replaceable package medium = BasicModels.LCHC50;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a port
Modelica . Thermal . HeatTransfer . Components . HeatCapacitor
heatCapPTZl518
(C=985.6, T(start=sCPc))
"for PTZ 1518 1.1 kg Al 6061";
Modelica.Thermal.HeatTransfer.Components.Convection
convection ;
CP-Gc-calc-expanded
cPGc-calc
;
Modelica.Blocks.Math.Gain gain(k=60000)
;
Modelica . Thermal. HeatTransfer. Components . ThermalConductor
thermalConductor
(G=0.334) ;
Modelica. Thermal.HeatTransfer.Celsius. TemperatureSensor
temperatureSensor ;
Modelon. ThermoFluid. Sensors .VolumeflowSensor
volumeflowSensor (redeclare
package Medium = medium) ;
LiquidCooling.Pipes.Generic.LiquidPipe pipel(
L=0 . 18,
useHeatTransfer=true,
redeclare model HeatTransfer
=
Modelon . ThermoFluid.FlowChannel s . HeatTrans fer.
ConstantCoeff
(alpha0=1e6),
A=0 .00194,
redeclare model Friction
Modelon.ThermoFluid.FlowChannels.PipeResistances.
DetailedWallFriction,
positiveFlow=true,
from-dp=false,
107
;
............
.....................
- - ............
..............
-.............
.........................
.......................
T-start=sCPpT,
redeclare package Medium = medium) ;
Modelon.ThermoFluid.Interfaces.ApplicationSpecific.
LiquidFlowPort
liquidFlowPortout
Modelon.ThermoFluid.Interfaces.ApplicationSpecific.
LiquidFlowPort
liquidFlowPortin
equation
connect (cP-Gc-calc.gc,
connect(gain.y,
convection.Gc);
cPGc-calc.volflow)
connect (thermalConductor.port-b,
;
heatCapPTZl518.port)
connect(port-al, convection.solid) ;
connect (convection.fluid, thermalConductor.port-a);
connect (temperatureSensor. T,
cP-Gc-calc.temp)
;
connect (volumeflowSensor.portB, pipel.portA) ;
connect (pipel.portB, liquidFlowPortout) ;
connect (volumeflowSensor.portA, liquidFlowPortin) ;
connect (volumeflowSensor.y, gain.u);
connect (temperatureSensor.port, pipel.q) ;
connect (pipel.q, convection.fluid) ;
end CP-scratch3F;
108
;
....
....
....
..
..
......
....................
-..............
- -....................
..................
--..................
................
......
- -11.- "I'l ", ..........
TE Module
A.6
model TE-hack2
"constant property TE module with no electrical output"
parameter Modelica.SIunits.SeebeckCoefficient Se
"Seebeck coefficient";
parameter Modelica.SIunits.Resistance Re
"electrical resistance (TE) ";
parameter Modelica.SIunits .ThermalConductance t-cond
"Thermal conductance of TE module";
parameter Modelica.SIunits.Temperature startT
"starting temp";
//Real Qp;
Modelica.SIunits.Current I;
Modelica.SIunits.TemperatureDifference dT;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a (T(start=startT))
"hot side"
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-b
portb
(T (start=startT))
"cold side"
equation
dT = port-a.T
I
=
-
Se*(port-a.T
port-b.T;
-
port-b.T)/(2*Re);
port-b.Q-flow = -(Se*port-b.T*I
port-a.Q-flow =
//Qp
Se*port-a.T*I
= port-a.Q-flow -
+ t-cond*dT +
+ t-cond*dT -
port-b.Q-flow;
end TE-hack2;
109
0.5*I^2*Re);
0.5*I^2*Re;
............
.
..........................
A.7
HC-50 Medium
"modelon lc table based HC50"
package LC-HC50
extends LiquidCooling.Media.Templates.Coolant(
redeclare package EquationsOfState =
Modelon.Media.EquationsOfState.Templates.Liquids.
TableBased-T
limits(
TMIN=273.15
50,
-
TMAX=273.15 + 110,
DMIN=900,
DMAX=1100,
PMIN=0
.
le5,
PMAX=50e5,
HMIN=0.0,
HMAX=200 . Oe3,
SMIN=0.0,
SMAX=l.0e3),
tableData(
beta-const=0,
kappa-const=0,
reference-p=101325,
reference-d=1351.1,
reference-h=0,
reference-s=0,
TinK=false,
tableDensity=[-50, 1378.8; -40,
-20,
1362.2; -10,1356.6;
20, 1340;
1323.4;
90,
30, 1334.5;
60, 1317.8;
1373.3; -30,
1367.7;
0, 1351.1; 10, 1345.6;
40, 1328.9; 50,
70, 1312.3; 80, 1306.7;
1301.2; 100, 1295.7],
tableHeatCapacity=[-50, 2.563; -40,
110
2.583; -30,
2.602;
....
....
.. ....
..............
........
..............
.............
...................
................
..............................
-20,
2.622; -10,
0, 2.661;
30, 2.72; 40, 2.74;
20, 2.701;
60, 2.78;
2.642;
70,
2.799;
50,
80, 2.819;
tableConductivity=[-50, 0.4345; -40,
-20,
0.4645; -10,
20, 0.5045;
50, 0.5345;
90,
30,
60,
0.5745;
50,
5.99;
2.1;
0.5145; 40,
100, 2.8581,
0.4545;
10, 0.4945;
80, 0.5645;
100, 0.5845],
1.8; 70,1.6;
20.4; -30,
30, 2.61496e3;
40,
9.39766e3; 70,
80, 20.71331e3;
90,
12.5; -20,
20, 3.2; 30, 2.7;
80,
1.5;
0.13153e3; -20,0.22715e3; -10,
0, 0.63675e3; 10,
60,
2.839;
0.5245;
tableVaporPressure=-50, 0.04109e3; -40,
-30,
2.76;
0.4445; -30,
0.5445; 70, 0.5545;
0, 4.7; 10, 3.8;
60,
90,
2.681;
0.4745; 0, 0.4845;
tableViscosity=[-50, 38.4; -40,
-10,
10,
90, 1.3;
40, 2.4;
100, 1.2],
0.07444e3;
0.38405e3;
1.0367e3; 20, 1.65953e3;
4.06008e3;
50, 6.21724e3;
14.03252e3;
30.24412e3; 100, 43.70856e3]),
npol-rho=2,
npol-Cp=1,
npohlpVap=2),
mediumName="Dynalene HC50 ",
substanceNames={"HC50"},
redeclare package TransportProperties
Modelon.Media.TransportProperties.Templates.Simplified.
TableBased
limits(
TMIN=273.15 -
50,
TMAX=273.15 + 110,
DMIN=900,
DMAX=1100,
PMIN=0 . le5,
PMAX=50e5,
HMIN=0.0,
HMAX=200.0e3,
SMIN=0 .0,
111
8.4;
...........
............
....
....
............
.
............
- ..........
....
................
.. .......................
......
................
SMAX=1.0e3),
tableData(
beta-const=0,
kappa-const=0,
ref erence-p=101325,
reference-d=1351.1,
reference-h=0,
re ferences=0,
TinK=false,
-20,
1323.4;
1334.5;
30,
1340;
20,
1317.8; 70, 1312.3;
60,
50,
1328.9;
40,
1345.6;
10,
0, 1351.1;
1362.2; -10,1356.6;
1367.7;
1373.3; -30,
1378.8; -40,
tableDensity=[-50,
1306.7;
80,
90, 1301.2; 100, 1295.7],
tableHeatCapacity=[-50, 2.563; -40,
60,
2.78;
2.799;
70,
tableConductivity=[-50,
-20,
50,
0.4645; -10,
30,
0.5045;
20,
60,
0.5345;
0.5745;
90,
0.4345; -40,
0.5145;
5.99;
4.7;
0,
50, 2.1; 60,
1.8;
2.76;
90,
40,
0.5245;
0.5545;
30, 2.61496e3;
60,
9.39766e3;
80,
20.71331e3;
0.5645;
80,
10,
3.8;
20.4; -30,
3.2;
20,
70,1.6; 80,
-10,
12.5; -20,
8.4;
40,
2.4;
30,
1.5; 90,
0.13153e3; -20,0.22715e3;
0, 0.63675e3;
0.4945;
0.5845],
tableVaporPressure=[-50, 0.04109e3; -40,
-30,
10,
2.858],
0.4545;
0.4445; -30,
0.4845;
70,
100,
2.839;
0,
0.4745;
0.5445;
100,
2.819;
80,
tableViscosity=[-50, 38.4; -40,
-10,
50,
2.72; 40, 2.74;
30,
20, 2.701;
10, 2.681;
0, 2.661;
2.642;
2.622; -10,
-20,
2.602;
2.583; -30,
2.7;
1.3;
100, 1.2],
0.07444e3;
0.38405e3;
10, 1.0367e3; 20, 1.65953e3;
40, 4.06008e3;
70,
50, 6.21724e3;
14.03252e3;
90, 30.24412e3;
npol-eta=2,
npol-lam=1),
112
100, 43.70856e3]),
....
..
..................... ............
..
.........
..............
I.................
-..................
. L.......................
.. ...
CompressibilityType=EquationsOfState.CompressibilityType,
ThermoStates=Modelon.Media. Interfaces .Types .IndependentVariables .pTX,
final limits=EquationsOfState.limits,
analyticInverseTfromh=EquationsOfState.analyticInverseTfromh,
hasCriticalData=false,
FixedComposition=true,
redeclare model VolumeDynamics
IncompressibleVolume
=
(nS=nS, nC=nC));
end LC-HC50;
113
A.8
PCM Block
poti
I
PCMunit_mass
DI-
k=PCM_719
PTRT -I II
I
-
L
-
I
U
A
I
!zi1
0-
I
I
4J~.4i
I
-4.
I
k=thck
4
f-13-
-
I
thickness
-
I
--
&M
-
fin length
k=Lflni3
I
a
-h
A&T
-1~
0~]
AT
port a
Figure A-6: Dymola graphical model of the PCM block
114
I
model PCMcontainer2
parameter Real thick=0.002 "thickness of Al sides
parameter Real PCM-m=1.5 "mass of PCM in HS
(m]";
(kg] ";
parameter Real Lfin=O.l "Length of fins, ie HS length [m]";
parameter Modelica.SIunits.Temperature sPCMi(start=233.15,
displayUnit="degC");
parameter Modelica. SIunits . Temperature sPCMcl (start=233 .15,
displayUnit="degC");
parameter Modelica. SIunits . Temperature sPCMc2 (start=233.15,
displayUnit="degC");
parameter Modelica. SIunits . Temperature sPCMc3 (start=233.15,
displayUnit="degC");
parameter Modelica. SIunits . Temperature sPCMc4 (start=233.15,
displayUnit="degC");
parameter Modelica.SIunits.Temperature sPCMel(start=233.15,
displayUnit="degC");
parameter Modelica.SIunits .Temperature sPCMe2 (start=233.15,
displayUnit="degC");
parameter Modelica.SIunits.Temperature sPCMe3 (start=233.15,
displayUnit="degC");
parameter Modelica. SIunits . Temperature sPCMe4 (start=233.15,
displayUnit="degC");
"Temperature of element"
output Modelica.SIunits .Temperature Tavg;
Modelica.Blocks.Sources.Constant PCMunit-mass(k=PCM-m/9)
Modelica.Blocks.Sources.Constant thickness(k=thick);
Modelica.Blocks.Sources.Constant fin-length(k=Lfin/3) ;
PCMunitInt2 pCMunitInt (PCM-T-start=sPCMi)
;
PCMunitEdge2 pCMunitEdge2 (LTstart=sPCMe2) ;
PCMunitEdge2 pCMunitEdge4 (T-start=sPCMe4) ;
PCMunitEdge2 pCMunitEdgel (T-start=sPCMel) ;
PCMunitEdge2 pCMunitEdge3 (T-start=sPCMe3) ;
PCMunitCorner2 pCMunitCorner2 (T-start=sPCMc2) ;
PCMunitCorner2 pCMunitCornerl (Tstart=sPCMc1);
115
................
....
PCMunitCorner2 pCMunitCorner3(T-start=sPCMc3);
PCMunitCorner2 pCMunitCorner4(T-start=sPCMc4)
Modelica. Thermal. HeatTransfer. Interfaces. HeatPort-a port-a;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-b
Fin finK(side=0.005)
Fin finA(side=0.005)
Fin finH(side=0.005)
Fin finJ(side=0.005);
Fin finC(side=0.005)
Fin finB(side=0.005)
Fin finL(side=0.005)
Fin finE(side=0.005);
Fin finF(side=0.005)
Fin finG(side=0.005)
Fin finD(side=0.005)
Fin finI(side=0.005) ;
equation
connect (pCMunitCorner4 .port-a4,
connect (finK.port-b,
pCMunitEdge3.port-a4)
connect (pCMunitEdge3.port-a2,
connect (finL.port-b,
finK.port-a)
connect (port-a,
pCMunitCorner3.port-a2)
;
connect (port-a,
pCMunitCorner4.port-al)
;
connect (pCMunitCorner4 .port-a3,
;
;
;
pCMunitCornerl.port-a4)
;
finA.port-a)
;
pCMunitEdgel .port-a4);
connect (pCMunitEdgel .port-a2,
connect (finB.port-b,
finH.port-a)
finC.port-a)
connect (pCMunitCornerl .port-a3,
connect (finA. port -b,
;
;
pCMunitEdge4.port-a4)
connect (pCMunitEdge4 .port-a2,
connect (finC.port-b,
;
pCMunitCorner3.port-a3)
pCMunitEdge3.port-a1)
connect (finH.portb,
;
finL.port-a)
connect (port-a,
;
finB.port-a)
;
pCMunitCorner2 .port-a4);
connect (pCMunitCorner2.port-a3,
finE .port-b)
116
;
port-b;
..
......
..........
....
..
.........
.....
connect(finE.port-a,
pCMunitEdge2.port-a4);
finJ.port-b)
connect (pCMunitEdge2.port-a2,
connect (finJ.port-a,
finI.port-al);
connect (finI.port-a2,
finH.port-al)
connect (finK.port-a2,
finF. portal);
connect (finF.port-a2,
finA.port-al)
;
connect(finC.port-al, finD.port-a2)
;
finE.port-a2)
;
finI .portb);
pCMunitEdge3.port-a3);
connect (pCMunitInt.port-a2,
connect (f inG. port-b,
finG.port-a)
;
pCMunitEdge2.port-a3);
connect (ifinB.port-al,
finG.port-a2);
connect (finG.port-al,
finL.port-a2)
connect (pCMunitInt .port-a4,
connect (finF.port-a,
;
pCMunitInt.port-al);
connect (pCMunitInt .port-a3,
connect (finI.port-a,
;
finD .port-b)
connect (pCMunitEdgel.port-a3,
connect (finD.port-a,
;
pCMunitCorner3.port-a4)
connect (finJ. port-a2,
connect (finD. port-al,
;
;
finF.port-b)
pCMunitEdge4.port-a3)
connect (pCMunitCornerl .port-a2,
port-b);
connect (port-b,
pCMunitEdgel .port-al) ;
connect (port-b,
pCMunitCorner2.port-al);
connect (PCMunit-mass.y, pCMunitCornerl.m) ;
connect (PCMunit-mass .y, pCMunitEdge4.m);
connect (PCMunit-mass .y, pCMunitCorner4 .m) ;
connect (PCMunit-mass.y, pCMunitEdgel.m) ;
connect (PCMunit-mass.y, pCMunitCorner2.m);
connect (PCMunitimass .y, pCMunitInt .m);
connect (PCMunit-mass.y, pCMunitEdge2.m) ;
connect (PCMunit-mass.y, pCMunitEdge3.m) ;
connect (PCMunit_mass .y, pCMunitCorner3 .m);
;
connect (ifin-length.y,
finA.length)
connect (fin-length.y,
finB.iength) ;
connect (fin-length.y,
finC.length)
connect (fin-length.y,
finD.length);
connect (fin-length.y,
finE.length) ;
;
117
;
connect (fin-length.y,
finF.length) ;
connect (fin-length. y, finG.length) ;
connect (fin-length. y,
finH.length) ;
connect (fin-length. y, finI.length) ;
connect (fin-length. y, finJ.length) ;
connect (thickness.y, pCMunitCorner4.thk) ;
connect (thickness.y, pCMunitEdge3.thk) ;
connect (thickness.y, pCMunitCorner3.thk) ;
connect(thickness.y, pCMunitEdge4.thk) ;
connect (thickness.y, pCMunitEdge2.thk) ;
connect (thickness.y, pCMunitCorner2.thk) ;
connect(thickness.y, pCMunitCornerl.thk) );
connect (thickness.y, pCMunitEdgel.thk) ;
connect(fin-length.y,
finK.length);
connect (ifin-length.y,
finL.length)
T-avg =
(pCMunitInt.pCMCapacitor.T + pCMunitEdgel.pCMCapacitor.T +
pCMunitEdge2.pCMCapacitor.T + pCMunitEdge3.pCMCapacitor.T +
pCMunitEdge4 .pCMCapacitor.T + pCMunitCornerl.pCMCapacitor.T +
pCMunitCorner2 .pCMCapacitor.T +
pCMunitCorner3.pCMCapacitor.T + pCMunitCorner4.pCMCapacitor.T) /9;
connect (finL.port-al,
port-a);
connect (finK.port-al,
port-a)
connect (pCMunitCorner2 .port-a2,
finE .port-al);
connect (pCMunitEdge2.port-al, finJ.port-al)
;
connect (finJ. port -al, pCMunitCorner3 .port-al);
connect (finE.port-al,
pCMunitEdge2 .port-al) ;
connect (pCMunitCornerl.port-al,
connect (pCMunitEdge4 .port-al,
connect (finH.port-a2,
pCMunitEdge4.port-al)
finH.port-a2)
;
pCMunitCorner4.port-a2);
end PCMcontainer2;
118
;
..
................
........
...
A.8.1
PCM Interior Unit
model PCMunitInt2
PCMCapacitor pCMCapacitor (T(start=PCM-T-start))
PCMThermalConductor pCMThermalConductor2
Modelica.Blocks.Interfaces.RealInput m "mass of PCM unit";
PCMThermalConductor pCMThermalConductor4
;
PCMThermalConductor pCMThermalConductorl
;
PCMThermalConductor pCMThermalConductor3
;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a4;
Modelica. Thermal. HeatTransfer. Interfaces. HeatPort-a port-al
Modelica. Thermal. HeatTransfer. Inter faces. HeatPorta port-a2;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a3;
parameter Modelica. SIunits . Temperature
PCM-T-start (start=233.15,
displayUnit="degC")
"Temperature of element";
equation
connect (pCMCapacitor.port, pCMThermalConductor3.port-a);
connect (pCMCapacitor.port, pCMThermalConductor2.port-a) ;
connect (pCMCapacitor .port, pCMThermalConductor4 .port-a);
connect (pCMCapacitor .port, pCMThermalConductorl.port-a);
connect (m, pCMThermalConductorl.m) ;
connect (pCMThermalConductor4.m, m) ;
connect (m, pCMThermalConductor3 .m);
connect (m, pCMThermalConductor2.m) ;
connect (pCMCapacitor.m-unit,
m)
;
connect (port-a4,
pCMThermalConductor4.port -b)
;
connect (port-al,
pCMThermalConductor1.portb)
;
connect (port-a3,
pCMThermalConductor3.port -b)
;
connect (port-a2,
pCMThermalConductor2.port-b)
;
connect (port-a2,
port-a2);
end PCMunitInt2;
119
........
......
..............
-..............
............
............
.........
. . .
.
..............
PCM mass
model PCMCapacitor "PCM heat capacitor unit"
Modelica.SIunits.SpecificHeatCapacity cp
"specific heat of the PCM";
constant Modelica.SIunits.SpecificHeatCapacity c=3.15e3
"specific heat of the PCM";
constant Real r-trans=2;
constant Modelica.SIunits.Temperature T-trans=-36.5 + 273.15;
constant Modelica.SIunits.SpecificEnthalpy h-trans=213e3;
Modelica.SIunits.Temperature T(start=293.15, displayUnit="degC")
"Temperature of element";
Modelica.SIunits.TemperatureSlope derT (start=O)
"Time derivative of temperature
(= der(T))";
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port
Modelica.Blocks.Interfaces.RealInput m-unit
"Signal representing mass
[kg]";
equation
T = port.T;
m-unit*cp*der-T
cp =
1)))
der (T)
= port.Q-flow;
((h-trans/ (Modelica. Constants.pi* (((T + c);
= derT;
end PCMCapacitor;
120
T-trans) *r-trans) ^2 +
....
....
.....
..
..........................
............
....
.........
....
. ......
A.8.2
................
....
PCM Edge Unit
model PCMunitEdge2
PCMCapacitor pCMCapacitor(T(start=T-start))
PCMThermalConductor pCMThermalConductor2
;
Modelica.Blocks.Interfaces.RealInput m "mass of PCM unit" ;
PCMThermalConductor pCMThermalConductor4
PCMThermalConductor pCMThermalConductorl
PCMThermalConductor pCMThermalConductor3
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a4
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a2
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a3;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-al;
HeatCapacitor-side
heatCapacitor-side (T (start=T-start))
Modelica.Blocks.Interfaces.RealInput thk ;
ThermalConductor-thk
thermalConductor-thkl
parameter Modelica. SIunits . Temperature
T-start (start=233.15, displayUnit="degC")
"Temperature of element";
equation
connect (pCMCapacitor.port, pCMThermalConductor3.port-a) ;
connect (pCMCapacitor.port, pCMThermalConductor2.port-a) ;
connect (pCMCapacitor.port, pCMThermalConductor4 .port-a);
connect (pCMCapacitor.port, pCMThermalConductorl.port-a) ;
connect (m, pCMThermalConductorl .m);
connect (pCMThermalConductor4 .m, m) ;
connect(m, pCMThermalConductor3.m);
connect (m, pCMThermalConductor2 .m) ;
connect (pCMCapacitor.m-unit,
m)
;
connect (porta4,
pCMThermalConductor4 .port-b);
connect (port-a3,
pCMThermalConductor3.port-b);
connect (port-a2,
pCMThermalConductor2.port-b)
connect (port-a2,
port-a2) ;
connect (heatCapacitor.side.m,
m)
;
121
;
connect(thk,
heatCapacitor-side.thk)
connect (pCMThermalConductor1.port b,
;
thermalConductor-thkl.port-a);
connect (thermalConductor-thkl .port-b, portal)
connect (heatCapacitor-side.port,
connect (thk,
;
thermalConductor-thkl.port-a);
thermalConductor-thkl.thk)
end PCMunitEdge2;
122
;
11
..........
..........
......
..........
.....................
.......
................... ............
A.8.3
PCM Corner Unit
model PCMunitCorner2
PCMCapacitor pCMCapacitor(T(start=T-start))
PCMThermalConductor pCMThermalConductor2 ;
Modelica.Blocks.Interfaces.RealInput m "mass of PCM unit" ;
PCMThermalConductor pCMThermalConductor4
PCMThermalConductor pCMThermalConductorl
PCMThermalConductor pCMThermalConductor3;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a4
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a2;
Modelica. Thermal. HeatTransfer. Interfaces. HeatPort-a port-a3;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-al
HeatCapacitor-side heat Capacitor-side(T(start=T-start))
Modelica.Blocks.Interfaces.RealInput thk ;
ThermalConductor-thk
thermalConductor-thk1
ThermalConductor-thk
thermalConductor-thk2
Heat Capacit or-side heatCapacitor-sidel (T (start=T-st art))
parameter Modelica.SIunits.Temperature
T-start (start=233.15, displayUnit="degC")
"Temperature of element";
equation
connect (pCMCapacitor .port, pCMThermalConductor3.port-a);
connect (pCMCapacitor.port, pCMThermalConductor2.port-a);
connect (pCMCapacitor.port, pCMThermalConductor4.port-a) ;
connect (pCMCapacitor.port, pCMThermalConductorl .port-a);
connect (m, pCMThermalConductorl.m) ;
connect (pCMThermalConductor4 .m, m) ;
connect (m, pCMThermalConductor3.m) ;
connect
(m, pCMThermalConductor2 .m);
connect (pCMCapacitor.munit,
m)
;
connect (port-a4,
pCMThermalConductor4 .port-b)
;
connect (port-a3,
pCMThermalConductor3.port-b)
;
connect (port-a2,
port-a2)
123
......
.....
.....
connect (heatCapacitor-side.m,
connect(thk,
m)
;
heatCapacitor-side.thk)
connect (pCMThermalConductorl .port b,
connect (thermalConductor-thkl
thermalConductor-thkl.port-a);
port .b, port-al)
connect (heatCapacitor-side.port,
connect(thk,
;
;
thermalConductor-thkl.port-a);
thermalConductor-thkl.thk);
connect (pCMThermalConductor2.portWb,
thermalConductor-thk2.port-a);
connect (thermalConductor-thk2.port b, port-a2);
connect(thk,
connect (thermalConductor .thk2.port-a,
connect(m,
;
thermalConductor-thk2.thk)
heatCapacitor-sidel.m)
connect (heatCapacitor-sidel .thk,
heatCapacitor-sidel.port);
;
thk)
end PCMunitCorner2;
124
;
..............................................
.
A.9
...............
I I..,.." I'll "..,
---
-
-
-
-
-
-
. -
External Convection
V
massFlwBounday
pressureBownday
Liquid Cooling fixed volume
temperatureSensor
jdegC
porla
Figure A-7: Dymola graphical model of external convection
125
>
- --
.-
, I
..........
model External-conv-temp3aLC
"convection over a flat plate with laminar flow with temp rise"
replaceable package medium = LPG constrainedby
Modelon.Media.Interfaces.GenericMedium
"Amb.
Medium with const. prop.
;
parameter Modelica.SIunits.ThermalConductivity lamda;
parameter Modelica.SIunits.Density rho;
parameter Modelica.SIunits.SpecificHeatCapacity cp;
parameter Modelica.SIunits.KinematicViscosity nue;
parameter Modelica.SIunits .Temperature boil-pt
"boiling point of the ambient fluid";
parameter Modelica.SIunits.Temperature sExtT;
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort-a
port-a
Modelica.Thermal.HeatTransfer.Components.Convection
convection;
Modelica.Blocks . Interfaces .RealInput vel
"velocity of convective object
[m/s]";
Real Nu;
Real Re;
Real Pr;
Real alpha;
Real h "conv coeff";
Real gc;
parameter Modelica.SIunits.Length L "Length scale";
parameter Modelica.SIunits.Area A "Area of convection";
Modelica.Blocks.Interfaces.RealOutput amb-t ;
Modelon. ThermoFluid.Sources .MassFlowBoundary
massFlowBoundary(
f lowDe f inition=Mode lon . ThermoFluid. Choices. FlowDe f init
ion .V-flow,
VFlowUnit=Modelon . ThermoFluid. Choices. RealVFlowUnit . SI,
use-f low-in=true,
redeclare package Medium = medium,
T(displayUnit="K") = 228.15)
;
Modelon. ThermoFluid. Sources .PressureBoundary
pressureBoundary(
126
..........
....
..
...................................
.........
..1
.......................
p(displayUnit="kPa") = 101300,
redeclare package Medium = medium,
T(displayUnit="K')
= 228.15,
N=l) ;
Modelica . Thermal . HeatTransfer . Celsius . TemperatureSensor
temperatureSensor ;
Modelon.ThermoFluid.Volumes.TwoportVolume twoportVolume(
redeclare package Medium = medium,
V=A*0.001,
redeclare model HeatTransfer
Modelon.ThermoFluid.Volumes.HeatTransfer.
LumpedHT-constAlpha
(alpha0=le6),
A-h=A,
internalHeatResistance=true,
realTimeMode=false,
initOpt=Modelon.ThermoFluid.Choices.InitOptions.initialValues,
p-start (displayUnit="kPa") = 101300,
T-start=sExtT)
equation
alpha = lamda/(rho*cp);
Re = abs(vel)*L/nue;
Pr = nue/alpha;
Nu = 0.664*(Re^0.5)*(Pr^(l/3));
h = Nu*lamda/L;
gc = h*A;
massFlowBoundary.V-flow-in
= vel*L*0 .001;
//volume flow is speed by width by height
assert(
temperatureSensor.T < boil-pt,
"ambient is vaporizing!",
Assert ionLevel .warning);
connect (convection.solid, port-a) ;
convection.Gc = gc;
connect (temperatureSensor.T, ambt) ;
connect (temperatureSensor.port, convection.fluid) ;
127
......................
..................
. .....
.....
connect(twoportVolume.q, convection.fluid) ;
connect(twoportVolume.portB, pressureBoundary.fluidPort[l]);
connect(massFlowBoundary.fluidPort, twoportVolume.portA) ;
end External-conv-temp3aLC;
128
...........
..
......
A.9.1
LPG Medium
package LPG "modelon lc table based LPG"
extends LiquidCooling.Media.Templates.Coolant(
redeclare package EquationsOfState =
Modelon.Media.EquationsOfState.Templates.Liquids.
TableBasedT(
limits(
TMIN=273.15 -
50,
TMAX=273.15 -
40,
DMIN=900,
DMAX=1100,
PMIN=0.le5,
PMAX=50e5,
HMIN=0 .0,
HMAX=200.0e3,
SMIN=0 .0,
SMAX=l.0e3),
tableData(
beta-const=0,
kappa-const=0,
reference-p=101325,
reference-d=584.55,
reference-h=0,
reference-s=0,
TinK=false,
tableDensity=[-50, 584.55; -40,
584.55],
tableHeatCapacity=[-50, 2237.5; -40,
2237.5],
tableConductivity=[-50, 0.1312; -40,
0.1312],
tableViscosity=[-50, 3.493e-7*584.55; -40,
tableVaporPressure=[-50, 86670; -40,
npol-rho=2,
npolCp=l,
npol-pVap=2),
129
3.493e-7*584.55],
110941]),
mediumName="LPG "
,
substanceNames={"LPG" },
redeclare package TransportProperties
=
Modelon .Media.TransportProperties.Templates. Simplified.
TableBased
limits(
TMIN=273.15 -
50,
TMAX=273.15 -
40,
DMIN=900,
DMAX=1100,
PMIN=0.le5,
PMAX=50e5,
HMIN=0.0,
HMAX=200
.
Oe3,
SMIN=0.0,
SMAX=l
.
Oe3),
tableData(
beta-const=0,
kappa-const=0,
reference-p=101325,
ref
erenced=584. 55,
reference-h=0,
reference-s=0,
TinK=false,
tableDensity=[-50, 584.55; -40,
584.55],
tableHeatCapacity=[-50, 2237.5; -40,
2237.5],
tableConductivity=[-50, 0.1312; -40,
0.1312],
tableViscosity=[-50, 3.493e-7*584.55; -40,
3.493e-7
*584.55],
tableVaporPressure=[-50, 86670; -40,
110941]),
npol-eta=2,
npol-lam=1),
CompressibilityType=EquationsOfState.CompressibilityType,
ThermoStates=Modelon.Media. Interfaces.Types.
IndependentVariables .pTX,
final limits=EquationsOfState.limits,
130
....
....
..
................
-..................
...................
-......
..
...
...
. .... . ....
analyticInverseTfromh=EquationsOfState.analyticInverseTfromh,
hasCriticalData=false,
FixedComposition=true,
redeclare model VolumeDynamics = IncompressibleVolume (nS=nS,
nC=nC));
end LPG;
131
132
Appendix B
Modelica Verification Testing and
Simulink Comparison Testing
B.1
Verification Testing
The following figures show the models used in the verification tests of the Modelica
component models as well as the results of those tests, if not included in Chapter 2.
133
...
.
..
...
expansionVolume
01
*G
const
V=8 Oe-4
duration=100
Fluid block
fixedHeaflow
h16M=2
Figure B-1: The model used for verification testing of the Dymola fluid block component using the Liquid Cooling library. This model simulated a closed loop fluid
circuit with a constant thermal input at the fluid block and a variable fluid flow rate.
134
..
........................................
-............
............
....
....
....
..........
I.::..,
.........................
fixedTemperaturel
I
i
T=323.15
Figure B-2: The model used for verification testing of the PCM block. One side of the
block is connected to a fixed temperature boundary, and the other side is thermally
isolated.
135
...........
.. ..........
ramp
external
duration=30
E
trapezoid
CL
period=40
Figure B-3: The model used for verification testing of the external convection model.
The robot speed is varied while the temperature applied to the heat sink side of the
convection is cycled up and down in a trapezoidal pattern.
136
-
..
.............
.......
.1..............
.........
.....................
heatCapacitor
thermalConductor
prescribecTemperature
pulse
period=20
Heater
Figure B-4: The model used for verification testing of the heater model. The temperature boundary connected to the thermal mass is cycled above and below the upper
and lower bounds for heater operation.
137
Simulink and Dymola Comparison Tests
B.2
The following figures show the models used in the comparison testing performed to
confirm that the simulation results agree between Dymola and Simulink, and the
results of the test.
so
system
deAs
2S
///7
exyLqlow
riy
pr
wce
rc
wl~
aa
Mpe
Riuca
cMndo.Z
I
I;
PvSa*eM"WL-
Mc
-dI
W
M PAWI
tewperaft"s
R
o-"
ZMRr
II
77
_
durafimt-l
-- tniM- C
Figure B-5: Dymola model of the TMS system used for Dymola/Simulink comparison
tests
138
......................
-
.....
..
....
pCMcontairw1_I T_avg
oP_scratch4.temperatureSensorT
u
Scopp3
Gain
cPscatch4.port-as 1Qflow
Group 1
cP_scratch3.temperatureSensmr.T
Siro iglde
CP_saatch3.pot_a1.Q_flow
-Ispsdset
y
exkdqflow
--JE---Il
Lj_
scow
Bsidas. System ffcmielnoAct iLt_%s
SoopQ
Figure B-6: Simulink model of the TMS system used for Dymola/Simulink comparison tests
139
External convection Q flow
-
0.0350.0300.0250.0200.0150.0100.0050.000-0.005-I
3000
2000
1000
4000
time (s)
Figure B-7: Dymola results for the external heat flow
0.04
----
.
O.035
-.-.-
/
0.03
O.025
0.02
0.015
0.011- -
-
0.005
0
500
1000
1500
2000
2500
3000
3500
4000
Time (s)
Figure B-8: Simulink results for the external heat flow
140
..
........................
............
..........................
..
......
.. ............
. ........
PCM block average temperature
M298
229.6229.4-
2292229.0228.8228.6228&4228,2-
I
1000
0
2000
3000
4000
time (s)
Figure B-9: Dymola results for the PCM average temperature
FCM.Ta.
| -.....
229.4
-.
.
.....
..
..
..
...
...
..
... .....
...
229
-
.--....
.....
S2288
'-228.6
2284
226.2
2280
-
5w
100
1500
2000
Time (s)
20O
3000
3500
4000
Figure B-10: Simulink results for the PCM average temperature
141
-
fluid block 4 Q flow -
fluid block 3 Q flow
25..
20-
IS-
% 10-
5-
0-
I00
0
2000
time (s)
3000
4000
Figure B-11: Dymola results for the fluid block heat flows
C.
cPscratch4.Qfiow
cPscrath3.Qlow
20
15
10
5
0
0
SM
100
1500
200
2500
30M
350
4000
Time (s)
Figure B-12: Simulink results for the fluid block heat flows
142
. .............
....
--
----------:.-
---
Fluid temperature 3
Fluid temperature 3
-
Fluid temperature 4
Fluid temperature 4
-
-- Motor capacitor temp
Motor capacitor temp
250200-
150100-
so0-50-
0
4000
3000
2000
1000
time (s)
Figure B-13: Dymola results for the system temperatures
300
cPscratch4.T
cPscratch3.T
250
-MtrCap.T
200
---
150
-
- -
-
-
- -
-
-
- .
.
-.-.- -..--
-
--
-
- -
-
E
a)
1J 6
0100
......
1500......
2000.
2500..
1500
250M
...
3000......
... ....
3500..........
0-
0
500
1000
2MW
3000
35M0
Time (s)
Figure B-14: Simulink results for the system temperatures
143
4000
144
...
..
..
..........
.............
I..........
..
......
..............
Appendix C
Matlab Code
% Ethan Heller, May 2013
% TMS control
% File 6Fvel2
% Modelon LC model and the velocity as a controlled output
%% Startup
%initialize
clear all; cdc;
ytmat =
ydmat = [];
utmat = [I;
udmat = [3;
ypmat = [1;
[];
tpmat =
ymdmat
=
xStatemat
rmat =
[];
=
[];
[];
%load in the velocity reference trajectory
load VrefVtL2.mat;
%load in simin
load DSinit6.mat; %load in DSxinit for initial parameter values
145
wm
~w
%set simulation parameters
model =
'partial-run-sim6Fvel2';
%set model used
load-system (model)
open-system (model)
cs = getActiveConfigSet(model);
%get the model configuration setup
model-cs = cs.copy; %copy the configuration
tau = 375;
%set the system step = smallest thermal time constant
t-final = tau*ceil(simin.Time(end)/tau);
%get final time from vel ref input (timeseries)
t-cur = 0;
%initialize current time
sStateNames = sGetStateNameStarts6f;
%open file with the names of the states
ssN
ts
=
size(sStateNames,2);
1; %sampling time for MPC
=
p = 200; %MPC prediction horizon modified from 200/20
m = 20;
%MPC control horizon
T = floor(tau/ts);%number of MPC simulation steps
wghts = struct('ManipulatedVariables', [0.0
0.02],...
'OutputVariables', [65 .008 .01 1]);
%MPC weights structure
MV(l) = struct('Min',0.001,'Max',.6,'RateMax',0.01,'RateMin',-0.025);
%MPC manipulated variable 1 (vdem)
MV(2) = struct('Min',0.01,'Max',11.98,'RateMax',0.1,'RateMin',-0.05);
%MPC manipulated variable 2 (pump)
OV(l)
= struct('Min',0,'Max',0.5,'MaxECR',.10);
%MPC output variable 1 (vel)
OV(2) = struct('Min',-40+273.15,'Max',140+273.15,'MaxECR',.005);
%MPC output variable 2 (T mtr)
OV(3) = struct('Min',-48,'Max',105,'MaxECR',.15);
%MPC output variable 3 (T liquid)
OV(4) = struct('Min',-46,'Max',-42.6,'MaxECR',O);
%MPC output variable 3 (T ext)
DV = [];
146
....................
tsamp
ts; %sampling time for linearization
=
initT2
=
[0 150 tau]'; %time for initial run
initU2
=
[0; 0;
initTS2
=
2.7J; %initial Us: pump
timeseries(initU2,initT2);
%time series of initial inputs2
%% Iteration Code: MPC
while t-cur < t-final
%run until the final time as determined from external input
load-system(model)
open-system (model)
t-s = t-cur;
%simulation start time
t-f = t-s+tau;
%simulation stop time
set-param(model-cs,'StartTime','t-s','StopTime','t-f');
%need to set initial parameters of the model to the initial values
%of the last run
if t-cur
==
for i
=
0 %on the first run only
1:ssN
%set inital conditions, the model does not reset automatically
fmuSetValueSimulink (...
'partial-run-sim6Fvel2/BasicModels.System-model-final-Sim6F
sStateNames{l, i}{l,
l},DSxinit (i));
end
%set inputs 1 and 2 to timeseries input
inl = simin;
%set v dem input from Vref data
in2 = initTS2;
%set pump input from initial data
else %for all other runs
for i = 1:ssN
%set
inital conditions, loop through all variables
fmuSetValueSimulink
(...
'partial-run-sim6Fvel2 /Bas icModels. System-model-f inal-Sim6F '
sStateNames{l,i}{ll},sDSx(end,i));
end
147
I
..................................................................
....
......
...
-.........................
-
inl = TSmpcl; %set pump input from MPC
in2 = TSmpc2; %set v scalar input from MPC
clear sDSx;
clear tDS;
end
simOut-itr = sim(model,
%simulate the model
model-cs);
(iteration i)
y-itr = simOut-itr.get('y-itr');
ycell = struct2cell(y-itr);
ytmat-itr = ycell{l,1};
ytmat =
%get the simulation output
%convert output to cell
%convert time output to mat form
[ytmat;ytmat-itrl;
%concatenate time output
= ycell{2,1}(1,1) .values;
ydmat-itrl
%obtain the first output value
= ycell{2,1}(1,2) .values-273.15;
ydmat-itr2
%obtain the 2nd output value in deg C
ydmat-itr3 = ycell{2,1}(1,3).values;
%obtain the 3rd output value
ydmat-itr4 = ycell{2,1}(1,4).values;
%obtain the 4th output value
ydmat =
ydmat-itr3 ydmat-itr4];
[ydmat;ydmat-itrl
ydmat-itr2
%concatenate data output
%save states for plotting checks, use ytmat for time scale
= simOut-itr.get('x-itr');
x-itr
signals . values;
.x-tr
xStateitr
xStatemat
=
[xStatemat;
xState-itr];
%obtain results from Dymola to use in setting inital states
DymXitr = loadDSResult
('BasicModels. System-model-f inal-Sim6F-results .txt');
for n = 1:ssN
[tDS sDSx(:,n) ] = getDSVariable(DymXitr, sStateNames{l,n}{2, 1});
end
%do the linearization on output y-itr and input u-itr
%need to interpolate data to uniform sampling for n4sid
148
....
.. .. ..
..........................
......
= y-itr.time(l);
tstart
tfinal = y-itr.time(end); %set interp start/stop
ti = tstart:tsamp:(tfinal-ts);
yis(:,1)
= interpl (y-itr.time,y-itr.signals
yis(:,2)
= interpl (y-itr.
yis(:,3)
= interpl (y-itr.time,y-itr.signals
(3) .values,ti);
yis(:,4)
= interpl (y-itr.time,y-itr.signals
(4) .values,ti);
time, y-itr.
(1) .values,ti);
signals (2) .values,ti);
uis(:,l) = interpl(inl.Time,inl.Data,ti);
uis(:,2) = interpl(in2.Time,in2.Data,ti);
data = iddata(yis,uis,tsamp); %create data set for
lin
%linearize using 10 states to SS model (iteration i)
[linplant,xO] = n4sid(data,10,'DisturbanceModel','none');
MPCobj
mpc(linplant,ts,p,m,wghts,MV,OV,DV);
%create the MPC object
[yp, tp, xp]
(iteration i+1)
= lsim(linplant,uis,ti,xO);
%get simulation states for lin sys
xpinit = xp(end,:)';
tpmat =
[tpmat;tp];
ypmat = [ypmat;ypj;
%grab the last state as MPC initial
%grab lin plant times for comparison
%grab lin plant outputs for comparison
SimOpt = mpcsimopt(MPCobj);
%set simulation options w/
initial values
uold = [uis(end,l);uis(end,2)];
xmpc = mpcstate(MPCobj,xpinit, [}, [],uold);
%set the MPC state for sim
%assign control initialization
set (SimOpt, 'PlantInitialState' ,xpinit, ...
149
. ........
....
............
.......
'ControllerInitialState',xmpc);
v = interpl(simin.Time,simin.Data,t-f:ts: (t-f+tau-ts));
%next timestep disturbance
vel
tmpc
(reference signal)
v'; %set velocity reference from Vref
=
=
tf:ts:(t-f+tau-ts);
%create a time vector for control timeseries
for
j = 1:T
Tmtr(j,l) = 95.6189*tanh((tmpc(j)-(t-final/3))/(t-final/3)) ...
+27.8228+273.15; %hyperbolic tangent for ref value shaping
Tliq(j,l)
=
Text(j,1) =
(75/t-final)*tmpc(j)-45;
(0.2/t-final)*tmpc(j)-45; %values for MPC set pts
end
r =
[vel Tmtr Tliq Text];%reference signal
%do the MPC simulation
(iteration i+1)
[y-mpc, t-mpc, u-mpc, xp-mpc, xmpc-mpc, SimOptions]
=
sim(MPCobj,T,r,SimOpt);
TSmpcl = timeseries(u-mpc (:,1),tmpc);%pump timeseries input
TSmpc2 = timeseries (umpc (:,2) ,tmpc) ;%Vscalar timeseries input
utmat =
[utmat; tmpc']; %create input time matrix
udmat =
[udmat;
u-mpc(:,l)
u-mpc(:,2)
velJ;
%create input data matrix
ymdmat =
rmat =
[ymdmat; y-mpc]; %create matrix of MPC output prediction
[rmat;
rj;
t-cur = t-f %set current time as final time of simulation
close-system (model, 0);
end
%% Output part
150
....
......................
.................
................
..
.....
.......
velref = interpl(simin.Time,simin.Data,ytmat); %create vel ref array
velerr = velref -
ydmat(:,1);
%determine the vel error
toterr = sum(velerr) %output the total error sum
rmatC = rmat;
rmatC(:,2)=rmatC(:,2)-273.15; %convert the reference mtr T to deg C
figure; plot(ytmat,ydmat) %plot the Ys
xlabel('Simulation time
(s) ');
ylabel('Output Values');
legend('velocity (m/s) ','motor T
(^{\circ}C) ',....
'fluid T (^{\circ}C) ','external T (^{\circ}C) ');
figure; plot(utmat,udmat) %plot the Us
xlabel('Simulation time
(s)');
ylabel('System inputs');
legend('vel demand (m/s)','pump demand
(lpm)','vel reference
(m/s)');
figure; plot(ytmat,xStatemat) %plot the states
xlabel('Simulation time
(s)');
ylabel('State values');
figure; plot(utmat,ymdmat);
xlabel('Simulation time
%plot the MPC predictions
(s)');
ylabel('MPC Predicted Output Values');
legend('velocity (m/s) ','motor T (K) ','fluid T (^{\circ}C)
',...
'external T (^{\circ}C) ');
figure; plot(tpmat,ypmat); %plot the linearized Ys
xlabel('Simulation time
(s) ');
ylabel('Linear Output Values');
legend('velocity (m/s) ','motor T (K) ','fluid T
'external T
(^{\circ}C)',...
(^{\circ}C) ');
figure; plot(ytmat,(velerr ydmat(:,l) velref]); %plot velocity
xlabel('Simulation time
(s)');
ylabel ('Velocities (m/s) ');
legend('vel error','output vel','ref vel');
figure; plot(utmat,rmatC) %plot the references
xlabel('Simulation time
(s)');
ylabel ('Reference Values');
legend('velocity (m/s) ','motor T
'fluid T (^{\circ}C)',
(^{\circ}C) ',...
'external T (^{\circ}C)');
151
..............
ypmatC = ypmat;
ypmatC(:,2) = ypmatC(:,2)-273.15;
%convert linear mtr T to deg C
%plot the linearized and measured Ys together
figure; plot(ytmat,ydmat)
xlabel('Simulation time
(s)');
hold; plot(tpmat,ypmatC,':')
ylabel('Measured and Linear Output Values');
legend('velocity
'fluid T
(m/s)','motor T (^{\circ}C)',...
(^{\circ}C)','external T (^{\circ}C)',...
'lin velocity','lin motor T',...
'lin fluid T','lin external T');
152
..
..
............................
....
..
-.:
. ...................
Appendix D
Closed-Loop Simulation Test
Results
The following figures show some of the results of the Simulink closed-loop control
testing.
12
L!LJ~
LY~J
..
...........-
.....
-.. .. ..
10
8
-- .- --
- -- - -- .-........ -- --
-- -- --
-
CL
E 6 -----
-
-----.-.-.
CO,
vel
demand (m/s)
pump demand (1pm) vel reference (m/s)
4
2
0'
2000
4000
6000
8000
Simulation time (s)
10000
12000
14000 15000
Figure D-1: The control commands calculated by the MPC. The velocity reference is
also shown for comparison to the velocity control demand.
153
....................
.. - ---.............
...... .. ..... ....
.
450
. . ........
..... .I......
...
...
....
....
...
......
....
400
350
(U
300
250
- - - - -velocity (m/s)
motor T (K)
-- - -- -fluid T
(C)
a200
150
OD
100
-- -- external T C)
--- - - - - - - -- - -
0
50
.....
-.
..........................
....-.... ......
. ..............................................
~-...
0
-50
)
2000
12000
10000
8000
6000
Simulation time (s)
4000
14000 15000
Figure D-2: The MPC predictions of the output values in response to the control
commands.
120
100
80
-
velocity (m/s)
motor T (C)
fluid T (C)
extemalT(C) -
-- -
--
-
--
--
- -
-
- - - -.-
-.
-. ...
-.
-.
.....
....... ..
..........
..........
...
........-.
60
C1
P1
40
.. ..... ................
...............
-.--.--.--.
-. -.
.-.-. .....
20
-.........
0
..................
......................
-...-.
---.
.......
-..
. ..-. ....
...
............
-
-20
-40
2000
4000
8000
600 0
Simulation time (s)
10000
12000
14000 15000
Figure D-3: The output reference values used in the control. The motor temperature
reference (green) is a hyperbolic tangent function specifically fit to follow the natural
response of the motor temperature when following the velocity reference (blue), a
trapezoid that requests 90% motor speed at the plateau.
154
_
_."I
Bibliography
[1] Ethylene propylene rubber (EPM, EPDM). http: //www.matweb. com/search/
DataSheet . aspx?MatGUID=f8e3355cc2c541fbb0174960466819c0&ckck=1 Online.
[2] Modelica and the modelica association. https: //www.modelica. org/. Online.
[3] Code of federal regulations, title 49, part 193, subpart g, 1980. Online.
[4] Appendix 1: Property tables and charts (SI units).
http://highered.
mcgraw-hill. com/sites/dl/free/0073398128/835451/Appl.pdf, 2010. Online.
[5]
EC-max 40 040 mm, brushless, 120 watt. http://www.maxonmotorusa.com/
medias/sys-master/8800984956958/12_.171_EN.pdf, 2012. Online.
[6] Fifth progress report, 2012. Progress report on the robotic inspection project as
a collaboration between MIT and Qatar University.
[7] RE 40 040 mm, graphite brushes, 150 watt. http: //www.maxonmotorusa. com/
medi as/sys _mast er/8800950812702/12_082_EN. pdf , 2012. Online.
[8] Standard Liquid Cold Plate PT Zed 1518.
http: //www. priatherm. com/
datasheets/dataX20sheet%20PTZed_1518.pdf, 2012. Online.
[9] Best practice-buildings library user guide. http: //simulationresearch. ibl.
gov/modelica/userGuide/bestPractice.html, 2013. Online.
[10] bvp4c. http: //www. mathworks. com/help/matlab/ref /bvp4c. html, 2013. Online.
[11] Estimate state-space model using a subspace method. http: //www. mathworks.
com/help/ident/ref/n4sid.html, 2013. Online.
[12] fmincon.
Online.
http://www.mathworks.com/help/optim/ug/fmincon.html,
2013.
[13] Simulate controller with nonlinear plant. http://www.mathworks.com/help/
mpc/gs/simulations-involving-nonlinear-plants.html, 2013. Online.
155
[14] Work-arounds-buildings
users
library
guide.
http: //
simulationresearch.lbl.gov/modelica/userGuide/workArounds.html#
reducing-nonlinear-equations-of -serially-connected-f low-resistances,
2013. Online.
[15] A. Abhat. Low temperature latent heat thermal energy storage: Heat storage
materials. Solar Energy, 30(4):313-332, 1983.
[16] R. Akhilesh, A. Narasimhan, and C. Balaji. Method to improve geometry for
heat transfer enhancement in PCM composite heat sinks. International Journal
of Heat and Mass Transfer, 48(13):2759-2770, 2005.
[17] D. Arcury and E. Heller, 2013. Personal Communication.
[18] A. Bemporad, M. Morari, and N. Lawrence Ricker. Model predicitve control
toolbox user's guide. Technical report, The MathWorks, Inc., Natick, Mass.,
2013. User's Manual.
[19] E. D. Buchanan, D. J. Benford, J. B. Forgione, S. Harvey Moseley, and E. J. Wollack. Cryogenic applications of commercial electronic components. Cryogenics,
52(10):550-556, 2012.
[20] J. Buschle, WD Steinmann, and R. Tamme. Analysis of steam storage systems
using modelica. In 5th InternationalModelica Conference, Vienna, Austria, 2006.
[21] Cabot
Corporation.
Aerogel
thermal
wrap
insulation.
http:
//www. cabot-corp. com/Aerogel/Industrial-and-Cryogenic/Products/
PR201005131338PM6352/. Online.
[22] K. Dietl, J. Vasel, S. Gerhard, W. Casas, and C. Mehrkens. Modeling of cold
plates for power electronic cooling. In Bernhard Bachmann, editor, 6th International Modelica Conference, pages 627-628, Bielefeld, Germany, 2008. The
Modelica Association.
[23] Dynalene. Dynalene HC. http: //www. dynalene. com/pdf/HC. pdf, 2009. Online.
[24] Dynalene. Dynalene HC Heat Transfer Fluid Engineering Guide, 2012. Manufacturer's Guide.
[25] R. Fernandez, E. Gonzilez, V. Felidl, and A.G. Rodriguez. A wall climbing robot
for tank inspection. an autonomous prototype. In 36th Annual Conference on
IEEE Industrial Electronics Society, pages 1424-1429, 2010.
[26] E. Hage. Choice of electric motor: Avoid overheating and over-dimensioning.
Technical report, specAmotor, Confirmat, The Netherlands, 2007.
[27] F. P. Incropera and D. P. Dewitt. Convection correlations: Noncircular tubes.
In Fundamentalsof Heat and Mass Transfer, pages 495-496. John Wiley & Sons,
Hoboken, NJ, 5 edition, 2002.
156
[28] F. P. Incropera and D. P. Dewitt. Free convection. In Fundamentals of Heat
and Mass Transfer, pages 539-543. John Wiley & Sons, Hoboken, NJ, 5 edition,
2002.
[29] F. P. Incropera and D. P. Dewitt. Fundamentals of Heat and Mass Transfer,
pages 545-546. John Wiley & Sons, Hoboken, NJ, 5 edition, 2002.
[30] F. P. Incropera and D. P. Dewitt. Introduction to convection. In Fundamentals
of Heat and Mass Transfer, volume 5, page 355. John Wiley & Sons, Hoboken,
NJ, 2002.
[31] F. P. Incropera and D. P. Dewitt. One-dimensional, steady-state conduction. In
Fundamentals of Heat and Mass Transfer, pages 126-144. John Wiley & Sons,
Hoboken, NJ, 5 edition, 2002.
[32] Intel Corporation.
Intel(r) atom processor d525 (IM cache, 1.80 GHz).
http://ark.intel.com/products/49490/Intel-Atom-processor-D525-/
281M-Cache-1_80-GHz429. Online.
[33] JPL. Mars science laboratory:
mission/rover/body/. Online.
Body.
http: //mars. jpl.nasa.gov/msl/
[34] JPL. Mars exploration rover mission. http://marsrover.nasa.gov/mission/
spacecraft rover-body.html, 2011. Online.
[35] JPL. Mars exploration rover mission. http://marsrover.nasa.gov/mission/
scrover-temp-heaters.html, 2011. Online.
[36] JPL. Mars exploration rover mission. http://marsrover.nasa.gov/mission/
spacecraft rover-temp.html, 2011. Online.
[37] L. P. Kalra, J. Gu, and M. Meng. A wall climbing robot for oil tank inspection. In
IEEE InternationalConference on Robotics and Biomimetics, pages 1523-1528,
2006.
[38] L. P. Kalra, Weimin Shen, and J. Gu. A wall climbing robotic system for non destructive inspection of above ground tanks. In Canadian Conference on Electrical
and Computer Engineering, pages 402-405, 2006.
[39] M. Krstid and Hsin-Hsiung Wang. Stability of extremum seeking feedback for
general nonlinear dynamic systems. Automatica, 36(4):595-601, 2000.
[40] W. E. Larimore. Canonical variate analysis in identification, filtering, and adaptive control. In Proceedings of the 29th IEEE Conference on Decision and Control, pages 596-604 vol.2, 1990.
[41] J. Leland and G. Recktenwald. Optimization of a phase change heat sink for
extreme environments. In Ninteenth Annual IEEE Semiconductor Thermal Measurement and Management Symposium, pages 351-356, 2003.
157
Aspects and experiences of user choices in subspace identification. Technical Report LiTH-ISY-R-2564, Department of Electrical Engineering,
Linkping University, SE-581 83 Linkping, Sweden, Dec 2003.
[42] L. Ljung.
Design and con[43] H. Lun, F. Filippone, D. C. Roger, and M. Poser.
in Europe and
tanks
storage
struction aspects of post-tensioned LNG
http://www.contech.co.nz/uploaded/Post-tensioned*/*20LNG/*
Australia.
20Storage%2OTanks.pdf, 2006. Online.
[44] S. Mannan. Lee's Loss Prevention in the Process Industries, volume 1-3, pages
33-40. Elsevier Butterworth-Heinemann, Burlington, MA, 2005.
[45] S. Mannan. LPG storage. In Lee's Loss Prevention in the Process Industries,
volume 1-3, page 20. Elsevier Butterworth-Heinemann, Burlington, MA, 2005.
[46] Modelon AB, Ideon Science Park, LUND. FMI Toolbox User's Guide 1.4.4, 2013.
[47] M. Otter. Modelica overview, 2011.
[48] Pacor Incorporated. Aerogel insulation.
aerogels.html, 2012. Online.
http: //www . pacorinc . com/pro-_
[49] RL Patterson, A. Hammoud, and M. Elbuluk. Assessment of electronics for
cryogenic space exploration missions. Cryogenics, 46(2):231-236, 2006.
[50] S. W. Ryu, J. J. Park, S. M. Ryew, and H. R. Choi. Self-contained wall-climbing
robot with closed link mechanism. In IEEE/RSJ International Conference on
Intelligent Robots and Systems, volume 2, pages 839-844 vol.2, 2001.
[51] J. Savall, A. Avello, and L. Briones. Two compact robots for remote inspection
of hazardous areas in nuclear power plants. In IEEE International Conference
on Robotics and Automation, volume 3, pages 1993-1998 vol.3, 1999.
[52] H. Schempf. Neptune: above-ground storage tank inspection robot system. In
IEEE International Conference on Robotics and Automation, pages 1403-1408
vol.2, 1994.
[53] C. Schmid and L. T. Biegler. Quadratic programming methods for reduced
hessian SQP. An International Journal of Computer Applications in Chemical
Engineering, 18(9):817-832, 1994.
[54] Silverwing. Handscan MFL2000, 2012. Online.
[55] A. Stupar, U. Drofenik, and J. W. Kolar. Optimization of phase change material heat sinks for low duty cycle high peak load power supplies. Components,
Packaging and Manufacturing Technology, IEEE Transactions on, 2(1):102-115,
2012.
http://www.techcorr.com/services/
OTIS FAQ.
[56] TechCorr USA LLC.
2012. Online.
cfm,
Inspection-and-Testing/OTIS-FAQ.
158
[57]
Thermablok Incorporated.
Aerogellaerogel
thermablok. com/index. htm, 2012. Online.
insulation.
http://www.
[58] Y. Tundi and E. Heller, 2012. Personal Communication.
[59] M. Verhaegen. Identification of the deterministic part of MIMO state space
models given in innovations form from input-output data. Automatica Special
issue on statistical signal processing and control, 30(1):61-74, 1994.
[60] Weimin Shen, J. Gu, and Yanjun Shen. Proposed wall climbing robot with
permanent magnetic tracks for inspecting oil tanks. In IEEE International Conference Mechatronics and Automation, volume 4, pages 2072-2077, 2005.
[61] M. Wetter. Modelica buildings library. http: //simulationresearch. ibl. gov/
modelica, 2013. Online.
[62] D.
Woligroski.
A
beginner's
guide
for
WaterCool-
ing
your
PC.
http://www.tomshardware.com/reviews/
a-beginners-guide-f or-waterc ooling-your-pc, 1573. html, 2007.
Online.
[63] J. Yu and H. Zhao. A numerical model for thermoelectric generator with the
parallel-plate heat exchanger. Journal of Power Sources, 172(1):428-434, 2007.
159