AI Consulting and Training Club, Bahria Town Lahore

Category: Self Study Courses

  • Linux for Robotics – Foundations

    Welcome, future roboticist! This 16-week course is your launchpad into the world of robotics development. The single most important tool in a roboticist’s arsenal isn’t a soldering iron or a 3D printer—it’s the operating system. Linux is the undisputed king of the robotics world, powering everything from small hobbyist rovers to the Mars Helicopter, Ingenuity. This course demystifies the Linux command line and transforms it from an intimidating black screen into your most powerful ally. We will journey from the absolute basics of terminal commands to the practical skills needed to manage, develop, and deploy software on a robotic system. By the end, you’ll be comfortable navigating the Linux environment, writing simple automation scripts, and managing the software that brings robots to life, with a special focus on the Robot Operating System (ROS). This is not just a course about typing commands; it’s about learning to think like a roboticist.

     

    Primary Learning Objectives

     

    Upon successful completion of this course, you will be able to:

    • Master the Command Line: Confidently navigate the Linux filesystem, manipulate files and directories, and manage user permissions.
    • Automate and Control: Write practical Bash scripts to automate repetitive tasks and manage system processes.
    • Manage Software: Install, update, and manage software packages using package managers and build complex software from source code.
    • Network and Collaborate: Connect to remote systems (like a robot) using SSH and manage your code using Git for version control.
    • Integrate with ROS: Understand the fundamental architecture of the Robot Operating System (ROS) and be able to compile, run, and inspect basic ROS nodes.
    • Apply Knowledge: Synthesize learned skills to set up and control a simulated robot in a final capstone project.

     

    Necessary Materials

     

    1. A Computer: A laptop or desktop computer with at least 8GB of RAM and 40GB of free disk space.
    2. Operating System: You have two main options:
      • Dedicated Installation (Recommended): Install Ubuntu 22.04 LTS as your primary OS or in a dual-boot configuration. This provides the best performance.
      • Virtual Machine (Easiest Start): Install VirtualBox (free) or VMware Workstation Player and then install Ubuntu 22.04 LTS inside a virtual machine.
    3. Internet Connection: Required for downloading software and accessing documentation.
    4. (Optional but Highly Recommended for later lessons): A Raspberry Pi 4 (4GB or 8GB model) with a 32GB+ microSD card. This will provide invaluable experience with hardware common in robotics.

     

    Course Structure (16 Weeks)

     

    • Weeks 1-14: Core Lessons
    • Week 15: Review and Final Project Work
    • Week 16: Final Project Submission and Course Wrap-up

     

    Week 1: The Command Line is Your Cockpit

     

    • Objectives:
      1. Understand why Linux is dominant in robotics.
      2. Learn the basic structure of a command: command [options] [arguments].
      3. Navigate the filesystem using pwd, ls, and cd.
    • Key Vocabulary:
      • Kernel: The core of the operating system that manages the CPU, memory, and peripherals.
      • Shell: A program that takes commands from the keyboard and gives them to the operating system to perform. Bash (Bourne Again SHell) is the most common one.
      • Terminal: A program that opens a window and lets you interact with the Shell.
      • Filesystem: The hierarchical structure of directories and files in an operating system.
      • Root Directory (/): The top-level directory of the filesystem.
    • Lesson Content:

      Welcome to the command line! If you’re used to clicking on icons, this might feel like a step back in time. But for a roboticist, it’s a step into the cockpit. A graphical user interface (GUI) is like a passenger’s window—you can see where you’re going. The command-line interface (CLI) is the control panel—it lets you fly the plane. In robotics, you need precise, repeatable, and scriptable control over your system, which is exactly what the CLI provides.

      Linux is open-source, stable, and incredibly flexible. It gives you direct access to hardware and system processes, which is critical when you’re debugging why a motor isn’t spinning or a sensor isn’t responding.

      Let’s start with the three most fundamental commands for navigation.

      1. pwd (Print Working Directory): This command tells you where you are right now in the filesystem.
      2. ls (List): This lists the contents of your current directory.
      3. cd (Change Directory): This moves you to a different directory.

      Commands often have options (or flags), which modify their behavior. These usually start with a dash (-). For example, ls -l will show a “long” list with more details. The things you act upon are arguments. For example, in cd Documents, Documents is the argument.

    • Hands-on Examples:
      1. Open your terminal.
      2. Type pwd and press Enter. It will probably show you something like /home/yourusername. This is your home directory.
      3. Type ls to see what’s in your home directory. You should see folders like Documents, Downloads, Music, etc.
      4. Type ls -a. The -a flag shows all files, including hidden ones (which start with a .).
      5. Let’s move. Type cd / to go to the root directory, the very top of the filesystem.
      6. Now type ls. You’ll see a very different set of folders: bin, etc, home, var, etc. This is the core of the OS!
      7. Let’s go back home. The tilde symbol ~ is a shortcut for your home directory. Type cd ~.
      8. Type pwd again to confirm you are back where you started.

     

    Week 2: Manipulating Files and Controlling Access

     

    • Objectives:
      1. Create, copy, move, and delete files and directories.
      2. Understand the basics of Linux file permissions.
      3. Learn to view file contents without opening an editor.
    • Key Vocabulary:
      • Permissions (rwx): Read (r), Write (w), and Execute (x) rights for a file or directory.
      • Owner, Group, Other: The three categories of users whose permissions are defined for a file.
      • sudo: A command that means “Super User Do,” allowing you to run a command with administrator (or “root”) privileges.
    • Lesson Content:

      Now that you can navigate, it’s time to interact with the world around you. In robotics, you’ll constantly be creating log files, moving datasets, and creating directories to organize your code.

      Here are the essential commands for file manipulation:

      • touch <filename>: Creates a new, empty file.
      • mkdir <dirname>: Creates a new directory.
      • cp <source> <destination>: Copies a file or directory.
      • mv <source> <destination>: Moves or renames a file or directory.
      • rm <filename>: Deletes a file. Be careful! There is no undo or trash bin in the default CLI.
      • rmdir <dirname>: Deletes an empty directory. (Use rm -r to delete a directory and all its contents).

      Permissions are a core security feature of Linux. When you type ls -l, you’ll see something like -rwxr-xr--.

      • The first character (-) indicates the file type (d for directory).
      • The next three (rwx) are the owner’s permissions.
      • The next three (r-x) are the group’s permissions.
      • The final three (r–) are for everyone else.

        We can change these permissions with the chmod command, which is vital for making our scripts executable.

      Finally, to peek inside files, we can use:

      • cat <filename>: Prints the entire file content to the terminal.
      • less <filename>: Lets you view a file page by page (press q to quit).
      • head/tail <filename>: Shows the first/last 10 lines of a file.
    • Hands-on Examples:
      1. Navigate to your home directory (cd ~).
      2. Create a directory for our course work: mkdir linux_robotics_course.
      3. Move into that directory: cd linux_robotics_course.
      4. Create a file to represent a robot’s log: touch sensor_log.txt.
      5. Create a directory for code: mkdir scripts.
      6. Let’s pretend sensor_log.txt got too big and we want to archive it. First, copy it: cp sensor_log.txt sensor_log_backup.txt.
      7. Now, move the original into the scripts folder: mv sensor_log.txt scripts/.
      8. Check the contents: ls and ls scripts.
      9. Let’s clean up. Remove the backup: rm sensor_log_backup.txt.
      10. Remove the file inside scripts: rm scripts/sensor_log.txt.

     

    Week 3: Text Editors and Package Management

     

    • Objectives:
      1. Learn to edit text files in the terminal using nano.
      2. Understand the concept of a package manager.
      3. Use apt to find, install, and remove software.
    • Key Vocabulary:
      • nano: A simple, beginner-friendly command-line text editor.
      • vim: A powerful but more complex modal text editor favored by many developers.
      • Package Manager: A system that automates the process of installing, updating, and removing software packages.
      • apt (Advanced Package Tool): The default package manager for Debian-based systems like Ubuntu.
      • Repository: A remote server that stores a collection of software packages.
    • Lesson Content:

      You can’t do everything by just creating and moving files. You need to edit them. Whether it’s a configuration file for a robot’s parameters, a Python script, or a C++ source file, you need a text editor. While there are graphical editors, learning a terminal-based one is crucial for when you’re remotely connected to a robot with no desktop interface.

      We’ll start with nano. It’s simple and works like a normal text editor. You type nano <filename> to open a file. The commands are listed at the bottom (e.g., ^X means Ctrl+X to Exit).

      Now, for the magic of Linux: package management. Imagine you need a specific library for your robot’s camera. Instead of searching online, downloading a zip file, and figuring out how to install it (and all of its dependencies), you can just ask your package manager.

      On Ubuntu, this is apt. The main commands are:

      • sudo apt update: Refreshes your list of available packages from the repositories. Always do this first!
      • apt search <package_name>: Searches for a package.
      • sudo apt install <package_name>: Installs a package.
      • sudo apt remove <package_name>: Removes a package.
      • sudo apt upgrade: Upgrades all your installed packages to the latest versions.
    • Hands-on Examples:
      1. Go to your linux_robotics_course directory.
      2. Let’s create a startup script for our robot. Type nano startup_check.sh.
      3. Inside nano, type the following two lines:
        Bash

        #!/bin/bash
echo "System checks complete. Ready to roll!"
      4. Press Ctrl+X to exit. It will ask if you want to save. Press Y (for Yes), and then press Enter to confirm the filename.
      5. Use cat startup_check.sh to see that your content was saved.
      6. Now, let’s use apt. First, update your package list: sudo apt update. (You will be prompted for your password).
      7. Let’s install a fun little program. Search for it: apt search cowsay.
      8. Install it: sudo apt install cowsay.
      9. Now run it! Type cowsay "Linux is powerful!".
      10. You’ve just edited a file and installed new software entirely from the command line!

     

    Week 4: Shell Scripting for Automation

     

    • Objectives:
      1. Understand the purpose and structure of a shell script.
      2. Learn to use variables, loops (for), and conditionals (if).
      3. Make a script executable and run it.
    • Key Vocabulary:
      • Shebang (#!): The first line of a script (#!/bin/bash) that tells the system which interpreter to use to run the script.
      • Variable: A named placeholder for storing data.
      • for loop: A control flow statement for iterating over a sequence of items.
      • if statement: A conditional statement that executes a block of code if a condition is true.
      • chmod: (Change Mode) The command used to change a file’s permissions.
    • Lesson Content:

      The true power of the command line is unlocked when you start automating tasks. A shell script is simply a text file containing a sequence of commands. Instead of typing five commands in a row every time you want to start your robot, you can put them in a script and run it with a single command. This ensures consistency and saves time.

      A basic script starts with a shebang: #!/bin/bash.

      Variables store information. You define them with NAME=”Value” and access them with $NAME.

      ROBOT_NAME=”Bumblebee”

      echo “Initializing $ROBOT_NAME…”

      for loops let you repeat actions.

      Bash

      for i in 1 2 3
do
  echo "Launching sensor node $i"
done

      if statements let you make decisions.

      Bash

      if [ -f "config.txt" ]; then
  echo "Config file found."
else
  echo "WARNING: Config file not found!"
fi

      The [ -f "config.txt" ] part tests if the file “config.txt” exists.

      Before you can run a script, you must give it execute permission. chmod +x your_script.sh. Then you can run it with ./your_script.sh.

    • Hands-on Examples:
      1. Inside your linux_robotics_course/scripts directory, create a new script: nano system_launcher.sh.
      2. Add the following content:
        Bash

        #!/bin/bash

# A simple script to simulate launching a robot system.

ROBOT_HOSTNAME="turtlesim"
SENSORS=("camera" "lidar" "imu")

echo "--- Starting Launch Sequence ---"

echo "Pinging main computer at $ROBOT_HOSTNAME..."
# We will learn the 'ping' command later, for now we simulate
echo "Connection successful."

echo "Initializing all sensors..."
for sensor in "${SENSORS[@]}"
do
  echo "  -> Starting $sensor node."
  sleep 1 # Pauses for 1 second
done

if [ "$1" == "--diagnostics" ]; then
    echo "Running diagnostics mode."
fi

echo "--- System is now operational. ---"
      3. Save and exit (Ctrl+X, Y, Enter).
      4. Make the script executable: chmod +x system_launcher.sh.
      5. Run it: ./system_launcher.sh. See the output.
      6. Now run it with an argument: ./system_launcher.sh --diagnostics. Notice the conditional if statement now runs. You’ve written your first intelligent script!

     

    Week 5: Power Tools: Searching and Filtering Text

     

    • Objectives:
      1. Find files and directories using find.
      2. Search for text within files using grep.
      3. Learn to chain commands together using pipes (|).
    • Key Vocabulary:
      • find: A command to search for files in a directory hierarchy based on criteria like name, size, or type.
      • grep: (Global Regular Expression Print) A command that searches for lines containing a match to a specified pattern.
      • Pipe (|): A mechanism in Linux that sends the output of one command to be the input of another command.
      • Standard Output (stdout): The default place a command sends its results (usually the terminal screen).
    • Lesson Content:

      Your robot will generate enormous amounts of data and log files. How do you find the one error message in a million lines of text? You don’t read it all. You use power tools.

      find is your bloodhound for files.

      • find . -name "*.txt": Finds all files ending in .txt in the current directory (.) and subdirectories.
      • find / -type d -name "config": Finds all directories named config, starting from the root directory /.

      grep is your magnifying glass for text inside files.

      • grep "ERROR" robot.log: Searches the file robot.log for any line containing the word “ERROR”.
      • grep -i "warning": The -i flag makes the search case-insensitive.
      • grep -r "192.168.1.10": The -r flag searches recursively through all files in the current directory.

      The real magic happens when you combine commands with the pipe (|). This takes the output of the command on the left and “pipes” it as the input to the command on the right.

      Example: ls -l /var/log | grep “syslog”

      This command first lists all files in /var/log and then sends that list to grep, which filters it to show only the lines containing “syslog”.

    • Hands-on Examples:
      1. Let’s create some dummy log files. Go to your linux_robotics_course directory.
      2. echo "INFO: System nominal." > log1.txt
      3. echo "WARN: Battery at 20%." >> log1.txt (Note: >> appends, > overwrites)
      4. echo "INFO: Lidar spinning." > log2.txt
      5. echo "ERROR: Motor controller timeout." >> log2.txt
      6. Now, use grep to find the error: grep "ERROR" *.txt. The * is a wildcard for “all”.
      7. Find the warning, but case-insensitively: grep -i "warn" *.txt.
      8. Now let’s use find and a pipe. Find all .txt files and then count how many lines are in them.

        find . -name “*.txt” -exec wc -l {} +

        A more intuitive way using a pipe:

        find . -name “*.txt” | xargs cat | wc -l

      9. Let’s see the processes running on your system and find the one for your shell (bash). We’ll learn ps next week, but try this: ps aux | grep "bash". This lists all processes (ps aux) and pipes the result to grep, which filters for lines containing “bash”. You’ve just performed a complex system query!

     

    Week 6: Process Management and Networking

     

    • Objectives:
      1. View, manage, and terminate running processes using ps, top, and kill.
      2. Understand basic networking concepts and commands like ping and ifconfig/ip.
      3. Learn to securely connect to another machine using ssh.
    • Key Vocabulary:
      • Process: An instance of a running program. Each process has a unique Process ID (PID).
      • ps: (Process Status) A command to see a snapshot of currently running processes.
      • top: An interactive command that provides a real-time view of running system processes.
      • kill: A command to send a signal to a process, typically to terminate it.
      • IP Address: A unique numerical label assigned to each device connected to a computer network.
      • ssh (Secure Shell): A network protocol for operating network services securely over an unsecured network.
    • Lesson Content:

      A robot is not a single program; it’s a collection of many programs (processes) running simultaneously. A process for the camera, one for the motors, one for navigation logic, etc. Sometimes, a process misbehaves—it might crash or use 100% of the CPU. You need to be able to identify and manage these processes.

      • ps aux: Shows all processes for users with a terminal, in a detailed format. It’s a great way to get a snapshot.
      • top: Launches an interactive dashboard showing you CPU usage, memory usage, and the processes that are consuming the most resources. Press q to quit.
      • kill <PID>: If a program freezes, you can find its PID with ps or top and use kill to terminate it. kill -9 <PID> is a more forceful way to terminate a stubborn process.

      Networking is how your robot communicates. It might be talking to your laptop over WiFi, or to other robots. The most common tool you’ll use is ssh. It allows you to open a terminal on a remote machine as if you were sitting in front of it. The syntax is ssh username@ip_address. This is THE primary way roboticists debug and control their robots in the field.

      Other useful commands:

      • ip addr (or the older ifconfig): Shows your network interfaces and IP addresses.
      • ping <ip_address>: Sends a small packet to a network address to see if it’s online and how long the response takes.
    • Hands-on Examples:
      1. Open two terminals.
      2. In the first terminal, run the command sleep 1000. This is a simple program that just waits for 1000 seconds. It’s now a running process.
      3. In the second terminal, find the process ID (PID) of the sleep command. Type ps aux | grep "sleep". You’ll see two lines; one is the grep command itself, and the other is sleep 1000. Note the number in the second column—that’s the PID.
      4. Let’s terminate it. Type kill <PID>, replacing <PID> with the number you just found.
      5. Look back at the first terminal. It should say “Terminated” or have simply exited. You’ve just manually managed a process!
      6. Now, check your own IP address. Type ip addr. Look for an entry named eth0 or wlan0 (or similar) and find the inet address (e.g., 192.168.1.5).
      7. Ping your own computer’s “localhost” (which is always 127.0.0.1): ping 127.0.0.1. You should see replies. Press Ctrl+C to stop. This is a great way to check if your robot’s network stack is working at all.

     

    Week 7: Version Control with Git

     

    • Objectives:
      1. Understand why version control is essential for software development.
      2. Initialize a repository, track changes, and make commits with Git.
      3. Learn to clone a remote repository from a service like GitHub.
    • Key Vocabulary:
      • Version Control System (VCS): A system that records changes to a file or set of files over time so that you can recall specific versions later.
      • Git: A distributed version control system.
      • Repository (Repo): A directory where Git has been initialized to start version controlling files.
      • Commit: A snapshot of your staged changes at a specific point in time.
      • git clone: Creates a copy of a remote repository on your local machine.
      • git add: Stages a change, preparing it to be included in the next commit.
      • git commit: Records the staged changes to the repository’s history.
    • Lesson Content:

      Imagine you’re working on your robot’s navigation code. You make a change to “improve” it, but it ends up making the robot drive in circles. How do you get back to the version that worked? Without version control, you’d be relying on Ctrl+Z or manually saved copies like code_v2_final_works.py. This is a recipe for disaster.

      Git is a professional tool that solves this problem. It tracks every change you make to your project. It’s like having an infinite “undo” button for your entire project. It’s also the foundation for collaboration, allowing teams of engineers to work on the same code without overwriting each other’s work. Most robotics software, including ROS, is distributed using Git.

      The basic workflow is:

      1. Modify files in your project.
      2. Stage the changes you want to save (git add <filename>).
      3. Commit the staged changes with a descriptive message (git commit -m "Message describing changes").

      To get code from somewhere else (like GitHub), you use git clone <URL>.

    • Hands-on Examples:
      1. First, configure git with your details:

        git config –global user.name “Your Name”

        git config –global user.email “youremail@example.com”

      2. Go to your linux_robotics_course/scripts directory.
      3. Initialize a git repository here: git init. You’ll see a message that an empty repository has been created.
      4. Check the status: git status. It will show your system_launcher.sh script as an “untracked file”.
      5. Let’s track it. git add system_launcher.sh.
      6. Check the status again: git status. The file is now a “change to be committed”.
      7. Commit the file: git commit -m "Initial commit of system launcher script".
      8. Now, modify the file. nano system_launcher.sh and add a comment at the top like # Version 1.0. Save and exit.
      9. Check the status: git status. It will show the file has been “modified”.
      10. Let’s clone a remote repository. We’ll clone a simple ROS example (even though we haven’t covered ROS yet, the process is the same).

        cd ~/linux_robotics_course

        git clone https://github.com/ros/ros_tutorials.git

      11. An entire folder ros_tutorials containing code is now downloaded to your machine, managed by Git.

     

    Week 8: Introduction to ROS – The Robot’s Nervous System

     

    • Objectives:
      1. Understand the philosophy and high-level architecture of ROS.
      2. Learn the three core concepts: Nodes, Topics, and Messages.
      3. Install ROS 2 and run a basic simulation.
    • Key Vocabulary:
      • ROS (Robot Operating System): A flexible framework for writing robot software. It’s a collection of tools, libraries, and conventions that aim to simplify the task of creating complex and robust robot behavior.
      • Node: A single process that performs a computation. A robot system is comprised of many nodes (e.g., a camera node, a motor control node, a planning node).
      • Topic: A named bus over which nodes exchange messages. Nodes can publish data to a topic or subscribe to a topic to receive data.
      • Message: The data structure used for sending information on a topic (e.g., a sensor reading, a motor command).
    • Lesson Content:

      Welcome to the heart of modern robotics software: ROS. It’s important to understand that ROS is not an operating system in the traditional sense like Linux or Windows. It’s a “meta-operating system” that runs on top of an OS (like Linux!).

      Think of a robot like the human body. You have different parts doing different jobs: eyes (camera), muscles (motors), inner ear (IMU sensor), and the brain (control computer). ROS provides the nervous system that lets them all communicate.

      • A Node is like a single functional unit. The “eye” is a node that captures images. A “muscle” is a node that receives commands and moves a motor.
      • A Topic is like a nerve pathway. The camera node publishes images on the /camera/image topic. The brain node subscribes to the /camera/image topic to receive those images.
      • A Message is the actual signal sent along the nerve. For the /camera/image topic, the message is a data packet containing the image itself, its height, width, etc.

      This “publish-subscribe” model is incredibly powerful because it decouples the nodes. The camera node doesn’t need to know or care who is using its images. It just publishes them. This makes it easy to add, remove, or upgrade parts of your robot system without rewriting everything.

    • Hands-on Examples:
      1. Install ROS 2 Humble Hawksbill. The official installation instructions are the best source. Follow them carefully: ROS 2 Installation Guide. This will involve adding the ROS repository and using apt to install the packages.
      2. After installation, you need to “source” the setup file in every new terminal you open to make the ROS commands available. Add this to the end of your ~/.bashrc file so it happens automatically: echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc. Then run source ~/.bashrc in your current terminal.
      3. Let’s run a classic ROS demo: Turtlesim. Open two terminals.
      4. In the first terminal, start the simulation node:

        ros2 run turtlesim turtlesim_node

        A small window should pop up with a turtle in the middle.

      5. In the second terminal, start a node that lets you control the turtle with your keyboard:

        ros2 run turtlesim turtle_teleop_key

      6. Click on the second terminal so it’s active, and use the arrow keys on your keyboard. The turtle will move!
      7. What just happened? The turtlesim_node created a topic called /turtle1/cmd_vel. The turtle_teleop_key node publishes messages on that topic every time you press a key. The turtlesim_node is subscribed to that topic, receives the messages, and moves the turtle accordingly. You have just operated a complete (if simple) ROS system.

     

    Week 9: Working with ROS 2 Workspaces and Packages

     

    • Objectives:
      1. Understand the structure of a ROS 2 workspace and packages.
      2. Learn to create a package and build it using colcon.
      3. Use ros2 run and ros2 launch to execute ROS nodes.
    • Key Vocabulary:
      • Workspace (ws): A directory containing ROS 2 packages. You build the entire workspace at once.
      • Package: The main unit for organizing software in ROS. A package might contain ROS nodes, a launch file, configuration files, etc.
      • colcon: The build tool used to compile ROS 2 workspaces.
      • ros2 run: A command to execute a single node from a package.
      • ros2 launch: A command to execute a launch file, which can start up many nodes and set their parameters all at once.
    • Lesson Content:

      You won’t always be using pre-built ROS nodes. You’ll need to write your own. To do this, you need to organize your code into packages within a workspace.

      A ROS 2 workspace is a directory with a specific structure, typically:

      my_ros_ws/
└── src/
    ├── my_first_package/
    │   ├── package.xml
    │   ├── setup.py
    │   └── ... (your code)
    └── another_package/
        └── ...

      The src directory holds the source code for all your packages. The package.xml file is crucial; it contains meta-information about the package, like its name, version, and dependencies.

      The build process with colcon looks like this:

      1. You write your code in the src directory.
      2. You navigate to the root of your workspace (my_ros_ws).
      3. You run colcon build.
      4. colcon goes through all the packages in src, figures out dependencies, and compiles everything, putting the results in new build, install, and log directories.
      5. To use the nodes you just built, you need to source a new setup file: source install/setup.bash.

      While ros2 run <package_name> <node_name> is good for running one node, it’s tedious for a real robot with 10+ nodes. That’s what launch files are for. They are Python scripts that let you define a whole collection of nodes to start, configure, and connect. You run them with ros2 launch <package_name> <launch_file_name>.

    • Hands-on Examples:
      1. Let’s create a workspace:

        mkdir -p ~/ros2_ws/src

        cd ~/ros2_ws/src

      2. ROS 2 has a tool to create a template package for us. Let’s make a simple Python-based one:

        ros2 pkg create –build-type ament_python –node-name my_node my_package

      3. This creates a new directory my_package with all the necessary boilerplate files.
      4. Now, let’s build the workspace. Go to the root: cd ~/ros2_ws.
      5. Run the build command: colcon build. It should build your empty package successfully.
      6. After it finishes, you’ll see build, install, and log directories.
      7. Source the new environment so ROS can find your package: source install/setup.bash.
      8. Now, run your (currently empty) node: ros2 run my_package my_node. It won’t do anything yet, but the fact that it runs without error means you’ve successfully created and built your own ROS package.
      9. Let’s try a more complex launch file. The turtle demo has one.

        ros2 launch turtlesim multisim.launch.py

        This launches a much more complex scenario than the one we ran manually last week, all from a single command.

     

    Week 10: ROS 2 Topics, Services, and Actions in Practice

     

    • Objectives:
      1. Use command-line tools to inspect ROS 2 topics.
      2. Understand the difference between Topics, Services, and Actions.
      3. Call a ROS 2 service from the command line.
    • Key Vocabulary:
      • ros2 topic: A command-line tool for inspecting and interacting with topics.
      • ros2 service: A command-line tool for inspecting and calling services.
      • Service: A request/response communication model. One node (the client) sends a request to another node (the server) and waits for a response. Unlike topics, this is a two-way, synchronous communication.
      • Action: A longer-term, asynchronous goal-oriented communication model. A client sends a goal (e.g., “navigate to the kitchen”), the server provides feedback during execution (e.g., “distance remaining: 10 meters”), and returns a final result.
    • Lesson Content:

      We’ve discussed topics, but how do we see what’s happening under the hood? ROS 2 provides powerful command-line introspection tools.

      • ros2 topic list: Shows all active topics in the system.
      • ros2 topic echo <topic_name>: Prints the messages being published on a specific topic to your screen. This is incredibly useful for debugging.
      • ros2 topic info <topic_name>: Shows how many publishers and subscribers a topic has, and the message type.

      While Topics are for continuous streams of data (like sensor readings), they aren’t great for commands where you need a confirmation. For that, we have Services. Think of it like ordering at a counter. You make a request (“I’d like a coffee”) and wait until you get a response (“Here is your coffee”). It’s a blocking, one-to-one interaction.

      Actions are for long-running tasks. Think of ordering a pizza for delivery. You send the goal (“Deliver a pepperoni pizza to my address”). You can call for feedback (“What’s the status of my order?”). Eventually, you get a final result (the pizza arrives). This is perfect for tasks like “rotate 90 degrees” or “drive to waypoint B”.

    • Hands-on Examples:
      1. Start the Turtlesim demo again in one terminal: ros2 run turtlesim turtlesim_node.
      2. In a second terminal, let’s inspect. First, source your ROS environment (source /opt/ros/humble/setup.bash).
      3. List the topics: ros2 topic list. You should see /turtle1/cmd_vel and /turtle1/pose, among others.
      4. Let’s watch the turtle’s pose (its X, Y, and orientation). Run: ros2 topic echo /turtle1/pose. It will print a lot of messages, even if the turtle isn’t moving.
      5. Now, start the teleop node in a third terminal: ros2 run turtlesim turtle_teleop_key.
      6. Drive the turtle around and watch the /turtle1/pose output in the second terminal. You are now spying on the communication between the nodes! Ctrl+C to stop the echo.
      7. Now for services. Turtlesim has services to do things like reset the simulation or spawn a new turtle. List them: ros2 service list.
      8. Let’s call the /reset service. The service type is std_srvs/srv/Empty. We call it like this:

        ros2 service call /reset std_srvs/srv/Empty

        The turtle in the simulation will jump back to the center. You just commanded a node using a service.

     

    Week 11: Simulation and Visualization with Gazebo and RViz

     

    • Objectives:
      1. Understand the role of simulation in robotics.
      2. Launch a simulated robot in the Gazebo simulator.
      3. Use RViz to visualize sensor data from the simulated robot.
    • Key Vocabulary:
      • Gazebo: A powerful 3D robotics simulator that can model physics, sensors, and environments.
      • RViz (ROS Visualization): A 3D visualization tool that lets you see what your robot is thinking. It displays sensor data, robot models, and planned paths.
      • URDF (Unified Robot Description Format): An XML file format used in ROS to describe all elements of a robot model (links, joints, sensors, etc.).
    • Lesson Content:

      Physical robots are expensive, fragile, and can be dangerous. Before you run code on a real robot, you test it extensively in simulation. A good simulator like Gazebo allows you to create a virtual world with realistic physics. You can place a model of your robot (defined in a URDF file) in this world and it will behave much like the real thing. It can drive, collide with objects, and its virtual sensors (cameras, lidars) will generate data just like their real counterparts.

      Simulation is for testing the robot’s interaction with the world. RViz is for visualizing the robot’s data. It doesn’t show you a pretty 3D world. Instead, it shows you what the robot is “seeing” and “thinking”. You can display:

      • The laser scan from a Lidar.
      • The point cloud from a 3D camera.
      • The robot’s own model of itself (/robot_description).
      • The path a navigation algorithm is planning.

      RViz is arguably the single most important debugging tool in the entire ROS ecosystem.

    • Hands-on Examples:
      1. We need to install Gazebo and some demo packages.

        sudo apt update

        sudo apt install ros-humble-gazebo-ros-pkgs ros-humble-turtlebot3*

        (This may take some time and download a lot of packages).

      2. The TurtleBot3 is a standard educational robot platform. We will launch a simulation of it. First, we need to tell ROS which model we’re using. Add this to your ~/.bashrc file:

        echo “export TURTLEBOT3_MODEL=burger” >> ~/.bashrc

        Then source the file: source ~/.bashrc.

      3. Now, run the launch file that starts Gazebo with a TurtleBot3 in an example world:

        ros2 launch turtlebot3_gazebo empty_world.launch.py

        Gazebo should launch, showing a small robot in an empty environment.

      4. This one launch file started Gazebo and a ROS node that controls the simulated robot. Now, let’s visualize its data. Open a new terminal.
      5. Launch RViz with a pre-made configuration for the TurtleBot3:

        ros2 launch turtlebot3_bringup rviz.launch.py

      6. RViz will open. You’ll see the model of the robot, and importantly, you should see red dots in front of it. That is the visualization of the Lidar sensor scan from the simulated robot in Gazebo!
      7. To prove it’s all connected, open a third terminal and launch the teleop node:

        ros2 run turtlebot3_teleop teleop_keyboard

        Use the w, a, s, d, x keys to drive the robot around in Gazebo. Watch how the robot model and the Lidar scan update in real-time in RViz. You are now running and visualizing a complete, simulated robotic system.

     

    Week 12: Device Drivers and The Real World

     

    • Objectives:
      1. Understand how Linux represents hardware devices as files in the /dev directory.
      2. Use commands like lsusb and dmesg to inspect connected hardware.
      3. Learn the concept of serial communication for microcontrollers.
    • Key Vocabulary:
      • Device Driver: A piece of software that allows the operating system’s kernel to communicate with a hardware device.
      • /dev: A special directory in Linux that contains “device files.” Interacting with these files is how programs talk to hardware.
      • lsusb: A command to list all connected USB devices.
      • dmesg: A command to print the kernel’s message buffer. It’s extremely useful for seeing what happens when you plug in a new device.
      • Serial Port: A common communication interface used to connect computers to peripherals like microcontrollers (e.g., Arduino) or GPS units. Often appears as /dev/ttyUSB0 or /dev/ttyACM0.
    • Lesson Content:

      So far, we’ve lived in the software world. How does Linux actually talk to a physical camera, a motor controller, or an Arduino? The answer is through device drivers and device files.

      Linux has a beautiful philosophy: “Everything is a file.” Your hard drive is a file. Your mouse is a file. A USB-connected sensor is a file. These special files live in the /dev directory. When a ROS node wants to get data from a motor controller connected via a USB-to-Serial adapter, it doesn’t need complex code. It just needs to read from the file /dev/ttyUSB0. The kernel and the device driver handle all the low-level complexity.

      When you plug in a new piece of hardware, your first step is often to figure out what device file it was assigned.

      • lsusb gives you a high-level view of what’s connected to your USB bus.
      • dmesg | tail is your best friend. dmesg prints all kernel messages. By piping it to tail, you see the last few messages, which will be the ones generated when you just plugged your device in. This often explicitly tells you the name of the device file (e.g., “attached to /dev/ttyACM0”).

      For many robotics components, you’ll need to make sure your user has permission to read and write to these device files, often by adding your user to the dialout or plugdev group. sudo usermod -a -G dialout $USER.

    • Hands-on Examples:
      1. Plug in any USB device you have—a mouse, a keyboard, a flash drive, or even your phone.
      2. Open a terminal and run lsusb. You should see the device listed.
      3. Now, run dmesg. You’ll see a lot of text.
      4. Unplug the device. Wait a few seconds. Plug it back in.
      5. Immediately run dmesg | tail -n 20. The -n 20 tells tail to show the last 20 lines. You should see messages related to the device you just connected, identifying what it is and how the kernel is handling it.
      6. Look in the /dev directory: ls /dev. You’ll see a huge number of files. Look for familiar ones like sda (your first hard disk) or tty (your terminals).
      7. If you have an Arduino or Raspberry Pi Pico, plug it in. Run dmesg | tail. It will almost certainly tell you it has been assigned a device file like /dev/ttyACM0. A ROS node could now open this file to communicate with it.

     

    Week 13: Building Software from Source

     

    • Objectives:
      1. Understand why you sometimes need to build software from source instead of using a package manager.
      2. Learn the basic cmake and make workflow.
      3. Introduce the concept of cross-compilation for embedded systems.
    • Key Vocabulary:
      • Source Code: The human-readable instructions written by a programmer in a language like C++ or Python.
      • Compiler: A program that translates source code into machine code (binary) that the CPU can execute.
      • make: A build automation tool that reads a Makefile to determine how to compile a project.
      • cmake: A cross-platform tool that generates Makefiles (and other build files) tailored to your specific system. It’s the standard for C++ projects in the ROS ecosystem.
      • Cross-Compilation: The process of compiling code on one type of machine (e.g., your x86 laptop) to run on a different type of machine (e.g., an ARM-based Raspberry Pi).
    • Lesson Content:

      apt is wonderful, but it doesn’t have everything. Sometimes you need:

      • The absolute latest, cutting-edge version of a library.
      • A piece of software that isn’t in the standard repositories.
      • To apply a custom patch or change a configuration option that isn’t available in the pre-built package.

      In these cases, you must build from source. The most common workflow for C++ projects (which form the core of ROS and many high-performance robotics applications) is CMake.

      The process generally looks like this:

      1. Download the source code (often with git clone).
      2. Create a build directory: mkdir build && cd build.
      3. Run cmake to configure the build: cmake .. (the .. points to the source directory one level up).
      4. Run make to compile the code: make. This can take a while.
      5. Install the compiled program: sudo make install.

      Cross-compilation is a more advanced but vital concept. Your powerful laptop can compile code much faster than a small Raspberry Pi. So, you can set up a toolchain on your laptop to build programs that will run on the Pi’s ARM architecture. This saves enormous amounts of time during development.

    • Hands-on Examples:
      1. Let’s download and compile a simple, well-known C++ library: spdlog. It’s a logging library.
      2. First, make sure you have the necessary build tools: sudo apt install build-essential cmake git.
      3. Clone the source code: git clone https://github.com/gabime/spdlog.git.
      4. cd spdlog.
      5. Create a build directory and enter it: mkdir build && cd build.
      6. Run cmake: cmake ... You’ll see it check your system for compilers and libraries.
      7. Run make: make. You’ll see the compilation process, with percentages indicating progress.
      8. Finally, install it system-wide: sudo make install.
      9. The spdlog library is now installed on your system. Any C++ program you write could now use it. You’ve successfully built a professional software library from source.

     

    Week 14: System Performance and Real-Time Considerations

     

    • Objectives:
      1. Understand why real-time performance is critical in robotics.
      2. Learn about process priority using nice and renice.
      3. Introduce the concept of Real-Time Linux (PREEMPT_RT).
    • Key Vocabulary:
      • Real-Time System: A system that must process data and produce a response within a guaranteed time frame (a “deadline”). Missing a deadline is considered a failure.
      • Latency: The delay between a stimulus and a system’s response.
      • Jitter: The variation in latency.
      • Process Priority: A value assigned to a process to determine how much CPU time it should receive relative to other processes.
      • nice / renice: Commands to run a program with a modified scheduling priority, or to change the priority of a running process.
      • PREEMPT_RT: A patch for the Linux kernel that transforms it into a hard real-time operating system, capable of meeting very strict deadlines.
    • Lesson Content:

      For a web server, if a response is a few milliseconds late, nobody notices. For a robot, if the command to stop a motor is a few milliseconds late, it could crash into a wall. This is the world of real-time computing.

      Standard Linux is designed for fairness and high throughput, not for guaranteed response times. It might decide to delay your motor control process to finish a background file-writing task. In robotics, we need to tell the OS what’s important.

      The simplest way to do this is with process priority. The nice value of a process ranges from -20 (highest priority) to 19 (lowest priority).

      • nice -n -10 ./my_critical_robot_process: Starts a process with a higher priority.
      • sudo renice -n -15 <PID>: Changes the priority of an already running process. (You need sudo for negative nice values).

      For truly demanding applications (like high-speed robot arms or autonomous drones), a standard kernel isn’t enough. We need Real-Time Linux. The PREEMPT_RT patch modifies the kernel to be “preemptible,” meaning a high-priority task can interrupt a lower-priority one at almost any time, dramatically reducing latency and jitter. Installing a PREEMPT_RT kernel is an advanced topic, but knowing it exists and why it’s needed is fundamental for serious robotics work.

    • Hands-on Examples:
      1. Let’s observe the effect of nice. We will run two simple, CPU-intensive loops.
      2. Open a text editor and create a file called loop.sh:
        Bash

        #!/bin/bash
i=0
while true; do
  i=$((i+1))
done
      3. Make it executable: chmod +x loop.sh.
      4. Open two terminals, side-by-side.
      5. In the first terminal, run the script normally: ./loop.sh.
      6. In the second terminal, run the script with the lowest possible priority: nice -n 19 ./loop.sh.
      7. Now open a third terminal and run top.
      8. In top, you should see two loop.sh processes. Press the < and > keys to sort by different columns. Find the %CPU column. You will see that both processes are trying to use a lot of CPU, but the one with the normal priority (NI value of 0) is getting significantly more CPU time than the “niced” one (NI value of 19).
      9. Close the terminals running the scripts to stop them. You’ve just directly manipulated the OS scheduler!

     

    Final Project (Weeks 15-16)

     

     

    Project Description

     

    Your mission is to configure and run a simulated mobile robot to perform a simple security patrol. You will use a pre-existing ROS 2 simulation package for a robot called the “Leo Rover”. You will clone the repository using Git, install its dependencies using apt and rosdep, build the workspace using colcon, and launch the simulation. Finally, you will inspect the running system using ROS 2 command-line tools and write a small shell script to automate the launch process.

    This project synthesizes skills from the entire course:

    • Weeks 1-2: Filesystem navigation and manipulation.
    • Week 3: Package management (apt).
    • Week 4: Shell scripting.
    • Week 7: Version control with Git.
    • Weeks 8-11: Core ROS 2 concepts, workspaces, building, and launching.

     

    Step-by-Step Instructions

     

    1. Set Up the Workspace:
      • Create a new ROS 2 workspace for this project: mkdir -p ~/leo_ws/src && cd ~/leo_ws/src.
    2. Get the Source Code:
      • The simulation package for the Leo Rover is available on GitHub. Clone it into your src directory:

        git clone https://github.com/fictionlab/leo_simulator.git

    3. Install Dependencies:
      • ROS has a tool called rosdep to automatically install dependencies listed in a package’s package.xml file.
      • Navigate to the root of your workspace: cd ~/leo_ws.
      • Initialize rosdep if you haven’t already: sudo rosdep init && rosdep update.
      • Run the installer. This command looks in all the packages in your src directory and installs their dependencies using apt:

        rosdep install –from-paths src -y –ignore-src

    4. Build the Workspace:
      • From the root of your workspace (~/leo_ws), build the packages:

        colcon build –symlink-install

    5. Source the Workspace:
      • Before you can run anything from your workspace, you must source its setup file.

        source install/setup.bash

      • Pro Tip: Add this command to your ~/.bashrc to avoid typing it every time, but be careful as this can shadow other workspaces.
    6. Launch the Simulation:
      • The package comes with a launch file to start Gazebo with a pre-defined world and the Leo Rover.
      • Run the launch file: ros2 launch leo_gazebo leo.launch.py
      • Gazebo should open, showing a rover in a simple outdoor environment.
    7. Inspect and Control the Robot:
      • Open a new terminal and source your workspace again: cd ~/leo_ws && source install/setup.bash.
      • Use ros2 topic list to see all the topics the robot is publishing. Look for /cmd_vel (for sending motion commands) and /camera/image_raw (for the camera feed).
      • For this rover, a simple teleop node can be used to drive it around. Let’s install a generic one: sudo apt install ros-humble-teleop-twist-keyboard.
      • Run the teleop node. It will publish to the /cmd_vel topic, which the simulated robot is listening to.

        ros2 run teleop_twist_keyboard teleop_twist_keyboard

      • Follow the on-screen instructions (use i, j, k, l etc.) to drive your rover around its environment in Gazebo.
    8. Create a Launch Script (The Final Step):
      • It’s annoying to open multiple terminals to launch the simulation and the teleop node. Let’s automate it with a shell script.
      • In your ~/leo_ws directory, create a script nano launch_patrol.sh.
      • Add the following content:
        Bash

        #!/bin/bash

# Script to launch the Leo Rover simulation and teleop control.

echo "Sourcing ROS 2 and workspace..."
source /opt/ros/humble/setup.bash
source $(pwd)/install/setup.bash

echo "Launching Gazebo simulation in a new terminal..."
gnome-terminal -- bash -c "ros2 launch leo_gazebo leo.launch.py; exec bash"

sleep 5 # Give Gazebo time to start up

echo "Launching keyboard teleop in a new terminal..."
gnome-terminal -- bash -c "ros2 run teleop_twist_keyboard teleop_twist_keyboard; exec bash"

echo "Launch script finished."
      • Make the script executable: chmod +x launch_patrol.sh.
      • Now, close all other terminals and run your script from the ~/leo_ws directory: ./launch_patrol.sh.
      • It should automatically source the correct files and open two new terminals, one for Gazebo and one for the teleop node.

    Congratulations! You have successfully set up a complex robotics simulation, demonstrating a solid foundation in the Linux skills essential for any robotics developer. You are ready to continue your journey and build amazing things.