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.
Robot Operating System – A flexible framework for writing robot software
71–80 of 85 posts
Re: Robot Operating System – A flexible framework for writing robot software
#72Please 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.
Re: Robot Operating System – A flexible framework for writing robot software
#73Earlier 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.
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
#74Earlier 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…
Re: Robot Operating System – A flexible framework for writing robot software
#75My 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…
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
#76Earlier 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.
Re: Robot Operating System – A flexible framework for writing robot software
#77But 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
#78Please 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.
Re: Robot Operating System – A flexible framework for writing robot software
#79Earlier 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.
Re: Robot Operating System – A flexible framework for writing robot software
#80https://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.