ROS, the Robot Operating System, is a software framework that helps robots sense, decide, and act using many smaller programs working together. This cheat sheet covers the core communication tools students need to understand before building or debugging a robot project. It explains how nodes exchange data, how packages organize code, and how launch files start a system.
Students can use it as a quick reference while programming simulations or real robots.
Key Facts
- A ROS node is one running program, and a robot system usually contains many nodes working at the same time.
- A topic carries continuous data streams using a publish and subscribe model, such as /camera/image or /cmd_vel.
- A service uses a request and response model, so it is best for short tasks that need one clear answer.
- An action is used for longer goals that need feedback, cancellation, or progress updates, such as moving to a target pose.
- A message type defines the structure of data on a topic, such as geometry_msgs/Twist for linear and angular velocity commands.
- A ROS package groups related source code, message definitions, launch files, and configuration files into one reusable unit.
- In ROS 2, the command ros2 topic list shows active topics, and ros2 topic echo /topic_name prints live messages from that topic.
- Update rate can be estimated with frequency = messages received / time, so 120 messages in 10 seconds equals 12 Hz.
Vocabulary
- Node
- A node is an individual ROS program that performs one part of a robot system, such as reading a sensor or controlling a motor.
- Topic
- A topic is a named communication channel that sends ongoing data from publishers to subscribers.
- Service
- A service is a communication method where one node sends a request and another node returns a response.
- Action
- An action is a communication method for long-running tasks that can provide feedback and be canceled.
- Message
- A message is a defined data format used to send information through a topic, service, or action.
- Launch File
- A launch file starts and configures multiple ROS nodes at once so a robot system can run consistently.
Common Mistakes to Avoid
- Using a service for continuous sensor data is wrong because services are designed for request and response tasks, not steady data streams.
- Forgetting to match message types is wrong because a publisher and subscriber on the same topic must use the same message structure.
- Assuming a topic name is correct without checking it is wrong because even a small spelling or namespace difference creates a separate topic.
- Starting nodes one by one without a launch file can cause errors because required parameters, remappings, or startup order may be missed.
- Ignoring units in message fields is wrong because robots may interpret values differently, such as meters versus centimeters or radians versus degrees.
Practice Questions
- 1 A lidar node publishes 300 scan messages in 15 seconds. What is the topic frequency in Hz?
- 2 A robot velocity command uses geometry_msgs/Twist with linear.x = 0.40 m/s. How far should the robot travel in 5 seconds if it maintains that speed?
- 3 Choose the best ROS communication method for each task: streaming camera images, resetting a sensor once, and driving to a goal while reporting progress.
- 4 Explain why a robot system is usually designed as many small ROS nodes instead of one large program.
Understanding ROS (Robot Operating System) Overview
A useful way to understand ROS is to think about the path from a physical event to a robot movement. A sensor produces measurements. A driver turns those measurements into ROS messages.
Another program may filter noise, combine readings, or identify objects. A planning program chooses a safe motion. A controller sends commands to motors.
Each stage can run separately, which makes the robot easier to test. It also means a fault in one stage can affect every later stage. A camera may work perfectly while the robot still moves badly because the coordinate data or controller settings are wrong.
Communication choice affects how reliable a system feels. Topics suit data that changes often, including laser scans, wheel speeds, and camera frames. A subscriber normally uses the newest useful data rather than every old reading.
Services fit tasks such as resetting an odometer or asking for a saved map. Actions fit navigation because reaching a destination takes time. The robot can report its current progress while a user can stop the goal if an obstacle appears.
Students should choose the simplest pattern that matches the job. Using a service for a long movement can leave a program waiting with little information about what is happening.
Time is one of the hardest parts of robotics. Sensor data arrives at different rates, and computers need time to process it. A command based on an old camera image may be unsafe if the robot is moving quickly.
Message timestamps help programs decide whether data is fresh enough to use. Update frequency matters too. A twelve hertz sensor sends one reading about every eighty three milliseconds.
That may be fine for a slow indoor robot, but it may be too slow for a fast vehicle. In ROS 2, quality of service settings control details such as whether a node prefers reliable delivery or lower delay.
Reliable delivery is useful for important state information. Lower delay can be more useful for images when an old frame has little value.
Most debugging starts by observing the system before changing code. Check that the expected nodes are running. Inspect active topics and watch a few live messages.
Confirm that message fields have sensible units and values. Velocity is often measured in metres per second, while angular velocity is commonly measured in radians per second. A value with the wrong unit can produce motion that looks mysterious but has a simple cause.
Names matter as well. Two programs can fail to connect when one uses a slightly different topic name.
Launch files reduce setup mistakes by starting related programs with shared settings. Good projects keep parameters, device settings, and robot-specific values outside the main program, so students can change a camera frame rate or wheel size without rewriting the logic.