ROS fundamentals

Why it matters

ROS (Robot Operating System) is the common software framework of research labs, robotics start-ups and many AMR and cobot products. It lets you combine drivers, perception, navigation and manipulation packages written by others instead of building everything from scratch. Familiarity with ROS 2 is one of the most frequently listed skills in robotics job descriptions.

Key ideas

What ROS is. Not an operating system in the usual sense, but middleware plus tools and libraries that run on Linux (and other platforms). It provides inter-process communication, hardware abstraction through drivers, standard message types, a build system, visualisation and simulation tools, and thousands of reusable packages. ROS 1 (last release Noetic, end-of-life 2025) used a central ROS Master; ROS 2 (Humble, Jazzy …) uses DDS middleware with peer-to-peer discovery, quality-of-service settings and better real-time and security support. New work should use ROS 2.

The computation graph.

• Node — a process (or component) doing one job: a camera driver, a localiser, a planner.
• Topic — a named, typed data stream with publish/subscribe, many-to-many and asynchronous. Used for continuous data: sensor readings, velocity commands (/cmd_vel), odometry.
• Message — the typed data structure carried on a topic (e.g. sensor_msgs/LaserScan, geometry_msgs/Twist).
• Service — synchronous request/response, for short calls such as "reset odometry" or "get map".
• Action — for long-running goals with feedback and cancellation, e.g. "navigate to pose" or "move arm to pose".
• Parameters — node configuration values, changeable at launch or run time.
• Discovery — ROS 1: nodes register with the Master (roscore), then talk directly. ROS 2: DDS discovers peers automatically; no master.

Quality of Service (ROS 2). Reliable vs best-effort delivery, history depth, durability. Sensor streams often use best-effort; commands and maps use reliable. Publisher and subscriber QoS must be compatible or no data flows.

Organisation and tools.

• Package — unit of code organisation: nodes, launch files, configuration, message definitions, package.xml (metadata/dependencies) and build files.
• Workspace built with colcon (ROS 2; ROS 1 used catkin).
• Launch files start and configure many nodes together (Python/XML/YAML in ROS 2).
• tf2 — maintains the tree of coordinate frames (map → odom → base_link → laser, base_link → camera) over time; any node can ask for the transform between two frames at a given time.
• URDF/Xacro — robot description (links, joints, geometry, inertia) used by tf, RViz, MoveIt and Gazebo.
• RViz (visualisation), Gazebo (physics simulation), rosbag (record/replay data), command-line tools (ros2 node list, ros2 topic echo, ros2 topic hz).
• Major stacks: Nav2 (mobile navigation), MoveIt (arm motion planning), ros2_control (hardware interfaces and controllers).

Limits. ROS itself is not hard real-time; low-level servo loops stay in motor drives or real-time controllers, and ROS sends set-points. Network bandwidth matters for images and point clouds.

Formulas

Data rate = message size × publish rate

• bytes × Hz = bytes/s; ×8 for bit/s.

Raw image size = width × height × channels × bytes per channel

Point in parent frame: ᴾp = ᴾR_C · ᶜp + ᴾt_C (what tf2 computes)

• ᴾR_C, ᴾt_C — rotation and translation of child frame C in parent P.

Laser return to Cartesian (in sensor frame): x = r·cos β, y = r·sin β

• r — range (m); β — beam bearing (rad).

Worked examples

Example 1 (standard). A camera node publishes uncompressed 640 × 480 RGB images (1 byte per channel) at 30 Hz. Find the bandwidth of this topic.

1. Image size = 640 × 480 × 3 × 1 = 921 600 bytes.
2. Data rate = 921 600 × 30 = 27 648 000 bytes/s ≈ 27.6 MB/s.
3. In bits: 27.648 × 8 ≈ 221 Mbit/s — too much for typical Wi-Fi, so use compressed image transport or process on the robot.

Answer: ≈ 27.6 MB/s (≈ 221 Mbit/s).

Example 2 (GATE level, frames). A laser scanner frame laser is mounted on base_link at translation (0.2, 0, 0.3) m and rotated 90° about z (scanner x-axis points along the robot's left). A return has range 2 m at bearing 30° in the laser frame. Find the point in base_link.

1. In the laser frame: x = 2·cos 30° = 1.732 m, y = 2·sin 30° = 1.000 m, z = 0.
2. Rotation R_z(90°) maps (x, y) → (−y, x): (−1.000, 1.732, 0) m.
3. Add the translation: (−1.000 + 0.2, 1.732 + 0, 0 + 0.3) = (−0.800, 1.732, 0.300) m.

Answer: (−0.80, 1.73, 0.30) m in base_link — exactly the computation tf2 performs when you call a transform lookup.

Common mistakes

• Thinking ROS 2 needs roscore — that was ROS 1; ROS 2 discovers peers through DDS.
• Using a topic for a request that needs a reply (use a service) or a long task that needs feedback and cancel (use an action).
• Mismatched QoS between publisher and subscriber, so nothing is received.
• Publishing data with the wrong frame_id or timestamp, breaking tf lookups.
• Forgetting to source the workspace setup file after building.
• Expecting ROS to close kHz-rate servo loops in hard real time.

For GATE ME

ROS is not a core GATE topic; it appears in university exams and interviews. Expect conceptual questions on nodes, topics, services, actions, packages, launch files and tf, and simple estimates of message bandwidth. The frame-transform calculation links directly to homogeneous transforms, which GATE does test.

Quick check

1. Which communication pattern suits "navigate to a goal with progress updates"?
2. What replaced the ROS Master in ROS 2?
3. Data rate of a 200-byte message at 50 Hz?
4. Which tool records topics for later replay?
5. What file describes a robot's links and joints?

Answers: 1. Action; 2. DDS peer-to-peer discovery; 3. 10 000 bytes/s; 4. rosbag (ros2 bag); 5. URDF (often written as Xacro).