ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Fully Open Source (Industrial) Robotics Controller

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!



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


Potentially related to this discussion: Functional Safety Design Patterns


I think this might be interesting for those here,


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.