ROS: The Robot Operating System | Hacker News Reader

ROS: The Robot Operating System

ros.org

19 pointspmoriarty13 comments

ROS is great! It's mostly an IPC framework, and very thinly wraps DDS. We use it extensively for prototyping and simulation at NASA JPL. We even have a closed-source version that improves many of the shortcomings for real-world deployment or NASA flight projects. I highly recommend ROS as a starting point to anyone looking to get into robotics development. https://www-robotics.jpl.nasa.gov/tasks/showTask.cfm?FuseAct...

Really? I find that ROS is hugely over-complicated.

This. I mean, production-grade robotics is complicated, but using it just for connecting some Python functions via Pub/Sub is probably overkill... I guess there are simpler options (Redis maybe?)

(Personally, while working on my master's thesis I tried ROS for some weeks before switching to V-REP Edu + NumPy + OpenCV. Not saying everybody should do that, but it worked for me)

If you don't need inter-process communications, you don't need ROS.

Caveat: ROS is for research into robotics systems and algorithms. You can pick up your fav language, write something up, and use a thin IPC library (pub / sub) to tie it into the ecosystem.

Otherwise, it quickly becomes impossible to share portable modules and code libraries (all written in different languages, mind you). The alternative: Sticking to their language and compiling in their library or dealing with their dependency chain ... is much worse.

> If you don't need inter-process communications, you don't need ROS.

All I'm saying is, there are cases when you do need IPC, but you can do it without ROS... Surely it brings major benefits wrt. code reuse, but it can also be quite intimidating for a newcomer. I guess the best way of mastering it would be working on an existing project and having some experienced user walk you through it.

It can be. But it has a medium-level initial complexity so that it can scale really well to very complex systems (see caveats above).

So there's a learning curve, sure. But when you want to jump on a new system, or prototype a small algorithm on a large system, ROS will save you a lot of trouble. Also it's everywhere. Any academic or industry roboticist will know and probably use ROS, at least for prototyping.

So, I worked with ROS over the summer at my internship. If I could ask, what did your closed-source version improve on?

In my experience, one of my worst experiences with ROS was maintaining environments and python versions as well as the build system.

A whole bunch of things! I won't bore you, but you can imagine the pain points a team must have solved to deploy it for real:

ROSCORE: a single point of failure. This immediately has a bunch of negative implications on prototyping small nodes and scaling to large systems.

No concept of vehicles, sensors, resources to interact with, and so on. You have to look up what topic to subscribe to, deal with their ad-hoc message types, etc just to connect to a process managing a part of a vehicle / robot.

No semi-persistent data storage is built in, meaning you need separate databases, intra-process shared memory, etc.

Zero multi-agent awareness. You'd have to solve a bunch of problems like adding / disconnecting robots from whomever is running roscore (we don't have one!).

Abysmal command and data routing, and no sub-structures that make it easy to verify commands, ensure the right nodes are in charge, display statuses, discover what nodes are running on a system and how to command them, and so on.

And convenience stuff, like ROS has no command editor for easily scripting a vehicle's actions, without need for programming (though you can program all you want).

And no legacy. We have access to some tried-and-true code-bases here to incorporate.

Nice! We're just starting a project using ROS, so I'm busy wrapping my head around it all. Have the motors turning and the 3D camera delivering data.

When you say it's a thin wrapper around DDS, are you using ROS 2 already?

Well, no. ROS 2 does a few things that our stack already does. ROS is a wonderful platform for open source / academic development and building community. We have a fairly tight requirement when doing gov / nasa work that doesn't always work with that model.

Only ROS 2 is implemented on top of DDS. Nobody uses it in practice, and the entire thing is super beta.

ROS 1 is a danger to public safety, and the very thought of it running things like self driving cars, robots that interact with humans, or exo-sceletons is making me sweat.

It is half assed, complex, and most importantly buggy. To name one example, instead of relying on some general binary serialisation protocol that everybody uses, ROS implements a custom messsage serialisation format with a custom message schema language, that generates code which involves a lot of raw buffer to struct casting. To verify compatibility between different talking ROS nodes they exchange a MD5 checksum of a normalized text version of the message schema both nodes have. The issue is that during the normalisation step they accidentally "forget" the arity of variables (scalar, array including it's length, list). This can cause two nodes to have slightly different message definitions, which ROS will happily cast into a C struct, just smashing whatever data is out of alignment into other fields that happen to be there.

They consider this a no-fix, since a change of the renormalisation step would mean that packages would have to be recompiled in order to be compatible. And they find that forcing their users to recompile their code is too much of a burden for them.

Also in practice TCP is used for everything, with no QoS whatsoever.

ROS 2 dependency on DDS is a whole other can of worms. While DDS seems to work somewhat well in practice, the fact that it's spec is a monstrous nightmare (hey at least they didn't use corba) and that vendors only show compatibility on a yearly "hey the demo kinda runs" event, doesn't make me conviced that this is not introducing more problems than it solves. Also even if DDS is a fine system, why entrust the same people that wrote ROS 1 with finding sane defaults for it's QoS, and why choose their horrid message serialisation format, and awkward catkin tooling? Just use DDS, the DDS message serialisation format, and whatever build system you feel like.

So heed my words, stay away from ROS don't touch it with a ten foot pole unless you absolutely have to.

Source: I wrote a clojure port of ROS that doesn't hook into their codegen chain and reimplements their entire system from the centralized master node to the code generation.

I agree with your assessment, but disagree with your recommendation. I sincerely doubt ROS will be used in its current state for legitimate autonomy. It can seem half-assed because it is fastly changing.

I think your DDS comments apply nicely to OpenDDS, and I sincerely hope that the spotlight of ROS2.0 will improve OpenDDS significantly.

ROS is a good platform to study and learn. It is not something you'll find in a car in a garage. But it is worth it, because there are similar-enough platforms used for actual, real-world applications that would impress even the most curmudgeonly programmer. Such as ...

https://www-robotics.jpl.nasa.gov/tasks/showTask.cfm?FuseAct...

ROS has been around for what 'feels like' at least 10 years now. I remember seeing it a long time ago with a robot that was doing something with a sock.

I don't have any opinion on it, just wanted to state that it isn't new, which may be good, stability FTW!!!

Reply on news.ycombinator.com