Could someone explain for a new bee. If I’m building a robot why would I use this and not just write a python script running on Linux?
Robot Operating System – A flexible framework for writing robot software
31–40 of 85 posts
Re: Robot Operating System – A flexible framework for writing robot software
#32My 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…
I spoke Mikael Arguedas at the 2018 French ROS days (JONAROS) where he gave a presentation about ROS 2 (talks are available online IIRC, in French). During his presentation; he said that most of ROS 1 was engineered before any of today's well known frameworks were available , hence the lot of custom tools. That has driven a major part of ROS 2's design (especially the use of DDS). Otherwise, I have been personally us…
he said that most of ROS 1 was engineered before any of today's well known frameworks were available , hence the lot of custom tools.
catkin is built on top of CMake, so that's no excuse.
Re: Robot Operating System – A flexible framework for writing robot software
#33jj
Re: Robot Operating System – A flexible framework for writing robot software
#34Could someone explain for a new bee. If I’m building a robot why would I use this and not just write a python script running on Linux?
You can use ROS with Python and Linux. In fact, that's a big chunk of actual ROS-based systems out there, with most of the rest being C++ and Linux.
For simple robots, you can get away with a simple script. But say, you want to attach more sensors, add some visualization, some logging, etc. Pretty soon you'll find yourself writing multithreaded (not great in Python) and/or multiprocess code, some kind of simple GUI to visualize data, some logging code, some way to manage parameters... and before you know it you'll find yourself writing your own little version of ROS (or more generally, robotic middleware). And without the huge ecosystem of ROS packages that might solve all sort of problems for you.
Re: Robot Operating System – A flexible framework for writing robot software
#35Earlier quoted context omitted.
The build system is mostly macros on top of cmake. But not ideal indeed. Same for the IDL. ROS 2.0 [0] should adress a lot of those issues, also stuff like real-time, improved security, no roscore needed. On the robots I worked with, I never missed any of those features, to be honest. Largest project of those is a research home service robot, quite different from a self-driving car in terms of reliability requirement…
> The build system is mostly macros on top of cmake. That makes it even worse. So it's crap on top of crap. CMake is mostly used to build cross-platform software, but I don't think anybody uses ROS on a system other than Linux, so why not just use established tools like simple `make`?
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.
Re: Robot Operating System – A flexible framework for writing robot software
#36Could somebody, please, explain me what I need in addition to ROS for functional safety. Some certified laser scanner? Do I understand it right, that ROS completely ignores functional safety?
Thank you for explaining this issue. So commercially available robot needs Jetson TX2 (or Wandboard) with ROS and some hardware from safety tools vendor like Pilz or Sick. And the whole safety assessment from TÜV with official certificate. That was helpful!
Re: Robot Operating System – A flexible framework for writing robot software
#37Earlier quoted context omitted.
The build system is mostly macros on top of cmake. But not ideal indeed. Same for the IDL. ROS 2.0 [0] should adress a lot of those issues, also stuff like real-time, improved security, no roscore needed. On the robots I worked with, I never missed any of those features, to be honest. Largest project of those is a research home service robot, quite different from a self-driving car in terms of reliability requirement…
> The build system is mostly macros on top of cmake. That makes it even worse. So it's crap on top of crap. CMake is mostly used to build cross-platform software, but I don't think anybody uses ROS on a system other than Linux, so why not just use established tools like simple `make`?
ROS runs on Mac, and ROS 2 adds Windows support.
Re: Robot Operating System – A flexible framework for writing robot software
#38Earlier quoted context omitted.
Yeah, ROS is a very good example of worse being the enemy of good (to mangle some sayings). It's a common framework which does basically everything you'd want to do in a robotic system, with a bunch of useful functionality on top of it, but basically every part of it is incomplete, poorly documented, awkwardly designed, and buggy. However, since there's basically nothing else which addresses the same space, people fe…
So basically, ROS is the UNIX of robotics (i.e. "worse is better", + judging by how many serious projects using it are mentioned elsewhere in this comment thread)?
Kind of. Fundamentally, it has never had much competition due to the narrowness of the scope. It is ubiquitous in university robotics due to its accessibility, but in my experience most (successful) industrial robotics applications will simply provide an interface to ROS: internally they will not use it at all.
One thing with ROS is that reimplementing it is not particularly difficult: I have, for various reasons and projects (in some cases before ROS was available) implemented basically all the core components of it (to similar levels of completeness and reliability). So the cost of doing it yourself is actually not all that high (and I think people overestimate it).
Re: Robot Operating System – A flexible framework for writing robot software
#39My 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…
I spoke Mikael Arguedas at the 2018 French ROS days (JONAROS) where he gave a presentation about ROS 2 (talks are available online IIRC, in French). During his presentation; he said that most of ROS 1 was engineered before any of today's well known frameworks were available , hence the lot of custom tools. That has driven a major part of ROS 2's design (especially the use of DDS). Otherwise, I have been personally us…
I just saw that ROS2 will be based on the DDS standard. I came across DDS before in a different context and it impressed me a lot. It reminds me of the concepts in the eve programming language where to build a distributed system you share a global data space. Both took inspiration from LINDA and tuple spaces. "The data is the interface" https://www.rti.com/products/what-is-a-databus
Re: Robot Operating System – A flexible framework for writing robot software
#40Could somebody, please, explain me what I need in addition to ROS for functional safety. Some certified laser scanner? Do I understand it right, that ROS completely ignores functional safety?
Thank you for explaining this issue. So commercially available robot needs Jetson TX2 (or Wandboard) with ROS and some hardware from safety tools vendor like Pilz or Sick. And the whole safety assessment from TÜV with official certificate. That was helpful!
Depends on what your market is. The suitability of Jetson TX2 for industrial robots is quite debatable, for instance. Might be sufficient for service robots, but really depends on the notified body accepting your argument. Also don't forget that the actuators (brakes? power?) are part of the safety architecture as well.
Word of advice: You need to have a 100% waterproof concept, otherwise your product will _not_ make it to market. Don't try to guess your way around the safety system, it will cost you dear later on.