ROS 2 & micro-ROS Quick Reference

1. How to use this document

You will not read this end-to-end. Use it like a dictionary with a learning path on top.

Day 1 of your co-op: skim sections 2–4 (Prerequisites, Suggested Path, the Practical N list at the end of section 5).
When you hit an unfamiliar term in a launch file or CMakeLists.txt: Cmd-F the term in section 5.
When you want depth on a topic: follow the 📚 links at the bottom of the section.
When you are working on MCU-based robots: jump to the Micro-ROS entries in this same document (section 5, letter M).

2. Prerequisites

You don't need a robotics degree, but the following mental model is assumed:

Prerequisite knowledge:

C++ or Python: ROS 2 nodes are written in C++ (rclcpp) or Python (rclpy). For micro-ROS, C (C99) is needed for MCU firmware.
Linux command line: source install/setup.bash, colcon build, ros2 run — all from the terminal.
Basic networking (UDP/TCP): ROS 2 uses DDS over UDP. See the Networking Concepts Quick Reference.
CMake: enough to read a CMakeLists.txt and add a dependency.
MCU toolchain (for micro-ROS): ability to compile and flash firmware on an ESP32 (ESP-IDF) or STM32 (STM32Cube).

Hardware: a laptop running Ubuntu 22.04 / 24.04 (or the ROS 2 Docker image). For micro-ROS work, an ESP32-S3 DevKit, STM32 Nucleo, or Raspberry Pi Pico.

3. Suggested learning path (5 steps)

Do these in order. Each step is one evening on the bench.

Step 1 — Set up ROS 2 and run the talker-listener demo

Install ROS 2 Humble or Jazzy on Ubuntu. Run the talker-listener demo. Understand nodes, topics, services, and actions from the CLI.

Step 2 — Write your own ROS 2 node in Python

Create a workspace, write a publisher node, a subscriber node, add parameters and a service. Use rclpy. Build with colcon.

Step 3 — Add URDF, TF2, and visualisation in RViz

Create a URDF model of a simple robot. Visualise it in RViz. Use robot_state_publisher and joint_state_publisher. Understand TF frames.

Step 4 — Flash micro-ROS on an MCU and bridge to ROS 2

Set up the micro-ROS toolchain. Flash micro-ROS on an ESP32 or STM32. Run the micro-ROS Agent on your laptop. Publish sensor data from the MCU as ROS 2 topics.

Step 5 — Run Nav2 on a simulated robot

Install Nav2 and run it on a simulated robot (Gazebo or MuJoCo). Explore the behaviour tree, costmaps, and planners. Connect to a real robot if available.

4. The Practical 15 — read these first

If you only read 15 entries in this glossary, read these. They cover ~90% of what you'll see in your first month on a microcontroller project.

🔥DDS (Data Distribution Service)🔥Launch File (ROS 2)🔥Nav2 (Navigation 2)🔥Node (ROS 2)🔥QoS (Quality of Service)🔥TF2 (Transform Library)🔥Topic (ROS 2)🔥Gazebo (ROS 2 Simulator)🔥MuJoCo (Physics Simulator)🔥ros2_control 🔥SLAM Toolbox 🔥robot_localization 🔥rviz2 🔥Micro-ROS Agent 🔥Micro-ROS Client

Each entry: a one-line definition, then a practical note in italics that says what it means on the bench. Entries marked 🔥 are the practical-15.

Letter

A

1 term

Action (ROS 2)

A long-running, preemptible task with feedback. Built on a goal (send), feedback (stream during execution), and result (return when done). Practical: Use actions instead of services for anything that takes > 1 s: moving a robot arm to a position, navigating to a waypoint, playing a sound. ros2 action list shows available actions. The ROS 2 action server is more robust than the ROS 1 version — it supports preemption and can survive a client disconnect. See also: Service (ROS 2), Topic (ROS 2), Nav2 (Navigation Stack).

Letter

C

3 terms

colcon (Build Tool)

The ROS 2 build tool (successor to catkin_make and catkin build). Wraps CMake + setuptools for ROS packages. Practical: Three commands you'll use daily: colcon build (build everything in the workspace), colcon build --packages-select my_pkg (rebuild one package), colcon test (run tests). Always source install/setup.bash after building. The --symlink-install flag saves rebuild time for Python packages. See also: CMakeLists.txt (ROS 2), package.xml (ROS 2), Workspace (ROS 2).

Composition (ROS 2)

Running multiple ROS 2 nodes in a single OS process using a component container. Nodes are compiled as shared libraries (rclcpp_components) and loaded at runtime. Practical: Composition reduces IPC overhead (zero-copy intra-process) and lowers memory usage — critical on resource-constrained robots. Use ros2 component list to see loaded components. Enabled via the COMPOSITION CMake macro in CMakeLists.txt. See also: Node (ROS 2), rclcpp (ROS 2 C++ Client Library), rclpy (ROS 2 Python Client Library).

CMakeLists.txt (ROS 2)

The CMake build file for a ROS 2 C++ package. Declares dependencies (find_package), builds executables (add_executable + target_link_libraries), installs targets, and registers for testing. Practical: The minimum viable CMakeLists.txt for a publisher:

find_package(rclcpp REQUIRED); add_executable(publisher src/publisher.cpp); ament_target_dependencies(publisher rclcpp); install(TARGETS publisher DESTINATION lib/${PROJECT_NAME})

. Always match versions between find_package and package.xml. See also: colcon (Build Tool), package.xml (ROS 2), rclcpp (ROS 2 C++ Client Library).

Letter

D

3 terms

DDS (Data Distribution Service)

The middleware that ROS 2 uses under the hood for discovery and transport. DDS is an OMG standard (not ROS-specific): nodes discover each other via Discovery Server (default: UDP multicast on the LAN), then communicate directly. Practical: You rarely touch DDS directly — the ROS 2 client library wraps it. Two settings matter: middleware implementation (Fast DDS, Cyclone DDS, RTI Connext — Fast DDS is the default, Cyclone DDS is lighter on embedded), and discovery (ROS_DISCOVERY_SERVER for non-multicast networks). See also: QoS (Quality of Service), Node (ROS 2), Topic (ROS 2).

Discovery Server

A centralized discovery mechanism for DDS when multicast is unavailable (e.g. across VLANs, VPNs, or unreliable Wi-Fi). Instead of every node shouting “who is here?” on a multicast group, they register with a known discovery server. Practical: Use the Fast DDS Discovery Server (fastdds discovery -i 0 -l <ip> -p 11811) when your ROS 2 nodes span multiple subnets. Set ROS_DISCOVERY_SERVER=<ip>:11811 on every node. This is non-optional for robots that connect over cellular or long-range Wi-Fi. See also: DDS (Data Distribution Service), QoS (Quality of Service).

Domain ID

An integer (0–232) that isolates ROS 2 communication on the same network. Nodes with different Domain IDs cannot see each other. Practical: Default is 0. Change it via export ROS_DOMAIN_ID=1 when two ROS 2 systems share a physical network but should not interfere (e.g. lab A and lab B in the same room). If you see nodes from someone else's robot on your ros2 topic list, your domain IDs are clashing. See also: DDS (Data Distribution Service), Discovery Server.

Letter

G

1 term

Gazebo (ROS 2 Simulator)

The reference simulator for ROS 2, used for testing perception, planning, and control without hardware. Gazebo Classic (≤ 11, end-of-life) uses SDF ≤ 1.7. Gazebo (formerly Ignition, now Gz v8+) uses SDF 1.9+ and is the current standard. Practical: Launch a world with gz sim empty.sdf. The ros_gz bridge connects ROS 2 topics to Gazebo topics. Performance tip: use <actor> instead of <model> for non-interactive traffic, and set <max_contacts> to 100 for simple scenes. For headless CI testing, add --render-engine ogre2 -v 4 -s to suppress rendering. URDF files must be converted to SDF for Gazebo. See also: URDF (Unified Robot Description Format), ros_gz (ROS 2–Gazebo Bridge), rosbag (ROS 2).

Letter

L

2 terms

Launch File (ROS 2)

A Python file (.launch.py) that describes which nodes to start, with what parameters, and how they relate. Replaces the XML launch files from ROS 1. Practical: The simplest launch file:

from launch import LaunchDescription; from launch_ros.actions import Node; def generate_launch_description(): return LaunchDescription([Node(package='my_pkg', executable='my_node')])

. Launch files support namespaces, parameter files, conditionals, and including other launch files. Use ros2 launch my_pkg my_launch.launch.py to run. See also: Node (ROS 2), Parameter (ROS 2), Namespace (ROS 2).

Lifecycle Node

A ROS 2 node with a state machine: Unconfigured → Inactive → Active → Finalized. The application controls transitions via service calls, enabling deterministic startup and shutdown. Practical: Use for hardware drivers (camera, LiDAR, motor controller) where you need to configure before activating and clean up before stopping. The ros2 lifecycle list command shows the current state of every lifecycle node. The controller manager in Nav2 (Navigation Stack) uses lifecycle nodes extensively. See also: Node (ROS 2), Nav2 (Navigation Stack).

Letter

M

7 terms

MoveIt 2

The ROS 2 motion planning framework for robotic arms, grippers, and manipulators. Handles kinematics (forward and inverse), collision checking, path planning (OMPL, CHOMP, STOMP), and trajectory execution. Practical: You interact with MoveIt 2 through the MoveGroupInterface (C++) or the moveit_commander (Python). The typical workflow: define your robot in URDF + SRDF, configure the planning scene, set a target pose, plan and execute. MoveIt 2 is the default choice for any ROS 2 arm project in 2026. See also: URDF (Unified Robot Description Format), TF2 (Transform Library), Nav2 (Navigation Stack).

MuJoCo (Physics Simulator)

A fast physics engine from Google DeepMind, optimised for contact-rich simulation (manipulation, grasping, locomotion). Uses .mjb (binary) or .xml (model) files with an MJCF format distinct from URDF/SDF. Practical: MuJoCo is 2–5× faster than Gazebo for the same scene and handles contacts more stably. Integrate with ROS 2 via mujoco_ros or mujoco_ros2 packages, which publish joint_states, tf, and camera images on ROS 2 topics. The MuJoCo viewer (python -m mujoco.viewer) is useful for quick prototyping. Choose MuJoCo when your robot does manipulation; choose Gazebo when you need complex outdoor terrain, sensor noise modelling, or plugin ecosystems. See also: Gazebo (ROS 2 Simulator), URDF (Unified Robot Description Format), colcon (Build Tool).

Micro-ROS Agent

A ROS 2 node that acts as a gateway between the micro-ROS client (on an MCU) and the rest of the ROS 2 graph. The agent runs on a Linux machine (laptop, Raspberry Pi, or companion computer). It translates DDS/XRDCE serialized messages from the MCU into standard ROS 2 topics. Practical: Run ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyUSB0 for a wired MCU, or ros2 run micro_ros_agent micro_ros_agent udp --port 8888 for wireless. The agent is a standard ROS 2 node — you can inspect it with ros2 node list, ros2 topic list, etc. See also: Micro-ROS Client, Transport (Micro-ROS), DDS (Data Distribution Service).

Micro-ROS Client

The lightweight ROS 2 client library that runs on a microcontroller. Supports a subset of the ROS 2 API: publishers, subscribers, services, and parameters — but not actions or composition. Practical: The client is written in C99 with no dynamic allocation (memory is pre-allocated in the rclc_support_t init struct). Target MCUs: ESP32, STM32, Raspberry Pi Pico (RP2040), Arduino Portenta. The client communicates with the Micro-ROS Agent over a serial or UDP transport. Use rclc_executor_t to spin — it replaces the standard rclcpp::spin(). See also: RCLC Executor, Transport (Micro-ROS), Micro-ROS Agent.

Micro XRCE-DDS

eProsima's protocol for serializing DDS messages over resource-constrained links. The XRCE (X-Robotics Communication for Embedded) protocol is the wire format used by micro-ROS to communicate between Client and Agent. Practical: You never see XRCE frames directly — the Client library handles serialization and the Agent handles deserialization. The overhead is ~12 bytes per message header, making it feasible even at 115200 baud. The rmw_microxrcedds package is the RMW implementation that uses XRCE under the hood. See also: RMW (ROS Middleware), Micro-ROS Agent, Micro-ROS Client.

Memory Constraints (Micro-ROS)

The defining challenge of micro-ROS: fitting a ROS 2 node into 100–500 KB of RAM. Strategies: (1) pre-allocate everything statically (no malloc after init); (2) limit the number of topics, services, and handles; (3) reduce the DDS participant count (one per node, not per object); (4) use rcl_get_default_allocator() with a static memory pool. Practical: A minimal publisher + subscriber on an ESP32-S3 uses ~80 KB RAM. Adding services adds ~15 KB each. Always profile with idf.py monitor or freeRTOS heap debugging. If you run out of memory, the executor will silently stop calling callbacks. See also: RCLC Support, Micro-ROS Client, ESP32-S3.

micro_ros_setup

A ROS 2 package that generates, configures, and builds micro-ros firmware for different MCU platforms. Provides scripts for creating a firmware workspace, configuring the transport (serial/UDP), selecting middleware options, and flashing. Practical: The typical workflow: ros2 run micro_ros_setup create_firmware_ws.sh esp32 → ros2 run micro_ros_setup configure_firmware.sh esp32 --transport serial → ros2 run micro_ros_setup build_firmware.sh → ros2 run micro_ros_setup flash_firmware.sh. This is the recommended way to start — manual builds are error-prone. See also: Micro-ROS Client, Transport (Micro-ROS), colcon (Build Tool).

Letter

N

3 terms

Namespace (ROS 2)

A prefix applied to a node's topics, services, and parameters to group them. For example, a node named camera in namespace /robot1 publishes to /robot1/camera/image. Practical: Namespaces let you run two copies of the same robot stack on the same machine or network without collision — critical for multi-robot systems. Set with ros2 run my_pkg my_node --ros-args -r __ns:=/robot1. See also: Launch File (ROS 2), Domain ID.

Nav2 (Navigation 2)

The ROS 2 navigation stack for mobile robots. Handles localization (AMCL / particle filter), path planning (global: NavFn, Smac; local: DWB, Regulated Pure Pursuit), control, recovery behaviors, and costmap management. Practical: Nav2 is the de facto standard for wheeled robots in ROS 2. Configure it via YAML parameter files for your robot's footprint, speed limits, and planner. The nav2_bringup package provides a single launch file to get started. Calibrate your robot's odometry before tuning Nav2 — garbage in, garbage out. See also: TF2 (Transform Library), Action (ROS 2), Lifecycle Node.

Node (ROS 2)

The fundamental unit of computation in ROS 2. A node is a process (or component) that communicates with other nodes via topics, services, actions, and parameters. Practical: Every ROS 2 program is one or more nodes. A typical robot runs 10–50 nodes: one per sensor driver, one for localization, one for planning, one for control. Write nodes in C++ (rclcpp) for performance or Python (rclpy) for rapid prototyping. ros2 node list shows running nodes; ros2 node info /my_node shows its interfaces. See also: Topic (ROS 2), Service (ROS 2), Action (ROS 2), Composition (ROS 2).

Letter

P

2 terms

package.xml (ROS 2)

The manifest file for a ROS 2 package. Declares the package name, version, maintainer, license, dependencies (build, runtime, test), and export tags. Practical: Every ROS 2 package needs a package.xml. The two most common dependencies: <depend>rclcpp</depend> for C++ nodes, <depend>rclpy</depend> for Python nodes. Run ros2 pkg create my_pkg --build-type ament_cmake to scaffold one. See also: CMakeLists.txt (ROS 2), colcon (Build Tool).

Parameter (ROS 2)

A configurable key-value pair attached to a node. Parameters replace global ROS 1 rosparam and are declared per-node. Practical: Set parameters at launch via ros2 run my_pkg my_node --ros-args -p my_param:=42, or load from a YAML file. Parameters can be dynamically updated at runtime (if the node supports it). ros2 param list shows available params; ros2 param get /node param_name reads one. Use parameters for anything that changes between robot configurations — PID gains, speed limits, sensor calibration values. See also: Node (ROS 2), Launch File (ROS 2).

Letter

Q

1 term

QoS (Quality of Service)

A set of DDS policies that control how messages are delivered: Reliability (Best Effort vs. Reliable), Durability (Transient Local vs. Volatile), History (Keep Last vs. Keep All), Depth (how many samples to buffer). Practical: Use Reliable for commands (you must not miss a “stop” message) and Best Effort for sensor data (a dropped LiDAR scan is OK if the next one arrives). If a publisher and subscriber have incompatible QoS profiles, they won't connect — ros2 topic info /topic --verbose shows compatibility. The rclcpp::QoS class makes this easy in C++. See also: DDS (Data Distribution Service), Topic (ROS 2).

Letter

R

10 terms

RCLCPP / RCLPY

The ROS 2 client libraries for C++ (rclcpp) and Python (rclpy). rclcpp is faster, lower-level, and the right choice for drivers, controllers, and performance-critical nodes. rclpy is slower but much faster to write — ideal for behavior scripts, data logging, and prototypes. Practical: Most teams write the “hardware-near” nodes in C++ and the “logic” nodes in Python. Both libraries wrap the same rcl (ROS Client Library) C interface, so they can coexist in the same system. See also: Node (ROS 2), Composition (ROS 2).

rosbag (ROS 2)

A tool and format for recording and playing back ROS 2 messages. ros2 bag record -a records all topics; ros2 bag play my_bag replays them. Practical: Essential for debugging: record a bag while the robot runs, then replay it in a development environment to test changes without the hardware. Bags are stored as SQLite3 databases (ROS 2 .db3 format). Use ros2 bag info my_bag to inspect contents. For long recordings, filter topics: ros2 bag record -o robot_run /camera/image /scan /tf. See also: Topic (ROS 2), rqt.

rqt

A Qt-based GUI framework for ROS 2 with plugins: rqt_graph (visualize the node/topic graph), rqt_plot (plot numeric topic data), rqt_reconfigure (dynamically tune parameters), rqt_image_view (display camera images). Practical: rqt_graph is the #1 tool when onboarding to an existing ROS 2 codebase — it shows you which nodes talk to which topics. Launch rqt from the terminal with the same ROS domain as your running nodes. Plugins are extensible; rqt_bag is a visual bag viewer. See also: rosbag (ROS 2), TF2 (Transform Library).

ros_gz (ROS 2–Gazebo Bridge)

The official bridge package bridging ROS 2 and Gazebo communication. Maps Gazebo topics/ services to ROS 2 equivalents via a YAML configuration file. Practical: The simplest bridge: ros2 run ros_gz_bridge parameter_bridge /cmd_vel@geometry_msgs/msg/Twist@gz.msgs.Twist. Use a YAML config file for complex setups: bridge: blocks mapping topics, with fields ros_topic, gz_topic, type, and direction (BIDIRECTIONAL, GZ_TO_ROS, ROS_TO_GZ). ros_gz_sim provides spawn and delete entity services. Start seeing topic data with gz topic -e -t /world/default/model/my_robot/link/odometry/odometry. See also: Gazebo (ROS 2 Simulator), Topic (ROS 2), Parameter (ROS 2).

ros2_control

The standard framework for robot control in ROS 2. Defines a Controller Manager (loads, unloads, switches controllers at runtime), Hardware Interfaces (abstracts the real or simulated robot hardware), and Controllers (e.g. joint trajectory, velocity, position). Practical: All modern ROS 2 robots use ros2_control. Set up with a YAML config file describing your hardware (<ros2_control> tags in URDF) and controllers (ros2_controllers.yaml). Start the controller manager with ros2 run controller_manager controller_manager, then load a controller: ros2 control load_controller joint_state_broadcaster --set-state active. Common controllers: joint_state_broadcaster, joint_trajectory_controller, diff_drive_controller, position_controllers. See also: URDF (Unified Robot Description Format), Node (ROS 2), Lifecycle Node.

robot_localization

A package for sensor fusion and state estimation using an Extended Kalman Filter (EKF) or Unscented Kalman Filter (UKF). Combines IMU, wheel odometry, GPS, visual odometry, and other sensors into a single filtered odometry estimate. Practical: Configure via ekf.yaml with sensor topics and noise covariances. Launch ros2 run robot_localization ekf_node --params-file ekf.yaml. The node publishes odometry/filtered (nav_msgs/Odometry) and tf from odom to base_link. Key gotcha: set two_d_mode: true for wheeled robots (fixes roll/pitch). robot_localization is the de facto state estimator for ROS 2 mobile robots — don't write your own filter. See also: TF2 (Transform Library), Nav2 (Navigation Stack), SLAM Toolbox.

rviz2

The 3D visualization tool for ROS 2. Displays robot models (URDF), sensor data (laser scans, point clouds, camera images), transforms (TF tree), paths, maps, and custom markers. Practical: Launch with rviz2 or ros2 run rviz2 rviz2. Save your display configuration as a .rviz file and load it: rviz2 -d my_config.rviz. Essential displays: RobotModel (loads URDF), TF (shows coordinate frames), LaserScan, PointCloud2, Map, Path. For programmatic markers, use visualization_msgs/Marker and MarkerArray — publishing to /rviz_markers with a namespace. rviz_visual_tools provides a convenient C++/Python API for common shapes. See also: URDF (Unified Robot Description Format), TF2 (Transform Library), rqt.

RCLC Executor

The micro-ROS executor that replaces the standard ROS 2 spinning loop. It is a cooperative, non-blocking scheduler that polls publishers, subscribers, services, timers, and guard conditions in a single thread with configurable timing. Practical: Pattern:

rclc_executor_init(&executor, &support, num_handles, &allocator); rclc_executor_add_subscription(&executor, &sub, &msg, &callback); rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100));

. You control how much time the executor spends per cycle — critical for real-time control loops. Do not use blocking calls inside callbacks. See also: Micro-ROS Client, RCLC Support, rclcpp (ROS 2 C++ Client Library).

RCLC Support

The initialization struct that allocates all memory for a micro-ROS node. Created with rclc_support_init(&support, 0, NULL, &allocator). Holds the DDS participant, the ROS 2 node handle, and the allocator. Practical: You always allocate the support struct first, then create nodes, publishers, and subscribers from it. On constrained MCUs (like the RP2040 with 264 KB RAM), pre-allocate a pool and pass it via rcl_get_default_allocator() or your own static allocator. The support struct must outlive all handles created from it. See also: RCLC Executor, Micro-ROS Client, Transport (Micro-ROS).

RMW (ROS Middleware)

The ROS Middleware interface — an abstraction layer between the ROS 2 client library and the DDS implementation. In micro-ROS, the RMW is rmw_microxrcedds, a minimal RMW that uses eProsima's Micro XRCE-DDS serialization instead of full DDS. Practical: The micro-ROS RMW trades features (no QoS profiles beyond default, no multi-participant) for memory footprint (~50 KB RAM for a simple publisher + subscriber). You don't configure the RMW directly — it's baked when you build the firmware. See also: DDS (Data Distribution Service), Micro-ROS Client, Transport (Micro-ROS).

Letter

S

2 terms

Service (ROS 2)

A synchronous request-response communication pattern. The client sends a request and blocks (or awaits) until the server returns a response. Built on a service definition file (.srv). Practical: Use services for one-shot queries: “what is your current pose?”, “set the camera exposure”, “enable the motor brake”. ros2 service list shows available services; ros2 service call /my_service my_interfaces/srv/MySrv "{}" calls one from the CLI. Compare with Action (ROS 2) for long-running or feedback-producing calls. See also: Topic (ROS 2), Action (ROS 2).

SLAM Toolbox

The primary SLAM (Simultaneous Localization and Mapping) package for ROS 2. Builds a 2D occupancy grid map from laser scan data while estimating the robot's pose in real time. Practical: Launch with ros2 launch slam_toolbox online_async.launch.py. Two modes: online_async (real-time, non-blocking — recommended) and online_sync (blocking, lower latency but may drop scans on slower hardware). Save the built map: ros2 run nav2_map_server map_saver -f my_map. Relocalize against an existing map using ros2 launch slam_toolbox localization_launch.py map:=my_map.yaml. SLAM Toolbox replaced gmapping and is the default choice for 2D ROS 2 SLAM in 2026. See also: Nav2 (Navigation Stack), TF2 (Transform Library), rosbag (ROS 2).

Letter

T

4 terms

TF2 (Transform Library)

The library that manages coordinate transforms between frames in ROS 2. Maintains a tree of frame relationships (e.g. map → odom → base_link → laser_link) and can look up the transform between any two frames at any time. Practical: Every sensor and actuator needs a TF frame. Publish static transforms with a static_transform_publisher node; publish dynamic transforms (odometry) from your localization node. ros2 run tf2_tools view_frames generates a PDF of your TF tree — the first thing to check when a sensor seems “in the wrong place”. See also: URDF (Unified Robot Description Format), Nav2 (Navigation Stack).

Topic (ROS 2)

The primary communication channel in ROS 2. Topics are named buses over which nodes exchange messages of a specific type (defined in .msg files). Publishers write to a topic; subscribers read from it. This is a one-to-many, anonymous pub-sub pattern. Practical: ros2 topic list shows active topics; ros2 topic echo /topic_name prints messages in real-time; ros2 topic hz /topic_name shows the publishing rate. Topic names are hierarchical: /robot/camera/image_raw. Choose message types from std_msgs, geometry_msgs, sensor_msgs, or define your own in a custom .msg file. See also: Node (ROS 2), Service (ROS 2), DDS (Data Distribution Service).

Transport (Micro-ROS)

The physical link between the MCU running micro-ROS and the Agent. Options: Serial (UART over USB or dedicated TX/RX pins), UDP (over Wi-Fi or Ethernet), Custom (CAN, Bluetooth, LoRa — implement the transport interface). Practical: Serial is simplest (just a USB cable), but limited to ~1 Mbps. UDP over Wi-Fi (ESP32) gives higher throughput but adds latency jitter. The transport is configured at build time in the firmware and at launch time for the Agent. Use micro_ros_setup to configure transports in your build. See also: Micro-ROS Agent, Micro-ROS Client, Serial (UART).

Timing / Real-Time (Micro-ROS)

Micro-ROS does not provide hard real-time guarantees on most MCUs — it depends on the underlying RTOS. On FreeRTOS (ESP32, STM32), you can set task priorities and use interrupt-safe patterns. The rclc_executor_spin_some() pattern lets you bound the maximum time spent in ROS callbacks per loop iteration. Practical: For hard real-time control (motor current loops at 10 kHz), do the control in a dedicated FreeRTOS task or timer ISR, and publish the state to ROS at a lower rate (100 Hz). The executor can be called from the low-priority idle task. See also: RCLC Executor, Micro-ROS Client, FreeRTOS.

Letter

U

1 term

URDF (Unified Robot Description Format)

An XML format that describes a robot's kinematic chain: links (with geometry, visual, collision meshes), joints (revolute, prismatic, continuous, fixed), and material properties. Practical: URDF is the starting point for any robot simulation or planning. Tools: urdf_to_graphiz generates a visual tree from the URDF; check_urdf validates the file. For complex robots, use xacro to parameterize the URDF with macros. The robot state publisher node publishes the URDF as a TF tree. Keep the URDF in a dedicated <robot>_description package. See also: TF2 (Transform Library), MoveIt 2, Gazebo (ROS 2 Simulator).

Letter

W

1 term

Workspace (ROS 2)

A directory tree containing source code (src/), build artifacts (build/), installed packages (install/), and logs (log/). Created with mkdir -p my_ws/src && cd my_ws && colcon build. Practical: You set up the workspace environment with source install/setup.bash. Use a fresh workspace per robot project. Overlay workspaces: source the base workspace (e.g. ROS 2 core), then your overlay workspace — changes in the overlay shadow the underlay. This is how you develop a single package against a stable ROS 2 installation. See also: colcon (Build Tool), package.xml (ROS 2).

No matches

Try a different term, or press Esc to clear the search.

6. Quick reference tables

6.1 Essential ROS 2 CLI commands

Command	Description
`ros2 run <pkg> <node>`	Run a node from a package
`ros2 topic list`	List all active topics
`ros2 topic echo <topic>`	Subscribe and print messages
`ros2 node info /node`	Show node info
`colcon build`	Build the workspace

6.2 micro-ROS transport comparison

Transport	Medium	Max throughput	Best for
Serial (UART)	Wired (TX/RX)	~1 Mbps	Low-latency, reliable
UDP	Wi-Fi / Ethernet	Limited by network	Wireless, multi-agent
TCP	Wi-Fi / Ethernet	Limited by network	Reliable streaming
Custom (CAN, BLE)	Varies	Varies	Specialized hardware

7. Further reading

🔥 ROS 2 Documentation — docs.ros.org
🔥 micro-ROS documentation — micro.ros.org
🔥 micro-ROS GitHub — github.com/micro-ROS
📚 Nav2 documentation — navigation.ros.org
📚 ROS 2 Design (articles + demos) — design.ros2.org

Last updated: July 2026. Maintained as a living document — if a term on your co-op isn't here, add it.