Embodied AI and the robot system

Most of the AI in this program lives on servers: it reads text, classifies images and predicts numbers, and its mistakes appear on a screen. Embodied AI is different. A robot senses the physical world through noisy sensors, decides what to do under uncertainty, and acts through motors that move real mass in real time, where mistakes can break objects or hurt people. Robotics has its own long tradition of geometry, estimation, planning and control, developed over decades before deep learning. Today the two traditions are merging: learned perception, learned policies and large foundation models are being combined with classical methods to build robots that can work in unstructured homes, warehouses, farms and hospitals. This course covers both. This first lesson introduces the types of robots and their applications, the sense-plan-act loop and its timing, the software architecture of modern robots including ROS 2, the role of simulation, the classical and learning-based approaches the course will cover, and the safety mindset that must accompany every robot project.

Types of robots

• Industrial manipulators: fixed robot arms, typically with six joints, used for welding, painting, assembly, machine tending and palletizing. Hundreds of thousands are installed each year worldwide, most in automotive, electronics and metal industries.
• Collaborative robots (cobots): lighter arms designed to work near people with force and speed limits, used for assembly, inspection and packing.
• Mobile robots: wheeled autonomous mobile robots (AMRs) in warehouses and hospitals, delivery robots, cleaning robots, and outdoor vehicles in agriculture and mining.
• Mobile manipulators: arms mounted on mobile bases, which can move between workstations.
• Legged robots: quadrupeds for inspection of industrial sites, and humanoids under intense development for general-purpose work in human environments.
• Aerial and underwater robots: drones and remotely operated or autonomous underwater vehicles.
• Medical and assistive robots: surgical systems, rehabilitation devices, exoskeletons and prosthetics.

Each type brings different challenges. Industrial arms work in structured cells where parts arrive in known positions; AMRs navigate dynamic spaces among people; humanoids must balance, walk and manipulate objects never seen before. The more unstructured the environment, the more the robot depends on perception, uncertainty handling and learning.

The sense-plan-act loop

Every robot runs a loop: sense the world, estimate the state of the robot and its surroundings, decide what to do, and send commands to actuators. In practice, several loops run at different rates. Low-level motor control runs at hundreds to thousands of times per second; state estimation and whole-body control at hundreds of hertz; perception at the camera frame rate of 10 to 60 Hz; and planning or high-level reasoning at a few hertz or slower. A large language model that takes a second to respond can choose which task to do next, but it cannot balance a robot.

Timing matters as much as intelligence. A controller acting on old information can overshoot, oscillate or become unstable, because by the time it reacts, the world has moved on. The simulation below compares a simple position controller at different loop rates and sensing delays.

import numpy as np
# A sense-plan-act loop: moving to a target 1 m away with a proportional controller
# The effect of loop rate and sensing delay on overshoot and settling
def run(rate_hz, delay_s, kp=4.0, t_end=4.0, noise=0.005, seed=1):
    rng = np.random.default_rng(seed)
    dt = 1.0 / rate_hz
    delay_steps = int(round(delay_s / dt))
    x, v, target = 0.0, 0.0, 1.0
    readings = [0.0] * (delay_steps + 1)
    xs = []
    for _ in range(int(t_end / dt)):
        readings.append(x + rng.normal(0, noise))     # sense
        measured = readings[-1 - delay_steps]          # delayed measurement
        cmd = kp * (target - measured)                 # decide
        v += (cmd - v) * min(1.0, dt / 0.05)           # act: actuator with 50 ms lag
        x += v * dt
        xs.append(x)
    xs = np.array(xs)
    last = xs[int(len(xs) * 0.75):]
    return xs.max() - target, np.abs(last - target).mean()

for rate, delay in [(100, 0.0), (100, 0.1), (20, 0.0), (20, 0.2), (10, 0.3)]:
    over, err = run(rate, delay)
    print(f"{rate:4d} Hz loop, {delay * 1000:3.0f} ms delay: overshoot {max(over, 0) * 100:6.1f} cm, final error {err * 100:6.1f} cm")

 100 Hz loop,   0 ms delay: overshoot    0.1 cm, final error    0.0 cm
 100 Hz loop, 100 ms delay: overshoot    9.4 cm, final error    0.0 cm
  20 Hz loop,   0 ms delay: overshoot    0.2 cm, final error    0.1 cm
  20 Hz loop, 200 ms delay: overshoot   39.9 cm, final error    0.2 cm
  10 Hz loop, 300 ms delay: overshoot   91.7 cm, final error   26.8 cm

With no delay, the controller settles cleanly whether it runs at 100 Hz or 20 Hz. Adding delay causes overshoot that grows sharply: 100 ms of delay produces about 9 cm of overshoot, 200 ms about 40 cm, and at 10 Hz with 300 ms of delay the system oscillates and fails to settle. Delays come from sensor exposure and transfer, perception networks, communication between computers, and actuator response. Designing the robot's computing architecture, choosing where each computation runs, and tuning controllers for the delays that remain are central engineering tasks, and a reason why heavy AI models are usually kept out of the fastest loops.

Robot software architecture

Robot software is usually organized as many communicating processes: drivers for each sensor and actuator, perception modules, state estimators, planners, controllers, safety monitors and user interfaces. The Robot Operating System (ROS), now in its second generation (ROS 2), is the most widely used open framework. It is not an operating system in the usual sense but middleware that provides:

• Nodes: processes that perform one function, such as a camera driver or a path planner.
• Topics: named publish-subscribe channels carrying messages such as images, point clouds, joint states and velocity commands.
• Services and actions: request-response calls and long-running goals with feedback, such as "navigate to the loading dock".
• Transforms (tf2): a library that tracks coordinate frames over time, such as where the camera is relative to the gripper (Lesson 2).
• Tools for recording and replaying data (bags), visualization, simulation integration, and a large ecosystem of packages for navigation (Nav2), manipulation (MoveIt 2) and perception.

ROS 2 is built on the Data Distribution Service (DDS) standard, with quality-of-service settings for reliability and latency, and supports real-time and multi-robot systems better than the original ROS. Industrial robots also use vendor controllers and programmable logic controllers, often integrated with ROS-based perception and planning.

Simulation

Simulation is indispensable in robotics. Physics simulators model rigid bodies, joints, contacts, friction, sensors and cameras, allowing developers to test software before touching hardware, to generate training data, and to train learning-based controllers with millions of trials that would take years on real robots. Widely used simulators include Gazebo (closely integrated with ROS), MuJoCo (known for accurate contact dynamics and widely used in research), NVIDIA Isaac Sim and Isaac Lab (GPU-accelerated with photorealistic rendering), PyBullet, and Webots. The gap between simulated and real behaviour, the sim-to-real gap, arises from inaccurate physics, friction, delays, sensor noise and visual differences; Lesson 9 covers techniques for closing it.

Classical and learning approaches

Robotics problems can be solved in two broad ways, and modern systems mix them:

Classical methods are well understood, data-efficient and verifiable, but they need accurate models and struggle with the variety of the real world. Learning methods handle variety and complex perception, but need large amounts of data, can fail unpredictably outside their training distribution, and are harder to certify for safety. The course follows the stack from bottom to top: kinematics (Lessons 2 and 3), sensing and estimation (Lessons 4 and 5), localization and mapping (Lesson 6), planning (Lesson 7), control (Lesson 8), learning for control (Lessons 9 and 10), foundation models (Lesson 11), and safety and deployment (Lesson 12).

A safety mindset

Robots can injure people by striking, crushing or pinching them, by dropping loads, or by moving unexpectedly. Safety must be designed in from the start, not added after a demonstration works. Basic principles include risk assessment of every task and hazard; physical safeguards such as fences, light curtains and area scanners for industrial robots; speed and force limits for collaborative robots; reliable emergency stops; safety-rated control functions that do not depend on the AI software; and testing that covers failure modes as well as normal operation. Learned components add new risks, because their behaviour in unusual situations is hard to predict, so most deployed robots wrap learned policies in classical safety layers that constrain what they can command (Lesson 12).

Hardware matters

It is easy for AI students to focus on algorithms and forget that robots are machines. Motors have torque and speed limits and heat up under sustained load; gearboxes add backlash, friction and compliance; batteries limit operating time and sag under heavy current; cables wear out at moving joints; and sensors get dirty, misaligned or damaged. A brilliant policy is useless if the gripper cannot apply enough force or the battery lasts twenty minutes. Successful robotics teams therefore include mechanical and electrical engineers alongside AI specialists, and they choose algorithms that suit the hardware they actually have.

Cost also shapes what is practical. Industrial customers compare a robot with the cost of a worker, a conveyor or a simpler machine over several years, including integration, maintenance and downtime. Many promising research systems have struggled to find markets because a cheaper, simpler solution already existed. Understanding the economics of the application is part of engineering a useful robot.

Throughout the course, each lesson pairs concepts with a small simulation in code. These examples are deliberately simple, a single joint, a corridor, a grid, so that the core idea is visible, but the same principles scale to the full robots and software frameworks used in industry and research.

As you work through the lessons, keep a single example robot in mind, such as a mobile manipulator fetching items in a hospital, and ask how each topic applies to it. The pieces fit together into one system in the capstone.