Lecture 12 - Control I

Professor Feynman at your service. What complex system, mathematical beast, or project hurdle are we dismantling and mastering today?

I see you've brought us a lecture on the fundamentals of Robot Control. To get you to a rock-solid, intuitive grasp of this material as quickly as possible, we are going to strip away the academic jargon and take this one core piece at a time.

Part 1

1. The Hook & The "Why"

Imagine a massive 6-Degree-of-Freedom (6DoF) industrial robot holding a heavy payload out at arm's length. Gravity is constantly pulling down on the center of mass with a force of $F_{g} = m \times g$ . The robot's shoulder and elbow joints are fighting immense, continuous gravitational torque just to stay still.

If the power suddenly cuts out in the factory, you don't want a multi-ton metal arm violently crashing into the floor. Furthermore, when the power is on, how do we make the robot move smoothly to a target millimeter by millimeter, while fighting gravity, inertia, and its own mechanical friction? That is the exact problem robot control algorithms and hardware are designed to solve.

2. The Intuitive Core: Anatomy of an Actuator

Before we can write control algorithms (the software), we must understand the physical constraints of the hardware. A robotic joint isn't just a simple spinning motor; it's a sophisticated stack of components working in sequence.

Here is the physical sequence of a joint actuator, from input to output:

The Encoder (Feedback): Think of this as the robot's sense of proprioception. It constantly measures the position of the shaft so the controller knows exactly where the joint is at any given microsecond.
The Electromagnetic Brake (Fail-Safe): Sitting inside the housing, this is a mechanical safety net designed to lock the joint and maintain positional stability.
The Electric Servo Motor: This consists of a rotor and stator, acting as the "muscle" that generates the raw torque.
The Planetary Gearbox (Amplification): Electric motors love to spin very fast with relatively low torque. However, robot joints need to move relatively slowly with immense torque. The gearbox sits at the end of the line to amplify that torque before delivering the final mechanical output to the shaft.

Because of this specific hardware stack, the operating sequence is highly choreographed: the controller must first apply an electrical signal to disengage the brake. Only then does it send the control signal to the motor to generate torque, which passes through the gearbox to physically move the joint.

3. Curated Deep-Dive

To intuitively bridge the gap between these physical mechanical components and the control theory we will tackle next, I highly recommend skimming Chapter 8 of Robotics: Modelling, Planning and Control by Siciliano et al. It perfectly illustrates how things like gearbox elasticity and motor friction complicate our math.

4. Socratic Checkpoint

Let's pause here and lock in your intuition about the hardware before we move on to the Cascade Control Structure.

Look closely at the fail-safe mechanism. The text specifies that the brake is "spring-applied" , and that the controller must apply an electrical signal to disengage it. From an engineering and physics standpoint, why is it critical to design the brake to require power to release, rather than requiring power to engage?

Part 2

We want safety regardless of power so if power goes off then I need the robot to stop. So it needs to be activated by energizing it. That's more safe and more robust against power failure.

Exactly right. You nailed it.

If the power to the robot gets cut, we want the system to immediately default to the physics of the spring, mechanically clamping down to prevent a multi-ton arm from collapsing. We use electrical energy to fight the spring and release the brake. This is known in engineering as a "normally closed" or "fail-safe" system.

Now that we have a physically safe joint, let's inject some intelligence into it. We are moving to Page 4: The Cascade Control Structure.

1. The Hook & The "Why"

Imagine you are at a red light in a sports car. When the light turns green, your goal is to reach the next stoplight exactly 100 meters away. You don't just slam the gas pedal to the floor, hold it, and then slam the brakes at the very last microsecond. If you did, you'd overshoot, skid, or blow the engine.

Instead, your brain does something highly sophisticated: you calculate the distance (Position), which dictates how fast you should be going (Speed), which dictates how hard you press the pedal right now (Torque/Current). A robot joint does the exact same thing using a Cascade Control Structure.

2. The Intuitive Core: Nested Loops

Instead of one massive, complicated mathematical equation trying to control the motor's position directly, we break the problem down into three smaller, faster, "nested" control loops, one inside the other :

The Inner Loop (Current/Torque Regulator): This is the fastest loop. It talks directly to the motor's power supply. It doesn't know where the robot is or how fast it's going; its only job is to make sure the electrical current flowing through the motor exactly matches what is being requested.
The Middle Loop (Speed Regulator): This loop looks at how fast the joint is currently spinning. If it needs to speed up, it sends a request to the Inner Loop saying, "Give me more current!"
The Outer Loop (Position Regulator): This is the "manager." It looks at the final destination. If the robot is far away, it tells the Middle Loop, "We need a high speed!" As the joint gets closer to the target, it tells the Middle Loop, "Okay, start slowing down."

By nesting them this way, we decouple the electrical dynamics (current) from the mechanical dynamics (speed and position).

3. Curated Deep-Dive

To see how these nested loops are mathematically tuned in the real world, look up the "Ziegler-Nichols tuning method for Cascade PID controllers." It will show you exactly why engineers always tune the innermost (current) loop first, before tuning the speed or position loops.

4. Socratic Checkpoint

Let's test your engineering intuition.

If you look at the block diagram for the Cascade Control Structure (Page 4), you will see little blocks labeled "Max / Min" sitting between the Position Regulator and the Speed Regulator, and again between the Speed Regulator and the Current Regulator.

In the context of our sports car analogy, or our heavy 6DoF robotic arm, why is it absolutely critical to mathematically "cap" or saturate the output of the Position loop before it is handed off to the Speed loop? What physical disaster are we preventing?

Part 3

This is because it respects the physics and the hardware I'm dealing with for example for a robot it has joint limits and for a car it has a maximum speed that it can go with. So by using limits and minimum and maximum, I am respecting the hardware and the physics of it.

Spot on. You are exactly right—you are enforcing the laws of physics on the mathematics.

To refine that just a bit: remember that the output of the Position Regulator is actually a Speed request to the middle loop. If the target position is very far away, the math will calculate a massive position error. Without those Max/Min limiters, the Position loop might demand a speed of 10,000 RPM from a motor that can only physically spin at 3,000 RPM. The controller would essentially demand the impossible, maxing out the current, generating massive heat, and potentially melting the coils or stripping the gears before the robot even got close to the target.

By capping the signals, we say: "I don't care how far away the target is, you will not ask the motor to spin faster than its physical limit."

Now that we have successfully controlled a single joint, let's look at the chaos that happens when we string six of them together. We are moving to Pages 8 & 9: The Control Problem & Robot Dynamics.

1. The Hook & The "Why"

Imagine swinging a baseball bat. When you rotate your shoulder, your elbow and wrist naturally want to whip outward due to centrifugal force. You don't have to consciously think about keeping your elbow stable; your brain automatically sends counter-acting signals to your arm muscles.

A multi-axis robot has the same problem. When joint 1 (the base) rotates quickly, it creates massive centrifugal and Coriolis forces that whip joint 2 and joint 3 around. The movement of one joint violently disturbs the others. So, how does the computer brain of the robot handle this?

2. The Intuitive Core: Decentralized vs. Centralized

Engineers generally take two different approaches to this problem, depending on the hardware :

Decentralized (Independent) Control: We give every single joint its own isolated controller. Joint 2's controller has no idea what Joint 1 is doing. It just treats all those whipping forces as annoying, random disturbances. This actually works pretty well if the robot has high-ratio gearboxes. The gearbox acts like a thick wall; it amplifies the motor's torque going out, but it also heavily dampens those chaotic physical forces coming back in from the other joints.
Centralized Control (MIMO - Multiple Input, Multiple Output): This is the "big brain" approach. Instead of isolated controllers, one master mathematical model looks at the entire robot simultaneously. If it commands Joint 1 to spin, it instantly calculates the exact whipping force that will hit Joint 2, and preemptively tells Joint 2's motor to push back. We absolutely must use this approach if we are using Direct Drive motors (motors with no gearboxes), because there is no mechanical wall to hide behind—every dynamic force hits the motor directly.

3. Curated Deep-Dive

To truly understand the "whipping" forces, look up a visualization of "Coriolis and Centrifugal forces in manipulator dynamics." It will intuitively show you how a spinning base joint physically pulls the outer joints outward.

4. Socratic Checkpoint

Let's look at the beast of an equation on Page 9, which represents the Centralized dynamic model of the manipulator:

M (q) \ddot{q} + C (q, \dot{q}) \dot{q} + D \dot{q} + g (q) = τ + J^{T} (q) F_{a}

Don't let the symbols scare you; this is just a highly evolved, rotating version of Newton's $F = m a$ .

$τ$ is the Force (torque) we supply.
$\ddot{q}$ is the acceleration.
Therefore, $M (q)$ is our mass, or "Inertia Matrix".

Notice that the inertia matrix is written as $M (q)$ , meaning Inertia is a function of $q$ (the current position/angle of the joints). If a robot's physical weight (mass) never changes, why does its inertia change depending on what pose the robot is standing in? Think about an ice skater spinning on the ice.

Part 4

this is because while mass is constant inertia depends on the configuration of the Rope so it's not just a function of the mass of the links. It's also a function of the joint angles that the robot is going to have that's why metrics is a function of the position and angle of the joints.

Bingo. (I know you meant robot and matrix, but your physics intuition is completely flawless.)

Exactly like an ice skater pulling her arms in to spin faster, a robot stretching its arm straight out has a vastly different moment of inertia than a robot curled up in a tight ball. Because the angles ( $q$ ) literally change the physical shape of the mass distribution, the Inertia Matrix $M$ is a function of $q$ .

Now that you understand why the math is so difficult, let's look at how engineers actually solve it without melting the robot's onboard computer. We are moving to Pages 12 & 13: Joint Space Control & Beating the Non-Linearity.

1. The Hook & The "Why"

The dynamic equation $M (q) \ddot{q} + C (q, \dot{q}) \dot{q} + D \dot{q} + g (q) = τ + J^{T} (q) F_{a}$ is a beautiful representation of reality, but it is a nightmare to calculate in real-time, thousands of times a second. If the onboard controller tries to mathematically calculate every tiny shifting inertia and whipping Coriolis force with perfect precision, it will lag. We need a mathematical shortcut.

2. The Intuitive Core: The "Disturbance" Trick

Look at "Consideration #2" on Page 12. Engineers play a brilliant mathematical trick here. They look at that shifting, complicated Inertia Matrix $M (q)$ and slice it in two:

M (q) = \overset{―}{M} + Δ M (q)

$\overset{―}{M}$ : The "average" or constant inertia of the joint. This is just a basic, unchanging number. It's incredibly easy for a computer to handle.
$Δ M (q)$ : The "Delta." This is the shifting, messy part that changes with the robot's pose.

They take the easy, constant part ( $\overset{―}{M}$ ) and use it to build a nice, clean, predictable Linear system.

Then, they take all the messy stuff—the shifting inertia $Δ M (q)$ , the Coriolis whipping forces $C (q, \dot{q})$ , and Gravity $g (q)$ —sweep it all into one massive pile, and label it $d$ for "Disturbance".

If you look at the block diagram on Page 13, you'll see the genius of this. We've conceptually split the robot into two systems:

A nice, decoupled linear system that behaves exactly how we want.
A highly coupled, non-linear system acting as an annoying "black box" that just throws disturbances ( $d$ ) at us.

Instead of perfectly calculating the universe, the controller just says, "I'll control the simple linear part, and I'll treat everything else as an annoying wind blowing against me, adjusting my power on the fly to compensate."

3. Curated Deep-Dive

To see how modern control software fights back against that $d$ term without actually calculating the massive equation, look into "Disturbance Observers (DOB) in Motion Control." It's a clever algorithm that estimates the total sum of all those messy forces purely by watching how the motor unexpectedly slows down. It calculates the counter-force needed almost instantly!

4. The Socratic Checkpoint

Let's wrap up this concept with one final thought experiment based on the math. Look closely at the equation for that total disturbance $d$ on Page 12:

d = (K_{r}^{- 1} Δ M (q) K_{r}^{- 1}) {\ddot{q}}_{m} + (K_{r}^{- 1} C (q, \dot{q}) K_{r}^{- 1}) {\dot{q}}_{m} + K_{r}^{- 1} g (q)

$K_{r}$ is the reduction ratio of the gearbox. Notice that every single messy term ( $Δ M$ , $C$ , $g$ ) is multiplied by $K_{r}^{- 1}$ (the inverse of the reduction ratio).

If an industrial robot has a massive gearbox reduction ratio (say, 100:1), meaning $K_{r}$ is very large and $K_{r}^{- 1}$ is very small (like 0.01)... what mathematically and physically happens to all those chaotic non-linear disturbances $d$ ? And based on your answer, why does having heavy gearboxes make decentralized (independent) joint control so much easier?

Part 5

Just because a heavy gearbox amplifies the output and then in the input so all those external disturbances will be weakened very heavily when fit from the outside through the gearbox. That's why the reduction ratio massively influences the magnitude of the disturbance, thus making decentralized joint control almost entirely caring about controlling a highly linear system with minimal disturbance.

Absolutely brilliant! You just hit the exact realization that dictates how 90% of the world's industrial robots are built.

You correctly identified that the gearbox acts as a massive mechanical firewall. The motor pushes out with amplified strength, but chaotic external forces trying to push back in are divided by that huge ratio $K_{r}$ . Because of this, engineers can use Decentralized control schemes, treating each joint as an isolated, highly linear system and completely ignoring the "wobbly" dynamics of the rest of the arm. It saves massive amounts of computing power.

We have successfully conquered the mechanical hardware, the nested control loops, and the terrifying non-linear math. To finish this lecture, let's tie all of this theory into the real, physical cables and computers shown on Pages 6 and 7.

1. The Hook & The "Why"

Imagine you have just written the perfect trajectory algorithm in Python. You can't just plug a USB cable from your laptop directly into a 1,000-pound industrial robotic arm. A one-second lag from a background OS update could cause the arm to fail its control loop and crash into a wall. So, how do we separate the "thinking" from the "reflexes"?

2. The Intuitive Core: Brain vs. Spinal Cord

Look at the system architecture diagrams . Real-world robotics splits the system across a strict Network Boundary:

The Brain (The PC / Motion Planner): Sitting safely on a desk, a standard computer looks at the environment (like CMOS cameras or user inputs). It acts as the Motion planner and Trajectory generator. It decides where the robot needs to go and the path it should take, but it doesn't actually control the motors.
The Spinal Cord (The Robot Controller): Look at the ABB IRC5 or generic Robot controller boxes. This is a rugged, highly specialized industrial computer. It takes the requested path from the PC and runs those blazing-fast, nested Cascade Control loops we talked about earlier. It talks directly to the Actuators and reads the Sensors thousands of times a second without ever being interrupted by a background task.
The Operator Interface (FlexPendant): The handheld device (like the ABB FLEXPENDANT ) allows a human to manually jog the robot, bypassing the PC entirely to ensure safety and precise manual teaching on the factory floor.

3. Curated Deep-Dive

To deeply understand why we split the brain from the spinal cord, look up the difference between a "General Purpose Operating System (GPOS like Windows/Linux)" and a "Real-Time Operating System (RTOS)." It is the fundamental software concept that keeps industrial robots safe.

4. Socratic Checkpoint

This brings us to the end of Lecture 12, but let's test your overall systems intuition one last time.

If we look at the flow of data from the Trajectory generator to the Controller, we know the Controller is constantly doing calculus—calculating derivatives for velocity ( $\dot{q}$ ) and acceleration ( $\ddot{q}$ ) based on the changing position over time ( $d t$ ).

Why is it an absolute mathematical disaster if the Robot Controller's internal clock lags even by a few milliseconds, and how does separating it from the PC (which handles the cameras and user interfaces) prevent this disaster?

Part 6

This is because computers first of all do integration and derivative in the discrete domain so they take great time steps and use that to take the derivative of variables and integrate them so a lag would disrupt this time strip and it would disrupt the calculations so thus a specialized robot controller must have a highly robust internal clock that is not interrupted by any background processes so for the PC it can have background forces is running and so on as long as it is just doing perception but the robot controller must have higher robust times tips.

Magnificent! You have hit the absolute bullseye of digital control theory.

You intuitively grasped exactly how digital computers "fake" continuous calculus. The controllers in those block diagrams are constantly taking discrete derivatives, which are essentially division problems:

V e l o c i t y = \frac{P o s i t i o n_{c u r r e n t} - P o s i t i o n_{p r e v i o u s}}{Δ t}

In a Real-Time Operating System (RTOS) running on a dedicated Robot controller, that $Δ t$ (time step) is a mathematically sacred contract. If the system promises a loop time of exactly 1 millisecond, it delivers it in 1 millisecond.

If we ran that control loop on a standard PC and the operating system decided to pause for 50 milliseconds to check for a Wi-Fi update, the robot would continue moving blindly during that lag. When the PC finally woke up, the position error would be massive. The controller would try to divide by that assumed $Δ t$ , resulting in a mathematically infinite speed request, and the robotic arm would violently snap, likely destroying the Actuators or smashing through the workspace.

By drawing a hard network boundary, we let the PC handle the heavy, forgiving tasks (like CMOS cameras and Trajectory generator math), while the industrial controller acts as an unbreakable spinal reflex.

The Journey Complete

Look at what you've successfully dismantled and mastered today:

The Hardware: You understand exactly why the sequence of an encoder, a fail-safe brake, a motor, and a heavy gearbox prevents catastrophe .
The Cascade Control: You intuitively see how nesting Current, Speed, and Position loops—and capping them with physical limits—keeps the system stable .
The Non-Linear Math: You recognized how engineers use heavy reduction ratios to magically shrink chaotic dynamic disturbances, allowing for simple, decentralized control of highly complex arms .
The Architecture: You understand the critical software split between high-level path planning and low-level, real-time calculus .

You didn't just memorize formulas; you understood the physical engineering reality behind them. That is the true mark of an engineer.

Professor Feynman out. Class dismissed!