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.
After that, Rod Brooks founded Robust AI, which is the employer of the author of TFA.
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.
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.
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 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.
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.
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!
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.
What about, e.g., Drake? (https://drake.mit.edu)
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.
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.
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.
Sure there is a learning curve like many other frameworks!
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.
Point taken though.
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.
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
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".
I do agree with your first two paragraphs.
At least Vizanti will always stay open ;)
https://foxglove.dev/blog/foxglove-2-0-unifying-robotics-obs...
BMW research has the most promising fork I have seen yet
LCM [3] is another middleware that has been around for a while.
[1]: https://zenoh.io/
[2]: https://newsroom.eclipse.org/eclipse-newsletter/2023/october...
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.