robo.op

opening industrial robotics

Robo.Op is an open hardware / open software platform for hacking industrial robots (IRs). Robo.Op makes it cheaper and easier to customize your IR for creative use, so you can explore the fringes of industrial robotics. The toolkit is made up of a modular physical prototyping platform, a simplified software interface, and a centralized hub for sharing knowledge, tools, and code. For latest examples of what Robo.Op can do, look here!

See our project page – peopleplusrobots.github.io/robo-op – for implementation details.

Below are details on the motivations and design decisions behind Robo.Op

Challenges for creative robotics

Although the last decade has seen a large body of work develop for creative robotics, there are still steep challenges to overcome for working with IRs outside of manufacturing settings. The three primary challenges for working on the fringes of industrial robotics are (1) Access: their high costs make it difficult to even have access to an IR; (2) Siloing: robotics brands are purposefully not compatible with one another; and (3) Private: the knowledge to work with IRs is often hidden or non-existent. 

Robo.Op tries to address each of these challenge by making it cheaper and easier to customize your IR for creative use. It's made up of a modular prototyping platform, a simpler software interface, and a centralized hub for sharing knowledge, tools, and code.

Current infrastructure for IRs – their supply-chains, knowledge systems, and price-points – is geared towards large multi-robot operations, where pre-existing tasks are programmed into teams of IRs. This environment does not foster individuals wanting to explore, experiment, and innovate on current uses of industrial robots. Therefore, just gaining access to an industrial robot is perhaps the toughest obstacle one must first overcome. This is beginning to change, though. De-industrialization in some parts of the US has led to the growth of second-hand markets for industrial robots and accessories, and there has also been efforts to create cheaper, open industrial robots from scratch (see for example, OSE's - Industrial Robot and UFactory's uArm).

If you're fortunate enough to have access to an industrial robot, the next challenge is learning how to use it. This is not an easy task as a robot's programming language, controller, hardware configuration, and even coordinate system can vary from brand to brand. Industrial robotics companies do this to make it more difficult for you to switch brands in the future: the more time, money, and resources you've invested learning their proprietary software and hardware, the less likely you'll change to a different company. One unfortunate consequence of these proprietary interfaces is that collaboration and knowledge sharing becomes extremely difficult across platforms. ROS – Robot Operating System – is attacking this challenge within robotics communities; providing tools, libraries, and standardized conventions for working collaboratively across robotics platforms.  Although there is a large community contributing useful tools to ROS, its primary audience are roboticists, engineers, and computer scientists; using ROS requires quite a bit of specialized knowledge in computer vision, motion planning, physical simulation, etc.  

ROBO.OP – prototyping a universal toolkit for hacking industrial robots

The idea for Robo.Op grew out of a separate project with the Human-Machine Virtuosity research group at Carnegie Mellon University. We wanted to make an end-effector, a "smart-tool" at the end of a robotic arm, that could sense directional forces placed on it. While sensors for this already exist, they come with a $30,000 price tag (see bottom left). At the same time, we noticed a lot of similarities between all of the custom tools that students, faculty, and researchers were building for our robots (see bottom right). Each of these end-effectors for mark-making, gripping, seeing, and deforming seemed to be re-inventing the same basic building blocks: a way to attach to the robot, ways to act on a material, ways to sense the environment, and ways to actuate the tool.

Two things became clear: (1) we couldn't purchase existing sensors and tools from robotics companies, and (2) a lot of redundant work was happening to rebuild the same basic end-effectors.

So we set out to create an open hardware / open software toolkit that lets designers:

1. Develop affordable custom tools for creative robotics. 
2. Share tools and knowledge across robot platforms.
3. Bypass the expensive, proprietary software and hardware currently offered by robotics companies.

OPENING HARDWARE

With these goals outlined, our first steps were to prototype a universal adaptor plate for the end of the robot. This adaptor plate is designed to be a modular, open hardware platform that (a) integrates existing physical computing platforms (e.g., Arduino and RedBoard) and (b) creates a common baseline for prototyping smart tools for any industrial robot. 

The current version of the hardware for Robo.Op is called the Robot Tool Adaptor (RTA).  The RTA is built from a series of modular components:  

• an adaptor plate that connects to the RTA to the end of a robot, 
• power units that transfer high-voltage power from to robot into standard three-prong outlets
• an intelligence unit that holds a micro-controller and a circuit board that connects robot and microcontroller I/O's
• connectors for attaching external devices

The RTA irons out a number of small, but cumbersome, hurdles that everyone deals with when working with IRs beyond their basic use. For example, power is often the last thing you think of when designing a custom end-effector: if you want to put motors, micro-controllers, cameras, or projectors on the end of the robot arm, how do you actually get power to these devices?  You used to need a battery big enough or an extension cord long enough to run your tool. But this is inefficient and sometimes hazardous in the working area.  The RTA routes normal 120V power from the robot into generic power outlets mounted right at the end of the arm. This lets you just plug-in your device and power it directly from the robot.  Similarly, the on-board micro-controller is powered directly from the robot – so there's no more need to follow two steps behind your robot with a USB cord connecting your laptop to your arduino!

Another common hardware hurdle is communicating between your microcontroller and your robot. Current common-practice for an arduino-controlled end-effector is to asynchronously program the robot and microcontroller: they don't actually communicate with one another, so you have to manually pause a program running the robot to run a program on the microcontroller. The RTA enables a microcontroller and IR to communicate directly through their digital I/O's: we've integrated an additional circuit board converts a 5V signal from an arduino into a 12V signal that a robot can read (and vice versa). 

The last problem to eliminate is mounting tools and sensors.  It's fairly straightforward to mount a primary tool to the end of an IR: you just match up a hole pattern between tool and robot, then bolt it on. But it becomes increasingly complicated when you want to integrate additional accessories like sensors, projectors, or tools. The RTA uses a modular bolt and t-slot system for mounting.  These quick connectors leaves your component layout as flexible as possible, while still letting you add, remove, or reposition components as necessary.

Opening software

With the Robot Tool Adaptor offering a unified platform for prototyping hardware, we wanted to make a similar effort to modularize and simplify the software interfaces for programming IRs. As mentioned earlier, each industrial robot manufacturer uses its own proprietary programming language for their line of IRs. This makes it extremely difficult to (1) learn multiple machine languages, (2) collaborate with groups using different brand IRs, and (3) openingly share useful code and knowledge. To make it easier to read, learn, and share code for creative robotics, we decided to port RAPID (ABB's closed, arcane programming language) to Processing (an open, java-based creative-coding platform).

To enable a Processing sketch to communicate with an industrial robot, we created a generic server program to continuously run on the robot's controller. Current common-practice for programming tasks on an IR is to pre-plan all of its motion paths using some proprietary software environment (for ABB this software is call RobotStudio,) or 'teaching' it point-by-point by moving it with a joy-stick. While this off-line, static method for programming IRs is adequate for repetitive manufacturing tasks, it is extremely limiting for creative robotics: it does not facilitate interaction between designer, robot, and environment, and the trial-and-error nature of off-line programming is very time-consuming and tedious. 

By connecting our generic server program to Processing sketch over TCP/IP, we are able to send and receive commands to the robot in real-time. This opens up a world of possibilities for on-line programming: it lets an IR dynamically respond to streaming input from a person, sensor, environment, or material. By facilitating live communication Robo.Op helps to push potential uses for IRs beyond automation and into interaction.

The diagram below breaks down the structure for sending a command from a user's processing sketch to an IR running the server program. The basic idea behind the design of the code is for the generic server program running on the robot (Server.mod) to just parse and handle key-value strings sent from the class, Robot.java. These key-value strings  lets the processing interface remain modular and independent from a proprietary machine language of an IR brand. For example, to adapt our processing interface from an ABB robot to a KUKA robot, you don't need to modify any processing code; you just need to format the Server.mod file for KUKA's language.  This means that a Processing sketch developed on an ABB robot should also work on a KUKA.

The processing interface, in addition to making live-control and cross-platform programming possible, also integrates other communication channels. For example, it integrates serial communication for connecting to the microcontroller on the RTA over Xbee. It also integrates Andreas Schlegel's oscP5 library to connect other software environments, such as Grasshopper3D, Pure Data, MAX/MSP, VVVV, or Unity, to an IR. This lets our Processing interface act as a gateway for interactive software environments, not usually associated with industrial robotics, to begin to play in the same sandbox.

Sharing Knowledge

The last component of Robo.Op is a central hub for sharing knowledge, tools, and code.  To that effort we are hosting the project on github.  This lets anyone fork our project, adapt Robo.Op to their particular robot configuration, then contribute back code, fabrication files, and example projects for their custom builds. See peopleplusrobots.github.io/robo-op for links to code, fabrication files, and a detailed wiki.

Currently the project supports ABB robots, but we are eager to collaborate with others to make additional IR brands open for creativity (e.g., KUKA, FANUC, or Stabuli).  If you are interested in collaborating please get in touch with us at peopleplusrobots@gmail.com or info@madlab.cc