I decided to write this one because of my day job. As Head of Support at Stereolabs, I’ve lost count of how many tickets I’ve opened, read, or answered that all boiled down to the same thing: “I can see the topic in ros2 topic list, I can echo nothing, and I have no idea why.” The customer is convinced the camera driver is broken. It almost never is. What’s broken is the contract between the two ends of the conversation, and that contract is Quality of Service.

It’s such a recurring pattern that I could practically diagnose it in my sleep now. A sensor stream is published one way, someone subscribes the default way, the middleware quietly decides the two are incompatible, and everybody stares at a blinking cursor wondering where the data went. No crash, no error, just silence. When you spend your days helping people integrate real hardware into real robots, you learn very fast that this single concept causes more head-scratching than almost anything else in ROS 2.

But honestly, I didn’t need the support queue to teach me this lesson; MyzharBot taught me first, the hard way. Years ago I spent an entire evening convinced I had a hardware fault on my little tracked robot, because a ultrasonic sensor topic simply wouldn’t reach the node that needed it. I checked cables, I re-flashed, I swapped ports. The real culprit was a mismatched reliability setting between a best-effort sensor and a subscriber that politely demanded guarantees I could never provide. I felt equal parts relieved and embarrassed when I finally found it.

That’s exactly why I promised, back in the Understanding the ROS 2 Communication Middleware tutorial, that QoS deserved its own chapter, and why it kept resurfacing when the qos_overrides parameters showed up in the node parameters tutorial. This is that chapter, and I tried to write the guide I wish someone had handed me before that long “ultrasonic sensor” evening.

I kept the tone practical, with the compatibility tables I actually picture in my head when I read a support ticket, and I closed it with a short “Test Your Knowledge” quiz to make the ideas stick.

If a topic has ever gone mysteriously quiet on you, give it a read. My hope is the next silent topic costs you five seconds instead of an afternoon.

Happy robotics programming! 🤖

The project is called YALIO, which stands for Yet Another Lidar ICP Odometry, and I’ve made it available on GitHub at Myzhar/yalio-ros2.

To be honest, this is a project that has been on my mind for a long time. I spent a significant amount of time searching, but I could never find anything simple online that performs only odometry estimation using 2D lidar information. Most existing solutions are either buried inside massive, complex SLAM suites or are too specialized for a specific research platform. I wanted something modular, lightweight, and easy to drop into any ROS 2 stack—something that does one thing and does it well.

There’s also a bit of personal history behind it. I first worked with ICP (Iterative Closest Point) algorithms back in 2005, right after getting my laurea degree. Back then, I was working on my thesis, and the computational power I had available was a tiny fraction of what a modern NVIDIA Jetson offers. I’ve always wanted to go back and see how these algorithms have evolved over the 21 years since then. After digging back into the literature, I decided to go with Point-to-Line ICP (PL-ICP) because it seemed to be the most promising evolution of the original method for structured environments.

The idea is simple: low-cost 2D lidars like the LDRobot LD19 and LD06 are everywhere now. While they are often used just for basic obstacle avoidance, I believe the scan data they produce is more than good enough to estimate the motion of a robot by matching consecutive scans. YALIO does exactly that. I chose PL-ICP because, unlike standard point-to-point matching, it accounts for the surface geometry of walls and corners, which makes it much more robust in the indoor environments where these 2D lidars typically operate.

I’ve implemented YALIO as a managed (lifecycle) ROS 2 component that loads into a shared container. However, I made a conscious effort to keep the core algorithm in a pure C++ library with no ROS dependency. This means the math can be reused in non-ROS projects or even on tiny embedded systems if needed. If you’ve followed my recent ROS 2 Lifecycle Nodes tutorial, you’ll recognize YALIO as a real-world application of those concepts: the odometry node is a nav2_util::LifecycleNode composable component, optionally managed by the Nav2 lifecycle_manager.

⚠️ Please keep in mind that the project is still a work in progress. I’m currently refining the error handling and tuning the parameters for higher speeds. In the next few weeks, once I have validated and tested it in different lighting and geometric conditions, I will add a new page to the ROS 2 Projects section to describe its internal architecture in detail.

In the meantime, I’ve already added a new branch to my LD Lidar ROS 2 Driver repository, add_yalio_odometry. This branch uses YALIO as the primary odometry source in a new demo SLAM launch file. I finally got to replace the “fake” static odometry node I used in the original launch file with a real, dynamic estimate. This makes the SLAM demo much more meaningful and closer to how a real autonomous robot should behave.

I’m excited to see how this performs on MyzharBot in more complex environments. Stay tuned for updates, and feel free to try it out and open issues on GitHub if you find problems or have ideas for improvements!

Happy robotics programming! 🤖

I have a special relationship with this library. I started using OpenCV back in the early 2000s, during its beta versions, when the API was pure C and the documentation was sparse. I picked it up while writing my laurea degree thesis, and it immediately became the tool I relied on for everything vision-related. Over the following years, I watched it evolve from that original C interface, through the C++ rewrite that made it actually pleasant to use, through the Python bindings that brought it to an entirely new audience, and through the deep learning integration in the 4.x era. It’s a library I’ve grown up with professionally, and every major release carries a bit of that history.

So yes, this announcement landed differently for me than just another library update. OpenCV is one of those tools you just take for granted; it’s been the backbone of computer vision projects for over two decades, and this major version bump is the largest leap the project has taken in a long time.

The official launch happened at CVPR 2026 in Denver on June 4th, with the pip package following on June 8th. And honestly, coming just two weeks after ROS 2 Lyrical Luth, this is shaping up to be quite a season for open-source robotics and computer vision. Two major releases in less than a month; I’ll happily take it.

Given how important OpenCV is to me, I read through the full announcement pretty carefully, and there’s a lot to unpack.

The DNN engine rewrite: the headline feature

If there is one thing that defines this release, it’s the complete redesign of the deep learning inference engine. The old DNN module in OpenCV 4.x was functional but limited; ONNX operator coverage sat at around 22%, which meant you constantly ran into missing ops when trying to load modern models. OpenCV 5 brings that number to 80%+. That is not an incremental improvement; that is a fundamental change in what you can actually run with OpenCV out of the box.

The new engine is graph-based, with proper shape inference, constant folding, dynamic shape support, and even control flow through If/Loop subgraphs. It also handles quantized models natively and includes attention fusion using FlashAttention-style optimizations. This is a serious piece of engineering.

Three engines for a smooth transition

One of the smartest decisions the team made was keeping backward compatibility through a three-tier engine selection model, exposed via the EngineType enum:

ENGINE_CLASSIC is the original 4.x engine, preserved for non-CPU backend support. ENGINE_NEW is the new graph-based engine, currently CPU-only. ENGINE_AUTO is the default: it tries the new engine first and falls back to classic when needed. There’s also ENGINE_ORT, an optional wrapper around ONNX Runtime for cases where you want to delegate to that backend explicitly.

This is a thoughtful migration path. You get the new engine’s benefits immediately for supported models, and nothing breaks for everything else. I can already imagine how many CI pipelines would have exploded otherwise.

LLM and VLM support, natively

This one genuinely surprised me. OpenCV 5 can now run large language models and vision-language models natively, with a built-in tokenizer (no external dependency), KV-cache for autoregressive decoding, and support for Qwen 2.5, Gemma 3, PaliGemma, and the GPT family. The team reports token-for-token accuracy matching ONNX Runtime. Running a VLM from OpenCV directly is not something I expected to see in 2026, but here we are.

Performance numbers

The team benchmarked the new engine against ONNX Runtime on an Intel Core i9-14900KS, and the results are worth quoting: XFeat is 31.25% faster, YOLOv8n is 11.5% faster, OWLv2 is 36.6% faster, and BiRefNet is 32.4% faster. These are real workloads, not toy benchmarks.

New data types and core improvements

OpenCV 5 adds native FP16 (cv::hfloat) and BF16 (cv::bfloat) support, which is long overdue. Working with neural network outputs in deep learning pipelines has always required manual conversion steps; having these types first-class in cv::Mat makes the whole thing significantly cleaner.

There’s also support for 0D (scalar) and 1D tensor representations, proper broadcasting operations, and new 64-bit integer and boolean types. The library is finally catching up to how modern ML frameworks represent data, which matters a lot when you’re gluing OpenCV preprocessing together with PyTorch or ONNX models.

On raw performance: the team reports up to 2x improvements on mathematical workloads and 3 to 4x speedups on ARM for operations like resizing and warping. The Universal Intrinsics layer has been updated to v2.0 with support for SSE, AVX2/512, NEON, SVE, and RISC-V Vector. This is great news for anyone running embedded vision on ARM boards.

Hardware Acceleration Layer (HAL)

This is a feature that I think will have a big long-term impact: OpenCV 5 introduces an automatic dispatch mechanism to vendor-optimized kernels through a Hardware Acceleration Layer. Currently supported backends include Intel IPP (IPPICV) for x86/x64 with SSE/AVX, Arm KleidiCV for AArch64, Qualcomm FastCV for Snapdragon/Hexagon DSP, and RISC-V Vector extensions. The dispatch is automatic; the same OpenCV code just runs faster on each platform.

For robotics and edge deployments, this is a big deal. You write once and the library adapts to the hardware underneath without any extra configuration.

3D vision: a long-overdue reorganization

This section is personally very relevant to my work. The calib3d module, which had grown into a bloated catch-all over the years, has been split into three focused modules:

3d covers geometry, I/O, ICP, and SLAM components. calib handles single and multi-camera calibration, including hand-eye and robot-world calibration. stereo covers depth estimation from stereo pairs.

The new calibrateMultiview API for multi-camera setups, point cloud and mesh I/O for OBJ and PLY formats, dense RGB-D fusion with TSDF, HashTSDF, and ColorTSDF, and the USAC framework with MAGSAC robust estimation are all welcome additions. At Stereolabs, we deal with 3D reconstruction and depth pipelines every day; a well-structured API for these building blocks makes a real difference.

Features module: deep learning meets classic detectors

The features2d module has been replaced by a new features module that brings deep learning-based detection and matching alongside the classic detectors we know and love.

New additions include ALIKED (a CNN-based keypoint detector and descriptor), DISK (reinforcement learning features designed for wide-baseline matching), and LightGlueMatcher (an attention-based matcher with confidence-scored correspondences). Classic detectors like SIFT, ORB, and FAST are retained for backward compatibility, so nothing breaks if you’re not ready to migrate.

The combination of learned features with the classic OpenCV pipeline architecture is interesting; I’m curious to see how ALIKED and LightGlueMatcher perform on real-world robotics sequences versus standard benchmarks.

Generative models in OpenCV

I wouldn’t have predicted this one a couple of years ago. OpenCV 5 ships with LaMa inpainting for mask-guided object removal and a diffusion-based inpainting pipeline as a second option. This feels a bit out of scope for a library historically focused on classical and discriminative vision, but given where the field has gone, I understand the push. It makes OpenCV more self-contained for demo and prototyping use cases.

Python and C++ improvements

On the Python side: NumPy 2.x support is here at last, named (keyword) arguments work properly for algorithm classes, and the bindings have been modernized throughout. If you’ve spent time fighting NumPy deprecation warnings in OpenCV, this update is for you.

On the C++ side: C++17 is now the minimum recommended standard, with C++20 modules planned for later 5.x releases. The legacy C API (the old cvXxx function style) is officially deprecated in this release. It’s been a long time coming; the C API has been a maintenance burden and a source of confusion for newcomers for years.

The documentation has also been migrated from Doxygen to Sphinx + Doxygen, with persistent navigation, hand-written tutorials alongside the API reference, and Python and C++ signatures shown together. A small change in appearance, but a big improvement in day-to-day usability.

What’s coming next in the 5.x cycle

The work isn’t done. The team has committed to GPU acceleration for the new DNN engine (CUDA and TensorRT), a non-CPU HAL for accelerated pre/post-processing that avoids GPU-to-CPU round trips during inference, and C++20 module support. These are the pieces that will make OpenCV 5 really complete for production deep learning pipelines; right now the new engine is CPU-only, which limits where you’d actually deploy it.

Final thoughts

OpenCV 5 is a real release. The DNN engine rewrite alone would justify a major version bump; everything else on top, the HAL, the 3D reorganization, the new data types, and the Python modernization, makes this feel like the library catching up to where the field has been for the past few years. The ~1 million daily installs figure and 86,000+ GitHub stars show how many projects still depend on it; this update will have a wide impact.

If you’re maintaining a computer vision pipeline that uses OpenCV’s DNN module, this is the time to start testing. The ENGINE_AUTO default means migration should be smooth for most cases, but it’s worth validating explicitly rather than assuming. The full OpenCV 5.0 documentation is the best place to start.

Happy robotics programming… with vision! 🤖

I’ve had this one sitting on my to-do list for quite a while, and for a very good reason. Lifecycle nodes are one of those topics that you can technically ignore when you’re first learning ROS 2—right up until the day a hardware conflict or a race condition crashes your robot in a way you can’t explain. At that point, you usually find yourself wishing someone had forced you to learn about managed nodes weeks earlier.

I’ve often joked that in robotics, timing isn’t just everything—it’s the only thing. I’ve been burned enough times by unmanaged hardware drivers doing the wrong thing at startup, or trying to publish data before the serial port was even open, that I finally decided it was time to sit down and write a proper, in-depth guide to this architecture.

I often find that beginners overlook Lifecycle nodes because they seem like unnecessary boilerplate. I certainly did at first. I remember thinking, “Why do I need a complex state machine just to start a node?” But as MyzharBot evolved from a simple mobile platform into a complex system with multiple GPUs and lidars, I realized that deterministic startup is the primary difference between a reliable robot and a fragile prototype.

In this tutorial, I cover the full lifecycle state machine from first principles. I break down the four primary states, the six transition states, and all the success and failure paths. I’ve also detailed exactly what I think should happen inside each callback to keep your system stable. To make it easier to visualize, I’ve included a detailed interactive diagram that you can expand to read every state and transition arrow at full resolution.

On the practical side, I use my own ldrobot-lidar-ros2 driver as a concrete example of why this makes sense for hardware. I’ve found that being able to stop a LiDAR motor without actually closing the serial port, or reconfiguring the driver settings without destroying and recreating the entire node, is a massive time-saver when I’m out in the field.

I also spent a good chunk of the guide talking about Nav2’s Lifecycle Manager. More importantly, I explain why the Nav2 team felt the need to introduce their own nav2_util::LifecycleNode wrapper. I personally think the bond mechanism they added is a life-saver. If you’ve ever had your navigation stack silently fall apart because a depth camera node crashed and none of the other nodes noticed, you’ll appreciate why bonds are so important for safety-critical tasks.

I’m also continuing my new tradition of adding a “Test Your Knowledge” section at the end. I’ve put together seven multiple-choice questions, and I’ll warn you now: some of them have more than one correct answer. I put a particular amount of care into the question about on_activate()—let’s just say that one was inspired by a very long, very painful debugging session I had on MyzharBot a few years back! 😅

I really hope this tutorial helps you build more robust robots.

Happy robotics programming! 🤖

One of the main goals I set for this tutorial series was to make each entry a genuine learning tool, not just a reference document to skim and forget. I want to make sure that when I explain a concept, I’m giving you a way to verify that it actually stuck.

That’s why I’m excited to announce that I’ve added a “Test Your Knowledge” section at the end of every ROS 2 tutorial on the site.

I didn’t want these to be boring, academic tests. I’ve personally designed each quiz to be a short set of multiple-choice questions that target the specific ideas that I’ve seen trip people up—including the mistakes I made myself during my first few months with ROS 2.

What it looks like

Each quiz is a short set of multiple-choice questions covering the key ideas from that tutorial. Questions are deliberately practical, they focus on concepts that tend to trip people up or that matter when you’re working on a real system. You pick an answer, then expand a collapsible panel to see whether you got it right and, more importantly, why.

It looks like this:

What is the default RMW implementation in ROS 2 Humble?

• a) Cyclone DDS
• b) Fast DDS
• c) RTI Connext
• d) Zenoh

Show correct answer

b) Fast DDS
ROS 2 Humble ships with eProsima Fast DDS as its default RMW implementation.

No score, no time limit, just you and the material. If you find yourself unsure about an answer, it’s a good signal to re-read that section of the tutorial before moving on.

Where to find it

The section is already live in every published ROS 2 tutorial:

• Understanding ROS 2
• Installing ROS 2
• Starting ROS 2 Nodes
• Understanding the ROS 2 Communication Middleware
• Configuring a ROS 2 Node Using Parameters
• Understanding ROS 2 Node Names and Namespaces
• ROS 2 Python Launch File Explained
• ROS 2 Node Composition Explained

Scroll to the bottom of any of these pages to find it.

Let me know what you think

This is a bit of an experiment for me. I’m genuinely curious if you find these quizzes useful. Do the questions hit the right difficulty level? Do they actually help you feel more confident about the material? I’m always looking for ways to make my site a better resource for the community, and I’d love to hear your thoughts on how I can improve this format.

If you have any feedback, please drop me a message at info@myzhar.com or reach out through my contact page. I read every single message I get, and I’m always happy to chat about robotics.

Happy robotics programming! 🤖

It pairs with Ubuntu 26.04 “Resolute” as its primary Tier 1 platform, which makes total sense: Lyrical Luth + Ubuntu 26.04 is the LTS-on-LTS combo that most production teams have been waiting for. If you’re still on ROS 2 Humble with Ubuntu 22.04, now is a great time to start planning your migration.

What’s new compared to Jazzy?

Jazzy Jalisco was a good release, but Lyrical Luth brings some things that genuinely excited me when I read the changelog. Let me walk you through what I think is most interesting.

Callback Group Events Executor

This one is huge for performance. The new CallbackGroupEventsExecutor uses 10–15% less CPU than the classic SingleThreadedExecutor and MultiThreadedExecutor. It also comes with proper support for multiple time sources and finer threading control. On nodes with a lot of callbacks, this is a meaningful free win; you just switch executor type and get better efficiency for nothing. Can’t wait to try it on my setups!

Async ROS Nodes in Python (AsyncNode)

Finally! rclpy now has an AsyncNode base class that integrates ROS callbacks natively with Python’s asyncio event loop. If you’ve ever wrestled with mixing async code and ROS subscribers, you know how painful that could be. This makes the whole thing much cleaner and more CPU-efficient than the default SingleThreadedExecutor.

Zero-Copy GPU Data Transfer

This is the one I’m personally most excited about. rosidl::Buffer now lets you publish and subscribe to ROS messages without copying data between CPU and GPU memory. The initial support is for rmw_fastrtps_cpp, but it’s a game changer for any pipeline that touches deep learning or computer vision; the cost of memcpy between GPU frames has always been a silent killer of latency budgets.

Parameters and configuration

• YAML type annotations: you can now use !!str, !!bool, !!int, !!float tags in parameter files to resolve ambiguous type interpretation once and for all
• Parameter range validation extended to integer and double arrays, not just scalars
• Expanded ros2 param CLI with batch operations on single nodes

Launch file improvements

A bunch of quality-of-life improvements here that will make launch files nicer to write and maintain:

• New substitutions: string-join and path-join for XML/YAML launch files
• Per-message log level control: granular severity per message directly from the launch file
• Runtime logging backend selection: via RCL_LOGGING_IMPLEMENTATION env variable, no rebuild needed

Bag recording enhancements

Several additions I’ve wanted for a long time:

• Remote control via ROS service APIs; start/stop/discover bags from anywhere on the network
• Python bag APIs for programmatic pause, resume, seek, and state queries
• Circular recording with --max-bag-files to cap disk usage by auto-deleting the oldest splits
• Descriptive split naming with counter, prefix, and timestamp built in
• Per-topic message loss statistics published to events/rosbag2_messages_lost

CLI enhancements

• ros2 topic bw can now monitor multiple topics at once
• ros2 service info --verbose shows QoS profiles and endpoint details
• ros2 doctor --report expanded to include actions, services, and ROS env variables
• Fish shell support is finally here alongside bash/zsh 🐟

URDF 1.2

The robot description format gets a proper update:

• Quaternion support via quat_xyzw, no more euler-only rotations
• Capsule geometry as a new collision primitive
• Acceleration, deceleration, and jerk limits in joint definitions
• robot_state_publisher can now subscribe to robot_description topic instead of only publishing it

Tracing

For anyone doing serious performance work:

• Runtime opt-out via TRACETOOLS_RUNTIME_DISABLE=1 disable instrumentation without a rebuild
• Snapshot mode with LTTng for “flight recorder” style memory-buffered capture
• Dual session tracing with separate sessions for initialization and runtime events

Developer quality of life

• Thread naming utilities in rcpputils for easier profiling and debugging
• class_loader plugins can now accept constructor arguments for initialization parameters
• rcutils gains Base64 encoding/decoding and strnlen for platform compatibility
• New CMake target ament_ros_defaults for consistent C/C++ version specification across packages

Supported platforms

By the numbers

Behind every apt install ros-lyrical-* there’s a massive community effort: 239 contributors, 110 beta testers, and nearly 2,651 test cases executed. That’s pretty impressive, and it shows how healthy the ROS ecosystem remains.

What’s next?

The next non-LTS distribution, ROS 2 Makoa Mata-mata, is already on the calendar for May 2027.

If you’re on Jazzy, migration should be pretty smooth; most new features are additive and things like the executor change are opt-in. I covered the highlights here, but the full changelog is extensive, so check the official Lyrical Luth release notes for the complete picture before jumping in on production systems.

Happy robotics programming! 🤖

That’s why I’m so excited to finally launch the ROS 2 Projects section of the website. This space is dedicated to the open-source packages I’ve developed, providing a much deeper look into their architecture, their features, and—most importantly—how you can integrate them into your own robotic stacks.

I decided to kick things off with a project that is very close to my heart: the LD Lidar ROS 2 Driver. This project actually started from a place of mild frustration for me. Back in 2021, I backed the LDRobot Kickstarter for the LD19 lidar. When it finally arrived, I was eager to get it running on MyzharBot. However, I quickly discovered that while a ROS 1 driver existed, there was absolutely nothing for ROS 2. Since I was already moving all my development to the newer stack, I didn’t want to look back or use bridge hacks.

What began as a quick weekend hack for me to get a basic /scan topic publishing eventually evolved into a much more robust project. I didn’t want just a prototype script; I wanted a driver that followed modern ROS 2 best practices. I implemented it using Nav2 Lifecycle nodes to ensure predictable state management, integrated it with SLAM Toolbox for easy mapping, and I even sat down to model a custom URDF for the sensor because I couldn’t find a decent 3D model anywhere online.

I also added udev rules to handle those common “permission denied” serial port issues that always seem to pop up at the worst times, and I included benchmarking tools to verify latency—because in robotics, I know that every millisecond counts. It’s been incredibly rewarding for me to see members of the community chime in to confirm support for the LD06 sensor as well. Currently, I’ve ensured that everything works smoothly on both ROS 2 Humble and Jazzy.

This is just the beginning for the Projects section. I have several other packages in the pipeline—ranging from custom sensor interfaces to navigation utilities—that I can’t wait to document and share with you all. I truly believe that by sharing these complete projects, I can help others bridge the gap between “learning” ROS 2 and actually “building” with it.

I’m already working on the next set of project pages, so stay tuned for more updates!

Happy robotics programming! 🤖

Instead of dwelling on the downtime, I want to focus on the two major updates I’ve just pushed to the site. These are topics I’ve been wanting to cover for a long time because they represent the bridge between simply “writing a script” and actually “building a production-ready robot system.”

The first is a comprehensive guide on ROS 2 Python Launch files. If you’ve spent any time in the ROS ecosystem, you know that launch files are the glue that holds everything together. However, moving from the simple XML of ROS 1 to the fully programmatic Python-based system in ROS 2 can be quite a shock. I’ve packed this tutorial with the specific tips and tricks I use in my day-to-day workflow to make my bringup scripts as flexible and reusable as possible. I remember the “aha!” moment I had when I first mastered concepts like OpaqueFunction: it completely changed how I architect my robot software, and I’ve tried to pass that same clarity on in this guide.

The second update is an advanced tutorial diving deep into ROS 2 Node Composition. This is a topic that many developers overlook when they’re starting out, but it’s absolutely crucial for high-performance robotics. As I started pushing more high-bandwidth data, like high-resolution camera streams and dense point clouds, through the latest iterations of MyzharBot, I realized that the standard process-based node model was becoming a massive overhead bottleneck. Composition allows me to load multiple nodes into a single process container, enabling zero-copy data transfer between them. In this tutorial, I explain the core concepts behind IPC (Intra-Process Communication) and show you exactly how to leverage it to make your systems run significantly faster.

I truly hope you find these tutorials useful in your own robotics journey. It feels great to be back at the keyboard sharing these lessons, and I’m already working on the next set of guides to keep this momentum going!

Happy robotics programming! 🤖

Think of it this way: in a complex ROS 2 system, you might have dozens, even hundreds, of individual nodes running simultaneously. Each node performs a specific task, like reading sensor data, controlling motors, or planning a path. Without a clear naming convention and a way to group related nodes, your system can quickly become a tangled mess. That’s where node names and namespaces come in.

A node name is essentially a unique identifier for a specific instance of a node. It’s how you refer to that particular node when you want to interact with it, inspect its state, or remap its topics. For example, you might have two camera drivers, and giving them distinct names like /camera_front and /camera_rear makes it immediately clear which is which.

Namespaces, on the other hand, provide a hierarchical structure, allowing you to group related nodes and topics under a common prefix. Imagine building a multi-robot system, say, with two identical MyzharBots. If both robots use a node named /camera, you’d have a conflict. By assigning each robot its own namespace, like /robot1/camera and /robot2/camera, you can run identical software stacks on multiple platforms without any naming clashes. This is incredibly powerful for scalability and reusability.

A clear understanding of how node names and namespaces work will greatly enhance your ability to design and implement complex robotic systems. It helps you:

• Avoid naming conflicts: As mentioned, this is vital for multi-robot setups or even just when integrating multiple instances of the same type of sensor or actuator on a single robot.
• Improve modularity: Namespaces allow you to encapsulate parts of your system, making it easier to develop, test, and deploy individual modules without affecting the entire application.
• Create more maintainable code: A well-structured naming scheme makes your ROS graph much more readable and understandable, not just for you, but for anyone else who might work on your project. Debugging becomes a much less painful experience when you can quickly identify which node is responsible for what.
• Simplify multi-robot deployments: This is a game-changer. With namespaces, you can launch an entire robot’s software stack, including all its sensors, actuators, and navigation nodes, and then easily duplicate that stack for another robot by simply changing the top-level namespace.

I’ve personally found these concepts invaluable when working on MyzharBot, especially as it evolved through different versions and integrated more complex functionalities. Being able to logically separate the perception stack from the navigation stack, or easily adapt the entire system for different hardware configurations, has saved me countless hours of debugging and refactoring.

This new tutorial dives deep into these concepts, showing you not just the “what” but also the “how.” You’ll learn how to rename and remap nodes at launch, and how to follow best practices for building robust multi-robot systems. It’s packed with practical examples and insights that I’ve gathered over years of working with ROS.

So, if you’re looking to level up your ROS 2 skills and build more robust, scalable, and maintainable robotic applications, I highly recommend checking it out.

Go to the tutorial section to Understand ROS 2 Node Names and Namespaces!

As always, please don’t hesitate to reach out if you have any questions or feedback. I love hearing from you and seeing what you’re building.

Happy robotics programming! 🤖

I remember countless times in the early days of MyzharBot when I would hardcode values directly into my C++ or Python nodes. Every time I wanted to change a PID gain, a sensor threshold, or even just a topic name, I had to recompile or restart everything. It was a huge time sink and a source of constant frustration. That’s why I quickly learned to appreciate the power of ROS 2 parameters.

This tutorial covers the essentials of using parameters to configure your ROS 2 nodes effectively. I’ll walk you through how to declare parameters in your code, how to give them default values, and then, crucially, how to override those values without touching your source code. You’ll learn how to list, get, and set parameters both from the command line—which is great for quick debugging and testing—and using the rqt GUI, which provides a fantastic visual interface for dynamic reconfiguration. I personally love rqt for tuning parameters on the fly while MyzharBot is running, letting me see the immediate impact of my changes.

A significant section of the tutorial is dedicated to using YAML files for parameter management. This is where things get really powerful for complex configurations. Imagine having dozens of nodes, each with multiple parameters. Trying to manage that from the command line would be a nightmare. YAML files allow me to define all my parameters in a structured, human-readable format that I can easily version control, share, and load with a single command. This is indispensable for deploying robots in different environments or with varying hardware setups.

I’ve poured a lot of my practical experience into this guide, aiming to make it as clear and actionable as possible. My goal is to equip you with the knowledge to build ROS 2 systems that are not only functional but also flexible and easy to manage.

So, dive into the tutorial, experiment a bit with configuring your own nodes, and see how much easier it makes your robotics development.

As always, I’m eager to hear your thoughts and see what you build!

Happy robotics programming! 🤖