Challenge: Predicting The Future¶
This course is, in a sense, about predicting the future. In fact, nearly all of engineering design is about predicting the future. When an engineer decides to "design" something, the process of making decisions about what form that "something" should take, from how big it is, how much it must weigh, what it should be made out of, what components it will have, how much it will cost... virtually all of these "small" decisions boil down to attempts by the engineer to predict how the product (or policy) will hold up to its intended use.
The truth is, the discipline of engineering is all about developing tools that can help you predict the future of the objects you wish to create, control, or change for the better. Even though your "tool box" for doing this is small as you walk into this course, it is not empty. You, a human (I presuppose), predict the future all of the time. Sometimes, you even do this without involving your conscious thought processes.
What do you mean I can "predict the future?"¶
Set your phone down in front of you. Then close your eyes, wait a few seconds, and pick up the phone.
How did you do that? Perhaps your brain coded the phone's location in a spatial map representing your surroundings relative to your current location. But even if that were the case, you also knew to reach for the location your phone was in when you put it down. Why? Because you also had a mental model representing your belief about how the phone's position relative to you would evolve over time. Reaching for the phone after closing your eyes required you to predict the future of the phone's location. While it is not known precisely just what those models inside your brain look like or how they are built, engineering models are much better understood. In this class, we will learn how to build engineering models that describe the world around us using math.
What is a Model?¶
A model, or more precisely, an engineering model, is a representation of something we want to understand. The word representation here means that while a model represents something real, and can even predict the behavior of that real thing quite accurately, it is not the same as the real thing. A model airplaine is a good example of a physical model of what we would call a "true" airplane that carries people and cargo over long distances. While it shares some features of the real airplane, it is different in some fundamental ways, such as its power source, size, and flight time. It cannot do everything that a real airplane can do... but it does enough things similarly enough that we might better understand how real airplanes work and/or how they should be built by building a model.
An engineering model can be physical, like a model airplane, or it may not be. What makes a model an engineering model is its utility for designing and/or understanding the thing it is supposed to represent.
The engineering models we will be building in this class will rarely (if ever) be physical models. They will mostly be comprised of mathematical equations that help us predict the behavior of physical things or processes that we wish to build or understand. The mathematical equations representing the thing or process we wish to understand will, if we do our jobs correctly, allow us to predict what will happen when something changes.
This ability to "predict" using a model is fundamental to engineering. If engineers needed to simply change design elements randomly, building full-sized airplanes over and over until one worked "just right," engineering as a discipline would be incredibly dangerous, expensive, and inefficient. Using mathematical equations to tell us what will happen when we build a design or implement a policy can allow us to avoid many costly and dangerous mistakes that would result from a "trial and error" approach.
While it would be a strange coincidence if your brain used "engineering models" in the sense defined above, thinking about how your conscious, human "self" might build a model of your attempt to grab a phone is still a useful way to conceptualize how your brain seems to predict what will happen around you. You might imagine that you could plot your brain's expectation (or prediction) for the phone's position relative to you as a function of time. That plot might look like this:
Note that on this plot, I drew predictions in gray. The actual observation you made of the phone's position before closing your eyes is in black. The behavior of the phone in the exercise is admittedly not very interesting. In reaching for your phone, you probably expected that it would be "right where you left it," which is how you "knew" where to send your arm when you reached to grab the phone. If you grabbed your phone on the first try, your subconscious's model of the phone's behavior was "usefully accurate."
Our subconscious is, as it turns out, pre-calibrated to build usefully accurate models of our surroundings. It is better at building some types of models than it is at others. It's how we manage to thrive in a world full of uncertainty. When your brain's model of a situation isn't quite good enough (did you miss the phone the first time you grabbed for it?) it can usually learn to be better next time.
This course is about learning to build engineering models that are useful for predicting the behavior of complex systems we are interested in understanding. As engineers, we often build models to predict how our design decisions will impact the performance of a "thing" we make. Sometimes, we build models to understand how a policy or device we create will impact its environment... by predicting how changes in a complex system will impact its behavior, we can make better decisions about just what sorts of impacts changes or additions to a design might have.
So let's take that idea and think about our cell phone experiment. Your phone is incredibly complex, more powerful than desktop computers were when you were young. It can crash the stock market, recognize your face, guide you somewhere you've never been, or keep you in touch with friends who are thousands of miles away.
And yet, for the purposes of attempting to hold this incredibly complicated machine in the context of our experiment, all you needed to know was where you left it! The reduction of your cell phone to a static, unchanging three-dimensional point in space is an obvious choice if you don't think too much about it... but it's staggering if you do.
How did your brain know that the model for your phone could be so simple? How would you know whether to account for a sudden earthquake, or a mischevious friend who, after your eyes were closed, might see fit to move your phone? Somehow, your brain was able to make good engineering decisions about what was important, and what was not.
This course will teach you to build that skill into your conscious toolset as you grow into an engineer. The key, for us, will be to use a "systems approach" to model building.
Systems Approach to model building¶
In this course, We will focus on using a systems approach to building models. A systems approach is powerful because it acknowledges and respects the interconnectivity of the things we make with the world that they exist in. "System" models should be as simple as possible while still respecting the dimensions of interconnectivity that produce important behavior.
A strict definition of the "systems approach" is difficult to get all practitioners to agree upon. In fact, terms like "system dynamics" or "systems approach" usually mean totally different things to businesspeople, mechanical engineers, economists, or sociologists!
While you may encounter lots of definitions to "system dynamics" or "systems thinking" in your career as a global citizen, most people who build engineering models of systems for a living agree that taking a systems approach to modeling means starting with a wide lens and looking at the big picture. How does the system we wish to model interact with its surroundings? What pieces of the system interact with each other? What interactions are important to predict the system behavior we're interested in, and what interactions can be ignored?
Asking these questions encourages us to build the simplest possible engineering model capable of telling us what we'd like to know. Once we evaluate that model by doing an experiment, we might decide our model was too simple. At that point, we can modify our approach to "dig deeper" and increase our model's complexity. We start with a "big picture" view when we use a systems approach to reduce the risk that we will miss important interactions between the system and its environment.
For instance, we now know that studying the progression of COVID-19 at the per-person level is extremely important. However, if we were to keep our analysis only at the per-person scale, we risk missing important population-level dynamics of the disease's progression, mutation, and treatment, which have the potential to affect an individual's experience with the disease. A systems approach to studying COVID-19 might take a population-level view first, and "drill down" to the individual and cellular dynamics of the disease as necessary to refine the population-level model, treating the population as the "system" to understand, rather than an isolated individual or cell.
But before we dive too deep, we should take a moment to be clear about what we mean by a "system."
What is a System?¶
A system refers to any collection of items, pieces, or subprocesses that we call elements. These elements interact to produce a behavior we are interested in understanding and/or predicting. A system is generally described as an "isolated slice" of the universe. Anything inside that "slice" is part of the system. Anything outside of that "slice" is called the system's "environment," or its surroundings.
This means that while a system may exchange energy, material, and/or information with things that are outside of its boundaries, changes in the system's behavior are generally driven by its environment, rather than the other way around.
What is an Element?¶
Elements are the "atomic units" of a system. They can be either processes, physical objects, or collections of physical objects. Their relevant behavior can be represented completely by an equation or set of equations describing how they interact with either other elements in the system or with the system's surroundings.
Elements could, in theory, be modeled as "systems" themselves, with their own sets of interacting elements. However, when we declare that something is to be considered an "element" in a system, it means that we are not interested in unpacking its behavior or construction any further.
For example, a bus could be considered an "element" in a transportation system. The bus itself could be modeled as a system comprised of elements like wheels, springs, an engine, and so on. However, when we say that the bus is an element in our transportation system, it means that we are considering the bus to be an irredicible building block in our definition of the transportation system. Perhaps this bus's behavior of interest could be modeled using only an equation relating the time of day and a "traffic congestion factor" to its position along a route.
It's true that this is a bold simplification of a bus's behavior. By making the declaration that this bus's position is the only thing we care about, and that this position can be known using only two independent variables, we are assuming a lot. We are ignoring a lot. What if the bus breaks down? Why don't we care about how it bounces over potholes, or how much fuel it uses?
Well, we can't model everything. When we decide to consider building a model of the "transportation system," we must immediately begin simplifying reality. We have to decide where the system (as we define it) begins and ends, and what level of complexity is required to know what we need to know about the system.
This leads us to a pair of fundamental truths about engineering models:
- All models are wrong because they do not include every nuance of every phenomenon that may impact a system's behavior
- Good models a useful because they sufficiently predict the system's behavior. They are still "wrong" in the sense that there are phenomena they will either ignore or predict inaccurately, but they are "accurate enough."
Building good models is the goal, and in ES103, we will use a simple three-step process to build a model.
What is a DYNAMIC System?¶
A "Dynamic System" is any system whose behavior varies significantly with time when one of its inputs or operating conditions changes. A bridge may be a system of composed of beams that interact with one another, but if we look on a short enough time scale (years rather than decades, perhaps), the bridge's behavior may or may not vary interestingly in time, even if its elements all play interacting roles to support the weight of passing traffic. At Lafayette, ES230 (Statics) considers "trusses" (like bridges) that fall into this category.
However, it is only our model of a bridge that may not display time-varying behavior. Real bridges do have behavior that varies in time; it's just that as engineers, our model scope may not always include time-varying behavior. For an example of an incorrectly scoped model of a bridge, you could read about what happened to the Tacoma Narrows Bridge), which collapsed due to vibration (time-varying behavior) that it was not designed to withstand, since the engineers' model scope did not consider that type of behavior.
In ES103, we will be almost exclusively considering models of dynamic systems, meaning that we are interested in how the system's behavior evolves over time. Dynamic Systems display many types of behavior when subjected to a sudden change in input conditions, but many will show behavior in their outputs (quantities of interest) that can be roughly grouped into one of the following categories:
The categories of system behavior above are basic-- some complex systems exhibit combinations of these "prototypical" responses. Still, categorizing system behavior this way, and grouping systems into "families" that exhibit responses such as linear growth, exponential growth, exponential decay and/or approach, overshoot and oscillation, is often useful because it helps us develop expectations for and interpretations of a system's behavior when we observe it.
Disciplined Process for Model Building¶
In ES103, we will follow the following general procedure for building models of systems. Each of the steps in the diagram below is explained in more detail in the following sections.
At the beginning of the course, we will take a broad view of each of these steps. As we need more detail, we will develop more detail. However, the course is designed to get you using the whole process right away! For now, we will move through these steps in chronological order.
Model Scoping¶
When we attempt to model a phenomenon or series of interconnected phenomena as a "system," we are looking for a collection of elements that interact with each other and the system's surroundings to produce the behavior we are interested in understanding. Defining the boundary that indicates what is "inside" the system and what is not is what we will call model scoping. The process of "scoping" a system model involves drawing the system boundary, and answering the following three questions:
- What quantities (energy, material, information) go in to the system boundary that are relevant to the behavior we're interested in?
- What quantities (energy, material, information) go out of the system boundary that are relevant to the behavior we're interested in?
- What quantities (energy, material, information) are stored within the system boundary?
Asking yourself these questions can actually help you determine what your system model's boundary should look like. When we think about scoping a system, we are trying to identify a relatively isolated "slice" of the universe that produces the behavior we're interested in. Some interesting phenomena require a very broad scope, and some require us to consider only a tiny collection of "elements"-- sometimes even one is enough. Consider the following picture, which shows a few possible system boundaries.
Let's think about a few of these system boundaries and discuss the answers to the three questions posed above. What would the utility of each of these system scopes be? Some examples are given below:
A. System A shows a boundary around the earth's atmosphere. We may be interested in the concentration of stored CO2 in the atmosphere. CO2 might enter the system boundary from human-driven operations like manufacturing via factories or transportation, amongst other similar processes of CO2 exchange. CO2 might leave the atmosphere by being absorbed, for example by vegetation.
B. System B, which encompasses a factory, maybe a useful system scope for an industrial engineer to optimize the factory's efficiency and/or productivity. Material and energy both enter the factory. Some of that energy and material leave the factory in the form of gas emissions, solid waste, and/or heat. Some material probably leaves the factory in the form of the product it produces. Interacting elements in this factory could include, but are not limited to, the portion of an assembly line represented by system C.
G. System G represents a single hip joint on a quadruped factory robot, and could be used to understand how the robot's motors should be powered to produce appropriate walking motion. Energy flows in to the system boundary to power its motor. That energy is stored inside of the system boundary by the inertia of the gears and limbs, and some energy leaves the system boundary via heat and work done on the robot's body.
Ask yourself what goes in, goes out, and is stored in the other system definitions in the graphic. What material, energy, or information goes into, comes out of, and is stored in each? What questions could each of these system scopes answer? What could some limitations for each be?
Clearly, if an engineer only wants to optimize the design of a piston (System J) in an engine so that it can handle the forces of combustion, the engineer would probably not need to consider much (or any) of what is defined in system A's scope. Conversely, the model scope defined in J is probably not very helpful for predicting atmospheric CO2.
Scoping is something we will continue to refine over the course of the semester. It is only the first step in modeling a system, but it is both extremely important and easy to get confused by-- don't despair! Your knack for scoping will improve with practice.
Model Construction¶
Model Construction is the process of building the equation(s) that represent the behavior of the system we defined in the "Model Scoping" step.
Model Construction varies a lot by sub-discipline in engineering, but it can be reduced to the following general procedure:
- Define the model's independent variables. These are quantities that are known before the model's equations are evaluated. They may be physical parameters like mass, they may be parameters that characterize a process, such as death rate. They may be quantities that vary in a known way, such as time or a spatial coordinate. A model's independent variables are often called "inputs" if they are quantities that may vary with space or time, and often called parameters if they are unchanging.
- Define the model's dependent variables. These are quantities that result from the interactions between system elements and either one another or the system's surroundings. The dependent variables nearly always describe the phenomena your system is supposed to predict. A model's dependent variables are often called "outputs."
- Use a disciplined process to relate the model's independent variables to its dependent variables.
Step 3 is probably the most complex of the three, and it is the one that can differ wildly from discipline to discipline. For example, the way an environmental engineer goes from a list of model inputs and outputs to a final equation will be quite different from the way a mechanical engineer might accomplish the same goal.
The processes used to actually relate a model's inputs to its outputs might be the use of an empirical relationship, or perhaps Newton's laws, or perhaps the conservation of energy. We will focus on only a small subset of the methods for model construction in this course, but for us, step 3 involves rigorously defining our system's elements, how each behaves, and how each interacts with the others.
It is in this step that you will need to decide what level of detail you will use to represent each of the elements in your system scope. Simple is often a good place to start! If, when you evaluate your model, you find its accuracy lacking, you may consider increasing the level of detail with which you represent each element, or whether the system scope you chose was appropriate.
Model Evaluation¶
Once a model is constructed, it must be evaluated to see how well it matches the system it is supposed to represent. This is typically done by conducting an experiment on the real system if possible, collecting data, and comparing those data to the output(s) of the model. It is important that if data were used in the construction phase to determine relationships between elements in the model, new data under different conditions are collected for the evaluation phase. This will help inform us about how well the model generalizes, or represents the behavior of the model under new circumstances.
Challenge in Practice¶
Now, let's use these three steps to create an engineering model that we could use to represent what happened during this experiment.
System Model Scoping¶
The first step is to scope the system we wish to model. While it is true that your brain's scope for the system might well be (almost certainly is) different than what we come up with here, we will start by considering the simplest possible model that describes what happened. In this experiment, nothing important about the environment changed when we closed our eyes. The only thing we required to predict the phone's future position was our observation of where it was when we set it down. Therefore, we could consider the following system scope as appropriate to start:
In this scope, I include only ome element in my model-- the phone itself. I decided on this scope by asking the three questions central to model scoping:
Question 1: What quantities (if any) go in to the system boundary that are relevant to the behavior we're interested in?
Answer: Information about the position of the phone crosses from the system's surroundings into the system boundary as a source of information. This information would, in theory, come from my brain measuring the phone's location using my eyes.
Question 2: What quantities go out of the system boundary (if any) that are relevant to the behavior we're interested in?
Answer: No information, material, or energy leaves the system boundary... I don't think. If the model construction or evaluation steps indicate that this is a mistake, I can revisit it later.
Question 3: What quantities are stored within the system boundary?
Answer: Information about the phone's position is stored in the model. Note that at this point, I haven't decided whether the phone "has legs" or will spontaneously teleport to a new location based on some equation. All I know is that for my model to be useful, it has to tell me where the phone is at some future time.
This may seem like a trivial exercise, but as the complexity of the systems we consider increases, it is a very important step to complete before trying to construct the model. Having scoped the system we're considering, we already know what we want out of it and what goes into it when we construct the model.
This sets us up to think carefully about what goes into the model. In this case, it's not much!
Model Construction¶
Now it's time to actually construct the equations that relate our input to our output over time. Here, we have to complete the three steps of model construction:
- Determine system inputs and parameters (independent variables)
- Determine system outputs (dependent variables)
- Relate independent to dependent variables
Because of our choices regarding system scope in the prior step, we are looking specifically for an equation or set of equations that describes how the 2-dimensional (XY) position we last observed the phone (an independent variable) relates to where the phone will be in the future (our only dependent variable). We're talking about future positions, so we should also include time as a possible independent variable in our model.
Because we're looking for equations, we will need some definitions. We will define the predicted position of the phone in 2D space, with X pointing to our right, and Y pointing forward:
$$\vec{r}_p = [x_p,y_p]$$The arrow above $\vec{r}_p$ indicates that the quantity is a vector. We will discuss vectors in more detail later, but for now, suffice it to say that a vector is a quantity that we cannot describe with just one, single number. We need, at a minimum, the phone's two predicted coordinates $x_p$ and $y_p$ in order to fully define where the phone is in 2D space relative to us.
We will define the observed position of the phone when we closed our eyes similarly as
$$\vec{r}_o = [x_o,y_o]$$Now, this allows us to write the simple, mathematical statement that "the phone does not move over time once we close our eyes." This can be written as a set of equations:
$$x_p(t) = x_o$$$$y_p(t) = y_o$$The notation $x_p(t)$ indicates explicitly that $x_p$, or predicted x position of the phone, is a function of time. The observation we made when we closed our eyes, is not a function of time. The first equation states that the phone's predicted x location will be equal to the phone's last observed location "forever." The second equation says that the phone's predicted y location will be equal to the phone's last observed y location "forever."
That's it! Because the output of the model, $\vec{r}_p (t)$, is just an ordered pair $[x_p (t), y_p (t)]$, we now have all the information we need to construct an engineering model of the system in the experiment. This allows us to move on to evaluating the model.
Model Evaluation: Measurements and Data¶
To evaluate our model, we will need to compare our model's predictions to actual data. Because we don't have data for the literal experiment you did while reading this notebook, we will have to use some that I collected using a camera that measured phone position as a function of time. In my version of this experiment, I set the phone down 0.6 meters in front of me, and 0.3 meters to the right of my body's centerline. The measurements from this experiment, which were taken three times per second until the phone was grabbed at 3 seconds, are given below.
| time (s) | $x_m$ (m) | $y_m$ (m) |
|---|---|---|
0.00 | 0.30971 | 0.60488 0.33| 0.30257| 0.59457 0.67| 0.29679| 0.59547 1.00| 0.28845| 0.59834 1.33| 0.29532| 0.59888 1.67| 0.29188| 0.60318 2.00| 0.29878| 0.59552 2.33| 0.29973| 0.59810 2.67| 0.29287 | 0.59592 3.00| 0.30233| 0.60873
In the table, $x_m$ and $y_m$ are given the subscript 'm' to indicate that they are measurements and we list their units (m) in parentheses to make it clear what sort of distances we are talking about. You will notice that, accoording to the measuremments we made, the phone does not in fact stay still! But what does this mean? Does it mean that we were wrong about our model scope or model construction?
Not necessarily! Measurements of 'real' phenomena always have some error. Sometimes it is hard to tell whether disagreement between your model and measurements is due to the fidelity or accuracy of your model, or whether it is due to measurement error. Well-calibrated sensors are very helpful here.
To see just how well our model fits our measurements, we will use the MATLAB/Octave programming language. We can execute code directly inside this document using this language! Some basic information about how to do this is given below.
The information below is not related to our example. We will return to our example as soon as we get through a bit of technical material that will give us the tools we need to complete the model evaluation phase of our example. If we are to construct engineering models, we need a "common language" with which to make computations, present our data, etc.
Basic Operations in the MATLAB/Octave Programming Language¶
Octave, which is the open-source version of MATLAB, can be used as a simple calculator. Operations are performed one line at at time. See the "cell" below, which defines two variables, adds their values on one line, and then multiplies them on the next. More information about basic arithmetic operations can be found at this link. To "run" or execute the code in this cell, select it, and then hit Shift+Enter (Hold Shift, then hold Enter as well).
If you are very new to computer programming, and even if you are not, you will probably benefit from reading section 1 of The ES103 Programming Resource, especially if what follows seems a little confusing to you. We will be learning programming skills by needing them a little at a time to solve particular problems, so you should not approach reading the programming resource (or any other document) as a "how-to" of computer programming. Many spoken and written languages are learned effectively by immersion, and programming languages are no different. You will learn by trying, struggling, and self-correcting, because your learning is itself a dynamic system!
% a comment, which is not executed, is noted by a %. In Jupyter, make sure this % is followed by a space.
% use comments to tell the reader what we are doing. First, we "define" a variable a to be the number 2.
a = 2; % the semicolon at the end of the line means "don't show me this when you execute the code."
% now, we will define a second variable. Variable names should be descriptive when possible.
b = 3.02;
% now we will add them together.
c = a+b % note there is no semicolon, which means the code will "Show" us the result
d = a*b %same here. When you run this cell, think about what you expect to see!
Often we need "arrays" or lists of numbers in order to plot data. MATLAB can also perform arithmetic on these, as shown below.
More detailed information about accessing and manipulating arrays in MATLAB can be found here and here.
If you have trouble understanding what is happening in the cell below, I suggest you visit both of these links.
% let's create a matrix (an array) of numbers. One column will represent time, and the other will represent "f," which we have computed as some function of time.
% arrays are defined by row. a semicolon inside the definition of the array, which begins and ends with [], means "create a new row"
data = [ 1 10; 2 11; 3 10; 4 9; 5 8] %no semicolon at the end... we should see this one when we execute.
% let's subtract 1 second from all of the times in 'data.' We can access the "times" in our data, or the first column only, as follows:
data(:,1) = data(:,1)-1 %notice that we have UPDATED all values in the first column of the array. the colon : in data(:,1) represents "all rows" in the "first column"
% Now, let's say we need to convert the units of column 2 from meters to centimeters. We could do this by multiplying all elements in the second column by 100.
data(:,2) = data(:,2)*100
%when you run this cell, you will see "Data" printed three times, with the updates we made as we made them.
One of the major advantages of MATLAB/Octave as a language is its built-in data visualization (plotting) capability. Let's imagine that we wanted to plot "f" vs. time for the fictitious data above. We could do this using the functionality in the following cell. Note that the Jupyter notebook (this document) "stores" the values of our variables from cell to cell, so we can access "data" in the cell below to plot it. more information about plotting and line styles is available here.
% first, let's "pull out" time and "f" from our data matrix, so that each is a simple, nx1 (n rows by 1 column) array.
t = data(:,1); % we don't need to see it, do we? If you want to look at it, remove the semicolon.
f = data(:,2);
%now use the "figure" and plot" commands to create a new figure, and then plot x (time) vs. y (f) on a set of axes.
figure %just call this to create a new figure
plot(t,f,'k-x') %this command tells Octave to plot f vs. t in black with x at each data point and a line connecting them (color codes available at the link above)
xlabel('Time (s)') % a proper plot has x and y axes labeled!
ylabel('f (units)')
axis([0 max(t) 0 max(f)]) % this is optional, but allows us to set the scale of the plot. Format is axes([ min_x max_x min_y max_y])
Because we often want to make comparisons between predictions and data in MATLAB/Octave, we often need to plot more than one thing on one figure. This is shown below.
% consider that, in addition to plotting "f" above, we want to plot "g," which is a second array of values we create using an EQUATION
% that represents g(t). We will use MATLAB to implement this function and plot its results on top of "f"
% recall that 'data' and 't' should still be defined from when we executed the cells above. If they are not, we will see a descriptive error message.
% let's define 'g' as our function of time. note that element-wise multiplication and power operations (raising each element to a power, for instance) require a period before the operator symbol.
g = -1000 * (0.005.*(t-2).^2) + 1000; % also note the parentheses here to make the order of operations very explicit.
%now plot g and f both versus time.
figure
plot(t,data(:,2),'k-x',t,g,'r')
xlabel('Time (s)')
ylabel('output')
%note the new command here, which produces a LEGEND telling us which color is which thing.
legend('f','g')
Model Evaluation: Using MATLAB/Octave to evaluate the model of phone position¶
Back to our example. Let's use our "model," defined above, to make an array of predicted positions for the phone, and let's also create an array representing our model's prediction of the phone as a function of time. Note that below, we define variables according to how we defined them when we defined our model in the "model construction" step above.
% define a common time vector. We can just use the same times as our collected data
t = [0 ; 0.33; 0.67; 1.00; 1.33; 1.67; 2.00; 2.33; 2.67; 3.00]; % this will create a 'tall' 10x1 array
% now define our PREDICTED x and y positions, according to our model. We will use variables x_o and y_o to represent "observed" positions
x_o = .3;
y_o = .6;
% now, create an array of predicted positions. Here, we just want x_o repeated 10 times in a 10x1 array. we will use the "ones" function
% in octave to create a 10x1 array of '1', and then we will scale it by x_o.
xpred = x_o * ones(10,1);
% repeat this for ypred, or our predictions for the y value of the phone
ypred = y_o * ones(10,1);
% now we will use the table to create arrays representing our measured positions.
xm = [.30971; .30257; .29679; .28845; .29532; .29188; .29878; .29973; .29287; .30233];
ym = [.60488; .59457; .59547; .59834; .59888; .60318; .59552; .59810; .59592; .60873];
% now we will plot our predicted vs. measured positions. We will make a plot for X and one for Y.
figure
plot(t,xm,'ko',t,xpred,'r.-');
xlabel('Time (s)')
ylabel('X position of phone (m)')
legend('measured','model')
figure
plot(t,ym,'ko',t,ypred,'r.-')
xlabel('Time (s)')
ylabel('Y position of phone (m)')
legend('measured','model')
Now that we have used our model to make predictions, we can evaluate how well our model matches the data we collected. It might seem like there's a lot of disagreement here. However, if we look at the Y scale of the plots, we can see that in actuality, our model is never more than 1cm away from the positions we measured! If we think that this is an acceptable level of accuracy, we may be done, although it would be a good idea to validate our model in a new experiment to test how well it describes the phone's position in another context.
This concludes an entire "lap" through the Modeling process. In fact, this series of 3 steps is the exact same series of steps you will follow all semester! The complexity involved in each off the steps will definitely increase, but this is "the whole job."
Challenge in Practice 2¶
Let's look at another experiment that demonstrates how your brain uses a "model" (not an engineering model) of its environment to help you function in the world. As we go through the exercise, we will think about how the steps above help develop an engineering model to do describe what your brain is doing!
Set your phone down in front of you again. Close your eyes. Then, scoot your chair about a foot or so to the left, and then pick up your phone without opening your eyes.
You probably still did it, right? Maybe with just a little bit of grasping?
Once again, your brain needed to predict where your phone would be when your hand went to grab it. But as good as our brains are after eons of evolution, they are not omniscient. They use models of the comprised of our bodies and their interactions with the world around us to operate, and models are never perfect representations of reality.
In this exercise, we could visualize your brain's expectation about the phone's position relative to you over time using the following plot:
The "model evaluation" your brain was doing without you in each exercise is you actually grasping for the phone. As in the previous exercise, your model was "accurate enough" as far as your brain is concerned.
Assignment¶
In this assignment, your challenge is to construct an engineering model of the second exercise we conducted using closed eyes, a scooted chair, and your cell phone. Again, because you won't be able to collect data yourself, I have collected some for you. In the experiment I did, I followed the following procedure. You can use this procedure to help you construct your model. all times "t" in the procedure are in seconds.
- I closed my eyes before beginning to move.
- Over the course of 3 seconds, with my eyes closed, I moved my chair 0.3 meters to my left with a constant velocity.
- Then, I grabbed my phone.
measurements of the phone relative to me in XY coordinates with X facing to my right and Y facing forward are provided below in one second intervals below for use in the model evaluation step. Time starts at 0 the moment I began moving.
t = [0; 0.5; 1.0; 1.5; 2.0; 2.5; 3.0]
xm = [0.28; 0.43; 0.41; 0.44; 0.50; 0.56; 0.61];
ym = [0.60; 0.60; 0.61; 0.59; 0.61; 0.59; 0.59];For convenience, these are already provided in MATLAB/Octave format so you can copy/paste them into your code.
Deliverables: System Scope¶
In the cell below, paste a picture that shows your system scoping steps. You can do this on paper, take a picture, and paste the picture into the cell, or you can use www.draw.io to make an electronic diagram, then paste a screenshot of your diagram into the cell below.
YOUR ANSWER HERE
Deliverables: Model Construction¶
In the cell below, paste a picture of any hand calculations you make during your model construction process.
YOUR ANSWER HERE
Deliverables: Model Evaluation¶
In the CODE cell below (the above two are text cells called "markdown" cells), construct and execute your code for model evaluation. Then, in the markdown cell below the code cell, proviide an analysis of how well your model matched the data.
% YOUR CODE HERE
error('No Answer Given!')
YOUR ANSWER HERE