4 ms·

Nice article. Would be interested to hear your thoughts on ROS 2, I haven't tried it out yet. Good luck with your consulting business! Not a fan of that fake s

by jpm_sd 6y ago

Nice article. Would be interested to hear your thoughts on ROS 2, I haven't tried it out yet. Good luck with your consulting business! Not a fan of that fake soldier-robot video that keeps popping up on HN. I think it misrepresents the robotics industry and it's horribly violent.

msadowski 6y ago
I promise myself to check out ROS2 for quite a some time now but I never find time for a proper sit down. I love the idea of ROS2 but the advice I'm usually giving clients is to only look into it as a part of their R&D and to expect to be very early adopters and therefore most likely needing to fix multiple issues that will inevitably come up. For the companies that have a single product they are focusing on and that they want to push out of the door as quickly as possible with minimum R&D budget I suggest sticking with ROS Melodic (afaik more package support Melodic than Noetic) but I also recommend them to keep an eye out on ROS2 and switching to it as soon as it makes sense for them. Right now I'm basing almost all my view on ROS2 on Michael Ferguson's blog (https://www.robotandchisel.com/ https://www.robotandchisel.com/) and particularly this article: https://www.robotandchisel.com/2020/07/29/five-things-ros2/ https://www.robotandchisel.com/2020/07/29/five-things-ros2/. When I will finally start experimenting with ROS2 I'm going to start with Autoware course: https://www.youtube.com/watch?v=XTmlhvlmcf8 https://www.youtube.com/watch?v=XTmlhvlmcf8 About the fake soldier-robot video: I think it's a good satire and I hope we will never get to anything similar to this in real life. As you probably noticed from the article I'm not a fan of military robotics.
snovv_crash 6y ago
My industrial-robotics perspective TLDR on ROS2: the biggest thing it changes is the transport layer, and the transport layer wasn't the reason industry didn't adopt ROS1.
- robotresearcher 6y ago
  What reasons dominated?
  - contingencies 6y ago
    Observation by a non ROS user: ROS is basically a hardware abstraction layer and set of common software components used by academics across many different manufacturers' hardware. Overwhelmingly it is used with third party robot arms to aid programming by people who want to focus on the maths and not the deployment, however it can be used for my sorts of situations. In reality, industry generally doesn't care about nominally innovative academic approaches to robotics, or even very much about hedging their lock-in with a vendor-neutral codebase, they just buy something that already works and use the software tools from the hardware vendor. Source: I went to a ROS conference last year and there was ~nobody using it in industry. The amount of money they were spending on hardware was staggering. I run a robotics company, we don't use ROS.
  - Iv 6y ago
    Last time I used it was a couple of years ago but it was rife with incompatibilities between versions. Make no mistake, it was still a huge step forward for academia as the alternative was to manage all algorithms individually and design a transport layer yourself, but as a software developer it feels like it was lacking in terms of good practices like backward compatibility. From a business perspective, ROS is an open framework, which is a plus only if you are in a specific perspective. Many robotics company still think in terms of walled gardens and hope to sell full solutions to clients, not have to support just a module in a complex environment. I would say that what ROS is lacking is a competitive marketing advantage. If ROS was promoting its brand and offering access to clients for companies that support it, it would help a lot its adoption.
  - snovv_crash 6y ago
    A few reasons: 1. Why would you? Having a bunch of nodes communicating with each other makes pretty graphs for a dissertation, but if you really just want to get something done, calling a library is much easier than messing with launch files and dealing with message passing and asynchronous behaviour. It brings in a ton of new complexity to solve issues which are only complicated to people who don't know how C++ threads or coordinate systems or other robotics bread and butter work. It reminds me of that quip, "You had a problem and tried to solve it with ROS, now you have 2 problems." 2. ROS is designed as a framework, not a library. This means that it's very hard to pick and choose the pieces you like, rather it is all or nothing. It also ends up with a lot of lock-in, and as a result code written for ROS is very hard to take into another context. 3. A lot of ROS tries to just 'make it work', regardless of if things are only partially configured, misconfigured, etc. If this is a one-off proof of concept then this is fine. If someone dies because things are misconfigured, I want the tools to complain very, very loudly, and preferably not work at all. 4. Unit testing in ROS environments is a pain. It is more oriented around doing simulation, but the simulation is the top level thing. This means something like business logic that depends on the simulation working in a certain way, or on the outputs of the simulation, is hard to verify the correctness of. This is unacceptable in a business environment. 5. Tooling. Why does it need its own package manager, its own build system? It even has its own runtime dependency analysis. Just use CMake, and the OS tools. Please please please. Deployment is such a pain! Anyways this is just off the top of my head. Consider the later points, and then go back to the first one, of "Why should industry use it?" To me, there isn't sufficient motivation for the added complexity ROS brings.

by jpm_sd 6y ago

msadowski 6y ago

I promise myself to check out ROS2 for quite a some time now but I never find time for a proper sit down. I love the idea of ROS2 but the advice I'm usually giving clients is to only look into it as a part of their R&D and to expect to be very early adopters and therefore most likely needing to fix multiple issues that will inevitably come up. For the companies that have a single product they are focusing on and that they want to push out of the door as quickly as possible with minimum R&D budget I suggest sticking with ROS Melodic (afaik more package support Melodic than Noetic) but I also recommend them to keep an eye out on ROS2 and switching to it as soon as it makes sense for them. Right now I'm basing almost all my view on ROS2 on Michael Ferguson's blog (https://www.robotandchisel.com/ https://www.robotandchisel.com/) and particularly this article: https://www.robotandchisel.com/2020/07/29/five-things-ros2/ https://www.robotandchisel.com/2020/07/29/five-things-ros2/. When I will finally start experimenting with ROS2 I'm going to start with Autoware course: https://www.youtube.com/watch?v=XTmlhvlmcf8 https://www.youtube.com/watch?v=XTmlhvlmcf8 About the fake soldier-robot video: I think it's a good satire and I hope we will never get to anything similar to this in real life. As you probably noticed from the article I'm not a fan of military robotics.

snovv_crash 6y ago

My industrial-robotics perspective TLDR on ROS2: the biggest thing it changes is the transport layer, and the transport layer wasn't the reason industry didn't adopt ROS1.

robotresearcher 6y ago
What reasons dominated?
- contingencies 6y ago
  Observation by a non ROS user: ROS is basically a hardware abstraction layer and set of common software components used by academics across many different manufacturers' hardware. Overwhelmingly it is used with third party robot arms to aid programming by people who want to focus on the maths and not the deployment, however it can be used for my sorts of situations. In reality, industry generally doesn't care about nominally innovative academic approaches to robotics, or even very much about hedging their lock-in with a vendor-neutral codebase, they just buy something that already works and use the software tools from the hardware vendor. Source: I went to a ROS conference last year and there was ~nobody using it in industry. The amount of money they were spending on hardware was staggering. I run a robotics company, we don't use ROS.
- Iv 6y ago
  Last time I used it was a couple of years ago but it was rife with incompatibilities between versions. Make no mistake, it was still a huge step forward for academia as the alternative was to manage all algorithms individually and design a transport layer yourself, but as a software developer it feels like it was lacking in terms of good practices like backward compatibility. From a business perspective, ROS is an open framework, which is a plus only if you are in a specific perspective. Many robotics company still think in terms of walled gardens and hope to sell full solutions to clients, not have to support just a module in a complex environment. I would say that what ROS is lacking is a competitive marketing advantage. If ROS was promoting its brand and offering access to clients for companies that support it, it would help a lot its adoption.
- snovv_crash 6y ago
  A few reasons: 1. Why would you? Having a bunch of nodes communicating with each other makes pretty graphs for a dissertation, but if you really just want to get something done, calling a library is much easier than messing with launch files and dealing with message passing and asynchronous behaviour. It brings in a ton of new complexity to solve issues which are only complicated to people who don't know how C++ threads or coordinate systems or other robotics bread and butter work. It reminds me of that quip, "You had a problem and tried to solve it with ROS, now you have 2 problems." 2. ROS is designed as a framework, not a library. This means that it's very hard to pick and choose the pieces you like, rather it is all or nothing. It also ends up with a lot of lock-in, and as a result code written for ROS is very hard to take into another context. 3. A lot of ROS tries to just 'make it work', regardless of if things are only partially configured, misconfigured, etc. If this is a one-off proof of concept then this is fine. If someone dies because things are misconfigured, I want the tools to complain very, very loudly, and preferably not work at all. 4. Unit testing in ROS environments is a pain. It is more oriented around doing simulation, but the simulation is the top level thing. This means something like business logic that depends on the simulation working in a certain way, or on the outputs of the simulation, is hard to verify the correctness of. This is unacceptable in a business environment. 5. Tooling. Why does it need its own package manager, its own build system? It even has its own runtime dependency analysis. Just use CMake, and the OS tools. Please please please. Deployment is such a pain! Anyways this is just off the top of my head. Consider the later points, and then go back to the first one, of "Why should industry use it?" To me, there isn't sufficient motivation for the added complexity ROS brings.