Related to the discussion happening here, a second technical report studying the Linux networking stack presented at Latency and throughput in ROS2.
This is a great discussion! I just wanted to bring up another group of people that would be interested in having and/or developing a low-level, real-time, robot-agnostic controller based on ROS or a single scripting language: research labs!
Backstory: I work for a professor who does industrial robotics research. (We are in the process of developing a lab for flexible assembly to collaborate with industry, graduate students, and undergraduate students.) We currently have three collaborative robots from different vendors and two manipulators being created from scratch by grad students. There is no history of using ROS in this lab, and it’s my job to learn to program each with vendor software and ROS, understand the limitations and capabilities of each method, and teach others when to use which and how. I imagine there are other research labs that work with robots from multiple vendors. Here’s a thesis on ROS software tested on the Panda and the UR5 intended for industrial applications (I know two potential customers is not the hugest motivation…)
I have the feeling that it’s still quite hard to get started on using ROS for an industrial application, because of many factors, not only involving the complexity of the ROS platform.
Yes, this has been my experience. I was 100% new to C++, python and ROS coming into this job a few months ago. The biggest source of friction in getting up to speed has been that I have tried to learn ROS from reading about how to use it on each robot separately. So, while ROS concepts are familiar each time, I’m still investing a lot of time learning how to control each.
In my opinion, in industry, users need an easy way of programming so they “get things done."
Students I’ve talked to are also wary of investing the time to learn C++ and ROS in their design projects.
In summary, being able to learn ROS on a controller such as discussed in this thread would be a quicker way to control many different brands of robot. I think people would be even more interested in learning the skillset and would be more inclined to test out different robots.
I hope this post is somewhat helpful in sharing a perspective from a noob in an industrial robotics research lab and not just a rambling commentary.
This I run into all the time as well, along with @chloe comment around students/even grad level students wary of C++ and ROS. This effort will obviously be a multi-generational effort. But first lay out a roadmap, and start small and build from there. I agree with @ThiloZimmermann that a near term initiative around the ROSIN FTP vehicle may be a good place to start. We look forward to seeing progress and challenging prior ways of thinking. Perhaps a side discussion can take place at ROSCon in Madrid to start framing out a roadmap with spurs to account for some of these ancillary concerns that we all know at some point have to be covered.
Looking forward to continued dialog on this one!
In addition, we started allocating resources to build a community-oriented prototype. We’ve introduced it at https://acutronicrobotics.com/modularity/robot-controller/. We will very likely manufacture a limited amount of units to get input from those interested. You can reach us directly if you have direct feedback.