Hacker News Reader

Comment by dima55 | Hacker News Reader

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?

View on HN

> 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?

"What is ROS" is really the right question. Maybe this helps:

https://goosetaco.notion.site/Beware-of-negative-polarity-st... . It links to https://answers.ros.org/question/12230/what-is-ros-exactly-m...

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.

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.

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.

Reply on news.ycombinator.com