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.
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.
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.
The thing I don't get about ROS is that at no time in its almost 20 year history has anyone, at any point, referred to ROS as having good docs or an easy to use interface. Despite this, it has been pushed on undergraduates and people who find it very confusing and hard to use.
It just seems to me no one seems willing to admit defeat that perhaps ROS is not working out for the purpose of making robotics more accessible.
Like, they spend so much effort on their varied Turtle mascots and all the themes for the many and frequent releases (that never make it easier to work with), I wish they put that kind of energy into the onboarding experience.
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.
> 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.
I mean it is a huge dilemma right now. Noetic is incredibly stable, it has lots of packages, language models all know it in detail, any problems are noted and workarounds known... and support will be cut in a bit over a year.
Kind of the exact opposite is the case for Jazzy really. I think it really hinges on the date you need to have working code on and how long you intend to maintain it I guess. For a company building up its software with a 2 year latency in deployment it probably makes more sense to develop slowly along with ROS 2 and hope for the best.
Also don't get me started on Gazebo Classic/11 vs Ignition lol, that's a similar can of worms right there.
It was infuriating joining a robotics company with a ROS based stack. A lot of the original engineers had started at the company in undergrad as interns, and I swear it was impossible to make anything better because they didn’t know what better looked like. They just understood ROS and were highly proficient with it, so any move away from ROS would slow down the engine of the company.
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.
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.
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!
I've hired a few roboticists and my advice is always the same - if you're a new grad, knowing ROS and having strong C++, ROS, and OpenCV experience will give you a leg up.
After that, the most common things new grads want to work on are path planning or computer vision. These are high-ish demand but usually go to grad students or senior folks. But you can be an excellent candidate by knowing about them and how to integrate and test them. Path planning has several open source libraries and implementations. Do a comparison on several maps. Pull game maps and try em out. Anything. For AI/CV, there's similarly many applications.
The key for non-PhDs is to know the existing stuff well. Even if you're a PhD, you'll spend less than 1% of your time doing anything interesting / researchy, and will mostly be using existing codebases for everything. Very few research-primary positions exist.
How is experience meant to be demonstrated? Do you do a home project and put it at the top of your resume?
Edit: I don't mean to be pedantic; I'm just ~6 years out of touch here. I did a SLAM-in-quadcopter and force-controlled-6dof-arm in undergrad, and those projects are being correctly ignored by hiring managers as "he's since forgotten this stuff" today.
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.
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.
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!
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.
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.
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.
ROS is one of those "frameworks" that's so awful and pervasive that for teams of more than 2 people handrolling your own networking is almost always going to be better than trying to make ROS work.
Any framework that has "Start for free" and "Contact sales" on the home page is gonna do really great at mass developer adoption. Can't wait for them to rugpull everyone and close source all of their code when the VCs want to get paid.
Indeed. In the robotics space, this just happened with foxglove studio. Six months ago, I considered advocating that we switch our bespoke visualizer to be a bunch of foxglove plugins instead. Today, it's clear that would have been a terrible move.
Quite right. Corporate open source is always one step away from straight up trapping people through sunk cost. Sometimes a change in management is all that needs to happen.
that's probably the most notorious example of a company abandoning open source and switching to a proprietary license, so that is a strong reason to believe that viam will rugpull if given the chance
I know this is just reopening a discussion that HN has had a million times, but what mongo (and elastic, and so on) swapped to is not IMO a rugpull to anyone except those who were reselling those specific open source projects. Anyone using those tools internally/as a backend weren't affected by that, whether they were a hobbyist or small business. The exception being people who only want true FOSS for ideological reasons.
The trouble with the SSPL is that it also nerd-snipes people who think the legal system works like code. Example of such a person: https://ssplisbad.com/
As far as I can tell reading the license, the key terms of the SSPL hinges on "such that a user could run an instance of the service using the Service Source Code you make available". If you make something available that is then able to be run, then you've fulfilled the license.
Looking at it again the page I linked above actually goes beyond overly-strict interpretation into actual bad-faith reading. When talking about what you have to publish, they cut off the sentence short so that they can interpret it mean things like the BIOS or IDE, but reading the actual license text it's clear that's not the case. "All programs that you use to make the Program or modified version" vs "all programs that you use to make the Program or modified version available"
As someone who only runs FOSS in my day-to-day, and not anything with SSPL, I'm really annoyed that that page nerd-sniped me into defending the SSPL.
the main trouble with the sspl is that it isn't an open-source license, which is a problem for people who only want true foss for practical reasons, not just ideological reasons. reselling is one of the rights that an open-source license protects, and historically speaking, everyone having that right has been absolutely critical to the development of things like linux, gcc, x-windows, ffmpeg, emacs, postgres, and wikipedia; without it, not only wouldn't we have objective-c support (contributed by next against their will) or linux distributions (like slackware, red hat, debian, and especially ubuntu), we also wouldn't have wikipedia quotes in google serps, or android
a secondary problem with it is that, as you point out, the sspl is so vague that you can never be sure that you're in compliance with it, and it's never been litigated, so there's no precedent
it sounds like you have a pretty weak grasp both of how the legal system works and of the history of free software licensing. actual bad-faith reading is literally the job description of a lawyer
Bad-faith readings are the job of a lawyer, but what I pointed out goes beyond a bad-faith reading. It's a literal lie, made by truncating a sentence. If you were to say "Nazis are the greatest evil the world has seen", and a lawyer in court quoted you as saying "Nazis are the greatest", that's not a lawyer's standard bad faith reading.
If you think the above would be legally permissible then I'm afraid you're incorrect regarding which of us has a "pretty weak grasp of how the legal system works".
