Introduction to Robotics

The big picture

Watch a robot vacuum work a living room for five minutes and you will see the whole subject of this course in miniature. It glides forward, bumps a chair leg, backs off, pivots, and tries a new heading. It finds the wall and follows it. When its battery runs low it stops wandering and drives, with apparent purpose, back to its charging dock. Nobody is steering. Inside that plastic disc, a loop is spinning many times per second: measure the world, decide, move, and measure again. That loop, sense, think, act, is the beating heart of every robot ever built, from a $30 line-follower kit to a rover on Mars.

This course is an engineering tour of that loop. Module by module we will take it apart: the sensors that do the sensing, the motors and mechanisms that do the acting, and the mathematics and software that do the thinking in between. You will work real numbers throughout, gear ratios, trigonometry, feedback gains, because robotics is not a spectator subject. By the end you will be able to look at any robot, or any machine claiming to be one, and see the loop inside it.

Today's job is to pin down the idea itself. What exactly is a robot? The word gets stuck on everything from factory arms to chatbots, and engineers need a sharper definition than marketing provides. We will build one from the sense-think-act loop, test it against tricky cases, introduce the autonomy spectrum, and close with the single most important fact about where robots succeed and fail: the difference between structured and unstructured environments.

The sense-think-act loop

Strip away the chrome and every robot is three subsystems wired in a circle. Sensors convert physical facts about the world, distance, light, force, rotation, into electrical signals: the robot's eyes, ears, and inner ear. A controller, usually a microcontroller or computer, reads those signals and computes what to do next: the brain, though often a very small one. Actuators, mostly motors, convert the decision back into physical action: the muscles. The action changes the world or the robot's place in it, the sensors measure the change, and the loop closes. Engineers call this the sense-think-act loop, or the perception-decision-action cycle, and a typical hobby robot runs it 50 to 100 times every second.

The loop is a definition you can use. A robot is a machine that senses its environment, processes what it senses, and physically acts on its environment, with some degree of autonomy. Every word earns its place. Senses: the machine must take in information about the world, not just execute a fixed script. Physically acts: it must push on the world with motors, grippers, wheels, not just display pixels. Autonomy: some part of the decision, however small, must happen inside the machine rather than inside a human operator.

Test the definition on your household. A dishwasher runs a fixed program with a couple of interlocks; it does not measure the dishes and it cannot change its plan, so it is automation, not a robot. A remote-controlled car senses nothing and decides nothing; the human does the whole think step, so it is a puppet, a teleoperated machine. Your laptop senses (keyboard, camera) and thinks magnificently, but it cannot act on the physical world, so it is a computer. A chess program is pure think. The robot vacuum senses (bumpers, cliff sensors, wheel encoders), thinks (its behavior logic picks the next move), and acts (drive motors, brush motors), so it clears the bar with room to spare. The definition has fuzzy edges, a modern washing machine with load sensing sits closer to the line than a 1970s one, and reasonable engineers argue about drones and driverless cars, but the three-part test sorts most machines cleanly.

Key idea: A robot is a machine that senses its environment, decides, and physically acts, with some autonomy; the sense-think-act loop is both the definition and the block diagram of every robot in this course.

Where the word came from

The word robot is younger than the machines are. It entered the language in 1920, when the Czech playwright Karel Capek wrote R.U.R. (Rossum's Universal Robots), a play about artificial workers who eventually rise against their makers. His brother Josef suggested the name, from the Czech robota, meaning forced labor or drudgery. The word for the field came two decades later: the science fiction writer Isaac Asimov coined robotics in a 1941 short story, and went on to write the famous Three Laws of Robotics, rules built into his fictional robots to keep them from harming humans. Enjoy the Three Laws as literature, but understand that they are not engineering: no real robot has ever run them, and Asimov's own stories are mostly about the loopholes. Real robot safety, which we treat seriously in Module 6, is built from risk assessments, force limits, and safety-rated stops, not from laws of fiction.

Notice what the etymology tells you about the job description. From the very first use, robots were imagined as workers, machines to take over labor that is dull, dirty, or dangerous. That framing, the three Ds, still describes most of the world's working robots today: they weld, they haul, they inspect pipes, they defuse bombs. The dream of the mechanical butler is old; the economics of the mechanical welder is what actually built the industry, as the next lesson's history will show.

Key idea: Robot comes from the Czech word for forced labor, and the field's center of gravity has always been work: dull, dirty, and dangerous jobs where a machine can outlast, outlift, or outsafe a person.

The autonomy spectrum

Autonomy is not a yes-or-no property; it is a dial. At the far left sits pure teleoperation: a human makes every decision and the machine transmits motion. Bomb-disposal robots work this way, and so, surprisingly to many people, does the da Vinci surgical system: the surgeon's hands drive every motion of the instruments, and the robot contributes steadiness and scale, filtering out tremor and turning a 3 centimeter hand motion into a 1 centimeter instrument motion. Nothing in the operating room decides anything by itself.

In the middle lives supervised autonomy, where the machine handles the routine and the human handles the exceptions. The Mars rovers are the classic case. With a one-way light delay to Mars of anywhere from about 3 to 22 minutes, joystick driving is physically impossible, so engineers on Earth send a plan each morning, drive 40 meters toward that ridge, avoiding hazards, and the rover executes it with onboard hazard-avoidance software, stopping and replanning around rocks on its own. A warehouse fleet works the same way: thousands of drive units route themselves, while a handful of human operators watch dashboards and untangle the rare jam.

At the far right is full autonomy in some bounded domain: the robot vacuum owns its whole job, sensing, deciding, docking, with no human in the loop at all. Note the phrase bounded domain. The vacuum is fully autonomous at vacuuming one floor of one house; it is not autonomous at anything else. When you evaluate any robot claim, ask two questions: autonomous at what task, and in what environment? A machine can sit at different points on the dial for different parts of its job, and honest engineering documentation always says which.

Key idea: Autonomy is a spectrum from teleoperation through supervised autonomy to full autonomy in a bounded domain; always ask autonomous at what, and where.

Structured worlds are easy, our world is hard

Here is the fact that explains almost every robot success and failure of the last sixty years. A structured environment is one engineered to be predictable: a factory cell where the part arrives at the same position within a millimeter, every cycle, forever. An unstructured environment is everywhere else: your kitchen, a forest, a flooded street, anywhere objects appear in random places, lighting changes, and surprises are normal. Robots conquered structured environments decades ago, which is why over four million industrial robots work in factories today. Unstructured environments are still the research frontier, which is why you do not own a robot that folds laundry.

Why the gap? A factory robot can be blind and brilliant: if the world is guaranteed, you can replay a recorded motion with no sensing at all. The moment guarantees vanish, the sense and think parts of the loop must carry the load, and perception in the wild is brutally hard. The roboticist Hans Moravec noticed in the 1980s that we had machines that could beat chess masters but none that could clear the chessboard afterward with the reliability of a five-year-old. This inversion, hard reasoning is easy for machines while easy sensorimotor skill is hard, is called Moravec's paradox. Evolution spent hundreds of millions of years tuning animal perception and manipulation and only a few hundred thousand on formal reasoning; the skills that feel effortless to you are the ancient, deeply optimized ones, and they are precisely what robots struggle to match.

Keep the two-worlds picture with you for the whole course. When you meet a wildly successful robot, look for the structure it exploits or imposes: the warehouse robots that navigate by barcode stickers on a flat concrete floor, the delta arm fed parts by a vibratory feeder at a fixed height. When you meet a struggling robot, you will usually find it drowning in unstructure. And when a demo video amazes you, ask the engineer's question: how many takes, and what happens when the lighting changes?

Key idea: Robots thrive where the environment is engineered to be predictable and struggle where it is not; Moravec's paradox says the sensorimotor skills humans find effortless are the hardest ones to build.

The robot census

How many robots are there? The International Federation of Robotics counted about 4.3 million industrial robots operating in factories worldwide in its 2024 report, with roughly half a million new ones installed per year, most of them in automotive and electronics plants in Asia. Service robots, the category that includes floor cleaners, hospital carts, agricultural machines, and delivery robots, now sell in the millions of units per year, led by tens of millions of robot vacuums in homes. Add roughly a million surgical procedures per year assisted by teleoperated systems, growing fleets of warehouse robots (Amazon alone reports having deployed more than 750,000), and a handful of very famous machines on Mars, and you have the real robot population: not humanoid butlers, but a vast, mostly invisible workforce of arms and carts doing structured jobs superbly. That census, far more than any movie, is what this course will teach you to understand.

Common misconceptions

• A robot has to look like a person. Almost none do. The overwhelming majority of working robots are bolted-down arms and wheeled carts; the humanoid form is rare because legs and hands are enormously hard and seldom the best tool for a bounded job.
• Anything automated is a robot. A dishwasher, an elevator, and a thermostat automate, but they sense little and adapt less. The engineering test is the full loop: sensing, onboard decision, and physical action with some autonomy.
• Robots see and understand the way we do. A robot's world is a stream of numbers: distances, encoder counts, pixel brightness. Turning those numbers into anything like understanding is the hard, unfinished part of the field, per Moravec's paradox.
• Asimov's Three Laws keep real robots safe. The Three Laws are fiction and could not be implemented in any real controller. Actual robot safety comes from standards, risk assessment, guarding, and force limiting, which Module 6 covers in detail.

Recap

• A robot senses its environment, decides onboard, and physically acts, with some degree of autonomy; the sense-think-act loop runs continuously, often 50-100 times per second.
• The word robot entered the language through Capek's 1920 play R.U.R., from the Czech for forced labor, and robotics was coined by Asimov in 1941.
• Autonomy is a spectrum: teleoperation (da Vinci), supervised autonomy (Mars rovers, warehouse fleets), and full autonomy in a bounded domain (robot vacuums).
• Structured environments make robots look brilliant; unstructured ones expose the difficulty of perception and manipulation, which is Moravec's paradox.
• The real robot population is about 4.3 million industrial arms plus millions of service robots per year, working mostly out of sight.

Sources

1. Moravec, H. (2024). Robot. In Encyclopaedia Britannica. britannica.com
2. IEEE. (n.d.). ROBOTS: Your guide to the world of robotics. IEEE Spectrum. robots.ieee.org
3. International Federation of Robotics. (2024). World Robotics reports. IFR. ifr.org
4. NASA Jet Propulsion Laboratory. (n.d.). Mars exploration rovers. NASA. mars.nasa.gov
5. Wikipedia. (2025). Robot. Wikimedia Foundation. en.wikipedia.org

The big picture

In 1961, on a die-casting line at a General Motors plant in Trenton, New Jersey, a one-armed machine weighing about 4,000 pounds began pulling red-hot metal parts out of a casting machine and stacking them, hour after hour, in air laced with toxic fumes. It was called Unimate, and it was the first industrial robot ever put to work. The job it took was one no human should have had: die-casting workers of that era risked burns from splashing molten zinc and breathed its fumes all shift. Sixty-odd years later, the descendants of that arm number in the millions, and machines that trace their lineage to a few research labs now drive across Mars and trot through construction sites.

History matters in robotics for a practical reason: every architecture you will study in this course was invented to solve a specific problem at a specific moment, and the problems explain the designs. Why are factory arms blind position-repeaters? Because Unimate's customers had perfectly structured lines and 1960s computers could do no better. Why did mobile robots take thirty more years to matter? Because sensing and computing had to catch up. Why did warehouse robotics explode after 2012? Because one company found a way to impose structure instead of solving perception.

Today we walk the timeline in five acts: the founders and the first factory arms, the research machines that invented the field's software ideas, the Japanese scale-up, the mobile and autonomous wave, and the modern era of cobots, warehouse fleets, and machine learning. Keep score of a recurring pattern: in robotics, the demo usually arrives decades before the deployment.

Act one: a patent, a party, and a beer

The industrial robot began, as many machines do, with a patent. In 1954 a self-taught American inventor named George Devol filed for a Programmed Article Transfer device: a mechanical arm whose motions were recorded on a magnetic drum and replayed on command. At a cocktail party in 1956, Devol met Joseph Engelberger, an engineer with a physics degree, a taste for Asimov, and, crucially, the salesmanship the idea needed. The two founded Unimation, the first robot company, and Engelberger spent the rest of his life selling the industry into existence; he is remembered as the father of robotics, and the field's top honor is named for him.

Their Unimate was hydraulic, driven by pressurized oil, because electric motors of the day could not deliver the force, and it stored joint positions in digital form on a magnetic drum: teach it once by stepping through the motion, then let it replay the sequence forever. Note what it lacked: sensors. The Unimate could not see or feel; it repeated positions with about 1/10,000th of an inch precision and trusted the world to be where it was yesterday, the purest possible bet on a structured environment. General Motors installed the first one in 1961. In 1966 Engelberger took a Unimate on national television, where it poured a beer, sank a putt, and conducted the studio band, a stunt that told America robots were real. Detroit was slow, but the orders came, first for die casting, then for the spot welding that Unimates would soon do by the hundreds on GM's assembly lines.

Key idea: The first industrial robot, Unimate (1961), was a blind, hydraulic, record-and-replay arm; its total dependence on a structured environment set the pattern for factory robotics that largely persists today.

Act two: the research machines invent the software

While Unimation sold repetition, research labs attacked intelligence. From 1966 to 1972, SRI International built Shakey, a wobbling tower of camera, rangefinder, and radio link that was the first mobile robot to reason about its own actions: told to push a block off a platform, it could find the platform, find a ramp, push the ramp into place, roll up, and do it. Shakey needed hours where you would need seconds, but the algorithms invented for it became pillars of computer science: the A* search algorithm (published 1968 by Hart, Nilsson, and Raphael), which you will use in Module 5, and the STRIPS planner, an ancestor of modern task planning. Meanwhile at Stanford in 1969, mechanical engineering student Victor Scheinman built the Stanford Arm, one of the first all-electric, computer-controlled six-jointed arms, proving robots did not need hydraulics. Its descendant, the PUMA (Programmable Universal Machine for Assembly), built by Unimation for GM in 1978, became the archetypal research and light-assembly arm; PUMAs ran in labs for decades, and in 1985 one even assisted a brain biopsy, an early step toward surgical robotics.

Key idea: The 1960s and 70s research machines, Shakey and the Stanford Arm, contributed little commerce but invented the field's lasting software and electric-arm foundations, including A* search and task planning.

Act three: Japan scales it up, and the danger gets real

The technology was American; the scale-up was Japanese. Kawasaki licensed Unimation's technology in 1968, and through the 1970s Japanese manufacturers, backed by government policy and hungry automakers, adopted robots faster than anyone. By the early 1980s Japan operated more industrial robots than the rest of the world combined, and companies like FANUC, Yaskawa, and Kawasaki grew into giants that still dominate the market alongside Europe's ABB and KUKA. The lesson repeated later by other countries, notably South Korea and China, is that robot leadership follows manufacturing demand, not just invention.

The same era delivered the field's first hard safety lessons. In January 1979, Robert Williams, a 25-year-old worker at a Ford casting plant in Flat Rock, Michigan, was struck and killed by a parts-retrieval robot arm while climbing into a storage rack to fetch a casting himself, the first person known to be killed by a robot. In 1981 a Japanese engineer, Kenji Urada, was killed while servicing a robot that had not been powered down. The industry's response was physical: cages, light curtains, and interlocks that kept humans and powered robots strictly apart, a regime that ruled factories for the next thirty years and that we will revisit when we meet collaborative robots.

Key idea: Japan turned robotics from an invention into an industry in the 1970s and 80s, and early fatalities made strict physical separation of humans and robots the reigning safety doctrine.

Act four: robots leave the cage

The 1990s and 2000s put robots on other worlds and on public roads. The Soviet Lunokhod 1 had already driven on the Moon by remote control in 1970, but in July 1997 NASA's Sojourner, an 11.5 kilogram rover the size of a microwave oven, became the first robot to drive on Mars, proving supervised autonomy across interplanetary distances. Consumer robotics arrived with Sony's AIBO robot dog (1999) and iRobot's Roomba vacuum (2002); the Roomba, co-created by MIT professor Rodney Brooks, sold millions by embodying his behavior-based philosophy: simple reactive rules, no map, no plan, and a price tag of $199. Honda stunned the field in 1996 by revealing P2, a walking humanoid developed in secret for a decade, followed by the smaller ASIMO in 2000, machines that made dynamic walking real but never found a commercial job.

Then DARPA, the US defense research agency, bet on self-driving. Its 2004 Grand Challenge offered $1 million to any autonomous vehicle that could cross 142 miles of Mojave desert; the best entry managed 7.4 miles before getting stuck, and no one won. Eighteen months later, in the 2005 rematch, five vehicles finished, led by Stanford's Stanley in under 7 hours, and the 2007 Urban Challenge moved the contest to city streets with traffic. Those three contests seeded essentially every autonomous vehicle team of the following decade. The same years produced two quieter revolutions. Willow Garage released the Robot Operating System (ROS) starting in 2007, free software plumbing that let researchers stop rewriting drivers and start sharing code, and a startup called Kiva Systems rethought the warehouse: instead of teaching robots to pick from shelves (unstructured, hard), its squat orange robots carried the shelves to human pickers, navigating by barcode stickers on the floor (structured, easy). Amazon bought Kiva in 2012 for $775 million and has since deployed more than 750,000 mobile robots.

Key idea: Between 1997 and 2012, Mars rovers, the Roomba, the DARPA challenges, ROS, and the Kiva warehouse model moved robotics out of the cage, usually by imposing structure or accepting supervision rather than solving full autonomy.

Act five: the present tense

The 2010s and 2020s are close enough to touch. Collaborative robots, launched commercially by Universal Robots' UR5 in 2008, are force-limited arms safe enough to share a bench with people, and now make up roughly one in ten new industrial installations. Boston Dynamics' legged machines, from the DARPA-funded BigDog (2005) to the commercially sold Spot quadruped (2020) and the acrobatic Atlas humanoid (retired in hydraulic form in 2024 and reborn electric), turned dynamic balance from a lab trick into a product. Surgical robotics matured into a standard of care, with the da Vinci system (cleared by the FDA in 2000) assisting millions of procedures. On Mars, the helicopter Ingenuity made the first powered flight on another planet in April 2021 and flew 72 times. And machine learning began doing real work, mostly in perception and grasping, alongside a noisy wave of humanoid startups whose promises this course will teach you to evaluate with an engineer's skepticism: ask what task, what environment, how many takes.

Year	Milestone	Why it mattered
1954-56	Devol patent; Unimation founded	Robotics becomes a business
1961	Unimate works at GM	First industrial robot deployed
1966-72	Shakey at SRI	A* search and task planning invented
1969	Stanford Arm	Electric, computer-controlled arms
1979	First robot-related death	Safety cages become doctrine
1997	Sojourner on Mars	Supervised autonomy across space
2002	Roomba ships	Behavior-based robots go home
2005	Stanley wins Grand Challenge	Autonomous driving proven feasible
2007-12	ROS; Amazon buys Kiva	Shared software; structured warehouses
2021	Ingenuity flies on Mars	First powered flight off Earth

Common misconceptions

• Robotics is a recent field born from modern AI. The first industrial robot started work in 1961, before the moon landings, and core algorithms like A* date to 1968; modern learning arrived into a mature engineering discipline, not a vacuum.
• The first robots replaced workers doing pleasant jobs. Unimate's first job was unloading a die-casting machine, hot, toxic work with real injury rates; dull, dirty, and dangerous tasks drove adoption then and still do.
• Humanoids like ASIMO led to today's factory robots. The lineages are nearly separate: factory arms descend from Unimate and the Stanford Arm, while humanoid research, though technically dazzling, has yet to produce a widely deployed worker.
• Amazon's warehouse robots pick items off shelves. The Kiva insight was the opposite: robots carry whole shelf pods to stationary human pickers, replacing hard perception with an engineered, barcode-gridded floor.

Recap

• Devol's 1954 patent and Engelberger's salesmanship created Unimation, and the hydraulic, sensorless Unimate began work at GM in 1961.
• Shakey (A* search, planning) and the Stanford Arm (electric control) invented the field's research foundations in the late 1960s.
• Japan's 1970s-80s scale-up made robots an industry; the deaths of Robert Williams (1979) and Kenji Urada (1981) made cages the safety norm.
• Sojourner (1997), Roomba (2002), the DARPA challenges (2004-07), ROS (2007), and Kiva (bought by Amazon, 2012) took robots beyond the factory.
• The present era runs on cobots, legged machines, surgical systems, warehouse fleets, and machine learning applied mostly to perception.

Sources

1. Moravec, H. (2024). Robot. In Encyclopaedia Britannica. britannica.com
2. Wikipedia. (2025). Unimate. Wikimedia Foundation. en.wikipedia.org
3. NASA. (n.d.). Mars Pathfinder and Sojourner rover. NASA Mars Exploration Program. mars.nasa.gov
4. IEEE Spectrum. (n.d.). Robotics coverage. IEEE. spectrum.ieee.org
5. Computer History Museum. (n.d.). Timeline of computer history: AI and robotics. CHM. computerhistory.org

The big picture

Biology never settled on one body. It built cheetahs and octopuses and hummingbirds, each shaped by the job it had to do. Robotics did the same thing much faster, and for the same reason: form follows task. An arm bolted to a factory floor and a quadrotor hovering over a bridge deck share a control theory and share almost nothing else. If you can look at a robot's shape and read the job off it, you are already thinking like a roboticist.

This lesson is a field guide to robot bodies. We will walk the five great families, manipulator arms, wheeled robots, legged robots, aerial and underwater vehicles, and soft robots, and for each one ask three engineer's questions: what does this shape do well, what does it cost, and where is it actually deployed today? Along the way you will meet the specific arm geometries by name, because when you shop for or specify a robot, those names are the vocabulary of the catalog.

One theme runs through all of it. Every body plan is a bargain: you buy capability with complexity, weight, cost, and control difficulty. Wheels are cheap and dumb and win almost everywhere; legs are expensive and brilliant and win in a few places. Knowing which bargain a shape represents is how you avoid the classic beginner mistake of building a walking robot for a job a $40 wheeled chassis would do better.

Manipulators: the arm family

A manipulator is a chain of rigid links connected by joints, anchored at one end (the base) and carrying a tool at the other (the end effector). Joints come in two flavors: revolute joints rotate, like your elbow, and prismatic joints slide, like a drawer. Chain enough of them together and you can put the tool wherever you like, which is why arms do most of the world's robot work.

Four geometries account for nearly all commercial arms. The articulated arm is the classic anthropomorphic shape, typically six revolute joints, that you picture when you hear industrial robot: enormous flexibility, reach from under a meter to over three, payloads from a few kilograms to more than two tonnes. It welds, paints, and tends machines. The SCARA (Selective Compliance Assembly Robot Arm) has two vertical-axis revolute joints plus a vertical slide: stiff up and down, compliant sideways, and blindingly fast at the one motion electronics assembly needs most, pick a part, move it horizontally, press it down. A SCARA can cycle in a quarter of a second. The delta robot hangs three light arms from an overhead frame in a parallel triangle, keeping all its heavy motors on the fixed base, which is why deltas can pick 150 to 300 items per minute off a moving conveyor, sorting cookies or vaccine vials, at accelerations above 10 g. The Cartesian or gantry robot uses three prismatic axes at right angles: dead simple to program, absurdly rigid, and scalable to any size, which is why 3D printers, CNC routers, and warehouse gantries all use it.

Type	Joints	Strength	Typical job
Articulated	6 revolute	Reach and dexterity	Welding, painting, machine tending
SCARA	2 revolute + 1 prismatic	Fast horizontal moves, vertical stiffness	Electronics assembly, packaging
Delta (parallel)	3 arms, base-mounted motors	Extreme speed, light payload	High-rate food and pharma picking
Cartesian/gantry	3 prismatic	Rigidity, simple math, scalability	3D printing, CNC, large-part handling

Two numbers dominate any arm's spec sheet. Payload is the mass it can carry at full extension including the gripper, and beginners routinely forget that a 3 kg gripper on a 5 kg-rated arm leaves only 2 kg for the part. Repeatability is how tightly the arm returns to the same commanded point, often 0.02 to 0.1 mm for industrial arms, and it is not the same as accuracy, which is how close the arm gets to the point you specified in world coordinates. Industrial arms are wonderfully repeatable and only moderately accurate, which is exactly what you need to replay a taught motion and exactly what frustrates anyone trying to command positions from a CAD model.

Key idea: Arms are chains of revolute and prismatic joints; articulated, SCARA, delta, and Cartesian geometries trade dexterity, speed, and rigidity against each other, and payload plus repeatability are the two specs that decide most purchases.

Wheels: the workhorse of mobility

If arms do most of the world's robot work, wheels do most of its robot traveling. The reason is efficiency: a wheel rolling on a hard flat surface loses almost nothing to friction, needs no energy to stand still, and can be controlled by nothing more than a motor speed. Nature never invented the wheel because it cannot grow an axle, but engineers can, and on the flat floors humans build for themselves the wheel is close to unbeatable.

The dominant configuration in small robots is differential drive: two independently driven wheels on a common axis, plus one or two passive casters for balance. Drive both wheels forward and the robot goes straight; drive them at different speeds and it curves; drive them in opposite directions and it spins in place, a zero-radius turn that is enormously useful indoors. Nearly every robot vacuum and most hobby robots use this layout, and in Module 3 you will compute its motion from wheel speeds exactly. Cars use Ackermann steering instead, with steered front wheels, which handles high speed and heavy loads far better but cannot turn in place, forcing self-driving software to plan the same three-point turns you do. Omnidirectional designs use mecanum or omni wheels with rollers set at an angle, letting a platform slide sideways or diagonally without rotating; the price is complexity, poor efficiency, and hatred of debris. Tracks spread weight over a large contact patch for mud, rubble, and stairs, at the cost of high friction turning and constant maintenance.

Key idea: Wheels dominate mobile robotics because they are efficient, simple, and well matched to human-built floors; differential drive is the default small-robot layout, with Ackermann, omnidirectional, and tracked designs each buying a specific capability.

Legs: expensive, and sometimes worth it

Roughly half the Earth's land surface is inaccessible to wheeled vehicles, and every staircase ever built is a wall to a Roomba. That is the case for legged robots: legs choose discrete footholds, so they can cross gaps, climb steps, and pick their way over rubble that would strand any wheel. The cost is severe. A quadruped needs at least twelve actuated joints against a differential drive robot's two motors, it must actively balance every instant it is standing, it burns energy holding itself up, and a control failure means falling over rather than merely stopping.

Two ideas make legged machines work. Static stability means the robot's center of mass stays inside the polygon formed by its ground contacts, so it can freeze mid-stride and not fall; hexapods and slow-walking quadrupeds do this. Dynamic stability means the robot is continuously falling and catching itself, like a person running, which is faster and more agile but requires fast control loops and good state estimation. Honda's ASIMO and Boston Dynamics' machines demonstrated dynamic walking convincingly, but note the deployment record: after decades of research, the legged robots that actually earn money are inspection quadrupeds like Spot, which walk substations, construction sites, and offshore platforms carrying cameras and gas sensors. That is a real job, and it exists because those sites have stairs, ladderways, and clutter that a cart cannot cross. When someone shows you a backflipping humanoid, admire the engineering and then ask the deployment question.

Key idea: Legs buy access to unstructured terrain at the price of many actuators, active balance, and energy; static stability freezes safely, dynamic stability moves faster, and today's commercial payoff is mostly remote inspection.

Flying and swimming robots

Take the constraint of the ground away and two more families appear. The multirotor, usually a quadrotor, is mechanically the simplest flying machine ever built: four fixed-pitch propellers, no swashplate, no linkages, controlled entirely by varying motor speeds. Spin all four faster to climb; slow one pair to tilt and translate; exploit the fact that two rotors turn clockwise and two counterclockwise to control yaw by unbalancing their torques. A quadrotor is inherently unstable and would tumble instantly without its controller running hundreds of corrections per second off an inertial sensor, which is exactly why cheap fast microcontrollers, not new aerodynamics, created the drone industry around 2010. Fixed-wing drones trade hovering for endurance and range, which is why mapping and agricultural survey aircraft have wings, and the honest limit on all of it is energy: most battery multirotors fly 20 to 40 minutes, and physics is not about to be generous here.

Underwater, the tradeoffs shift again. Remotely operated vehicles (ROVs) stay tethered to a ship, which solves power and communication at once, and do the world's subsea inspection and repair. Autonomous underwater vehicles (AUVs) cut the tether and must therefore navigate blind, because radio and GPS do not penetrate seawater more than a few meters, forcing reliance on inertial navigation, acoustic beacons, and sonar. Space is a fifth environment with its own body plans, from the seven-jointed Canadarm2 that walks end over end across the International Space Station to Mars rovers built with rocker-bogie suspensions that let six wheels crawl over obstacles as tall as a wheel.

Key idea: Multirotors are mechanically trivial and control-dependent, fixed wings buy endurance, and underwater vehicles must navigate without radio or GPS; every medium imposes its own body plan.

Soft robots: bodies that give

The newest family throws out the rigid link entirely. A soft robot is built from elastomers, textiles, or inflatable chambers, and moves by pressurizing internal channels or pulling embedded tendons. A soft gripper does not need to know a tomato's exact shape or apply a calculated force; it simply wraps and conforms, and the material does the accommodating. That is morphological computation, the idea that a well-designed body can handle problems the controller would otherwise have to solve, and it is the family's central insight.

Soft robots are genuinely deployed in food handling, where compliant grippers pick produce and baked goods that rigid jaws would crush, and in surgical and search tools where a machine must squeeze through gaps. They are also honestly limited: they are weak compared with steel, hard to model mathematically because they deform continuously rather than at joints, slow when driven by pumped air, and often dependent on a bulky external compressor. Expect them to spread wherever contact with delicate or unpredictable objects is the whole problem, and to stay rare wherever precision and force dominate.

Key idea: Soft robots replace joints with deformable materials, letting the body absorb uncertainty (morphological computation), which wins in delicate grasping but sacrifices strength, speed, and mathematical tractability.

Common misconceptions

• Legged robots are simply better than wheeled ones. On flat ground a wheel wins on cost, energy, reliability, and simplicity by wide margins; legs pay off only where the terrain actually defeats wheels, which indoors it usually does not.
• An arm rated for 10 kg can lift a 10 kg part. Payload ratings include the end effector and often assume a modest reach and speed; a heavy gripper, full extension, or fast acceleration all eat into the number.
• Repeatability and accuracy mean the same thing. Repeatability is returning to the same taught point, and industrial arms excel at it; accuracy is hitting a point you specify in world coordinates, and it is usually much worse without calibration.
• Drones are hard because flying is aerodynamically complex. A quadrotor's mechanics are trivial. What made drones possible was cheap inertial sensing and fast control loops that stabilize an inherently unstable machine hundreds of times per second.

Recap

• Manipulators are chains of revolute and prismatic joints; articulated arms give reach, SCARAs give horizontal speed, deltas give extreme picking rates, and gantries give rigidity and scale.
• Payload includes the gripper, and repeatability (returning to a taught point) is not accuracy (hitting a specified coordinate).
• Wheels dominate mobility on human-built floors; differential drive turns in place, Ackermann handles speed and load, omni wheels slide sideways, tracks handle rubble.
• Legs access rough terrain but need many actuators and active balance, with static stability meaning a safe freeze and dynamic stability meaning controlled falling.
• Multirotors depend entirely on fast feedback, fixed wings on endurance, underwater vehicles on acoustics because radio and GPS fail in water, and soft robots on materials that absorb uncertainty.

Sources

1. IEEE. (n.d.). ROBOTS: Your guide to the world of robotics. IEEE Spectrum. robots.ieee.org
2. Moravec, H. (2024). Robot. In Encyclopaedia Britannica. britannica.com
3. NASA. (n.d.). Mars rover wheels and suspension. NASA Mars Exploration Program. mars.nasa.gov
4. Wikipedia. (2025). Robotic arm. Wikimedia Foundation. en.wikipedia.org
5. IEEE Spectrum. (n.d.). Robotics coverage. IEEE. spectrum.ieee.org

The big picture

Close your eyes and touch your nose. You just used a sense most people never name: proprioception, the awareness of where your own body parts are without looking at them. Nerve endings in your muscles and joints report angles and tensions continuously, which is why you can walk in the dark and type without watching your hands. Robots need exactly the same sense, and they need it first. Before a robot can ask where the world is, it must know where its own arm is pointing and how far its own wheels have turned.

This lesson covers the internal senses. We start with the encoder, the small, unglamorous device that counts rotation and quietly makes closed-loop motor control possible, and we will work its arithmetic until converting counts to millimeters is automatic for you. Then we meet the potentiometer, the cheap analog alternative, and finally the inertial measurement unit, the accelerometer and gyroscope package that lets drones stay level and phones know which way is up.

The lesson's real theme, though, is honesty about error. Every sensor lies a little, and each type lies in its own characteristic way: encoders count perfectly but cannot see wheel slip, gyroscopes are smooth but drift, accelerometers are stable on average but noisy instant to instant. Learning each sensor's specific dishonesty is more valuable than memorizing its datasheet, because the whole art of robot perception is combining flawed sensors into a usable estimate.

Encoders: counting rotation

An encoder reports how far a shaft has turned. The most common type, the optical incremental encoder, puts a disc with evenly spaced slots on the motor shaft and shines an LED through it at a photodetector. Every slot that passes produces a pulse, so the controller counts pulses and multiplies by the angle per slot. Magnetic encoders do the same job by sensing a rotating magnet with Hall-effect elements, and they shrug off the dust and oil that blind optical discs, which is why they dominate rugged applications.

Work the arithmetic, because you will do this constantly. Suppose your robot has a motor with a 100 counts-per-revolution encoder on its shaft, a 50:1 gearbox, and a wheel 65 mm in diameter. How far does the robot travel per encoder count? First, counts per wheel revolution: 100 counts on the motor shaft times 50 motor turns per wheel turn equals 5,000 counts per wheel revolution. Next, wheel circumference: pi times 65 mm, about 204.2 mm. So each count represents 204.2/5,000 = 0.0408 mm, roughly 41 micrometers of travel. Now the reverse: your robot reports 12,000 counts since it started. Distance traveled is 12,000 times 0.0408 mm = 490 mm, just under half a meter. That single conversion, counts to distance, is the foundation of odometry in Module 5.

One channel of pulses tells you how much the shaft turned but not which way. The fix is quadrature: two detectors offset so their pulse trains are a quarter cycle apart, producing channels A and B. If A leads B, the shaft turns one way; if B leads A, the other. Quadrature also multiplies resolution, since a controller can count all four edge transitions per cycle and get 4 counts where the disc has 1 slot. That is why a datasheet may advertise 400 counts per revolution for a 100-slot disc, and why you must read carefully whether a quoted number is pulses or post-quadrature counts.

The deeper distinction is memory. An incremental encoder reports change only, so at power-up it has no idea where it is; the robot must run a homing routine, driving each joint until it trips a limit switch to establish a zero. An absolute encoder encodes a unique pattern for each shaft position, so it knows its angle the instant power arrives, at higher cost. Industrial arms increasingly use absolute encoders precisely so a power blink does not require rehoming a machine in the middle of a weld.

Key idea: Encoders count shaft rotation; multiply counts per motor revolution by gear ratio to get counts per wheel revolution, divide circumference by that to get distance per count, and remember that incremental encoders need homing while absolute ones do not.

What encoders cannot see

Here is the encoder's characteristic lie, and it is important enough to state plainly: an encoder measures the motor, not the world. If the wheel spins on a wet floor, the encoder happily counts 5,000 pulses while the robot goes nowhere. If a belt slips or a set screw loosens, the encoder reports the motor's honest rotation and the machine's position is quietly wrong. If the arm is blocked by a person's hand, the encoder may show the commanded angle while the actual link stalled a joint away, unless the encoder sits on the output side of the gearbox.

This is why encoder-based position estimates degrade over time and why every serious mobile robot eventually adds an outside reference, a wall, a beacon, a camera, or GPS, to correct them. Keep this asymmetry in mind: internal sensors are precise but blind to the world; external sensors see the world but are noisy. Robotics lives on their combination.

Potentiometers and simple angle sensing

A potentiometer is the humblest angle sensor: a resistive track with a wiper that moves as the shaft turns, producing a voltage proportional to angle. Feed it 3.3 V, and a 10-bit analog-to-digital converter reads 0 to 1023 across the pot's travel, typically 270 degrees, giving about 0.26 degrees per step. Hobby servos use exactly this internally to close their own position loop. The advantages are cost, absolute reading at power-up, and dead simplicity. The disadvantages are equally clear: limited travel (no continuous rotation), mechanical wear on the track producing noisy or dead spots after heavy use, and sensitivity to supply voltage and electrical noise. Use them for a joint that sweeps a limited arc and rarely, for anything that must run millions of cycles.

Key idea: Potentiometers give cheap absolute angle over a limited arc but wear out and pick up electrical noise, which is why they live inside hobby servos and rarely inside industrial joints.

IMUs: accelerometers and gyroscopes

An inertial measurement unit (IMU) is the chip that tells your phone which way is up and keeps a quadrotor from tumbling. Modern IMUs are MEMS devices, micro-electromechanical systems, with microscopic silicon structures etched onto a chip and read electrically. They cost a few dollars and combine two instruments.

An accelerometer measures proper acceleration, which includes gravity. Sitting still on a table, a 3-axis accelerometer reads about 9.81 m/s squared along whichever axis points up, and near zero on the others. That is the trick that gives it absolute tilt: compare the measured gravity vector to the chip's axes and you know how the robot is oriented relative to down, no drift ever, because gravity does not wander. The catch is that this only works when the robot is not accelerating for other reasons. Under braking, vibration, or a quadrotor's constant corrections, the sensor cannot distinguish gravity from motion, and its tilt estimate goes briefly nonsense. Accelerometers are also electrically noisy, jittering by a few hundredths of a g sample to sample.

A gyroscope measures angular rate, degrees per second of rotation about each axis, using tiny vibrating structures that experience the Coriolis effect when spun. Gyros are beautifully smooth and immune to linear acceleration, but they measure rate, not angle, so getting orientation requires integrating: add up rate times time step. Integration accumulates error, and a small constant offset (bias) becomes a growing lie. Work the number: a low-cost MEMS gyro might have a bias of 0.5 degrees per second after calibration. Integrate that for one minute and your heading estimate is off by 30 degrees. After five minutes it is 150 degrees, which is worse than useless. This is gyro drift, and it is the single most important limitation in inertial navigation. Expensive fiber-optic and ring-laser gyros push bias down by orders of magnitude, which is why aircraft-grade inertial units cost thousands rather than dollars, but no gyro escapes drift entirely.

Key idea: Accelerometers give drift-free tilt from gravity but are noisy and confused by motion; gyroscopes give smooth angular rate but drift when integrated into angle. Their weaknesses are opposites.

Sensor fusion: two lies making a truth

Because those weaknesses are complementary, combining them beats either alone. That combination is sensor fusion, and the simplest usable version is the complementary filter. Trust the gyroscope over short intervals, where it is smooth and accurate, and trust the accelerometer over long intervals, where its average is anchored to gravity. In practice the filter computes something like: new angle estimate = 0.98 times (previous angle plus gyro rate times time step) plus 0.02 times (angle from accelerometer). The 0.98 term carries the gyro's smooth short-term motion; the 0.02 term slowly pulls the estimate back toward gravity's truth, canceling drift. Ten lines of code, and it flies drones.

More sophisticated fusion uses a Kalman filter, which tracks not just the estimate but its uncertainty, and weights each new measurement by how trustworthy it is compared with the prediction. The mathematics is beyond this course, but the intuition is exactly the complementary filter's, made rigorous and adaptive: measurements you trust move the estimate a lot, measurements you distrust move it a little. Add a magnetometer (an electronic compass) to correct yaw, which gravity cannot pin down, and you have the 9-axis IMU inside phones and flight controllers. Be warned that magnetometers are the flakiest of the three: motors, steel structure, and the robot's own current-carrying wires all bend the local magnetic field, and an uncalibrated compass on a metal chassis can be off by tens of degrees.

Key idea: Sensor fusion combines sensors whose errors differ in character; a complementary filter trusts gyros short-term and accelerometers long-term, and a Kalman filter generalizes that by tracking uncertainty explicitly.

Sensor	Measures	Strength	Characteristic failure
Incremental encoder	Shaft rotation change	High resolution, cheap	Blind to slip; needs homing
Absolute encoder	Shaft angle	Known at power-up	Higher cost
Potentiometer	Angle over limited arc	Cheap, absolute	Wear, dead spots, electrical noise
Accelerometer	Proper acceleration + gravity	Drift-free tilt reference	Noisy; fooled by motion
Gyroscope	Angular rate	Smooth, immune to linear acceleration	Bias drift when integrated
Magnetometer	Magnetic field direction	Absolute heading reference	Distorted by motors and steel

Common misconceptions

• An encoder tells the robot where it is. It tells the robot how far its motor turned. Wheel slip, belt slip, and blocked joints all break the link between motor rotation and real motion.
• A gyroscope measures which way the robot is facing. It measures how fast the robot is turning. Heading comes from integrating that rate, and integration is exactly where drift creeps in.
• An accelerometer measures how fast the robot is going. It measures acceleration including gravity. Integrating it twice for position is a classic beginner trap: the error grows with the square of time and becomes meters within seconds.
• Adding more sensors always improves the estimate. Only if their errors are independent and you fuse them properly; three sensors that all fail in the same condition, such as three cameras in darkness, give false confidence rather than robustness.

Recap

• Proprioception is a robot's sense of its own configuration, provided mainly by encoders, potentiometers, and IMUs.
• Distance per encoder count equals wheel circumference divided by (counts per motor revolution times gear ratio); a 100 CPR encoder, 50:1 gearbox, and 65 mm wheel gives about 0.041 mm per count.
• Quadrature adds direction sensing and four times the resolution; incremental encoders need homing while absolute encoders know their angle at power-up.
• Accelerometers provide drift-free tilt from gravity but are noisy and confused during acceleration; gyroscopes are smooth but a 0.5 deg/s bias becomes 30 degrees of heading error in one minute.
• Complementary and Kalman filters fuse these complementary weaknesses, and magnetometers add heading but are easily distorted by motors and steel.

Sources

1. NASA. (n.d.). Inertial measurement and navigation. NASA Technical Reports Server. ntrs.nasa.gov
2. National Institute of Standards and Technology. (n.d.). Robotics and autonomous systems research. NIST. nist.gov
3. Wikipedia. (2025). Inertial measurement unit. Wikimedia Foundation. en.wikipedia.org
4. Wikipedia. (2025). Rotary encoder. Wikimedia Foundation. en.wikipedia.org

The big picture

A robot that cannot answer the question how far away is that will run into things. Ranging is the most basic external sense in robotics, older than machine vision and still, in 2020s products, more reliable. Your robot vacuum bumps into a chair partly because the cheap sensors it can afford have real blind spots, and a self-driving car stops for a pedestrian in the dark because a spinning laser measured that person's distance 20 times a second with centimeter precision. Same question, three orders of magnitude difference in cost and capability.

Almost all of it comes from one principle: time of flight. Send a pulse, wait for the echo, and use the known speed of the pulse to convert elapsed time into distance. The physics is a middle-school formula. The engineering is everything, because sound is slow and forgiving while light is fast and merciless, and that single difference dictates whether your ranging device costs three dollars or three thousand.

Today we work through ultrasonic sensing with real arithmetic, then infrared triangulation, then lidar, ending with a fair comparison against radar and stereo cameras. As always, spend as much attention on how each sensor fails as on how it works: a robot that trusts a sonar aimed at a curtain, or a lidar in a snowstorm, will do something confident and wrong.

Ultrasonic ranging: cheap, slow, forgiving

An ultrasonic sensor chirps a burst of sound above human hearing, typically 40 kHz, and listens for the echo. Sound travels through 20 degree C air at about 343 meters per second, so distance follows from d = v times t divided by 2, halved because the pulse makes a round trip. Work an example. Your sensor reports an echo 5.83 milliseconds after the chirp. Distance is 343 m/s times 0.00583 s = 2.0 meters of total travel, halved to 1.0 meter to the object. A handy shortcut for the popular HC-SR04 module: divide the microsecond echo time by 58 to get centimeters. That 5,830 microsecond echo divided by 58 gives 100 cm. Same answer, no calculator.

Because sound is slow, the timing electronics are trivially cheap, which is why an ultrasonic module costs a couple of dollars and shows up in every beginner robot kit. Slowness costs you elsewhere, though. At 1 meter, a round trip takes about 5.8 ms, so you can only ping about 170 times per second even in theory, and you must wait for reverberations to die before the next chirp, which caps practical update rates near 20 Hz. Multiple sensors on one robot can hear each other's chirps, a problem called crosstalk, solved by firing them in sequence rather than simultaneously.

The bigger limitation is the beam. An ultrasonic sensor does not measure a point; it floods a cone typically 15 to 30 degrees wide and reports the distance to the nearest thing anywhere inside that cone. At 2 meters, a 30 degree cone is over a meter across. So a sonar reading of 2.0 m means something is 2 meters away, somewhere in a wide arc, and the robot has no idea where within it. That coarseness makes sonar good for do not hit anything and poor for map the room precisely.

Then come the failure modes, and they are gloriously specific. Sound reflects specularly off smooth surfaces: aim a sonar at a wall at a steep angle and the echo bounces away like light off a mirror, never returning, so the sensor reports maximum range and the robot sees an open corridor where a wall is. Soft materials absorb: curtains, foam, thick sweaters, and cats all swallow the chirp and become invisible. Every sensor has a blind zone of a few centimeters where the receiver is still ringing from its own transmission, so objects closer than roughly 2 cm are simply undetectable. And since the speed of sound rises about 0.6 m/s per degree Celsius, a sensor calibrated at 20 C reads roughly 3 percent long at 0 C, a real error outdoors.

Key idea: Ultrasonic ranging uses d = 343 t/2 (or microseconds divided by 58 for centimeters); it is cheap and forgiving but returns a wide cone rather than a point, misses angled and soft surfaces entirely, is blind within a few centimeters, and shifts with temperature.

Infrared: triangulation and proximity

Light is 875,000 times faster than sound, so timing a light pulse over 1 meter means resolving about 6.7 nanoseconds, which cheap microcontrollers cannot do. Inexpensive infrared sensors therefore dodge the timing problem entirely by using geometry instead. A triangulating IR rangefinder, the classic Sharp GP2Y series, shines a narrow infrared beam forward and images the returning spot on a small linear detector array offset a couple of centimeters from the emitter. A near object puts the spot at one end of the array; a far object puts it near the other. Angle gives distance, no nanosecond clock required.

The advantages over sonar are a much narrower beam, roughly a pencil rather than a cone, and faster updates. The disadvantages are equally distinct. The output is nonlinear and, worse, non-monotonic: below the sensor's minimum range the reading folds back so that a very close object produces the same voltage as a distant one, and a robot that trusts it will accelerate into a wall it thinks is far away. Surface color and finish matter enormously since the sensor measures reflected light: a black matte object may read 30 percent farther than a white one at the same distance, and a mirror or polished floor can vanish or produce phantom returns. Direct sunlight, rich in infrared, blinds them outdoors.

A simpler cousin is the reflective IR proximity sensor, an emitter and photodetector pair that reports only near or far. These cost cents, and they are the sensors under your robot vacuum that detect stair edges (a cliff sensor reads no reflection and screams stop) and the ones a line-following robot uses to see dark tape on light floor, which we will control with PID in Module 4. Modern small robots increasingly use laser time-of-flight chips instead, such as the VL53 family, which pack the nanosecond timing into a single chip and measure to a couple of meters with a narrow beam for a few dollars.

Key idea: Cheap infrared rangefinders triangulate rather than time light, giving a narrow beam and fast updates but nonlinear, surface-dependent readings that fold back dangerously below minimum range.

Lidar: light detection and ranging

Lidar does what the infrared sensor could not: it genuinely times light. A laser pulse leaves, hits something, returns, and precise electronics measure the interval. Since light travels about 30 centimeters per nanosecond, resolving 1 centimeter of distance requires timing to about 67 picoseconds, which is why lidar was long a laboratory instrument. Many modern units use a phase-shift or frequency-modulated method rather than raw pulse timing, but the principle is the same: light's travel encodes distance.

A 2D lidar spins a single laser in a horizontal plane, taking hundreds or thousands of measurements per revolution at 5 to 15 revolutions per second, producing a slice of the room: a ring of distances at known angles. That slice is exactly what mapping algorithms want, and hobby-grade 2D units now cost around $100, which is why nearly every serious indoor mobile robot and premium robot vacuum has one. A 3D lidar stacks many laser channels (16, 32, 64, 128) and sweeps them, generating a point cloud of hundreds of thousands of 3D points per second: the spinning bucket you have seen on autonomous test vehicles. Solid-state designs steer the beam electronically with no spinning parts, which is cheaper and far more reliable in the long run.

Lidar's virtues are real: centimeter accuracy, a narrow beam that measures actual points rather than cones, hundreds of thousands of measurements per second, and complete indifference to lighting since it brings its own. Its weaknesses are equally real. Rain, snow, fog, and dust scatter the beam, producing dropouts or phantom returns near the sensor. Glass is nearly invisible, and shiny or very dark surfaces return too little light, which is why lidar-guided robots famously struggle with glass office walls. Spinning units have bearings that wear. And lidar tells you where surfaces are, never what they are: a point cloud cannot distinguish a child from a mailbox, which is precisely the job we will hand to cameras in the next lesson.

Key idea: Lidar times light to produce accurate point measurements independent of lighting, in 2D slices or 3D point clouds, but it is defeated by glass, weather, and dark surfaces, and it reports geometry without identity.

Choosing a ranging sensor

Sensor	Typical range	Beam	Cost	Defeated by
Ultrasonic	0.02 to 4 m	15-30 degree cone	A few dollars	Angled walls, soft fabric, temperature shift
IR triangulation	0.1 to 1.5 m	Narrow	Under $20	Sunlight, dark or shiny surfaces, fold-back below minimum
Laser ToF chip	0.03 to 4 m	Very narrow	Under $10	Bright sun, low-reflectance targets
2D lidar	0.15 to 12 m	Narrow, planar sweep	$100 and up	Glass, weather, moving parts wear
3D lidar	Up to 200 m	Narrow, many channels	Hundreds to thousands	Weather, cost, data volume
Radar	Up to 250 m	Wide	Tens of dollars up	Poor angular resolution, clutter

Radar deserves its own note because it is the one ranging technology that laughs at weather. Millimeter-wave automotive radar sees through rain, fog, and dust that stop lidar cold, and it measures target velocity directly via the Doppler shift, which lidar and cameras must infer by comparing frames. Its weakness is angular resolution: radar knows something is 60 meters ahead and closing at 12 m/s, but it is far vaguer about that object's exact shape and position than lidar. This is why serious autonomous vehicles carry radar and lidar and cameras: the sensors fail in different weather and on different materials, so fusing them, exactly as we fused gyro and accelerometer last lesson, produces a system more robust than any part of it.

Key idea: No single ranging sensor is best; robust systems fuse technologies whose failure modes differ, such as radar for weather and velocity, lidar for geometry, and cameras for identity.

Common misconceptions

• An ultrasonic reading of 2.0 m means an object is straight ahead at 2 m. It means the nearest reflector anywhere in a cone over a meter wide at that distance is 2 m away. Sonar gives distance without direction.
• If the sensor reads maximum range, the path is clear. A wall at a steep angle, a curtain, or foam all bounce or absorb the chirp away, producing a confident maximum-range reading in front of a solid obstacle.
• Cheap infrared rangefinders time the light like lidar. They triangulate the position of a reflected spot, which is why their output is nonlinear, surface-dependent, and dangerously ambiguous below minimum range.
• Lidar sees everything. Glass is nearly transparent to it, black surfaces return too little light, and rain, snow, and dust generate dropouts and phantom points. Lidar also reports geometry only, never identity.

Recap

• Time-of-flight ranging computes distance as speed times time divided by two; for sound in 20 C air use 343 m/s, or divide microseconds by 58 for centimeters.
• Ultrasonic sensors are cheap and tolerant but deliver a wide cone, have a few centimeters of blind zone, miss angled and soft surfaces, and drift about 3 percent with a 20 degree temperature change.
• Inexpensive IR rangefinders triangulate a reflected spot: narrow beam, fast, but nonlinear, reflectance-dependent, sunlight-sensitive, and ambiguous below minimum range.
• Lidar genuinely times light (30 cm per nanosecond), producing 2D scan slices or 3D point clouds with centimeter accuracy, independent of ambient light but defeated by glass and weather.
• Radar penetrates weather and measures velocity directly but resolves angle poorly, which is why real autonomous systems fuse radar, lidar, and cameras.

Sources

1. National Oceanic and Atmospheric Administration. (n.d.). What is lidar? NOAA National Ocean Service. oceanservice.noaa.gov
2. United States Geological Survey. (n.d.). What is lidar data and where can I download it? USGS. usgs.gov
3. National Institute of Standards and Technology. (n.d.). Robotics and autonomous systems. NIST. nist.gov
4. IEEE Spectrum. (n.d.). Sensors and robotics coverage. IEEE. spectrum.ieee.org

The big picture

You have given your robot proprioception and ranging. It knows its own joints and how far away the nearest wall is. It still has no idea that the object on the table is a coffee cup, no way to tell whether its gripper is crushing that cup, and no notion of where in the world it stands. This lesson supplies all three: cameras for identity, force and touch for contact, and satellite navigation for global position.

These three sensors have something in common that the last two lessons' sensors did not: they produce information a robot must interpret rather than simply read. An encoder count means one thing. A 2-megapixel image means whatever your algorithms can extract from six million numbers, which in Module 5 will occupy us properly. Here we stay at the hardware level: what the devices measure, what the data actually looks like, and where each one breaks.

Keep a running tally of one number as you read: data rate. Proprioception costs bytes per second. Ranging costs kilobytes. Vision costs tens of megabytes per second, and that single fact shapes robot computing more than any other.

Cameras: cheap, rich, and hard

A digital camera is an array of light buckets. Photons fall on a grid of photosites on a CMOS sensor, each accumulating charge in proportion to the light it receives, and after the exposure the chip reads out a number per site. Color comes from a Bayer filter, a mosaic of red, green, and blue filters over the photosites (twice as many green, since human vision is most sensitive there), and the missing colors at each pixel are interpolated from neighbors. The output is a grid of numbers, typically 0 to 255 per channel: for the robot, an image is a matrix, nothing more.

Compute the load, because it explains a great deal. A modest 640 by 480 color camera at 30 frames per second produces 640 times 480 = 307,200 pixels, times 3 bytes of color, times 30 frames = about 27.6 megabytes every second. Step up to 1920 by 1080 at 30 fps and it is roughly 187 MB/s, and a self-driving car with eight such cameras is drinking from a firehose of about 1.5 GB/s. This is why robot vision usually runs on dedicated hardware, why images are downscaled aggressively before processing, and why a Raspberry Pi that handles a lidar comfortably will choke on full-resolution video.

Cameras are the cheapest rich sensor available: a few dollars buys you resolution, color, and texture that no lidar can match, and only a camera can read a barcode, recognize a face, or tell a red light from a green one. The price is fragility. Cameras need light, and performance collapses at dusk or in a dark warehouse. They are blinded by glare and by driving out of a tunnel into sun. Motion blur smears fast motion across pixels, so a robot moving quickly must use short exposures, which demands more light, a genuine tradeoff with no free side. And a single camera fundamentally cannot measure distance: the image of a toy car 1 meter away and a real car 20 meters away can be pixel-identical, an ambiguity called scale.

Key idea: A camera delivers a matrix of brightness numbers at high data rates (640x480 color at 30 fps is about 27.6 MB/s), offering unmatched richness and identity information but requiring light and providing no depth from a single view.

Getting depth from cameras

Three tricks recover the missing dimension. Stereo vision copies biology: two cameras a fixed distance apart (the baseline) see the same scene from slightly different viewpoints, and the horizontal shift of a feature between the images, its disparity, shrinks with distance. The governing relation is Z = f times B divided by d, where Z is depth, f is focal length in pixels, B is the baseline, and d is disparity in pixels. Work it: with f = 700 pixels and a baseline B = 0.12 m, an object showing 42 pixels of disparity sits at Z = 700 times 0.12 / 42 = 2.0 m. Now push it out: at 20 m the same rig yields a disparity of only 4.2 pixels, and at 40 m just 2.1 pixels, so a half-pixel matching error becomes meters of depth error. That is the fundamental stereo limitation: accuracy degrades with the square of distance, and widening the baseline is the only geometric cure. Stereo also fails on blank surfaces, since matching a white wall's pixels between images is impossible when every patch looks alike.

Structured light fixes that by projecting a known infrared pattern of dots onto the scene and watching how the pattern deforms, which is how the original Kinect worked; it gives excellent indoor depth on textureless surfaces and fails outdoors where sunlight swamps the projected dots. Time-of-flight depth cameras illuminate the whole scene with modulated infrared light and measure the phase shift at every pixel, producing depth at video rates over a few meters, again indoors. Note the pattern: each depth camera works beautifully in the environment it was designed for and poorly outside it, which is precisely why outdoor robots still buy lidar.

Key idea: Depth from cameras comes from stereo disparity (Z = fB/d, with error growing quadratically with range and failing on textureless surfaces), structured light, or time-of-flight imaging, and the latter two are largely indoor technologies.

Force and touch: knowing when you have arrived

Position control alone cannot do many jobs. Tell an arm to move to the exact surface of a table and a millimeter of model error means either hovering short or pressing hard enough to break something. Any task defined by contact, polishing, inserting a peg, wiping, holding an egg, needs the robot to feel.

The workhorse is the strain gauge: a fine metal foil pattern bonded to a structural element. Stretch it and the foil grows longer and thinner, raising its electrical resistance by a tiny fraction, typically parts per thousand, which a Wheatstone bridge circuit converts into a measurable voltage. Arrange gauges around a machined structure and you get a load cell. Put six of them in the right geometry and you get a six-axis force-torque sensor mounted at the arm's wrist, reporting force along x, y, z and torque about each axis, the standard instrument for robotic assembly and polishing. Good ones resolve well under a newton and cost thousands of dollars.

There is a clever cheaper route: series elastic actuation, which deliberately inserts a spring between motor and joint. Measure the spring's deflection with an encoder, multiply by its known stiffness, and Hooke's law gives you force for the price of a spring and a sensor you already have. The spring also protects the gearbox from impact and makes the joint gentle by nature, which is why this design appears throughout collaborative and legged robots. Many cobots skip dedicated sensors entirely and infer external force from motor current, since a blocked joint draws more current than a free one; it is cheap and coarse, defeated by friction and gearbox losses, but sufficient to trigger a safety stop.

Tactile sensing, the robotic analogue of skin, remains a genuine research frontier. Arrays of capacitive or resistive elements can map pressure across a gripper pad, and optical tactile sensors film the deformation of a soft gel from inside with a camera, recovering a remarkably detailed picture of contact geometry and even slip. Compare any of it with human skin, which packs thousands of mechanoreceptors per square centimeter in four types sensing pressure, vibration, stretch, and texture, all self-repairing, and you will understand why picking up a strange object still defeats robots that can weld a car body to a tenth of a millimeter.

Key idea: Force sensing usually comes from strain gauges in load cells or wrist force-torque sensors, with series elastic actuation and motor-current estimation as cheaper alternatives, while dense tactile skin remains far behind biology.

GPS and its honest accuracy

A GNSS receiver (Global Navigation Satellite System, the family that includes the US GPS, Europe's Galileo, Russia's GLONASS, and China's BeiDou) computes position by timing signals from satellites whose orbits are precisely known. Each satellite broadcasts its position and a timestamp; the receiver measures arrival delay to infer distance, and with four or more satellites it solves for latitude, longitude, altitude, and its own clock error. Signals travel at light speed, so a timing error of one microsecond becomes 300 meters of position error, which is why the satellites carry atomic clocks.

Be precise about accuracy, because popular belief runs optimistic. A standard smartphone or hobby receiver with a clear sky view is good to roughly 3 to 5 meters horizontally, and altitude is typically two to three times worse than horizontal. That is fine for a car on a road network and useless for a robot lawnmower trying to cut parallel stripes. Differential GNSS and RTK (real-time kinematic) close the gap by using a nearby fixed base station whose exact position is known: since both receivers see nearly the same atmospheric delays, broadcasting the base station's corrections cancels most of the shared error. RTK, which additionally tracks the carrier wave phase, reaches 1 to 3 centimeters, which is why RTK guidance now steers agricultural tractors along rows.

The failure modes are geometric and unforgiving. Satellite signals arrive at roughly the power of a dim light bulb viewed from thousands of kilometers away, so they do not penetrate buildings, dense foliage attenuates them badly, and indoors GNSS is simply unavailable. In cities, multipath error occurs when signals bounce off buildings and arrive late, adding phantom distance and throwing positions off by tens of meters in urban canyons. Updates typically come at 1 to 10 Hz, far too slow for fast control. And GNSS gives position, never orientation: a stationary robot cannot know which way it faces from a single receiver, which is why outdoor robots pair GNSS with an IMU and wheel odometry, letting the fast sensors handle motion between the slow satellite fixes. That is sensor fusion again, the theme of this entire module.

Key idea: Standard GNSS gives 3 to 5 m accuracy at 1 to 10 Hz outdoors only, RTK corrections bring that to centimeters, and GNSS never reports heading, so it must be fused with inertial and odometric sensing.

Common misconceptions

• A camera can measure distance. A single image cannot resolve scale: a small object nearby and a large one far away can produce identical pixels. Depth requires two views, projected patterns, or timed light.
• Stereo depth is accurate at any range. Disparity shrinks with distance, so depth error grows roughly with the square of range; a rig accurate to centimeters at 2 m may be meters off at 40 m.
• GPS is accurate to a few centimeters. Ordinary receivers manage 3 to 5 m horizontally, worse vertically. Centimeter accuracy requires RTK corrections from a nearby base station.
• Robots have a sense of touch comparable to ours. Wrist force sensors measure total contact force well, but dense, durable, high-resolution skin remains unsolved, which is why fine manipulation still defeats robots that weld to a tenth of a millimeter.

Recap

• Cameras output matrices of brightness values; 640x480 color at 30 fps is about 27.6 MB/s, and 1080p is roughly 187 MB/s, which dictates robot computing.
• Stereo depth follows Z = fB/d, so accuracy falls off quadratically with range and fails on textureless surfaces; structured light and time-of-flight depth cameras fix that indoors but fail in sunlight.
• Strain gauges in load cells and six-axis wrist sensors measure contact force; series elastic actuation and motor-current estimation are cheaper approximations.
• Tactile skin remains far behind biology, which packs thousands of self-repairing receptors per square centimeter.
• Standard GNSS delivers 3 to 5 m accuracy at 1 to 10 Hz outdoors, RTK reaches 1 to 3 cm, multipath corrupts urban readings, and no receiver reports heading.

Sources

1. National Coordination Office for Space-Based PNT. (n.d.). GPS accuracy. GPS.gov. gps.gov
2. National Institute of Standards and Technology. (n.d.). Robotics and autonomous systems. NIST. nist.gov
3. NASA Jet Propulsion Laboratory. (n.d.). Robotics and machine vision research. NASA JPL. jpl.nasa.gov
4. Wikipedia. (2025). Computer stereo vision. Wikimedia Foundation. en.wikipedia.org

The big picture

Pick up a cheap hobby gearmotor and you are holding the single most common actuator in robotics. Inside is a spinning brushed DC motor that, by itself, is nearly useless for driving a robot: it turns 12,000 times a minute and produces roughly the torque of a determined mosquito. Bolted to the front is a gearbox that trades most of that speed for torque, and out the other end comes a shaft turning 120 times a minute with a hundred times the twist, which is exactly what a wheel wants. Everything interesting about robot actuation lives in that trade.

This lesson makes the trade quantitative. We start with how a DC motor makes torque, then draw the torque-speed curve that every motor obeys, then do gearing arithmetic until the numbers are second nature, and finish by sizing a motor for a real robot from first principles: given a 4 kg robot on 65 mm wheels that must accelerate at 0.5 m/s squared and climb a 10 degree ramp, what motor do you buy? That calculation is the difference between a robot that drives and a smoking pile of stripped gears.

Two habits will serve you here. Always carry units, since torque in newton-meters and speed in radians per second multiply to watts, and that consistency catches most errors instantly. And always leave margin: real robots meet carpet, ramps, and friction that no calculation fully captures, so engineers size for roughly twice the computed requirement and sleep better.

How a DC motor makes torque

A brushed DC motor exploits one fact: a current-carrying wire in a magnetic field feels a force. Wind that wire into a coil, mount it on a shaft between permanent magnets, and the force becomes a twist. The trick is that a coil which has rotated half a turn would be pushed backward, so the motor includes a mechanical switch, the commutator, with sliding brushes that flip the current direction every half revolution and keep the twist going one way. Brushes wear out, spark, and generate electrical noise, which is why brushless motors, which do the same switching electronically, dominate drones, high-performance robots, and anything expected to last.

Two constants describe any DC motor, and they are secretly the same number. The torque constant Kt says torque equals Kt times current: a motor with Kt = 0.02 N-m per amp draws 5 A to make 0.1 N-m. The back-EMF constant Ke says the spinning motor generates a voltage proportional to its speed, opposing the supply. That opposition is what regulates a motor: at startup the motor is not turning, generates no back-EMF, and draws enormous current limited only by winding resistance, which is why a stalled motor gets hot and why motor drivers need current limits. As it speeds up, back-EMF rises, net voltage across the winding falls, current falls, and torque falls with it. The motor settles where torque exactly balances the load.

Key idea: DC motor torque is proportional to current, and back-EMF proportional to speed reduces current as the motor spins up, which is why stalled motors draw dangerous current and free-spinning motors draw almost none.

The torque-speed curve

Those two effects produce robotics' most useful graph. At a fixed supply voltage, a DC motor's torque falls linearly as its speed rises, defining two endpoints. Stall torque is the maximum twist, produced at zero speed with maximum current. No-load speed is the fastest the motor spins with nothing attached, where torque is zero. Draw a straight line between them and you have the motor's entire steady-state behavior.

Power is torque times angular speed, so it is zero at both ends (all twist and no motion at stall, all motion and no twist at no-load) and peaks exactly in the middle, at half the stall torque and half the no-load speed. Maximum efficiency, however, occurs closer to the high-speed end, typically 10 to 30 percent of stall torque. This gives a design rule worth remembering: run motors in the upper-speed part of their curve, not near stall. A motor grinding along at 80 percent of stall torque is converting most of your battery into heat and will cook itself within minutes.

Work a specific motor. Suppose a 12 V brushed motor has a stall torque of 0.50 N-m, a stall current of 10 A, and a no-load speed of 9,000 rpm. At half stall (0.25 N-m) it turns 4,500 rpm, which is 4,500 times 2 pi divided by 60 = 471 rad/s, so mechanical output is 0.25 times 471 = 118 watts. Meanwhile electrical input at roughly half the stall current is 12 V times 5 A = 60 W, which is impossible, and that contradiction is the lesson: catalog stall figures are idealized peaks a real motor cannot sustain thermally, so trust continuous ratings over stall numbers when you buy. The linear curve is a superb model of shape and a poor model of thermal reality.

Key idea: Torque falls linearly from stall torque at zero speed to zero at no-load speed; power peaks at the midpoint, efficiency peaks nearer no-load, so operate well away from stall.

Gearing: trading speed for torque

Raw motors are fast and weak; robots need slow and strong. A gearbox with reduction ratio N multiplies torque by N and divides speed by N, and if it were perfect, power would pass through unchanged. Real gearboxes lose to friction, so include an efficiency factor eta: output torque equals input torque times N times eta, while output speed is exactly input speed divided by N.

Work it fully. Take a motor rated 0.05 N-m of continuous torque at 6,000 rpm, fitted with a 50:1 gearbox at 70 percent efficiency, typical for a small worm or multi-stage spur box. Output speed is 6,000/50 = 120 rpm, which is 120 times 2 pi divided by 60 = 12.6 rad/s. Output torque is 0.05 times 50 times 0.70 = 1.75 N-m. Check the power: input is 0.05 N-m times 628 rad/s = 31.4 W; output is 1.75 times 12.6 = 22.0 W. The ratio 22.0/31.4 is 0.70, exactly the efficiency, which confirms the arithmetic. That habit of checking power in against power out will catch a wrong gear ratio every time.

Now convert torque into a robot's pushing force. A wheel of radius r converts torque T into a tangential force F = T/r. With our 1.75 N-m on a 65 mm diameter wheel (r = 0.0325 m), F = 1.75/0.0325 = 53.8 newtons per wheel, and two driven wheels give about 107 N of thrust. Meanwhile the linear speed is v = omega times r = 12.6 times 0.0325 = 0.41 m/s, a brisk walking pace for a small robot. One motor spec, two numbers that matter: how hard it pushes and how fast it goes.

Gearbox types matter as much as ratios. Spur gears are cheap and efficient (roughly 90 percent per stage) but noisy and backlash-prone. Planetary gearboxes distribute load across several planet gears in a compact coaxial package, reaching high ratios with good efficiency, and dominate quality robot joints. Worm gears deliver enormous reduction in one stage and are usually non-backdrivable, meaning the output cannot turn the input, which holds a lifted arm in place with no power but wastes efficiency (often 50 to 70 percent) and forbids any joint that must yield to human hands. Harmonic drives achieve 50:1 to 160:1 in a very thin package with near-zero backlash, which is why they sit inside almost every precision industrial arm and cost accordingly.

Key idea: A gearbox multiplies torque by N times efficiency and divides speed by N; wheel force is torque divided by wheel radius, and the gearbox type determines backlash, backdrivability, and efficiency.

Sizing a motor for a real robot

Here is the calculation you will actually perform. Design target: a 4.0 kg robot on four 65 mm diameter wheels, two of them driven, that must accelerate at 0.5 m/s squared on flat ground and still climb a 10 degree ramp at steady speed.

Step one, force to accelerate. F = ma = 4.0 times 0.5 = 2.0 N. Step two, force to climb. The gravity component along a slope is m g sin(theta) = 4.0 times 9.81 times sin(10 degrees) = 4.0 times 9.81 times 0.174 = 6.8 N. Step three, rolling resistance. A coefficient around 0.03 on carpet gives 0.03 times 4.0 times 9.81 = 1.2 N. The demanding case is climbing while accelerating: 2.0 + 6.8 + 1.2 = 10.0 N total. Step four, torque per wheel. Total wheel torque is F times r = 10.0 times 0.0325 = 0.325 N-m, split between two driven wheels, so 0.163 N-m each. Step five, apply the safety factor: double it to about 0.33 N-m per motor of continuous output torque. Step six, check speed. If you want 0.4 m/s, required wheel speed is v/r = 0.4/0.0325 = 12.3 rad/s, about 118 rpm.

So you need gearmotors delivering roughly 0.33 N-m continuously at about 118 rpm. Multiply to confirm the mechanical power: 0.33 times 12.3 = 4.1 W per motor. A common 12 V gearmotor with a 100:1 reduction rated near 0.4 N-m at 130 rpm fits comfortably, and at maybe 60 percent overall efficiency each motor will draw about 7 W electrically, so two motors plus electronics might pull 1.5 A from a 12 V pack. Now battery sizing follows: a 2,200 mAh pack would run roughly 2,200 mAh divided by 1,500 mA, about 1.4 hours of driving. Every one of those numbers came from mass, wheel radius, and a target acceleration, which is exactly how real machines get specified.

Key idea: Size motors by summing acceleration, gradient, and rolling-resistance forces, converting to wheel torque with T = F times r, splitting across driven wheels, and doubling for margin, then check speed and battery draw.

Quantity	Formula	Worked value
Output speed	input rpm / N	6,000/50 = 120 rpm
Output torque	input torque x N x eta	0.05 x 50 x 0.7 = 1.75 N-m
Wheel force	T / r	1.75/0.0325 = 53.8 N
Linear speed	omega x r	12.6 x 0.0325 = 0.41 m/s
Climb force	m g sin(theta)	4 x 9.81 x sin(10 deg) = 6.8 N
Mechanical power	T x omega	0.33 x 12.3 = 4.1 W

Common misconceptions

• A bigger gear ratio always makes a better robot. Reduction buys torque and spends speed. Gear too far and your robot is unstoppable at 3 cm/s, cannot be pushed by hand, and wastes power turning gears.
• A motor's stall torque is what it can deliver. Stall figures are instantaneous peaks at maximum current; sustained operation near stall overheats windings within minutes. Buy on continuous ratings.
• Gearboxes conserve power. They conserve it in the ideal case only. A worm box at 60 percent efficiency throws away 40 percent of your battery as heat, which matters enormously for run time.
• Voltage controls a motor's torque. Current controls torque; voltage sets the speed at which back-EMF balances the supply. This is why motor drivers limit current, not voltage, to protect a stalled motor.

Recap

• DC motor torque is proportional to current, and back-EMF rising with speed is what limits current and torque as the motor accelerates.
• The torque-speed curve runs linearly from stall torque at zero speed to zero torque at no-load speed; power peaks at the midpoint and efficiency nearer the fast end.
• A gearbox multiplies torque by N times efficiency and divides speed by N: 0.05 N-m at 6,000 rpm through 50:1 at 70 percent gives 1.75 N-m at 120 rpm.
• Wheel force equals torque divided by wheel radius, and linear speed equals angular speed times radius.
• Sizing sums acceleration, gradient, and rolling forces: our 4 kg robot needed about 0.33 N-m per motor at 118 rpm after doubling for margin.

Sources

1. OpenStax. (2016). Force and torque on a current loop. In University physics volume 2. Rice University. openstax.org
2. Khan Academy. (n.d.). Torque and angular momentum. khanacademy.org
3. Wikipedia. (2025). DC motor. Wikimedia Foundation. en.wikipedia.org
4. National Institute of Standards and Technology. (n.d.). Robotics and autonomous systems. NIST. nist.gov

The big picture

Last lesson gave you a motor that spins. That is not yet an actuator you can command, because spinning is not the same as going to 47 degrees and staying there. Getting from raw rotation to controlled position requires either a feedback loop wrapped around the motor or a motor whose physics enforces discrete positions on its own. Those two answers are the servo and the stepper, and between them they run most of the small robots on Earth.

Then there is the third path, the one that lifts excavator booms and swings 500 kilogram industrial arms: fluid power. Hydraulics and pneumatics move force with pressurized oil and air, and they still win decisively wherever force density is the binding constraint. Unimate was hydraulic for exactly this reason, and Boston Dynamics' Atlas was hydraulic until 2024.

This lesson is a tour of those three technologies with the numbers that let you choose among them. By the end you will know why a $12 hobby servo can hold a position it cannot measure precisely, why a 3D printer uses steppers and no encoders, why a pneumatic gripper cannot be told to close halfway, and why the world's strongest robots leak oil.

Hobby servos: a motor with a brain

A hobby servo is a complete little control system in a plastic box: a small DC motor, a gearbox (often 200:1 or more), a potentiometer geared to the output shaft, and a control circuit. You command an angle; the circuit compares the potentiometer's reading to your command and drives the motor toward the difference until it vanishes. It is the sense-think-act loop, miniaturized, running at maybe 50 Hz inside a component costing less than lunch.

The command interface is a standard worth knowing. Servos are told what to do with pulse width modulation: a pulse repeated every 20 milliseconds (50 Hz), whose width encodes the target. A 1.0 ms pulse means one extreme, roughly 0 degrees; 1.5 ms means center, 90 degrees; 2.0 ms means the other extreme, about 180 degrees. Convert linearly: a 1.25 ms pulse commands about 45 degrees, and 1.75 ms commands about 135 degrees. Note that the information lives entirely in the pulse's width, not its height or its repetition rate, which makes the scheme wonderfully robust over long, noisy wires.

Servos come in two useful sizes of honesty. Analog servos update their internal loop about 50 times a second and hum audibly while holding; digital servos run their loop at several hundred hertz, hold position more stiffly, and draw more current at idle. Both share real limits. Resolution is coarse, typically around 1 degree at best, since a cheap potentiometer and 8-bit electronics can do no better. There is no feedback out: your controller commands 90 degrees and has no idea whether the servo achieved it, stalled against an obstacle, or stripped a gear, which is why serious arms use encoders on every joint. Standard servos sweep only about 180 degrees. And a stalled servo pushing against a blocked load will happily draw current until its gears or its driver fail. Continuous-rotation servos are the same hardware with the potentiometer disconnected from the output, turning the position command into a speed command, a cheap and popular way to drive small robot wheels.

Key idea: A hobby servo closes its own position loop with an internal potentiometer, commanded by pulse width (1.0 to 2.0 ms within a 20 ms frame), giving cheap angle control with about 1 degree resolution and no feedback back to your controller.

Steppers: position without feedback

A stepper motor takes a completely different route to controlled position. Its rotor has many teeth, and its stator has multiple coil phases. Energize the phases in sequence and the rotor snaps forward one fixed increment per step, holding firmly between commands. The most common industrial stepper is the 1.8 degree hybrid type, which means 360/1.8 = 200 discrete steps per revolution. Command exactly 200 steps and the shaft has turned exactly once, no sensor required, which is why steppers dominate 3D printers, CNC machines, camera rigs, and laboratory instruments.

Resolution improves further with microstepping, where the driver feeds sinusoidally proportioned currents to both phases to hold the rotor between full steps. At 1/16 microstepping, a 200-step motor delivers 3,200 microsteps per revolution, that is 0.1125 degrees each. Work a linear example: a 3D printer axis with a 200-step motor driving a belt with a 20 tooth pulley at 2 mm tooth pitch moves 40 mm per revolution, so a full step is 40/200 = 0.2 mm and a 1/16 microstep is 0.0125 mm, 12.5 micrometers. That is the arithmetic behind every printer's configuration file. Be aware that microstepping improves smoothness far more than it improves true positioning accuracy, because holding torque between detents is weak and friction easily swallows a microstep.

The stepper's characteristic failure is the mirror image of its virtue. Because there is no feedback, a stepper that is asked for more torque than it can deliver, whether by acceleration that is too aggressive, a jammed axis, or too high a step rate, will simply skip steps. The controller believes the axis moved; it did not. Nothing reports the error, and every subsequent position is wrong by the lost amount, which is exactly why a 3D print can shift sideways mid-job and continue printing confidently in the wrong place. Steppers also draw full current while holding still, running hot even at rest, and their torque falls off sharply at high speed. Modern closed-loop steppers bolt an encoder on the back specifically to catch missed steps, blending the two philosophies.

Key idea: Steppers move in fixed increments (1.8 degrees, 200 per revolution) with no feedback, so position is known by counting commands, but overload causes silently missed steps that corrupt all later positions.

Choosing among the electric options

Actuator	Position control	Typical resolution	Best for	Weakness
Geared DC motor	External loop with encoder	Encoder-limited, very fine	Drive wheels, arm joints	Needs a controller and sensor
Hobby servo	Internal, closed	About 1 degree	Small joints, grippers, pan-tilt	No feedback out, limited sweep
Stepper	Open loop by counting steps	1.8 degrees, finer with microstepping	Printers, CNC, precise linear axes	Silent missed steps, hot at rest
Brushless with encoder	External, high performance	Very fine	Drones, legged robots, cobots	Costly electronics

Hydraulics: force without compromise

Hydraulics transmit force through nearly incompressible oil. A pump pressurizes the fluid, valves route it, and a cylinder converts pressure into linear force. The arithmetic is Pascal's principle: force equals pressure times piston area. Take a modest cylinder with a 50 mm bore, giving an area of pi times 0.025 squared = 0.00196 square meters. At a common industrial pressure of 20 MPa (about 200 bar, 2,900 psi), the force is 20,000,000 times 0.00196 = 39,200 newtons, roughly 4 tonnes of thrust from a cylinder you can hold in one hand. No electric actuator of that size comes remotely close, and that single fact explains excavators, aircraft controls, and the original Unimate.

Because oil barely compresses, hydraulic systems are stiff and hold heavy loads rigidly without consuming energy in the holding. They are also controllable to fine positions using servo valves, and they tolerate shock loads that would strip a gearbox. The costs are equally emphatic: pumps, reservoirs, hoses, filters, and coolers make the system bulky and loud; hydraulic fluid leaks, and eventually every hydraulic machine does leak; efficiency is mediocre because a running pump consumes power even when nothing moves; and maintenance is constant. Boston Dynamics' decision to retire the hydraulic Atlas in 2024 in favor of an all-electric version captures the industry's direction: electric actuators have improved enough that hydraulics are retreating toward the very high-force applications only they can serve.

Key idea: Hydraulic force equals pressure times piston area, so a 50 mm bore at 20 MPa yields about 39 kN, an unmatched force density that costs bulk, noise, leaks, and maintenance.

Pneumatics: fast, cheap, and springy

Pneumatics use compressed air, typically at 0.6 MPa (6 bar, about 87 psi), the standard pressure in factory air lines. Run the same 50 mm bore cylinder at 6 bar: 600,000 times 0.00196 = 1,180 newtons, about 120 kilograms of push. Far less than hydraulics, but plenty for clamping, stamping, and gripping, and the components are cheap, light, clean, and safe around food and electronics.

Air's compressibility is the whole story, good and bad. Bad, because a compressed-air actuator is effectively a spring: it bounces, it overshoots, and it is genuinely difficult to stop halfway with any precision. That is why pneumatic devices are usually run bang-bang, fully extended or fully retracted against mechanical stops, and why a pneumatic gripper is open or closed rather than positioned. Good, because that same springiness makes pneumatics naturally compliant and shock-tolerant, which is exactly what you want gripping a delicate part or absorbing an impact, and it is why soft robots use pumped air almost exclusively. Pneumatics are also very fast, cycling many times per second, which suits high-rate packaging lines. The hidden cost is efficiency: compressing air, then throwing the exhaust away, wastes most of the input energy, making shop air one of the most expensive utilities in a factory despite feeling free at the tool.

Key idea: Pneumatics at 6 bar give roughly 1.2 kN from a 50 mm bore: cheap, fast, clean, and inherently compliant, but bouncy, hard to position mid-stroke, and energetically wasteful.

Common misconceptions

• A hobby servo tells your controller where it ended up. Standard servos are command-only. If the arm is blocked, your code never learns; add an encoder or current sensing if you need to know.
• Microstepping makes a stepper sixteen times more accurate. It makes motion much smoother and improves resolution nominally, but holding torque between detents is weak and friction absorbs microsteps, so true accuracy improves far less.
• Steppers cannot lose position because they are digital. Overload, excessive acceleration, or a jam causes silently missed steps, and every later position inherits the error, which is why closed-loop steppers exist.
• Pneumatics can be positioned anywhere along the stroke like an electric axis. Air compresses, so mid-stroke positioning is springy and imprecise; standard practice is full extension or retraction against hard stops.

Recap

• Hobby servos contain motor, gearbox, potentiometer, and controller, commanded by pulse widths of 1.0 to 2.0 ms every 20 ms, with about 1 degree resolution and no feedback out.
• Steppers hold fixed increments, commonly 1.8 degrees for 200 steps per revolution; 1/16 microstepping gives 3,200 microsteps, or 0.0125 mm on a 40 mm-per-revolution belt axis.
• Missed steps under overload are silent and permanent, the stepper's defining risk, addressed by closed-loop versions with encoders.
• Hydraulic force is pressure times area: a 50 mm bore at 20 MPa gives about 39 kN, unbeatable force density at the cost of bulk, leaks, and maintenance.
• Pneumatics at 6 bar give about 1.2 kN from the same bore, are fast, cheap, and compliant, but bounce, resist mid-stroke positioning, and waste energy.

Sources

1. Britannica. (2024). Hydraulics. In Encyclopaedia Britannica. britannica.com
2. Wikipedia. (2025). Stepper motor. Wikimedia Foundation. en.wikipedia.org
3. Wikipedia. (2025). Servomotor. Wikimedia Foundation. en.wikipedia.org
4. IEEE Spectrum. (2024). Boston Dynamics retires hydraulic Atlas. IEEE. spectrum.ieee.org

The big picture

Two motors, two wheels, one caster. That is the entire drivetrain of most small robots, and the mathematics linking those two motor speeds to where the robot actually goes is the first real kinematics you will do. It is not hard mathematics, just two equations, but it is genuinely load-bearing: it converts high-level commands like drive forward at 0.3 meters per second while turning left at 30 degrees per second into the two numbers your motor controllers need, and it converts encoder readings back into an estimate of how the robot moved, which is odometry.

We are going to work these equations numerically until they are yours. Then we turn to the other end of the robot, the part that touches the object: the gripper. Grasping looks trivial when you do it and becomes a doctoral thesis when a robot tries, so we will build the practical picture, the main gripper types, how to compute the force needed to hold something, and why the industry mostly avoids the whole problem by using suction cups instead.

Have a pen ready. Every equation in this lesson gets used with real numbers, and the arithmetic is the point.

The differential drive equations

Set up the geometry. A robot has two driven wheels of radius r, separated by a distance L called the wheelbase or track width, measured between the wheel contact points. The left wheel turns at angular speed omega_L and the right at omega_R, so each wheel's ground speed is v_L = omega_L times r and v_R = omega_R times r.

Two facts give the whole model. First, the robot's forward speed is the average of the wheel speeds: v = (v_R + v_L)/2. Second, the robot's rate of rotation is the difference of the wheel speeds divided by the wheelbase: omega = (v_R - v_L)/L. The first is intuitive; the second says that a difference in wheel speed is what makes the robot turn, and that a wider robot needs a bigger speed difference to turn at the same rate.

Work example one, straight ahead. Both wheels at 0.30 m/s: v = (0.30 + 0.30)/2 = 0.30 m/s and omega = (0.30 - 0.30)/L = 0. The robot goes straight at 0.30 m/s. Good.

Work example two, a gentle turn, and let us fix numbers: r = 0.035 m, L = 0.25 m. Suppose v_L = 0.20 m/s and v_R = 0.30 m/s. Then v = (0.30 + 0.20)/2 = 0.25 m/s, and omega = (0.30 - 0.20)/0.25 = 0.40 rad/s, which is 0.40 times 180/pi = 22.9 degrees per second, turning left because the right wheel is faster. The instantaneous center of curvature, the point the robot pivots around, sits at radius R = v/omega = 0.25/0.40 = 0.625 m to the left of the robot's center. So this command traces a circle of radius 62.5 cm. Check it a second way: R = (L/2) times (v_R + v_L)/(v_R - v_L) = 0.125 times (0.50/0.10) = 0.125 times 5 = 0.625 m. The two methods agree, which is how you catch algebra errors.

Work example three, spinning in place. Set v_L = -0.20 m/s and v_R = +0.20 m/s. Then v = (0.20 + (-0.20))/2 = 0, and omega = (0.20 - (-0.20))/0.25 = 1.6 rad/s, about 91.7 degrees per second. The robot rotates about its own center without translating, the zero-radius turn that makes differential drive so useful indoors. How long to turn exactly 90 degrees? 90 degrees is 1.571 radians, so t = 1.571/1.6 = 0.98 seconds.

Key idea: For a differential drive robot, v = (v_R + v_L)/2 and omega = (v_R - v_L)/L, and the turning radius is R = v/omega, which goes to zero when the wheels run equal and opposite.

Inverse kinematics: from desired motion to wheel commands

The equations run backward, which is how you actually drive a robot. Given a desired v and omega, solve for the wheel speeds: v_R = v + (omega times L)/2 and v_L = v - (omega times L)/2. Then convert each to a motor command by dividing by wheel radius to get radians per second.

Do it. You want the robot to travel at 0.40 m/s while turning right at 0.50 rad/s (turning right means negative omega by our sign convention, since positive omega turns left). With L = 0.25 m: v_R = 0.40 + (-0.50 times 0.25)/2 = 0.40 - 0.0625 = 0.3375 m/s, and v_L = 0.40 + 0.0625 = 0.4625 m/s. Convert to wheel angular speeds with r = 0.035 m: omega_R = 0.3375/0.035 = 9.64 rad/s (92 rpm), and omega_L = 0.4625/0.035 = 13.21 rad/s (126 rpm). Those two numbers go to your motor controllers, and this five-line calculation sits inside every differential drive robot ever written.

One practical warning the equations do not contain: saturation. If the requested v_L exceeds your motor's top speed, the controller clamps it, and the actual turn rate silently differs from the commanded one, usually sending the robot wide on turns at speed. Good software checks both wheel commands against the limit and scales both down together, preserving the ratio and therefore the curvature, rather than letting one wheel clip.

Key idea: To command motion, invert the equations: v_R = v + omega L/2, v_L = v - omega L/2, then divide by wheel radius; scale both wheels together if either saturates so the intended curvature survives.

Odometry, and why it drifts

Run the same equations on measured encoder data instead of commands and you get odometry, the robot's estimate of its own position. Each control cycle, read how far each wheel turned, compute the average (distance traveled) and the difference (heading change), and update the pose: x increases by d times cos(theta), y by d times sin(theta), and theta by the computed rotation, with theta being the robot's heading.

Do one step. In a 50 ms cycle, the left wheel moved 6.0 mm and the right 6.4 mm, with L = 250 mm. Distance d = (6.0 + 6.4)/2 = 6.2 mm. Heading change = (6.4 - 6.0)/250 = 0.0016 rad, about 0.092 degrees. If the robot started at heading 0, it is now at x = 6.2 mm, y = about 0.005 mm, heading 0.092 degrees. Repeat 20 times a second forever.

And there is the problem, which Module 5 will treat properly: every step adds its error to the total, and heading errors are the killer, because a small heading error grows into a large position error the farther you drive. If your estimate of L is off by 2 percent, every turn is wrong by 2 percent and the errors accumulate in the same direction. One millimeter of wheel diameter difference between left and right makes a robot curve steadily while believing it drives straight. And no amount of encoder precision helps at all when a wheel slips, because odometry measures wheels, not ground. Expect a well-tuned indoor robot to accumulate a few percent of distance traveled as position error, which is fine for 3 meters and hopeless for 100.

Key idea: Odometry integrates the same differential drive equations from encoder measurements, and its errors, especially in heading and from wheel slip, accumulate without bound, typically a few percent of distance traveled.

Grippers: the hard end of the robot

An end effector is whatever the arm carries: a welding torch, a paint sprayer, a sensor, or, most interestingly, a gripper. Grasping is the part of robotics where human ease and machine difficulty diverge most sharply, and the industry's response has been ruthless pragmatism: use the simplest device that can hold the specific parts, and design the workspace so no other parts appear.

The workhorse is the parallel jaw gripper, two flat fingers that close in a straight line, driven pneumatically or electrically. It is simple, strong, precise, and completely dependent on the part having two roughly parallel faces at a known width. For irregular objects, angular and three-finger centric grippers close radially and self-center round stock, which is why they hold bottles and pipes well. Vacuum grippers, meaning suction cups, are the quiet champions of industry: they need only one accessible flat or gently curved surface, they are cheap, fast, and forgiving, and they handle the boxes and sheets that make up an enormous fraction of real material handling. Compute their strength: a 40 mm diameter cup has an area of pi times 0.02 squared = 0.00126 square meters, and a practical vacuum of 60 kPa below atmosphere gives 60,000 times 0.00126 = 75 newtons, enough for about 7.6 kg with no safety factor, so in practice you would rate it near 2.5 kg and use several cups. Magnetic grippers do the same trick for ferrous steel. Soft and granular jamming grippers, from the last module's discussion, handle produce and irregular items.

Then there are multi-fingered dexterous hands, with 15 or more actuated joints and tactile skin, which can in principle do anything a human hand can. In practice they remain expensive, fragile, and hard to control, and they appear in research labs far more often than on production lines. The honest summary is that the field has largely won at grasping known objects in known poses and is still working on grasping arbitrary objects in clutter, which is Moravec's paradox showing up in hardware.

Sizing a grip force

How hard must a gripper squeeze? For an object held between two friction pads, the gripper must generate enough normal force that friction beats gravity plus acceleration. The requirement is roughly F_normal greater than or equal to (m times (g + a) times S) divided by (2 times mu), where mu is the friction coefficient, S is a safety factor, and the 2 accounts for two contacting jaws.

Work it: hold a 2.0 kg part with rubber pads on steel (mu about 0.6), on an arm that accelerates the part upward at 5 m/s squared, with a safety factor of 2. Numerator: 2.0 times (9.81 + 5) times 2 = 2.0 times 14.81 times 2 = 59.2 N. Denominator: 2 times 0.6 = 1.2. Required normal force = 59.2/1.2 = 49.4 newtons per jaw. Notice what dominates: acceleration added 50 percent to the requirement, and dropping to smooth steel pads at mu = 0.15 would quadruple the needed force to about 198 N. This is exactly why grippers have rubber or urethane pads and why fast robots need stronger grips than slow ones. It is also why a robot that drops parts is often fixed by changing pad material rather than buying a bigger gripper.

Key idea: Required grip force scales with mass, acceleration, and safety factor and inversely with friction: 2 kg accelerating at 5 m/s squared with mu = 0.6 and S = 2 needs about 49 N per jaw, and slick pads multiply that several times over.

Common misconceptions

• Turning a differential drive robot means slowing one wheel to zero. Any speed difference turns it. Zeroing one wheel pivots around that wheel's contact point, radius L/2, which is just one case among many.
• Better encoders fix odometry drift. Encoders measure wheels. Slip, unequal wheel diameters, and errors in the assumed wheelbase all corrupt odometry no matter how finely you count.
• Grippers should squeeze as hard as possible. Excess force crushes parts, wears jaws, and wastes energy; the correct force comes from the friction calculation with a modest safety factor.
• A dexterous five-fingered hand is what industry wants. Most production tasks are best served by a two-jaw gripper or suction cups, because the workspace can be engineered so that only known parts in known poses ever appear.

Recap

• Differential drive forward kinematics: v = (v_R + v_L)/2 and omega = (v_R - v_L)/L, with turning radius R = v/omega.
• With v_L = 0.20, v_R = 0.30 m/s and L = 0.25 m, the robot moves at 0.25 m/s, turns at 0.40 rad/s, and traces a 0.625 m radius arc.
• Inverse kinematics gives wheel commands: v_R = v + omega L/2 and v_L = v - omega L/2, then divide by r for motor speeds, scaling both if either saturates.
• Odometry applies the same equations to encoder data and drifts steadily, particularly through heading error and wheel slip.
• Parallel jaw, angular, vacuum, magnetic, and soft grippers cover most industrial needs; grip force follows F = m(g + a)S/(2 mu), giving about 49 N per jaw for a 2 kg part at mu = 0.6.

Sources

1. National Institute of Standards and Technology. (n.d.). Robotic grasping and manipulation performance. NIST. nist.gov
2. Wikipedia. (2025). Differential wheeled robot. Wikimedia Foundation. en.wikipedia.org
3. Wikipedia. (2025). Robot end effector. Wikimedia Foundation. en.wikipedia.org
4. IEEE Spectrum. (n.d.). Robotic manipulation coverage. IEEE. spectrum.ieee.org

The big picture

Hold your hand out in front of you and freeze it. Now, without moving your hand at all, move your elbow. You can: your elbow swings through an arc while your fingertips stay put. That small demonstration contains this lesson's two central ideas. First, placing your hand somewhere takes a certain number of independent motions, and your arm has more than that number, which is why the elbow can wander while the hand holds still. Second, if I told you every joint angle in your arm, I could compute exactly where your fingertip is, and that computation is forward kinematics.

Kinematics is the geometry of motion without regard to forces: where things are and how they move, not what pushes them. It is the mathematical core of manipulation, and it splits into two problems. Forward kinematics asks: given the joint angles, where is the hand? That problem always has exactly one answer, and it is straightforward trigonometry. Inverse kinematics asks the reverse: given a desired hand position, what joint angles get me there? That one may have no solution, one solution, several, or infinitely many, and it is the subject of the next lesson.

Today we build forward kinematics from the ground up. We start with degrees of freedom, work the two-link planar arm completely with numbers you can verify on a calculator, then extend the ideas to workspaces, redundancy, and the coordinate frames that let engineers chain these calculations along a six-jointed industrial arm.

Degrees of freedom

Degrees of freedom (DOF) is the number of independent parameters needed to specify a system's configuration. For a robot, it is essentially the number of independently actuated joints. For an object in space, it is a fixed fact of geometry: a rigid body in three-dimensional space has exactly six degrees of freedom, three for position (x, y, z) and three for orientation (roll, pitch, yaw). Move a coffee mug anywhere in a room and hold it at any angle, and you have specified six numbers. There is no seventh.

That is why the standard industrial arm has six joints. Six actuated DOF is the minimum to place an end effector at an arbitrary position with an arbitrary orientation within the arm's reach. Fewer joints means giving something up. A four-DOF SCARA can place a tool anywhere in a horizontal plane, at any height, rotated about the vertical axis, but it cannot tilt the tool, which is fine because inserting components straight down never requires tilt. A planar two-link arm, our worked example today, has two DOF and can reach points in a plane but cannot control the orientation of its final link independently.

What about a seventh joint? An arm with seven DOF is redundant: it has more freedom than the task requires, which is exactly the situation of your own arm (shoulder 3, elbow 1, wrist 3, giving 7). Redundancy is genuinely useful. It lets a robot reach the same point in infinitely many configurations, which means it can dodge an obstacle with its elbow, avoid a joint limit, or stay away from awkward configurations while keeping the tool exactly where the task demands. The cost is a harder control problem, since the robot must choose among infinite solutions, and more hardware. Redundant arms show up where robots work in cluttered spaces alongside people.

Key idea: A rigid body in space has six degrees of freedom, three of position and three of orientation, so six joints is the standard for arbitrary placement; fewer sacrifices capability, and seven or more provides redundancy that allows the same hand pose with different elbow positions.

Forward kinematics of a two-link planar arm

Now the central calculation. Picture an arm lying flat on a table, anchored at the origin. Link 1 has length L1 and makes angle theta1 with the x axis. At its tip sits the second joint, and link 2 has length L2 and makes angle theta2 relative to link 1. We want the coordinates of the end point.

Build it in two steps. The elbow, the joint between the links, is simply L1 at angle theta1 from the origin: x_elbow = L1 cos(theta1) and y_elbow = L1 sin(theta1). Now, from the elbow, the second link points at the angle theta1 + theta2 measured from the x axis, because theta2 is measured relative to link 1 and angles add. So the end effector is at:

x = L1 cos(theta1) + L2 cos(theta1 + theta2)
y = L1 sin(theta1) + L2 sin(theta1 + theta2)

Those two lines are the forward kinematics of the two-link planar arm, and they are worth memorizing because their structure repeats for every serial chain: each link contributes its own length times the cosine and sine of the accumulated angle.

Work example one. Let L1 = 0.40 m and L2 = 0.30 m, with theta1 = 30 degrees and theta2 = 45 degrees. First the accumulated angle: theta1 + theta2 = 75 degrees. Now the values: cos(30) = 0.866, sin(30) = 0.500, cos(75) = 0.259, sin(75) = 0.966. Substitute: x = 0.40 times 0.866 + 0.30 times 0.259 = 0.3464 + 0.0777 = 0.424 m. And y = 0.40 times 0.500 + 0.30 times 0.966 = 0.200 + 0.290 = 0.490 m. So the tool sits at (0.424, 0.490) meters. Sanity check the magnitude: the distance from the origin is the square root of (0.424 squared plus 0.490 squared) = square root of (0.180 + 0.240) = square root of 0.420 = 0.648 m, comfortably less than the fully extended 0.70 m and more than the folded minimum of 0.10 m. The answer is geometrically plausible.

Work example two, the straight arm. Set theta1 = 0 and theta2 = 0. Then x = 0.40 times 1 + 0.30 times 1 = 0.70 m and y = 0. The arm points straight along x at full extension, exactly as it must. Work example three, folded back: theta1 = 0, theta2 = 180 degrees gives x = 0.40 times 1 + 0.30 times (-1) = 0.10 m and y = 0. The forearm has doubled back over the upper arm, leaving the tool 0.10 m out. These two extremes bound the reachable radius.

Key idea: For a two-link planar arm, x = L1 cos(theta1) + L2 cos(theta1 + theta2) and y = L1 sin(theta1) + L2 sin(theta1 + theta2); each link adds its length times cosine and sine of the accumulated joint angle.

The workspace

Sweep both joints through all their angles and the set of points the tool can reach is the arm's workspace. For our planar arm with L1 = 0.40 and L2 = 0.30, the reachable set is an annulus, a flat ring, with outer radius L1 + L2 = 0.70 m (arm straight) and inner radius the absolute value of L1 - L2 = 0.10 m (arm folded). No amount of cleverness reaches a point 0.75 m away or a point 0.05 m from the shoulder; those are outside the workspace, and asking for them is the most common cause of an unreachable target error in real robot code.

Engineers distinguish two workspaces. The reachable workspace is every point the tool can touch in at least one orientation. The dexterous workspace is the smaller set of points the tool can reach in any orientation, which for many arms is a modest region near the middle of the reach. That distinction matters practically: an arm may technically reach the far corner of a table and be unable to hold a screwdriver vertically there. Notice also that equal link lengths (L1 = L2) shrink the inner radius to zero, giving a full disc workspace, which is why many arm designs use similar link lengths.

Key idea: The workspace of a two-link arm is an annulus from the absolute value of L1 minus L2 out to L1 plus L2; the reachable workspace is larger than the dexterous workspace where all orientations are available.

Frames, transformations, and real arms

Our two-link calculation used plain trigonometry, which stops being practical at six joints in three dimensions. The professional tool is the coordinate frame: attach a small set of x, y, z axes to every link, and describe each link's position and orientation relative to the previous link's frame. Each such relationship is captured in a 4 by 4 homogeneous transformation matrix, which packs a 3 by 3 rotation and a 3-element translation into one object that can be multiplied. The full forward kinematics of a six-jointed arm is then the product of six such matrices, from base frame to tool frame, and the tool's position and orientation in world coordinates fall out of the result.

The bookkeeping convention almost everyone uses is Denavit-Hartenberg parameters, published in 1955, which describe each joint-link pair with just four numbers: link length, link twist, link offset, and joint angle. Give a robot's DH table and any competent kinematics library will compute its motion. The mathematics of matrices is beyond this course, but the concept is not, and it is the concept that matters: the position of the tool is nothing more than a chain of relative transformations, exactly like our two-step elbow-then-tool calculation, generalized to three dimensions and mechanized so a computer can do it in microseconds.

One more idea deserves naming, because it shows up everywhere in robot control. The Jacobian is the matrix that relates joint velocities to end-effector velocity: turn each joint at a given rate and the Jacobian tells you how fast the tool moves and in what direction. It is the derivative of the forward kinematics, it converts joint speeds into tool speeds, and, run in reverse, it converts a desired tool motion into required joint rates. It is also what tells you when an arm is in trouble, because a Jacobian that loses rank means the arm has hit a singularity, which is exactly where the next lesson begins.

Key idea: Real arms chain 4 by 4 homogeneous transformations, one per joint (conventionally parameterized by Denavit-Hartenberg values), and the Jacobian relates joint velocities to end-effector velocity.

Configuration	DOF	Can control	Cannot control
2-link planar arm	2	Position in a plane	Tool orientation
SCARA	4	x, y, z and rotation about vertical	Tool tilt
Standard industrial arm	6	Full position and orientation	Elbow placement (no spare freedom)
Redundant arm	7 or more	Full pose plus obstacle avoidance	Nothing, but control is harder

Common misconceptions

• More joints always mean a better robot. Extra joints add cost, weight, flex, and control complexity. Six is chosen because six is what full pose control requires; a seventh is added deliberately for obstacle avoidance, not for its own sake.
• Forward kinematics can have several answers. It never does. Given every joint angle, the tool has exactly one pose. Multiple solutions belong to inverse kinematics.
• An arm can reach anything inside its maximum radius. Two-link arms have an inner dead zone of radius equal to the absolute difference of the link lengths, and real arms have joint limits carving further holes in the workspace.
• theta2 is measured from the x axis. In the standard convention, joint angles are relative to the previous link, which is why the second link's absolute direction is theta1 + theta2. Mixing conventions is the most common source of kinematics errors.

Recap

• Degrees of freedom count independent motions; a rigid body in space has exactly six, three of position and three of orientation, which is why standard arms have six joints.
• Redundant arms with seven or more DOF can hold the tool fixed while repositioning the elbow, useful for obstacle and joint-limit avoidance.
• Two-link forward kinematics: x = L1 cos(theta1) + L2 cos(theta1 + theta2), y = L1 sin(theta1) + L2 sin(theta1 + theta2).
• With L1 = 0.40 m, L2 = 0.30 m, theta1 = 30 degrees, theta2 = 45 degrees, the tool sits at (0.424, 0.490) m, a radius of 0.648 m.
• The workspace is an annulus between 0.10 m and 0.70 m for those links; real arms chain homogeneous transformations, and the Jacobian maps joint velocities to tool velocity.

Sources

1. Wikipedia. (2025). Forward kinematics. Wikimedia Foundation. en.wikipedia.org
2. Wikipedia. (2025). Denavit-Hartenberg parameters. Wikimedia Foundation. en.wikipedia.org
3. Khan Academy. (n.d.). Trigonometry. khanacademy.org
4. National Institute of Standards and Technology. (n.d.). Robotic systems performance measurement. NIST. nist.gov

The big picture

Forward kinematics was the easy direction. You knew every joint angle and computed one unambiguous answer for where the tool ended up. Now reverse the arrow, because reversing it is what robots actually need: the task says put the gripper at this point on the table, and the controller must find joint angles that achieve it. That is inverse kinematics, and it is a fundamentally harder problem in every way that matters.

Harder how? Three ways. There may be no solution at all, if the point lies outside the workspace. There may be several distinct solutions, since your own arm can reach the same cup with your elbow up or down. And for redundant arms there may be infinitely many, an entire continuum of elbow positions holding the hand fixed. Forward kinematics is a function; inverse kinematics is a search among possibilities, sometimes an empty set of them.

Today we solve it properly for the two-link planar arm, with numbers, using nothing more than the law of cosines. Then we look at what happens near singularities, the configurations where an arm loses the ability to move in some direction and its controller can do something violent, and we close with how six-jointed industrial arms are handled in practice. Get out the calculator again; this lesson earns its keep in arithmetic.

Why the inverse problem is hard

Consider the target point (0.424, 0.490) that our arm reached last lesson with theta1 = 30 degrees and theta2 = 45 degrees. Ask the reverse question: what joint angles put the tool there? The answer we already know is one solution. But there is another. Reflect the elbow across the line from the shoulder to the target and you get a second configuration, elbow bent the other way, whose tool lands on exactly the same point. Roboticists call these the elbow-up and elbow-down solutions, and both are correct. A real controller must choose, usually by picking whichever requires less joint motion from the current pose, or whichever avoids an obstacle.

Now ask for the point (0.90, 0.00) with L1 = 0.40 and L2 = 0.30. Total reach is 0.70 m, so the target is unreachable: zero solutions. Ask for a point 0.05 m from the shoulder and it lies inside the inner dead zone: again zero solutions. Ask a seven-DOF arm for any reachable pose and you get infinitely many solutions. So the inverse problem's answer set can be empty, dual, or infinite, and good software must handle all three cases explicitly rather than assuming a solution exists.

Key idea: Inverse kinematics may have no solution (target outside the workspace), multiple solutions (elbow up or down), or infinitely many (redundant arms), so the controller must both detect reachability and choose among valid answers.

Solving the two-link arm, step by step

Here is the closed-form solution, worked completely. Given a target (x, y) and link lengths L1 and L2, we want theta1 and theta2.

Step one: find the straight-line distance from the shoulder to the target. Call it D, where D = square root of (x squared plus y squared). Step two: check reachability. If D is greater than L1 + L2 or less than the absolute value of L1 - L2, stop, because no solution exists.

Step three: solve for theta2 with the law of cosines. The triangle has sides L1, L2, and D, with theta2 related to the angle between the links. The law of cosines gives cos(theta2) = (x squared + y squared - L1 squared - L2 squared) divided by (2 L1 L2). Step four: solve for theta1 using theta1 = atan2(y, x) - atan2(L2 sin(theta2), L1 + L2 cos(theta2)). The first term aims the arm at the target; the second corrects for the fact that the bent elbow throws the tool off that straight line.

Now use it. Target (0.424, 0.490), L1 = 0.40, L2 = 0.30. First D: x squared = 0.1798, y squared = 0.2401, sum = 0.4199, so D = 0.648 m. That is between 0.10 and 0.70, so the point is reachable. Next theta2: numerator = 0.4199 - 0.16 - 0.09 = 0.1699; denominator = 2 times 0.40 times 0.30 = 0.24; so cos(theta2) = 0.1699/0.24 = 0.708. Taking the inverse cosine gives theta2 = 44.9 degrees, which rounds to the 45 degrees we started from. The arithmetic closes, which is the best possible check on a kinematics derivation.

Finish with theta1. We need sin(theta2) = sin(44.9 degrees) = 0.706 and cos(theta2) = 0.708. Then atan2(y, x) = atan2(0.490, 0.424) = 49.1 degrees. And atan2(L2 sin(theta2), L1 + L2 cos(theta2)) = atan2(0.30 times 0.706, 0.40 + 0.30 times 0.708) = atan2(0.212, 0.612) = 19.1 degrees. So theta1 = 49.1 - 19.1 = 30.0 degrees. Exactly our starting value. The forward and inverse calculations are now verified against each other, and you have a complete, usable IK solver for a planar arm.

The second solution comes free: taking the negative inverse cosine gives theta2 = -44.9 degrees, and recomputing theta1 with that value yields theta1 = 49.1 + 19.1 = 68.2 degrees. Check it forward: x = 0.40 cos(68.2) + 0.30 cos(23.3) = 0.40(0.371) + 0.30(0.918) = 0.148 + 0.275 = 0.424, and y = 0.40(0.929) + 0.30(0.396) = 0.371 + 0.119 = 0.490. Same point, different arm shape. That is the elbow-down solution, proven numerically.

Key idea: For a two-link arm, compute D, check reachability, get theta2 from cos(theta2) = (x squared + y squared - L1 squared - L2 squared)/(2 L1 L2), then theta1 = atan2(y, x) - atan2(L2 sin theta2, L1 + L2 cos theta2); the negative theta2 root gives the second solution.

Why atan2 and not arctangent

A small but genuinely important detail. The ordinary arctangent function takes a single ratio y/x and returns an angle between -90 and +90 degrees, which cannot distinguish the direction (1, 1) from (-1, -1) since both have ratio 1. Robot arms work in all four quadrants, so kinematics code universally uses atan2(y, x), a two-argument function that examines the signs of both inputs and returns the correct angle across the full -180 to +180 degree range. Using plain arctangent in an IK routine produces an arm that works perfectly in front of itself and reaches backward in nonsense directions behind, a bug so common it is practically a rite of passage.

Singularities

Extend the arm perfectly straight, theta2 = 0, and reach for a target slightly farther out. It cannot get there, but that is not the interesting part. The interesting part is what happens to the mathematics: at full extension, the arm can still move sideways easily but has completely lost the ability to move outward, no matter what the joints do. That is a singularity: a configuration in which the arm loses one or more directions of instantaneous motion, and formally, where the Jacobian loses rank.

Singularities matter because of what they do to joint speeds. Near a singularity, achieving a modest tool velocity in the compromised direction requires enormous joint velocities, which the mathematics happily computes and the hardware cannot deliver. An arm asked to move in a straight line through a singular configuration will slow, then lurch as a joint attempts an impossible speed, and controllers typically detect the condition and stop with a fault rather than attempt it. The classic industrial case is the wrist singularity, where two wrist axes align, and the robot must spin one joint 180 degrees almost instantaneously to continue the path. Programmers avoid singularities by planning paths that steer around them, by adding redundancy, or by switching to joint-space motion where the exact tool path does not matter.

Add to this the plain reality of joint limits. A mathematically valid IK solution requiring the elbow to bend to 200 degrees is useless if the joint stops at 150. Real solvers check every returned solution against limits, discard the invalid ones, and choose from what remains, which sometimes means an apparently reachable point is not actually reachable by this robot in this pose.

Key idea: A singularity is a configuration where the arm loses a direction of motion and required joint speeds explode; full extension and aligned wrist axes are the classic cases, and joint limits further prune the valid solution set.

When there is no formula

Our two-link solution was closed-form: exact algebra, computed in microseconds. Six-jointed industrial arms with an intersecting spherical wrist also have closed-form solutions, worked out once per robot design, which is why they compute IK effortlessly thousands of times a second. But an arbitrary arm geometry, particularly a redundant one, often has no closed-form solution at all.

For those, robots use numerical inverse kinematics: start from the current joint angles, compute where the tool currently is with forward kinematics, measure the error to the target, use the Jacobian to work out which joint changes would reduce that error, take a small step, and repeat. It is hill climbing in joint space, converging in perhaps 5 to 50 iterations. The advantages are generality (it works for any geometry) and the ability to fold in extra objectives such as staying away from obstacles or joint limits, which is how redundancy gets exploited. The costs are that it needs a good starting guess, it can converge slowly or fail near singularities, and it returns one solution rather than the full set. Modern motion-planning libraries lean on these numerical methods heavily, and understanding that they are iterative rather than exact explains a great deal about how real robots behave, including why the same commanded pose can produce slightly different arm configurations on different runs.

Key idea: Closed-form IK exists for simple and well-designed arms, but general and redundant arms use iterative numerical solvers that follow the Jacobian downhill toward the target and can incorporate extra objectives.

Common misconceptions

• Inverse kinematics has one right answer. The two-link arm has two solutions for almost every reachable point, a six-DOF arm typically has up to eight, and redundant arms have infinitely many.
• If the target is within maximum reach, the arm can get there. The inner dead zone, joint limits, obstacles, and required tool orientation all shrink the truly reachable set well below the outer circle.
• Singularities are just points the arm cannot reach. They are usually reachable; the problem is that motion in certain directions demands impossible joint velocities near them, which is a control failure, not a reach failure.
• Numerical IK always finds the solution. Iterative solvers can stall in local minima, fail from a poor starting guess, or behave badly near singularities, and they return one solution rather than enumerating all of them.

Recap

• Inverse kinematics finds joint angles for a desired tool pose and may have zero, two, or infinitely many solutions.
• The two-link recipe: D = square root of (x squared + y squared), check reachability, then cos(theta2) = (x squared + y squared - L1 squared - L2 squared)/(2 L1 L2).
• theta1 = atan2(y, x) - atan2(L2 sin theta2, L1 + L2 cos theta2); for target (0.424, 0.490) with L1 = 0.40 and L2 = 0.30 this returns theta1 = 30.0 and theta2 = 44.9 degrees, matching the forward calculation.
• Always use atan2 rather than arctangent so all four quadrants resolve correctly.
• Singularities cost a direction of motion and demand explosive joint speeds; general and redundant arms rely on iterative numerical solvers guided by the Jacobian.

Sources

1. Wikipedia. (2025). Inverse kinematics. Wikimedia Foundation. en.wikipedia.org
2. Wikipedia. (2025). Singularity (robotics). Wikimedia Foundation. en.wikipedia.org
3. Khan Academy. (n.d.). Law of cosines. khanacademy.org
4. National Institute of Standards and Technology. (n.d.). Robotic systems performance measurement. NIST. nist.gov

The big picture

Build a small two-wheeled robot, add two downward-facing infrared sensors, put black tape on a white floor, and try to make the robot follow the tape. This is the traditional first project in every robotics club on Earth, and it is the perfect vehicle for the most important idea in control engineering. Your first attempt will almost certainly be: if the line is to the left, turn left; if it is to the right, turn right. That works, sort of. The robot follows the line while weaving drunkenly from side to side, hunting back and forth, never settling. By the end of this lesson you will know exactly why, and you will know the three-term fix that turns that wobbling machine into one that glides down the tape as if on rails.

The idea is feedback: measure the difference between what you want and what you have, and use that difference to decide what to do. It is the same loop your body runs to stand upright, the same one a thermostat runs, and the same one that lands rockets. In robotics it is unavoidable, because motors do not do exactly what they are told, floors have friction, batteries sag, and the world pushes back.

We will build up to PID control, work its arithmetic explicitly on a line follower, then talk honestly about tuning, which is a craft as much as a calculation, and about the two failure modes that trip up every beginner: integral windup and derivative noise.

Open loop versus closed loop

Open-loop control means commanding an action and hoping: send both motors 60 percent power for 2 seconds to drive one meter. It works exactly as well as your model of the world. Change the floor from tile to carpet, drop the battery from 12.4 V to 11.1 V, or add 200 grams of payload, and the distance changes and nothing notices. A microwave oven is open loop, running its timer regardless of whether the food is hot, and that is acceptable because the consequences of being wrong are mild.

Closed-loop control measures the result and corrects. Define the setpoint as the value you want, the process variable as what you measure, and the error as setpoint minus process variable. The controller's whole job is to compute an output that drives that error toward zero, continuously, forever. For our line follower, the setpoint is line centered under the robot, the process variable comes from the sensors, and the output is a steering correction applied as a difference between wheel speeds.

Set up the numbers concretely. Suppose an array of five infrared sensors under the robot reports the line's position as a number from -100 (line far left) through 0 (centered) to +100 (line far right). The setpoint is 0, so error = 0 minus reading, which means a line drifting right (+40) gives error -40. The controller must convert that error into a steering command that turns the robot right to recenter.

Key idea: Open-loop control commands blindly and fails when reality differs from the model; closed-loop control computes error as setpoint minus measurement and continuously acts to drive it toward zero.

Bang-bang and why it wobbles

The simplest closed-loop controller is bang-bang: if the error is positive, apply full correction one way; if negative, full correction the other. Your first line follower did this. It is cheap, needs no tuning, and is genuinely used in thermostats and refrigerators, where a little oscillation around the target costs nothing.

Its flaw is structural: the correction ignores the size of the error. A robot 2 millimeters off the line applies exactly as hard a turn as one 40 millimeters off, so it invariably overcorrects, sails past center, triggers the opposite full correction, and oscillates. That weaving is not a bug in your code; it is the mathematical signature of a controller that cannot be gentle. The fix is proportionality.

Proportional control

Proportional control makes the correction proportional to the error: output = Kp times error, where Kp is the proportional gain you choose. Small error, small nudge; large error, hard turn. Suddenly the robot eases onto the line instead of slamming toward it.

Work it. Say Kp = 0.8 and the sensor reports the line at +40 (drifted right), so error = -40. Output = 0.8 times -40 = -32, meaning apply 32 units of rightward steering. If the base speed of each motor is 150 units, the controller sets left motor = 150 - (-32) = 182 and right motor = 150 + (-32) = 118, clamped to the motor maximum. The robot curves right, the line drifts back toward center, the error shrinks, and the correction eases off automatically. That single line of code, output = Kp times error, is probably the highest value-per-character in all of robotics.

Proportional control has two characteristic weaknesses. First, gain selection is a real tradeoff: too small and the robot responds sluggishly and drifts wide on curves; too large and it overshoots and starts oscillating again, because a big correction is still being applied at the moment the robot crosses center. Second, and subtler, is steady-state error. Suppose the robot's right motor is slightly weaker, so it needs a constant small leftward correction just to go straight. With pure proportional control, that correction can only exist if some error exists to produce it, so the robot settles slightly off the line forever, with the residual error exactly big enough to generate the needed nudge. Proportional control cannot eliminate the very error it needs to function.

Key idea: Proportional control sets output = Kp times error, scaling the response to the size of the problem, but high gain causes overshoot and any persistent disturbance leaves a permanent steady-state error.

Adding integral and derivative

The integral term attacks steady-state error by accumulating it. Each cycle, add the current error to a running total, and include Ki times that total in the output. If the robot sits 3 units off the line, the sum grows by 3 every cycle, so the integral contribution grows steadily until it becomes large enough to push the robot back onto the line, at which point the error stops accumulating. In effect, the integral term remembers persistent bias and cancels it. Its cost is sluggishness and a tendency to overshoot, because that accumulated history keeps pushing even after the error reaches zero.

The derivative term looks forward instead of back, responding to how fast the error is changing: derivative = (current error minus previous error) divided by the time step, contributing Kd times that rate. When the robot is racing back toward the line, the error is shrinking fast, so the derivative term is large and opposes the motion, applying the brakes before the robot overshoots. Derivative acts as damping, and it is what lets you run a higher proportional gain without oscillation. Its cost is noise sensitivity: because it differentiates, a jittery sensor reading produces enormous spurious derivative output, which is why real controllers low-pass filter the measurement before differentiating it.

Put the three together and you have PID: output = Kp times error + Ki times (sum of errors times dt) + Kd times (change in error divided by dt).

Key idea: The proportional term responds to the present error, the integral term to accumulated past error (eliminating steady-state offset), and the derivative term to the error's rate of change (providing damping).

A PID line follower, computed by hand

Let us run three cycles explicitly. Gains: Kp = 0.8, Ki = 0.02, Kd = 4.0. Time step dt = 0.02 s (a 50 Hz loop). Base motor speed 150. Start with integral sum = 0 and previous error = 0.

Cycle 1. Sensor reads +40, so error = -40. Integral sum becomes 0 + (-40 times 0.02) = -0.8, contributing 0.02 times -0.8 = -0.016, essentially nothing yet. Derivative = (-40 - 0)/0.02 = -2,000, contributing 4.0 times -2,000 = -8,000, which is enormous. That spike is the well-known derivative kick that occurs when error jumps suddenly, and real code avoids it either by ramping the setpoint or by differentiating the measurement rather than the error. Suppose we use the standard fix and get a sane derivative contribution near -400 after filtering and clamping. Proportional term = 0.8 times -40 = -32. Total output, after the controller clamps its result to the motor range, is a hard right turn at full available correction.

Cycle 2. The robot has swung back, and the sensor now reads +10, so error = -10. Proportional = 0.8 times -10 = -8. Integral sum = -0.8 + (-10 times 0.02) = -1.0, contributing -0.02. Derivative = (-10 - (-40))/0.02 = +1,500, contributing 4.0 times 1,500 = +6,000 before filtering, or a modest positive damping term after it. Note the sign: the derivative term now opposes the correction, because the robot is closing on the line quickly and needs to slow its approach. That is damping doing exactly its job.

Cycle 3. Sensor reads -2 (slightly left), so error = +2. Proportional = +1.6. Integral sum = -1.0 + (2 times 0.02) = -0.96, contributing -0.019. Derivative = (2 - (-10))/0.02 = +600, a positive damping contribution. The total output is now small, and the robot is tracking the line with gentle corrections rather than lurching. Compare that with the bang-bang version, which would still be applying full correction at this instant.

Two practical notes the arithmetic just exposed. Because the derivative term divides by a small dt, its raw values dwarf the others, which is why Kd is small and filtering is mandatory. And because the integral accumulates slowly, Ki is small too; if you ever see Kp, Ki, and Kd of similar magnitude, something is probably wrong.

Key idea: Running PID by hand shows the terms trading roles: proportional dominates the initial correction, derivative supplies damping as the robot returns, and integral quietly removes persistent bias.

Tuning, and the two classic traps

Tuning means choosing Kp, Ki, and Kd, and the practical method is straightforward. Set Ki and Kd to zero. Raise Kp until the robot oscillates steadily around the line, then back it off to roughly half or two-thirds of that value. Add Kd, increasing it until the oscillation damps out and the approach to the line is crisp without becoming twitchy. Add Ki last, and only if the robot consistently settles slightly off center; keep it small. Change one gain at a time and watch what happens, because the interactions are strong.

Symptom	Likely cause	Fix
Slow, lazy correction, drifts wide on curves	Kp too low	Increase Kp
Fast weaving oscillation	Kp too high, Kd too low	Lower Kp, raise Kd
Settles consistently off center	Steady-state error, no integral action	Add a small Ki
Slow overshoot then correction	Ki too high	Lower Ki, consider clamping the sum
Twitchy, jittery steering	Kd amplifying sensor noise	Filter the measurement, lower Kd

Two failure modes deserve names. Integral windup happens when the error persists because the actuator is saturated: the robot has lost the line entirely, the motors are already at full correction, and the integral sum grows and grows. When the line finally reappears, that enormous accumulated sum keeps driving the robot hard past center for a long time before it unwinds. The standard fixes are to clamp the integral sum to a maximum, to stop accumulating whenever the output is saturated, or to reset the sum when the error changes sign. Derivative noise amplification is the mirror problem: sensors jitter, differentiation amplifies jitter, and the steering twitches. Filter first, differentiate second.

Finally, a word about stability, which is the deep reason all this care is necessary. A control loop is stable if disturbances die out and unstable if they grow. The danger comes from delay: every loop takes time to sense, compute, and act, and if the correction arrives late enough that it is pushing the wrong way by the time it lands, high gain amplifies the error instead of reducing it, and oscillations grow until something breaks. This is why fast control loops are so valuable (less delay per cycle), why aggressive gains destabilize sluggish systems, and why a robot that behaves perfectly at 200 Hz can shake itself apart at 20 Hz with identical gains. The formal treatment belongs to a control theory course; the intuition, correct in time or wrong in effect, belongs here.

Key idea: Tune Kp first, then Kd for damping, then a small Ki for offset; guard against integral windup and derivative noise, and remember that loop delay plus high gain is the recipe for instability.

Common misconceptions

• More proportional gain always means better tracking. Past a point, higher Kp produces overshoot and then growing oscillation, because the correction is still large as the robot crosses the target.
• Every controller needs all three terms. Plenty of excellent robot controllers are P or PD only. The integral term is added specifically to kill steady-state offset and often causes more trouble than it solves.
• The derivative term predicts the future. It responds to the current rate of change, which acts like damping; it is not a forecast, and it is extremely sensitive to sensor noise.
• PID gains transfer between robots. Gains depend on mass, sensor scaling, loop rate, and motor characteristics, so gains from another robot are at best a starting point.

Recap

• Open-loop control commands without checking; closed-loop control acts on error = setpoint minus measurement.
• Bang-bang control oscillates because its correction ignores error size; proportional control (output = Kp times error) scales the response.
• Proportional alone leaves steady-state error; the integral term accumulates error to remove it, and the derivative term damps the approach.
• Full PID: output = Kp times error + Ki times sum(error times dt) + Kd times (change in error)/dt, worked here at 50 Hz with Kp = 0.8, Ki = 0.02, Kd = 4.0.
• Tune Kp, then Kd, then a small Ki; clamp the integral to prevent windup, filter before differentiating, and remember that delay plus high gain equals instability.

Sources

1. Wikipedia. (2025). PID controller. Wikimedia Foundation. en.wikipedia.org
2. Britannica. (2024). Control system. In Encyclopaedia Britannica. britannica.com
3. National Institute of Standards and Technology. (n.d.). Control systems and robotics measurement. NIST. nist.gov
4. NASA. (n.d.). Guidance, navigation, and control. NASA Technical Reports Server. ntrs.nasa.gov

The big picture

Try this. Stand in a room you know well, close your eyes, and walk ten steps forward, turn left, walk five more, turn right, walk three. Now, still with your eyes closed, point to the door. Most people are off by a considerable margin, and the longer the walk, the worse it gets. You just experienced the central problem of robot navigation, and you experienced it with a biological sensor suite far better than anything on a $500 robot.

Every mobile robot faces this question continuously: where am I? Module 3 gave you odometry, the estimate built by integrating wheel motion, and warned that it drifts. This lesson makes that warning quantitative, then builds the standard solution, which is to correct the drifting internal estimate with external observations of the world. That is localization. Then we take away the map, which is where most real robots start, and confront the problem of building a map while simultaneously using it to figure out where you are. That is SLAM, simultaneous localization and mapping, and it is the technology inside every mapping robot vacuum you can buy today.

Along the way you will meet the single most beautiful idea in mobile robotics, loop closure, which is what happens when a robot recognizes a place it has seen before and, in one stroke, corrects an entire history of accumulated error.

How bad is odometry, really?

Let us put numbers on the drift. Two error sources dominate. Systematic errors are consistent biases: unequal wheel diameters, an incorrect assumed wheelbase, tire wear. Non-systematic errors are random: wheel slip on a slick patch, bumping a threshold, one wheel riding up a cable.

Work the systematic case first, because it is the one people underestimate. Suppose your wheels are nominally 65.0 mm in diameter but the right one is actually 65.5 mm, a manufacturing difference under one percent that you would never notice by eye. Over one wheel rotation, the right wheel travels pi times 65.5 = 205.8 mm while the left travels pi times 65.0 = 204.2 mm, a difference of 1.6 mm. Feed that into the differential drive equation with a 250 mm wheelbase: heading change per wheel revolution = 1.6/250 = 0.0064 radians, about 0.37 degrees. That happens every single wheel revolution. After 20 revolutions, roughly 4 meters of travel, the robot has quietly turned 7.3 degrees while believing it drove perfectly straight. At the end of a 10 meter hallway it is heading about 18 degrees off and its position estimate is more than a meter wrong.

Notice what that example proves: heading error is the dangerous kind. A 1 percent distance error over 10 meters costs you 10 centimeters. A 5 degree heading error over the same 10 meters costs you 10 times sin(5 degrees) = 0.87 meters, nearly nine times worse, and unlike distance error it keeps compounding as you continue. This is why calibration procedures for mobile robots focus obsessively on the wheelbase and wheel diameter ratio, and why any robot expected to travel more than a few meters needs an external reference.

Add non-systematic error and it gets worse in a different way. Slip is unpredictable, so it cannot be calibrated out; it can only be detected by comparing wheel odometry against something else, such as a gyroscope's measured rotation or a lidar's view of the world. A robot whose wheels report a 30 degree turn while its gyro reports 12 degrees has just learned that it was slipping, which is more useful than either sensor alone.

Key idea: Odometry error accumulates without bound, and heading error dominates: a half-millimeter wheel diameter mismatch turns into 0.37 degrees per wheel revolution, and 5 degrees of heading error costs 0.87 m of position after just 10 m of travel.

Localization: fixing drift against a map

The cure is external reference. If the robot has a map, then every lidar scan or camera view is evidence about where it must be standing: a scan showing a wall 2 m ahead and a corner 3 m to the left is consistent with only a few positions in a known floor plan. Localization is the process of matching observations to the map to estimate the robot's pose.

The standard method is beautifully intuitive: the particle filter, also called Monte Carlo localization. Instead of tracking one estimated pose, the robot tracks a cloud of hundreds or thousands of hypotheses, each a guess about where it might be. The algorithm loops three steps forever. Predict: move every particle according to the odometry, adding a little random noise because odometry is imperfect. Weight: for each particle, ask how well the actual sensor reading matches what the robot would see if it were really there, and give better matches higher weight. Resample: draw a new set of particles, favoring the heavy ones, so hypotheses that explain the data multiply and those that do not die out.

Watch what this produces. At startup with no idea where it is, the particles scatter across the entire map. As the robot drives and observes, hypotheses inconsistent with the walls it sees vanish, and the cloud collapses, sometimes into two or three clusters if the building has identical-looking corridors, then finally into a single tight blob around the true pose. The cloud's spread is itself useful information: a tight cloud means confident localization, a spread-out cloud means the robot honestly does not know, which is exactly the kind of self-knowledge a safe robot needs. Particle filters handle the multiple-hypothesis case naturally, which is why they became the workhorse of indoor robot localization.

Key idea: Localization corrects drifting odometry by matching sensor observations to a known map; a particle filter maintains many pose hypotheses, weights them by how well they explain the data, and resamples so good hypotheses survive.

SLAM: the chicken and the egg

Localization assumed a map. Most robots do not have one. Handing your new vacuum a floor plan of your house is not a product anyone would buy, so the robot must build its own map, and here is the trap: to build a good map you need to know where you are when you take each measurement, and to know where you are you need a good map. Each requires the other. That circularity is the core difficulty of SLAM, simultaneous localization and mapping.

The resolution is to solve both at once as a single large estimation problem. A modern SLAM system extracts recognizable features from sensor data, walls and corners from lidar, distinctive visual patterns from cameras, and builds a graph: nodes are robot poses at different times, and edges are measured relationships between them, some from odometry (I moved about 30 cm forward between these two poses) and some from observations (from both of these poses I saw the same corner in these relative positions). Then an optimizer finds the arrangement of poses that best satisfies all the constraints at once, minimizing total disagreement. This graph-based formulation is why SLAM is often described as a big least-squares problem rather than a filter.

The magic ingredient is loop closure. Suppose the robot drives a long circuit around a floor and arrives back near its starting point. Odometry says it is 1.8 meters away from where it began, because error accumulated the whole way. But the sensors recognize the starting location, so the system adds a powerful new constraint: these two poses are actually the same place. The optimizer then redistributes that 1.8 meter error backward across the entire loop, nudging every pose in the history slightly, and the map snaps from a drifting spiral into a closed, consistent floor plan. If you have watched a mapping robot vacuum's app while it works, you have seen this happen: the map looks slightly skewed, and then suddenly it straightens. That is loop closure firing.

Key idea: SLAM solves localization and mapping together as one optimization over a graph of poses and constraints, and loop closure, recognizing a previously visited place, retroactively corrects the entire accumulated trajectory.

Where SLAM breaks

SLAM is a genuine success story, cheap enough now that a $300 vacuum runs it, but it is not magic, and knowing its failure modes tells you a lot about robot behavior you may have witnessed.

The first enemy is perceptual aliasing: places that look identical. A long featureless corridor gives a lidar nothing to distinguish position along its length, so the robot's estimate slides. Rows of identical office doors, warehouse aisles, and hotel hallways are notorious. Worse, aliasing can cause a false loop closure, where the system decides two different places are the same, which corrupts the entire map at once and is far more damaging than missing a true closure. Modern systems therefore demand strong evidence before accepting a closure.

The second enemy is change. SLAM's mathematics generally assumes a static world, but real environments move: people walk through, chairs shift, doors open and close. Good systems filter transient objects and update maps over time, but a room rearranged between sessions can leave a robot confidently lost. The third is sensor-specific: glass walls that lidar sees through, dark or reflective surfaces, dim lighting for visual SLAM, and featureless white rooms. The fourth is computational, since large maps and long histories cost memory and processing, which is why consumer robots limit map size and simplify aggressively.

Finally, note the honest engineering answer that Module 1 foreshadowed: sometimes the winning move is to avoid SLAM entirely by structuring the environment. Warehouse robots navigate a grid of floor barcodes; factory AGVs follow magnetic tape or wire in the floor; some systems use reflective markers at known positions. That is not a failure of ambition, it is good engineering: if you control the building, imposing structure is cheaper and vastly more reliable than solving perception in general.

Key idea: SLAM fails on perceptual aliasing, changing environments, glass and low-texture scenes, and unbounded computation, which is why commercial systems often add structure such as floor markers rather than relying on perception alone.

Approach	Needs a map?	Error behavior	Typical use
Odometry alone	No	Grows without bound	Short moves between corrections
Odometry plus IMU	No	Grows more slowly; detects slip	Dead reckoning between fixes
Localization (particle filter)	Yes, known map	Bounded by map accuracy	Warehouse and service robots
SLAM	No, builds one	Bounded after loop closure	Mapping vacuums, exploration
Markers or floor barcodes	Engineered map	Very small, bounded	Warehouses, factory AGVs

Common misconceptions

• Better encoders would fix odometry drift. The dominant errors are wheel diameter mismatch, wheelbase error, and slip, none of which higher counting resolution addresses at all.
• Distance error and heading error are equally serious. Heading error is far worse, because its position consequence grows with every meter you subsequently travel.
• A particle filter tracks the robot's single best guess. It deliberately maintains many hypotheses, and the spread of that cloud is a meaningful measure of the robot's own uncertainty.
• Once a robot has run SLAM, it knows the building permanently. Maps age. Furniture moves, doors change state, and a rearranged room can leave a robot confidently mislocalized against its own stale map.

Recap

• Odometry drifts without bound; a 0.5 mm wheel diameter mismatch produces about 0.37 degrees of heading error per wheel revolution.
• Heading error dominates: 5 degrees of heading error costs about 0.87 m of position after 10 m of travel, and it compounds with distance.
• Localization matches observations to a known map, most commonly with a particle filter that predicts, weights, and resamples pose hypotheses.
• SLAM solves mapping and localization together as a graph optimization, and loop closure retroactively corrects the whole trajectory when a place is recognized.
• SLAM breaks on perceptual aliasing, dynamic environments, glass and low-texture scenes, and computation limits, so engineered markers remain common in industry.

Sources

1. Wikipedia. (2025). Simultaneous localization and mapping. Wikimedia Foundation. en.wikipedia.org
2. NASA Jet Propulsion Laboratory. (n.d.). Rover navigation and visual odometry. NASA JPL. jpl.nasa.gov
3. National Institute of Standards and Technology. (n.d.). Navigation and mapping performance for mobile robots. NIST. nist.gov
4. IEEE Spectrum. (n.d.). Robotics coverage. IEEE. spectrum.ieee.org

The big picture

Your robot now knows where it is. Two questions remain, and they are the hardest in the field: what is out there, and what should I do about it? This lesson takes both. First vision, the process of turning a matrix of brightness numbers into statements about the world such as there is a red cup 40 centimeters ahead. Then planning, the process of turning a goal into a sequence of motions that gets there without hitting anything. Then architecture, the question of how all these pieces are organized into a robot that behaves sensibly.

These topics could each fill a course, so our aim is working understanding rather than implementation: enough to read a robotics paper, evaluate a product claim, and know which technique fits which problem. And we will end with the question everybody asks now, which is what artificial intelligence and machine learning actually contribute to robots. The honest answer is more interesting than either the hype or the dismissal, and it follows directly from Moravec's paradox in Lesson 1.

From pixels to meaning

Remember that an image is a grid of numbers. Computer vision is the discipline of extracting structure from that grid, and it proceeds in stages, each throwing away data while adding meaning.

The cheapest useful operation is thresholding: classify every pixel as foreground or background by comparing it to a cutoff. Our line follower did exactly this, calling anything darker than a threshold line. Color thresholding extends the trick, and works far better in HSV space (hue, saturation, value) than in raw red-green-blue, because hue stays roughly constant as lighting brightens and dims while RGB values all shift together. A robot hunting an orange ball asks for pixels whose hue lies in the orange band, then computes the centroid of the matching region, the average x and y of those pixels, which gives a target direction in one step. This is real, deployed technology: color blob tracking runs on microcontrollers and remains the right answer for constrained tasks.

Next comes edge detection. An edge is a place where brightness changes sharply, and since object boundaries usually produce such changes, edges compress an image into a sketch. Operators like Sobel compute brightness gradients; the Canny detector adds noise smoothing, thinning, and thresholding to produce clean single-pixel contours. From edges you can find lines and circles, which is enough to locate a rectangular part on a conveyor or read the position of a pallet.

Beyond edges lie features: small distinctive patches, usually corners, that can be recognized again from a different angle or distance. Feature detectors such as ORB find hundreds per image and describe each one so that the same physical corner can be matched between two views. Feature matching is what makes visual odometry and visual SLAM possible, and it is why a camera-based robot can recognize that it has returned to a place it saw before. Finally, at the top of the stack, convolutional neural networks take on classification and detection, answering not just where is the edge but what is that object, with the caveats we will discuss shortly.

One vision technique deserves special mention for its practical importance: the fiducial marker, a printed pattern such as an AprilTag or ArUco tag. A camera can detect one reliably in milliseconds and recover not just its identity but its full six-degree-of-freedom pose relative to the camera, with centimeter accuracy. Tape a few tags to walls, shelves, or workpieces and an enormous amount of perception difficulty simply evaporates. This is Module 1's structure lesson wearing a paper hat, and it is how many working robots avoid needing general vision at all.

Key idea: Vision proceeds from thresholding and color blobs, through edges, to matchable features and learned detectors; fiducial markers sidestep much of the difficulty by adding structure the camera can read reliably.

Path planning on a grid

Now the second question. Given a map, a start, and a goal, find a path. The standard first move is to discretize: overlay the map with a grid of cells, mark cells containing obstacles as blocked, and treat the rest as a graph where each free cell connects to its neighbors. A 10 by 10 meter room at 5 centimeter resolution becomes a 200 by 200 grid, 40,000 cells, which any modern processor searches in milliseconds.

The workhorse algorithm is A* (pronounced A star), the one invented for Shakey in 1968. A* explores outward from the start, but instead of expanding blindly in all directions like Dijkstra's algorithm, it prioritizes cells by the score f = g + h, where g is the actual cost to reach this cell from the start and h is a heuristic estimate of the remaining cost to the goal, usually the straight-line distance. The effect is a search that bulges toward the goal rather than spreading evenly, often examining a small fraction of the cells Dijkstra would.

Trace it concretely. Start at cell (0,0), goal at (9,0), with a wall of blocked cells at x = 4 spanning y = -2 to +2. A* first pushes straight along the x axis because h keeps shrinking, hits the wall at (3,0), and now must expand sideways. The cells at (3,1) and (3,-1) have slightly higher g (a detour costs distance) and slightly higher h, so they wait while the frontier tries alternatives, but as everything else proves worse they get expanded, then (3,2) and (3,-2), and eventually a cell past the wall's edge opens the way around. A* returns the shortest path around the wall, and it is guaranteed to do so as long as the heuristic never overestimates the true remaining cost, a property called admissibility. Straight-line distance is admissible because no path can be shorter than a straight line.

Two practical adjustments matter. First, a path that scrapes obstacle corners is unsafe for a robot with physical width, so planners inflate obstacles by the robot's radius before searching, which converts the robot into a point and bakes clearance into the map. Second, grid paths are jagged, full of 45 degree zigzags, so a smoothing step or a planner working in continuous space produces motion a wheeled robot can actually follow. Sampling-based planners such as RRT (rapidly exploring random trees) handle high-dimensional problems like a six-jointed arm in cluttered space, where a grid over all six joint angles would be astronomically large.

Key idea: A* searches a grid using f = g + h, where g is cost so far and h is an admissible estimate of remaining cost, finding shortest paths efficiently; real planners inflate obstacles by robot radius and smooth the resulting path.

Potential fields and their trap

A completely different approach skips search entirely. In the potential field method, the goal exerts an attractive force on the robot and every obstacle exerts a repulsive force that grows as the robot gets closer. Each control cycle, sum all the forces and drive in the direction of the total. It is elegant, extremely cheap to compute, works directly from live sensor readings without any map, and handles moving obstacles naturally, since a person walking toward the robot simply pushes it aside.

It also has a famous fatal flaw: local minima. Picture a robot approaching a U-shaped obstacle with the goal beyond it. Entering the concavity, the goal pulls forward while the two side walls push inward from both sides and the back wall pushes backward. At some point these forces cancel exactly. The robot stops, or oscillates, permanently stuck in a place that is not the goal, with no mechanism to recognize that backing out is necessary. No amount of gain tuning fixes this, because it is a property of the field, not the tuning.

So the practical answer, used by essentially every real mobile robot, is a two-layer system. A global planner such as A* runs on the map and produces a route, exploiting its ability to reason about the whole environment and escape traps. A local planner such as a potential field or the dynamic window approach runs at high rate on live sensor data, following that route while dodging the pedestrian who just stepped out, and calling for a replan if it gets stuck. Global planning for the shape of the journey, local reaction for the surprises: that division of labor is one of the most durable patterns in the field.

Key idea: Potential fields navigate by summing attraction to the goal and repulsion from obstacles, which is cheap and map-free but traps the robot in local minima, so real systems pair a global search planner with a local reactive one.

Behavior architectures

Zoom out to how a robot's whole software is organized. The original approach, from Shakey's era, is the deliberative or sense-plan-act architecture: build a complete world model, reason about it, produce a plan, then execute. It is powerful for complex goals and it is what lets a robot decide to fetch the wrench from the far bench before assembling. It is also slow, and it fails badly when the world changes while the robot is still thinking.

In 1986 Rodney Brooks attacked this directly with the subsumption architecture, arguing that robots should not build world models at all. Instead, stack simple behaviors that connect sensors almost directly to actuators: a lowest layer that avoids obstacles, above it a layer that wanders, above that a layer that explores. Higher layers work by suppressing lower ones when appropriate, and no layer maintains a model. Brooks summarized the philosophy in the slogan that the world is its own best model, meaning the robot should just look again rather than remembering. Reactive robots built this way are fast, robust, and cheap, and the Roomba is the commercial vindication of the idea: it has no map in its basic form, just behaviors, and it cleans your floor.

Reactive systems cannot plan, though. A purely reactive robot cannot decide to go around the building because the direct route is blocked, because it has no representation of the building. So modern practice is hybrid: a deliberative layer that plans slowly over a model, a reactive layer that responds in milliseconds to sensor events, and a middle executive layer that sequences tasks, monitors progress, and triggers replanning when reality departs from the plan. A Mars rover is exactly this: a plan uplinked from Earth, an onboard executive that carries out the day's sequence, and fast reactive hazard checks that stop the rover if a wheel encounters something unexpected. Modern practice often expresses the middle layer as a behavior tree, a structure borrowed from video games that makes complex conditional behavior readable and easy to modify.

Key idea: Deliberative architectures plan over world models but respond slowly, reactive architectures like subsumption respond instantly but cannot plan, and virtually all real robots are hybrids with fast reactive layers under a slower deliberative one.

What machine learning actually contributes

Now the sober assessment. Machine learning has genuinely transformed one part of robotics: perception. Object detection and classification from images, which resisted decades of hand-written rules, was substantially solved by convolutional networks trained on large labeled datasets. Grasp-point prediction, deciding where on an unfamiliar object to place the gripper, improved dramatically through learning from large numbers of grasp attempts. Speech interfaces and semantic scene understanding likewise rest on learned models. Any robot that must recognize arbitrary objects in unstructured settings uses learning today.

The picture in control and motion is more mixed, and it pays to be precise about why. Classical control theory offers something learning generally cannot: guarantees. You can prove a PID loop's stability margins; you cannot prove much about a neural network policy's behavior on inputs it never saw. Physical trial and error is also expensive and slow, since a robot arm that must break 500 objects to learn a grasp is a poor investment, which is why so much learning happens in simulation and then confronts the sim-to-real gap, the collection of differences in friction, compliance, sensor noise, and lighting that make simulated success fail on hardware. Techniques like domain randomization, deliberately varying simulated physics and appearance so the policy cannot depend on any one setting, have narrowed that gap significantly but not closed it.

So the honest summary as of the mid-2020s: robots overwhelmingly run classical control loops and classical planners with learned perception on top, plus a growing but still limited set of learned skills for tasks that resist analysis, mostly contact-rich manipulation. Learning has not repealed kinematics, PID, or A*; it has supplied the piece those methods always lacked, which is robust interpretation of messy sensory data. Watch this space with interest and skepticism in equal measure, and when you see a demonstration, ask the questions Lesson 1 gave you: what task, what environment, how many takes, and what happens when the lighting changes.

Key idea: Machine learning has largely solved robot perception and is advancing contact-rich manipulation, but classical control and planning still run most robot motion because they offer guarantees, and the sim-to-real gap remains a real obstacle.

Common misconceptions

• A* finds the path fastest because it is smarter about obstacles. A* is fast because its heuristic biases search toward the goal; with a zero heuristic it degenerates exactly into Dijkstra's algorithm.
• Potential fields just need better tuning to escape traps. Local minima are structural: forces genuinely cancel inside concave obstacles, and no gain adjustment removes that equilibrium.
• Reactive robots are primitive compared with planning ones. Reactive layers provide the millisecond responses that keep robots safe; the best systems combine both rather than choosing.
• Modern robots are mostly neural networks now. Perception is largely learned; motion control and planning remain overwhelmingly classical because they need provable stability and predictable behavior.

Recap

• Vision builds from thresholding and color blob centroids, through edge detection, to matchable features and learned detectors, with fiducial markers offering reliable pose in milliseconds.
• A* searches a grid with f = g + h and an admissible heuristic; planners inflate obstacles by the robot's radius and smooth jagged grid paths.
• Potential fields sum attraction and repulsion for cheap map-free navigation but get trapped in local minima inside concave obstacles.
• Real robots pair a global planner for route shape with a fast local planner for surprises, under hybrid architectures combining deliberative and reactive layers.
• Machine learning dominates perception and is improving manipulation, while classical control and planning still govern motion because they provide guarantees; the sim-to-real gap remains significant.

Sources

1. Wikipedia. (2025). A* search algorithm. Wikimedia Foundation. en.wikipedia.org
2. Wikipedia. (2025). Subsumption architecture. Wikimedia Foundation. en.wikipedia.org
3. NASA Jet Propulsion Laboratory. (n.d.). Autonomous navigation for planetary rovers. NASA JPL. jpl.nasa.gov
4. IEEE Spectrum. (n.d.). Artificial intelligence and robotics coverage. IEEE. spectrum.ieee.org

The big picture

Everything so far has been the physics and mathematics of robots. This lesson is about the practice: how engineers actually make these machines do useful work, and what the machines that already do useful work are really like. If you have absorbed the earlier modules, you now have the vocabulary to look inside a surgical robot or a Mars rover and understand what you are seeing, which is exactly what we are going to do.

We start with programming, because the way you tell a robot what to do differs enormously depending on the robot. A factory arm is programmed by leading it through motions with a handheld pendant. A research robot is programmed in C++ or Python against a middleware framework. A warehouse fleet is not programmed at all in the individual sense; it is dispatched by a central system that treats robots as interchangeable resources. Then we cover simulation, and then four case studies chosen because each illustrates a different lesson from this course. We end with safety, which in this field is not a formality but the reason certain machines are built the way they are.

How robots are programmed

The oldest method is still the most common on factory floors: teach pendant programming. A technician holds a rugged handheld console with a screen, a joystick, and an enable switch, jogs the arm to a position, and presses a button to record that pose. Repeat for each waypoint, add commands for the gripper and for waiting on signals, and you have a program that is essentially a list of positions with actions between them, the direct descendant of Unimate's magnetic drum. The advantages are enormous in context: the technician needs no programming background, the taught positions are exactly correct in the real cell (sidestepping the accuracy problem from Module 1, since repeatability is what matters), and the whole process takes hours rather than weeks. The disadvantage is equally clear: the robot must be stopped and the cell occupied while teaching, which for a busy production line is expensive downtime.

Offline programming moves the work to a computer. A CAD model of the cell, the parts, and the robot lets an engineer generate paths, simulate reach and collisions, and verify cycle times without touching the hardware. This is standard for complex applications such as painting car bodies or welding long seams, where hand-teaching hundreds of points would be impractical. The catch is calibration: the simulated world must match the physical one, and since the real cell always differs by a few millimeters, offline programs require a touch-up step on the actual robot, using measured reference points to correct the model.

Research and modern service robots use a third approach: general-purpose programming against a framework, overwhelmingly ROS, the Robot Operating System, first released by Willow Garage in 2007 and now maintained as ROS 2 by the Open Source Robotics Foundation. ROS is not an operating system; it is middleware plus a huge ecosystem. Its organizing idea is simple and powerful: a robot's software is a set of independent programs called nodes, each doing one job (read the lidar, run the localizer, plan a path, drive the motors), which communicate by publishing and subscribing to named message streams called topics. A node that publishes laser scans neither knows nor cares who reads them, so you can swap a simulated lidar for a real one without changing a line in the mapper.

What ROS really provides is community. Drivers for hundreds of sensors, mature implementations of SLAM, navigation, and motion planning, tools for recording and replaying all the data from a run, and a visualizer that displays everything the robot believes about the world in 3D. Before ROS, every lab rewrote all of it; that duplicated effort is the waste ROS eliminated, and its arrival in 2007 is a genuine turning point in the field's productivity. It is worth knowing the limits too: ROS 1 was not designed for hard real-time control or for security, which is why safety-critical inner loops usually run on separate microcontrollers, and why ROS 2 was rebuilt on an industrial communications standard with real-time and security in mind.

Key idea: Factory arms are taught by pendant or programmed offline from CAD with a calibration touch-up, while research and service robots use ROS, whose node-and-topic model plus shared drivers and algorithms transformed the field's productivity.

Simulation: indispensable and misleading

Simulators such as Gazebo, Webots, and Isaac Sim model a robot's physics, sensors, and environment well enough to develop and test software without hardware. The benefits are real and large. You can crash a simulated robot a thousand times before lunch at zero cost. You can test scenarios that are dangerous or rare in reality, such as a pedestrian stepping out from behind a van. You can run experiments faster than real time, and you can run thousands in parallel, which is what makes learning-based methods tractable at all. And you can develop software before the hardware exists, which is routine practice on serious programs.

The danger is the sim-to-real gap from the last lesson, and it is worth naming exactly what simulators get wrong. Friction and contact are modeled crudely, and contact is precisely what manipulation is about. Compliance and backlash in real gearboxes are often ignored. Sensor noise is usually cleaner in simulation than in life, and simulated cameras rarely reproduce glare, motion blur, or the peculiar way a real lidar behaves against a glass wall. Timing is deterministic in simulation and jittery in reality. The result is a well-known trap: software that works flawlessly in simulation and fails immediately on hardware, usually at the first real contact. Experienced teams treat simulation as necessary but never sufficient, add deliberate noise and randomization so their code cannot depend on a perfect world, and reserve final judgment for the physical machine.

Key idea: Simulation makes development fast, safe, and parallel, but it models friction, contact, compliance, sensor noise, and timing imperfectly, so results must always be confirmed on hardware.

Four case studies

The industrial arm. A six-axis welding robot on an automotive line is the field's economic bedrock. It carries perhaps 150 kg, repeats to 0.05 mm, and runs three shifts a day for a decade with scheduled maintenance. It is usually blind, since the fixtures guarantee part position, and it is programmed by pendant. Its intelligence is minimal and its reliability is extraordinary, and that tradeoff is deliberate: in a structured environment, reliability is worth vastly more than cleverness. When you hear that industry deploys about half a million new industrial robots per year, this is the machine being counted.

The warehouse fleet. Amazon Robotics, descended from Kiva, operates more than 750,000 mobile units. Each drives under a shelving pod, lifts it, and carries it to a station where a human picks the item, navigating a concrete floor gridded with fiducial stickers. Notice how many of this course's lessons converge here: differential drive, fiducial markers for localization, a central planner routing hundreds of units to avoid deadlock, and above all the Kiva insight that imposing structure beats solving perception. There is no general vision, no grasping, no SLAM. That is why it works at that scale.

The surgical robot. Intuitive Surgical's da Vinci system, first cleared by the FDA in 2000, is a teleoperated master-slave device: the surgeon sits at a console viewing a magnified 3D endoscopic image and moves two hand controllers, while four arms reproduce those motions inside the patient through incisions around a centimeter wide. The system contributes three things, and it is worth being precise. It filters physiological hand tremor. It scales motion, so a centimeter of hand movement can become a few millimeters of instrument movement. And its wristed instruments articulate inside the body in ways a rigid laparoscopic tool cannot. It decides nothing. Over 10 million procedures have now been performed with these systems, and the honest research picture is mixed by procedure: strong benefits in some operations, comparable outcomes to skilled laparoscopy in others, at higher equipment cost.

The planetary rover. NASA's Perseverance rover landed on Mars in February 2021 carrying the lessons of every previous mission. It uses a rocker-bogie suspension so six wheels can crawl over obstacles as tall as a wheel while keeping all of them on the ground. Because the one-way light delay runs from about 3 to 22 minutes, Earth cannot drive it; instead, engineers uplink a daily plan and onboard software executes it, using visual odometry (matching features between successive stereo image pairs to measure actual motion over slippery sand, where wheel odometry lies badly) and autonomous navigation software that builds a local terrain map and plans safe paths. Its 2-meter, five-degree-of-freedom arm places instruments against rocks and cores samples. Power comes from a radioisotope generator producing about 110 watts, which shapes everything: this is a robot whose whole computer budget is a fraction of a laptop's, running the most demanding autonomy in the solar system. Its companion Ingenuity, a 1.8 kg helicopter, made the first powered flight on another world in April 2021 and flew 72 times before its rotor was damaged in January 2024.

Key idea: The four archetypes trade autonomy differently: industrial arms buy reliability with structure, warehouse fleets replace perception with engineered markers, surgical robots amplify a human who decides everything, and rovers run supervised autonomy because physics forbids teleoperation.

Safety: the rules written in consequence

Module 1 recounted the 1979 death of Robert Williams and the 1981 death of Kenji Urada. The industry's response became a body of standards you should know by name. ISO 10218 covers safety requirements for industrial robots and their integration, and the American national standard ANSI/RIA R15.06 adopts it. The traditional protective scheme it codifies is physical separation: fixed guards and fences, interlocked gates that command a stop when opened, light curtains and laser scanners that detect entry, and emergency stop circuits designed so that a single component failure cannot defeat them. Alongside these sits the practice of lockout-tagout, in which a worker servicing a machine physically locks its energy sources off and keeps the only key, which exists precisely because Urada was killed while servicing a robot that had not been powered down.

Collaborative robots forced a genuine rethink, because the whole point of a cobot is that there is no fence. The technical specification ISO/TS 15066 supplies the missing piece by defining four collaborative modes: safety-rated monitored stop (the robot halts while a person is in the shared space), hand guiding (the operator moves the arm directly using a device with an enabling switch), speed and separation monitoring (the robot slows as a person approaches and stops if they get too close), and power and force limiting (the robot is designed so any contact stays below documented pain and injury thresholds, which the specification tabulates by body region). The last mode is what allows a cobot to touch a person at all, and it is the reason cobots are typically slower and lighter than caged arms.

Two crucial points about all of this. First, safety is a property of the application, not the robot: a force-limited cobot holding a knife or a welding torch is not safe, so every installation requires its own risk assessment. Second, the standards are functional, not aspirational; they specify measurable forces, reaction times, and failure behaviors that can be verified, which is why they work where Asimov's Three Laws could not.

Key idea: ISO 10218 codifies guarding, interlocks, and emergency stops for caged industrial robots, ISO/TS 15066 defines four collaborative modes including power and force limiting with documented injury thresholds, and safety always depends on the specific application.

System	Autonomy	Key enabling idea	Scale
Industrial welding arm	None, replays taught path	Structured cell, high repeatability	About 4.3 million in service
Amazon warehouse unit	Fleet-dispatched navigation	Fiducial floor grid, shelves to humans	Over 750,000 deployed
da Vinci surgical system	Teleoperated only	Tremor filtering, motion scaling, wristed tools	Over 10 million procedures
Perseverance rover	Supervised autonomy	Visual odometry, onboard hazard avoidance	One, on Mars

Common misconceptions

• Industrial robots are programmed by writing code. Most are taught by physically jogging the arm through positions with a pendant, and the resulting program is essentially a list of poses and actions.
• The da Vinci robot performs surgery. It reproduces a surgeon's hand motions with tremor filtering and motion scaling; every decision and motion originates with the human at the console.
• If it works in simulation it will work on the robot. Friction, contact, compliance, sensor noise, and timing all differ, and contact-rich tasks fail on hardware most often.
• Collaborative robots are inherently safe. Safety belongs to the application: a force-limited arm holding a sharp or hot tool is dangerous, which is why every installation requires a risk assessment.

Recap

• Teach pendants dominate factory programming, offline CAD programming handles complex paths with a calibration touch-up, and ROS 2 supports research and service robots through nodes, topics, and shared algorithms.
• Simulation is essential for speed, safety, and parallel experimentation but misrepresents friction, contact, compliance, noise, and timing.
• Industrial arms trade intelligence for reliability in structured cells; Amazon's 750,000-plus units bring shelves to people over a fiducial grid.
• The da Vinci system is purely teleoperated, contributing tremor filtering, motion scaling, and wristed instruments across more than 10 million procedures.
• Perseverance runs supervised autonomy with visual odometry on about 110 watts, and safety standards ISO 10218 and ISO/TS 15066 define guarding and the four collaborative modes.

Sources

1. NASA. (n.d.). Mars 2020 Perseverance rover. NASA Mars Exploration Program. mars.nasa.gov
2. NASA Jet Propulsion Laboratory. (n.d.). Ingenuity Mars helicopter. NASA JPL. jpl.nasa.gov
3. Occupational Safety and Health Administration. (n.d.). Robotics safety and control of hazardous energy. US Department of Labor. osha.gov
4. National Institute of Standards and Technology. (n.d.). Collaborative robotics and safety performance. NIST. nist.gov
5. IEEE Spectrum. (n.d.). Industrial and medical robotics coverage. IEEE. spectrum.ieee.org

The big picture

We finish where every honest technical course should: with the question of what all this is for, and what it costs. Robots are not neutral tools appearing from nowhere. They are built by companies with incentives, deployed into workplaces with people in them, and increasingly into hospitals, homes, and battlefields. An engineer who can compute a gear ratio but cannot think clearly about who bears the cost of automation is only half-educated.

This lesson has three parts. First, the employment question, treated with actual evidence rather than slogans, because both the robots will take all the jobs position and the automation always creates more jobs position are weaker than their advocates claim. Second, the ethical questions that robotics specifically raises, several of which have no settled answer and where your job is to understand the argument rather than receive a conclusion. Third, and most practically, how you get into this field, whether that means a career or a workbench in your garage.

A note on stance. I am going to give you the strongest version of each side of the contested questions rather than telling you what to conclude. That is not evasion; it is the honest state of the evidence, and being able to hold a genuine controversy in your head without collapsing it prematurely is itself an engineering skill.

Robots and jobs: what the evidence says

Start with what is not in dispute. Robots do displace specific workers from specific jobs. When a welding cell replaces six welders, those six people lose that work, and the research consistently finds that displaced manufacturing workers often do not recover their previous earnings, particularly older workers and those in regions where one industry dominates. Displacement is concentrated, visible, and painful, and dismissing it as the price of progress is a moral failure as well as a political one.

Also not in dispute: aggregate unemployment has not risen with automation over the long run. Agriculture employed roughly 40 percent of the American workforce in 1900 and under 2 percent today, and mass unemployment did not follow; the workforce moved into work that did not previously exist. Robot-dense countries such as South Korea, Japan, and Germany do not show unusually high unemployment, and firms that automate frequently grow and hire, because lower costs expand output.

Where economists genuinely disagree is on magnitude, distribution, and speed. The influential Acemoglu and Restrepo studies of US local labor markets estimated meaningful negative effects of industrial robot adoption on employment and wages in exposed areas, while other researchers analyzing different countries and periods found smaller or offsetting effects, and studies at the firm level often find automating firms expand employment even as their competitors shrink. These are not contradictory so much as different questions: what happens to a firm, a local labor market, and a whole economy can differ enormously.

Three points survive all the disagreement, and they are the ones worth carrying. First, the transition matters as much as the destination: even if new jobs eventually appear, a 52-year-old machinist in a one-factory town does not smoothly become a robot technician, and policy determines whether that transition is cushioned or brutal. Second, robots substitute for tasks rather than occupations. Most jobs are bundles of tasks, some automatable and some not, so the common outcome is jobs changing rather than vanishing: a warehouse worker who once walked ten miles a day now works a picking station. Third, demographics complicate the whole picture, since Japan, South Korea, Germany, and China face shrinking working-age populations, and there the loudest concern is a shortage of workers, not a surplus. Robotics adoption in elder care and logistics there is driven by people who cannot be hired at any wage.

Key idea: Robots demonstrably displace specific workers while aggregate employment has historically adjusted; the honest debate is about magnitude, distribution, and the human cost of transition, not about whether work will exist.

The ethical questions

Responsibility. When an autonomous machine causes harm, who is accountable? The manufacturer that wrote the software, the operator who deployed it, the integrator who configured the cell, the regulator who approved it? Traditional product liability assumes a designer could foresee failure modes, which strains when behavior emerges from a learned model whose decisions no one can fully explain. This is not hypothetical: it is being litigated and legislated now, in vehicle regulation and in the European Union's approach to AI liability, and the answers will shape what gets built.

Autonomous weapons. Should a machine be permitted to select and engage a human target without a person deciding? Proponents argue machines do not panic, seek revenge, or commit atrocities from fear, and could in principle apply rules of engagement more consistently than frightened soldiers. Opponents argue that delegating killing to software crosses a moral line regardless of accuracy, that accountability evaporates, that error rates in target discrimination are unacceptable, and that low-cost autonomous weapons would lower the threshold for war. The United Nations has hosted years of discussion without binding agreement, and thousands of AI and robotics researchers have signed pledges against building such systems. This is the one topic in this lesson where a large portion of the field has taken a public position, and you should know that it is the field's own most contested ethical question.

Privacy and surveillance. A robot in your home carries cameras, microphones, and now a detailed map of your floor plan, which is commercially valuable data about your house's size, furnishings, and your daily routines. Delivery robots and security patrol robots record public and semi-public spaces continuously. The engineering questions are concrete: what is stored, where is it processed, who can access it, and what happens at a subpoena or a breach. Design decisions here, such as processing images on the device rather than in the cloud, are ethical decisions in technical clothing.

Care and companionship. Robots in eldercare raise a genuinely hard question. Japan has pioneered devices like the seal-shaped therapeutic robot Paro, and studies report reduced agitation and improved mood in some dementia patients. Critics argue this substitutes simulated relationship for human contact and may let institutions reduce staffing while claiming to improve care. Defenders note that the realistic comparison is often not a human companion but no companion at all, and that a device reducing distress at 3 a.m. is not obviously worse than solitude. Both positions have force, and the outcome depends heavily on whether such devices supplement or replace human presence.

Two more deserve mention. Bias enters robots through learned perception, since a system trained on unrepresentative data may perform worse for some people than others, which becomes a safety issue when the system is deciding whether an object in the road is a person. And automation dependency, well documented in aviation, describes what happens when a human supervisor of a highly reliable automated system loses the vigilance and hands-on skill needed to intervene during the rare failure, which is precisely the moment intervention matters.

Key idea: Robotics ethics turns on responsibility for autonomous harm, autonomous weapons, privacy in domestic and public spaces, the role of care robots, bias in learned perception, and human skill loss under automation.

Careers in robotics

Now the practical part. Robotics is not one job, and understanding its divisions helps you aim.

Role	Core work	Typical background
Robotics software engineer	Perception, planning, control code; ROS, C++, Python	Computer science or engineering degree
Mechanical design engineer	Linkages, gearboxes, structures, thermal and stress analysis	Mechanical engineering degree
Electrical and embedded engineer	Motor drivers, power, sensor interfacing, firmware	Electrical or computer engineering degree
Controls engineer	Feedback design, stability, system identification	Engineering degree with control coursework
Robot technician	Install, program, maintain, and repair working robots	Associate degree or certificate, strong demand
Systems integrator	Design whole cells, select equipment, deliver to customers	Engineering plus applications experience

Two observations about that table. First, the technician path is genuinely undervalued: every deployed robot needs installation, programming, and maintenance, the work cannot be offshored because the machine is here, and the entry credential is often a two-year degree or manufacturer certification rather than a four-year one. The US Bureau of Labor Statistics tracks these occupations and projects continued growth. Second, no one is a robotics generalist at the start. You enter through one door, mechanical, electrical, software, or controls, and you broaden by working next to people who came in through the others. If you are choosing coursework, the reliable core is linear algebra, calculus, physics, programming, and a control systems course, with linear algebra being the single most underestimated item on that list because everything from kinematics to computer vision to state estimation is built on it.

Your first robot

Nothing in this course substitutes for a machine that moves. Here is a concrete path, chosen so each step teaches a specific lesson from earlier modules.

Pick a controller. An Arduino-class microcontroller is the standard on-ramp: tiny, cheap, real-time, and directly connected to motors and sensors, with an enormous library ecosystem. A Raspberry Pi or similar single-board computer runs Linux, ROS, and cameras, but does not do precise timing well. The professional pattern is both: a microcontroller running control loops, a computer running perception and planning, talking over a serial link. Build the microcontroller robot first.

Build the classic sequence. Start with a differential-drive chassis, two gearmotors, a motor driver, and a battery, and drive it open loop. Add encoders and implement the odometry from Module 3, then drive a 2 meter square and measure how far off it ends up; you will feel drift rather than read about it. Add an ultrasonic sensor for obstacle avoidance, and observe firsthand the angled-wall and curtain failures from Module 2. Add two infrared sensors and write a proportional line follower, then extend it to full PID, tuning the gains as Lesson 12 described until the weaving stops. That single progression exercises sensing, actuation, kinematics, and control, and it is roughly a semester of evenings.

Then go wider. Add a camera and try color blob tracking, then AprilTags. Move to a lidar and run ROS 2 with an existing SLAM package, which teaches you both mapping and, just as valuably, how to work inside a large software ecosystem you did not write. Build a small arm from hobby servos and implement the two-link inverse kinematics you worked by hand in Lesson 11, which is the moment the trigonometry stops being abstract.

Compete and collaborate. Competitions are the best accelerator available. FIRST Robotics runs seasons for school-age students; VEX operates at multiple levels; RoboCup runs international soccer, rescue, and home leagues; Micromouse (small robots solving mazes autonomously) has run since the 1970s and is a superb self-contained project; and university programs run rover, submarine, and combat competitions. What competitions give you that a personal project cannot is a deadline, a specification you did not write, and a team, which is exactly the shape of professional engineering work.

Key idea: Start with a microcontroller and a differential-drive chassis, work the sequence of odometry, obstacle avoidance, and PID line following, then add cameras, lidar with ROS, and an arm, using competitions for deadlines and teamwork.

Common misconceptions

• Economists agree that robots destroy jobs on net. They do not. Studies disagree substantially by country, period, and level of analysis; what is agreed is that displacement is real, concentrated, and costly to those affected.
• You need a PhD to work in robotics. Research roles often do, but the largest and fastest-growing demand is for technicians, integrators, and application engineers who install, program, and maintain working robots.
• Ethical questions are for philosophers, not engineers. Whether a robot processes camera data on-device or in the cloud, and how much force a joint can apply, are engineering decisions that settle ethical questions in practice.
• Building a real robot requires expensive equipment. A competent first robot costs about the price of a textbook, and the intellectual content of the odometry-to-PID sequence is identical to what industrial machines do.

Recap

• Robots displace specific workers, aggregate employment has historically adjusted, and the real debate concerns magnitude, distribution, and the cost of the transition.
• Robots substitute for tasks rather than whole occupations, and aging populations in Japan, Korea, Germany, and China drive adoption where workers cannot be hired at any wage.
• The central ethical questions are responsibility for autonomous harm, autonomous weapons, privacy and surveillance, care robots, bias in learned perception, and automation dependency.
• Robotics careers divide into software, mechanical, electrical, controls, technician, and integration roles, with technicians in strong demand and linear algebra the most underrated prerequisite.
• Build a differential-drive robot, add encoders and odometry, then ultrasonic avoidance, then a PID line follower, then cameras, lidar with ROS, and an arm, and use competitions for deadlines and teamwork.

Sources

1. US Bureau of Labor Statistics. (n.d.). Occupational outlook handbook. US Department of Labor. bls.gov
2. International Federation of Robotics. (2024). World Robotics reports. IFR. ifr.org
3. IEEE Spectrum. (n.d.). Robotics and society coverage. IEEE. spectrum.ieee.org
4. Britannica. (2024). Automation. In Encyclopaedia Britannica. britannica.com
5. National Institute of Standards and Technology. (n.d.). Robotics research and standards. NIST. nist.gov