Concepts and Packages
Last updated
Last updated
Definition: Nodes are independent processes that perform computation. Each node is typically responsible for a single task (e.g., reading sensor data, controlling motors, localization).
Implementation: Nodes are written using ROS client libraries such as roscpp
(C++) or rospy
(Python).
Role: The ROS Master provides name registration and lookup for nodes, topics, and services, enabling nodes to discover and connect with each other.
Mechanism: Topics are named message buses for asynchronous, many-to-many communication. Nodes publish messages to topics, and other nodes subscribe to receive those messages.
Strong Typing: Each topic enforces a specific message type for data consistency.
Mechanism: Synchronous, request/response interactions for tasks that require confirmation or a result (e.g., requesting a sensor reading).
Packages: The basic unit of ROS software organization, containing nodes, libraries, configuration files, and more.
tf / tf2
Coordinate frame transforms (essential for robot kinematics)
rviz
3D visualization tool for sensor data, robot models, and planning
ros_control
Framework for controller management and hardware abstraction
moveit
Motion planning and manipulation for robotic arms
navigation
Autonomous navigation stack for mobile robots
gazebo_ros_pkgs
Integration between ROS and Gazebo simulator
urdf
Unified Robot Description Format for robot models
robot_localization
State estimation from multiple sensors
rosbag
Data recording and playback
sensor_msgs, geometry_msgs, std_msgs
Standard message types for sensors, geometry, etc.
image_transport, cv_bridge
Tools for handling images and computer vision
robot_state_publisher
Publishes robot joint states to tf
actionlib
Tools for asynchronous task execution
ros_perception
Perception stack for vision and point cloud processing
rosparam, rosnode, rostopic, rosservice
Core tools for managing ROS system
ROS Industrial
Packages for industrial robot support
rqt
GUI plugins for introspection, plotting, and debugging
cv_bridge
, image_transport
(vision)
robot_state_publisher
, joint_state_publisher
(robot state)
dynamic_reconfigure
(runtime parameter tuning)
catkin
(build system)
roslaunch
, rosbag
, rosmsg
, rostopic
, rosservice
, rosnode
(core utilities)
urdf_tutorial
, turtlesim
(learning and demos)
Tutorials:
ROS 1 is structured around several key concepts that enable modular, distributed, and scalable robot software development. The main ideas are organized at different levels2:
Communication: Nodes communicate with each other using topics, services, or the parameter server, and are managed at runtime by the ROS Master2.
Operation: Nodes register themselves and their communication interfaces with the Master, which acts like a DNS server for the ROS network. After discovery, nodes communicate directly2.
Purpose: Stores global parameters (key-value pairs) accessible at runtime by all nodes. Used for configuration and tuning of nodes without code changes2.
Transport: Default is TCPROS (reliable TCP/IP), with UDPROS (UDP-based, low-latency) for specific use cases2.
Definition: Strictly defined data structures used to communicate over topics. Defined in .msg
files and can include primitive types or nested messages.
Definition: Defined in .srv
files with request and response fields.
Purpose: Files (with .bag
extension) for recording and replaying topic data. Essential for debugging, simulation, and development.
Workspaces: Directories for building and managing multiple packages together.
While the importance of a package depends on your application, the following are widely used and considered essential in most ROS 1 projects:
Other Notable Packages (from usage statistics):
2
ROS 2 Tutorials:
Lifecycle Node: Supports managed states (e.g., unconfigured, inactive, active, finalized), enabling robust startup, shutdown, and error handling.
Features: Nodes are more modular in ROS 2, can be composed into a single process, and support advanced lifecycle management for reliability.
Mechanism: Topics are named channels for asynchronous, many-to-many publish/subscribe communication. Nodes publish messages to topics, and other nodes subscribe to receive them2.
DDS Integration: ROS 2 uses the Data Distribution Service (DDS) middleware, enabling automatic discovery, decentralized communication, and advanced Quality of Service (QoS) controls.
QoS Policies: Fine-grained control over reliability, durability, deadline, and resource usage, crucial for real-time and safety-critical applications.
Definition: Services provide synchronous, request/response communication. A client sends a request to a service server and waits for a response, suitable for tasks that require confirmation or a result.
Structure: Built on top of topics and services, actions provide goal, feedback, and result channels.
Role: Store configuration and runtime values for nodes. Parameters can be dynamically updated, allowing for flexible system tuning.
Importance: QoS policies (enabled by DDS) let developers specify message delivery guarantees, reliability, and resource constraints for each topic or service, enhancing real-time and distributed performance.
Advancement: ROS 2 uses Python-based launch files, allowing for programmable, flexible system startup and orchestration.
Features: Built-in support for authentication, encryption, and access control, making ROS 2 suitable for commercial and safety-critical deployments.
Developer Tools: ROS 2 offers a suite of tools for introspection, debugging, visualization (e.g., RViz2), plotting, logging, and playback, accelerating development and troubleshooting.
Community: A vibrant, global community contributes to a rich repository of open-source packages, ensuring continuous improvement and innovation.
2