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! 🤖

This one has been sitting on my to-do list for a while, and for good reason — lifecycle nodes are one of those topics that you can technically ignore until the day you really need them, at which point you wish someone had forced you to learn them earlier. I’ve been burned enough times by unmanaged hardware drivers doing the wrong thing at startup that I felt it was time to write this properly.

The tutorial covers the full lifecycle state machine from first principles: the four primary states, the six transition states, all transitions with their success and failure paths, and what actually happens inside each callback. There’s a detailed interactive diagram you can expand to read every state and arrow at full resolution.

On the practical side, I use my own ldrobot-lidar-ros2 driver as a concrete example of why lifecycle nodes make sense for hardware: being able to stop a LiDAR motor without closing the serial port, or reconfigure the driver without destroying and recreating the node, is exactly the kind of thing that saves you in production.

The tutorial also covers Nav2’s Lifecycle Manager and, more importantly, explains why Nav2 introduced its own nav2_util::LifecycleNode on top of the standard one — the bond mechanism. If you’ve ever had a navigation stack silently fall apart because one node crashed without anyone noticing, bonds are the answer to that.

And yes, there’s a “Test Your Knowledge” section at the end. Seven multiple-choice questions, some with more than one correct answer. I put a particular amount of care into the on_activate() question — let’s just say it was inspired by personal experience 😅

Happy robotics programming! 🤖

That’s why I’ve added a “Test Your Knowledge” section at the end of every ROS 2 tutorial.

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 an experiment. I’m genuinely curious whether you find it useful, whether the questions hit the right level, whether they actually help you consolidate what you’ve read, or whether the format could be improved.

If you have feedback, drop me a message at info@myzhar.com or reach out via the contact page. I read every message.

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! 🤖

The first project page covers the LD Lidar ROS 2 Driver — a driver I originally wrote because no ROS 2 support existed for the LDRobot LD19 lidar I backed on Kickstarter. What started as a weekend effort to get a /scan topic publishing grew into a full driver: Nav2 Lifecycle nodes, SLAM Toolbox integration, a custom-modelled URDF, udev rules, benchmarking tools, and launch files for every use case. It supports the LD19 and LD06 sensors on ROS 2 Humble and Jazzy.

More ROS 2 project pages are on the way. Stay tuned!

Happy robotics programming! 🤖

Let’s not dwell on that and focus on the good news instead.

I published a detailed tutorial on ROS 2 Python Launch files, packed with tips and tricks I use in my day-to-day workflow to make launch files as flexible as possible by taking full advantage of Python’s capabilities.

I also published an advanced tutorial diving deep into ROS 2 Node Composition, explaining the concepts behind it and how to leverage it to significantly improve the performance of your robotics systems, thanks to IPC (Intra-Process Communication) and zero-copy data transfer.

I hope you find these tutorials useful.

Happy robotics programming! 🤖

The new tutorial is easy and explains simple concepts, but it’s crucial for organizing and managing your robotic applications effectively.

A clear view of how node names and namespaces work can greatly enhance your ability to design and implement complex robotic systems. By understanding these concepts, you’ll be better equipped to avoid naming conflicts, improve modularity, and create more maintainable code.

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

Do not hesitate to reach out if you have any questions or feedback and…

Happy robotics programming! 🤖

This tutorial covers the essentials of using parameters to configure your ROS 2 nodes effectively. You’ll learn how to list, set, and manage parameters both from the command line and using the rqt GUI.

A section is dedicated to using YAML files for parameter management, which is especially useful for complex configurations.

Dive into the tutorial, experiment a bit, and as always…

happy robotics programming! 🤖

If you’ve ever felt confused by how ROS 2 handles communication under the hood, you’re definitely not alone. The middleware layer can be tricky—especially for developers moving from ROS 1 to ROS 2, or even for those jumping straight into ROS 2 for the first time.

In this guide, we’ll explore the different middleware implementations available in ROS 2, including:

• Fast DDS
• Cyclone DDS
• Connext DDS
• GurumDDS
• Zenoh

You’ll also find hands-on examples, clear explanations, and tips for choosing and configuring the best middleware for your project.

Dive in, experiment a bit, and as always—happy robotics programming! 🤖

A Circle Closing?

Twenty-three years ago, in 2003, I began my Computer Engineering thesis by transforming a 2D Sick LiDAR into a 3D sensor to digitize environments for robotic navigation.

Today, the circle closes as Stereolabs, the incredible company I’ve been with since 2018, joins forces with Ouster, a pioneer in 3D LiDAR technology.

Stereo vision and 3D lasers, two passions I’ve cultivated for decades, along with Robotics and AI, are converging in my professional life. It feels like destiny. I’m still processing the emotions of this moment.

I’m eager to see what the future holds as we embark on this new journey together. The possibilities are boundless, and I’m excited to be part of this transformative chapter.