Did you miss Víctor's talk at ROS-Industrial Conference 2018? Find the video and a summary in this post. He discusses the challenges and strategies for building robots using the Robot Operating System (ROS).


[2:03] We have seen that system integration supersedes other tasks when building a robot. However, programming has been a big topic in robotics research for the last decade.

Honestly, our experience has told us that system integration goes way beyond programming. And according to statistics, roboticist use about 70% of their time and resources dealing mainly with hardware and software interfaces, over and over again. We ourselves started this modular robotics journey to address that particular problem.

Why? Because if we look at the traditional process of building a robot, we see that integration of hardware components is a big part of it. While with the modular approach, that step is shortened or even eliminated.

Challenges we've faced:

[4:06] I'd like to share with you today some of the challenges we have been facing during this journey. I'll start with the Link Layer.

In a common robotics set up you may have a robot controller, a couple of actuators plus a sensors feeding the robot with information. But in some cases, when we look at the link layer we see that delays go up to 2 milliseconds due to congestion.

We've been working to solve this problem. Particularly using a set of standards that extend traditional Ethernet to make it real-time capable.

We were able to lower the latency and restrict it quite substantially, three orders of magnitude. We've come from 2 milliseconds down to the micro-second level. This has been done with a number of partners, among others Xilinx, with whom we've been working very actively, a fact we are very happy about.

[6:43] The next problem we tackled was RTOS and networking stack. In a paper, we described how we attacked this problem. We use the Linux Networking Stack which gives a lot of flexibility. We designed the following set up, with 4 different configurations:

With these 4 options in mind, we started measuring. And since we are focused on modularity, all has been run on this tiny device: the H-ROS SoM.

When it remains idle, we get something bellow 2 milliseconds. If we start stressing, things start exploding. Applying the preempt patches we get bellow the 1 millisecond level.

The real value of doing those optimizations can be seen when we introduce traffic. Neither the Vanilla kernel neither the normal kernel are able to remain stable, However, with the patches, we indeed are able to get the responses we want. A both-way response bellow 600 microsecond.

[9:34] The next question we asked ourselves was: How does this look with ROS on top?

[12:18] Of course, we also looked at the issue of time-synchronization in robot modules. By using PTP in a distributed manner, we were able to obtain sub-microsecond level distributed synchronization. This was pretty remarkable.

Overloading the system, latencies sometimes exploded. But using PTP they got strict. In our experiments, bellow 3 milliseconds.

[13:45] With all of this information, we had qualified our device to do soft or firm real-time. But we asked ourselves, can we actually do better? And we believe we can.

That's why we started to work with AI for robots. We said, now we have the modular way of building robots, where we have somehow eliminated the integration effort. But there's still the huge task of programming. Could we simplify this a bit?

And what we started doing is using Reinforcement Learning Techniques. Training robots rather than programming them.

This potentially allows to serve clients by deploying the robots, changing some minor set ups and getting the robot trained only -and hopefully on the edge- in the factories.

But are we ready to do so?

We ourselves are not ready yet. We've participated in state-of-the-art conferences, we've contributed, but still our results with MoveIt are better. Yet we still are investing on AI because we believe it has potential. And we keep working on it, and that's why we are releasing some API levels.

[16:55] When we asked ourselves if we could do it better, we did not think only about AI but also wondered if there are any other relevant things. And in did, there was: interoperability among modules.

That's why we started building HRIM, a meta-model for robots.

Our modularity solution:

[20:28] After all of the work, we can say that modularity indeed reduces system integration effort. The H-ROS SoM is our solution, where we have wrapped all in a stack that goes from the hardware architecture up to the application level with optimized ROS client libraries for real-time response.

Our vehicle is this tiny device that typically gets integrated in robot hardware. We've worked with manufacturers like Han's Robot. And got their robot joints natively run ROS2. The robot joint (or actuator) itself is publishing, is subscribing, has parameters. Of course you can fine-tune things but all the complexity of installing ROS2 or cross-compiling things is avoided. We fixed it by working directly with manufacturers.

Using the SoM and working with manufacturers we have managed to come up with the first industrial modular and collaborative robot. Pre-orders are open now and MARA robotic arm is available worldwide for 15,000€, what we believe is a more than reasonable price for a modular robot that has industrial capabilities and ROS 2 running on every single one of the joints.

So with this, I invite you all to join us and dive into modularity!