Why another driver? While working with existing RPLIDAR drivers, I noticed that most are direct ports of legacy code, often missing out on modern ROS 2 features or lacking clean state management. I wanted a driver that feels “native” to ROS 2.
Key Features:
Modern C++ (C++17): Written from scratch using modern paradigms (std::optional, smart pointers) ensuring memory safety and readability.
Lifecycle Node Support: Fully supports the Managed Node state machine (Unconfigured → Inactive → Active). Perfect for fleet management and deterministic startup.
Dynamic Reconfiguration: Supports ROS 2 Parameter Callbacks. You can change the motor RPM or toggle geometric correction at runtime without restarting the node.
Performance Oriented: Optimized to minimize runtime memory allocation (pre-allocated buffers) for consistent latency.
Hardware Support: Verified on A-Series, S-Series, and the new C1 (ToF) model.
I’ve been testing it on ROS 2 Jazzy, and it seems stable.
I am actively looking for feedback and contributors. If you have an RPLIDAR unit gathering dust, please give it a try and let me know what you think!
Subject: Clarification on Development Goals and Philosophy (Response to Feedback)
Thank you for your feedback. Since many of your points were raised on Reddit as well, I would like to take this opportunity to provide a more detailed and accurate explanation here for the ROS 2 community.
Regarding the “Copied Files” (Vendoring)
The 40+ files you mentioned are the RPLIDAR SDK. My focus was not on rewriting the low-level SDK from scratch, but on how the ROS 2 Node interacts with it. Please look at how the node structure has changed to be more “ROS 2 Native” (Lifecycle, Composition) rather than the quantity of SDK files vendored for build stability.
Modern C++ & Code Standards
When I described this project as “modern C++,” I was primarily referring to the architectural and design choices: explicit ownership (RAII), lifecycle-managed resource handling, node-level threading, clear layering, and ROS 2-native concepts such as Composition and managed state transitions. I agree that some modern language-level conveniences (e.g., std::optional) are not yet consistently applied. That is a valid point, and I will update the wording to avoid ambiguity. These are incremental improvements I plan to refine over time, and I welcome PRs that help move the codebase further in that direction.
Networking & Scope Management
Due to current equipment availability and project scheduling, I prioritized stabilizing the Serial communication first. I removed the legacy networking code because it was tightly coupled and unstable. Support for TCP/UDP and other connection methods is planned for future updates, referenced against the existing protocol but implemented in a cleaner way.
Decoupling the SDK
My mention of “lowering coupling” refers to the Node Wrapper design. The goal was to ensure that even if the SDK version changes or new models are added, we only need to update the wrapper logic without rewriting the entire Node architecture. This is about maintainability.
Why I started this project
As you can see from the official repository, there have been few signs of major refactoring, and many issues/PRs seem stagnant. I felt a completely new approach was needed to support modern ROS 2 standards. That is the sole reason I started this project—to provide a better alternative for the community.
Language & Communication
I could explain all of this perfectly in my native language. However, would that help the global community? I use English, the lingua franca of engineering, because my goal is to solve robotics problems together with everyone, not alone. While the AI-assisted tone might feel “over-enthusiastic” or unnatural to you. I ask that you focus on the technology and code, not just the tone of the text.
Motivation & Documentation
I was surprised that many official drivers for affordable sensors, including RPLIDAR, do not yet fully embrace modern ROS 2 concepts such as Lifecycle, Composition, and long-term maintainability patterns. This is not a criticism of the existing maintainers—their priorities and constraints may simply be different from mine. However, for my own use cases, I felt that a more ROS 2-native, lifecycle-oriented design was necessary.
So my blog documents this exploration process: identifying limitations, exploring alternatives, designing a ROS 2-native structure, and implementing it. The goal is to share this reasoning with others who might face similar problems.
If the logical flow of my writing is awkward, I will gladly accept advice. But I hope we can keep the discussion focused on constructive technical improvements.
How can we keep discussion technical if you’re silent about the fact that maybe 99% of “your” work (including the blog) was done by an LLM and you maybe don’t even understand the codebase? This is real dishonesty.
I believe we have discussed the “tooling” aspect enough. Let me clarify my stance one last time, and then I hope we can return to technical discussions.
On LLM Usage & “Devil’s Proof”
As I have stated multiple times, I use LLMs primarily for English polishing. My thought processes, pivot decisions, and architectural intentions have been shared openly across various threads. Debating “what percentage is AI” is a classic “Devil’s Proof.” Even if I explain my personal thought process, you could simply claim that the explanation itself was generated by an LLM. Since it is impossible to prove the absence of AI assistance to someone who has already decided to disbelieve, I see no value in continuing this non-technical discourse.
What is “Understanding the Codebase”?
To me, engineering is not about typing every single character manually. It is about Planning, Designing, Reviewing, Testing, Documenting, and Releasing. And most importantly, it is about Taking Responsibility—listening to feedback, fixing bugs, and maintaining the software. I do all of the above. I believe that is the true definition of “understanding the codebase.”
The Real Goal: Growth & Contribution
My motivation for open source is simple: to help others and to grow as an engineer through that process. Does “LLM usage” really matter if the result helps the community and fosters learning?
For example, a recent discussion on Reddit regarding “Diagnostics” led me to research deep into REP 107. through that interaction, I learned the strict recommendations for hardware diagnostics and the architectural difference between Diagnostics and Watchdogs. This is the kind of interaction I value. I am here to learn and solve problems together.
If you have technical feedback on the code, architecture, or adherence to ROS standards (like the REP 107 I mentioned), I am all ears. But attacking the “tools” I use to overcome language or time barriers seems to miss the point of open source.