Fully Open Source (Industrial) Robotics Controller

ROS-Industrial
1

I’m unsure if this is the right forum to discuss ROS related business ideas or not, if not please let me know where the right place is.

I have this vision of a fully open source industrial robotics controller based on ROS-I. This includes hardware and software, basically, everything that you need to drive a robot from the motor drivers up or alternatively to drive a robot with an existing proprietary controller.

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.

What’s missing from ROS at the moment are following pieces. I’ll also add my ideas on how to solve them.

  • a robot command/programming language, equivalent to what you have for industrial robots - that’s only necessary if you want to skip the vendor’s controller
  • An easy to use online programming HMI, well, that’s doable.
  • A low-level real-time capable platform to drive the robot if you are not interested in using the vendors’ controller. Machinekit + ros_control work for this.
  • A reference hardware platform. I know applications are diverse, but having a common ground to start from just makes things a lot easier. An RT Linux capable platform, preferably with low-level IO access, which is powerful enough to support CV and machine learning applications should do. Turns out the Up2 is a good candidate.

The opportunity I see here is to build such a platform. For a client, this platform would give following benefits, compared to using a proprietary robotics controller.

  • No vendor lock-in.
  • Easy and intuitive programming, thanks to the great HMI and teaching capabilities.
  • Leverage the whole ROS eco-system for your application.
  • Rebrand the product for your application.
  • A reference platforms makes it easy to get started, more focus on your core business.

How to make money with this business?

  • Sell the hardware/software as a turnkey solution.
  • Provide consulting services around ROS, robotics hardware and so on.
  • Use dual licensing for commercial and open source applications.
  • Provide paid premium support for the platform.

The goal of this project is to make using industrial robots more affordable and accessible by leveraging the power of ROS.

Status: Idea, partially proof of concept

I would very much appreciate your feedback if you think this is a reasonable idea and what kind of applications you see for such a platform.

9 Likes
2

I’d suggest to wait for ROS 2 and consideration of TSN in DDS. The paper about hard-real time support of ROS 2 middleware DDS via TSN referenced in this thread could be interesting for you. From the papers conclusion:

“For higher layers, we foresee a contending landscape where the integration of TSN
in different middleware solutions focused on interoperability
such as OPC-UA and DDS promise to deliver a bottom-up
real-time communication solution.”

2 Likes
3

I love the idea of an end to end open robot controller. The nature of my work (contract research at SwRI) means that custom hardware is almost never allowed for safety, cost, and support reasons. I think you will find a lot of folks here that have similar restrictions.

What a lot of us can collaborate on is the user facing end of your proposed stack: the programming language, virtual pendant, and communication interface between PC & hardware. I’m just musing now, but recently we’ve seen more robot vendors provide a “dumb servo” interface to their hardware. We should have (but do not) the basic software in place to easily replicate what robot controllers can do now: jog, point to point move, cartesian move. Save paths, load paths.

4
  • a robot command/programming language, equivalent to what you have for industrial robots - that’s only necessary if you want to skip the vendor’s controller

If we have our own controller, that is ROS based, it almost eliminates the need for a robot command language. However, I do think there is value in providing a programming interface that is more familiar to industrial robot programmers. We are actively developing something called moveit_simple, that attempts to simplify programming, while still benefiting from power of ROS.

Additional must-haves:

  • Trajectory generation, planning, and smoothing at the joint level is also missing. This would have to be added to the low level controller in order to achieve industrial robot level motion.
  • Collaborative functionality. Might as well jump into this growing market, rather than focus on legacy applications.

How to make money with this business?

This is by far the harder question. An open source controller still requires a robot. Not everyone is going to build a custom robot (or not enough to make it a worth while business). If the controller worked with off the shelf robots, that would help, but I don’t see getting the cooperation of existing robot vendors as very likely.

5

Very interesting topic indeed! Thanks @machinekoder for bringing it up and @fkromer for referring to our previous work (we will release before ROSCon a follow up on that!).

We actually looked at a somewhat similar idea a while ago and have an inhouse prototype that interfaces with two of the most common collaborative robots seamlessly (in our opinion, @shaun-edwards is indeed right about the opportunity here). From a modularity perspective (which is what we’re mostly interested in), such a concept (an Open Source (Industrial and generic) Robotics Controller) is something very appealing but we did not obtain good input from the robot vendors we spoke with (which I guess was expected).

We already expressed this to @machinekoder directly but to motivate others to contribute, we from Erle Robotics wouldn’t mind allocating some resources and contributing with such a project.

E.g.: if there were to be enough interest, we could produce a limited number of our existing prototype of generic robot controller and distribute it to those interested parties.

6

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.

7

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.

8

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.
9

@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.

10

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.

11

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.

12

Dear @machinekoder,

thank you for your post . And thank you @fkromer, @Jmeyer, @shaun-edwards, @vmayoral, @gbiggs & @basdebruijn for adding valuable answers to this thread.

And to answer your introductory questions: Yes, ROS Discourse is the right forum to discuss this :slight_smile:

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.

As you and @vmayoral are both based in Europe, you could even apply for some EU funding for a Focused Technical Projects (FTP) via the ROSIN project (http://rosin-project.eu/ftps) and give it a try.

Good luck!

@gavanderhoorn, @mrobinson, @mirko-b, and Thilo

3 Likes
13

+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.

1 Like
14

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.

2 Likes
15

Hello @GURob,

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.

16

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.

1 Like
17

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?

Thanks!

18

Hi @vmayoral,

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.

4 Likes
19

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 (bth@keba.com) or have a look a this Document

2 Likes
20

Very nice and exciting topic! I would love to make a robot and understand everything about how it works :slight_smile:

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.)
  • Certified

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)

EDIT:

Open source robots

Electronics

2 Likes