Robotics and ROS 2 Essentials

Sure. A ROS system, being a collection of independent nodes coupled with a publish/subscribe messaging system, allows you to mix and match nodes for whatever. So as a researcher, it is great. It gives you a "good enough" robot for the 98% that is necessary infrastructure for the 2% where you want to experiment/innovate. In an commercial setting, yeah, you run into scaling issues all over the place. Also, the code quality of different stock nodes is highly variable.

So ROS can get you past your A-round -- but count on addressing scalability and stability issues as go. Which is why "write out ROS" is on everybody's to-do list.

In any case, learning ROS is well worth it. As a hiring manager, I know I can easily teach you our system if you know ROS already.

I suffer it so much every single time I have to interact with it that sometimes I really really want to do something else, but I can't. Unfortunately is not my call, is part of my job. I have already made my opinion about ROS in a previous thread, but another user synthesized it very clearly: it's a trainwreck. Now we can be more precise: it's an academia trainwreck tool.

Tangentially relevant: the TryHackMe Advent of Cyber side quest this year[0] featured a pair of ROS nodes that we had to attack.

I had never encountered ROS before but, having scoured the documentation to figure out how to write a malicious node[1] and exfil data via `rostopic`, it sure felt great not to have to use ROS professionally, and to know I was probably never going to encounter it again.

[0] https://tryhackme.com/r/room/adventofcyber24sidequest

[1] https://0x85.org/sidequest2024-2.html

> It does little or nothing really well, but it does everything kind of okay.

Yes. ROS is basically mediocre interprocess middleware with a standard interface used by much academic software. So you can hack stuff together without too much trouble. It won't be efficient or reliable, but it's useful.

Think of it as the PHP level of robotics.

Can you explain what ROS does/is to the uninitiated? Why is everyone still using it if its such a trainwreck?

ROSCon Macao, 2019. As a time hack (our food robotics R&D facility, the "Noodleplex", was right across the border) I dragged all the academics down to the best bar (little resistance offered) instead of attending. While an interesting set, I was gobsmacked how little industrial nous attendees had and came to form the opinion that ROS use goes hand in hand with a "ROS can do CV ... everything is a nail" mentality. CV is a niche tool. Deployed, commercially relevant engineering generally uses something else unless the explicit system goal is visual input, because something else is always faster, cheaper, more reliable and has a supply chain stability half life greater than six months.

Which would you choose to do real-time robotics with C++ on Linux/PREEMPT_RT with CUDA support?

I have worked in two failed and failing startups that invested heavily in ROS. I could fill several volumes with "ROS Gotchas". Everything in the ROS stack is either a useless curio or an on-fire clown car.

Using ROS is a great way to turn your project and business into a cautionary tale.

Ros2's colcon will build the packages in your workspace individually, in topological order of the dependency DAG. This is a completely insane way to structure a c++ build because it destroys the innate parallelism of the compilation process.

The build system for ros1, catkin, didn't have this problem because it turned all your packages into a single cmake build. Just one of the many ways that ros2 was a regression from ros1.

Sounds like your build system is the problem, not ROS.

Been 10 years in and around the robotics industry and I'd recommend exactly the opposite. I've assisted companies refuse to work with anything touching ROS. Most successful things I've seen in production that are with ROS use a large non-ROS core with a thin ROS layer on top for compatibility. Companies that do use ROS have needed several times the resources of those that don't, to achieve the same thing.

Usually people get stuck with ROS in commercial environments either because they inherited it from an academic project (company is a spinoff), or they used ROS for a demo and afterwards never planned with long enough roadmaps to make the cost benefit analysis obvious enough.

I'm really intrigued by robotics as future career. How would you rate it for the next 10-15 years? I'm seriously thinking of investing in a masters degree focused on robotics (CMU). I'm close to 50 and already have a cs PhD. Just intrigued by it and feel it might have a longer career (when it takes off).

Highly recommend to avoid any companies that would touch ros with a 10ft pole. It's an unmitigated pile of endless shit, and any projects that don't recognize this are also.

ROS is like the One Ring. Binds everything in the darkness but corrupts you into his dark slave slowly. It must be thrown away into the hot lava.

what?

I love ROS. There are setup files for stuff inside ROS (pathfinding etc) that I haven't enjoyed, and I've definitely struggled with things like keeping it all standardised with like dockerfiles, but the ROS itself? the concurrency is amazing. I constantly wish I had it on non-robotics projects...

as others have mentioned, it has scaling issues. But for getting things done on a base level, its super powerful. The fault-tolerance it allows has benefited our robots a lot - it's often possible even with severely degraded systems to manually guide one around.

I do agree with what others have said about how the best usages are often to not go too deep into the ecosystem and instead use its messaging and concurrency protocol in limited ways, and have a lot of your internal logic siloed, to avoid hardcore dependency. After all, the idea of this kind of system is to allow new nodes to listen to sensor data (coming in) and/or planning goals (going out) to be able to make their decisions. Not passing some kind of intermediate calculation to some other subsystem

Where I was, 1 was standard, 2 experimental and nothing worked really. Slowly a half assed, bug ridden internal implementation of ROS 2 was started… a sh*tshow to be honest. The discontinuity between R1 and R2 was for me just unacceptable, unprofessional and just awful.

If I could decide (and in the area where I am, we did) I would ditch the whole thing. After all, if you squint, ROS is a collection of things:

- a launcher (which is a very bad scripting language embedded in horrible XML). Can be very easy be substituted by some python or shell scripts. - a description language of messages, that can be read by C, Python and Lisp; can be substituted by raw sockets or google protocol buffers or whatever. - a parameter/configuration distribution system, which can be implemented based on libconfig (https://github.com/hyperrealm/libconfig)

All that options are pretty much standard, stable and well supported, with bindings for any mainstream language.

I would run away from ROS2 to avoid another disaster when ROS3 comes.

I run a robotics dev tools company and we work closely with companies of all sizes across the robotics industry, so have a unique perspective on this.

I would say about half of the industry (read: for-profit robotics startups from early stages through to 10,000s of robots in production) uses ROS, and of those probably 2/3 are on ROS 2 at this point, and the rest are in some stage of migration. ROS 2 solved a lot of problems that didn't need solving, but like it or not ROS 1 is abandonware at this point so almost no one is planning to stick with ROS 1 longer than they have to.

Most companies aren't maintaining their own fork of ROS (other than to submit patches upstream), but a small number of companies on ROS 1 forked it and diverged so significantly that there is no point trying to rebase on ROS 2 - of these GM Cruise was the most notable, although the future of their stack is unknown now that GM canceled the robotaxi project.

The other half of the industry uses some sort of in-house stack built from parts (compare batteries-included frameworks like rails/django to building a backend using libraries like expressjs and sequelize). There is usually some form of pub/sub messaging architecture, because pub/sub is a natural fit for robotics and makes it easier to log and replay/resimulate. Some common things I see are zeromq, vanilla DDS (no ROS), zenoh, or write their own pub/sub (sometimes using shared memory). The messages themselves are often protobuf, flatbuffer, cbor, json, or sometimes just raw c structs.

Building your own stack isn't hard, but its much easier if you have used ROS before and know which concepts you want to reuse, rather than reinventing everything from first principles.

Some newer robotics frameworks are also starting to spring up which is great to see, for example https://github.com/copper-project/copper-rs and https://github.com/dora-rs/dora

There are also frameworks more specifically targeted towards robot learning, for example https://github.com/huggingface/lerobot

If people are just starting out in robotics, or just starting a robotics company, I still recommend ROS despite its warts, it is worth learning because it has had such a big influence on the current ecosystem. There is no "right answer" though, many companies have been successful with each approach.

What's that old robotics industry saying?

"You either die trying to scale ROS to production, or you live long enough to repeatedly reinvent it?" - Johnny 5

We use ros1 today. We have a very slow moving effort to migrate things to ros2 that I'm not really involved with.

A previous job used ros2. IMO, it's worse in most ways compared to ros1. The launch system of ros2 alone is enough reason not to use it.

You treat it like the metaphorical toxic waste it is: avoid it at all costs. You don't need ROS to get a dependency manager, a build system, a middleware, and/or a process manager.

I'd imagine it runs the gamut. ROS for some older places; those starting fresh are probably doing ROS 2.

No, you were not banned, your permission to post publicly was restricted because for the past three years you've been insulting, spreading lies and refusing to cooperate with other members of the community who actually want to change things and improve ROS. You're the one who is taking this personally because you claim Open Robotics is going after you. You've broken the code of conduct numerous times. The fact that you're incapable of any introspection and realizing that other people in that same thread are criticizing ROS in a civilized way and who are also proposing alternatives to ROS' build system, while you're just adding noise and whining about being personally targeted, makes Ryan's decision to restrict your permission to post publicly even more reasonable.

Depends on what you want to learn. The SLAM Frontend (computing motion information from sensors) offers a lot of variety through the chosen combination of sensors (wheel odometer, IMU, mono/stereo/multi camera, lidar, radar, sonar, to name a few).

At least for vision, deep learning should be very useful. For the others I have no experience how much machine learning is relevant. Geometry and physics based methods should work well here, but there is probably much room to tack on some ML.

The SLAM backend (optimization) is mostly old-school methods like nonlinear least squares optimization or particle filters. Not sure if that counts as ML today.

I'd go for g2o or Ceres for mapping (unless you expect to have no loop closures), as there's really no need to reinvent that. It's definitely useful to learn about the backend, but usually the combination of sensors and their properties will demand more algorithmic tailoring than the backend, which gets more abstract input (i e. motions & uncertainties) and can be used more black-boxy.