A practical, research-based guide for going from zero to genuinely competent in robotics: what to learn, in what order, with which tools, on which hardware, and through which projects.
Last verified: August 2026. Software versions and release dates are called out explicitly so you can check for newer releases before you start.
- What robotics actually is
- The modern robotics software stack
- Programming languages
- Mathematics
- Physics and mechanics
- Electronics
- Embedded systems
- Linux for robotics
- ROS 2
- Robot modeling
- Simulation
- Sensors
- Actuators
- Control systems
- Computer vision and AI
- Localization, mapping, and navigation
- Manipulation and robotic arms
- Networking and distributed robotics
- Git and engineering workflow
- Recommended learning path (staged curriculum)
- Projects
- Hardware recommendations
- Online resources
- Best books
- Communities and competitions
- How to study robotics effectively
- Career paths
- Common mistakes
- Recommended technology stack for 2026
- Final roadmap
Robotics is not one discipline. It is an integration problem that sits on top of several mature fields:
- Programming — the logic that turns sensor data into motor commands.
- Electronics — the physical circuits that move current between sensors, controllers, and actuators.
- Embedded systems — the real-time, resource-constrained code that runs directly on hardware.
- Mechanical engineering — the physical structure, linkages, gears, and materials the robot is built from.
- Mathematics — the language used to describe motion, uncertainty, and optimization.
- Control systems — the theory of making a physical system track a desired behavior despite noise and disturbance.
- Computer science — data structures, algorithms, concurrency, and software architecture.
- Computer vision — extracting meaning from cameras and depth sensors.
- Artificial intelligence / machine learning — increasingly used for perception and, more selectively, for decision-making.
- Networking — coordinating multiple processes, computers, or robots.
- Linux — the operating system underneath almost every serious robotics stack.
- Systems engineering — making all of the above work together reliably, not just in isolation.
A working roboticist does not need to be an expert in every one of these, but needs working fluency in most of them, because a robot fails at the interfaces between disciplines far more often than within any single one (e.g., a motor that is electrically fine but mechanically under-geared, or a controller that is theoretically correct but starves of CPU time).
| Domain | What distinguishes it |
|---|---|
| Mobile robots | Wheeled/tracked locomotion, navigation, mapping |
| Robotic arms / manipulators | Kinematics, motion planning, grasping |
| Drones (UAVs) | Flight dynamics, stabilization, GPS/visual odometry |
| Humanoids | Balance, bipedal locomotion, whole-body control |
| Autonomous vehicles | Large-scale perception, safety-critical planning, regulation |
| Industrial robotics | Precision, repeatability, safety standards (e.g., ISO 10218) |
| Service robots | Human-robot interaction, unstructured environments |
| Embedded robotics | Extreme resource constraints, real-time firmware |
| Agricultural robotics | Outdoor perception, GPS-denied navigation, ruggedization |
| Medical robotics | Precision, certification, sterility, human safety |
| Underwater robotics (ROV/AUV) | Buoyancy, pressure, acoustic communication, no GPS |
Regardless of domain, nearly every robot needs:
- A way to sense the world (sensors + drivers)
- A way to represent position and orientation (coordinate frames, transforms)
- A way to move (actuators + motor control)
- A way to decide what to do (planning/control/AI)
- A way for software components to talk to each other (middleware — usually ROS 2)
- A way to test safely before touching real hardware (simulation)
This is why the roadmap below front-loads programming, Linux, electronics, and mathematics before touching any specific robot: those are the fundamentals that transfer across every domain in the table above.
Robot hardware
↓
Microcontroller / embedded computer
↓
Firmware / drivers
↓
Linux
↓
ROS 2 / middleware
↓
Robot drivers
↓
Sensors / actuators
↓
Perception / localization / planning
↓
Control
↓
Applications / autonomy
Robot hardware — the physical chassis, motors, sensors, and wiring.
Microcontroller / embedded computer — the lowest-level compute (e.g., an STM32 or ESP32) that talks directly to hardware in real time, with no operating system or a minimal RTOS.
Firmware / drivers — the code that speaks the electrical protocol of a specific sensor or actuator (I2C, SPI, UART, PWM) and exposes it as a usable interface.
Linux — the general-purpose operating system running on the "brain" computer (a Raspberry Pi, an x86 mini-PC, or an NVIDIA Jetson), providing process management, networking, and a filesystem.
ROS 2 / middleware — the communication layer that lets independent programs ("nodes") exchange data (sensor readings, commands, robot state) without every developer writing custom networking code.
Robot drivers — ROS 2 packages that wrap a specific piece of hardware (a LiDAR, a motor controller) and publish/subscribe to standard ROS 2 topics.
Sensors / actuators — the physical devices that give the robot information about the world and the ability to act on it.
Perception / localization / planning — software that turns raw sensor data into an understanding of "where am I" and "what should I do next" (SLAM, path planning, object detection).
Control — the layer that converts a desired trajectory or velocity into precise, closed-loop actuator commands (PID, MPC).
Applications / autonomy — the top-level logic that defines the robot's task (deliver a package, follow a person, pick an item).
Each layer exists because it hides the complexity of the layer below it. A beginner's most common mistake is trying to work at the top of this stack (ROS 2, AI) before understanding what is happening at the bottom (electronics, firmware). The staged curriculum in Section 20 is built to avoid that.
| Language | Primary role in robotics | Strengths | Weaknesses |
|---|---|---|---|
| Python | Rapid prototyping, ROS 2 nodes, AI/CV, scripting | Fast to learn, huge ecosystem (NumPy, OpenCV, PyTorch), first-class ROS 2 support via rclpy |
Slower at runtime, weaker for hard real-time or performance-critical loops |
| C++ | Performance-critical ROS 2 nodes, most robot middleware internals, real-time control | Fast, deterministic, used for the majority of production robotics code and almost all of ROS 2 core itself | Steeper learning curve, manual memory management, slower to prototype in |
| C | Microcontroller firmware, drivers, RTOS work | Minimal overhead, direct hardware access, the default language of embedded toolchains (Arduino core, STM32 HAL) | No abstractions; verbose for anything beyond firmware |
| Rust | Emerging in embedded and safety-critical robotics | Memory safety without a garbage collector, strong tooling, growing ROS 2 support (rclrs) |
Smaller robotics ecosystem than C++/Python as of 2026; steep learning curve |
| MATLAB/Simulink | Control system design, simulation, academic coursework | Excellent for control theory, model-based design, widely used in universities and some industrial control teams | Proprietary/expensive, not typically used to run on the robot itself |
| Lua | Scripting inside some simulators and game-engine-adjacent robotics tools | Lightweight embeddable scripting | Niche in robotics; not a core skill |
| JavaScript/TypeScript | Web dashboards, teleoperation UIs, some IoT-adjacent robotics | Useful for browser-based robot monitoring/control interfaces (e.g., using roslibjs) |
Not used for on-robot control logic |
- Which language should a beginner learn first? Python. It has the lowest barrier to entry, is the primary language for early ROS 2 exercises, and is what most beginner-friendly robotics tutorials and courses use.
- Which language is most important for ROS 2? Both Python (
rclpy) and C++ (rclcpp) are first-class ROS 2 client libraries. Learn Python first for logic and prototyping, then learn C++ because most production ROS 2 packages, drivers, and performance-sensitive nodes (perception, control loops) are written in it. - Which language is important for embedded robotics? C, and increasingly C++ (used heavily on platforms like STM32 and ESP32). Arduino's own environment is a C/C++ dialect.
- Which language is important for high-performance robotics? C++. It remains the standard for anything with hard real-time or high-throughput requirements (control loops, perception pipelines, motion planning internals).
- Which language is useful for computer vision and AI? Python, because virtually every major CV/ML framework (OpenCV, PyTorch, TensorFlow) has Python as its primary interface, with C++ used underneath for deployment and speed.
- Which languages are optional? MATLAB (useful in academic control courses but not required), Lua (niche), Rust (valuable but not mandatory), JavaScript (only relevant if you build web interfaces for your robot).
Python
↓
C/C++
↓
ROS 2 (Python first, then C++)
↓
Embedded C/C++
↓
Advanced robotics (mixed C++/Python depending on layer)
Rust is worth learning if you specifically want to work in safety-critical embedded robotics, next-generation firmware, or you're contributing to projects that have adopted it (some newer drone flight-controller and industrial firmware projects have started using it, and ROS 2 has an official but less mature Rust client library, rclrs). It is not a substitute for learning C++ in 2026 — the ROS 2 ecosystem, tutorials, drivers, and job postings are still overwhelmingly C++/Python. Treat Rust as a later, optional specialization rather than a required step.
No single language is universally "best" — the right choice depends on the layer of the stack you're working in.
| Topic | Why it matters |
|---|---|
| Algebra | Rearranging equations of motion, solving for unknowns in kinematics |
| Trigonometry | Angles, rotations, sensor geometry (e.g., LiDAR ranging) |
| Vectors | Representing position, velocity, force |
| Matrices | Representing transformations, sensor fusion, rotations |
| Linear algebra | The mathematical backbone of kinematics, SLAM, and control |
| Coordinate systems | Every robot has multiple reference frames that must be related to each other |
| Geometry | Collision checking, path planning, workspace analysis |
| Calculus | Velocity/acceleration as derivatives, control system design |
| Differential equations | Describing how a system evolves over time (dynamics, control) |
| Probability & statistics | Sensor noise, localization (particle filters, Kalman filters), machine learning |
| Numerical methods | Nearly everything in robotics is solved numerically, not analytically, in real code |
- Coordinate frames — every sensor, joint, and the robot base each has its own frame; robotics software constantly converts between them.
- Homogeneous transformations — a 4×4 matrix representation combining rotation and translation, used throughout robotics software (this is exactly what ROS 2's
tf2library manages for you). - Rotation matrices, Euler angles, and quaternions — three different ways to represent orientation. Quaternions avoid the "gimbal lock" problem of Euler angles and are what ROS 2 uses internally for orientation.
- Forward kinematics — computing where the end of a robot arm is, given joint angles.
- Inverse kinematics — the harder, opposite problem: computing the joint angles needed to reach a desired position.
- Jacobians — relating joint velocities to end-effector velocities; central to both control and manipulation.
- Trajectories — smooth, time-parameterized paths a robot follows, respecting velocity/acceleration limits.
- Optimization — used in trajectory generation, motion planning, and increasingly in modern control (e.g., Model Predictive Control).
Learn immediately (before or alongside Stage 1–2): algebra, trigonometry, basic vectors, basic matrices, coordinate frames conceptually.
Learn early but can be revisited (Stage 5, alongside ROS 2 basics): linear algebra, rotation representations, homogeneous transforms, basic calculus, basic probability.
Can wait until you actually need it (Stage 9–13): differential equations in depth, Jacobians and inverse kinematics, optimization theory, advanced probability (Kalman/particle filters), state-space control mathematics.
You do not need a full university-level math degree before starting. Most working roboticists learned the deeper mathematics while building projects that required it, not before.
Core concepts, and why each matters when you actually write robot code:
- Newtonian mechanics (F = ma) — every actuator command is ultimately trying to produce a desired force or acceleration.
- Force and torque — motors are rated in torque, not just speed; undersized torque is one of the most common reasons a beginner robot "doesn't work" even though the code is correct.
- Friction — affects wheel traction, gripper contact, and is a major source of the gap between simulation and real hardware ("sim-to-real gap").
- Velocity and acceleration — the quantities your control loops are actually trying to command and measure.
- Momentum — matters for anything with mass moving quickly (mobile robots stopping, arms decelerating).
- Center of mass — determines whether a robot tips over, especially for arms, humanoids, and top-heavy mobile platforms.
- Gears and mechanical advantage — trade speed for torque; almost every hobby and industrial actuator uses a gearbox, and gear ratio errors are a common source of "the math says X but the robot does Y" bugs.
- Motors as physical systems — understanding stall torque, no-load speed, and the torque-speed curve prevents you from choosing an underpowered motor.
- Rotational dynamics (torque, moment of inertia, angular acceleration) — needed for anything with a rotating joint or wheel.
You do not need a full mechanical engineering degree, but you do need enough of this to select the right motor, gear ratio, and structure for a given task — this is one of the most common gaps in self-taught, software-first roboticists.
Ohm's law (V = IR), voltage, current, resistance, power, and Kirchhoff's laws are the absolute starting point — you should be able to read a simple circuit diagram and predict current/voltage before touching a microcontroller.
| Concept | What it's for |
|---|---|
| Digital logic | Understanding HIGH/LOW signals, gates, basic timing |
| PWM (pulse-width modulation) | Controlling motor speed, servo position, LED brightness |
| ADC (analog-to-digital converter) | Reading analog sensors (e.g., a potentiometer, some IR sensors) |
| DAC (digital-to-analog converter) | Producing analog output signals |
| GPIO | General-purpose digital input/output pins |
| UART | Simple serial communication (e.g., debugging, GPS modules) |
| I2C | Multi-device bus for sensors (IMUs, displays) — few wires, moderate speed |
| SPI | Faster point-to-point bus, common for high-speed sensors and displays |
| CAN bus | Robust bus used in industrial and automotive robotics for reliability in noisy environments |
| USB | Host-level communication, common for higher-bandwidth sensors (cameras, LiDAR) |
- Motor drivers — the circuit (often an H-bridge) that lets low-power logic control a high-power motor.
- Encoders — sensors that measure motor/wheel rotation, essential for closed-loop control.
- IMUs (inertial measurement units) — combine accelerometers/gyroscopes (often magnetometers) to measure orientation and motion.
- Batteries — chemistry (LiPo vs. Li-ion), voltage sag under load, and safe charging/handling.
- Voltage regulators — step voltage up/down safely for different subsystems (a 12V battery does not directly power a 3.3V sensor).
- Power management — budgeting current draw across motors, compute, and sensors so nothing brownouts under load.
Start with Ohm's law and basic circuits, then GPIO/PWM (control an LED, then a servo), then ADC (read a potentiometer or basic sensor), then move to I2C (read an IMU). Save CAN bus and advanced power design for when you're building larger platforms — most beginner and even intermediate projects never need CAN.
| Platform | Type | Best for |
|---|---|---|
| Arduino (Uno/Mega/Nano) | Microcontroller, beginner-friendly | First embedded projects, simple sensor/actuator control, huge community |
| ESP32 | Microcontroller with built-in Wi-Fi/Bluetooth | Wireless sensor nodes, IoT-adjacent robotics, good micro-ROS support |
| STM32 | Professional-grade microcontroller family | Real ROS-adjacent embedded work, more demanding real-time or performance needs, industry-standard |
| Raspberry Pi | Single-board computer (SBC) running Linux | Running ROS 2, hosting perception/navigation, general "robot brain" compute |
| Other SBCs (e.g., NVIDIA Jetson, Radxa, Orange Pi) | Linux-capable compute, some with GPU/NPU acceleration | GPU-accelerated perception/AI on the robot itself (Jetson is the dominant choice for on-robot deep learning) |
A microcontroller (Arduino, ESP32, STM32) has no operating system (or a minimal RTOS), executes one program directly on the chip, and excels at precise, low-latency, real-time tasks — reading an encoder every millisecond, generating exact PWM signals.
A single-board computer (Raspberry Pi, Jetson) runs full Linux, can run ROS 2, handle networking, run multiple processes, and do heavier computation (path planning, computer vision) — but timing is less deterministic.
- Microcontroller only: simple, self-contained projects (a line follower, a single servo controller).
- SBC only: projects that are compute-heavy but don't need hard real-time control (e.g., pure simulation, a vision-only project with an external motor controller).
- Both together (the most common real-world pattern): the microcontroller handles tight, real-time control loops close to the hardware (motor PWM, encoder reading), while the SBC runs ROS 2, handles higher-level decision-making, and talks to the microcontroller over serial, I2C, or — increasingly — micro-ROS.
- Firmware — the low-level program that runs directly on the microcontroller.
- Interrupts — hardware signals that pause normal execution to handle a time-critical event immediately.
- Timers — hardware counters used for precise timing, PWM generation, and scheduling.
- Real-time constraints — guarantees that a task will complete within a fixed time budget, essential for safe, stable control loops.
- RTOS concepts (e.g., FreeRTOS) — task scheduling, priorities, and inter-task communication on more demanding embedded projects.
micro-ROS brings a subset of the ROS 2 client library down onto resource-constrained microcontrollers (commonly ESP32 and STM32), letting the microcontroller publish/subscribe to ROS 2 topics directly instead of using a custom serial protocol. This is the modern (2024–2026) recommended approach for bridging embedded firmware and ROS 2, replacing older, more ad-hoc serial-bridge patterns. It is documented and maintained under the micro-ROS project, which is affiliated with the official ROS 2 ecosystem.
ROS 2's primary supported platform is Ubuntu Linux; most robotics drivers, tooling, and documentation assume a Linux environment; and most real robots run Linux as their "brain" operating system because of its reliability, transparency, and free/open licensing.
- Terminal fluency — navigating directories, running programs, piping/redirecting output.
- SSH — remotely accessing and controlling a robot's onboard computer (essential — you rarely have a monitor attached to a real robot).
- Processes — starting, stopping, and monitoring running programs (
ps,kill,htop). - Permissions — file ownership and permission bits, and specifically device permissions (a very common beginner blocker: "why can't my program access
/dev/ttyUSB0?"). - Networking basics — IP addresses, ports, and how two machines find each other on a network (needed once your robot and your laptop are separate machines).
- Serial and USB devices — how Linux exposes hardware as device files (
/dev/ttyACM0,/dev/ttyUSB0) and why device names can change between reboots. - udev rules — creating persistent, predictable device names so "my LiDAR is
/dev/ttyUSB0today and/dev/ttyUSB1tomorrow" stops being a problem. - systemd basics — running a program automatically on boot (useful once you want your robot to start its software without a manual SSH login).
- Git — see Section 19.
- Build systems and CMake — ROS 2's C++ packages are built with CMake under the hood via
colcon; understanding basic CMake helps you debug build errors instead of being stuck by them. - Python environments — virtual environments and package management to avoid dependency conflicts between projects.
- Package management (
apt) — installing and managing system-level software on Ubuntu. - Debugging and logs — reading stack traces, using
journalctl/log files, and basic use of a debugger (gdbfor C++,pdbfor Python).
Ubuntu LTS remains the easiest and most officially supported choice for ROS 2 as of 2026. Each ROS 2 distribution targets exactly one Ubuntu LTS release as its Tier 1 (fully supported and tested) platform. As of mid-2026, the current ROS 2 long-term-support release is Lyrical Luth (released May 2026, supported until May 2031), which targets Ubuntu 26.04 LTS. The previous LTS pairing, ROS 2 Jazzy Jalisco with Ubuntu 24.04 LTS, remains a very solid, widely documented, and still-supported choice if you prefer a more mature, heavily-tutorialed combination while the newest release's ecosystem catches up.
Non-Ubuntu options (Debian, Fedora, Arch-based, openSUSE, macOS, and Windows) can run ROS 2, either through community/Tier 2–3 support or by building from source, but expect more manual troubleshooting, fewer binary packages, and less beginner-oriented documentation. If your goal is to spend your energy learning robotics rather than fighting your OS, start on Ubuntu LTS; move to another distribution later if you have a specific reason to (for example, if you're already deeply invested in another distribution's packaging ecosystem and are comfortable resolving build issues yourself).
ROS 2 (Robot Operating System 2) is not an operating system in the traditional sense. It is a set of software libraries, tools, and conventions that run on top of Linux (or Windows/macOS) to help you build robot software out of independent, communicating pieces. It replaced ROS 1, which is now end-of-life for new projects; ROS 2 was built from the ground up to fix ROS 1's weaknesses in real-time performance, security, multi-robot support, and production readiness.
- Nodes — independent programs that do one job each (e.g., a camera driver node, a path-planning node).
- Topics — named, typed data streams that nodes publish to and subscribe from (e.g.,
/cmd_velfor velocity commands). - Publishers / subscribers — the two ends of a topic-based connection.
- Services — a request/response pattern for one-off, synchronous interactions (unlike the continuous stream of a topic).
- Actions — a pattern for long-running tasks with feedback and the ability to cancel (e.g., "navigate to this point," which reports progress and can be preempted).
- Parameters — configurable values a node can expose and be reconfigured with, without recompiling.
- Launch files — Python (typically) scripts that start and configure many nodes together as a coherent system.
- Packages — the basic unit of ROS 2 software distribution, containing nodes, configuration, and metadata.
- Workspaces — a directory structure where you build and organize your own and third-party ROS 2 packages together.
- colcon — the standard build tool used to compile ROS 2 workspaces.
- Interfaces / messages — the strongly-typed data definitions used on topics, services, and actions (
.msg,.srv,.actionfiles). - QoS (Quality of Service) — configurable delivery guarantees (reliable vs. best-effort, history depth) that let you tune communication for different needs (a camera feed can tolerate dropped frames; a safety-stop command cannot).
- Executors — the mechanism that decides how and when callbacks run within a node (single-threaded vs. multi-threaded).
- Callbacks — the functions triggered when a subscribed message arrives, a service is called, or a timer fires.
- Lifecycle nodes — nodes with a formal state machine (unconfigured → inactive → active → finalized), used for more predictable startup/shutdown in production systems.
- DDS (Data Distribution Service) — the underlying industry-standard middleware protocol ROS 2 uses for communication (this is one of the biggest architectural differences from ROS 1).
- tf2 — the library that tracks and transforms coordinate frames over time (e.g., "where is the camera relative to the robot base right now").
- URDF — the XML format describing a robot's physical structure (see Section 10).
- RViz2 — the standard 3D visualization tool for inspecting sensor data, robot state, and planning output.
- rosbag (ROS 2 bag) — records and replays streams of ROS 2 messages, essential for debugging and offline testing.
- Diagnostics — a standardized system for reporting node/hardware health.
- Simulation integration — ROS 2 connects to simulators (primarily Gazebo) via bridge packages so simulated and real robots can use identical ROS 2 code (see Section 11).
- Lyrical Luth — 12th release, LTS, released May 2026, supported until May 2031, targets Ubuntu 26.04 LTS. Recommended for new long-term projects as of this writing.
- Kilted Kaiju — 11th release, standard (non-LTS) release, supported until November 2026, targets Ubuntu 24.04 LTS.
- Jazzy Jalisco — previous LTS (2024), still supported, and still the release most existing tutorials and third-party packages target most heavily as of 2026 — a very reasonable choice if you prioritize tutorial/package maturity over having the newest release.
Always check the official ROS 2 documentation for the current release and its target platform before installing, since this changes yearly.
Do not learn ROS 1 unless you are specifically maintaining or interfacing with a legacy system — its concepts (nodes, topics, services) map closely enough to ROS 2 that there is no benefit to learning it first, and much of its official tooling has reached end-of-life.
A physical robot becomes a software model through:
- URDF (Unified Robot Description Format) — an XML format describing links (rigid bodies) and joints (connections/degrees of freedom) that make up a robot.
- Xacro — an XML macro language layered on top of URDF that lets you parameterize and avoid duplicating repetitive robot description code (e.g., defining a wheel once and reusing it four times).
- Links — individual rigid bodies of the robot (a wheel, an arm segment, the chassis).
- Joints — the connections between links, defining how they can move relative to each other (revolute, prismatic, fixed, continuous).
- Inertial properties — mass, center of mass, and moment of inertia for each link, required for accurate physics simulation.
- Collision models — simplified geometry used for fast collision checking (often simpler shapes than the visual model).
- Visual models — the detailed meshes/geometry used for rendering (in RViz2, Gazebo, etc.).
- TF trees — the runtime hierarchy of coordinate frames (built from the URDF's link/joint structure) that ROS 2's
tf2uses to know where everything is relative to everything else. - robot_state_publisher — a ROS 2 node that reads your URDF and joint states, and publishes the resulting TF tree automatically.
Building a correct URDF is one of the highest-leverage early ROS 2 skills: nearly every simulation, visualization, navigation, and manipulation tool depends on having an accurate robot model.
Simulation lets you validate algorithms, debug logic errors, and iterate rapidly — without risking expensive hardware, without needing physical space, and without the slow cycle time of charging batteries and resetting a physical robot after every crash. Nearly every serious robotics team simulates extensively before deploying to real hardware, and this is more true, not less, for beginners with limited budgets.
- Gazebo — the standard open-source physics-based robot simulator used with ROS 2. As of 2026, the actively maintained release line is Gazebo Ionic (short-term release, supported through December 2026) and Gazebo Jetty (the newest release, paired with ROS 2 Lyrical Luth), with Gazebo Harmonic as the still-supported prior LTS release (paired with ROS 2 Jazzy, supported until May 2029). Check the Gazebo–ROS compatibility documentation for the exact pairing that matches whichever ROS 2 release you install, since Gazebo and ROS 2 are versioned and released independently.
- RViz2 — visualization only, not a physics simulator; shows you sensor data, TF frames, and robot state in 3D, whether that data comes from simulation or real hardware.
- ros_gz — the bridge package family connecting ROS 2 topics to Gazebo's own internal transport, letting simulated sensors/actuators appear as normal ROS 2 topics.
- Visualization (RViz2) — displays existing data; does not compute physics or generate new data.
- Simulation (general term) — any software stand-in for real hardware, which may or may not include realistic physics.
- Physics simulation (Gazebo) — actually computes forces, collisions, gravity, and sensor noise models, so the simulated robot behaves approximately like the real one.
- Hardware-in-the-loop (HIL) — a hybrid setup where some real hardware (e.g., a real flight controller) is connected to a simulated environment, used in more advanced testing pipelines (common in drone and automotive development).
Cameras, depth cameras, 2D/3D LiDAR, IMUs — Gazebo can simulate all of these with configurable noise, letting you test perception and navigation code before you own the physical sensor.
- Spawn a simple differential-drive robot in Gazebo and drive it with keyboard teleoperation.
- Attach a simulated LiDAR and visualize the scan in RViz2.
- Build a simple maze and drive the robot through it manually before attempting autonomy.
- Simulate a basic robotic arm and move it through a sequence of joint positions.
| Sensor | Measures | Strengths | Limitations / failure modes |
|---|---|---|---|
| Ultrasonic | Distance via sound time-of-flight | Cheap, simple | Poor with soft/angled surfaces, narrow beam, slow, cross-talk between multiple units |
| Infrared (IR) | Distance or proximity via reflected light | Cheap, fast | Sensitive to ambient light and surface color/reflectivity |
| Encoders | Shaft rotation (position/velocity) | Precise, essential for closed-loop control | Wheel slip means encoder readings ≠ actual robot motion (this is why odometry drifts) |
| IMU (accelerometer + gyroscope, often + magnetometer) | Orientation, angular velocity, linear acceleration | Fast update rate, works anywhere | Drifts over time (especially the gyroscope integral), magnetometer is sensitive to nearby metal/electronics |
| Cameras | Visual/color image data | Rich information, cheap, passive | No direct depth, sensitive to lighting, requires more compute to process |
| Depth cameras (e.g., stereo, structured light, ToF) | Per-pixel distance | Direct 3D perception, good for close-range manipulation | Limited range, can fail on reflective/transparent/dark surfaces, often struggles outdoors in sunlight |
| LiDAR (2D or 3D) | Precise distance via laser time-of-flight, across a scan | Accurate, long range, works well for mapping and localization | Expensive (especially 3D), can struggle with glass/mirrors, no color/semantic information on its own |
| GPS/GNSS | Absolute global position | Works outdoors over large areas | Useless/unreliable indoors and in "urban canyons," limited accuracy (meters, not centimeters, without augmentation) |
| Force/torque sensors | Contact force and torque, usually at a robot's wrist or gripper | Essential for safe/compliant manipulation | Expensive, adds complexity to mounting and calibration |
For every sensor, also account for: noise (all real sensors are imperfect and must be filtered/fused), sampling rate (how often it produces new data, which limits how fast your control loop can react), calibration (many sensors, especially cameras and IMUs, need calibration procedures for accurate results), and common failure modes (know what a broken or misaligned sensor looks like in your data, or you will mistake sensor failure for a software bug).
| Actuator | How it works | Typical use |
|---|---|---|
| DC motors | Continuous rotation, speed controlled by voltage/PWM | Wheels, simple continuous motion |
| Servo motors | DC (or brushless) motor + gearbox + built-in position feedback | Precise angular position control (arms, steering) |
| Stepper motors | Move in discrete, precise steps | Open-loop precise positioning (3D printers, some arm joints) |
| BLDC (brushless DC) motors | Electronically commutated, no brushes | Higher efficiency/lifespan, common in drones and higher-performance robots |
| Motor controllers/drivers | Electronics interfacing logic-level signals to motor-level power | Required for any motor beyond the smallest hobby servos |
| Encoders (paired with motors) | Feedback on actual position/velocity | Enables closed-loop control (see below) |
Open-loop control sends a command without checking whether it actually happened (e.g., "run this stepper motor for exactly 200 steps and assume it moved exactly that far"). It's simpler but accumulates error and cannot correct for disturbances (a stalled wheel, an unexpected obstacle).
Closed-loop control uses sensor feedback (typically from an encoder) to continuously measure the actual state and correct the command to match a desired target — this is the foundation of PID control and everything built on top of it (Section 14).
- Open-loop control — command without feedback (as above); simplest, least robust.
- Feedback — measuring the actual output and comparing it to the desired output.
- PID control — Proportional-Integral-Derivative control, the single most widely used control algorithm in robotics. It computes a correction based on the current error (P), the accumulated past error (I), and the rate of change of error (D). Almost every beginner and intermediate robotics project (line followers, balancing robots, motor speed control) uses PID somewhere.
- Velocity control — closed-loop control targeting a desired speed.
- Position control — closed-loop control targeting a desired position.
- Trajectory control — closed-loop control tracking a full time-parameterized path, not just a single setpoint.
- State-space models — representing a system's dynamics with state vectors and matrices rather than a single transfer function, enabling more powerful multi-variable control techniques.
- LQR (Linear-Quadratic Regulator) — an optimal control technique that computes a feedback law minimizing a cost function balancing performance and control effort.
- Model Predictive Control (MPC) — repeatedly solves a short-horizon optimization problem in real time, allowing explicit handling of constraints (e.g., "never exceed this joint limit"); increasingly common in modern legged robots, autonomous vehicles, and drones.
- Nonlinear control — techniques for systems where linear approximations break down (e.g., aggressive drone maneuvers, legged locomotion).
A beginner should be fully comfortable with PID (tuning it by hand on a real or simulated motor) before touching anything else in this list. State-space methods, LQR, MPC, and nonlinear control are intermediate-to-advanced topics that matter for research-grade or highly dynamic robots (legged robots, aggressive drone flight) but are not required to build a competent wheeled robot, arm, or navigation stack.
- OpenCV — the standard open-source computer vision library, used for both classical image processing and as glue around deep-learning pipelines.
- Image processing — filtering, thresholding, edge detection, color-space conversion — the classical, non-learned building blocks of vision.
- Feature detection — identifying distinctive, trackable points in an image (used in visual odometry and visual SLAM).
- Object detection — locating and classifying objects in an image (bounding boxes), often via deep learning models today.
- Segmentation — classifying an image pixel-by-pixel (which pixels belong to "floor," "obstacle," "person"), useful for navigation and manipulation.
- Depth perception — estimating distance either from dedicated depth sensors or from stereo/monocular vision algorithms.
- Camera calibration — determining a camera's intrinsic (lens) and extrinsic (position/orientation) parameters, required for any accurate geometric use of camera data.
- SLAM (Simultaneous Localization and Mapping) — building a map of an unknown environment while simultaneously tracking the robot's position within it; can be vision-based, LiDAR-based, or a fusion of both.
- Machine learning / deep learning — used heavily for perception tasks (detection, segmentation, classification) where hand-crafted rules don't generalize well.
- PyTorch — the dominant deep learning framework used in robotics research and increasingly in production as of 2026.
- ONNX — an open format for exporting trained models so they can run efficiently across different runtimes/hardware, common when deploying a model trained in PyTorch onto a robot's onboard compute.
- Edge inference — running trained models directly on the robot (often on GPU/NPU-equipped boards like NVIDIA Jetson) rather than sending data to a remote server, needed for real-time, network-independent operation.
AI/deep learning is genuinely valuable where the problem is hard to hand-specify with rules — recognizing arbitrary objects, understanding complex scenes, adapting to visual variation. Classical algorithms (geometric SLAM, PID, A*/Dijkstra path planning, Kalman filters) remain preferred where the problem has clean mathematical structure, needs to be provably reliable, needs to run with tight real-time and resource guarantees, or needs to be easily debuggable — which describes most of the safety-critical parts of a robot's control stack. In practice, most competent modern robots use classical algorithms for control, state estimation, and low-level planning, and reserve deep learning specifically for perception tasks (what is in the scene) rather than for decision-making about safety-critical actions.
- Odometry — estimating a robot's change in position over time from proprioceptive sensors (wheel encoders, IMU); accumulates drift and cannot be trusted alone for long durations.
- Localization — determining the robot's position within a known map.
- Mapping — building a representation of an unknown environment.
- SLAM — doing both simultaneously, since in most real applications you don't have a pre-existing map and need to build one while navigating.
- AMCL (Adaptive Monte Carlo Localization) — a widely used particle-filter-based localization algorithm for a robot operating within a known, pre-built map.
- Sensor fusion — combining multiple imperfect sensor sources (e.g., wheel odometry + IMU + GPS) into a single, more reliable estimate.
- EKF (Extended Kalman Filter) — the classic algorithm for fusing multiple noisy sensor streams into a smoothed state estimate, commonly used via the ROS 2
robot_localizationpackage. - Path planning — computing a route from the robot's current position to a goal, respecting the map and obstacles (e.g., A*, Dijkstra, RRT).
- Obstacle avoidance — locally adjusting motion to avoid collisions with obstacles that may not be in the static map (e.g., a person walking by).
- Nav2 — the current official ROS 2 navigation stack, integrating path planning, obstacle avoidance, localization, and recovery behaviors into a coherent, configurable system (the direct successor to ROS 1's
move_base).
A typical autonomous mobile robot pipeline: sensor fusion (EKF) combines odometry and IMU data for a continuous local estimate → SLAM or AMCL provides map-relative localization → Nav2's global planner computes a path across the map → Nav2's local planner/controller executes that path while reacting to obstacles in real time.
Building on Section 4's mathematics:
- Forward kinematics — given joint angles, compute the end-effector's position and orientation.
- Inverse kinematics — given a desired end-effector position, compute the required joint angles (generally harder, and can have multiple or zero solutions).
- Jacobians — relate joint velocities to end-effector velocities, used both in control and in numerically solving inverse kinematics.
- Motion planning — computing a full, collision-free path for a manipulator through its joint space, not just a single endpoint.
- Collision checking — verifying a planned motion doesn't collide with the robot itself or its environment.
- Grasping — determining how and where to make contact with an object to pick it up reliably.
- MoveIt 2 — the current official ROS 2 framework for manipulation: motion planning, kinematics, collision checking, and grasp execution, built on top of ROS 2 and typically paired with a URDF-modeled arm.
- Perception-based manipulation — using vision/depth sensing to locate and grasp objects whose position isn't known in advance, combining Sections 15 and 17.
Manipulation is best tackled after you're comfortable with ROS 2 fundamentals, simulation, and basic control (Stages 6–9 in Section 20) — the mathematics (inverse kinematics, Jacobians) and tooling (MoveIt 2) assume that baseline. Attempting manipulation as a first ROS 2 project is one of the more common ways beginners get stuck.
- Ethernet / Wi-Fi — the physical/link-layer connections a robot's compute uses to talk to other machines.
- TCP/IP and UDP — the transport protocols underlying almost all robotics networking; UDP's lower overhead and lack of retransmission delay makes it common for time-sensitive robotics data.
- DDS — ROS 2's default middleware, built on a publish-subscribe model over UDP with configurable reliability (see QoS in Section 9).
- ROS 2 discovery — the process by which ROS 2 nodes automatically find each other on a network, which can require configuration (e.g., using a discovery server) on networks with strict multicast restrictions.
- Robot-to-PC communication — running heavy computation (visualization, planning, teleoperation) on a separate laptop/desktop while the robot itself only runs what it must onboard.
- Remote debugging — SSH-ing into a robot, streaming logs, and using remote visualization (RViz2 running on your laptop, subscribing to the robot's topics over the network).
- Telemetry — continuously streaming robot state/health data back to an operator or logging system.
As soon as a robot involves more than one computer — which is extremely common (an onboard SBC plus an operator's laptop, or a fleet of multiple robots) — networking stops being optional. Debugging "my nodes can see each other on one machine but not across two" is one of the most common intermediate-level ROS 2 problems, and understanding basic networking (and DDS discovery configuration specifically) will save you significant frustration.
Idea
↓
Requirements
↓
Simulation
↓
Prototype
↓
Firmware
↓
ROS 2 package
↓
Testing
↓
Hardware integration
↓
Debugging
↓
Documentation
↓
Release
This is not bureaucracy for its own sake — validating an idea in simulation before writing firmware, and writing firmware before wiring it into a full ROS 2 package, systematically catches cheaper-to-fix problems earlier and avoids debugging multiple new subsystems (mechanical, electrical, and software) simultaneously.
- Git — version control; essential for tracking changes, experimenting safely on branches, and collaborating.
- GitHub — hosting, code review, and project management on top of Git.
- Issues — tracking bugs, tasks, and ideas in a structured, referenceable way.
- Branches — isolating in-progress or experimental work from a known-working main branch.
- Commits — small, well-described, incremental snapshots of your work (a robotics-specific tip: commit working states before attempting risky hardware changes, so you can always revert your software to match).
- README files — the first thing anyone (including future you) reads to understand what a repository does and how to run it.
- Documentation — beyond the README: setup instructions, wiring diagrams, architecture notes — genuinely important in robotics because hardware-specific knowledge is easy to forget or lose when it isn't written down.
- CI (Continuous Integration) — automatically building and testing your code on every change, catching regressions before they reach the robot.
- Testing — unit tests for pure logic, and simulation-based tests for behavior that depends on the physical/simulated world.
- Reproducible builds — pinning dependency versions and documenting your exact ROS 2 distro/OS version so your project can be rebuilt reliably later (or by someone else).
Given your own existing butex-notes and OBS packaging workflows, this section should feel familiar — the same discipline (clear READMEs, structured commits, reproducible environments) that you already apply to your coursework notes and RPM packages carries over directly to robotics projects.
Each stage lists what to learn, why it matters, prerequisites, resources, exercises, project ideas, and criteria to move on.
- What: Variables, control flow, functions; terminal basics, file navigation, SSH.
- Why: Every later stage assumes comfort with a terminal and basic programming logic.
- Prerequisites: None.
- Resources: Ubuntu official tutorials, any beginner Python course (Section 23).
- Exercises: Navigate a filesystem, write a script that reads/writes files, SSH into a Raspberry Pi (or a cloud VM if you don't have hardware yet).
- Projects: A command-line to-do list app; a script that organizes files by type.
- Move on when: You're comfortable in a terminal without constantly looking up basic commands, and can write a 50–100 line Python script from scratch.
- What: Core language, functions, classes, working with libraries (NumPy), reading/writing files, basic object-oriented design.
- Why: Python is the language you'll use for your first ROS 2 nodes and most CV/AI work.
- Prerequisites: Stage 0.
- Resources: Official Python tutorial, Section 23 courses.
- Exercises: Reimplement basic data structures; write a simple simulation of a bouncing ball using just math and printed output.
- Projects: A simple text-based game; a script that plots sensor-like data with matplotlib.
- Move on when: You can comfortably write and debug a multi-file Python program with classes.
- What: Ohm's law, GPIO, PWM, ADC, basic sensors, breadboarding.
- Why: You cannot debug hardware you don't understand electrically.
- Prerequisites: None strictly, but easier alongside Stage 1.
- Resources: Arduino official documentation and starter kit guide, a basic electronics course (Section 23).
- Exercises: Blink an LED; read a potentiometer via ADC; control a servo with PWM.
- Projects: A light-activated LED; a simple button-controlled buzzer.
- Move on when: You can wire and debug a basic circuit from a schematic without step-by-step hand-holding.
- What: Syntax, memory basics (pointers, stack vs. heap), compiling, and — for C++ specifically — classes and the standard library.
- Why: Required for microcontroller firmware and for reading/writing most production ROS 2 code later.
- Prerequisites: Stage 1 (programming fundamentals transfer).
- Resources: Official Arduino language reference, a structured C++ course (Section 23).
- Exercises: Rewrite a Stage 1 Python exercise in C++; write a simple Arduino sketch that reads a sensor and controls an output.
- Projects: An Arduino-based temperature-triggered fan controller.
- Move on when: You can write and debug a moderately complex Arduino sketch (multiple sensors/outputs, basic state logic) without help.
- What: Interrupts, timers, serial communication, ESP32/STM32 basics.
- Why: This is the "close to the metal" layer almost every real robot has.
- Prerequisites: Stages 2–3.
- Resources: ESP32/Arduino official documentation, STM32 HAL documentation (if going further).
- Exercises: Read an encoder using interrupts; send sensor data over serial to a computer.
- Projects: A two-motor robot chassis with basic open-loop driving controlled over serial or Wi-Fi (ESP32).
- Move on when: You've built and debugged at least one project combining multiple sensors/actuators on a microcontroller.
- What: Vectors, matrices, coordinate frames, basic transforms, quaternions conceptually.
- Why: Needed to understand what ROS 2's
tf2and URDF are actually doing. - Prerequisites: Basic algebra/trigonometry (assumed background), Stage 1.
- Resources: A linear algebra refresher course, ROS 2's own
tf2conceptual documentation (Section 23). - Exercises: Manually compute a 2D rotation and translation of a point by hand, then verify with code.
- Projects: A small script that visualizes coordinate frame transforms in 2D.
- Move on when: You can explain, in your own words, what a coordinate frame transform is and why a robot needs multiple frames.
- What: Nodes, topics, services, actions, launch files, packages, workspaces,
colcon. - Why: This is the core middleware skill for essentially all further robotics work.
- Prerequisites: Stages 1, 3 (Python and C++ basics), Stage 5 helpful.
- Resources: Official ROS 2 tutorials (use whichever current distro you installed, per Section 9).
- Exercises: Complete the official "writing a simple publisher and subscriber" tutorial in both Python and C++; write your own custom message type.
- Projects: A ROS 2 package with two nodes (e.g., a "sensor simulator" node and a "logger" node) communicating over a custom topic.
- Move on when: You can create a new ROS 2 package, write a working node, and launch a multi-node system from a launch file without following a tutorial verbatim.
- What: URDF/Xacro modeling, Gazebo,
ros_gz, RViz2. - Why: Lets you test full robot software before (or instead of) building hardware.
- Prerequisites: Stage 6.
- Resources: Gazebo official documentation, ROS 2's URDF tutorials.
- Exercises: Write a URDF for a simple differential-drive robot; spawn it in Gazebo; drive it with
teleop_twist_keyboard. - Projects: A simulated robot navigating a simple maze using manual teleoperation, with sensor data visualized in RViz2.
- Move on when: You can model, spawn, and drive a custom robot in simulation from scratch.
- What: Integrating real sensors/motors with ROS 2 drivers; encoder-based closed-loop driving.
- Why: Bridges your simulation and embedded-systems knowledge into a working real robot.
- Prerequisites: Stages 4, 6, 7.
- Resources: Manufacturer documentation for your specific sensors/motor drivers; micro-ROS documentation if bridging a microcontroller.
- Exercises: Publish real IMU or encoder data as a ROS 2 topic; drive a real motor from a ROS 2 node.
- Projects: A real (or micro-ROS-bridged) differential-drive robot that can be teleoperated and whose real sensor data appears correctly in RViz2.
- Move on when: Your real robot's sensor data and motor control both work reliably through ROS 2, matching what you validated in simulation.
- What: PID tuning, velocity/position control loops.
- Why: Converts commanded velocities/positions into precise, stable real-world motion.
- Prerequisites: Stage 8.
- Resources: A focused PID tutorial/course (Section 23); ROS 2
ros2_controldocumentation. - Exercises: Hand-tune a PID controller for wheel velocity on your real or simulated robot.
- Projects: A closed-loop line-following or wall-following robot using PID.
- Move on when: You can explain what happens (and why) when you change each of the P, I, and D gains, and can tune a controller without trial-and-error alone.
- What: Odometry, sensor fusion (EKF via
robot_localization), SLAM, AMCL, Nav2. - Why: This is what turns a drivable robot into an autonomous one.
- Prerequisites: Stages 7–9.
- Resources: Official Nav2 documentation and tutorials.
- Exercises: Run SLAM to build a map of a simulated (then real) environment; localize within that map using AMCL; send a navigation goal via Nav2.
- Projects: A robot that autonomously navigates a mapped room to a goal point, avoiding dynamic obstacles.
- Move on when: You can map a new environment and command reliable autonomous navigation within it.
- What: OpenCV fundamentals, camera calibration, basic object detection.
- Why: Adds semantic understanding of the environment beyond geometric sensors.
- Prerequisites: Stage 1 (Python), Stage 5 (math helps).
- Resources: Official OpenCV documentation and tutorials.
- Exercises: Calibrate a real camera; detect a colored object and publish its position as a ROS 2 topic.
- Projects: A robot that visually detects and drives toward (or away from) a specific colored object.
- Move on when: You can build a basic perception pipeline that reliably feeds useful information into your robot's decision-making.
- What: Forward/inverse kinematics in practice, MoveIt 2, grasping basics.
- Why: Extends robotics from mobility into physical interaction with objects.
- Prerequisites: Stages 6, 7, 9, ideally 11.
- Resources: Official MoveIt 2 documentation and tutorials.
- Exercises: Model a simple arm in URDF; configure it in MoveIt 2; plan and execute a pick motion in simulation.
- Projects: A simulated (then real, if hardware allows) arm that picks up an object detected via computer vision.
- Move on when: You can plan and execute non-trivial motions with MoveIt 2, respecting collisions.
- What: Whatever your target specialization demands: legged locomotion, multi-robot systems, advanced control (MPC), deep-learning-based perception/planning, research-level SLAM.
- Why: This is where you specialize based on the career path or project domain you care about (see Section 27).
- Prerequisites: Stages 0–12.
- Resources: Domain-specific papers, advanced university courses, specialized open-source projects (Section 23).
- Exercises/Projects: Domain-specific (see Section 21's advanced tier for starting points).
- Move on when: N/A — this stage is open-ended and matches how professional robotics careers continue to develop over years.
| Project | Hardware | Software | Skills learned | Difficulty | Extensions |
|---|---|---|---|---|---|
| LED controller | Arduino/ESP32, LED, resistor | Arduino IDE (C/C++) | GPIO, digital output | ★☆☆☆☆ | Add multiple LEDs, patterns |
| Button/input project | Arduino, pushbutton | Arduino IDE | Digital input, debouncing | ★☆☆☆☆ | Add a counter, debounce in software |
| Ultrasonic distance sensor | Arduino, HC-SR04 (or similar) | Arduino IDE | Timing-based sensing, serial output | ★★☆☆☆ | Trigger an alert past a threshold |
| Servo control | Arduino/ESP32, servo motor | Arduino IDE | PWM, actuator control | ★★☆☆☆ | Sweep pattern, potentiometer-controlled angle |
| Motor control | Arduino, DC motor, motor driver | Arduino IDE | PWM, H-bridge wiring | ★★☆☆☆ | Add direction control, speed ramping |
| Line follower | Arduino/ESP32, IR sensors, motors, motor driver | Arduino IDE | Sensor fusion (simple), reactive control | ★★★☆☆ | Add PID for smoother following |
| Project | Hardware | Software | Skills learned | Difficulty | Extensions |
|---|---|---|---|---|---|
| Encoder-based robot | Motors with encoders, microcontroller | Arduino/ROS 2 (via micro-ROS) | Closed-loop feedback basics | ★★★☆☆ | Compute and log real-world odometry |
| PID motor controller | Motor + encoder, microcontroller | Arduino/ROS 2 | PID tuning | ★★★☆☆ | Auto-tuning, comparing P vs. PI vs. PID |
| Obstacle-avoiding robot | Ultrasonic/IR sensors, motors | ROS 2 or Arduino | Reactive behaviors | ★★★☆☆ | Add multiple sensors, smarter avoidance logic |
| Differential-drive robot | Two motors + encoders, chassis, SBC + microcontroller | ROS 2, micro-ROS | Full mobile robot integration | ★★★★☆ | Add teleoperation, odometry publishing |
| ROS 2 teleoperation | Any drivable robot (real or simulated) | ROS 2 (teleop_twist_keyboard, custom nodes) |
Topics, cmd_vel, launch files |
★★★☆☆ | Build a custom joystick/web-based controller |
| Simulated robot in Gazebo | None (simulation only) | ROS 2, Gazebo, URDF | Robot modeling, simulation | ★★★☆☆ | Add sensors, test navigation logic |
| Project | Hardware | Software | Skills learned | Difficulty | Extensions |
|---|---|---|---|---|---|
| Autonomous mobile robot | Full differential-drive platform, LiDAR/depth camera, SBC | ROS 2, Nav2 | Full autonomy stack integration | ★★★★☆ | Multi-floor mapping, dynamic re-planning |
| SLAM robot | LiDAR or depth camera, mobile platform | ROS 2 SLAM packages (e.g., slam_toolbox) |
Mapping, localization | ★★★★☆ | Loop closure tuning, multi-session mapping |
| Nav2 robot | Mobile platform, LiDAR | ROS 2, Nav2 | Path planning, recovery behaviors | ★★★★☆ | Custom behavior trees, dynamic obstacle handling |
| Computer-vision robot | Camera, mobile or arm platform | ROS 2, OpenCV, PyTorch | Perception-driven behavior | ★★★★☆ | Real-time object tracking, deep-learning detection |
| Robotic arm | Servo/stepper-based arm kit or custom build | ROS 2, URDF, MoveIt 2 | Kinematics, motion planning | ★★★★★ | Add a gripper, closed-loop joint control |
| MoveIt 2 manipulation project | Robotic arm, gripper, camera | ROS 2, MoveIt 2, OpenCV | End-to-end perception-to-manipulation pipeline | ★★★★★ | Pick-and-place sorting by object type |
| Multi-sensor autonomous robot | LiDAR + depth camera + IMU + GPS (outdoor) | ROS 2, Nav2, sensor fusion (robot_localization) |
Full-stack integration at production complexity | ★★★★★ | Outdoor operation, long-duration autonomy |
A capable laptop or desktop running Ubuntu LTS (or Ubuntu in a VM/WSL2 — note some simulators perform poorly virtualized) is enough to learn Python, C++, ROS 2 fundamentals, URDF modeling, and Gazebo simulation end-to-end, including navigation and manipulation, without any physical robot. This is a genuinely complete way to work through Stages 0–12 in Section 20 before spending any money.
An Arduino Uno or ESP32 development board, a small chassis kit with two DC motors and wheels, a basic motor driver (e.g., an L298N-style board), an ultrasonic or IR distance sensor, a battery pack, and a breadboard/jumper wires. This is enough for Stage 2–4 electronics/embedded projects and the beginner project tier in Section 21.
A Raspberry Pi (or comparable SBC) as the "brain" running Ubuntu/ROS 2, paired with a microcontroller (ESP32/STM32) running micro-ROS for real-time motor/encoder control, a motor driver, a basic 2D LiDAR or depth camera, and a more capable chassis with encoders on the motors. This range covers Stage 8–10 projects: a real robot that can be teleoperated, mapped, and navigated autonomously.
A serious mobile robot platform (either a commercial kit like a TurtleBot-class robot, or a well-designed custom chassis) with a proper 2D/3D LiDAR, a depth camera, an IMU, and a more powerful SBC (e.g., an NVIDIA Jetson if you want onboard deep-learning inference) — or, for the manipulation branch, a robot arm with genuine closed-loop joint control (not just open-loop hobby servos) capable of running MoveIt 2 in a meaningful way.
Worth it: motors with built-in encoders (open-loop motors are a common source of frustration once you try closed-loop control later), a real LiDAR or depth camera once you reach the navigation stage (ultrasonic-only "mapping" is extremely limited), and a battery/power system with real capacity headroom (undersized batteries cause voltage sag that looks exactly like intermittent software bugs).
Avoid buying just because it's popular: an expensive humanoid or advanced arm before you've completed the intermediate project tier — the mathematics and software prerequisites (Sections 4, 17, Stage 12) make these frustrating rather than educational if attempted too early; and buying multiple different microcontroller families "just in case" — pick one ecosystem (Arduino/ESP32 is the most beginner-friendly) and go deep before diversifying.
Links were current as of research in August 2026. Verify official documentation links directly before relying on them, since URLs and content structures do occasionally change.
| Resource | Level | Topic | Cost | Why it's useful |
|---|---|---|---|---|
| ROS 2 Documentation | All | ROS 2 | Free | The single most authoritative ROS 2 reference and tutorial set |
| Open Robotics / ROS Discourse | All | ROS 2 ecosystem news, Q&A | Free | Official announcements and community discussion in one place |
| Gazebo Documentation | Beginner–Advanced | Simulation | Free | Official simulator docs, including ROS 2 compatibility tables |
| micro-ROS Documentation | Intermediate | Embedded + ROS 2 | Free | Official bridge between microcontroller firmware and ROS 2 |
| Arduino Documentation | Beginner | Embedded/electronics | Free | The standard beginner embedded reference |
| Raspberry Pi Documentation | Beginner–Intermediate | SBC setup, GPIO | Free | Official setup and hardware interfacing guides |
| Nav2 Documentation | Intermediate–Advanced | Navigation | Free | Official ROS 2 navigation stack reference |
| MoveIt 2 Documentation | Intermediate–Advanced | Manipulation | Free | Official ROS 2 manipulation framework reference |
| OpenCV Documentation | Beginner–Advanced | Computer vision | Free | Official CV library reference and tutorials |
| Resource | Level | Topic | Why it's useful |
|---|---|---|---|
| The Construct's ROS 2 courses (free tier) | Beginner–Intermediate | ROS 2 | Browser-based ROS 2 exercises, no local setup required to start |
| Articulated Robotics (YouTube) | Beginner–Intermediate | ROS 2, from-scratch robot building | Practical, real-hardware-focused, widely regarded as excellent for beginners |
| Robotics Back-End | Beginner–Intermediate | ROS 2 | Clear, focused written tutorials on individual ROS 2 concepts |
| Resource | Level | Topic | Why it's useful |
|---|---|---|---|
| The Construct's ROS 2 Developer paths | Beginner–Advanced | ROS 2, Nav2, MoveIt 2 | Structured, project-based, simulation-first curriculum |
| Udemy ROS 2 courses (search current offerings) | Beginner–Intermediate | ROS 2 fundamentals | Inexpensive, self-paced; quality varies — check recent reviews and ROS 2 (not ROS 1) currency before buying |
| Resource | Level | Topic | Why it's useful |
|---|---|---|---|
| MIT OpenCourseWare — Introduction to Robotics | Intermediate | Kinematics, dynamics, control | Rigorous, free, foundational theory |
| Stanford Engineering Everywhere / CS courses on robotics and AI | Intermediate–Advanced | Robotics, AI | Free, university-grade depth |
| ETH Zürich / University of Pennsylvania robotics course materials (published openly by several labs) | Advanced | SLAM, planning, control | Research-adjacent, rigorous, often accompanied by real assignments |
- Articulated Robotics — from-scratch real robot builds with ROS 2, strongly recommended for beginners.
- The Construct — ROS 2 tutorials and news.
- Real-time robotics/perception researchers' channels (e.g., conference talk recordings from ICRA/IROS, published by the conferences themselves) — for later-stage, research-level exposure.
See Section 24.
- Gazebo (installed locally) — the primary interactive simulator for ROS 2 robotics.
- The Construct's browser-based ROS 2 simulation environments — useful if you want to try ROS 2 before installing anything locally.
- ROS Discourse — official ROS 2 community forum.
- r/robotics and r/ROS — active community discussion, project sharing, troubleshooting.
- Robotics Stack Exchange — Q&A specifically for robotics.
- ros2/ros2 — the core ROS 2 meta-repository.
- ros-planning/navigation2 — Nav2 source.
- moveit/moveit2 — MoveIt 2 source.
- gazebosim — Gazebo's organization, including
ros_gz.
See Section 25.
- IEEE ICRA and IROS — the two flagship annual robotics research conferences; their papers (often available as preprints) represent the current state of the art.
- arXiv's
cs.ROcategory — a continuous stream of robotics research preprints, useful once you're ready for research-level reading.
| Book | Topic | Who it's for |
|---|---|---|
| Introduction to Robotics: Mechanics and Control — John J. Craig | Robotics fundamentals, kinematics | Readers who want the classical mechanical/mathematical foundation of manipulator robotics |
| Modern Robotics: Mechanics, Planning, and Control — Kevin Lynch & Frank Park (also free online) | Robotics fundamentals, kinematics, planning | A more modern, freely available alternative/companion to Craig's book |
| Probabilistic Robotics — Sebastian Thrun, Wolfram Burgard, Dieter Fox | Localization, mapping, SLAM, sensor fusion | Anyone going deep on SLAM/localization; considered a standard reference |
| A Gentle Introduction to ROS — Jason M. O'Kane (free online) | ROS concepts (originally ROS 1, concepts transfer) | Absolute beginners wanting a conceptual, non-intimidating introduction before diving into official ROS 2 docs |
| Programming Robots with ROS — Morgan Quigley, Brian Gerkey, William D. Smart | Practical ROS development (originally ROS 1-era, concepts largely transfer) | Readers who want a practical, project-based companion to official docs |
| Feedback Control of Dynamic Systems — Gene F. Franklin, J. David Powell, Abbas Emami-Naeini | Control theory | Readers who want a rigorous, standard control systems textbook |
| Computer Vision: Algorithms and Applications — Richard Szeliski (free online) | Computer vision | Readers going deep into CV beyond OpenCV tutorials |
| Making Embedded Systems — Elecia White | Embedded systems | Readers moving from Arduino-level projects to more serious embedded firmware practice |
| Practical Electronics for Inventors — Paul Scherz & Simon Monk | Electronics | Readers who want a comprehensive, hands-on electronics reference beyond "blink an LED" |
- ROS Discourse — the official venue for ROS 2 announcements, RFCs, and community Q&A; worth lurking on regularly once you're past the absolute basics.
- GitHub — beyond hosting your own code, following and reading issues/PRs on major robotics repositories (ROS 2 core, Nav2, MoveIt 2) is one of the highest-value ways to learn how experienced maintainers reason about real problems.
- Reddit (r/robotics, r/ROS) — good for project sharing, troubleshooting, and staying current with community sentiment on tools.
- University robotics clubs — if you're at BUTEX or any university with a robotics club or team, this is one of the fastest ways to get hands-on hardware experience and mentorship; if none exists, starting one (even informally, around a shared Discord/GitHub org) is a well-trodden path.
- RoboCup — a long-running international robotics competition spanning several leagues (soccer, rescue, home service robots); a strong target for teams wanting a multi-year, community-supported goal.
- FIRST Robotics Competition (FRC) / FIRST Tech Challenge (FTC) — primarily pre-university, but a well-established on-ramp into mechanical + electrical + software teamwork if you're mentoring or have younger relatives interested in robotics.
- University-hosted robotics/AI hackathons — shorter-format events that are excellent for forcing rapid, practical application of what you've learned.
- Kaggle — relevant specifically for the computer vision/machine learning components of robotics (not robotics-specific, but useful for building CV/ML skill in isolation before integrating it onto a robot).
Don't join a competition as your very first hands-on robotics activity — spend at least Stages 0–8 of Section 20 building foundational, individual competence first, so you can contribute meaningfully to a team rather than being a passenger. When you do join, pick one subsystem (e.g., "I own the navigation stack" or "I own the perception pipeline") rather than trying to touch everything — depth on one subsystem, combined with the ability to interface cleanly with teammates' subsystems, is what actually makes competition teams function well and is also the most realistic preview of how professional robotics teams are organized.
- Project-based learning over passive tutorials. Robotics is a field where reading about a concept and being able to apply it are far apart; prioritize building something (even something small and imperfect) over consuming more tutorial content.
- Theory vs. practice. Learn just enough theory to understand why a tool/algorithm works before using it, then return to deepen the theory once you've felt the practical problem it solves firsthand — this order (light theory → practice → deeper theory) tends to stick better than theory-first for most learners.
- Simulation vs. hardware. Use simulation to iterate on logic quickly and cheaply; move to real hardware specifically to learn what simulation can't teach you (noise, friction, wiring, power issues, timing) — treat the gap between simulated and real behavior as itself an important thing to study, not just an annoyance.
- Reading documentation. Official documentation (Section 23) should be your primary reference, not a last resort after searching random blog posts — robotics tooling changes yearly (Section 9's release cadence, for example), and outdated tutorials are one of the most common sources of beginner confusion.
- Debugging as a skill. Treat debugging systematically: reproduce the problem reliably, isolate which layer of the stack (Section 2) it's in, and check the simplest possible explanation (loose wire, wrong device path, unit mismatch) before assuming a complex software bug.
- Reproducing existing projects. Before designing your own project from scratch, reproduce a well-documented existing one exactly — this reveals gaps in your environment/setup knowledge without also debugging novel logic at the same time.
- Modifying existing robots/code. Once you've reproduced something working, modify it incrementally (change one sensor, one algorithm, one parameter at a time) — this builds intuition faster than always starting from a blank file.
- Writing technical notes. Given your existing
butex-noteshabit, apply the same structured note-taking to robotics: wiring diagrams, debugging logs, "why did I choose this gear ratio" reasoning — this becomes genuinely valuable reference material within a few months. - Keeping a GitHub portfolio. Publish your projects, even small/incomplete ones, with clear READMEs — this is both a learning aid (writing documentation clarifies your own understanding) and, later, a genuine portfolio artifact for career purposes (Section 27).
| Day | Focus |
|---|---|
| 2 weekdays | New concept/tutorial (30–60 min) |
| 2 weekdays | Hands-on project work applying that concept (60–90 min) |
| 1 weekend day | Longer project session (2–4 hours) — build, debug, iterate |
| 1 weekend day | Documentation/notes + light review of what didn't work and why |
| 1 day | Rest or light reading (community forums, a paper, a book chapter) |
Consistency over a period of months matters far more than occasional long, exhausting sessions — robotics has a real prerequisite chain (Section 20), and steady progress through it compounds.
| Career path | Languages | Mathematics | Tools | Typical projects | Education | Portfolio should show |
|---|---|---|---|---|---|---|
| Robotics software engineer | C++, Python | Linear algebra, basic control | ROS 2, Git, Linux | General-purpose autonomous robot software | CS/robotics/EE degree common but not universal; strong portfolio can substitute | End-to-end ROS 2 systems, clean software architecture |
| Embedded engineer | C, C++ | Basic calculus, discrete math | STM32/ESP32 toolchains, RTOS, oscilloscopes | Firmware for sensors/actuators, real-time systems | EE/CS degree common | Firmware projects with clear real-time constraints handled correctly |
| Controls engineer | C++, MATLAB/Simulink, Python | Differential equations, linear algebra, control theory (state-space, LQR, MPC) | MATLAB/Simulink, ROS 2 ros2_control |
PID/MPC controllers for real physical systems | Mechanical/EE/controls-focused degree common | Demonstrated, tuned controllers on real or simulated hardware with performance analysis |
| Perception engineer | Python, C++ | Linear algebra, probability, geometry | OpenCV, PyTorch, point-cloud libraries | Object detection, SLAM front-ends, sensor fusion | CS/robotics degree, often with CV/ML specialization | CV/perception pipelines with measured accuracy/performance |
| Autonomy engineer | C++, Python | Probability, optimization, control | Nav2, MoveIt 2, planning libraries | Full autonomous decision-making stacks | CS/robotics degree | Demonstrated autonomous behavior (navigation, manipulation) in real or simulated environments |
| ROS 2 engineer | C++, Python | Linear algebra | ROS 2 internals, DDS, colcon |
Middleware, drivers, ROS 2 tooling/package development | CS/EE degree | Contributions to ROS 2 ecosystem packages, well-structured custom packages |
| Roboticist / researcher | Python, C++, sometimes Julia/MATLAB | Strong across the board (Section 4), plus research-methods statistics | Simulation, research codebases, LaTeX for papers | Novel algorithms, published research | Graduate degree (MS/PhD) typically expected | Publications, open-source research code, reproducible experiments |
| Computer vision engineer | Python, C++ | Linear algebra, probability, geometry, optimization | OpenCV, PyTorch, ONNX | Detection, segmentation, visual SLAM | CS degree, often CV/ML-focused | Demonstrated, quantitatively evaluated CV pipelines |
| Mechatronics engineer | C/C++, some Python | Mechanics, electronics, control | CAD tools, electronics design tools, microcontroller toolchains | Integrated mechanical + electrical + firmware systems | Mechanical or mechatronics engineering degree | Complete physical builds (not just software) with documented design decisions |
| Hardware engineer | Limited (mostly firmware-adjacent C) | Electronics, some mechanics | PCB design tools, oscilloscopes, multimeters | Custom PCBs, sensor boards, power systems | EE degree | Designed and validated PCBs/circuits, not just breadboard prototypes |
Note that in practice these roles overlap heavily at small companies and in early-career positions — the table represents where emphasis differs, not a strict boundary.
- Learning ROS before learning programming. ROS 2 assumes working programming fluency; trying to learn Python/C++ through ROS 2 tutorials makes both harder to learn.
- Buying expensive hardware too early. Simulation (Section 11) can validate most software decisions first; expensive hardware bought before you know what you actually need is a common source of wasted money and discouragement.
- Ignoring electronics. Treating the robot as a "pure software problem" leads to debugging software for hours when the actual issue is a loose wire, wrong voltage, or undersized motor driver.
- Ignoring mathematics. Skipping Section 4 makes ROS 2's
tf2, URDF, SLAM, and manipulation feel like unexplainable "magic" rather than understandable systems. - Blindly copying ROS tutorials. Copying code without understanding node/topic architecture means you can't debug or extend it when your project inevitably diverges from the tutorial.
- Using outdated ROS 1 tutorials. ROS 1 is past end-of-life for new projects (Section 9); its APIs, tools, and idioms differ enough from ROS 2 that following ROS 1 material as a beginner actively teaches wrong habits.
- Skipping simulation. Going straight to hardware means every bug is expensive (in time, and sometimes in damaged components) to reproduce and fix.
- Learning too many languages simultaneously. Trying to learn Python, C++, and Rust at once (for example) slows all three down; follow the progression in Section 3.
- Building projects without understanding them. Completing a tutorial project without being able to explain what each part does means the "project" didn't actually build competence.
- Ignoring Git. Working without version control means losing working states, being unable to safely experiment, and (in team settings) being unable to collaborate.
- Ignoring debugging as a skill. Treating every bug as a mystery to be solved by trial-and-error, rather than systematically isolating the failing layer (Section 2), wastes enormous time.
- Jumping into AI before understanding robotics fundamentals. Deep learning is a powerful tool for perception specifically (Section 15), not a substitute for understanding control, kinematics, and system architecture — attempting an "AI robot" before Stages 0–9 usually produces a fragile project that's hard to debug because too many unknowns are stacked at once.
| Technology | Recommendation | When |
|---|---|---|
| Linux distribution | Ubuntu LTS (24.04 or 26.04, matched to your chosen ROS 2 distro) | Now |
| Python | Yes, learn first | Now |
| C++ | Yes, learn after Python fluency | Early (Stage 3) |
| Git | Yes | Now, alongside Stage 0 |
| Editor | VS Code (excellent ROS 2/C++/Python tooling) or Neovim if you already have a strong terminal-editor workflow (as you do) | Now |
| ROS 2 | Yes — current LTS (Lyrical Luth) for new long-term projects, or Jazzy Jalisco if you want maximum tutorial/package maturity | Stage 6 |
| Gazebo | Yes — the version matched to your ROS 2 distro per the official compatibility docs | Stage 7 |
| RViz2 | Yes, comes with ROS 2 | Stage 6–7 |
| Arduino / ESP32 | Yes, for your first embedded projects | Stage 2–4 |
| Raspberry Pi | Yes, as an accessible "robot brain" SBC | Stage 8, when moving to real hardware |
| OpenCV | Yes | Stage 11 |
| PyTorch | Later — once you have a concrete perception task that needs learned models, not before | Stage 11+, as needed |
| Nav2 | Yes | Stage 10 |
| MoveIt 2 | Yes, only if pursuing manipulation | Stage 12 |
| micro-ROS | Yes, once bridging a microcontroller to ROS 2 | Stage 8 |
| Rust | Optional/later specialization | Advanced, only if your target role/project calls for it |
| MATLAB/Simulink | Optional | Only if your coursework/job specifically requires it for control design |
Do not adopt every technology in this list immediately — each is tied to a specific stage in Section 20, and introducing it earlier than the recommended stage tends to add confusion rather than capability.
Programming
↓
Linux
↓
Electronics
↓
C/C++
↓
Microcontrollers
↓
Robotics Mathematics
↓
ROS 2
↓
Simulation
↓
Sensors + Motors
↓
Control
↓
Navigation / SLAM
↓
Computer Vision
↓
Manipulation
↓
Advanced Robotics
Comfortable Python and basic C++, a working Linux/terminal/Git workflow, foundational electronics (Ohm's law through PWM/ADC), and 2–3 completed beginner Arduino projects (Section 21). You will not be doing ROS 2 or autonomous navigation yet, and that's expected — this stage is about fundamentals, not robots that look impressive.
Everything above, plus: comfortable ROS 2 fundamentals (nodes/topics/services/launch files) in both Python and C++, a URDF-modeled robot running in Gazebo simulation, and your first real (or micro-ROS-bridged) hardware integration in progress. A realistic outcome at 6 months is a simulated, teleoperated robot and a partially-working real one — not yet a fully autonomous system.
Everything above, plus: closed-loop PID control on real hardware, a working SLAM-and-navigate pipeline (build a map, localize, autonomously navigate to a goal) either in simulation or on real hardware, and your first computer vision integration. A realistic outcome at 12 months is a genuinely autonomous mobile robot for a constrained environment (e.g., a mapped room), built and understood end-to-end by you — a strong portfolio project.
Specialization into a specific career path (Section 27) — manipulation, perception, controls, or a specific robot domain (Section 1's table) — through progressively larger, self-directed projects, competition participation (Section 25), and eventually contributing to open-source robotics packages or publishing your own well-documented work. Genuine competence in robotics, the kind that survives a real job interview or a real deployed system, realistically takes multiple years of consistent, project-driven learning — this roadmap gets you a strong, honest foundation, not a shortcut around that timeline.
Key version/release facts in this document (ROS 2 Lyrical Luth and Kilted Kaiju release details, Gazebo Ionic/Jetty/Harmonic support windows, Ubuntu 26.04 LTS, current Raspberry Pi model guidance) were verified against official documentation and release pages as of August 2026:
- ROS 2 official release documentation and news — docs.ros.org / openrobotics.org
- Gazebo official documentation — gazebosim.org/docs
ros_gzcompatibility table — github.com/gazebosim/ros_gz- Raspberry Pi official product and documentation pages — raspberrypi.com
Because ROS 2 and Gazebo both follow a yearly release cycle, re-check the official documentation links above before starting a new project, even if you're reading this guide only a few months after it was written.