[Announcement] rplidar_ros2_driver: A Modern C++ (C++17) Driver with Lifecycle Support

Projects
1

Hi ROS 2 Community,

I’m happy to announce the release of a new ROS 2 driver for Slamtec RPLIDAR devices: rplidar_ros2_driver.

GitHub Repository: GitHub - frozenreboot/rplidar_ros2_driver

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!

9 Likes
ROS News for the Week of January 5th, 2026 :tada:
Guidelines Must be Updated
2

This is one of worst AI slop posts that I’ve seen upvoted here and on Reddit

  • Claims: I rewrote it from scratch and heavily refactored
    • OP copied 40 files, then changed 2 classes
  • in Modern C++ (std::optional)
    • there’s no optional in whole repo
  • removed working code:
    • hardcoded serial, so networking based lidars won’t work
  • “Table of shame”, "Industrial
    • If anything this is opposite of industrial
  • claims Table of Shame Tight SDK Coupling - but copies the same SDK
  • multithreading… the rplidar SDK (that he copied) uses threads internally
  • Wrote whole GPT slop blog about it (why?)

I usually upvote everything, and OP might have good idea (Lifecycle), but the way and form is misleading at best and false at worst.

I get it, the Rplidar repo doesn’t take PR’s too often, but the whole vibes of this is… weird.

Now OP will say he used GPT (to make 20 page of slop blog right?) because he’s not native speaker.

2 Likes
Guidelines Must be Updated
4

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

5

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.

Edit: I wrote this post at a time when there was a verifiable discrepancy between the announced features and the actual code. @frozenreboot has explained later in this topic that it was a mistake. He also added a clear notice explaining how, how much and where he used AI in the repo. Great, thanks!

3 Likes
6

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.

  1. 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.

  2. 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.”

  3. 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.

7

Great driver. @frozenreboot :clap:

Slamtec probably do support Chinese users but even their testing tool on Windows is not working outside of China.

Thank you for posting about it everywhere, that’s how I learned about it from a friend. I was going to write a new one myself with Lifecycle, Composition, Hot-plug recovery but this was a good starting point for me. I added linear interpolation to fix the LaserScan jitter. Added, PointCloud2 support and sent a PR!

And please, bro, do NOT let the opinions of the whining people: @peci1 and @martincerven discourage you here. If they could do it, they would do it for themselves or send a PR to support this effort, for the forever-non-ending issues of the Slamtec devices.

1 Like
8

Thank you for the kind words and the support, Orhan. I’m glad my work provided a good starting point for your needs.

I completely agree—my goal is to build a driver that is robust enough for real-world commercial applications, not just for research. I’m reviewing your PR now, and the improvements (especially the interpolation and PointCloud2 support) look solid. I’ll merge them shortly. Let’s make this the standard!

9

@Katherine_Scott I have a couple of questions. I am sorry if I sound harsh but it truly saddens me when I see a kid bullied.

I see that you liked Martin’s reply. Since you are an official, an OSRA TGC Member, does that mean, saying things like

…you maybe don’t even understand…

(emphasis on the maybe which means “not knowing”) and

This is real dishonesty.

is totally within the community guidelines? Totally okay?

About the OpenRobotics’ LLM views, They are discouraging a lot of users with this attitude. (I followed it since it was a real Foundation, I started with ROS 1 Indigo). But this is something else. Can you you tell us where the official guidelines discourage users from writing custom ROS packages (not the contributions to the official repos) using LLMs, and sharing them with the community?

If there were no people like Steve Macenski (which approved multiple PRs of mine, God bless the neighborhood navigator), what would be the current state of the ROS? I opened a PR to the teleop_tools, tried to talk with the maintainers about sending another PR with a fix I am using locally, not using LLMs, but still, I did not hear a ping for almost a year.

A one-line-change PR of mine, to ROS 1, was merged after 1+ years, long after I switched to ROS 2.

None of those PRs were written using LLMs.

You cannot see me crying in this forum because of silent PRs, I understand that the maintainers could be busy.

If I write “ROS2” instead of “ROS 2”, I can be judged by the Open Robotics nonprofit corporation, but not when bullying new users in the community? I am using a lot of local modified forks of the official repos, including the launch package itself, because of this behaviour of not-regulating-official-repos enough but regulating-non-important-things. Please at least regulate this forum.

Disclamer: Even though I am also not a native speaker; Not a single LLM was used when writing this post. You can see dat da last PR link shows da date 2021, while da ChatGPT was first released in 2022.

1 Like
10

I’m glad you raised the concern, Orhan.

However, in this case, I stand by what I said before.

If the author explicitly mentions the code now uses `std::optional` and it does not, then this is a smoke trail. A smoke trail leading me to the conclusion that the author does not understand his code and maybe hasn’t even written it. Because, if he spent last 2 weeks writing the driver, he’d know very precisely whether he used std::optional or not. And even though this might look like a very small smoke trail, it undermines my trust in the driver (and, transitively, to the author).

I don’t say that manually written code is 100% bug-free. Some people really are better programmers with LLMs (although recent rigorous experiments show that it’s not the majority case). But as it has been established in ROS core development, academia and many other fields, it is the human who is responsible for LLM-generated code. As written above, the smoke trail leads me to the conclusion that this responsibility has not been fulfilled. Therefore, I’d expect the author admitting it so that potential users of the code would know. Nothing less, nothing more. But not disclosing this seems dishonest to me. That’s what I wrote and what I still stand for.

And I don’t say the driver cannot be usable. It might very well be! I might even use it for our school Turtlebots next semester if it shows to be working. But this story around makes it a bit bitter.

As an analogy why I think the “author” of LLM-generated code is the one who should be responsible for checking could be as follows: I guess every one of us has this kind of friends who go on a trip with you, take photos, and then send all the 1000 photos to everybody who was on that trip. This photo-bursting friend has maybe not even seen all of his photos, he just took (‘generated’) them. And there are some very valuable and great ones! But then, instead of him taking the 30 minutes to go through the photos and select 100 nice ones, each of the people who went to the trip have to spend their 30 minutes wading through the flood. This is what I find dishonest. Wasting peoples’ time.

1 Like
11

Hi everyone, I’m the maintainer of this package.

I want to clarify a few things regarding the recent discussion.

1. Regarding the “missing std::optional”
@peci1 You are absolutely right. The README mentioned std::optional, but the current codebase does not use it.
This is entirely my fault, not @Orhan’s.
In the early stages of development, I did use std::optional and other features. However, as I aggressively refactored the code for performance and simplicity (iterating through many versions before v1.0.0), those patterns were replaced. I simply failed to update the documentation to reflect these changes. This was a case of documentation drift, and I apologize for the confusion.

2. Development Process
This is my first major ROS 2 driver, and it has been a journey of trial and error. I often squashed “dirty commits” and rewrote large chunks of code to get things right, which contributed to the documentation mismatch.

3. v1.3.0 Release Candidate
However, I believe actions speak louder than words.
I have just opened a Pull Request which serves as the release candidate for v1.3.0.
[Pr 13 Plus by frozenreboot · Pull Request #14 · frozenreboot/rplidar_ros2_driver · GitHub]
In this PR, I consolidated @Orhan’s contributions (Interpolation, real-world experience) and applied critical stability fixes myself (Segfaults in dummy mode, Lifecycle activation issues).

The code is now stable and fully verified.
I will merge this PR shortly after a final review. I invite everyone to check the PR and judge the driver by its performance.

Thanks.

2 Likes
12

The author explained the std::optional case that I was already assuming.

However, since you like following smoke trails and detective work,

[Sherlock Holmes:] “The temptation to form premature theories upon insufficient data is the bane of our profession.”
— Arthur Conan Doyle

A good detective doesn’t assume.

So,

Concluding deductions based on a weak smoke trail, leads to unintentionally believing them. And that leads to blaming people unnecessarily. I’ve read all the Sherlock Holmes books, I suggest reading them as dealing with software is kind of a detective work. Arthur Conan Doyle based his Sherlock Holmes character on a real person, Joseph Bell, his professor at the Medical School, father of the forensics as a science. Don’t discard them as fiction.

Sometimes even the wisest of man or machine can make an error.
— Optimus Prime

But the good ones apologise.

13

Liking a post does not mean that you officially endorse the post or that you agree with every possible extracted snippet. Sometimes I like things to just to acknowledge that I’ve seen them. I also liked the original post. I think an improved, modern, RPLidar package is a good thing. I also think it is totally healthy and productive to acknowledge when things appear to be AI generated.

About the OpenRobotics’ LLM views, They are discouraging a lot of users with this attitude. (I followed it since it was a real Foundation, I started with ROS 1 Indigo). But this is something else. Can you you tell us where the official guidelines discourage users from writing custom ROS packages (not the contributions to the official repos) using LLMs, and sharing them with the community?

We do not discourage LLM generated posts. We do ask that LLM content be clearly marked as such.

If there were no people like Steve Macenski (which approved multiple PRs of mine, God bless the neighborhood navigator), what would be the current state of the ROS? I opened a PR to the teleop_tools, tried to talk with the maintainers about sending another PR with a fix I am using locally, not using LLMs, but still, I did not hear a ping for almost a year.

A one-line-change PR of mine, to ROS 1, was merged after 1+ years, long after I switched to ROS 2.

None of those PRs were written using LLMs.

You cannot see me crying in this forum because of silent PRs, I understand that the maintainers could be busy.

None of those Github orgs are managed by the OSRA. ROS is a huge project maintained by volunteers, there are lot of places where we need more volunteer support. My advice is, as always, if you want your PR reviewed promptly, help out the maintainer by reviewing another pull request.

If I write “ROS2” instead of “ROS 2”, I can be judged by the Open Robotics nonprofit corporation, but not when bullying new users in the community?

Encouraging people to use the official ROS brand guidelines is not “judging”. They were designed to help communicate that ROS 2 is a version of ROS not a new thing. And planning that out and sticking to it through the transition is going to make our life easier going forward.

I wouldn’t characterize @peci1 comments as bullying. Pointing out that the project appears to be generated by an LLM provides additional useful context to potential users. The responses and clarifications have been helpful to understand more about the announced software.

3 Likes
15

About the PR links I shared, yes, even though they have members which are also members of the OSRA. But not the launch package I mentioned. It is in fact, managed by the OSRA, resides in the ros2 Github organization. If I comment on a PR and get no response, why would I bother the maintainers by keep spamming instead of using a local fork with that change?

Yeah. Then coming here and calling it “AI slop” must be the correct way to mark things. (The other Martin)

I would, if it is directly attacking the person. I don’t see any constructive criticism here:

The other Martin said

I call both these Martins’ comments illogical at best, bullying at worst.

Thanks for the support but also supporting the non-constructive criticism makes no sense to me.

I truly don’t think so.

16

Hi everyone.

@Orhan, thank you for your support and for sharing your experiences. However, I believe we have clarified our stances enough. I would appreciate it if we could now shift the focus of this thread back to the technical aspects of the driver. Let’s cool down and get back to robotics.

@Katherine_Scott, thank you for providing the specific link. I have carefully reviewed the OSRF Policy on the Use of Generative AI in Contributions as you suggested.

To ensure full transparency and compliance:

  1. Immediate Update: I have updated the repository’s README to explicitly disclose the use of AI tools in accordance with the policy guidelines.
  2. Git History: I have decided to preserve the existing git history (without the tags) to maintain repository integrity and avoid issues for current users (e.g., hash changes).
  3. Future Compliance: Moving forward, I will strictly adhere to the Generated-by: tag convention in the commit messages and PR descriptions for all future contributions.

I appreciate you bringing this to my attention. I am committed to following the community standards.

1 Like
17

@frozenreboot Bro I’d like to apologise for turning your announcement post to a community guideline lecture, It wasn’t my intention. I was lead to it, and I could do this all day, if you haven’t requested otherwise since I haven’t got the response I expected from an official.

Also I apologise to @Katherine_Scott about my not-up-to-date information about their LLM views, but not about pointing out the obvious. There is a clear violation of policy here. Differentiating between “helpful / constructive criticism” and “ad hominem accusation / insulting language” must not be that hard. It is definitely against Open Robotics Discourse - Guidelines no matter if you pass a certain metric to be a “Great Contributor”.

Not counting the academia, in my 10+ years of commercial and industrial Robotics experience and as a ROS user in parallel, I’ve learned that what matters most is the architecture, output and reliability. You added features like

  • Lifecycle management,
  • Composition support,
  • Hot-plug recovery

which were included by “none” of the multiple implementations before.

I understand that you got excited about publishing a new great ROS driver written from scratch (you don’t need to re-write a full SDK on behalf of a company, it is not necessary for now). Open Robotics even shared your project on Twitter, LinkedIn. My suggestion to you would be not over-advertising it and not thinking it is ready / fully stable yet, before at least it has all the coverage that the original driver had. I’d even version it like 0.x.x myself. Your only mistake was over-confidence (understandable), which allowed them to judge you harshly. You also explained yourself but they don’t seem like they can take heed.

Many of us in the industry don’t think like academicians trying to prove a point in a paper. Most of my academician friends let their project work once, and forget about it, not worrying about reliability of their codes. Most of them still use & teach ROS 1 only (I even have an academician friend who still uses Fortran and not for a legacy hw). The real world, the competitive commercial / safe-grade industrial environment is very different comparing to the academia.

For the industrial side, let’s suppose you are developing an AGV/AMR: As long as it has safe-grade lidars for obstacle detection, speed management, and safety PLCs etc., at most of the industrial sites, there is no regulation against using a Rplidar as a navigation sensor with your driver. Slamtec says they have CE, FCC, IEC, ROHS, FDA, KC. and REACH certificates for their products on their website. It would be good for cost-efficiency in this competitive environment.

2 Likes
18

I understand this decision now that the driver is already announced and used. For your next projects, I suggest making your changes on top of existing driver’s git history. It greatly helps with transparency of your work.

PS: the off topic discussion has already moved to a new thread and I don’t want to spin it here. So just one important thing I’d like you to know: welcome to the community of ROS package maintainers! It’s great you’re putting the effort in it.

3 Likes
19

This is my second post in this topic, so I’ll try to clarify what I meant by my first post over two weeks ago.

I made the same comment here and on Reddit where I commented: “This is one of the worst AI slop posts that I’ve seen upvoted here.” And then I gave list of reasons why I believe “way and form is misleading at best and false at worst.”

The OP actually responded with:

“ Wow, honestly, thank you. This is exactly the “no-filter” feedback I was hoping for.
[…] “I’m glad someone looked at the code deeply enough to criticize the coupling. It means you care about quality. I’ll take your comment as motivation to push the networking support and std::optional implementation up the priority list. ”

I see that @Orhan made lot of comments here, and made second topic titled “Guidelines Must be Updated” where he accuses me and others of “Name-calling”, “Ad hominem attacks” and other.

Now, in this topic and the “Guidelines Must be Updated” @Orhan uses the same “Name-calling” , “Ad hominem attacks” that he accused others of:

  • “If the hobbyist youtuber Martin didn’t write that hateful comment first…”,
  • “Two Martins saying bad things, one after the other, liking each others’ posts, and a mod, coming and supporting this behaviour.”
  • “Two big guys bullying a kid and an OSRA official coming and supporting this behaviour because one of the bullies does some chores for them for free.”

As the last resort @Orhan focuses on term “AI slop” which he said I used three times in my first post: “AI slop post”,”slop blog”, “slop blog”.
You can read the post and lengthy blog and decide for yourself if it qualifies as AI Slop, which is pretty new term in itself.

I gave several reasons why the OP’s claims missed reality. What probably prompted me for admittedly harsh response was OP’s language used in this repo: “Table of Shame” and “heavily refactored, industrial-grade, rewrote it from scratch” for which I gave reasons in the first post.

Is the blog AI Slop? Anyone can read it and decide for themselves.

I see that @Orhan made some commits to this repo - after my first post - so maybe he felt the need this defense?

I don’t really have problems with LLM generated repos and PRs if they are original and useful.

Using “Table of Shame” to denigrate original repo, using bombastic claims to promote fork, writing lengthy blogs…

I wish OP and @Orhan best of luck with maintaining this fork, and I hope some of the claimed improvements can be merged into Slamtec’s original repo.