Many Ways to Control a Robot
Arguably what makes a robotic arm attractive as a platform for creative experimentation is its ability to move in space freely and precisely. Unrestricted by the nature of purpose-built machines like cartesian 2D plotter, 3D printers or cnc milling machines, a robot is a universal, generic machine that can be rapidly customised to achieve a specific set of actions without the burden of falling into an engineering rabbit hole while building a machine from scratch.
If we do not need to build an ad-hoc machine when using a robot instead, we must still program it to follow a specific sequence of actions. There are three general approaches to programming a robot, that are commonly referred to as online, offline and real time programming. What dictates which technique to use lies essentially in where the spatial information that we desire to reach with it rests.
Are we interested in moving in a sequence of arbitrary postures? Do we want to grab an object placed in front of it? Then we might primarily use online, also often referred to as visual programming, because the spatial information we need, where we need to go is best programmed by simply moving the robot there and recording it. We do not need to know beforehand the exact coordinates to program them, as we can extract that information by going where things are. Online here refers to the idea of being literally on the production line, in industrial settings.
On the contrary, if we desire the robot to draw a vector image, it would be cumbersome to move the robot manually, trying to reproduce the image. As we already start from a digital file, we don't need to physically move the robot around, because the spatial information is not online around the robot, it is offline directly in a digital file. The task to be accomplished is to convert this data from one language to another, that the robot controller can understand. This usual step, of converting digital information down to a robot program, is often handled by a computer program referred to as a post-processor. When working offline, we are free to choose what data (text, 2D images, 3D objects, scripts) and workflow we use, but it always must generate a robot program written in the correct syntax used by the robot controller.
In both cases above, a shared paradigm is that a robot program is generated, pre-compiled, online or offline, and the spatial information contained in this program generally does not change. What if we do not know beforehand where this information will be, before running the robot? What if the robot has to react to live, changing spatial information, like the position of a cursor on a touchscreen, or the position of a face tracked with a camera? In this case, we can control the robot in real time. There is no more program that contains any spatial information in the robot controller, but we can stream it directly from an external source.