| ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org |
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.
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 
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
+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.
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.
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?
Thanks!
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.
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
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:
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:
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:
EDIT:
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!
Matt
Thanks for the input @mrobinson and @chloe, very useful. We’ll be displaying an early prototype of ORC (Open Robot Controller) at ROSCon during the following days.
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.
Update: The Machinekit and ROS combination shows it’s fruits. I have successfully converted an industrial robot arm stripping out the included controller: Machinekit and ROS controlling an industrial robot Time to look for applications.
Very nice update @machinekoder! It’s pretty interesting to read that you’re replaced the original controller with your own:
I threw out the original controller in favor of some Mesa-Electronics FPGA Anything I/O Ethernet cards. In particular, I used one 7i80 as a control interface, one 7i52 to interface with the differential-pair step-generation inputs and encoder feedback outputs, and two 7i37 Isolated Anything-IO adapters to connect the I/Os of the robot.
I’m not familiar with the Borunte BRTIRUS0805A robot but it sounds like you’re running the controller directly in the FPGAs, right? If that’s the case, it’s rather similar to what we’re doing with the ORC (it has a big FPGA inside). Could you share a bit more about the difficulties you found while interfacing with the Borunte arm?
Yes, the Mesa-Electronics Anything I/O cards use Xilinx Spartan 6 FPGA for step generation and to process encoder feedback. The cards themselves are connected via Ethernet to the Linux host computer. The driver is called hostmot2 and works via an open protocol called “TRAM”. In short, the cards communicate with the host PC via a best-effort UDP connection/ No problem since there is a direct connection between the MESA card and the PC.
The hostmot2 source code, both from the FPGA and the driver are open-source. Some devs from the Machinekit community ported the FPGA code to SoC platforms. A group from Germany created a fully open source AC servo drive also using the protocol but implemented on a uC (see STMBL).
The greatest difficulty I faced was wiring up the new controller cards. Every AC servo has at least 10 I/O connections that times six gives a lot of wires to connect. Not a problem, but half of my cables harnesses where wired incorrectly, so I had to do at least twice… If I built a productions system, I would go for a solution that either uses EtherCAT or hostmot2 to interface with the AC servo drives, saving lot’s work wiring up the electric cabinet.
The Machinekit part of the setup was relatively straight-forward for me. A challenge was the emergency stop and following error detection implementation.
The ROS part with hal_ros_control is straightforward, it’s just a matter of connecting the robot HAL pins to the exposed ros_control HAL pins.