Latest / Mechanical Engineering Made Simple / (#122) The Engineering Bridge. Power, The Universal Language of State Variables.

Transcript

(#122) The Engineering Bridge. Power, The Universal Language of State Variables. · Mechanical Engineering Made Simple

• 0:00
  Welcome back design junkies to Mechanical Engineering Made
• 0:02
  Simple. If the podcast brings you value
• 0:05
  help, support the show with a like a follow or leave a comment
• 0:08
  below. Always appreciate the support,
• 0:10
  yeah. So, you know, usually when we
• 0:12
  talk about engineering with the general public, there is this,
• 0:15
  well, this prevailing expectation of absolute
• 0:18
  infallible precision. Cool for sure.
• 0:20
  It's treated almost like a medical diagnosis.
• 0:22
  Exactly like you break your arm right?
• 0:25
  The X-ray shows that jagged white line on the bone and the
• 0:28
  doctor just points at it and says there it is.
• 0:30
  That is the problem. Right, it's viewed as completely
• 0:32
  binary. The bone is either broken or it
• 0:35
  is not broken. It's just a clean, observable
• 0:38
  fact. And I mean, it is incredibly
• 0:40
  comforting to think that way. As human beings, we like things
• 0:43
  to be visible. We like them to be perfectly
• 0:45
  categorized. It makes us feel safe.
• 0:47
  Yeah, exactly. We want to believe that when we
• 0:49
  sit down to design A complex machine like a drone or a car
• 0:53
  suspension or a rocket nozzle, the mathematics will just give
• 0:56
  us this absolute infallible blueprint that perfectly mirrors
• 1:00
  reality. Which is a nice thought.
• 1:03
  But then you step into the actual physical world of dynamic
• 1:06
  systems. You step into this chaotic real
• 1:09
  world mess of mechanical, electrical and fluid engineering
• 1:14
  and suddenly, well, that X-ray machine is broken.
• 1:17
  The blueprint lies to you. It totally lies.
• 1:19
  We are looking at a design landscape that is, to put it
• 1:22
  bluntly, incredibly murky. It is the absolute definition of
• 1:26
  diagnostic Muddy Waters. And you know, that is exactly
• 1:30
  why we are pulling from a incredibly comprehensive manual
• 1:34
  for today's deep dive. Right, the manual on
• 1:36
  mathematical models. Yeah, mathematical daughters of
• 1:39
  dynamic physical systems. It is a dense, rigorous, and I
• 1:44
  mean completely essential breakdown of how we actually
• 1:47
  model systems that move, change and react overtime.
• 1:50
  Because if you don't understand the modeling, you really don't
• 1:51
  understand the system. Exactly.
• 1:53
  OK, so let's unpack this right out of the gate because our
• 1:55
  mission for you today listening to this is exploring the
• 1:58
  ultimate pain point in mechanical engineering.
• 2:00
  The nightmare scenario. Right, the nightmare scenario,
• 2:03
  building physical systems that just vibrate to pieces or
• 2:06
  overheat or simply fail the very second they leave the CAD
• 2:11
  software and enter the physical world.
• 2:13
  Which happens way more often than people think.
• 2:15
  All the time. And why does this happen?
• 2:17
  Usually it's because the mathematical models driving the
• 2:20
  design were completely misunderstood from day one.
• 2:23
  From the very beginning, yeah. So today we aren't just
• 2:25
  memorizing equations, we are breaking down the massive
• 2:28
  misconceptions that screw up designs.
• 2:30
  We're going to walk through step by step fixes.
• 2:32
  And we are showing how to actually optimize a system
• 2:35
  before you spend a single cent on physical prototypes.
• 2:38
  And what's really fascinating here is the sheer cost of
• 2:41
  ignoring this foundational step. I mean, formulating mathematical
• 2:46
  models of dynamic systems isn't just some academic exercise that
• 2:49
  your professors force you to do. It feels like it when you're in
• 2:52
  school though. Oh.
• 2:53
  Definitely, but in the real world, mathematical modeling is
• 2:56
  significantly less costly, incredibly less dangerous, and
• 3:01
  fundamentally faster than building real world test rigs.
• 3:04
  I mean, a good model let's you answer what if questions that
• 3:07
  current technology might not even be able to realize yet.
• 3:10
  Exactly. You can test a spacecraft's
• 3:13
  thermal limits as it reenters the atmosphere.
• 3:15
  Without ever launching a rocket. Right, You can test a
• 3:18
  submarine's crushed depth without drowning a crew.
• 3:21
  Yeah, but the cat? The massive, unforgiving catch
• 3:24
  is that you have to model it correctly.
• 3:26
  And here is where we hit the very first trap that ruins so
• 3:30
  many projects. I like to call it the Build it
• 3:32
  first trap mixed heavily with the simplicity misconception.
• 3:37
  Oh, the simplicity misconception is a big one.
• 3:39
  It's a massive real world issue. Engineers, especially, you know,
• 3:43
  junior ones with access to incredibly powerful software,
• 3:47
  they assume that the absolute best model is always the most
• 3:50
  precise, most complex 1 you can possibly create.
• 3:54
  You see this all the time. They just throw every single
• 3:56
  variable into the simulation. Right, they are modeling the
• 3:59
  wind resistance, the micro friction of a single ball
• 4:02
  bearing the ambient humidity. Only the gravitational pull of
• 4:05
  the moon too. Literally.
• 4:07
  And they assume that because it is complex, it is good
• 4:09
  engineering. But if we connect this to the
• 4:11
  bigger picture, that instinct is completely backward.
• 4:16
  I mean it fundamentally misunderstands the purpose of a
• 4:18
  model. Oh so.
• 4:19
  Well, this brings us to the core modeling trade off, fidelity
• 4:23
  versus effort. A highly complex model requires
• 4:26
  0 assumptions, right? It attempts to map reality
• 4:30
  almost perfect. Which sounds good on paper.
• 4:32
  It does, but here is the problem.
• 4:35
  A model that complex cannot be solved analytically.
• 4:39
  The math just becomes too tangled, too non linear, too
• 4:42
  heavy. So the computer just chokes on
• 4:44
  it. Exactly.
• 4:44
  It must be simulated experimentally by a computer,
• 4:47
  which takes enormous computing power, endless time, and
• 4:50
  honestly, it introduces entirely new avenues for digital errors.
• 4:54
  Because the actual best engineering model is not the
• 4:56
  most precise 1. The best model is simply the
• 4:59
  most basic, simple model that yields the exact information you
• 5:03
  need to make a specific design decision.
• 5:05
  I want to make sure you, the listener, really internalize
• 5:08
  this, because what does this actually mean for your workflow?
• 5:11
  It means you have to adopt A strict iterative loop.
• 5:14
  OK, step one. Step 1.
• 5:17
  You start by formulating A drastically simplified
• 5:20
  mathematical model. Keep it super simple.
• 5:22
  Right, Step 2, you translate that simple model to computer
• 5:26
  code. Step three, you simplify and
• 5:30
  linearize it even further to understand its core behavior.
• 5:34
  Wait. Further.
• 5:35
  Yeah, strip it down. Then Step 4, you analyze that
• 5:40
  model and then and only then do you simulate a slightly more
• 5:44
  complex version to test alternative designs.
• 5:47
  And finally you implement the control system.
• 5:49
  You got it. That's the loop.
• 5:51
  But wait, let me push back on this because I can hear the
• 5:53
  skeptics right now. Isn't engineering supposed to be
• 5:55
  an exact science? People love to say that.
• 5:57
  Right. If you build a quote UN quote
• 5:59
  simple model of a car suspension, let's when you
• 6:02
  intentionally ignore the complex friction of the rubber seals
• 6:05
  inside the shock absorber, aren't you just lying to
• 6:08
  yourself about how the car actually drives?
• 6:10
  That's a fairpoint. I mean, if you ignore reality,
• 6:13
  won't reality bite you when you actually build the car?
• 6:15
  It raises an important question, but no, you aren't lying to
• 6:18
  yourself. You are isolating the variables
• 6:21
  that actually matter for the specific problem you were trying
• 6:24
  to solve right now. OK, give me an example.
• 6:27
  Think about the car suspension you just mentioned if your
• 6:30
  immediate goal is simply to determine the required spring
• 6:33
  stiffness to keep the car's chassis from bottoming out when
• 6:36
  it hits a standard speed bump at 30 mph.
• 6:39
  Just a standard suspension check.
• 6:41
  Right. You absolutely do not need to
• 6:43
  model the thermal expansion of the damper fluid over a four
• 6:47
  hour road trip. The thermal expansion is real.
• 6:51
  Yes, the rubber seal friction is real, but their impact on the
• 6:54
  specific question of will the car bottom out on this bump is
• 6:58
  mathematically negligible. So they just don't matter for
• 7:02
  that specific test. Exactly.
• 7:04
  You add complexity only when the simple model fails to answer the
• 7:07
  question, or you know when you move to the next phase of design
• 7:10
  where thermal dynamics actually matter.
• 7:13
  OK, that makes perfect sense. You strip away the noise to see
• 7:15
  the signal. But to build these simple models
• 7:18
  without getting completely lost in the math, you really need a
• 7:22
  universal language. You absolutely do.
• 7:24
  Because let's face it, if you look under the hood of an
• 7:26
  electric vehicle today, modern systems aren't just mechanical
• 7:30
  anymore. They aren't just simple gears
• 7:32
  and levers. No, not at all.
• 7:34
  They are an absolute multi domain mess.
• 7:38
  Modern engineering is completely mechatronic.
• 7:41
  You are dealing with systems that are part mechanical, part
• 7:44
  electrical, part fluid, and part thermal, and they're all
• 7:47
  interacting simultaneously. Which sounds like a nightmare
• 7:50
  for the math. It is if you treat each domain
• 7:53
  with completely different math, like if your Mechanical
• 7:56
  Engineers are using one set of equations and your electrical
• 7:59
  engineers are using another. And your fluid dynamicists are
• 8:01
  off in their own world using a third set.
• 8:03
  Exactly. You create these massive,
• 8:06
  paralyzing bottlenecks in your design process.
• 8:09
  Because nobody can actually talk to each other.
• 8:12
  The electrical guy says the battery voltage is dropping and
• 8:15
  the mechanical guy says the motor torque is failing and they
• 8:17
  literally can't mathematically link the two in a single
• 8:21
  equation. Precisely, and the elegant
• 8:23
  solution to this multi domain mess is to unify the physics
• 8:26
  entirely using something called ideal elements.
• 8:30
  Ideal elements. OK, let's get into this.
• 8:32
  So in system dynamics, we can boil almost all of physical
• 8:35
  reality down to two primary physical variables.
• 8:38
  We call them through variables which we denote as F and across
• 8:41
  variables, which we denote as V. OK, let's slow down and really
• 8:45
  define these, because this is basically the Rosetta Stone for
• 8:48
  understanding complex engineering.
• 8:50
  It really is. Through variables are exactly
• 8:53
  what they sound like. They are quantities that are
• 8:56
  physically transmitted through an element, right?
• 8:59
  Like if I push on a spring, the mechanical force transmitted
• 9:02
  through that spring is a through variable.
• 9:04
  In an electrical circuit, the current flowing through a wire
• 9:07
  or a resistor is a through variable.
• 9:09
  And in a hydraulic system, the volume of fluid flowing through
• 9:13
  a pipe is a through variable. In a thermal system, the heat
• 9:18
  flowing through a conductor also a through variable.
• 9:21
  So that's the F and then we have the across variables, the V.
• 9:24
  Right, these are the differences measured across the terminals or
• 9:27
  the boundaries of the element. So if you have a mechanical
• 9:29
  damper, the velocity difference between the top of the damper
• 9:32
  and the bottom of the damper is your across variable.
• 9:35
  Yes, and in an electrical system it would be the voltage
• 9:38
  difference across the batteries, positive and negative terminals.
• 9:41
  OK. And for fluid?
• 9:42
  In a fluid system, the pressure drop from the entrance of a pipe
• 9:45
  to the exit is the across variable, and in a thermal
• 9:49
  system it's the temperature difference across an insulated
• 9:51
  wall. Here is where it gets absolutely
• 9:54
  incredible for me. Power, like the actual tangible
• 9:58
  flow of energy into an element, is universally defined across
• 10:02
  all these domains using these exact 2 variables.
• 10:05
  It's beautifully simple. Power is simply the product of
• 10:08
  the through variable and the across variable.
• 10:10
  You can read the universal equation as power equals F
• 10:14
  multiplied by the difference between V2 and V1 exactly.
• 10:17
  It literally does not matter if you are designing a mechanical
• 10:20
  gear train, an electrical circuit, or a hydraulic press.
• 10:24
  The math for power is identical. Which is incredibly elegant.
• 10:28
  It means a mechanical engineer and an electrical engineer are
• 10:31
  actually speaking the exact same language, just using different
• 10:34
  physical mediums. And using these unified
• 10:36
  variables, we can categorize all passive energy elements in the
• 10:40
  universe into three specific types.
• 10:42
  OK, what's the first one? 1st we have T type elements or
• 10:45
  inductive storage elements. These are components that store
• 10:48
  energy based on the through variable.
• 10:51
  Like what? Think of mechanical spring
• 10:53
  storing force, or electrical inductance storing current in
• 10:56
  the magnetic field, or fluid inertance storing momentum in a
• 10:59
  moving column of water. OK, so T type elements bank
• 11:03
  energy based on what is flowing through them.
• 11:05
  What is the second type? 2nd is a type elements or
• 11:08
  capacitive storage elements. These store energy by virtue of
• 11:13
  the across variable. So measuring across the
• 11:15
  boundaries. Right.
• 11:17
  This includes physical mechanical masses storing
• 11:19
  kinetic energy due to a velocity difference, electrical
• 11:22
  capacitance storing charge due to a voltage difference.
• 11:25
  Fluid capacitance, like a water tank storing energy due to
• 11:28
  pressure. Exactly, and thermal capacitance
• 11:30
  storing heat. But there is a very critical
• 11:32
  note here. For mechanical systems a mass
• 11:36
  must always be referenced to an inertial non accelerating frame.
• 11:41
  Meaning it's zero velocity reference is the ground.
• 11:44
  Yes. Right, because you can't measure
• 11:46
  the kinetic energy of a moving mass without knowing what it's
• 11:49
  moving relative to. I mean, if I'm holding a bowling
• 11:51
  ball on a moving train, the ball's kinetic energy relative
• 11:54
  to me is 0. But relative to the ground
• 11:57
  outside, it's massive. Exactly.
• 12:00
  You have to anchor the across variable to a non moving ground.
• 12:04
  That's a great way to picture. It and then we have the third
• 12:06
  type, the D type elements. These are the dissipators.
• 12:08
  Right, they don't store energy at all, they destroy it.
• 12:10
  Well technically they burn it off as heat.
• 12:12
  So mechanical bampers, electrical resistors, fluid
• 12:16
  friction in a pipe. Yeah, power always flows into AD
• 12:20
  type element. It never, ever gives power back
• 12:22
  to the system. A spring will bounce back, a
• 12:25
  capacitor will discharge, but a resistor just gets hot.
• 12:29
  Exactly, and beyond those 3 passive storage and dissipation
• 12:33
  elements, we also have multi port elements that connect
• 12:35
  different parts of a system together.
• 12:37
  Like Transformers? Right Transformers like
• 12:39
  mechanical levers, gear trains or electrical Transformers.
• 12:42
  They scale the variables up or down while maintaining power.
• 12:46
  And gyrator. Gyrators like gyroscopes or
• 12:48
  certain electrical components, they cross length of variables.
• 12:51
  They actually link a cross variable at one port to a
• 12:54
  through variable at the other. Oh.
• 12:55
  That's. Wild And finally transducers
• 12:58
  like an electric motor, which literally convert energy from
• 13:01
  one physical medium, like electrical current directly into
• 13:06
  another, like mechanical rotation.
• 13:07
  I feel like this is such a massive unlock for anyone
• 13:10
  listening who struggles to conceptualize different fields
• 13:13
  of engineering. It really bridges the gap.
• 13:15
  If you are struggling with a complex fluid piping system, you
• 13:18
  can literally draw it out and look at it like an electrical
• 13:21
  circuit. Water flow is your electrical
• 13:24
  current. That's the through variable.
• 13:26
  The pressure drop in the water is your voltage.
• 13:29
  That's the across variable. A narrow section of pipe is just
• 13:32
  a resistor. A large water storage tank is
• 13:35
  just a capacitor. They speak the exact same
• 13:38
  mathematical language. That is the beauty of ideal
• 13:41
  elements. You can translate any physical
• 13:44
  system into a unified network. But, and this is big, but,
• 13:48
  knowing the individual elements is only half the battle.
• 13:50
  Right, you have to actually wire them up.
• 13:52
  Now that you have these unified pieces, you have to connect them
• 13:55
  together to build a complete system without breaking the
• 13:58
  fundamental laws of physics. Which brings us seamlessly into
• 14:01
  the problem of wiring the system together and trying to escape
• 14:04
  what I like to call the infamous black box of engineering.
• 14:07
  Oh, the black box. Yeah, system structure and
• 14:10
  interconnection are governed by two vital unbreakable laws. 1st
• 14:14
  we have continuity equations. What do those say?
• 14:17
  This law states that the algebraic sum of all through
• 14:22
  variables entering any specific node or junction in your system
• 14:25
  must equal 0. So in classical mechanics, this
• 14:28
  is dynamic equilibrium, or basically Newton's laws of
• 14:32
  motion. Right.
• 14:33
  And in electronics, it's Kirchhoff's current law.
• 14:35
  The logic is simple. You cannot magically create or
• 14:38
  destroy force, current or fluid at a junction.
• 14:42
  What flows in must flow out. So if three pipes meet at a
• 14:46
  joint, the gallons per minute flowing into the joint must
• 14:49
  perfectly match the gallons per minute flowing out.
• 14:51
  The note itself can't store water.
• 14:53
  Exactly. And what is the second law?
• 14:55
  The second law deals with the compatibility equations.
• 14:57
  Right. This states that the algebraic
• 14:59
  sum of the remains across variable differences around any
• 15:03
  closed path or loop in the system must equal 0.
• 15:06
  OK, break that down. It simply means that distance or
• 15:09
  voltage or pressure is a scalar quantity tied to physical space.
• 15:13
  If you start at one specific point in your system, trace a
• 15:15
  path around a loop through various components, and come
• 15:17
  back to the exact same starting point.
• 15:19
  Your net change has to be 0. Your net change in elevation, or
• 15:23
  your net change in voltage, or your net change in pressure
• 15:26
  absolutely has to be 0. Because you can't walk around a
• 15:29
  staircase in a square and somehow end up higher than where
• 15:32
  you started unless you're in some MCS you're painting.
• 15:34
  Exactly. OK, so you have your TA and D
• 15:37
  components. You have your node and loop
• 15:39
  equations based on continuity and compatibility.
• 15:43
  Sit down and you start doing the math.
• 15:45
  And this is where it usually goes off the rails.
• 15:46
  Yes, this is the massive pain point engineers run into.
• 15:51
  For decades, engineers relied entirely on the classic input
• 15:55
  output form the IO form. They treat the entire system
• 15:59
  like a mysterious black box. Right where an input goes in,
• 16:03
  some mathematical magic happens inside the box and an output
• 16:06
  comes out governed by some terrifying massive NTH order
• 16:09
  differential equation. The black box approach is
• 16:11
  honestly a relic of classical control theory.
• 16:15
  It works for very simple things, but it fundamentally hides the
• 16:18
  internal reality of your system. So how do we optimize this?
• 16:22
  What's the modern approach? The optimization here, the way
• 16:25
  modern engineering is actually done, is moving entirely to the
• 16:28
  state variable form. State variable form.
• 16:32
  Yeah, instead of writing one massive, unwieldy equation
• 16:35
  linking the input to the output, modern control analysis breaks
• 16:39
  the system down into a set of state variables.
• 16:41
  Which we label as X1X2 up to XN. Right, and these variables
• 16:46
  represent the absolute minimum number of independent variables
• 16:49
  needed to define the total energy state of the system at
• 16:53
  any given moment in time. OK, I need to act as the
• 16:55
  surrogate for the audience here, because if we just start
• 16:58
  throwing around terms like state variables and vector matrices,
• 17:02
  eyes are going to glaze over. Fair enough, Let's ground it.
• 17:05
  Let's make this highly visual and step by step.
• 17:07
  If I'm building a drone, how do I actually find the state
• 17:11
  variables? What do I look for?
• 17:13
  It is actually beautifully intuitive once you know what to
• 17:15
  look for. You derive the natural state
• 17:17
  variables by simply counting your independent energy storage
• 17:20
  elements. Wait, that's it.
• 17:21
  That's it. Remember the T type and A type
• 17:23
  elements? We just talked about the.
• 17:24
  Springs, the masses, the capacitors.
• 17:27
  Exactly. For every independent T type
• 17:30
  storage element, like a spring in your drones landing gear, you
• 17:33
  write one equation for its shoe. It's your variable of the force.
• 17:37
  OK, For every independent A type storage element like the
• 17:40
  physical mass of the drone itself, you write one equation
• 17:43
  for it's together cross variable, its velocity.
• 17:46
  Chances. Link those up.
• 17:47
  You solve your continuity and compatibility equations to link
• 17:50
  them all together, and you formulate the entire system into
• 17:53
  a compact, standardized set of vector matrices, known
• 17:57
  universally as the ABC and D matrices.
• 18:00
  Whoa, back up right there. I know what a matrix is in
• 18:03
  standard Mat. It's basically an array of
• 18:04
  numbers, right? But when you say ABC and D
• 18:07
  matrices in this context, what are these four specific boxes
• 18:11
  actually doing? Like if I'm looking at the code
• 18:13
  for my drone, what goes into the A matrix versus the B matrix?
• 18:17
  That is a crucial distinction. The A matrix is the system
• 18:20
  matrix. It defines the internal physics
• 18:23
  of the drone itself, completely independent of the outside
• 18:25
  world. So it's just the drone's body?
• 18:27
  Yes, it maps how the drone's mass interacts with its own
• 18:32
  structural stiffness and damping.
• 18:34
  If you drop the drone out of the sky with no motors running, the
• 18:37
  A matrix dictates how it falls and flexes.
• 18:40
  Got it. And the B matrix.
• 18:41
  The B matrix is the input matrix.
• 18:44
  It maps how your steering controls your motor thrust.
• 18:47
  Actually connect to and influence that internal physics.
• 18:51
  So A is the physical body and B is the nervous system connecting
• 18:55
  the muscles to the body. Exactly.
• 18:56
  What about C&D? The C matrix is the output
• 18:59
  matrix. It defines what your sensors can
• 19:01
  actually see. Like the camera or the GPS?
• 19:04
  Right. You might have a complex A
• 19:05
  matrix with 20 internal states, but if you only have Agps and an
• 19:09
  altimeter on board, your C matrix maps those 20 states down
• 19:13
  to just position and height. That makes total sense.
• 19:15
  And the D matrix. Finally, the D matrix is the
• 19:18
  feed forward matrix. It represents a direct bypass
• 19:21
  where the input instantly affects the output without going
• 19:24
  through the physical state dynamics first.
• 19:26
  Which sounds rare. It is in most mechanical systems
• 19:29
  the D matrix is just 0. OK, that makes it incredibly
• 19:32
  clear. But I have to play devil's
• 19:34
  advocate here for a second. Go for it.
• 19:36
  Why should a practical hands on engineer care about setting up
• 19:41
  these four state variable matrices?
• 19:43
  It's. A common question.
• 19:45
  I mean, if the classical black box transfer function tells me
• 19:48
  that when I push the gas pedal down one inch the car goes
• 19:51
  forward at 20 miles an hour, why do I need to know the internal
• 19:55
  energy state of the transmission gears?
• 19:57
  The car moves, the client is happy.
• 20:00
  Why do the matrices matter? Because if you don't know the
• 20:03
  internal state, the system's behavior over time will
• 20:07
  completely blind side you. Blind side me how?
• 20:10
  Let's use your car example. Your black box equation simply
• 20:13
  says gas pedal input equals forward motion output.
• 20:16
  That's all it sees, right? But what if internally your
• 20:20
  transmission is absorbing massive amounts of kinetic
• 20:22
  energy and heating up due to friction?
• 20:24
  Oh man. The black box doesn't see the
• 20:26
  heat, It doesn't track like the energy stored in the
• 20:28
  transmission fluid. It just tells you the car is
• 20:31
  moving right up until the moment the transmission suddenly
• 20:34
  shatters into 1000 pieces on the highway.
• 20:38
  State variables track every single pool of energy in the
• 20:41
  system simultaneously. They tell you not just what the
• 20:44
  output is doing, but whether the internal components are secretly
• 20:48
  ripping themselves apart. That is a terrifying thought.
• 20:51
  The black box is basically driving blindfolded, just
• 20:53
  waiting to hit a wall. And that perfectly transitions
• 20:57
  us into the absolute nightmare of the time domain.
• 20:59
  Because things don't just break instantly, they break over time.
• 21:02
  Energy builds up, oscillates and tears things apart.
• 21:05
  Exactly. But analyzing systems purely in
• 21:08
  the time domain using raw differential equations is
• 21:11
  incredibly painful. The math gets nasty.
• 21:13
  Very nasty. If you try to calculate how a
• 21:15
  mass bounces on a spring over 10 seconds using basic calculus,
• 21:19
  the math is horrific. So to deal with these time
• 21:22
  domain terrors, engineers use transform methods, specifically
• 21:26
  the Laplace transform. The famous Laplace transform.
• 21:29
  Right. The Laplace transform takes
• 21:31
  these horrific tangled differential equations and turns
• 21:34
  them into simple manageable algebra by moving the problem
• 21:38
  out of the time domain into the complex frequency domain.
• 21:41
  You know, I always like to explain the Laplace transform
• 21:43
  visually. Well, let's hear it.
• 21:45
  It is like trying to untangle a massive knotted ball of yarn.
• 21:49
  That's your time domain differential equation.
• 21:52
  If you try to pull at the threads with raw calculus, it
• 21:55
  just gets tighter and more tangled.
• 21:56
  It really does. But a Laplace transform is like
• 21:58
  dropping that knotted ball into a magical chemical bath.
• 22:02
  The bath dissolves the knots entirely and you are left with
• 22:06
  straight parallel strings. I like that.
• 22:09
  You do simple addition and subtraction on those straight
• 22:11
  strings. That's the complex frequency
• 22:13
  domain algebra. And when you're done, you
• 22:15
  reverse the chemical process, pull the yarn out, and the math
• 22:18
  is solved. Exactly.
• 22:20
  The output relies entirely on the system's transfer function,
• 22:23
  which we denote as H of S. That's a perfect analogy.
• 22:26
  The Laplace transform untangles the dynamic behavior.
• 22:29
  It really does. And when we look at how a system
• 22:32
  actually responds to a test input, like an impulse strike, a
• 22:36
  sudden step input, or a steady ramp up in force, we are really
• 22:39
  looking at 2 distinct phases of behavior.
• 22:41
  What's the first phase? 1st is the transient response,
• 22:44
  which is the initial, often chaotic reaction right after the
• 22:47
  system is disturbed. Like the immediate bounce?
• 22:51
  Right second is the steady state response, which is how the
• 22:54
  system behaves after the initial chaos settles down.
• 22:57
  So let's isolate these and look at 1st order systems first.
• 23:01
  These are the simplest dynamic systems.
• 23:03
  Very simple. They only have one energy
• 23:05
  storage element, like a single mass sliding on a frictionless
• 23:08
  surface or a single capacitor charging.
• 23:11
  Because there's only one storage element, energy can't bounce
• 23:14
  back and forth. Exactly.
• 23:16
  The system's speed is governed by a single parameter called the
• 23:19
  time constant, which we denote with the Greek letter Tau.
• 23:22
  So what is the golden rule for engineers dealing with a first
• 23:26
  order system? The Golden Rule is incredibly
• 23:29
  practical. After four time constant the
• 23:32
  four times the value of Tau, the system has reached roughly 98%
• 23:37
  of its final steady state value. So it's basically done moving.
• 23:40
  For all practical engineering purposes, we consider it
• 23:43
  completely settled. It doesn't bounce, it doesn't
• 23:45
  overshoot, it is just a smooth exponential curve flattening
• 23:48
  out. But things get violently crazy
• 23:50
  when we step up to 2nd order systems.
• 23:52
  Oh yeah, they do. This is where you have two
• 23:54
  energy storage elements trading energy back and forth like a
• 23:57
  physical mass bouncing on a physical spring.
• 24:00
  The spring pushes the mass. The mass gains kinetic energy.
• 24:03
  It overshoots, stretches the spring, and the spring pulls it
• 24:06
  back. Now the system's behavior is
• 24:08
  governed by two entirely new parameters, the damping ratio,
• 24:12
  called Zeta, and the natural frequency, called Omega N.
• 24:15
  And this is exactly where physical systems vibrate to
• 24:18
  pieces. The value of the damping ratio
• 24:20
  Zeta dictates absolutely everything about the system's
• 24:23
  survival. OK, let's walk through the Zeta
• 24:26
  values. If Zeta is greater than one, the
• 24:28
  system is what we call over. Damped, it is sluggish.
• 24:31
  Sluggish like what? Imagine a door closer filled
• 24:34
  with thick molasses. It's slowly, painfully creeps
• 24:37
  toward the closed position without ever slamming or
• 24:40
  bouncing past the frame. Safe but slow.
• 24:42
  Right now, if Zeta is exactly 1, it is critically damped.
• 24:46
  I always say a critically damped system is like the perfect high
• 24:50
  end kitchen drawer. You shove it as hard as you can
• 24:53
  and it glides inward incredibly fast, but it stops exactly at
• 24:56
  the of the rail without slamming, clicking, or bouncing
• 24:59
  back even a millimeter. Yes, exactly.
• 25:02
  It is the theoretical ideal for a vast majority of mechanisms
• 25:06
  where you want speed without overshoot.
• 25:07
  But what if Zeta drops too low? If Zeta drops below 1, if it's
• 25:11
  between zero and one, the system is under damped.
• 25:14
  It moves fast, but it overshoots the target, bounces back and
• 25:18
  oscillates before eventually settling down.
• 25:20
  Like a car with bad shocks going over a speed bump, it just keeps
• 25:23
  floating up and down. Exactly.
• 25:24
  And if Zeta equals exactly 0, you have no damping at all.
• 25:28
  You have pure harmonic oscillation.
• 25:31
  The system will literally bounce back and forth forever.
• 25:33
  It never settles. And here is where it gets really
• 25:36
  interesting. On the mathematical side, this
• 25:38
  real world bouncing, this physical oscillation, is
• 25:41
  dictated mathematically by the location of complex poles in
• 25:44
  this plane. Yes, when you saw the
• 25:46
  denominator of your transfer function, the roots of that
• 25:49
  characteristic equation are called the poles.
• 25:51
  OK, the poles. If you plot these poles on a
• 25:54
  graph called the Complex set Plane, their physical location
• 25:57
  on the paper completely dictates whether the system will
• 26:01
  peacefully settle or vibrate itself to pieces.
• 26:04
  So how do you read the graph? The X axis is real numbers, the
• 26:07
  axis is imaginary numbers. If your poles sit purely on the
• 26:11
  real axis, you get that smooth, sluggish, over damped response.
• 26:16
  But if the poles migrate off the real axis and become complex
• 26:19
  numbers with imaginary parts, that means the system is going
• 26:23
  to oscillate. The imaginary part of the math
• 26:25
  literally translates to physical vibration in the real world,
• 26:28
  that is mind. Blowing it is, and the closer
• 26:31
  those poles get to the vertical imaginary axis, the more
• 26:34
  violently and endlessly the system vibrates.
• 26:36
  What if they cross it? If the poles crossover to the
• 26:39
  right half of the blame, the system is fundamentally
• 26:41
  unstable. It doesn't just vibrate.
• 26:43
  The vibrations grow exponentially until the system
• 26:45
  destroys itself. Like the Tacoma Narrows Bridge?
• 26:48
  Yes. Think of that famous footage of
• 26:50
  the bridge twisting in the wind until it collapsed.
• 26:53
  That is a system where the poles moved into the unstable region.
• 26:56
  And what about the zeros? We talked about the roots of the
• 26:59
  denominator being the poles. What do the roots of the
• 27:02
  numerator do? Zeros are fascinating.
• 27:05
  While poles dictate the underlying stability and
• 27:08
  vibration, A0 acts as an anticipator of the input.
• 27:12
  It anticipates. Yes, because a 0 mathematically
• 27:16
  introduces a derivative of the input into the system.
• 27:19
  It is essentially sensing the rate of change of the input
• 27:22
  before the full input even arrives.
• 27:24
  It's looking at the slope. Exactly.
• 27:26
  This drastically speeds up the response time of the system,
• 27:29
  acting almost like a predictive filter, though it can also cause
• 27:32
  a much larger initial overshoot because it reacts to
• 27:35
  aggressively. So to recap for the listener,
• 27:37
  holes cause the system to drag, bounce or explode, and zeros try
• 27:41
  to predict the future to speed things up.
• 27:43
  That's a great summary. But up until now, we've only
• 27:46
  been talking about how a system reacts to a single sudden event,
• 27:50
  like hitting a speed bump. Right, isolated events.
• 27:52
  But systems don't just experience simple clean step
• 27:56
  inputs. In the real world, engines
• 27:59
  vibrate continuously at high RPMS, Wind howls periodically.
• 28:03
  An airplane wing is constantly buffeted.
• 28:05
  We have to look at constant rhythmic noise.
• 28:08
  We do, and that brings us naturally to how we optimize
• 28:11
  these systems in practice using frequency response and
• 28:14
  bandwidth. OK, let's breakdown frequency
• 28:16
  response. Frequency response is
• 28:18
  essentially asking how does your system behave in the steady
• 28:21
  state when you feed it a continuous, never ending
• 28:25
  sinusoidal input. Like a constant vibration from a
• 28:27
  motor. Exactly what is absolutely
• 28:30
  crucial to understand here is that if your system is linear,
• 28:33
  feeling it a sine wave will result in an output that is the
• 28:36
  exact same frequency sine wave. So if I shake it at 50 Hertz.
• 28:39
  It will shake back at 50 Hertz. It will never magically output
• 28:42
  60 Hertz. The only things that change are
• 28:44
  the amplitude, how violent the shaking is compared to the input
• 28:47
  in the phase angle, how delayed the shaking is.
• 28:49
  To evaluate this, engineers use a visual tool called Bowed
• 28:52
  Plots, right? Yes, bowed plots are essential
• 28:55
  here. A bowed plot is split into two
• 28:57
  parts. On the top graph, you plot the
• 29:00
  magnitude ratio in decibels versus the logarithm of the
• 29:04
  frequency Omega. On the bottom graph you plot the
• 29:07
  phase angle delay versus the logarithm of Omega.
• 29:11
  And this step by step graphical optimization is where controls
• 29:15
  engineers really make their money.
• 29:18
  Dynamic systems act exactly like physical filters.
• 29:21
  Explain that. Think of a heavy mechanical
• 29:23
  mass. It will pass low frequencies
• 29:25
  through easily. If you push it slowly back and
• 29:27
  forth, it moves, but it will block or attenuate high
• 29:30
  frequencies. So if you vibrate it 10,000
• 29:33
  times a second. It's inertia prevents it from
• 29:35
  moving at all. The threshold frequency where
• 29:37
  this blocking begins to happen defines the system's bandwidth.
• 29:41
  And bandwidth is defined as the frequency range where the output
• 29:44
  amplitude drops no more than three decibels from its peak
• 29:47
  value, right? Exactly.
• 29:48
  So bandwidth determines the system speed of response.
• 29:51
  A narrow bandwidth means a sluggish system that filters out
• 29:54
  all the high frequencies. It just can't react fast enough.
• 29:57
  Right. And if you have complex periodic
• 30:00
  input noise, like a messy wind gust, engineers use a
• 30:04
  mathematical tool called a Fourier series.
• 30:07
  What does the Fourier series do? It breaks down that complex,
• 30:11
  messy real world noise into a clean stack of simple sine and
• 30:15
  cosine waves. Then they look at the boat plot
• 30:18
  to see if those specific frequencies fall inside or
• 30:21
  outside the system's bandwidth. But I have to ask you a serious
• 30:24
  question here, because it feels like there is a trap.
• 30:27
  There usually is. If a wider bandwidth makes a
• 30:30
  system react faster, track inputs more accurately, and act
• 30:33
  more responsively, shouldn't we as designers always optimize for
• 30:37
  the maximum possible bandwidth? Why not make the bandwidth as
• 30:40
  wide as physically possible? That's a very tempting thought.
• 30:43
  Or does that just open the door for high frequency garbage to
• 30:46
  come in and destroy the? That is the exact engineering
• 30:49
  trade off. Yes, an incredibly wide
• 30:51
  bandwidth means a fast, highly responsive system.
• 30:54
  A fighter jet has a much wider bandwidth than a commercial
• 30:57
  airliner, but it also means you are letting in absolutely
• 31:00
  everything. You are letting in high
• 31:01
  frequency sensor noise, electrical static, and
• 31:04
  mechanical chatter from the gears.
• 31:07
  If your bandwidth is too wide, your control motors will try to
• 31:10
  violently react to every tiny piece of random static.
• 31:14
  The system will jitter constantly, which leads to
• 31:17
  immediate mechanical wear and tear, burned out motors, or
• 31:20
  catastrophic instability. So you want your bandwidth just
• 31:24
  wide enough to capture the real intended signal and narrow
• 31:27
  enough to block all the high frequency garbage.
• 31:29
  You nailed it. Wow.
• 31:31
  OK, let's take a collective breath because up to now we have
• 31:35
  been building this beautiful, elegant mathematical castle.
• 31:39
  All of this magic in the Laplace transforms, untangling the yarn,
• 31:42
  the bowed plots, filtering the frequencies, the pristine state
• 31:46
  variable matrices. It all relies entirely on one
• 31:49
  massive, incredibly dangerous assumption.
• 31:51
  It relies on the assumption that the system is perfectly linear.
• 31:54
  And let's be honest, engineers absolutely love to assume
• 31:57
  systems are linear because the math is easy.
• 31:59
  It's so much easier if it's linear and I double the input.
• 32:03
  The output double S perfectly. If I push twice as hard, it goes
• 32:05
  twice as fast. It is a beautiful, predictable
• 32:09
  world. But what happens when we step
• 32:11
  outside the textbook? The superposition principle, the
• 32:14
  very bedrock of linear math, completely fails in reality.
• 32:17
  Exactly. Superposition states that the
• 32:19
  response to a large input is exactly the same shape as the
• 32:23
  response to a small input, just scaled up proportionally.
• 32:26
  But real physical components do not work that way.
• 32:29
  Not at all. Think about real world
• 32:31
  nonlinearities that plague every mechanical design.
• 32:34
  First, you have dead zones. Dead zones.
• 32:37
  This is where a small input causes absolutely 0 output.
• 32:41
  Think of a loose steering wheel in an old car.
• 32:43
  You turn the wheel a little bit left, a little bit right, and
• 32:46
  the car doesn't turn at all until the gears physically
• 32:48
  engage. The math for a dead zone is
• 32:50
  entirely nonlinear. Then you have backlash where
• 32:53
  gears clack back and forth in the housing when reversing
• 32:56
  direction and of course you have saturation.
• 32:58
  Saturation is everywhere. It is the reality that pushing
• 33:02
  harder doesn't give you any more output because a physical limit
• 33:04
  has been reached. A valve is already 100% open, a
• 33:08
  motor is drawing maximum current.
• 33:10
  Assuming linearity across the board is like assuming that if
• 33:13
  you can easily lift 50 lbs at the gym, you can definitely lift
• 33:17
  £500 just by trying 10 times harder.
• 33:19
  That's a painful analogy. The math seems right, but
• 33:22
  eventually your body hits a saturation limit.
• 33:25
  The physics completely change. Your spine doesn't just scale
• 33:28
  it's lifting capacity linearly, it physically breaks.
• 33:31
  And the consequence in engineering when you ignore
• 33:34
  these nonlinearities is the creation of limit cycles.
• 33:37
  Limit cycles? What are those?
• 33:38
  Well, in a purely linear system, a continuous oscillation depends
• 33:42
  entirely on how hard you initially hit the system.
• 33:45
  Hit it hard, it bounces big, hit it soft, it bounces small.
• 33:48
  But in a non linear system, these limit cycles are unique
• 33:51
  self-sustaining oscillations of a fixed amplitude and fixed
• 33:55
  period that the system will automatically fall into
• 33:57
  completely regardless of the initial state.
• 33:59
  Wait. Explain that it doesn't matter
• 34:01
  how hard you hit it. Exactly.
• 34:03
  Whether you tap the system lightly or smash it with a
• 34:05
  hammer, it will eventually settle into the exact same
• 34:09
  violent hum. The system actively hunts for
• 34:12
  this specific vibration and just locks into it indefinitely.
• 34:16
  That sounds incredibly dangerous.
• 34:17
  It's incredibly dangerous because a limit cycle can cause
• 34:20
  metal fatigue over thousands of cycles, destroying a component
• 34:24
  that classical linear math said was perfectly stable.
• 34:28
  So how do you actually fix this? If the linear math is broken by
• 34:31
  dead zones and saturation, and we know limit cycles are lurking
• 34:34
  in the dark, what do we do? We can't just throw away all the
• 34:37
  Laplace transforms and boat plots we just talked about.
• 34:39
  We don't throw them away. We have three primary
• 34:41
  workarounds to cheat our way through nonlinearities.
• 34:44
  OK, what's the first cheat? The first is linearizing
• 34:47
  approximations. This is the most common if we
• 34:50
  know a system is going to operate around a very specific
• 34:52
  reference trajectory. Let's say we are programming a
• 34:55
  drone to hover at exactly 50 feet.
• 34:58
  We use a mathematical tool called a Taylor series
• 35:01
  expansion. How does that help?
• 35:03
  We use the Taylor series to pretend the system is linear,
• 35:06
  just for very small movements around that specific 50 foot
• 35:09
  hover point. It works beautifully as long as
• 35:12
  the drone doesn't deviate too far from the hover point.
• 35:15
  But hold on, a drone doesn't just hover perfectly still in a
• 35:18
  vacuum. What if a massive gust of wind
• 35:21
  hits it or the pilot Yanks the joystick and the drone is flying
• 35:26
  wildly in aggressive banks and dives?
• 35:28
  You can't pretend that's linear. The Taylor series hover point is
• 35:31
  useless there. We have to have a way to handle
• 35:34
  messy high frequency large scale chaos without breaking the
• 35:38
  simulation. You're exactly right.
• 35:40
  And when the deviations are large, we move to the second fix
• 35:44
  describing function. This approach is incredibly
• 35:47
  clever. You take all the messy, ugly
• 35:49
  nonlinear, the dead zones, the saturation limits, the backlash,
• 35:52
  and you mathematically aggregate them into a single comprehensive
• 35:56
  block. So you just shove all the ugly
• 35:57
  stuff into one box. Pretty much.
• 35:59
  Then you feed a clean sine wave into this ugly block.
• 36:02
  Naturally the output is a distorted messy non sine wave.
• 36:05
  But here's the trick. You assume that the rest of the
• 36:08
  physical system acts as a natural low pass filter.
• 36:12
  You assume the physical inertia of the drone will strip away all
• 36:15
  the high frequency harmonic distortion.
• 36:18
  So mathematically, you simply ignore the distortion and only
• 36:23
  model the fundamental base frequency that survives.
• 36:27
  It is an approximation, but it brilliantly allows you to use
• 36:30
  your standard linear frequency response tools like the bowed
• 36:34
  plot on a highly nonlinear system.
• 36:37
  That is genius. You just assume reality is too
• 36:39
  sluggish to care about the high frequency distortion, so you
• 36:42
  mathematically delete it. Exactly.
• 36:43
  What is the third fix? The third fix is the phase plane
• 36:46
  method. This is a super visual approach
• 36:49
  for 2nd order systems. Instead of plotting A variable
• 36:51
  against time, which creates messy wave graphs, you ignore
• 36:54
  time entirely. You ignore time.
• 36:56
  Yes, you plot one state variable directly against another state
• 36:59
  variable. So like plotting the physical
• 37:01
  position of a pendulum on the X axis and the velocity of that
• 37:04
  pendulum on the Y axis. Time isn't on the graph at all.
• 37:08
  Exactly. This lets you track the exact
• 37:10
  transient response graphically as a flowing path.
• 37:13
  On the paper, you can literally see the system's behavioral
• 37:17
  energy drawn out as tracking spirals, saddles, and stable
• 37:20
  nodes. What does a stable node look
• 37:22
  like? If a system is stable and
• 37:24
  settling down, the graph will show a stable focus.
• 37:27
  It looks exactly like a spiral, drawing inward tighter and
• 37:30
  tighter toward the dead center 0 point.
• 37:33
  The energy is draining away into the center.
• 37:35
  Right. And if the system is trapped in
• 37:36
  one of those dangerous limit cycles we talked about, the
• 37:38
  graph will look like a solid, bold closed loop.
• 37:42
  No matter where you start on the graph, the trajectory line will
• 37:45
  get sucked into that loop and justice trace it endlessly.
• 37:48
  It's brilliant because you don't need to analytically solve the
• 37:51
  impossible differential equation, you just map where the
• 37:53
  energy is flowing visually exactly.
• 37:56
  But let's be real. Because these nonlinear
• 37:58
  equations are so incredibly horrific to solve by hand,
• 38:02
  modern engineers don't sit around drawing spirals on paper.
• 38:05
  They inevitably turn to digital simulation software.
• 38:08
  They boot up a program, build a block diagram, and hit run.
• 38:13
  Oh yeah, they absolutely do. And this is where the traps get
• 38:15
  truly, deeply digital. The computer takes over and
• 38:20
  engineers blindly trust it. Digital Continuous system
• 38:23
  simulation sounds completely foolproof.
• 38:26
  The computer solves the equations over successive tiny
• 38:29
  time steps, but the massive pain point here is that engineers
• 38:33
  click simulate without having any understanding of the
• 38:36
  integration method running under the hood of the software.
• 38:39
  And the result. Numerical instability.
• 38:41
  Right. The simulation literally blows
• 38:43
  up, the number shoot off to Infinity, or much, much worse,
• 38:47
  the software spits out a beautiful, clean graph that is
• 38:50
  completely, fundamentally lying to you about reality.
• 38:54
  To understand why the computer lies, you have to understand
• 38:56
  what the processor is actually doing when it simulates A
• 38:59
  dynamic system. OK, walk me through it.
• 39:00
  The computer does not know the exact smooth curve of the real
• 39:04
  world math. It is lined to the future.
• 39:06
  It only knows the exact point it is at right now and the slope of
• 39:10
  the math at this exact millisecond.
• 39:12
  So it has to guess the next point.
• 39:13
  And how does it guess? The simplest, most primitive
• 39:16
  method is the Euler method. Euler calculates the
• 39:19
  mathematical slope at the current moment, draws a straight
• 39:21
  line along that slope, steps forward in time, and places the
• 39:25
  next point. I always visualize this as
• 39:27
  walking blindfolded on a winding curved track.
• 39:30
  That's a good way to look at it. You stop.
• 39:32
  You feel with your foot that the track is curving slightly to the
• 39:35
  left, so you take a perfectly straight step to the left.
• 39:39
  But because the track is continuously curving, your
• 39:42
  straight step actually takes you slightly off the track.
• 39:44
  Exactly. That error, the gap between your
• 39:46
  straight step and the true curve, is what we call
• 39:49
  truncation error. That is exactly it, and with the
• 39:52
  Euler method, the truncation error is massive and it is
• 39:56
  highly sensitive to the size of the time step.
• 39:59
  If you take a giant step forward based on one quick slope
• 40:02
  reading, you will drift wildly off the curve.
• 40:04
  So Euler is out. What do we use instead?
• 40:08
  To fix Euler's inherent blindness, engineers developed
• 40:11
  Runj CUDA methods. Instead of taking one blind
• 40:14
  guess and stepping forward, Runj CUDA essentially probes the
• 40:17
  darkness ahead before committing to a step.
• 40:20
  Probes the darkness. The industry standard is the 4th
• 40:23
  order Runj CUDA method. It relies on 4 separate complex
• 40:28
  derivative calls per single time step.
• 40:31
  So looking ahead. Right.
• 40:32
  It checks the slope of your current position, it calculates
• 40:35
  2 projected slopes in the middle of the proposed step, and it
• 40:38
  checks one projected slope at the very end of the step.
• 40:41
  Then it mathematically averages those 4 slopes together to
• 40:45
  create an incredibly accurate curved path forward.
• 40:50
  It vastly improves accuracy, but the trade off is brutal, isn't
• 40:53
  it? It takes four times as much
• 40:55
  computing power to calculate a single millisecond of time.
• 40:58
  Right. And if that is too
• 41:00
  computationally expensive, you have 1/3 option predictor
• 41:02
  corrector methods like Adam's Bashforth and Adam's molten.
• 41:06
  How do those work? Instead of probing blindly into
• 41:08
  the future with multiple slope calculations within the current
• 41:11
  step, these methods look backward.
• 41:13
  They use historical data. They look at the past few steps.
• 41:17
  The simulation is already taken to predict where the next step
• 41:20
  should naturally fall on the curve, and then they use the
• 41:23
  differential equation to correct that prediction slightly.
• 41:26
  So it's more efficient. It uses less processing power
• 41:29
  per step than Run Jakuda, but requires the computer to
• 41:32
  constantly store past data in its active memory.
• 41:35
  OK, so let's talk step by step optimization.
• 41:38
  I have my software open. I understand Euler is bad and
• 41:41
  Ranj Kakuta is good, but how do I choose the right step size?
• 41:46
  That's the $1,000,000 question. Because if I set my digital time
• 41:49
  step to 1 nanosecond, the straight line truncation error
• 41:53
  will be virtually 0, but the computer will take 3 continuous
• 41:57
  weeks to simulate a one minute drone flight.
• 42:00
  Exactly. When choosing a step size,
• 42:03
  you're battling 2 completely opposing types of error.
• 42:06
  Truncation error, as we discussed, is caused by two
• 42:08
  largest step size. The straight lines cut the
• 42:11
  corners of the real curve and the simulation drifts away from
• 42:14
  physical reality. To fix it, you make the step
• 42:16
  size smaller. But if you make it too
• 42:18
  microscopic, you run into round off error.
• 42:20
  What causes round off error? Computers only have finite
• 42:23
  decimal memory. A processor can only hold so
• 42:26
  many decimal places before it has to chop the number off.
• 42:28
  Oh, so just deletes the end of the fraction?
• 42:30
  Yes. When you simulate a system at a
• 42:33
  nanosecond scale, you are adding billions of microscopic numbers
• 42:37
  together over and over. Every single time the computer
• 42:40
  does the math, a tiny fraction of a decimal is rounded off and
• 42:43
  lost. And over time.
• 42:45
  Over billions of calculations, those tiny rounding errors
• 42:48
  accumulate, and suddenly your simulation drifts away from
• 42:51
  reality again, not because the math model was wrong, but
• 42:54
  because the computer's physical memory architecture literally
• 42:57
  corrupted the calculation. It's a trap on both sides.
• 43:00
  Step too big, you cut corners. Step too small, the computer
• 43:03
  corrupts itself. So what on earth do you do with
• 43:07
  a stiff system? Stiff systems.
• 43:10
  Let's say I'm modeling a rocket engine.
• 43:12
  One part of my machine, the spark ignition and the initial
• 43:14
  chemical explosion reacts in microseconds, but the thermal
• 43:18
  build up, the heat soaking into the massive metal rocket nozzle
• 43:22
  takes hours to fully develop. A classic problem.
• 43:24
  Do you set the step size to microseconds for the fast part
• 43:28
  and just wait a month for your computer to finish the hours
• 43:30
  long thermal calculation? That is the classic stiff system
• 43:33
  dilemma, and it ruins countless simulations.
• 43:36
  If you use a standard runch CUDA method with a step size
• 43:39
  microscopic enough to capture the ignition, you will waste
• 43:43
  endless staggering amounts of computing power on the thermal
• 43:46
  side. And the round off error.
• 43:48
  By the time you reach hour two of the simulation, the round off
• 43:51
  error will have completely destroyed your thermal data.
• 43:54
  So how do you fix it? The fix is twofold.
• 43:56
  First, you use variable step methods designed specifically
• 44:00
  for stiff systems. The software dynamically changes
• 44:03
  the step size on the fly. Oh.
• 44:05
  That's smart. It takes microscopic, incredibly
• 44:08
  careful steps during the violent ignition event, and then once
• 44:12
  the explosion stabilizes into a steady burn, the algorithm takes
• 44:15
  massive leaps forward in time when tracking the slow,
• 44:18
  predictable thermal buildup. OK, so the software adapts to
• 44:22
  the speed of the physics. What if the software can't
• 44:24
  handle it? If the fast dynamics do not
• 44:27
  meaningfully impact the slow dynamics over the long run,
• 44:30
  meaning the microsecond spark doesn't fundamentally change the
• 44:33
  three hour heat soak, you simply decouple them.
• 44:35
  You split the simulation. Yes, you strip the high
• 44:39
  frequency components out of the macro model entirely.
• 44:42
  You run one simulation just for the spark, take the final output
• 44:45
  of that spark and feed it as a simple static initial condition
• 44:50
  into a completely separate long term thermal model.
• 44:53
  Divide and conquer. Mind blowing.
• 44:55
  As if simulation wasn't tricky enough, we finally need to close
• 44:58
  this deep dive down by answering the two most common questions
• 45:02
  engineers face today when dealing with the unpredictable
• 45:05
  reality of the physical world. Yeah, these are the big ones.
• 45:08
  Question one. How do we mathematically handle
• 45:10
  random real world noise? The wind outside does not blow
• 45:14
  in a perfect sine wave. No, it certainly doesn't.
• 45:16
  The electrical static in your sensor wiring is not a neat step
• 45:19
  function. Reality is chaotic.
• 45:22
  Right, when variables contain random unpredictable, non
• 45:25
  deterministic components, we are officially dealing with
• 45:28
  stochastic systems. And how do we model those?
• 45:31
  To model stochastic systems, engineers have to completely
• 45:34
  abandoned their deterministic differential equations.
• 45:37
  You can't rug an exact equation for a gust of wind.
• 45:39
  Instead, we turn to probability density functions, specifically
• 45:44
  the zero mean Gaussian distribution.
• 45:46
  The classic bell curve. Exactly.
• 45:48
  The absolute magic of a Gaussian or normal distribution is that
• 45:52
  it can be completely specified by just its variance, its
• 45:55
  spread, and if you feed a purely Gaussian noise input into a
• 45:59
  linear system, the output is mathematically guaranteed to
• 46:02
  also be perfectly Gaussian. So it preserves it's shit.
• 46:06
  Yes, it makes the math incredibly predictable even when
• 46:09
  the input is chaotic. But how do you know if the noise
• 46:11
  from one second ago affects the noise right now?
• 46:14
  Wind isn't purely random. A gust right now usually means
• 46:17
  it will still be gusting a half second from now.
• 46:19
  For that you use the autocorrelation function.
• 46:22
  This is a measure of time correlation.
• 46:24
  It tells you exactly how strongly past values of the
• 46:27
  random noise affect future values.
• 46:29
  OK. Give me an example.
• 46:30
  If the noise is purely random white noise like TV static, the
• 46:35
  autocorrelation is 0 everywhere except at the exact present
• 46:39
  moment. The past does not dictate the
• 46:42
  future, but if the noise is a rolling wind gust, the
• 46:45
  autocorrelation will show a distinct sloping curve.
• 46:48
  And what do you do with that curve?
• 46:49
  You pair this autocorrelation data with power spectrum
• 46:53
  filtering to figure out exactly which frequencies of the random
• 46:56
  noise possess the most physical energy, so you can specifically
• 46:59
  design your drone software filter to ignore them.
• 47:02
  Which perfectly tease up question too, How do we actually
• 47:05
  integrate these continuous analog physical systems with
• 47:09
  modern digital computer processors?
• 47:11
  A huge challenge today. Computers don't think in
• 47:14
  continuous time. A computer processor thinks in
• 47:16
  discrete digital ticks. It pulses.
• 47:19
  This brings us to discrete and hybrid systems.
• 47:22
  To get continuous real world data like the pressure in a pipe
• 47:25
  into a digital computer, you must use uniform sampling.
• 47:29
  OK. So sampling at regular
• 47:30
  intervals. Yes, you tell the sensor to
• 47:33
  sample the physical variable at a set interval, say every one
• 47:36
  millisecond. But you must obey the
• 47:39
  fundamental law of digital conversion, the sampling
• 47:43
  theorem, also known widely as the Nyquist criterion.
• 47:46
  The Nyquist criterion. What is the rule?
• 47:49
  The sampling period must be mathematically fast enough,
• 47:52
  specifically greater than twice the highest frequency present in
• 47:56
  the signal, to capture the true physical movement.
• 47:59
  If you sample too slowly, you get a catastrophic error called
• 48:03
  aliasing. You know, aliasing is so easy to
• 48:05
  visualize. It is exactly like when you
• 48:07
  watch a car commercial on TV and the car is driving forward on
• 48:11
  the highway, but the wheels look like they are spinning
• 48:13
  backwards. Yes, the camera frame rate
• 48:15
  effect. The camera's frame rate, which
• 48:17
  is its sample rate, isn't fast enough to catch the true
• 48:20
  continuous rotation of the wheel.
• 48:22
  It only captures fragmented snapshots that trick the brain
• 48:25
  into seeing reverse motion. If your drones altimeter alias
• 48:29
  is a vibration, the computer might think the drone is falling
• 48:32
  when it's actually rising. The data is completely
• 48:34
  corrupted. Exactly.
• 48:36
  So that gets data into the computer safely.
• 48:38
  But to output data from the digital computer back out to the
• 48:41
  physical motors, we use something called a zero order
• 48:44
  hold. A zero order hold.
• 48:46
  Because the computer only spits out control commands at discrete
• 48:49
  interval, say one command every 10 milliseconds, the zero order
• 48:52
  hold takes that discrete number and holds a physical voltage to
• 48:56
  the motor absolutely constant until the very next digital
• 48:59
  number arrives. So it's not a smooth curve
• 49:01
  anymore. No, It creates A rigid staircase
• 49:04
  pattern of voltage inputs for the analog system to react to.
• 49:08
  A zero order hold is literally a strobe light in a dark room.
• 49:12
  It freezes continuous fluid motion into distinct, separate,
• 49:16
  rigid steps that a digital computer can actually comprehend
• 49:19
  and control. That is a brilliant way to put
• 49:21
  it. And to handle the mathematics of
• 49:23
  these discrete staircase steps, we cannot use the continuous
• 49:26
  Laplace transform we talked about earlier, the.
• 49:28
  Laplace path only works on continuous yarn.
• 49:30
  Exactly for digital steps, we introduced the Z transform.
• 49:34
  The Z transform does for discrete digital systems exactly
• 49:37
  what the Laplace transform does for continuous analog ones.
• 49:40
  So it dissolves the digital knots.
• 49:42
  Right, it takes discrete different equations and turns
• 49:45
  them into manageable algebra, allowing us to build pulse
• 49:48
  transfer functions to perfectly control complex computer driven
• 49:53
  robotics. Wow, that is an absolutely
• 49:55
  incredible amount of ground covered today.
• 49:57
  Think about what we just did. We covered a lot.
• 49:59
  We took a chaotic physical system.
• 50:01
  We idealized it into universal TA&D components.
• 50:05
  We mapped the energy flow using state variable matrices.
• 50:09
  We untangled the math by bringing it into the time and
• 50:12
  frequency domains using Laplace transforms and Bode plots.
• 50:15
  We shatter the dangerous illusion of linearity.
• 50:18
  We navigated the hidden integration traps of computer
• 50:21
  simulation, and finally we bridged the gap between the
• 50:24
  continuous analog world and the discrete digital brain using the
• 50:28
  Z transform. It is the complete holistic life
• 50:31
  cycle of dynamic system modeling.
• 50:33
  But as our digital computers get exponentially faster, as our Z
• 50:36
  transforms in our 4th order Ranjakuda algorithms get more
• 50:40
  impossibly precise, and as artificial intelligence begins
• 50:43
  to actually automate the formulation of these very state
• 50:46
  matrices for us, it leaves us with a truly provocative thought
• 50:51
  about the future of engineering. What's that?
• 50:54
  Will we eventually hit a point in our lifetimes where our
• 50:56
  mathematical models achieve such perfect God like sidelity that
• 51:01
  physical prototypes become entirely obsolete?
• 51:04
  Or will the stochastic chaos of the real world, the
• 51:07
  unpredictable friction, the uneven heat gradients in the
• 51:10
  stubborn random noise of reality, always demand that an
• 51:14
  engineer eventually has to put down the simulation, build the
• 51:17
  physical thing, turn it on, and watch it break?
• 51:19
  Man, a terrifying and strangely beautiful thought to leave off
• 51:22
  on. You can't truly simulate reality
• 51:24
  until you truly understand it, and maybe reality always has one
• 51:27
  last unpredictable trick up its sleeve.
• 51:30
  If you got something useful out of today's episode, hit follow
• 51:32
  and drop a like. It helps grow the show and keeps
• 51:34
  the engineering knowledge flowing.