1. Project Overview
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.
There are three primary challenges people face when they want to use IRs outside of manufacturing settings:
- They are PROHIBITIVELY EXPENSIVE.
- They have PROPRIETARY INTERFACES.
- The KNOWLEDGE to use them is PRIVATE.
We built Robo.Op to bypass the expensive, proprietary software and hardware currently offered by robotics companies. Robo.Op enables artists and designers to (a) develop affordable custom tools for creative robotics, and (b) share tools and knowledge across robotic platforms.
To begin opening up IR hardware for creative use, we created a universal adaptor plate for the end of the robot. This end-effector adaptor plate is designed to be a modular, open hardware platform that integrates existing physical computing platforms (e.g., Arduino or RedBoard). It also creates a common, cross-brand baseline for prototyping smart tools on 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.
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.
The last component of Robo.Op is this wiki, a central hub for sharing knowledge, tools, and code. By hosting the project on github, we hope that anyone will fork our project, adapt Robo.Op to their particular robot configuration, then contribute back code, fabrication files, and example projects for their custom builds.
Currently the project supports ABB robots, but we are eager to collaborate with others to make additional IR platforms open for creativity (e.g., KUKA, FANUC, or Stabuli). If you have any questions, please get in touch with us at peopleplusrobots@gmail.com or through github.
We are excited to be collaborating with you ...