6 ms·

This article reads as a rant about ROS (robot operating system) without mentioning ROS once. Which in their quest to make robotics simple; made json a programmi

This article reads as a rant about ROS (robot operating system) without mentioning ROS once. Which in their quest to make robotics simple; made json a programming language and made a massive ecosystem of abstracted complexity that breaks in undebuggable ways.

joe_the_user 2y ago
Yeah, the article seems like it's several different claims and arguments. Yes, robotic is hard with no general solution visible and with the solutions readily a available to companies turning out to be from people who've spent a decade "squinting" at the problem, know the rules of thumb for a bunch things that work and don't work and still build things that are less than ideal. From this, yes, there are many ways that creating a simplified API in a conventional programming language seems useless. But as an argument against any "turn a hundred newbies loose", it seems not right. It seems plausible newbies to robotics could find paradigms that don't currently exist. I mean, robotics seems to be in the state that pre-deep-learning computer vision generally was in. Nothing worked "out of the box" and you needed experts to make the random smattering of approach that did exist work. Now we have an out-of-the-box working approach and I'm pretty sure it didn't come from existing experts.
agarwa90 2y ago
Like previously said, ROS is not an OS, its a framework for making hardware easily programmable with simple APIs, which happens to be very useful to get started with robots. Sure there is a learning curve like many other frameworks!
diydsp 2y ago
my bg: I have done a few robotics projects: a warehouse robot and a surgical arm. About ROS: that's fair, but to be fair, it was an ambitious first attempt that began hmm decades ago? and has some great parts (the 3d simulator, the robot construction, the python interface) and some less great parts (bags). It's a great place to make the next generation from. Unfortunately, the scope of robot design pain is even larger than TFA! the definition of "robot" is so broad it includes factory robots with hardly any sensor requirements and intelligence, as well as devices with intense vision input, or even large network requirements, micro devices, stationary devices, mobile truck-like things, robotic systems composed of numerous robots, humanoids, etc.
- jvanderbot 2y ago
  Similar bg + space and some DoD. ROS established concepts that pervade robotics. There is no non-ros-like robotics framework. Every _serious_ ROS alternative I've worked with has a similar "Markup as programming" problem because everyone has embraced the "Extensible node" paradigm (aka component based architecture). Configuring a system becomes half the battle. Even Space and DoD have this. I am not convinced ROS saw this coming, or knew about it prior, when they designed their "Operating system". real time embedded systems have a longish history of using message passing between tasks, but still, not convinced. My top three wishes for ROS are: * Get better interop with other messaging systems. I can build an entire business on HTTP POST/GET, but I need your very-limited rosmsg definition for this robot, this message archive, this wire definition? (not that I want HTTP but you get it). * Provide a roadmap for hardening. Ros-mil, ros-space, ros-2, etc all seem like steps in different paths toward the same goal. Tell people to stop trying to use a rosgraph across multiple platforms. Kill ROCOS. Teach the industry to use better tools! We have better distributed systems now. * Never change. Ironically, the fact that ros is so mushy and accessible means that really-high quality robotics research often is ROS-first. (eth zurich for example!). I'm not sure making it commercializable, hard, and interoperable will accomplish that.
  - sashank_1509 2y ago
    Throughout grad school I used ROS and whether the robot demo worked on the day it was supposed to was essentially a coin flip. In industry I use protobuf, Hydra for config management, few async processes and god does it make a sea of difference. It seems like other companies are catching up, I see more and more companies avoiding ROS these days!
    - singlepaynews 2y ago
      Would you have time to review my resume and help set an achievable get-in-the-field project goal?
      - jvanderbot 2y ago
daralthus 2y ago
what's the current recommendation instead of ROS?
- ubj 2y ago
  There's a few alternatives. Zenoh [1] is an up-and-coming distributed middleware. ROS2 is actually adding it as an alternative to DDS [2]. LCM [3] is another middleware that has been around for a while. [1]: https://zenoh.io/ https://zenoh.io/ [2]: https://newsroom.eclipse.org/eclipse-newsletter/2023/october/eclipse-zenoh-selected-alternate-ros-2-middleware https://newsroom.eclipse.org/eclipse-newsletter/2023/october... [3]: https://lcm-proj.github.io/lcm/ https://lcm-proj.github.io/lcm/
  - ModernMech 2y ago
    Those aren't really ROS alternatives though, as they seem to offer just the message passing layer, which is one of the best features of ROS, but it's not really enough in isolation from the other good features.
    - moffkalast 2y ago
      People forget that ROS isn't really about the IPC or the build system or the networking. Ok it is about those things, but fundamentally it's about standardization. Grab any lidar driver and it'll output a LaserScan. Every wheeled robot will send out Odometry, anything from a submarine to a flying drone to an agv will respond to a Twist message, every robot will have a central coordinate frame called "base_link", etc. The cross ecosystem interoperability is frankly insane and the main perk of it all. It makes building things easy when you don't have to deal with writing adapters every single damn time. This is why ROS 2 is currently such a step backwards because it fragments the ecosystem in DDS compatibility, making sure that no two packages will necessarily be able to run concurrently.
- margalabargala 2y ago
  Viam seems promising, especially for cloud connected stuff.
liendolucas 2y ago
You couldn't have described it better. ROS is painful and makes you actually hate robotics. My conclusion was that it was written only to be used by their own developers and researchers. Documentation on most useful plugins (SLAM and AMCL) is really bad to near non-existant. I felt like all this was for some elite and you either have a very strong foundation and know a lot to use it or prepare to suffer and stay long hours trying things out until they work. The ecosystem and tooling are the worst I have ever experienced: colcon, sourcing scripts, launch scripts and on top of that you have to use specific Ubuntu versions. Their flagship language is C++, which is a language I hugely dislike. Yes you have Python but is nothing more than a thin wrapper to the underlying API, is not a clean and native Python API so you end up writing a lot of bureocratic and gluing code.
- moffkalast 2y ago
  Ah your mistake was going for ROS 2 which is by any objective metric a complete trainwreck compared to ROS 1. Am a maintainer for a package in both, AMA. The move_base stack in ROS 1 was pretty bad overall, but if you made your own navigation it ran really well and was pretty bulletproof as a middleware for the most part (changing network conditions ahem ahem). Nav2 in ROS 2 is better, but it's really hard to tell because the DDS is so unreliable and rclpy is so slow that it's usually impossible to tell why it's only working half the time for no reason. Defaults are bad and pitfalls are everywhere. Incidentally this makes the entire thing unreliable even if you implement your own stuff so.. yeah. We'll see if Zenoh fixes any of this when it's finally out and common sense prevails over DDS cargo culting. Personally I'm not entirely convinced we won't see a community fork of Noetic gain some popularity after it's EoL. There is some effort to add Rust support, but it's just a community effort because OpenRobotics is completely understaffed. Google bought them and then they sort forgot they exist. There's only like 4 core devs in total. That's mainly why they're treating python as a second class citizen.
  - ModernMech 2y ago
    > your mistake was going for ROS 2 which is by any objective metric a complete trainwreck compared to ROS 1 Sometimes you don't have a choice. I prefer to stick with ROS 1 but the org I was working with insisted on running ROS2 for everything. The only thing worse than running ROS2 is running ROS2 installed next to ROS1 and trying to work with both.
Animats 2y ago
ROS isn't an "operating system". It's a piece of middleware. The purpose of ROS was to set up an intercommunication standard for academic robotics projects, so various components (vision, motion planning, etc.) from different sources could be connected. It's for prototyping, not production. Attempts to make robots easier to program in industry involve "teach pendants" and schemes where you push the robot through the desired motions to record a path. This works in well-organized work cells. Outside that, not so much. Amazon, despite major efforts, still hasn't deployed robotic bin picking much. Their AGVs, though, work great. Amazon is building a thousand units a day of those little Kiva moving platform robots that carry stuff around their warehouses. There was Rod Brooks' "Rethink Robotics", with their semi-intelligent "cobots". That was a flop. But it did lead others to make better small robot arms.
- ModernMech 2y ago
  > There was Rod Brooks' "Rethink Robotics", with their semi-intelligent "cobots". That was a flop. After that, Rod Brooks founded Robust AI, which is the employer of the author of TFA.
- Symmetry 2y ago
  We actually did use ROS in production at a previous job a decade ago.
kscottz 2y ago
I don't think that is the intent of the article at all. I think the article is making a comment on building a single framework that can enable anyone to solve an arbitrary robotics problem. From the second paragraph, "The idea goes something like this: Programming robots is hard. And there are some people with really arcane skills and PhDs who are really expensive and seem to be required for some reason. Wouldn’t it be nice if we could do robotics without them?" There are host of companies, both extant and deceased, who attempted to do just that. I don't think any ROS developer has ever made the claim that ROS makes building a robot "easy", "easier" yes, but "easy", certainly not. ROS is simply a collection of tools that people have built over the years to get their work done faster by not re-inventing the wheel. Many ROS packages have decades of real-world deployment behind them. Some ROS packages, like Nav2 and MoveIt, are incredibly helpful, other packages are difficult to use and poorly documented, just like in any open source ecosystem. > Which in their quest to make robotics simple; made json a programming language JSON, in ROS? I don't think that's how it works. > massive ecosystem of abstracted complexity that breaks in undebuggable ways If you have a solution for this I think you solved the problem of software engineering in general.
- joe_the_user 2y ago
  I think the article is making a comment on building a single framework that can enable anyone to solve an arbitrary robotics problem. The thing about that statement is it's mixing two different meanings of "framework". One thing framework means is a conventional library or API in a conventional programming language. The other thing framework means is a broad, conceptual that can be reused - in this case, in many robotics problems. Using the first meaning of framework, sure, maybe it's not useful. But using the second meaning of framework, I think it's very useful to keep looking for such a thing and getting more people involved might help.

joe_the_user 2y ago

Yeah, the article seems like it's several different claims and arguments. Yes, robotic is hard with no general solution visible and with the solutions readily a available to companies turning out to be from people who've spent a decade "squinting" at the problem, know the rules of thumb for a bunch things that work and don't work and still build things that are less than ideal. From this, yes, there are many ways that creating a simplified API in a conventional programming language seems useless. But as an argument against any "turn a hundred newbies loose", it seems not right. It seems plausible newbies to robotics could find paradigms that don't currently exist. I mean, robotics seems to be in the state that pre-deep-learning computer vision generally was in. Nothing worked "out of the box" and you needed experts to make the random smattering of approach that did exist work. Now we have an out-of-the-box working approach and I'm pretty sure it didn't come from existing experts.

agarwa90 2y ago

Like previously said, ROS is not an OS, its a framework for making hardware easily programmable with simple APIs, which happens to be very useful to get started with robots. Sure there is a learning curve like many other frameworks!

diydsp 2y ago

my bg: I have done a few robotics projects: a warehouse robot and a surgical arm. About ROS: that's fair, but to be fair, it was an ambitious first attempt that began hmm decades ago? and has some great parts (the 3d simulator, the robot construction, the python interface) and some less great parts (bags). It's a great place to make the next generation from. Unfortunately, the scope of robot design pain is even larger than TFA! the definition of "robot" is so broad it includes factory robots with hardly any sensor requirements and intelligence, as well as devices with intense vision input, or even large network requirements, micro devices, stationary devices, mobile truck-like things, robotic systems composed of numerous robots, humanoids, etc.

jvanderbot 2y ago
Similar bg + space and some DoD. ROS established concepts that pervade robotics. There is no non-ros-like robotics framework. Every _serious_ ROS alternative I've worked with has a similar "Markup as programming" problem because everyone has embraced the "Extensible node" paradigm (aka component based architecture). Configuring a system becomes half the battle. Even Space and DoD have this. I am not convinced ROS saw this coming, or knew about it prior, when they designed their "Operating system". real time embedded systems have a longish history of using message passing between tasks, but still, not convinced. My top three wishes for ROS are: * Get better interop with other messaging systems. I can build an entire business on HTTP POST/GET, but I need your very-limited rosmsg definition for this robot, this message archive, this wire definition? (not that I want HTTP but you get it). * Provide a roadmap for hardening. Ros-mil, ros-space, ros-2, etc all seem like steps in different paths toward the same goal. Tell people to stop trying to use a rosgraph across multiple platforms. Kill ROCOS. Teach the industry to use better tools! We have better distributed systems now. * Never change. Ironically, the fact that ros is so mushy and accessible means that really-high quality robotics research often is ROS-first. (eth zurich for example!). I'm not sure making it commercializable, hard, and interoperable will accomplish that.
- sashank_1509 2y ago
  Throughout grad school I used ROS and whether the robot demo worked on the day it was supposed to was essentially a coin flip. In industry I use protobuf, Hydra for config management, few async processes and god does it make a sea of difference. It seems like other companies are catching up, I see more and more companies avoiding ROS these days!
  - singlepaynews 2y ago
    Would you have time to review my resume and help set an achievable get-in-the-field project goal?
    - jvanderbot 2y ago

daralthus 2y ago

what's the current recommendation instead of ROS?

ubj 2y ago
There's a few alternatives. Zenoh [1] is an up-and-coming distributed middleware. ROS2 is actually adding it as an alternative to DDS [2]. LCM [3] is another middleware that has been around for a while. [1]: https://zenoh.io/ https://zenoh.io/ [2]: https://newsroom.eclipse.org/eclipse-newsletter/2023/october/eclipse-zenoh-selected-alternate-ros-2-middleware https://newsroom.eclipse.org/eclipse-newsletter/2023/october... [3]: https://lcm-proj.github.io/lcm/ https://lcm-proj.github.io/lcm/
- ModernMech 2y ago
  Those aren't really ROS alternatives though, as they seem to offer just the message passing layer, which is one of the best features of ROS, but it's not really enough in isolation from the other good features.
  - moffkalast 2y ago
    People forget that ROS isn't really about the IPC or the build system or the networking. Ok it is about those things, but fundamentally it's about standardization. Grab any lidar driver and it'll output a LaserScan. Every wheeled robot will send out Odometry, anything from a submarine to a flying drone to an agv will respond to a Twist message, every robot will have a central coordinate frame called "base_link", etc. The cross ecosystem interoperability is frankly insane and the main perk of it all. It makes building things easy when you don't have to deal with writing adapters every single damn time. This is why ROS 2 is currently such a step backwards because it fragments the ecosystem in DDS compatibility, making sure that no two packages will necessarily be able to run concurrently.
margalabargala 2y ago
Viam seems promising, especially for cloud connected stuff.

liendolucas 2y ago

You couldn't have described it better. ROS is painful and makes you actually hate robotics. My conclusion was that it was written only to be used by their own developers and researchers. Documentation on most useful plugins (SLAM and AMCL) is really bad to near non-existant. I felt like all this was for some elite and you either have a very strong foundation and know a lot to use it or prepare to suffer and stay long hours trying things out until they work. The ecosystem and tooling are the worst I have ever experienced: colcon, sourcing scripts, launch scripts and on top of that you have to use specific Ubuntu versions. Their flagship language is C++, which is a language I hugely dislike. Yes you have Python but is nothing more than a thin wrapper to the underlying API, is not a clean and native Python API so you end up writing a lot of bureocratic and gluing code.

moffkalast 2y ago
Ah your mistake was going for ROS 2 which is by any objective metric a complete trainwreck compared to ROS 1. Am a maintainer for a package in both, AMA. The move_base stack in ROS 1 was pretty bad overall, but if you made your own navigation it ran really well and was pretty bulletproof as a middleware for the most part (changing network conditions ahem ahem). Nav2 in ROS 2 is better, but it's really hard to tell because the DDS is so unreliable and rclpy is so slow that it's usually impossible to tell why it's only working half the time for no reason. Defaults are bad and pitfalls are everywhere. Incidentally this makes the entire thing unreliable even if you implement your own stuff so.. yeah. We'll see if Zenoh fixes any of this when it's finally out and common sense prevails over DDS cargo culting. Personally I'm not entirely convinced we won't see a community fork of Noetic gain some popularity after it's EoL. There is some effort to add Rust support, but it's just a community effort because OpenRobotics is completely understaffed. Google bought them and then they sort forgot they exist. There's only like 4 core devs in total. That's mainly why they're treating python as a second class citizen.
- ModernMech 2y ago
  > your mistake was going for ROS 2 which is by any objective metric a complete trainwreck compared to ROS 1 Sometimes you don't have a choice. I prefer to stick with ROS 1 but the org I was working with insisted on running ROS2 for everything. The only thing worse than running ROS2 is running ROS2 installed next to ROS1 and trying to work with both.

Animats 2y ago

ROS isn't an "operating system". It's a piece of middleware. The purpose of ROS was to set up an intercommunication standard for academic robotics projects, so various components (vision, motion planning, etc.) from different sources could be connected. It's for prototyping, not production. Attempts to make robots easier to program in industry involve "teach pendants" and schemes where you push the robot through the desired motions to record a path. This works in well-organized work cells. Outside that, not so much. Amazon, despite major efforts, still hasn't deployed robotic bin picking much. Their AGVs, though, work great. Amazon is building a thousand units a day of those little Kiva moving platform robots that carry stuff around their warehouses. There was Rod Brooks' "Rethink Robotics", with their semi-intelligent "cobots". That was a flop. But it did lead others to make better small robot arms.

ModernMech 2y ago
> There was Rod Brooks' "Rethink Robotics", with their semi-intelligent "cobots". That was a flop. After that, Rod Brooks founded Robust AI, which is the employer of the author of TFA.
Symmetry 2y ago
We actually did use ROS in production at a previous job a decade ago.

kscottz 2y ago

I don't think that is the intent of the article at all. I think the article is making a comment on building a single framework that can enable anyone to solve an arbitrary robotics problem. From the second paragraph, "The idea goes something like this: Programming robots is hard. And there are some people with really arcane skills and PhDs who are really expensive and seem to be required for some reason. Wouldn’t it be nice if we could do robotics without them?" There are host of companies, both extant and deceased, who attempted to do just that. I don't think any ROS developer has ever made the claim that ROS makes building a robot "easy", "easier" yes, but "easy", certainly not. ROS is simply a collection of tools that people have built over the years to get their work done faster by not re-inventing the wheel. Many ROS packages have decades of real-world deployment behind them. Some ROS packages, like Nav2 and MoveIt, are incredibly helpful, other packages are difficult to use and poorly documented, just like in any open source ecosystem. > Which in their quest to make robotics simple; made json a programming language JSON, in ROS? I don't think that's how it works. > massive ecosystem of abstracted complexity that breaks in undebuggable ways If you have a solution for this I think you solved the problem of software engineering in general.

joe_the_user 2y ago
I think the article is making a comment on building a single framework that can enable anyone to solve an arbitrary robotics problem. The thing about that statement is it's mixing two different meanings of "framework". One thing framework means is a conventional library or API in a conventional programming language. The other thing framework means is a broad, conceptual that can be reused - in this case, in many robotics problems. Using the first meaning of framework, sure, maybe it's not useful. But using the second meaning of framework, I think it's very useful to keep looking for such a thing and getting more people involved might help.