Live data from Hacker News

Robot Operating System – A flexible framework for writing robot software

ros.org

71–80 of 85 posts

Re: Robot Operating System – A flexible framework for writing robot software

#71
post #50

Earlier quoted context omitted.

What market are you looking at? Its all about risk... if you're targeting the medical domain for example, you have a multi-year project just to get thru the certifications. Conversely if you're just looking at creating a toy with limited movement, weight and power then the risk is significantly less. Get an engineering safety consultant to have a look.

Industrial cleaning, machine is slow, but has many liters clean and dirty water inside. Just prototyping it and thinking how to achieve reasonable price. 30-50k is too expensive, janitor is cheaper.

If you want a solution, don't develop your own. Industrial robots can be purchased on Ebay for <10k that have already had the certification and engineering done. Then you just need to do the easier job of engineering your specific task, versus an entire robot + your task.

Re: Robot Operating System – A flexible framework for writing robot software

#72

Please stop using names for version releases. Is "awesome igloo" newer than "super turtle" or "raring rino"? Just stop. Use boring versioning numbers. Your developers and users will thank you.

They're alphabetical, lol. Plus cool shirts.

Re: Robot Operating System – A flexible framework for writing robot software

#73

Earlier quoted context omitted.

CMake is pretty established. You don't have to use CMake and if you don't want to, you don't have to use it - you can just compile your code however you like and manually put all your package files where ROS expects them to be, or use symlinks or some other hack. Doesn't seem to be worth it just to avoid CMake.

The build system is effectively almost required, though, because the documentation telling you how to do anything in ROS assumes you're using Catkin. I wouldn't know how to arrange files for ROS to use without going through the build system.

It's not required if you know CMake and know what you're doing. There's even resources, if you search for them, e.g.:

https://github.com/gerkey/ros1_external_use

But if you're looking for good documentation and tutorials, then yes catkin is basically required, but I don't think that's unreasonable.

Re: Robot Operating System – A flexible framework for writing robot software

#74

Earlier quoted context omitted.

ROS started development almost 10 years ago. A lot of "high quality" solutions that seem like a good idea now may not have been around that long ago, or were still in nascent stage. Many of the changes in ROS2 are actually about incorporating some of these solutions -- the most obvious example being the switch to DDS for messaging. Regarding catkin, I actually think it's an OK solution with some nice features. It's m…

> ROS started development almost 10 years ago. A lot of "high quality" solutions that seem like a good idea now may not have been around that long ago, or were still in nascent stage. In my opinion this is no excuse. 10 years ago was 2008 and we had rock solid solutions to these problems - I don't think it was necessary to build custom solutions (and AFAIK catkin is already the successor of rosmake). But rereading my…

Can you detail some of the rock solid solutions in 2008 for the problems addressed? For example, building multiple C++ packages from source. Google's Bazel wasn't open sourced until 2015, so solutions were still appearing long after 2008.

Re: Robot Operating System – A flexible framework for writing robot software

#75

My experience with ROS has been suboptimal. It's a collection of incompatible, outdated and buggy tools that communicate with each other via a single-point of failure (roscore) using a pub/sub mechanism. Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment. I appreciate their effort and it is re…

ROS beginner here. I've been experimenting with ROS in my spare time for about a week, with the ultimate goal of building a trainable robot. So far, I've built a custom robot arm in gazebo, converted it to URDF, and hooked up gazebo to ROS. The next step is to start controlling joints.

A few years ago I tried to run a project based on ROS and gave up in the end due to compatibility problems (I was installing ros packages on top of an existing Ubuntu and it caused all kinds of problems). Now that I'm using their pre-built docker image and took the time to read the tutorials, I'm finding it more reliable and much nicer.

The tutorials are very clear and all the steps have "just worked" for me, although the individual packages don't always seem very well documented.

catkin doesn't seem like a heavyweight build system - more like an opinionated layout combined with some cmake macros and some scripts, built on top of cmake. I can see how this would be useful for myself as well as real roboticists to develop multiple packages in parallel without having to poke through complex and disparate build systems. A robotics student would want to dive into C++ or Python as fast as possible as opposed to figuring out the build system, and I think catkin serves this purpose.

Also, it's common for inexperienced linux/mac users to get confused between multiple installations - when they have to compile things from source, i.e. opencv. I wonder if the ros command line tools are partly designed to help students overcome that obstacle, i.e. the pattern roscommand packagename rosoptions.

I'd also argue against the added complexity of avoiding single points of failure during early stage robot development. Having to think about distributed systems and SRE would be a huge distraction from the already complex task of designing a robot and its software. I also very much hope that ROS isn't currently being used in self-driving cars without a lot of safety systems including hardware ones.

Re: Robot Operating System – A flexible framework for writing robot software

#76
post #53

Earlier quoted context omitted.

Having written plenty of makefiles and cmakelists I would much rather write the latter for a CPP project. The idioms are easier to remember so I don’t have to search through SO to do little things. Let’s say I want to include a version of OpenCV of at least version 3.0, this is a super simple cmake command, make equivalent is probably not standardized and is some some strange syntax I will have to include in every ma…

The Make equivalent is just the set of commands you would use to generate OpenCV plus a target and dependencies. If you can shell script you can write a Makefile.

My point is that "find_package(OpenCV 3.0 REQUIRED)" is a whole lot simpler to remember than whatever the equivalent shell commands are to enforce the minimum version of a library. What you are suggesting is to build the exact version for use with this specific project, different from "Developer I checked your environment and your version is too low". I'm just speaking from my experience, if you are very experienced with shell and can reproduce this type of behavior more quickly then more power to you. This is a similar debate to "why rewrite standard libraries in every project", for example, to count items in a list in python I can loop through and modify counts in a dict or I can use "collections.Counter(list_)" and it does it for me. Cmake provides ample standardized methods for C++ builds that I don't have to rewrite over and over again for every project.

Re: Robot Operating System – A flexible framework for writing robot software

#77
ROS can be an super enjoyable and productive environment to build software in. It gives you access to a set of common sensor and actuator drivers, motion planning, navigation, perception libraries, and implementations of the latest IROS papers. I’ve seen it used to prototype lots of non-robotics applications too; really any local distributed system integrating, calibrating, and coordinating sensors. Personally I think the standardized data types it provides for robotics and perception data is one of its greatest assets [1], and could be a standards effort in itself. And it’s home to a great community.

But it definitely has its limits, especially as applications mature, and the ecosystem can feel siloed from the technology landscape evolving so quickly in, for example, backend distributed systems. Knowledge transfer between the robotics community and the software engineering happening in distributed systems, databases, gaming, web development, etc. is a huge untapped opportunity. Hit me up if you want to talk more about this!

[1] e.g. http://wiki.ros.org/sensor_msgs

Re: Robot Operating System – A flexible framework for writing robot software

#78

Please stop using names for version releases. Is "awesome igloo" newer than "super turtle" or "raring rino"? Just stop. Use boring versioning numbers. Your developers and users will thank you.

The software is versioned with numbers,the codenames are for releases which could have version number ranges, or help differentiate stable from testing, etc. The developers and users can better make the distinctions with codenames.

Decimals do that job with less characters.

Re: Robot Operating System – A flexible framework for writing robot software

#79

Earlier quoted context omitted.

The software is versioned with numbers,the codenames are for releases which could have version number ranges, or help differentiate stable from testing, etc. The developers and users can better make the distinctions with codenames.

Decimals do that job with less characters.

Tell that to Android

Re: Robot Operating System – A flexible framework for writing robot software

#80
I wrote a blog article recently wherein I propose that cloud-native infrastructure can be a better foundation for robotic software stacks than ROS/ROS2. I've been involved in several ROS-based robot & robot-sensor efforts and (like many others here) have found it lacking in major ways.

https://capablerobot.com/blog/2018/2018-05-09-wheel-reinvent...

There are a whole host of performant, lightweight, and open source tools for distributed-tracking, pub/sub, logging, serialization, service discovery, KV stores, visualization, etc. Right now it seems the robot world (including me) ignores this fact and continues to reinvent wheels (poorly).

I'm curious for feedback on this idea and will be publishing updates as I experiment with this idea. I'll likely be starting with timing & latency experiments between ROS, ROS2, and other cloud-native pub/sub brokers.

Post reply on HN