great history. one of the hidden gems inside: "the wildly successful ROS operating system. ROS is used to this day by enthusiastic researchers and frustrated companies who can’t figure out how to migrate off of it"
Of the one or two successes I have experienced in my career, preventing the adoption of ROS was one of the most satisfying. Watching another group adopt it, and then fail spectacularly was also reasonably gratifying.
ROS usage is a great quick way to evaluate the doofusness levels of an org. It's such a dumpster fire on every level, no reasonable human should be going within a mile of that thing.
I keep hearing this as some sort of "common knowledge" but no one can really lay out why. I've shipped stuff with ROS (albeit with some custom modules that needed customization).
But genuine question, has some who has actually shipped with ROS laid out what they would like it to do better?
Like anything, I think ROS can be used well. The people who use it well would probably do better with other tools, though. The people who prefer ROS seem to be young engineers, likely recent grads (ROS is endemic in grad school) who enjoy fast prototyping, which of course is very cool and fun, but also anathema to getting real work done past a certain point. If for no other reason than it is a configuration and debugging nightmare.
This is just my observation and should be taken lightly.
I've tried a few times to get into ROS for personal projects. I guess I understand the gist of it, but I still don't understand it.
Suppose I've got a motor, a motor driver, and an Arduino. How does ROS work with that? There's all this message passing and distinct blocks of stuff, but how do I get my motor to turn?
I'm sure there are tutorials out there... I get tired trying to approach their docs. I typically understand things from the ground up or from the top down. Their docs seem to start in the middle and work up/down at the same time.
[edit]
What are my alternatives in this space? What is better than ROS?
> Suppose I've got a motor, a motor driver, and an Arduino. How does ROS work with that?
It does not, ROS is for much bigger systems, usually Linux-based. Some things it can give you:
- IPC for multiple independent processes. So if your navigation process crashes, your drivers and controller still operate. Can save some time if your stack is slow to start up.
- Visualizer - not the best out there, but kinda-working. And because of previous item, you can keep it off (to save CPU) and only start if needed.
- Device drivers for some devices. Those would be "research grade" - any problems would be ignored and may result in invalid data, or they can crash, or be very inefficient... But good enough to get started.
- Logging/replay - log data to file, replay later. Again, research grade - there is no schema evolution (at least in ROS 1), so the moment you add new field, throw away your old logs. You can also use it to make whole-system tests, but because there is no explicit sync, those tests would be janky and flaky.
- some pre-made modules, like localization
it's a lot of small pieces, good enough to start or for prototype, but not for the more "production" robots.
As far as alternatives... All orgs I have seen do their own. Some of them start with ROS and eventually replace every part, others start entirly from scratch.
The setup you describe, "how do I get my motor to turn", is lower level than ROS. Typically if I had a robot with a microcontroller to control a motor, I'd write some bespoke code (or find libraries, such as Adafruit's for example, probably) for my particular hardware. Most recently, I've just asked ChatGPT for such code (having done it myself the harder ways in years past, so admittedly I know reasonably well what to ask...).
Once you achieve code that moves the motor at various speeds or directions, you might e.g. connect to the Arduino from a computer (e.g. raspberry pi), write a python "ROS Node" script that listens to a ROS topic and sends serial commands from the Pi to the Arduino.
Then, if you attach a laser range-finder or 2D lidar to the Pi, and look for a corresponding ROS node for that laser hardware (on github via google), you would run that additional ROS Node...
And finally you might write the "main" script as a third ROS Node that:
- Interprets the laser data it gets from the laser node's published ROS topic
- Has some logic for the robot that interprets that data and chooses to set speed/direction of the motor.
This is all very ad hoc description but hopefully somewhat helpful... You also asked "what is ROS", to which my own typical answer is: A framework for Nodes to communicate with each other, that happens to have a lot of open source nodes available for common hardware.
(I write this with ROS1 in mind, having hardly touched ROS2)
ROS is a collection of mostly-independent components, each of which is a not-as-good implementation of existing tooling. The implementers and the users mostly haven't grasped how to use the existing tooling, and the whole community is full of the blind leading the blind. Alternatives for what? The build system? The IPC?
> Alternatives for what? The build system? The IPC?
Honestly, I don't know. I don't even know what ROS is.
I could spec a multiplatform (computing and embedded with sensors and controllers) system, and come up with something like messaging on a CAN bus between different bits of the system and compilation targets for each piece of the system... Is that what ROS is?
it's a collection of tools bound together by a common build system, set of libraries, and a messaging system with a bunch of tools for introspecting and debugging it. It is, in principle, most of the kind of stuff you want for developing a robotic system, it's just each part is not very good, and it strongly encourages a distributed architecture that more or less makes every problem harder, especially ones which are latency sensitive, like most robotics.
Unfortunately there's no unified alternative: your alternative is to basically just put together a similar system from third-party libraries. It's a bit of a pain but not fundamentally that difficult, and you can salvage what's useful from ROS with less faff than dealing with it.
Here is the sad news: That is what ROS should be but isn't.
I'm constantly wondering why the heck I would need a framework designed for distributed IPC, if I can't run ROS on my motor controllers and have ROS manage the CAN bus messaging? You'd think that I2C, SPI, CAN, LIN, etc would be the standard protocols between nodes, but nope, it's some TCP or ethernet based DDS, which is both swappable, but yet that swapping buys you nothing.
Modeling every micro controller and even the peripherals the micro controllers are connected to as nodes in a distributed system sounds like an amazingly useful concept that would be worth years of investment, but the ROS guys seem to stay very clear of anything that could be of use to someone.
I started considering this for my own project, but it leads to tying together transport and serialization in ways that require much harder thinking about.
ROS is the equivalent of protobuf + gRPC + Go + bazel for robotics but with some XML and bespoke C++ stuff and more academia who'll stop maintaining their project once they get their PhD and without Google or any other big funding source since Willow Garage went away.
