I wouldn’t be so pessimistic about that. If they see it as a way to sell more robots, they might be more interested. You need to approach them with the idea that it will expand the market for their robots, rather than as something to cannibalise their controller business. I’ve seen it work before.
You are welcome. I totally agree with the papers statement and appreciate the effort invested into modularization concepts HRIM, H-ROS, etc as well. I am looking forward to the follow up.
First: I’d love to have a full open source stack! Specifically the part where you just want to have a robot do some things.
For this idea to succeed (you want to make money doing this too), you need to know your targets. Will that be companies? A robot manufacturer (startup?) looking to offload support to a community? A manufacturing company which makes products? Why would such a company decide to use another platform if they already have spent serious money on a robot brand, including educating staff and writing programs (sometimes processes are signed of by their customer, which will make it even less interesting to switch)?
In my opinion, in industry, users need an easy way of programming so they “get things done”. These users don’t go designing robots, they don’t have the knowledge/time/money, they don’t go tinkering, they don’t have the time/knowlege/task to dive into writing nodes and worrying about dds, realtime etcetera. They have a task and want to use a tool to solve a problem.
Companies themselves struggle to hire staff who can perform these (for the ROS community simple) tasks. On a normal level, coming from school. These men and women do not have a university degree.
I think that one of the big missing things in a full stack is the programming language and easy programming for a factory user. All your points about the hardware side are doable.
If you want to have success:
- you need something that companies can buy, proving they can get going. They are mostly interested knowing if the tool can do the job, and what it yields them. Managers mostly decide about purchasing these tools. Concepts as ROS, Open Source or vendor lock-in are second round considerations.
- staff must be able to work with your stack solving a problem, They will help leverage the decision if they tell their Manager that they are able to work with the tools. Possibly even tried out a demo without hardware.
- If people coming from school knowing this programming language and if you’re lucky some hardware/software concepts, you’ll also solve the problem of companies trying to find educated personnel. Might be an opportunity for the ROSIN project and education.
- do not underestimate developing and selling a product, and providing support if you’re going to provide hardware/software as turnkey solution.
- consultancy would be where you have a starting point.
@shaun-edwards I was thinking about something end-user facing for the programming language, like a turnkey solution that works similar to what typical industrial robot controllers offer. But maybe I’m thinking to much “in-the-box” on this topic.
And yes, support for off-the-shelf robots is a necessity in my opinion, even if you don’t get the support of the vendors themselves, the vendors provide ROS support, so it shouldn’t be too hard to add support for their robots. But it would be of course better if the vendors collaborate, selling more robots, for additional user groups, could be an opportunity for them as well.
@vmayoral Thank you for contacting me. I’m very interested in hearing and seeing more at ROSCon.
@gbiggs I agree.
RT support of the middleware is definitely helpful, but I don’t think it’s a minimum requirement for such a controller. As pointed out, Machinekit or any other motion control layer needs to be RT capable, but the middleware itself could also operate in userland.
The RT support of the middleware, however, is necessary when we are talking about distributed motor control. Which is something @vmayoral is targeting for example.
I agree. Supporting closed source robot hardware would be possible, even without the vendors actively helping with the integration.
On the other hand, vendors could be interested in offering ROS support not only as a software package but also on the controllers they sell. Just musing.
And to answer your introductory questions: Yes, ROS Discourse is the right forum to discuss this
From a point of view of ROS-Industrial Consortia (in the Americas, Europe and Asia-Pacific) you mention a lot of issues that we 've looked at it in the past, and as my previous speakers/posters have already expressed: some of it is tempting, most of it could be possible, and all have been on the radar (which does not make it less right or wrong).
As you remember from our last collaborations (thanks again for your support at sprint tech workshop & World ROS-I Day - July 11 at IPA), the devil is in the details (e.g. see comments from @Jmeyer like: safety, cost, and support reasons). Therefore, we use official industrial robot controllers.
If you want to challenge this (and think, you can find potential customers that don’t have that restrictions), I personally would encourage you and others to further investigate in developing a fully Open Source Industrial Robotics Controller. In that respect: great offer, @vmayoral, for offering to allocate some resources and contributing with such a project.
So far there was not a sufficient alignment of the significant resources involved in such effort (think about the safety certification costs alone) to pull this off. If anybody has more links, please add them to this post/thread.
+1 for this. Thanks @basdebruijn and @ThiloZimmermann. After the reactions, we are considering doing so. I’m thinking more in the ROSin FTP direction though. Although the percentage funded is lower, it certainly (at least it does to me) matches a bit better the objective of a potential project (maybe someone could argue this?).
Creating a small consortium where each partner had access to a different industrial robot and could contribute with their corresponding abstractions for a common Open Robotics Controller (ORC?, not calling it OSRC for obvious reasons) may make sense.
If there’s anyone interested, please say so.
Very interesting idea indeed. I like the suggestion of ThiloZimmermann for a EU funding. So, If @machinekoder and @vmayoral are considering to apply it. Can I propose to joint this proposal as an academy collaborator? Thanks.
Thanks for your interest. That’s certainly very feasible. The current status of the project proposal is as follows:
Project will be focused around adapting a reference hardware Open Robotics Controller (ORC) (potentially to be provided by us, Erle Robotics and made it open (including hardware) during the project) to a variety of different industrial robots. Each partner should contribute with a HW/SW layer that adapts the ORC to the robot (or robots) selected. Obviously, this implies that each partner should have access to the corresponding industrial robot and the capability of modifying the interface with it. Ideally, contributions from each partner should focus on different robots (so that we demonstrate the flexibility of such ORC).
Currently, the group is composed by:
|Entity||Robot targets (potential targets/interfaces for the ORC)|
|Röessler Systems||access to Kuka, ABB and Fanuc manipulators.|
|Acutronic Robotics (Erle Robotics)||UR3 (potentially also UR3e) and MARA (a modular industrial manipulator, to be announced soon)|
We will need a bit more of information about you and your group but feel free to write me if you feel you could contribute. Please specify which robot targets you’d be willing to use for the project.
Hi @vmayoral @machinekoder I’ve been working on and off on an OS robot (hardware, so that dimensions can be adapted for each case), running on Machinekit called Matilda Currently I’m working towards changing the design from prototype for use in practical colleges in NL. I too would like to enquire how can collaborate this project.
Pretty interesting! Why don’t you write me directly at “victor at erlerobotics.com” and describe a bit more the contributions you have in mind, the entity you belong to and the robot targets you have in mind?
It looks an interesting initiative!
Robotnik is willing to collaborate in this project. We can contribute with our mobile robots!
We’ll write you directly.
Thank’s for your idea, I really agree!
The good news is: There is an industrial controller (controller + IO-system + Linux + Real-time + …) available which supports ROS.
Please send a short e-mail for more information (firstname.lastname@example.org) or have a look a this Document
Very nice and exciting topic! I would love to make a robot and understand everything about how it works
From my experience the only thing that makes a robot industrial is the fact that companies are able to buy it and legally use it (certifications / safety). It’s not about weight, payload, speed, range, being collaborative or even how the maintenance will be done, these are to be discussed after a certification is issued.
The dream robot for me would be:
- Open source hardware
- Mechanics (dimensioning, CAD / drawings, most interchangeable parts as possible)
- Electronics (CAD / BOM)
- Open source software
- ROS native
- Access to the closed-loop control (monitoring, configuring etc.)
I think there is a real marker opportunity in making cheap capable robots, robots that do not cost much (mechanics, electronics) but have nice software inside, which would easily allow tasks that known industrial robots struggle with (vision etc.).
For every robot that I have used so far the problem was always in the software:
- Not being able to run tasks concurrently
- Robot not following the setpoint (not because of the mechanics)
- Missing (paid) options
- Low memory
- ROS driver not exposing all controller functions
- And the list goes on…
I think one big barrier is the mechanics cost: making a decent robot is complicated and expensive.
There is already a lot of open source robots that can be 3D printed, however most of them use stepper motors or servomotors which may not be the best if scaling up the robot. It could be a great start using these projects with AC or DC servos instead of servomotors.
I can help for:
- The mechanics
- The software (from real time to GUI)
Open source robots
Related to the discussion happening here, a second technical report studying the Linux networking stack presented at Latency and throughput in ROS2.
Yet, another update 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.