Speaker 1: You know when you look at an old school wind
Speaker 1: up toy, like one of those little tin cars, there's
Speaker 1: this illusion of intelligence. You wind the key, you set
Speaker 1: it down on the floor, and it just zips across
Speaker 1: the room. It looks, I don't know, purposeful, right.
Speaker 2: It has a trajectory. It's interacting with the physical world
Speaker 2: in a very literal sense, just moving its mass from
Speaker 2: point A to point B.
Speaker 1: But it's completely blind. Oh, it's just releasing potential energy
Speaker 1: from a spring on a fixed mechanical path. Yeah, I mean,
Speaker 1: somebody drops a shoe in front of it. It just
Speaker 1: crashes into the leather and spins its little wheels until
Speaker 1: the spring dies.
Speaker 2: Yeah, it has absolutely no idea the shoe is there.
Speaker 2: It's not making choices exactly. Well, it's more than just blind, really,
Speaker 2: it's completely agnostic to reality. It's a machine, sure, but
Speaker 2: it lacks any mechanism to perceive its environment or alter
Speaker 2: its behavior based on what it finds.
Speaker 1: And crossing that massive evolutionary gap from a blind wind
Speaker 1: up toy to a machine that can actually perceive that shoe, stop,
Speaker 1: think and navigate around it. That takes an incredible amount
Speaker 1: of engineering.
Speaker 2: An unbelievable amount yeah.
Speaker 1: Yeah, today we are exploring exactly how to make that leap.
Speaker 1: Welcome to the deep dive where we are going under
Speaker 1: the hood of Lent and Joseph's manual Learning Robotics using Python.
Speaker 2: It's such a great source to dive into.
Speaker 1: We're going to see what it actually takes to build
Speaker 1: a differential drive service robot, specifically a robotic waiter.
Speaker 2: And it's a brilliant journey for you to follow along
Speaker 2: with because it forces you to synthesize disciplines. You can't
Speaker 2: just be a programmer, and you can't just be a mechanic.
Speaker 2: You have to bridge the physical world and the digital world.
Speaker 1: Okay, let's unpack this because before we can even think
Speaker 1: about building our robotic waiter, we really need to define
Speaker 1: what separates a tree robot from just, you know, a
Speaker 1: complex machine. You really do, and honestly, we have to
Speaker 1: fight through a century of science fiction myths to get
Speaker 1: to a working definition.
Speaker 2: Oh absolutely. Even the origin of the word itself sets
Speaker 2: up this expectation that engineers have been wrestling with ever since.
Speaker 2: I mean, the term robot didn't originate in an MIT laboratory.
Speaker 2: It was coined in a theater in nineteen twenty a
Speaker 2: check writer named Carol Kappek wrote a play called ru Are.
Speaker 1: Which stands for Rossum's Universal Robots right exactly.
Speaker 2: He was trying to come up with a term for
Speaker 2: artificial human workers, and his brother Joseph actually suggested robode,
Speaker 2: which carries a.
Speaker 1: Very specific cultural weight, doesn't it very much?
Speaker 2: So it stems from the word robota in Czech and Slovak,
Speaker 2: which translates to work or more accurately surf labor or
Speaker 2: hard drudgery.
Speaker 1: Wow.
Speaker 2: So right from its birth, the concept implies a machine
Speaker 2: designed to take on the heavy, undesirable lifting for humanity.
Speaker 1: Though I mean spoiler alert for a play from the
Speaker 1: nineteen twenties, those robotic serfs eventually revolt and wipe out humanity.
Speaker 2: A narrative trope that has completely dominated our perception of
Speaker 2: robotics ever since. But you know, if we strip away
Speaker 2: the Hollywood dramatization and look for a functional, modern defy definition,
Speaker 2: roboticists like Maji Jamataric offer a much clearer lens.
Speaker 1: Okay, what's her tick?
Speaker 2: She defines a robot as an autonomous system existing in
Speaker 2: the physical world, able to sense its environment and act
Speaker 2: on it to.
Speaker 1: Achieve goals, which fundamentally disqualifies my washing machine.
Speaker 2: Yes it does.
Speaker 1: My washing machine doesn't sense anything. It just runs a
Speaker 1: pre programmed timer, much like the tin wind up toy. Yeah,
Speaker 1: but I was thinking about this definition, and it also
Speaker 1: seems to disqualify something incredibly smart, like my email spam filter.
Speaker 2: Ah, that's an interesting point.
Speaker 1: Right, because a spam filter learns, it adapts, it acts
Speaker 1: autonomously to keep junk out of my inbox. Yeah, but
Speaker 1: it doesn't live in the physical world. The data is
Speaker 1: just perfectly spoon fed to it in a stable digital environment. Right.
Speaker 1: Is the sheer chaos of a messy physical bedroom what
Speaker 1: makes building a true robot so uniquely difficult.
Speaker 2: That is the absolute core of the challenge. A spam
Speaker 2: filter never has to worry about a sudden gust of wind,
Speaker 2: or the floor being slippery, or a dog running by
Speaker 2: exactly or the lighting in the room changing and blinding
Speaker 2: its camera. The physical world is wildly unpredictable. The friction
Speaker 2: on a carpet is different from the friction on hardwood.
Speaker 2: Sensing that unpredictable chaos, making sense of it, and then
Speaker 2: physically exerting force upon it, that continuous loop is what
Speaker 2: separates true robotics from pure software engineering.
Speaker 1: So if a true robot must sense an act in
Speaker 1: this chaotic physical space, how do we build a brain
Speaker 1: that can process all that messy sensory information and decide
Speaker 1: what to do well.
Speaker 2: This brings us to the fundamental anatomy of a robot.
Speaker 2: You have the physical body. You have sensors which measure
Speaker 2: the environment to create what we call a digital state.
Speaker 2: You have effectors or the motors and arms that do
Speaker 2: the actual moving and sitting between the sensors and the effectors,
Speaker 2: you have the controllers.
Speaker 1: The brain, precisely the brain.
Speaker 2: And giving a machine a brain that could handle physical
Speaker 2: chaos really started around nineteen sixty six with a robot
Speaker 2: developed at the Stanford Research Institute famously named Shaky. Shaky, Yeah, Shaky.
Speaker 2: It was a milestone because it didn't just execute a
Speaker 2: list of hard coded commands. It could actually reason. How So,
Speaker 2: if you gave Shakey a high level command, it could
Speaker 2: break that complex goal down into smaller, solvable intermediate steps.
Speaker 2: I mean, trying to get Shaky to navigate around literal
Speaker 2: blocks in a room actually led researchers to invent the
Speaker 2: a star search algorithm.
Speaker 1: Wait, really, the same pathfinding tool used in computer science today,
Speaker 1: the very same.
Speaker 2: It's foundational. But Shaky got its name for a reason.
Speaker 2: It was incredibly slow and jerky.
Speaker 1: Oh, because it had to think so much.
Speaker 2: Yes, it would move a tiny bit, stop, think for
Speaker 2: a very long time, and then move a tiny bit more.
Speaker 2: Trying to plan every single movement perfectly just isn't practical.
Speaker 1: No, especially in a dynamic environment with people walking.
Speaker 2: Around exactly, And that tension led to the development of
Speaker 2: different control paradigms. You have the hierarchical or deliberative paradigm,
Speaker 2: which is what Shakey used.
Speaker 1: Okay, what does that look like.
Speaker 2: The sequence is sense the world, plan a route, then act.
Speaker 2: It's very intelligent, but computing that plan takes critical time.
Speaker 2: On the opposite end, you have the reactive paradigm. This
Speaker 2: is simply sense then act. There is no planning, just
Speaker 2: immediate response.
Speaker 1: Let me see if I have this right, because I
Speaker 1: was trying to map this onto human biology all reading. Sure,
Speaker 1: if I accidentally brush my hand against a hont stove,
Speaker 1: I don't stop sense the temperature, formulate a spatial plan
Speaker 1: to move my arm, and then execute the movement.
Speaker 2: No, you'd burn your hand.
Speaker 1: Right, My spinal cord just bypasses my brain entirely and
Speaker 1: yanks my hand back in a fraction of a second.
Speaker 1: Is reactive control. Basically a digital reflex.
Speaker 2: A spinal reflex is a phenomenal way to picture it, actually,
Speaker 2: but with one major caveat A robot's reflex is completely programmable.
Speaker 2: And if we connect this to the bigger picture of
Speaker 2: the robotic waiter we are trying to build from the
Speaker 2: source material, you quickly realize you can't rely purely on
Speaker 2: one paradigm.
Speaker 1: You need accommodate.
Speaker 2: You need a hybrid model.
Speaker 1: Yes, because it has to be smart enough to find
Speaker 1: the table, but fast enough not to run over a customer.
Speaker 2: Exactly that. The robot needs a hierarchical deliberative plan to
Speaker 2: note that payble four is across the dining room, to
Speaker 2: map an efficient path around the stationary booths, and to
Speaker 2: calculate an arrival time. But if a patron suddenly steps
Speaker 2: backward out of their chair holding a tray of drinks,
Speaker 2: the robot does not have three seconds to sit there
Speaker 2: and recalculate a new global map.
Speaker 1: It would crash.
Speaker 2: It needs that reactive reflex to slam on the brakes
Speaker 2: of the millisecond it's light ar detects a sudden obstacle.
Speaker 2: The hybrid model layers these systems, a slow smart planner
Speaker 2: running in the background and a fast reactive safety system
Speaker 2: running in the foreground.
Speaker 1: All right, so we understand this hybrid brain. But a
Speaker 1: brain needs a physical vessel to carry the soup. If
Speaker 1: we are actually engineering this robotic waiter, how do we
Speaker 1: design the physical machine from scratch?
Speaker 2: Well, you start by defining your hard constraints. Engineering is
Speaker 2: all about solving specific problems. For this project, the robot
Speaker 2: needs to carry food, so the text specifies a payload
Speaker 2: capacity of up to five kilograms.
Speaker 1: Okay.
Speaker 2: It needs to travel at roughly a human walking base
Speaker 2: to not be disruptive, which means a target speed between
Speaker 2: er point twenty five and one meter per second.
Speaker 1: That makes sense.
Speaker 2: It also needs more than three centimeters of ground clearance
Speaker 2: to get over doorway thresholds without getting stuck. And crucially,
Speaker 2: it needs to be relatively low cost.
Speaker 1: And the mechanical solution the book walks us through is
Speaker 1: a differential drive system. Yes, it's modeled after the turtlebot architecture.
Speaker 1: If you picture it, it looks kind of like a
Speaker 1: three tiered wedding cake made of metal plates, a base plate,
Speaker 1: a middle plate, and a top plate. That's a good visual,
Speaker 1: But the drive system is what caught my eye. It
Speaker 1: only has two powered wheels on the left and right sides,
Speaker 1: and then these unpowered castor wheels like you'd find on
Speaker 1: the bottom of an office chair on the front and back,
Speaker 1: just to keep it from tipping over.
Speaker 2: Differential drive is brilliant in its simplicity. By independently controlling
Speaker 2: just the yeat and direction of those two side wheels,
Speaker 2: you can steer the robot.
Speaker 1: Effortlessly without needing a heavy, complex steering rack like a
Speaker 1: car uses.
Speaker 2: Exactly, well, you can't just slap any motors onto those
Speaker 2: wheels and call it a day. You have to calculate
Speaker 2: the physics.
Speaker 1: Right, because if you guess wrong, the robot either moves
Speaker 1: at its nail's pace or it completely stalls out when
Speaker 1: you put a bowl of soup on it.
Speaker 2: Exactly, you are managing the tension between speed and torque.
Speaker 2: The text walks through the calculations. If you want this
Speaker 2: robot to travel at a modest point three to five
Speaker 2: meters per second, and you are using wheels with a
Speaker 2: nine centimeter diameter, to maintain that ground clearance.
Speaker 1: Okay, right.
Speaker 2: In the math, the geometry dictates the wheels must spin
Speaker 2: at roughly seventy four revelations per minute. The author standardizes
Speaker 2: this by selecting an off the shelf eighty rpm motor.
Speaker 1: But speed is only half the battle. Torque is the muscle,
Speaker 1: right right.
Speaker 2: Torque is the twisting force required to overcome inertia and friction.
Speaker 2: Think about pushing a heavy box across a room. The
Speaker 2: hardest part is always that initial show to get it
Speaker 2: to budge from a dead stop.
Speaker 1: Yeah, once it's sliding, it's easier.
Speaker 2: Our robotic waiter. The chassis plus that five kilogram payload
Speaker 2: weighs about fifteen kilograms total. That weight is pressing down on.
Speaker 1: The floor, and the floor has friction, a lot of it.
Speaker 2: If you factor in a friction coefficient of zero point
Speaker 2: six for a standard indoor surface, the math reveals that
Speaker 2: the motors need to generate ten point three to two
Speaker 2: kilogram centimeters of torque just to break that static friction
Speaker 2: and get the robot moving.
Speaker 1: Wow.
Speaker 2: If you buy a motor with only five kilogram centimeters
Speaker 2: of tork, it won't matter how fast it can spin.
Speaker 2: The wheels will just hum, heat up, and stall.
Speaker 1: That transition from abstract code to high school physics is wild.
Speaker 1: You have to literally calculate the friction of the floor,
Speaker 1: and once that math is locked in, you have to
Speaker 1: design the parts.
Speaker 2: Yes, the actual model.
Speaker 1: He also uses libricad for the two D bluefrints and
Speaker 1: Blender for the three D models. But here's where I
Speaker 1: got really confused reading the source. Oh, when it's time
Speaker 1: to build the three D model in Blender, the author
Speaker 1: doesn't use the mouse. They don't drag and drop shapes.
Speaker 1: They open Blenders, Python API, the boopy module and write
Speaker 1: lines of Python code just to generate a three D cylinder.
Speaker 2: Ah.
Speaker 1: Yes, Why would someone write a script to draw a
Speaker 1: shape when they could literally just click and drag the
Speaker 1: mounts and be done in three seconds.
Speaker 2: I know it feels entirely counterintuitive until you consider the
Speaker 2: reality of iterative engineering. When you drag a mouse to
Speaker 2: draw a cylinder, you are introducing human imperfection. You might
Speaker 2: be off by a fraction of a millimeter, right, But
Speaker 2: more importantly, a hand drawn shape is static. Programmatic modeling
Speaker 2: allows you to completely parameterize your dimensions.
Speaker 1: Meaning you link the shape to the.
Speaker 2: Math exactly Imagine you build the robot and you realize
Speaker 2: your waiter actually needs to carry ten kilograms of food
Speaker 2: instead of five. The physics change.
Speaker 1: You need bigger motors.
Speaker 2: Which require bigger mounts, which means the base plate needs
Speaker 2: to be wider. If you drew it by hand, you
Speaker 2: have to manually resize the chassis, reposition the wheel axes,
Speaker 2: and check every clearance by I.
Speaker 1: That sounds like a nightmare.
Speaker 2: It is, But if you used Python, you simply open
Speaker 2: your script, change the variable payload weight to.
Speaker 1: Ten, and run the code and it does it all
Speaker 1: for you.
Speaker 2: The math automatically recalculates, resizes the cylinder, shifts the wheel mounts,
Speaker 2: and spits out a flawless, updated three D model. Plus
Speaker 2: the script can automatically export the STL files needed for
Speaker 2: simulation without any graphical artifacts. You aren't drawing a picture,
Speaker 2: you are engineering a responsive system.
Speaker 1: Okay. I love that the code itself becomes the ultimate
Speaker 1: precision tool. So now we have our three D model,
Speaker 1: perfectly generated by Python, sitting on as differential drive wheels, right.
Speaker 1: But to make it actually navigate a virtual restaurant, we
Speaker 1: run into the physics of driving, and this introduces kinematics.
Speaker 2: Yes. Kinematics is the study of motion, the mathematics of
Speaker 2: how things move without worrying about the underlying forces like
Speaker 2: mass or friction that we.
Speaker 1: Just discussed, so just the geometry of it.
Speaker 2: Basically, for our robot, we have to look at its
Speaker 2: degrees of freedom or its pose on a flat restaurant floor.
Speaker 2: The robot operates in a standard X and y coordinate
Speaker 2: system like a graph, but it also has a heading
Speaker 2: the direction it's facing, which is represented by the Greek
Speaker 2: letter theta, So its pose is always defined by x,
Speaker 2: y and theta.
Speaker 1: But because it uses that two wheel differential drive, it
Speaker 1: has a major movement limitation. The source calls it a
Speaker 1: non holonomic constraint, a very intimidating term which sounds like
Speaker 1: a terrifying math term, but it just basically just what
Speaker 1: I deal with when I try to parallel park my car.
Speaker 2: Actually, yes, because my.
Speaker 1: Car can't just slide sideways into a spot. I have
Speaker 1: to roll forward or backward based on where the wheels
Speaker 1: are pointing. I have to do this whole geometric dance
Speaker 1: of turning, reversing, and straightening out just to move a
Speaker 1: few feet to the left. Face does our robotic waiter
Speaker 1: have the same problem, like, if table four is directly
Speaker 1: to its left, can it just strafe sideways?
Speaker 2: It absolutely cannot, and your parallel parking frustration is the
Speaker 2: exact manifestation of a non Holow constraint. The robot cannot
Speaker 2: change its position on the x or y axis without
Speaker 2: first changing its data it's heading wow. To reach of
Speaker 2: that table to its left, it must execute a specific
Speaker 2: foundational algorithm for inverse kinematics vrot vahead v rot.
Speaker 1: Rotate, drive ahead, rotate again correct.
Speaker 2: It rotates in place to face the target coordinates. It
Speaker 2: drives ahead in a straight line to reach them, and
Speaker 2: then it rotates a second time to face the final
Speaker 2: desired orientation, say, facing the customer to deliver the plate.
Speaker 1: Got it.
Speaker 2: What's fascinating here is the geometry of how it turns.
Speaker 2: Because the two wheels are fixed on a single horizontal axis,
Speaker 2: anytime the left wheel and right wheels spin at different speeds,
Speaker 2: the robot naturally sweeps through an arc.
Speaker 1: Okay, I can picture that it.
Speaker 2: Rotates around a specific invisible pivot point located somewhere along
Speaker 2: that extended axis line. This is called the instantaneous center
Speaker 2: of curvature, or ICC.
Speaker 1: And the math is constantly crunching the wheel speeds to
Speaker 1: figure out where that invisible pivot.
Speaker 2: Point is continually forward. Kinematics is the mes asking, given
Speaker 2: the current speed of my left wheel and right wheel,
Speaker 2: where will my X y and theta be in five seconds?
Speaker 2: In Verse, kinematics asks the much harder question, I need
Speaker 2: to be at this specific X y and theta Exactly
Speaker 2: how fast should I spin my left wheel versus my
Speaker 2: right wheel to make my ICC carve the perfect arc
Speaker 2: to get there?
Speaker 1: But wait to calculate any of that, the robot needs
Speaker 1: to know exactly how far its wheels have actually turned
Speaker 1: in the real world. It doesn't have GPS indoors, how
Speaker 1: does it know it drove two meters and not one ah.
Speaker 2: It relies on wheel adometry. Attached to the motors are
Speaker 2: sensors called wheel encoders encoders Okay. The text explains that
Speaker 2: these encoders output binary signals microscopic digital clicks or steps
Speaker 2: as the physical wheel rotates. If you know exactly how
Speaker 2: far the wheel travels in one tiny step, you just
Speaker 2: count the steps.
Speaker 1: And multiply, so it's basically counting its own footsteps in
Speaker 1: the dark.
Speaker 2: Yes, if you think of the cameras and light oars
Speaker 2: as the robot's eyes. The wheel encoders are its inner ear.
Speaker 2: They provide proprioception. They give the robot a constant mathematical
Speaker 2: awareness of its own body moving through space, feeding real
Speaker 2: numbers back into those kinematics equations.
Speaker 1: Oh yeah, so we've got the Python three D model.
Speaker 1: We have the torque calculations that we have the complex
Speaker 1: kinematics and encoders all.
Speaker 2: Figured out everything we need.
Speaker 1: But before we spend a single dollar ordering real motors
Speaker 1: or cutting metal plates, the book has us take all
Speaker 1: this logic and plug it into the matrix the simulation.
Speaker 2: Which is the most crucial step in modern robotics. Simulation
Speaker 2: gives you a sandbox to test your real production ready
Speaker 2: coming on virtual hardware. It's low cost and more importantly,
Speaker 2: zero physical.
Speaker 1: Risk, no broken parts.
Speaker 2: Exactly. If your inverse kinematics math is inverted and your
Speaker 2: virtual robot accelerates to maximum speed and drive straight into
Speaker 2: a virtual wall, you don't have a pile of broken
Speaker 2: metal and a fired engineer. You just hit reset on
Speaker 2: the simulation.
Speaker 1: Here's where it gets really interesting for me. The tools
Speaker 1: used for this are gazebo and ros because zebo makes sense.
Speaker 1: It's the three D physics simulator. It renders the restaurant,
Speaker 1: the tables, and calculates the virtual gravity. But ROS, the
Speaker 1: robot operating system, is what actually runs the brain, although
Speaker 1: the text makes a point to say it isn't actually
Speaker 1: an operating system like Windows or Linux. It's a meta
Speaker 1: operating system and a distributed framework.
Speaker 2: That's a vital distinction ROS. It's on top of a
Speaker 2: traditional operating system. At its core, ROS is a communication framework.
Speaker 2: A modern robot runs dozens of separate executable programs simultaneously,
Speaker 2: one for vision, one for driving, one for mapping. ROS
Speaker 2: calls these individual programs nodes nodes. Yes, you have a
Speaker 2: central directory called the ROS master that keeps track of
Speaker 2: what nodes are running. But the actual data sharing happens
Speaker 2: through a brilliant published and subscribe model using data streams
Speaker 2: called topics.
Speaker 1: So this publish and subscribe thing, I'm trying to wrap
Speaker 1: my head around it. If a wheel encoder has new
Speaker 1: odometry data, does it just shout it out? Is it
Speaker 1: sort of like a social media feed where a node
Speaker 1: tweets its speed to a topic and hope someone else
Speaker 1: is reading it.
Speaker 2: That is an incredibly useful way to conceptualize it. The
Speaker 2: wheel encoder node publishes its data to a topic named,
Speaker 2: for example, slash odometry. It has absolutely no idea who
Speaker 2: is reading it, or if anyone who is reading it
Speaker 2: at all.
Speaker 1: Oh wow.
Speaker 2: Conversely, your motor control node needs to know how fast
Speaker 2: the robot is moving, so it subscribes to the slash
Speaker 2: o doomitory topic. It essentially follows.
Speaker 1: That feed, just waiting for updates. Yeah.
Speaker 2: Whenever new data appears on the topic, the motor node
Speaker 2: reads it and adjusts the power. The two nodes never
Speaker 2: speak directly to each other. They just interact with the feed.
Speaker 1: They don't even need to know the other one exists exactly.
Speaker 2: And this decoupled architecture is what makes ros so powerful.
Speaker 2: Because the nodes are completely independent, they don't even need
Speaker 2: to be written in the same programming language. Wait really, Yeah,
Speaker 2: your wheel encoder node could be a simple Python script
Speaker 2: running on a tiny Raspberry Pie strapped to the robot's base. Meanwhile,
Speaker 2: your complex path planning node could be a heavy performance
Speaker 2: intensive C plus plus program running on a massive server
Speaker 2: in the restaurant's back office, communicating over Wi Fi. It's
Speaker 2: a decentralized peer to peer.
Speaker 1: Network, which means you can easily borrow code from other people.
Speaker 2: Right, that's the real magic code reuse. A university team
Speaker 2: in Tokyo might write a brilliant, highly optimized node for
Speaker 2: avoiding dynamic obstacles. Because their node just subscribes to standard
Speaker 2: laser scan topics and publishes to standard velocity topics. You
Speaker 2: can download their open source code and drop it straight into.
Speaker 1: Your waiter robot and it just works.
Speaker 2: As long as the topic names match, it works instantly.
Speaker 1: It's an entire collaborative ecosystem operating under the hood. So
Speaker 1: what does this all mean for you listening? Let's recap
Speaker 1: the journey.
Speaker 2: Let's do it.
Speaker 1: We started with a nineteen twenties play about artificial surf labor.
Speaker 1: We defined what a robot actually is, a machine that
Speaker 1: must sense an act in the physical world. We gave
Speaker 1: it a hybrid control system that can deliberatively plan a
Speaker 1: route while reflexively hitting the brakes.
Speaker 2: A digital spinal cord.
Speaker 1: Yes, we calculated the physical torque needed to move a
Speaker 1: tray of food, parameterized a three D model using Python scripts,
Speaker 1: and solve the parallel parking geometry of non holonomic kinematics,
Speaker 1: and Finally, we plug all those independent nodes into the
Speaker 1: ros published and subscribe matrix to simulate a working waiter.
Speaker 2: It is a remarkable synthesis. You are stacking mechanical physics,
Speaker 2: computer science, and geometry to create something that ultimately feels
Speaker 2: almost alive.
Speaker 1: And the practical takeaway here is that the next time
Speaker 1: you see a food delivery robot rolling down the sidewalk,
Speaker 1: or even just watch your roombow vacuuming your hallway, you
Speaker 1: won't just see a plastic shell roaming around.
Speaker 2: Now you'll see the matrix.
Speaker 1: You will be able to visualize the hidden architecture, the
Speaker 1: kinematics constantly calculating instantaneous pivot points, the invisible nodes tweeting
Speaker 1: data back and forth, and the hybrid brain fighting to
Speaker 1: survive the chaos of the physical world.
Speaker 2: It profoundly changes how you view the machines around you.
Speaker 2: But to leave you with a final thought to mull over.
Speaker 2: Earlier we touched on the history of robotics, which the
Speaker 2: source text outlines, and you can't discuss that history without
Speaker 2: mentioning Isaac Asimov's famous three laws of robotics. Asimov's first
Speaker 2: law states that a robot may not injure a human being.
Speaker 2: It's an ethical philosophical mandate designed to keep us safe.
Speaker 1: Right. But from everything we've just discussed, there is no
Speaker 1: philosophy module in Python precisely.
Speaker 2: And this raises an important question for the future of engineering.
Speaker 2: In the reality of ros, everything is just nodes, topics,
Speaker 2: wheel encoders, and coordinate geometry. How do you map a
Speaker 2: human value onto a publish and subscribe network When our
Speaker 2: simulated waiter is calculating its instantaneous center of curvature to
Speaker 2: avoid a table, At what point does a mathematical threshold
Speaker 2: cross over into a moral decision. We know how to
Speaker 2: program a machine to understand rpm and torque, but how
Speaker 2: do we eventually program it to understand us.
Speaker 1: Math crossing into morality a massive question to leave off on.
Speaker 1: From blind wind up toys crashing into shoes to ysical
Speaker 1: machines calculating the geometry of human safety, we'll leave you
Speaker 1: upon to that one. Thanks for joining us on this
Speaker 1: deep dive.