Home · Course structure
IE University · IRL-N3CSAI.OACT.M.A1 · 2025–26
Introduction to Robotics Lab — Course Structure
The complete, syllabus-driven map of the course: what you'll learn, how you'll be assessed, and every one of the 15 live sessions across four modules — from the history of robotics and forward kinematics, through sensors, actuators and PID control, to the Pepper humanoid and a fully autonomous Raspberry Pi car. Each session links to the matching hands-on demo on this site.
About this course
The Robotics Lab is composed of 15 hours of practical experiments and laboratory activities. The course follows a Project-Based Learning — "learn by doing" — paradigm, an effective teaching technique for robotics built around real robot projects. It covers fundamental concepts, practical applications, and hands-on projects to equip students with the skills needed to design, program, and interact with robots, and to bring real-world situations and real-life problems into the lab. The course combines theoretical knowledge with practical experience, preparing students for advanced courses such as Robotics & Automation in their fourth year.
Instructor. Suzan T S Awinat — Adjunct Professor, Women in Robotics & STEM, and PhD candidate in computer engineering. Research areas: pattern recognition, Arabic NLP, genetic programming, evolutionary algorithms, semantics, and robotics. Office: T-05.17, IE Tower; office hours on request (also reachable on Teams).
Prerequisites & how this course connects. As a first-year lab in the BCSAI degree, the course assumes only secondary-school trigonometry (sine/cosine, the law of cosines, atan2 for kinematics), basic vectors and geometry, and introductory Python (variables, loops, functions, conditionals) — no prior robotics or electronics is required. It runs in parallel with your AI and programming foundations and feeds forward into the fourth-year Robotics & Automation course: the sense–think–act loop, kinematics, and feedback control you build here are the vocabulary of every later robotics, control, and embodied-AI subject. Think of it as the bridge that turns abstract algorithms into machines that move.
Weekly study & lab load. The course is 3 ECTS ≈ 75 hours total over the semester — roughly 5 hours per week. That breaks down as ~1 contact hour in the live lab plus ~4 hours of preparation: group-project work (the largest share, ~2 h/week), reading and individual study (~1 h/week), and exercises, async tasks and discussion (~1 h/week). The load is back-loaded: Modules 1–3 are reading- and concept-heavy, while Modules 4 (the car build) is dominated by hands-on group work and report writing. Budget extra hours in the two weeks before the Session 8 midterm and the Session 15 competition.
Jump straight to the interactive companion for any module:
What you'll be able to do
By the end of this course, students will be able to:
- Understand the fundamentals Grasp the fundamental principles of robotics and AI — the sense–think–act loop, kinematics, control, and perception.
- Design & program robots Be able to design and program robotic systems, using Python and other languages common in robotics.
- Work with real robots Gain practical experience with humanoid robots (Pepper) and autonomous vehicles (the Raspberry Pi car).
- Reason about ethics Develop critical-thinking skills regarding the ethical implications of robotics and AI in society.
- Collaborate with AI & peers Work effectively with AI tools and human teammates to solve problems and generate innovative solutions — fostering teamwork and leveraging AI to improve group productivity.
Key topics covered
Hands-on projects
How the course is taught
The IE University teaching method is collaborative, active, and applied. Students actively participate in the whole process to build their knowledge and sharpen their skills; the professor's main role is to lead and guide students toward the learning objectives through a diverse mix of teaching techniques and learning activities. The activity mix and the time a student is expected to dedicate (total 75 hours) breaks down as follows:
Estimated time to prepare for and participate in each activity: group work 30 h · lectures 15 h · exercises/field work 15 h · individual studying 9 h · discussions 6 h — 75 h total.
AI policy — critical GenAI use is encouraged. Generative AI is encouraged in this course to develop an informed, critical perspective on its uses and outputs. But know its limits: minimum-effort prompts give low-quality results, so refine your prompts. Don't take GenAI output at face value — assume it is wrong unless you know the answer or can cross-check it; you are responsible for any errors or omissions. AI is a tool you must acknowledge using — acknowledging it will not impact your grade, but failing to do so violates academic-honesty policies.
How you'll be assessed
Assessment reflects the balance robotics demands between theoretical understanding, hands-on experimentation, technical communication, and active engagement. The final grade is distributed across four components that together total 100%, designed to support a progressive journey from fundamentals to full system integration and autonomous behavior.
Workgroup experiments
Especially in Modules 2, 3 and 4, students collaborate on experiments involving sensors, actuators, control systems, humanoid interaction, and the Raspberry Pi car. Evaluates teamwork, applied problem-solving, and the ability to translate theory into functioning robotic systems.
What's judged: a working result (does the system do what was asked?), the soundness of your engineering choices, and how the work was shared across the team. Format: a functioning build or simulation plus a short multimedia presentation of results. Tip: commit early and often, keep a shared lab log, and divide work so every member can explain the whole system — not just their slice.
Intermediate tests
Periodic assessments (including the Session 8 midterm) measure comprehension of key concepts from Modules 1–3 — kinematics, control theory, and human–robot interaction — ensuring a solid theoretical foundation before the final project.
What's judged: conceptual understanding over memorization — can you set up a forward-kinematics equation, reason about what a PID term does, or trace the NLP pipeline? Format: short-answer and applied problems spanning Modules 1–3. Tip: re-derive the 2-link FK/IK equations by hand and explain each PID gain in one sentence; if you can teach it, you know it.
Report writing
Documentation of experimental work and project development, particularly during the Raspberry Pi car build and autonomous-navigation phases. Evaluates clarity, structure, and the ability to communicate technical processes and results.
What's judged: clear structure (objective → method → results → discussion), reproducibility, honest analysis of what failed and why, and clean figures/diagrams. Format: a written technical report on the car build and autonomous-navigation phase. Tip: write as you go — log wiring diagrams, gain values, and test runs in the moment; a report assembled from a live lab notebook always beats one reconstructed from memory.
Class participation
Robotics is inherently interactive. Participation in lectures, discussions, and labs is essential for foundational topics such as kinematics, AI basics, and NLP. Rewards consistent engagement, curiosity, and contribution.
What's judged: quality of contributions and consistent presence — thoughtful questions, helping teammates debug, and connecting today's topic to earlier ones count more than raw airtime. Format: ongoing, in lectures, discussions and labs. Tip: start in week one; a few substantive contributions throughout beats a burst at the end.
Participation rating
Based on two aspects — presence and contributions to class discussions. Contributions are judged on quality, not quantity: frequent participants don't automatically rate higher. Start contributing from the beginning of the course.
Individual & workgroup labs
You'll complete several labs individually or in groups and present results in multimedia form — a chance to reflect on class learning and apply it to practical problems. Full lab details are provided at the start of the course.
Re-sit / re-take policy
A re-sit / re-take policy applies as per IE University regulations. Check the University's official policy; the Program Director may provide further indications.
Attendance, conduct & ethics
Sessions are live and in-person; consult the University's Attendance Policy, Code of Conduct, and Ethics Code. The Program Director may provide further indications.
The full program — 15 sessions, 4 modules
All sessions are live and in-person. Each session below lists its objective, the topics it covers with short explanations, the core robotics concept where the material is technical, a key idea to take away, suggested readings, and a link to the matching interactive demo on this site.
Foundations of Robotics
The conceptual bedrock of the course: where robots came from, what makes a machine a robot rather than mere automation (the AI sense–think–act loop), and the mathematics of motion that lets us command an arm to reach a point in space.
- Place modern robotics in its historical and technological context, and classify robots by type and application.
- Explain how AI and machine learning turn sensing and actuation into intelligent behavior.
- Compute forward and inverse kinematics for a simple manipulator and reason about degrees of freedom.
Introduction to Robotics
Objective: orient students in the field, set expectations, and introduce the semester-long projects.
History and evolution of robotics
The word "robot" entered the language in Čapek's 1920 play R.U.R., but the lineage runs from ancient water-clocks and 18th-century automata, through Unimate — the first industrial arm, installed at a General Motors plant in 1961 — to today's learning, perception-driven systems. Each era's robots were defined by the technology available: gears and cams gave way to electric motors and microcontrollers, and then to sensors and AI. Why it matters: understanding this arc shows that "robot" is less a fixed object than the current frontier of what machines can do autonomously. Lab example: the demo timeline lets you scrub through these milestones and see how capabilities compounded.
Types of robots and their applications
Robots are commonly classified by morphology and mobility: manipulators (fixed-base arms, e.g. welding and assembly), mobile robots (wheeled/legged, e.g. warehouse AMRs), humanoids (human-shaped, e.g. Pepper), and autonomous vehicles (self-driving cars, drones). Each maps to domains — manufacturing, healthcare, logistics, exploration, service, and research — where its body plan is an advantage. Why it matters: choosing the right class is the first design decision; an arm bolted to the floor and a free-roaming car solve fundamentally different problems. This course deliberately touches three classes: a 2-link manipulator (Module 1), a humanoid (Module 3), and a mobile robot (Module 4).
Course overview and project introduction
A map of the semester: four modules, the four-part assessment scheme, and the two hands-on builds — Pepper interaction and the autonomous Raspberry Pi car — that everything drives toward. Why it matters: seeing the destination early lets you connect each abstract lecture (kinematics, control, NLP) to the concrete robot it will help you build, so no session feels isolated.
Key idea. "Robot" is a moving target: each generation of technology redraws the line between automation and autonomy.
Take away. You should leave Session 1 able to state the sense–think–act loop, name the four robot classes, and explain how the two semester projects map onto them.
- Craig, Introduction to Robotics — Ch. 1 (Introduction). Sets up the vocabulary — spatial descriptions, the notion of a manipulator — that the rest of the book builds on; read for the framing, not the equations yet.
Basics of Robotics and AI
Objective: understand the fundamental vocabulary of robotics and where AI/ML fit into a robotic system.
Fundamental concepts in robotics
The shared vocabulary of every robot: links (rigid segments), joints (actuated connections — revolute for rotation, prismatic for sliding), the end-effector (the tool at the tip), the workspace (everything the end-effector can reach), and degrees of freedom (independent ways the robot can move). These compose into the perception–planning–control pipeline. Why it matters: without this vocabulary, robotics papers and code are opaque; with it, a "6-DOF arm with a revolute wrist" is instantly meaningful. Lab example: describe the Module-1 demo arm in these exact terms — two links, two revolute joints, a point end-effector, a ring-shaped workspace.
Basics of AI and machine learning in robotics
AI enters the loop at three points: perception (e.g. a vision model that labels an obstacle), decision-making (planners and learned policies that choose actions), and learning (improving from data instead of hand-coded rules). Classical robotics writes the rules explicitly; ML lets the robot infer them from examples. Why it matters: hard-coded behavior is brittle in messy real environments, whereas a learned model generalizes — but it can also fail unpredictably, which is why this course pairs AI with a critical, verify-everything stance. Pitfall: ML is not magic — a poorly-labeled dataset or an untested edge case will produce a confident wrong answer.
Key idea. AI doesn't replace the loop — it makes each stage of sense → think → act more capable and more general.
Take away. Be able to label any robot's links, joints, end-effector and DOF, and say where AI plugs into its sense–think–act loop.
- Craig, Introduction to Robotics — Ch. 1 (terminology & spatial descriptions). Focus on the definitions of links, joints, frames and pose; these terms recur in every later chapter.
Robot Kinematics
Objective: master the geometry of robot motion — predicting where the hand goes, and computing the joint angles to reach a target.
Forward and inverse kinematics
Forward kinematics (FK) answers "given the joint angles, where is the hand?" — a direct trigonometric computation with exactly one answer. Inverse kinematics (IK) answers the harder reverse question, "what joint angles put the hand there?" — which can have zero (target out of reach), one (the arm is fully extended), or several (elbow-up vs. elbow-down) solutions. How it works: FK chains rotation/translation through each joint; IK solves the geometry backward, typically with the law of cosines and atan2. Why it matters: you command a robot in task space ("go to this point") but motors live in joint space, so IK is the translator between intention and motion. Lab example: drag the target in the FK/IK demo and watch the two joint angles snap to it — or fail when you reach past the arm's span.
Degrees of freedom and robot motion
DOF is the count of independent parameters needed to fully specify a robot's configuration — for the planar 2-link arm, the two joint angles. Why it matters: DOF must match the task's dimensionality: positioning a point in a 2-D plane needs 2 DOF; positioning and orienting a tool in 3-D space needs 6. Too few DOF and some poses are simply unreachable; extra ("redundant") DOF give multiple ways to reach the same pose, useful for dodging obstacles. Connects to: Pepper's ~17–20 DOF in S6 is the same idea scaled up — and the reason humanoid motion is so hard to coordinate.
x = L₁cosθ₁ + L₂cos(θ₁+θ₂), y = L₁sinθ₁ + L₂sin(θ₁+θ₂) (FK). For IK, the elbow angle comes from the law of cosines, cosθ₂ = (x²+y²−L₁²−L₂²)/(2L₁L₂), and the shoulder from θ₁ = atan2(y,x) − atan2(L₂sinθ₂, L₁+L₂cosθ₂); the ± on θ₂ gives the "elbow-up"/"elbow-down" branches. A target is unreachable when its distance from the base exceeds L₁+L₂ or is less than |L₁−L₂|. Worked example: with L₁=L₂=1, the point (1.4, 0) is reachable (1.4 < 2) with elbow bent ≈±81.8°; the point (2.5, 0) is not, since 2.5 > 2.Key idea. Forward kinematics is one fixed answer; inverse kinematics is a search for a solution that may not exist — or may have several.
Take away. Be able to write FK for a 2-link arm from memory, solve IK with the law of cosines, and explain why a target can have 0, 1, or 2 solutions.
- Craig, Introduction to Robotics — Ch. 3 (Manipulator kinematics): builds FK systematically with frames and the Denavit–Hartenberg convention. Ch. 4 (Inverse manipulator kinematics): the existence, multiplicity, and solution methods for IK. Read Ch. 3 first; the 2-link example is the simplest case of the general method.
Robotics Components
The physical building blocks: the senses (sensors) that let a robot perceive the world, the muscles (actuators) that let it move, and the controller that closes the loop between them to produce stable, accurate motion.
- Select appropriate sensors and actuators for a given perception or motion task.
- Explain how a feedback control loop reduces error toward a setpoint.
- Tune a PID controller and reason about overshoot, oscillation, and steady-state error.
Sensors and Actuators
Objective: understand the components that let robots perceive their environment and act upon it.
Types of sensors and their roles
Robot senses come in families. Proprioceptive sensors measure the robot's own state — encoders count shaft rotation; IMUs (accelerometer + gyroscope) measure tilt and motion. Exteroceptive sensors measure the world — ultrasonic and IR rangefinders return distance, line-follower arrays read floor reflectance, cameras capture rich 2-D images. Each has a working range, a sample rate, and characteristic failure modes (ultrasonics miss soft/angled surfaces; IR is fooled by sunlight; cameras need light and compute). Why it matters: picking the right sensor for the task is half of robot design — you measure what you must act on. Lab example: the sensor simulators let you sweep an ultrasonic beam and watch readings degrade near its min/max range.
Actuators in robotics
Actuators turn electrical energy into controlled motion. A DC motor spins fast with modest torque — great for wheels, paired with a gearbox. A servo bundles a motor, gearbox and feedback so it holds a commanded angle precisely — ideal for steering or a joint. A stepper moves in fixed discrete steps for open-loop precision without feedback — common in printers and pan/tilt rigs. Why it matters: the choice sets your robot's speed, torque, precision and cost. Lab example: the actuators demo shows how a gearbox trades the DC motor's speed for the torque a wheel actually needs.
distance = (speed_of_sound × echo_time) / 2. Worked example: sound travels ≈343 m/s; a 2 ms round-trip echo means distance = (343 × 0.002)/2 ≈ 0.34 m. An encoder with 20 pulses/revolution that counts 5 pulses has turned 5/20 = 90°.Key idea. A robot is only as good as what it can measure — every action ultimately rests on a sensor reading.
Take away. Be able to classify a sensor as proprioceptive vs. exteroceptive, state one failure mode for each common type, and match DC/servo/stepper to a motion task.
- Vaish, Python Robotics Projects — sensor & actuator interfacing chapters: the practical wiring and Python code for exactly the ultrasonic sensors, motors and drivers used in the Module-4 car.
- Craig — Ch. 5–6 (Jacobians/velocities): optional context on how joint velocities map to end-effector velocity, linking sensing of motion to actuation.
Control Systems in Robotics
Objective: learn how feedback control turns noisy sensors and imperfect actuators into precise, stable motion.
Introduction to control systems
Open-loop control sends a command and hopes (run the motor for 2 seconds and assume the robot moved 1 m); closed-loop control measures the result, computes the error = setpoint − measurement, and corrects continuously. Why it matters: the real world is uncertain — battery voltage sags, wheels slip, loads vary — so open-loop drifts while feedback self-corrects. How it works: the controller's job is to drive the error to zero quickly without overshooting or oscillating. Lab example: in the PID demo, switch feedback off and watch the system miss the target; switch it on and watch it home in.
Robot drive systems: drives, motors, and gearboxes
A motor alone spins fast with little torque; a gearbox trades that speed for the torque a wheel needs to actually move the robot. The drive configuration (differential two-wheel, four-wheel, tracked) then sets how the robot turns and how stably it carries load. Why it matters: these choices fix the robot's top speed, acceleration, climbing ability and turning radius before a single line of control code is written. Connects to: the car you build in Module 4 uses a differential drive — steering by spinning its two wheels at different speeds.
e(t) between setpoint and measurement: u = Kp·e + Ki·∫e dt + Kd·de/dt. The proportional term reacts to current error (bigger error → bigger push), the integral term accumulates past error to remove steady-state offset, and the derivative term reacts to how fast error is changing, damping overshoot. Tuning intuition: raise Kp until it responds briskly but starts to oscillate, add Kd to settle the oscillation, then add just enough Ki to erase any leftover gap. A gearbox multiplies torque by its ratio N while dividing speed by N (a 1:20 gearbox gives ~20× torque at ~1/20 the rpm).Key idea. Control is about closing the loop: measure the error, act to shrink it, and repeat — fast enough that the system stays stable.
Take away. Be able to state what each PID term does, sketch the effect of raising Kp/Ki/Kd, and explain the speed↔torque trade of a gearbox ratio.
- Craig, Introduction to Robotics — Ch. 9 (Linear control of manipulators): models a joint as a second-order system and derives the PID feedback law and stability conditions. Read for the intuition behind why the three terms behave as they do, even if the transfer-function math is new.
Humanoid Robots Interaction
Moving from mechanics to interaction: programming the Pepper humanoid to behave expressively, and adding a language layer so the robot can understand human speech and respond with appropriate actions.
- Describe Pepper's hardware and software stack and build simple behaviors in Choregraphe.
- Explain the NLP pipeline that turns an utterance into a robot intent and action.
- Design conversational, interactive behaviors for a humanoid robot.
Introduction to Pepper Robot
Objective: get to know the Pepper platform and create your first behaviors visually.
Overview of Pepper robot's hardware and software
Pepper (SoftBank Robotics) is a ~1.2 m social humanoid: stereo cameras and a depth sensor for vision, a microphone array for sound localization, touch sensors, sonars and bumpers on a wheeled omnidirectional base, a chest tablet for visual interaction, and ~17–20 motorized joints. All of it is driven by NAOqi, an event-and-service framework exposing APIs (ALMotion, ALSpeechRecognition, ALTextToSpeech, …) you call to make Pepper move, listen and speak. Why it matters: Pepper is designed for human interaction, not heavy work — its sensors and form factor optimize for reading and responding to people. Connects to: the cameras/microphones are S4 sensors and the joints are S4 actuators — Pepper is the whole sense–think–act loop in a human-shaped package.
Basic programming using Choregraphe
Choregraphe is a visual editor: you drag boxes (Say, Animation, Speech Recognition, conditionals) onto a canvas and wire their inputs/outputs into a behavior flow — no line-by-line code required, though boxes can contain Python. Why it matters: it lets you prototype expressive behaviors in minutes and see them on the (real or simulated) robot, lowering the barrier from idea to working demo. Lab example: the Pepper avatar demo mirrors this — trigger Say/Wave/Look behaviors and watch the figure respond, just as a Choregraphe flow would.
Key idea. Choregraphe's visual "boxes" are the humanoid equivalent of the kinematics and control you learned earlier — abstracted into reusable behavior blocks.
Take away. Be able to name Pepper's main sensors/actuators, explain what NAOqi provides, and build a simple speech-plus-gesture behavior in Choregraphe.
- SoftBank Robotics — NAOqi / Choregraphe documentation (provided in class). Skim the box library and the ALMotion / ALTextToSpeech APIs; these are the building blocks for the S7 conversational behaviors.
Natural Language Processing (NLP) for Robots
Objective: give the robot language — turning what a human says into something the robot can act on.
Implementing NLP for human–robot interaction
The robot hears speech, transcribes it (ASR), then runs it through an NLP pipeline that tokenizes the text, classifies it into an intent, extracts the relevant entities/slots, and maps the result to a concrete action. Why it matters: raw text is unstructured; the robot can only act on structured intent ("the user wants me to WAVE"). How it works: a classifier — rule-based keyword matching for a few commands, or a trained ML model for many — turns variable phrasings into one of a fixed set of intents. Lab example: the intent-classifier demo shows "can you wave hello?" and "wave at me" both resolving to the same WAVE intent.
Designing conversational behaviors for Pepper using NLP
Each recognized intent is wired to a Choregraphe behavior, and the robot's reply (speech + gesture) closes the conversational loop. Good design handles the no-match case gracefully ("sorry, I didn't catch that") and keeps responses short and timely. Why it matters: interaction feels natural only when latency is low and failures are handled politely. Connects to: this is the S1 sense–think–act loop with language as the sensor and a behavior as the action.
WAVE, slots {hand: left, count: 2} → call the wave animation with those parameters.Key idea. Language is just another sensor stream — NLP is the perception layer that turns speech into intents the robot can plan around.
Take away. Be able to trace an utterance through the four pipeline stages and explain why a confidence threshold and a no-match fallback are essential.
- Class materials on intent classification & NAOqi dialogue: cover building an intent set, simple classifiers, and wiring recognized intents to ALDialog/behaviors on Pepper.
Raspberry Pi Car Project
The capstone: everything from the earlier modules — sensors, actuators, control, and programming — is integrated to build and program a Raspberry Pi car that navigates and avoids obstacles autonomously, culminating in a class competition. Session 8 is the midterm.
- Set up a Raspberry Pi and wire sensors and actuators to its GPIO pins.
- Program motor control and a reactive obstacle-avoidance behavior in Python.
- Test, debug, and tune an autonomous vehicle, and document the process in a report.
Midterm
Objective: consolidate and assess understanding of Modules 1–3 before the build phase begins.
Midterm assessment
An intermediate test covering Modules 1–3: the history of robotics and the sense–think–act loop, robotics/AI fundamentals, forward and inverse kinematics, sensors and actuators, feedback and PID control, and NLP for human–robot interaction. Why it matters: it certifies you carry the conceptual toolkit into the build phase, where there is no time to relearn fundamentals while debugging hardware. Format: applied short-answer and problem-solving rather than recall — expect to set up an FK equation, reason about a PID term, or trace the NLP pipeline.
Key idea. Review across modules, not just the last one — the midterm spans the whole conceptual half of the course.
Take away. Walk in able to derive 2-link FK/IK, define each PID gain's effect, classify sensors/actuators, and trace an utterance through the NLP pipeline.
- Craig — Ch. 1 (terms), Ch. 3–4 (kinematics), Ch. 9 (control); plus the Pepper/NLP class notes. Re-work the demo examples (FK/IK arm, PID tuner, intent classifier) as practice problems.
Building a Raspberry Pi Car — Part 1
Objective: stand up the Raspberry Pi platform and prepare it for robotics.
Introduction to Raspberry Pi and its components
The Raspberry Pi is a credit-card-sized single-board computer: a full ARM CPU, RAM, USB/HDMI/network, and crucially a 40-pin GPIO header that exposes the processor's digital lines to the physical world. Why it matters: unlike a microcontroller, it runs a real Linux OS and Python, so the same machine can do vision, planning and low-level pin control — it is the car's whole brain. How it works: your Python program reads sensor pins and writes motor-control pins while the OS handles networking, files and the camera. Lab example: the interactive GPIO pinout demo lets you click any pin to see whether it's power, ground, or a programmable line.
Setting up the Raspberry Pi environment
Bringing the Pi to life: flashing Raspberry Pi OS to an SD card, first-boot configuration, installing Python and GPIO/motor libraries, enabling the interfaces you'll use (GPIO, I²C, SPI, camera), and connecting over SSH/VNC so you can develop without a monitor. Why it matters: a reproducible, well-configured environment prevents the "works on my Pi" failures that eat lab time. Tip: note your Pi's IP and library versions in the lab log from day one — future-you (and your report) will need them.
Key idea. The Pi turns the abstract sense–think–act loop into real wires — every concept now maps onto a physical pin.
Take away. Be able to identify power/ground/GPIO/bus pins on the header, flash and configure the Pi, and explain why 3.3 V logic can't drive a motor directly.
- Vaish, Python Robotics Projects — Raspberry Pi setup & GPIO chapters: step-by-step OS flashing, library install, and the first blink/read programs that confirm your wiring.
Building a Raspberry Pi Car — Part 2
Objective: connect the hardware and make the car move under program control.
Connecting sensors and actuators to Raspberry Pi
The wiring stage: the motors connect through an H-bridge motor driver (e.g. L298N) powered from its own battery, with the Pi supplying only logic-level direction/PWM signals; ultrasonic sensors, line sensors and encoders connect to input pins, sharing a common ground with the Pi. Why it matters: mixing power and logic incorrectly is the fastest way to brown-out or fry a Pi. Safety basics: common ground between Pi and driver, never back-feed motor voltage into a GPIO pin, and add a level shifter for any 5 V sensor output. Lab example: use the GPIO pinout demo to plan exactly which pins carry motor signals vs. sensor inputs before touching a wire.
Basic programming for car control
The first motion code: Python functions to drive forward/back, stop, and turn (by spinning the two wheels at different speeds), plus routines to read distance and line sensors. Why it matters: these primitives are the action vocabulary every later autonomous behavior is composed from. How it works: set direction pins high/low for forward/reverse and apply PWM for speed; poll sensors in the same loop. Tip: wrap motions in named functions (forward(), turn_left()) early — clean primitives make the S11 control loop far easier to write.
Key idea. Speed control is timing, not voltage — PWM duty cycle is how a digital pin produces an analog-feeling output.
Take away. Be able to wire motors through an H-bridge safely, set direction + PWM in Python, and explain how duty cycle maps to speed (including the deadband).
- Vaish — motor control & sensor interfacing with Python: the exact H-bridge wiring and PWM code patterns used to make the car move and read its sensors.
Advanced Programming for Raspberry Pi Car
Objective: move beyond basic motion to structured, responsive control software.
Advanced programming for the car
Moving from one-off motion commands to a structured, continuously-running control program: a clean sense–think–act loop that reads all sensors each cycle, fuses them into a decision, and issues motor commands — at a steady, fast rate. This is where multiple sensors are integrated, a PID controller is applied (e.g. for line-following or holding speed), and optionally a simple computer-vision step is added. Why it matters: well-structured loop code is testable and tunable stage-by-stage, while tangled code is impossible to debug under competition pressure. Lab example: revisit the PID tuner demo — the same Kp/Ki/Kd you slide there are the constants you'll set for the car's line-following or speed loop.
Key idea. Good robot code is a loop with clean stages — perception, decision, actuation — that you can test and tune independently.
Take away. Be able to structure the car's software as a fixed-rate sense–think–act loop and explain how a camera frame is reduced to a single error signal for control.
- Vaish — advanced projects: integrating sensors and vision into a control loop in Python. Craig — Ch. 9 (control): tuning intuition for the PID gains you'll apply to the car.
Autonomous Navigation
Objective: make the car drive itself — sensing obstacles and choosing a path without human input.
Autonomous navigation
Giving the car its own judgment: each cycle it reads its distance sensors, decides (forward / turn / stop) based on what's clear, and acts — fast enough to thread a course without hitting anything. This reactive scheme is the foundation that more advanced mapping and path-planning build on later. Why it matters: autonomy is the course's headline goal, and a reliable reactive controller is both achievable in a few sessions and genuinely robust. How it works: simple decision rules over thresholded sensor readings, tuned so the car commits to turns cleanly rather than dithering at obstacles. Lab example: drive the autonomous-car demo and watch a pure reactive policy clear a cluttered course.
Key idea. Autonomy can be simple: a tight reactive loop with good sensors beats a complex planner that's poorly tuned.
Take away. Be able to write a reactive obstacle-avoidance policy, contrast it with deliberative planning, and explain how a little state escapes local traps.
- Vaish — autonomous behavior chapters: building reactive obstacle-avoidance loops in Python on the Pi car.
Testing and Debugging
Objective: make the autonomous system reliable through systematic testing and tuning.
Testing and debugging
Turning a car that "mostly works" into one that works reliably: systematically isolating faults across the stack — power and wiring, sensor calibration, control gains, and decision logic — using logging and incremental tests. Why it matters: in a robot, software and hardware bugs look identical from the outside, so a method that separates them saves hours. How it works: test each layer in isolation (does the sensor read sane values? does each motor turn the right way? does the logic branch as expected?) before testing them together, and log everything so intermittent faults leave a trail. Lab example: re-run the autonomous demo while watching its readouts to see how telemetry exposes a misbehaving rule.
Key idea. When a robot misbehaves, suspect the physical layer first — most "algorithm bugs" are loose wires or miscalibrated sensors.
Take away. Be able to debug bottom-up, change one variable at a time, log telemetry, and produce a reproducible test — and capture all of it for the report.
- Vaish — debugging & troubleshooting notes. Plus report-writing guidance: this session generates exactly the test logs and observations that feed the 20% documentation component — record them as you go.
Competition Preparation
Objective: optimize and rehearse the car for the final competition.
Competition preparation
The dress rehearsal: final tuning of speed and avoidance behavior, repeated trial runs on the actual competition course, agreeing team strategy and roles, and finishing the project documentation. Why it matters: the gap between a lab demo and a competition run is all in the details — surface grip, ambient light, and one unfamiliar obstacle layout. How it works: time multiple runs, log failures, adjust one parameter at a time, and lock in the most repeatable configuration rather than the fastest single lap. Lab example: use the autonomous demo as a practice harness to rehearse strategy before the real track.
Key idea. Tune on the actual course: lighting, surface, and layout all change how your sensors and controller behave.
Take away. Arrive with a repeatable, margin-of-safety configuration, a tested team strategy, and a near-complete report — leaving only on-track fine-tuning.
- Project report — the bulk of the 20% report-writing component: objective, method, wiring/control design, results across trial runs, and an honest discussion of failures and fixes.
Competition 🎉
Objective: put it all together — race the autonomous cars and celebrate the semester's work.
Competition
The finale: teams run their autonomous Raspberry Pi cars on the course in front of the class. It's the culmination of the project-based-learning journey, drawing on every module — the kinematics of motion, the sensors and actuators, the feedback control, the Python programming, and the reactive autonomy — all at once. Why it matters: integration is the real test; subsystems that each pass in isolation can still fail together under timing, noise and the pressure of a live run. Lab example: race the autonomous-car demo to feel the same end-to-end loop you've built across the semester.
Key idea. A working robot in front of a crowd is the truest exam — it integrates everything and forgives nothing.
Take away. Leave able to point at your finished car and explain, subsystem by subsystem, how every module of the course is running inside it.
Robotics glossary
A quick reference to the ~60 core terms used across the course, each pinned to the session it appears in. Use it to revise before the midterm or to decode a reading.
- Robot
- A programmable machine that senses, processes, and acts on its environment via actuators.
- Sense–Think–Act loop S1–2
- The core robotics cycle: perceive the world, decide an action, execute it — then repeat.
- Degrees of freedom (DOF) S3
- The number of independent parameters that define a robot's configuration; e.g. a 2-link arm has 2, Pepper ~17–20.
- End-effector
- The tool or "hand" at the tip of a manipulator — the part that interacts with the world.
- Workspace
- The set of all points an end-effector can reach, bounded by link lengths and joint limits.
- Forward kinematics (FK) S3
- Computing the end-effector pose from known joint angles — a direct, single-valued calculation.
- Inverse kinematics (IK) S3
- Computing joint angles to reach a desired pose — may have zero, one, or multiple solutions.
- Joint / Link
- A joint is an actuated connection allowing motion; links are the rigid segments between joints.
- Pose
- The combined position and orientation of a rigid body (e.g. the end-effector) in space.
- Sensor S4
- A transducer converting a physical quantity (distance, light, rotation) into a readable signal.
- Ultrasonic sensor S4
- Measures distance by timing an echo: distance = (speed of sound × echo time) / 2.
- Encoder S4
- A sensor that counts shaft rotation in pulses, used to measure wheel/joint position and speed.
- Actuator S4
- A component that converts energy into motion — DC motor, servo, or stepper.
- Servo motor S4
- A motor with built-in feedback that holds a commanded angle precisely.
- Gearbox / Gear ratio S5
- Trades speed for torque (or vice-versa) by ratio N: torque ×N, speed ÷N.
- Open-loop vs. closed-loop S5
- Open-loop acts without feedback; closed-loop measures error and corrects continuously.
- Setpoint & error S5
- The setpoint is the desired value; error is the difference between it and the measured value.
- PID control S5,11
- u = Kp·e + Ki·∫e + Kd·de/dt — proportional, integral, derivative correction of error.
- Overshoot / Steady-state error S5
- Overshoot is exceeding the target before settling; steady-state error is the residual offset Ki removes.
- Humanoid robot S6
- A robot with a human-like body plan (head, arms, torso) — e.g. Pepper.
- Choregraphe S6
- SoftBank's visual programming tool for building NAO/Pepper behaviors from boxes.
- NAOqi S6
- The software framework/API running on NAO and Pepper robots.
- NLP S7
- Natural Language Processing — turning human language into structured, actionable meaning.
- Tokenization S7
- Splitting text into words or sub-word units as the first step of an NLP pipeline.
- Intent classification S7
- Mapping an utterance to one of a set of action categories (intents) the robot understands.
- GPIO S9
- General-Purpose Input/Output — software-controllable digital pins on the Raspberry Pi.
- PWM S10
- Pulse-Width Modulation — duty cycle sets the average output, used for motor speed control.
- H-bridge / Motor driver S10
- A circuit that lets low-current logic pins control direction and speed of a high-current motor.
- Computer vision S11
- Extracting meaning from camera images — e.g. detecting a line or obstacle to feed a controller.
- Autonomous navigation S12
- A robot moving and avoiding obstacles without human control — reactive or map-based.
- Reactive vs. deliberative S12
- Reactive maps sensors → actions directly; deliberative builds a map and plans a path.
- System integration S15
- Making all subsystems — sensing, control, actuation, software — work together reliably.
- Automation vs. autonomy S1
- Automation runs a fixed pre-set program; autonomy senses and decides at run-time, adapting to the world.
- Manipulator S1
- A fixed-base robot arm — a chain of links and joints ending in an end-effector.
- Mobile robot S1
- A robot that moves through its environment on wheels, tracks, or legs — e.g. the Pi car.
- Revolute / Prismatic joint S2
- A revolute joint rotates about an axis; a prismatic joint slides along one. The two basic joint types.
- Singularity S3
- A configuration (e.g. a fully-extended arm) where motion is lost or IK becomes ill-conditioned.
- atan2 S3
- A two-argument arctangent that returns the correct angle in all four quadrants — essential for IK.
- Law of cosines S3
- c² = a² + b² − 2ab·cosC; the relation used to solve the elbow angle in 2-link IK.
- Proprioceptive / Exteroceptive S4
- Proprioceptive sensors measure the robot's own state (encoders, IMU); exteroceptive sensors measure the world (rangefinders, cameras).
- IMU S4
- Inertial Measurement Unit — accelerometer + gyroscope (often magnetometer) measuring motion and orientation.
- IR / line sensor S4
- Infrared reflectance sensor; an array of them reads a floor line for line-following.
- Sensor noise & filtering S4
- Random variation in readings, reduced by averaging, median, or low-pass filters before acting on the value.
- DC / Stepper motor S4
- A DC motor spins continuously (speed via PWM); a stepper moves in fixed discrete steps for open-loop precision.
- Differential drive S5
- Two independently driven wheels; steering comes from a speed difference between them.
- Proportional / Integral / Derivative S5
- The three PID terms: react to present error, accumulated past error, and the rate of change of error.
- Integral windup S5
- Error accumulating in the integral term while the actuator is saturated, causing later overshoot.
- Cycle time / loop rate S2,11
- How often the sense–think–act loop runs; higher rates give faster, more stable reactions.
- NAOqi S6
- SoftBank's robot software framework exposing the motion, speech and vision APIs on NAO/Pepper. (See also above.)
- ASR (speech recognition) S7
- Automatic Speech Recognition — converting spoken audio into text for the NLP pipeline.
- Entity / slot extraction S7
- Pulling the parameters out of an utterance (which hand, how many times) after intent is known.
- Confidence threshold S7
- A cutoff below which a classifier asks for clarification rather than acting on an uncertain intent.
- Single-board computer S9
- A full computer on one board (e.g. Raspberry Pi) running an OS and Python while controlling hardware pins.
- I²C / SPI / UART S9
- Serial buses on the GPIO header for connecting sensors, displays and other peripherals.
- BOARD vs. BCM numbering S9
- Two ways to refer to Pi pins — physical position vs. GPIO number; mixing them causes wiring bugs.
- Duty cycle S10
- The fraction of each PWM period a pin is high; sets the average output and thus motor speed.
- Deadband S10
- The low duty-cycle range where a motor buzzes but doesn't turn, due to static friction.
- Reactive trap S12
- A corner or dead-end where a memoryless reactive controller oscillates; escaped by adding a little state.
- Calibration S13
- Adjusting sensor thresholds/readings to the actual surface and lighting so values mean what you expect.
- Telemetry / logging S13
- Recording timestamped sensor values and commands during a run to diagnose intermittent faults.
- Repeatability S14
- Getting the same result run after run — valued over peak speed in a competition setting.
- Project-Based Learning
- The course's "learn by doing" paradigm — knowledge built through real robot projects rather than lectures alone.
Annotated bibliography
The core references for the course, as listed in the syllabus.
Introduction to Robotics: Mechanics and Control
John J. Craig · 3rd ed. · Pearson, 2004 · ISBN 9780201543612 (Digital)
The course's compulsory text. It pairs real-world practicality with the underlying theory: roughly one-half mechanical-engineering material, one-quarter control theory, and one-quarter computer science. It covers rigid-body transformations, forward and inverse positional kinematics, velocities and Jacobians of linkages, dynamics, linear and non-linear control, force-control methodologies, mechanical design, and robot programming — directly underpinning Modules 1, 2 and parts of 4.
Python Robotics Projects
Diwakar Vaish · 1st ed. · Packt, 2018 · ISBN 9781788832922 (Digital)
The practical companion for the build modules. It teaches the basics of robotics using the Raspberry Pi as hardware and Python as the programming language — the exact stack used in Module 4's car project. Publisher preview ↗
Source: official course syllabus — Introduction to Robotics Lab (IRL-N3CSAI), IE University, 2025–26. This page is an interactive companion and is not officially affiliated with IE University.