ROS 2 Ecosystem: The 20 Packages to Reach For First

Before writing a custom node for a capability listed below, use the maintained upstream package instead. Reinventing TF broadcasting, SLAM, a diff-drive controller, or a bag recorder is wasted effort and a common source of subtle bugs (frame timing, QoS mismatches, coordinate convention errors) that these packages have already had years of real-world use to fix. Install commands below use the binary APT packages (ros-<distro>-<package>, distro = humble or jazzy); prefer these over building from source unless you need an unreleased fix.

Quick reference

Also worth knowing, just past the top 20: rosbridge_suite / foxglove_bridge (WebSocket bridges for browser-based tooling like Foxglove Studio), plotjuggler (standalone bag/live signal plotting), ros2_socketcan (a ready-made SocketCAN ⟷ ROS 2 bridge node, an alternative to hand-writing the CAN bridge shown in [[embedded-ros-bridge]]).

Deeper notes on the highest-leverage / most-misused packages

tf2 — coordinate transforms

from tf2_ros import Buffer, TransformListener
from rclpy.duration import Duration

self._tf_buffer = Buffer()
self._tf_listener = TransformListener(self._tf_buffer, self)
transform = self._tf_buffer.lookup_transform(
    'base_link', 'laser_frame', rclpy.time.Time(), timeout=Duration(seconds=0.2))

• Always pass an explicit timeout to lookup_transform — an un-bounded lookup that never resolves (a missing publisher, a broken TF tree) hangs the calling thread indefinitely.
• Use rclpy.time.Time() (i.e. "latest available") for most control-loop lookups; only request a specific past stamp when you genuinely need to transform a timestamped sensor reading.
• A LookupException/ExtrapolationException almost always means a broken or incomplete TF tree (a missing robot_state_publisher, a static transform never published) — fix the tree, don't catch-and-ignore the exception.

slam_toolbox vs robot_localization — don't confuse the two

• slam_toolbox answers "where am I, and what does the map look like?" from lidar scan matching. It publishes map -> odom.
• robot_localization answers "what's my best continuous pose estimate from these sensors?" by fusing odometry/IMU/GPS. It typically publishes odom -> base_link (and can publish map -> odom too if configured as the global fusion node, but don't run two nodes both publishing the same TF edge).
• A common misconfiguration is running both slam_toolbox and robot_localization each trying to publish map -> odom — pick exactly one authority per TF edge.

rosbag2 — record only what you need

ros2 bag record /scan /tf /tf_static /odom -o my_test_run
ros2 bag play my_test_run

• Explicitly list topics rather than -a (all) on a real robot — recording high-rate raw camera/lidar topics unbounded will fill disk and can starve I/O for other processes.
• Always include /tf_static alongside /tf when recording anything you'll want to visualize later — static transforms are published once (transient-local) and are easy to miss if the recorder started after they were published, unless the topic is explicitly subscribed.

image_transport + cv_bridge — don't publish raw images if you can help it

from cv_bridge import CvBridge
bridge = CvBridge()
ros_image = bridge.cv2_to_imgmsg(cv_frame, encoding='bgr8')

• Publish through image_transport (which offers compressed, theora, etc. transports automatically) rather than raw sensor_msgs/Image on bandwidth-constrained links (Wi-Fi to a base station, a slow serial-tunneled connection).
• Match the encoding string (bgr8, mono8, rgb8, ...) to what the array actually contains — a mismatched encoding is a common source of a visually "wrong colors" but otherwise functioning image pipeline.