THE MANTA PROJECT:
Conception, Implementation, and Reflections on a Cable
Array Robot and its Interfaces
By
Brian Ballsun-Stanton
Thesis submitted in partial fulfillment of the requirements for the
degree of Master of Science in Information Technology
Rochester Institute of Technology
B. Thomas Golisano College
of
Computing and Information Sciences
March 1, 2007

Acknowledgements
I would like to thank Jon Schull, Dianne Bills, and Steven Jacobs and the rest of the Information
Technology Department at Rochester Institute of Technology.
Copyright 2007 Brian Ballsun-Stanton
All Rights Reserved

TABLE OF CONTENTS
Abstract ...........................................................................................................................1
Introduction.....................................................................................................................1
Flying a Manta with Gesture and Controller: An Exploration of Certain Interfaces in
Human-Robot Interaction ..............................................................................................3
1 Introduction ...........................................................................................................3
1.1 Three Human Robotic Interface (HRI) Conceptual Axes..........................4
2 The Manta and our Explorations .........................................................................6
2.1 Interface Explorations with a P5 Glove and Counter-Weight Driven Cable
Array...................................................................................................................6
Interface Scheme One: from Hand Position to Page Position ..................7
Interface Scheme Two: from Finger Bends to Motor Vectors...................8
2.2 Interface Explorations with an Xbox 360 Controller and Winched Cable
Array.................................................................................................................10
Interface Scheme Three: from the P5 Glove to an Xbox 360 Controller11
Interface Scheme Four: from Motor Control to Vector Control..............12
3 Discussion and Future Research........................................................................13
Acknowledgements ..........................................................................................15
References.........................................................................................................15
Technical Discussion of the Manta Project .................................................................16
Four Motor Counterweight Manta........................................................................16
Counterweight Manta Mechanical Details ....................................................18
Counterweight Manta Hardware and Software Details ...............................21
Three Motor Winched Manta ................................................................................24
Winched Manta Mechanical Details...............................................................26
Winched Manta Hardware and Software Details..........................................29
Future Research and Conclusions ...............................................................................30
References......................................................................................................................31
Appendix A - MantaClient.java ...................................................................................31

THESIS INTRODUCTION 1
ABSTRACT
We have created and flown a cable array robot based flying sculpture. This sculp-
ture, in its various versions, flew in both Rochester, New York and London, England.
This thesis both explores the construction of the flying sculpture and presents a pub-
lished paper wherein an Human-Robotic Interaction design space is proposed to
facilitate discussion of robotic interfaces.
INTRODUCTION
"Well, wouldn't it be cool if we could fly something around the atrium?" With
those words we embarked on an adventure of innovation and creation. Our goal
evolved: we wanted to make a cable array robot which could be suspended in arbi-
trary spaces. A cable array robot is formed by running a number of cables around
through pulleys mounted in corners of the room. By attaching these cables to a cen-
ter point, and then tensioning and untensioning them, we can move any object
attached to the center point anywhere within the space defined by the pulleys. In our
case, we decided to suspend a fiberglass sculpture of a manta-ray from the center
point in order to represent the artistic vision of swimming through the invisible sea
of cyberspace. The Manta Project was also an exploration of the tools and techniques
of Information Technology reapplied to an implementation of a mechanical/electrical
structure.
The artistic context surrounding the manta is best described in the introduction
to the paper about the Manta’s Human-Robotic Interfaces: "The manta installation
was intended to express the idea that modern life is increasingly embedded in an
unseen ocean of information, controlled by barely perceptible computer-controlled
constraints. We sought to capture this vision via an incongruously graceful manta
ray flying through the atrium under the control of nearly transparent computer-con-

THE MANTA PROJECT2
trolled fishing lines. Projected on to the wings of the manta would be web pages and
other digital information sniffed from local unsecured wireless Internet traffic, thus
revealing the omnipresent but invisible sea of cyberspace through which we all
swim." This "incongruously graceful manta ray" was the product of two major hard-
ware revisions, countless software updates, and hours of rapid prototyping with
K'Nex, hot glue guns, fishing line, string, and duct tape.
This thesis is organized around two major components: the paper submitted for
Gesture Workshop 2007 which explores, compares, and contrasts the 4 interfaces
created during the course of the Manta Project followed by a technical overview and
documentation of our specific implementations and techniques. The paper explores
the human-robotic interaction (HRI) implications of the manta by comparing and
contrasting the different interfaces we used during the Manta's creation within the
context of an HRI design space formed by three axes: motor mapping, frame of refer-
ence, and location. The technical overview documents the basic infrastructure of the
cable-array robot as well as the various "cute tricks" we employed while working on
the various versions of the manta.

FLYING A MANTA WITH GESTURE AND CONTROLLER 3
FLYING A MANTA WITH GESTURE AND CONTROLLER: AN
EXPLORATION OF CERTAIN INTERFACES IN HUMAN-
ROBOT INTERACTION
By Brian Ballsun-Stanton and Jon Schull
Abstract. We document and discuss a number of interface explorations conducted while building a cable-array robotic
sculpture in the form of a fiberglass biomimetic flying manta ray. Our two primary interface devices were a gesture sens-
ing Essential Reality P5 glove and a Microsoft Xbox 360 game controller. We also offer a conceptual design space
comprising three axes: mapping, frame of reference, and interface location. This design space lets us discuss and compare
all of our explorations and envision other potentially interesting interfaces.
Keywords: Data Glove, Essential Reality P5 Glove, Game Controllers, Gesture, Gesture Control, Human-Robot Interaction,
Information Visualization, Interface Mappings, Interfaces, Microsoft Xbox 360, Robotics, Teleobservation
1 Introduction
Over the past year, students and faculty at the Rochester Institute of Technology
collaborated on a cable-array robotic1 kinetic sculpture in the form of a manta ray
(Fig. 1) that maneuvered through the B. Thomas Golisano College of Computing and
Information Sciences' three-story atrium. By lengthening and shortening computer-
controlled suspension lines operators could create the simulation of the manta
swimming through the air.
The manta installation was intended to express the idea that modern life is
increasingly embedded in an unseen ocean of information [7], controlled by barely
perceptible computer-controlled constraints. We sought to capture this vision via an
incongruously graceful manta ray flying through the atrium under the control of
nearly transparent computer-controlled fishing lines. Projected on to the wings of the
manta would be web pages and other digital information sniffed [2] from local unse-
cured wireless internet traffic, thus revealing the omnipresent but invisible sea of
cyberspace [17] through which we all swim.
This paper will discuss a number of human-robotic interface issues [3], [14] that
arose during the design, construction, and programming of the system. In our
1 For more information on cable array robots, see [6], [15] For a number of videos showing the manta at various locations, go to
http://vega.it.rit.edu/~bpb9521/

THE MANTA PROJECT4
designs, we explored gesture sensing [5], [9] and joystick driven interfaces. These
explorations allowed us to for-
mulate a potentially useful
design space for the investiga-
tion of HRI issues comprised of
three conceptual axes: Motor
Mapping, Frame of Reference,
and Location. This paper will
use the design space to discuss
and compare our interface
schemes and to illuminate some
potentially interesting issues
and new interfaces for future
consideration.
1.1 Three Human Robotic Interface (HRI) Conceptual Axes
The Motor Mapping axis of our conceptual framework (Fig. 2.) has two poles: nat-
ural (human-intuitive) mapping and mechanical (machine-informed) mapping. A
puppeteer with multiple marionettes who controls them using difficult, arcane, and
precise gestures, constrained by the kinematics of dangling strings, exemplifies
machine-informed mapping. In contrast, the operator of a hand puppet benefits from
a much more natural mapping in which each finger moves a correlated body part in
a direct and intuitive manner [12]. The Motor Mapping axis thus captures the range
of cognitive effort required to translate operator intentions into machine- executable
instructions.
As illustrated in Figure 2, the two poles of the Frame of Reference axis are oper-
ator observation and teleobservation. An example of an operator-observed frame of
Fig. 1. A view of the kite-like Manta ray suspended from computer-
controlled fishing lines in the three-story atrium of Rochester Institute
of Technology's B. Thomas Golisano College of Computing and
Information Sciences. The manta is comprised of fiberglass rods with
a translucent skin upon which we can project digital images. Because
the rods are joined in a state of dynamic tension, they flex and bend
when the lines are moved, producing a lifelike swimming motion.

FLYING A MANTA WITH GESTURE AND CONTROLLER 5
reference is a radio-controlled plane whose pilot simply controls and observes the
plane from the ground. Conversely, a teleobserved frame of reference is a pilot who
adopts the plane's point of view with the aid from a wireless camera mounted in the
plane's cockpit.1 There is a pronounced difference in frames of reference when the
airplane is flying
toward the pilot. The
teleobserving pilot
perceives a right turn
of the airplane as a
turn to the pilot's
right. Conversely, the
operator-observing
pilot perceives a right
turn of the airplane as
a turn to the pilot's
left. The Frame of
Reference axis thus
captures the effect of
point of view on the
interface.
The third orthogo-
nal axis of our HRI
design space, Location, (Fig. 2.) goes from operator-at-interface, where an operator
must go to the interface to operate the device, to interface-at-operator, where the
operator's physical location is relatively unconstrained. A traditional airplane is
operator-at-interface: the pilot must be in the cockpit. In contrast, an unmanned aer-
1 This is not to be confused with first-person vs. third-person perception as discussed in the computer gaming literature [4], [13]. From our point of view,
both first and third person perception in games is teleobservation because the computer-mediated action is happening remotely and we can only per-
ceive it via the monitor.
Fig. 2. This is a three-dimensional representation of our three-axis HRI design space.
Each axis varies between the two specified poles and is orthogonal to the others. The
first axis, Motor Mapping, varies between two poles: natural and mechanical. The sec-
ond axis, Frame of Reference, varies between operator observation and
teleobservation. The third axis, Location, varies between operator-at-interface and
interface-at-operator.

THE MANTA PROJECT6
ial vehicle controlled by a free-ranging foot soldier in the field is interface-at-opera-
tor. This axis captures the effect of operator freedom on the interface.
A variety of interface control schemes can thus be located within the three-
dimensional space of Fig. 2. We will suggest below that some regions within this
space are considerably more user-friendly than other regions, and that there are
"sweet spots" in which the operator's actions take on the character of nuanced ges-
ture rather than gross manipulation. In these spots, the device becomes an extension
of the actor rather than merely the object of his actions.1
2 The Manta and our Explorations
In the process of working on the project, some additional themes arose regarding
the emerging role of the interaction designer [11], and the nature of the designer's
creative processes. The interaction designer's mission, we would now suggest, is to
help develop "natural habitats" in which pervasive, ubiquitous and ambient comput-
ing [1] allows humans to express their intentions and achieve their goals with
minimal effort and maximal efficacy. We have also come to see the interaction
designers' creative process as exploratory movement through a multidimensional
design space in search of regions where man and machine can comfortably coexist.
2.1 Interface Explorations with a P5 Glove and Counter-Weight Driven
Cable Array
Our first cable array robot's infrastructure was a counterweight based four line
system in which four computer-controlled motors and pulleys reeled fishing lines in
and out to alter the robot's position under control of an Essential Reality P5 data
glove2. Within this arrangement, we will discuss two interfacing schemes used to con-
trol the sculpture and the projections. First, we will explore a system intended to
1 The philosopher Martin Heidegger [10] has created the concepts of present-at-hand and ready-to-hand. These concepts explore the distinction between
tools becoming an extension of our mind versus the direct object of our actions.
2 For more information about the Essential Reality P5 Glove (sadly, not in production) visit: http://scratchpad.wikia.com/wiki/P5_Glove

FLYING A MANTA WITH GESTURE AND CONTROLLER 7
control the digital imagery projected on to the manta's wings. Then we will discuss
our first cable-array control scheme.
Interface Scheme One: from Hand Position to Page Position
By extracting data from an ambient Wi-Fi network, we were able to create a
large dynamic virtual mosaic in the form of a 9 x 9 matrix of web pages. By continu-
ously projecting a small part of that mosaic onto the wings of the flying manta, we
sought to create the illusion that the manta was flying through a continuous sea of
web pages, revealing them briefly as it passed. We wanted our first interfacing
scheme to control the drift of this "sea of information" independently of the move-
ment of the manta itself. To this end, operators used a P5 Data Glove to pan across
the web page mosaic. The interface software sampled the glove's position every five
seconds in an attempt to match hand location to a web page.
A natural mapping of hand-position to page-position made great sense in theory
[12], but in practice, it proved unworkable. The P5's sensor bar did not reliably detect
the LEDs embedded in the P5 glove (these LEDs were used as a perceivable position
indicator by the sensor bar), and this caused rapid and disruptive shifts in the visual
display. The P5 handled the failure in detection poorly, resulting in frequent unin-
tended cross-screen jumps of the browser window's viewing area (viewport). Less
drastic, but more frequent jitter movements were also problematic. We tried to com-
pensate for this jitter error by using error correction algorithms, including Richard
Hachem's[8] implementation of a Kalman filter[16] for P5 Glove location data, but
these filters introduced unacceptable time delays without any significant decrease in
jitter error. A second source of error was far more insidious. Again, due to the poor
sensing of the LEDs on the glove, movement away from the center of the sensor bar
caused unpredictable skewing effects, which in turn caused intuitive movements to
produce non-intuitive results. For example, the sensor platform sometimes inter-

THE MANTA PROJECT8
preted a movement up as a movement away from the sensor platform, and the corre-
lation between hand motions and page motions varied with distance from the sensor
tower.
In terms of the design space illustrated in Fig. 2, this interface scheme fits in the
forward upper right octant (referring to one of the eight spaces in the cube, just as
quadrant refers to a square). The Mapping was natural (albeit error prone) in that
the display echoed the movement of the glove. The Frame of Reference was teleob-
served, since all of the action was happening in an electronic space. Finally, the
Location was (unfortunately) operator at interface: the system failed if we moved
more than a few feet from the sensor tower and controlling computer.
Interface Scheme Two: from Finger Bends to Motor Vectors
In the second interface scheme, we chose to forgo natural mapping in favor of a
relatively easy-to-implement machine-oriented linkage based on bend sensors in the
fingers of the P5 glove. As the operator curled and extended his fingers, the interface
software sent commands to the motors to reel out, stop, or reel in. By combining
these finger manipu-
lations, the operator
could fly the manta,
after a fashion. As
seen in Figs. 3a and
3b, very specific ges-
tures were required to
approximate move-
ment in one of the
eight directions by
Figs. 3a (left) and 3b (right). Operators used the stylized instruction sheet (3a) as a
guide to the manta's flight commands while using the finger-sensing interface. The
eight patterns around the edge indicate in which lateral direction to move relative to
the operator's position. The dots indicate a bent finger while the lines indicate an
extended finger. For example, the P5 Glove (3b) is gesturing for the robot to move lat-
erally away from the operator. Inset is the gesture the operator is trying to replicate.

FLYING A MANTA WITH GESTURE AND CONTROLLER 9
putting each motor into one of its three states. The resulting movements of the
manta created the illusion of flight: complete with flapping wings.
The problems encountered with this scheme stemmed from the non-intuitive
mapping as well as from electro-mechanical issues: because of idiosyncrasies of each
motor and winch, the speeds with which lines reeled in and out frequently varied.
With the fingers in a fixed configuration, the manta would typically drift away from
the desired direction of travel. Since this scheme did not include variable speed con-
trol, corrective actions by the operator produced saw tooth motions in which the
manta lurched dramatically but drunkenly through a three-story atrium above the
heads of onlookers.
Ironically, the visual effect of this performance was considerably more graceful
than this description might lead one to expect. Partly by design, partly through trial
and error, the manta's fiberglass frame flexed and bent gracefully in response to
jerky changes in motor speed, producing a surprisingly good simulation of a manta
flapping its way through an invisible medium. Our jerky but effective pattern of
design evolution became clear here too: somewhat like the manta, we were lurching
from one corner of our design space to another, in an ongoing attempt to find an intu-
itive control scheme for the operator and a corresponding natural pattern of
movement in the manta.
This interface occupies a location in the front bottom left octant of the design
space shown in Fig. 2. Our finger-sensing interface was machine mapped. Despite
the possibility of a natural mapping from our first scheme, we chose machine map-
ping for a quicker and less error prone implementation. In general, during
development, one the fastest routes to mechanical functionality is by conforming to
machine-imposed constraints. Furthermore, our physical package was prone to fre-
quent failure due to tangled fishing lines and had no remote control functionality.
This tendency towards failure required a constant presence at the package, render-

THE MANTA PROJECT10
ing moot the lack of remote control. The debugging requirements make it fully oper-
ator observed and operator-at-interface.
2.2 Interface Explorations with an Xbox 360 Controller and Winched
Cable Array
While audiences' appreciated our early performances, our first physical arrange-
ment of motors and lines had no remote control functionality, suffered from
frequently tangled lines, and required constant attention. For this reason, and
because the P5 sensors required that we stay within a few feet of the sensor platform,
it was very operator-at-interface. We therefore decided to redesign most aspects of
the system.
We replaced the four counterweighted motors with three more powerful motors
designed to winch the lines onto spools, all within a two-chambered enclosure
intended to reduce
the probability and
viciousness of entan-
glements. We
replaced the P5 Glove
with a Microsoft Xbox
360 controller (Fig. 4.)
chosen for its easy
computer connectivity. We also developed a client/server architecture for our soft-
ware that increased flexibility and modularity of design.
With this setup, we experimented with two more interfacing schemes. In one
scheme, we adopted a machine-mapped interface metaphor similar to the one we had
previously used: three axes of joystick movement (up-down on one joystick, and up-
down and left-right on the other) mapped to each of our three motors. In the last
Fig. 4. A picture of the Microsoft Xbox 360 controller driving the manta diagonally
upwards to the operator's left.

FLYING A MANTA WITH GESTURE AND CONTROLLER 11
scheme, the mapping was considerably more natural since movements of the right
joystick made the manta move along the horizontal plane and vertical movements of
the left joystick controlled the manta's altitude. We also used other buttons on the
controller to control other aspects of the software.
Interface Scheme Three: from the P5 Glove to an Xbox 360 Controller
Replacing finger-bends with joystick movements and implementing variable
motor speed controls, gave this interface scheme much more nuanced control of the
manta's speeds. On the other hand, the arrangement still required that the operator
continuously translate desired changes in the manta's location to desired changes in
line length, and translate changes in direction to changes in winch speed. Due to the
shift from four lines to three, this control scheme was virtually unusable. While the
interface was more ergonomic, the mappings now required the operator to input frac-
tional speeds: something almost impossible to do on a real-time basis.
Much more successful was our adoption of the client/server architecture and use
of the more portable Xbox 360 controller. Now, the operator could move around, con-
nected wirelessly to the server controlling the motors. This allowed the operator to
view the manta and the scene from various perspectives. While true teleobservation
escaped us (as the control scheme could not orient itself to the manta's frame of ref-
erence), we were no longer tied to the motors as in previous schemes.
This interface scheme can be located firmly at the center of the bottom four
octants. While this was fully machine mapped, as discussed above, the increased
freedom of the client/server architecture allowed us to divorce ourselves from being
completely operator observed and operator-at-interface. While it was not fully teleob-
served, it was much easier to "think oneself" into the Manta's Frame of Reference.
While it was not fully interface-at-operator, the increased freedom afforded by the
client/server architecture, a long cable connecting the controller to the computer and

THE MANTA PROJECT12
better tangle-proofing meant that the operator's Location was considerably less oper-
ator-at-interface than before. At heart, while these changes reduced the amount of
control over the manta, they increased the operator's sense of control. Fortunately,
this interface exploration leads us to a final interface scheme that allowed the oper-
ator to think about manta movements rather than motor movements.
Interface Scheme Four: from Motor Control to Vector Control
Our last interface scheme allowed us to move from machine-mapped thumb
movements to naturally mapped manipulations: thumb movements that translated
intuitively into manta movements and corresponded well with the operator's natural
perception of manta movements. By mapping the three axes of joystick movement
(Fig 4) to the three spatial axes of the rectangular atrium and by mapping degree of
joystick deflection to the speed of the manta, it became possible to use thumb move-
ments that made sense. For example, to move the manta away or to the right, the
operator could push his or her right thumb away or to the right. Of course, doing so
required that the computer perform the trigonometric computations to convert these
gestures into changing rates of winch rotation for the three motors. That however, is
precisely what gesture recognition systems and human-oriented interfaces must do:
allow human operators to express intentions with intuitive movements, and to get
intuitive feedback from those movements.
Indeed, while this last scheme was far from perfect, we found that we could over-
come a variety of sins by the combination of intuitive movement and intuitively
perceived feedback. For example, while we were still coping with mechanical idiosyn-
crasies as well as with variations in friction from one line to another and from one
moment to the next, compensating for these variations was relatively easy and
unconscious on the part of the operator. Thus, much as an automobile driver pushes
down or pulls back on an automobile accelerator to compensate for fluctuating head-

FLYING A MANTA WITH GESTURE AND CONTROLLER 13
winds, the manta operator simply pushes the appropriate joystick more or less force-
fully in the intended direction to compensate for mechanical and other fluctuations
in the system.
This latest scheme was a major advance over the prior interface because it
allowed the operator to gesture "I want it to go that way," with more or less vigor.
The scheme is in the middle of the top four octants, because it adds a relatively nat-
ural mapping to the moderately operator-observed and moderately
interface-at-operator character of the previous scheme. With a wireless Xbox 360
controller, or a wireless Wii remote controller, we expect to move even farther in the
interface-at-operator direction.
3 Discussion and Future Research
Several general observations seem pertinent. We suspect that some quadrants in
the design space are more promising when used in certain types of projects. In per-
formative robotics, our own experience leads us to speculate that as an interface
approaches the natural and interface-at-operator poles, the operator will feel more
like a performer performing than an operator controlling, and the robotic system will
feel more like an extension of the human body. We can report, for example, that dur-
ing one deployment [13], the operator had occasion to move the manta down floor
level and have it interact with human dancers. Although the operator was twenty
feet way from the dance floor, the experience of interacting with the other dancers
was more salient than the experience of interacting with the machinery or the manta
itself.
With regard to our framework, we should acknowledge that intuitiveness may be
in the eye of the beholder, and that is may not always be obvious in advance. In addi-
tion, there may well be additional orthogonal dimensions beyond the three we have
identified. However, even if it is not a comprehensive taxonomy, the framework may

THE MANTA PROJECT14
be useful for exploring and discussing alternative schemes - as well as for creating
new ones. For example, it was only when we envisioned a fully interface-at-operator
interface that we began thinking about a performance scenario in which an operator
would perform on the dance floor with the manta they were controlling.
We should also note that we are still far from realizing our ideal visual perform-
ance. Thumb twitching while tethered to a computer is likely to be, and to feel, less
expressive of the performer's intentions than arm waving and body swaying while
roaming freely. We intend to explore this question using a wireless Nintendo Wii
Remote or a Gyration Air Mouse, both of which promise a natural, interface-at-oper-
ator experience that should be as reliable (within receiver range) as the Microsoft
Xbox 360 controller.
Finally, we would like to defend explicitly the proposition that a manta ray danc-
ing at a disco (and other socio-technical scenarios not usually encountered in
engineering labs) provides a remarkably good opportunity for exploring human-com-
puter gestural interaction and for discovering novel engineering challenges. For
hundreds of thousands of years, living creatures have been interacting via gesture-
based communication. This is a time-honored working model with much to
recommend it.
The next century will distinguish itself by the emergence of non-biological robots
and ambient, pervasive computing infrastructures. These emergent technologies are
increasingly going to be a significant part of the human environment. We believe
that engineers, interaction designers, and their clients will have more success (and
fun) if they move away from machine-constrained and human-constraining control
schemes and strive to study, emulate, simulate, and situate their work in what peo-
ple do naturally. If we can get a robotic manta to dance, and to be welcome at a party,
we will have created something that is strange, yet intriguing and socially empower-
ing.

TECHNICAL DISCUSSION OF THE MANTA PROJECT 15
Acknowledgements
We would like to thank Dianne Bills, Steven Jacobs, and the Information
Technology Department's Innovation and Information class. Furthermore, we would
like to thank the Golisano College of Computing and Information Sciences as well as
the First International Conference on Digital Live Art for allowing us to fly our
manta in their spaces. Finally, we would like to thank the Department of Planning
and Natural Resources, Division of Fish and Wildlife, of the Virgin Islands for their
line drawing of a Manta Ray, used here with permission.
References
1. Abowd, G. D., & Mynatt, E. D.: Charting Past, Present, and Future Research in Ubiquitous Computing. ACM Trans. Comput. -Hum. Interact., 7 (2000)
29-58
2. Ansari, S., Rajeev, S. G., Chandrashekar, H. S.: Packet Sniffing: A Brief Introduction. Potentials, IEEE, 21 (2002) 17-19; 17- 19
3. Benko, H., Ishak, E. W., Feiner, S.: Cross-Dimensional Gestural Interaction Techniques for Hybrid Imrnersive Environments. vr, 00 (2005) 209
4. Bruce Thomas, Ben Close, John Donoghue et al.: First Person Indoor/Outdoor Augmented Reality Application: ARQuake. Personal and Ubiquitous
Computing, V6 (2002) 75-86
5. Chalhoub, N. G.: Control of a Leadscrew Driven Flexible Robot Arm. (1986)
6. German, J. J., Jablokow, K. W., Cannon, D. J.: The Cable Array Robot: Theory and Experiment. 3 (2001) 2804-2810 vol.3; 2804- 2810 vol.3
7. Gershon, N., Eick, S. G., Card, S.: Information Visualization. IEEE Comput. Graphics Appl., 17 29-31
8. Hachem, R.: Kalman Filtering for P5.
9. Hasanuzzaman, M., Zhang, T., Ampornaramveth, V. et al.: Gesture-Based Human-Robot Interaction using a Knowledge-Based Software Platform.
Industrial Robot, 33 (2006) 37-37-49
10. Heidegger, M.: Being and time. Harper & Row, (1962)
11. Jan O. Borchers ER -: A Pattern Approach to Interaction Design. AI & Society, V15 (2001) 359-376
12. Norman, D.: The design of everyday things. Doubleday, (1990)
13. Ryan, M.: Beyond Myth and Metaphor - the Case of Narrative in Digital Media. Game Studies: The international Journal of Computer Game
Research, 1 (2001)
14. Stefan Waldherr, Roseli Romero, Sebastian Thrun: A Gesture Based Interface for Human-Robot Interaction. Autonomous Robots, V9 (2000) 151-173
15. Usher, K., Winstanley, G., Carnie, R.: Air Vehicle Simulator: An Application for a Cable Array Robot. (2005) 2241-2246; 2241- 2246
16. Welch, G., & Bishop, G.: The Kalman Filter.
17. Wertheim, M.: The pearly gates of cyberspace: A history of space from dante to the internet. W. W. Norton \& Co., Inc, New York, NY, USA (1999)

THE MANTA PROJECT16
TECHNICAL DISCUSSION OF THE MANTA PROJECT
While the paper presented above explored the relative merits of the various
interfaces we constructed over the course of the manta project, attention must also
be paid to the technical aspects of the Manta. In the following section, a technical his-
tory of the manta and its construction will be provided.
Four Motor Counterweight Manta
This first manta was the creation of a number of individuals from the 2006
spring quarter's Innovation and Invention class, a few interested members of the
local robotics club and a few local artists. The basic concept informing this version
was simple: we wanted our motors to be able to reel and unreel lines so as to position
our object anywhere within the bounds of the lines. However, we were working under
a number of limitations. Our two major mechanical limitations, and their solution,
were found in our motors and a lack of known sensing techniques. We unfortunately
had far more troubles with the hardware and software. Our major challenges in this
version centered around the Essential Reality P5 Glove and interfacing with the
phidgets and victor motor controllers.
The center point of our robotic system was the fiberglass manta Ray, which,
due to an innovative jointing system using using K'Nex and hot glue, was able to flex
and bend with surprising realism. According a dis-
cussion with to K'Nex Industries Customer
Support, K'Nex are: "... a plastic construction toy
product of rods and connectors that fit together to
make 3D shapes." (K’Nex 2007) The fiberglass
manta had three major sections: two wings and a
spine. Each wing was formed using a system of
K'Nex joints joining three fiberglass rods (Figure 1). These rods, due to the nature of
Figure 1. A K’Nex connector and fiber-
glass rods forming a wing-tip.

TECHNICAL DISCUSSION OF THE MANTA PROJECT 17
their joints, were placed under tension to produce a pleasing wing-like shape. The
fiberglass/K'Nex hybrid also allowed us to rapidly prototype Manta shapes as each
fiberglass rod could be arbitrarily manipulated without effecting the whole structure.
Two of these wings joined together with a supporting arched spine to provide an
attachment points for the cable array. The underside of the manta was covered with
a translucent and lightweight plastic sheet to provide a skin. Our original plans were
to project assorted digital images onto this skin so as to evoke the sea of cyberspace
metaphor mentioned above. The spine's
attachment point was formed by still more
K'Nex hot glued into place, with the addition
of weighted washers for improved maneu-
verability. The use of K'Nex in this instance
allowed for each attachment and detach-
ment. Here, the quick attachment
mechanism connected to a circular K'Nex
disk with one of the four high-test fishing
lines attached equally around its circumfer-
ence. These lines ran to four points around
the Golisano college atrium, spaced so as to
define the largest possible rectangle given the space. Smooth enamel rings were used
in lieu of pulleys here, to constrain our fishing lines to their desired paths. These four
lines were routed around the corners of the atrium to allow them to converge on our
motors. Each line was connected to its associated motor by winding it approximately
three times around a pulley screwed to the motor's axle. This winding constituted a
major point of failure in this version, since any momentary lapse of tension would
cause the line to spring away from the pulley and usually get caught on the axle.
Figure 2. Illustration of one of the four lines form-
ing the cable-array. In this illustration, the line is
routed from the Manta along the balconies, across
the atrium proper, and then to the counterweight.
The counterweights were held via a separate line
stretched across the atrium. Illustration by
Catherine Lee, used with permission.

THE MANTA PROJECT18
From here, the lines were routed through more pulleys to four hanging counter-
weights. (Figure 2)
The motors were controlled through four Victor 883 Servo-to-DC motor con-
trollers. Three large power bricks were ganged together and routed to these four
motor controllers. Each controller received servo TTL
commands from a PhidgetServo device. This device took
USB input from the computer and translated it into the
appropriate TTL signal for each motor. Signals were gen-
erated through a Java program expressly written for the
purpose. The program's main source of input was an
Essential Reality P5 Glove. The entire P5 Glove system
was a glove connected to a sensor bar connected to the
host computer. (Figure 3)
This system was able to detect the approximate loca-
tion and rotation of the glove as well as finger bends. As
will be discussed later the rotation and location sensing
capabilities left much to be desired. Each finger on the
glove was mapped to each of the four motors while the thumb was a safety all-stop
switch. Each finger/motor combination had three states: all stop, forwards full and
backwards full. By combining chords of these combinations, the lines could be reeled
in and reeled out, resulting in movement in the approximate direction of the opera-
tor's intent.
Counterweight Manta Mechanical Details
After defining our problem, much of our initial design methodologies consisted of
an iterative process where we created very quick prototypes with K'Nex, pulleys, and
fishing line. This iterative rapid prototyping methodology accounts for much of our
Figure 3. P5 Glove and Sensor
Bar. The glove is able to sense
it’s position and rotation rela-
tive to the sensor bar via
infrared cameras in the sensor
bar. Through the Glove’s con-
nection to the sensor bar, the
glove receives power and
transmits finger bend and but-
ton-press information.

TECHNICAL DISCUSSION OF THE MANTA PROJECT 19
success, considering our low initial knowledge of the engineering necessary to com-
plete the task. In this regard, we had three major mechanical phases: crafting,
stringing, and debugging the installation.
Our crafting phase involved evolving a functional manta sculpture and a func-
tional motor assembly. We were looking for a manta sculpture that was easy to craft,
easy to changed, and had the desired biomimetic flexing qualities suggested by the
fiberglass rods. The initial prototypes used drilled poker chips, washers, and other
ad-hoc bits of miscellany that seemed appropriate for the task. Once a box of K'Nex
was found at a local garage sale, the plastic gears and rods immediately suggested a
design methodology. By tipping each fiberglass rod with part of a K'Nex axle (Figure
1), we were able to utilize the K'Nex prefabricated gears
to great success. Many experiments followed, exploring
the impacts of size, reinforcement, rod redundancy and
weight on the manta's biomimetic characteristics. Once
an approximate design was found, further experiments on
skinning materials followed. By hot-gluing sets of K’Nex
gears together, we were also able to create a simple, yet
stable spine that was compatible with the K’Nex tipped
fiberglass of the wings (Figure 4).
Our motor assemblies also went through a number of
rapid prototyping revisions. Here, the many revisions
were to find solutions to two major problems: the motors were too weak to lift the
manta at any acceptable speed and when stopped, the axles did not lock in place,
allowing the manta to drift slowly back down as its weight caused the motor to
unreel. After many unsuccessful trials, we finally discovered that a counterweight
arrangement. This arrangement solved both of our problems: as the force required to
move the somewhat balanced fishing line was much less, we were able to achieve
Figure 4. A picture of the three
white gears with external con-
nectors which allowed for
wing edge connection points
and for a double-spine to be
held solidly by cementing
fiberglass rods in the intersti-
tial spaces inside the gear with
hot glue.

THE MANTA PROJECT20
acceptable speeds with the test motor. Since the manta and counterweight balanced
each other out, the lack of axle locking did not cause us any problems.
A major flaw of this system was its response when the amount of tension in the
system changed. An unfortunate characteristic of the fishing line system emerged:
all of our pulleys, enamel rings, and counterweights fouled up when the entire sys-
tem was not under tension at all times. Here the same rapid prototyping process as
above came into play as we built elaborate constructions in attempts to solve the ten-
sion problem once and for all. While selection pressure was fierce, we did manage to
arrive at a design which, while still requiring tension, had a minimal number of
points of failure and was somewhat tolerant of slight lapses of tension. The enamel
rings, while commendably low-friction, were not frictionless. As such, the high num-
ber of routings introduced a certain amount of "give" in the system. This "give" was
most readily apparent when any motor swiftly changed direction. As the pulley spun,
the three loops that normally secured the line to the motor's pulley widened in diam-
eter, quickly exceeding the lip of the pulley. When tension reasserted itself, caused
usually by the changing of the direction of manta travel, these loops would suddenly
tighten on the axle connecting the pulley to the motor. Careful work by the operator
would the be necessary to untangle the line.
Curiously, we also had difficulties when the lines were overly tense. K'Nex, being
cheap, simple, and non-scientific products formed out of an Celcon acetal copolymer
produced by Ticona (Glickman et. al., 2006) easily deformed due to stresses in the
fishing line. In one instance, a deep groove was cut as a pulley spun against an
extremely taut line caused by a stuck counterweight. In this version, while the coun-
terweights were clearly necessary, they were poorly balanced against each other and
of the weight of the manta. This poor balancing act further complicated the design,
adding errors and additional friction. The counterweights and enamel pulleys also
added to the difficulties found in stringing, since each pulley had to be tied in place

TECHNICAL DISCUSSION OF THE MANTA PROJECT 21
and each counterweight had to be situated in an out of the way spot with large ver-
tical clearance.
Counterweight Manta Hardware and Software Details
Programming the software and configuring the hardware that would support the
web of cables presented us with an interesting set of challenges: interfacing with the
motors and getting consistent information out of our Essential Reality P5 Glove, a
motion sensing glove worn on the right hand and connected to the computer through
an USB-enabled attached sensor bar.
After some research and discussions with our robotics consultants, the decision
to use the Victor 883 Servo-to-DC motor control devices was easy. According to
Innovation First, the Victor 883's manufacturer: "The "Victor" is an electric motor
speed controller. It is used to vary the speed of an electric motor in a smooth progres-
sion anywhere from full forward to off (neutral) to full reverse. You connect your
battery to one side of the Victor, and your motor to the other side. Then, using pulse
width modulation signals plugged into the input you can control the speed and direc-
tion of the motor." (Innovation First, 2007) The computer-to-Victor interface had
many possible solutions. We were faced with two choices: using a USB-driven
Phidget, or using a serial port driven device that performed the same functions.
Despite extensive research implementing serial communications with a variety of
devices, our robotics consultants failed to deliver a custom circuit from which to con-
trol the motors. Phidgets, produced by Phidgets Inc are: "... an easy to use set of
building blocks for low cost sensing and control from your PC. Using the Universal
Serial Bus (USB) as the basis for all Phidgets, the complexity is managed behind an
easy to use and robust Application Programming Interface (API)." (Phidgets, 2007)
Faced with an impending deadline, we then chose to use the PhidgetServo, which
took instructions from the included API and translated them into TTL signals suit-

THE MANTA PROJECT22
able for driving servo motors. We also chose, at that time, to attempt to connect sen-
sors to our fishing line. A number of sensing
methodologies were tested. Our final sensing attempt
involved passing the fishing line running past each motor
to a custom wheel, ground away along one side. (Figure 5)
This asymmetrical wheel then, when the fishing line was
run past an attached pulley, would rotate causing two
snap action switches to toggle. The output of these events
was sent to a PhidgetIO board, produced by the same
company above which provided a computerized source for
detecting basic analog and digital input. However, this
sensing strategy was defeated due to a lack of significant
temporal resolution by the PhidgetIO board, it not being
capable of registering the hundreds of events (as each
switch was toggled on and off per each rotation of each
wheel of each motor) emanating from the sensors.
Our P5 Glove was capable of sensing 6 axes of movement (Up/Down, Left/Right,
Forwards/Away, Pitch, Yaw, and Roll) as well as finger bends and button presses.
(Figure 3) The glove system was comprised of the glove itself, a sensor bar, and the
interpretation software located on the computer. The 6 axes were sensed by the sen-
sor bar as it caused each of the infrared LEDs located on the glove to blink in a
distinct pattern. Unfortunately, poorly manufactured hardware coupled with undue
interference from external infrared sources induced error. We had two major sources
of error: jitter and skew. From various observations, we inferred that there were two
major types of error and one major skewing problem. The small-scale jitter we sus-
pect is due to camera noise as the CCDs in the sensor bar detect other infrared
sources and generate internal noise. The large-scale jitter was due to mis-observing
Figure 5. Picture of the
Counterweight Manta’s sensor
wheel. By passing the line
around the pulley, movement
of the line caused the pulley to
rotate, thereby rotating the
asymmetrically mounted
wheel. This wheel then acti-
vated, through its rotation,
two snap action switches.
Output from these switches
was sent to our PhidgetIO
device and thereby to the com-
puter. Temporal sensing
limitations of the PhidgetIO
device (not pictured) caused
this sensing methodology to
fail.

TECHNICAL DISCUSSION OF THE MANTA PROJECT 23
the glove LEDs. These mis-observations resulted in reported positions that seemed
(when mapping the glove's position to a virtual hand in the screen), to cause the hand
to jump to the other side of the screen. We tried two fixes. Our first attempts explored
simple averaging methodologies, trying to minimize the feelings of an nonreactive
interface and minimizing jitter. However, we were not able to find a satisfactory
averaging span of time where we had both a responsive interface and minimal jitter.
We then moved to the Kalman Filter, as implemented for the P5 Glove by Richard
Hachem. This filter managed to satisfactorily correct for the jitter, which exposed the
other source of error: skew.
While up to this point the glove had served us poorly, we chose to continue devel-
oping for it for a number of reasons: we had invested too much time in exploring its
flaws, we were under time pressure from a planned performance, and none of our
other input methodologies easily available (mouse and keyboard or their equivalents,
in the main) could offer simultaneous and synchronized three or four channel input.
Our one viable option at this point was to take the fairly reliable input from the P5
Glove's finger bend sensors and map it to each motor. This motor mapping would
prove to be sufficiently reliable for us to use it as part of our first real performance.
However, this finger-bend-to-motor-mapping solution was not without its flaws.
These flaws centered around the nature of the interface. In order to cause the manta
to move in a direction relative to the atrium, each motor would have to reel line in or
out. Since each finger's extension or curl was mapped to a specific motor reeling in
or out, a specific gesture had to be developed for each general direction. These ges-
tures required precise finger control of all the fingers on the operator's right hand
simultaneously. Furthermore, as these gestures focused on simple machine interac-
tion, in lieu of simple operator interaction, the gestures were hard to learn and
unintuitive.

THE MANTA PROJECT24
These unintuitive gestures complicated an already complex, uncalibrated, sys-
tem. Our four motors reeled the line at different rates for many reasons. At root,
these different rates caused unintended vectors to be introduced to the manta's
movement. These unintended vectors were far too large to be canceled out by adjust-
ing the gestures (as only a very finite set of gestures were supported, due to interface
difficulties), thereby requiring frequent position adjustments. This produced a saw-
tooth movement as the manta struggled to hold to the desired vector. Despite these
difficulties, the first version of the manta flew successfully.
The first official flight of the Manta was at the B. Thomas Golisano College of
Computing and Information Sciences' Digital Arts Competition in the spring of 2006.
Using the four motor counterweight system and the P5 Glove, the fiberglass manta-
ray skeleton, covered by a translucent light plastic skin cavorted above the heads of
the audience. This "performance" was marked by frequent interruptions. The most
frequent by far were snarls in the fishing line, followed closely by interface problems
with the P5 glove. Despite these hindrances, however, there was a strong audience
response to this flying sculpture. This response then prompted us to submit the
Manta to a number of conferences for display and discussion. An invitation to
(re)Actor, the First International Conference on Digital Live Art followed.
Three Motor Winched Manta
The success of the first version prompted a summer project: a new version, stur-
dier with a better interface and better hardware would make for an excellent
performance. With the deadline of the (re)Actor conference in London looming over
our heads, we set out to create a completely new second version of the Manta, incor-
porating the lessons we learned the first time around. This project had a number of
goals. In essence the goals were for better mechanical performance and a vastly
improved interface. Our planned upgrades allowed us to abandon our former motors

TECHNICAL DISCUSSION OF THE MANTA PROJECT 25
for much more powerful, if less precise models and the P5 glove for a Microsoft Xbox
360 controller.
In this iteration, we decided that in lieu of going with a counterweight based sys-
tem, we should upgrade to more powerful motors capable of acting as winches. We
found our salvation, here, in cheap drill motors. Not only were these drill motors,
once stripped from their drill housings, compatible with our preexisting power solu-
tion, but their unique profile and drill chuck attachment mechanism proved very
helpful in our prototyping and our final design. Just as our motors evolved, so did our
stringing methodology. Instead of complicated enamel pulleys, we moved to simple
carabiners attached with cable ties. By removing the complicated webs of strings and
the need for counterweights, we reduced the time it took for stringing. As the
mechanical portions of our project improved, we found more time to upgrade our soft-
ware and its interfaces. In this instance, we moved from the frequently recalcitrant
P5 Glove to the Xbox 360 controller. The interface upgrades focused on allowing the
human operator to give movement instructions relative to the manta as a whole
instead of issuing instructions to each motor individually. By offloading the mathe-
matical transforms necessary in order to interpret intent into motor instructions
onto the computer, made for a far less error prone, more easily controlled, and more
artistic manta performance.
In this version, while we kept the phidget and power brick backend, we switched
out our Victor 883 motor controllers for the much more compact and quiet Scorpion
XL controllers produced by Robot Power. According to Robot Power's product descrip-
tion: "The Robot Power Scorpion XL is a flexible high-performance two-channel speed
controller for small robots in the one to twelve pound class." (Robot Power, 2007) By
moving from the bulky, single-channel Victor 883 to the much slimmer, dual-chan-
nel Scorpion XL controllers, we were able to fit all of our controlling electronics inside
the fabricated wooden case providing a better visual aesthetic for the case as well as

THE MANTA PROJECT26
increasing portability dramatically while preserving the necessary Servo command
to DC power routing functionality of the Victor 883 controllers. (Figure 6) One quirk
of these controllers, however, is that the cal-
ibration sequence mated each Scorpion XL
controller to a specific pair of output ports on
the PhidgetServo, causing errors if the con-
nector order was flipped. These controllers
routed power to our three drill motors. A
winch, consisting of a spool for a fishing line
mounted on a metal shaft spooled each of
the three lines in and out. Here we found
our only major mechanical problem: line tension. Once again, even in this version,
we found line tension to be an extreme problem. Due to the nature of the fishing
lines' geometry, each one of the three lines somewhat frequently lost tension. Tangles
in this system formed since lines did not move in response to motors unspooling. As
the motor unspooled but the line remained slack, the slack line formed a larger cir-
cle around the spool. When tension was suddenly applied again, this large circle
frequently tightened around the axle connecting the spool to the drill chuck, causing
a snarl. These snarls, inevitably had to be untangled by hand, causing a pause in the
performance.
Winched Manta Mechanical Details
Here, having solved most of our major problems with the prior version, our
mechanical evolution focused on making the system more robust and less prone to
snarls. We also took advantage of the additional time here to redesign the manta
sculpture. The robustness evolutions explored rewiring wires and adding various
connectors to increase safety and portability. The main change here is that the power
Figure 6. Picture of the internal electronics of the
Winched Manta. Shown are a PhidgetServo USB-to-
TTL controller and two ScorpionXL controllers
which convert TTL servo commands received from
the PhidgetServo into proportional direct current
received from our power transformers.

TECHNICAL DISCUSSION OF THE MANTA PROJECT 27
bricks, in lieu of being dedicated per-board (one board having 2 power bricks and 2
motors) we re-soldered the connections so that each board drew from all three bricks.
We also mounted the drill motors and circuits in a wood and Plexiglas box. This
mounting allowed for easier carrying and a dramatic reduction in noise with the
addition of side panels. This box also allowed us to experiment with a number of
snarl reduction methodologies. We tried everything from fishing poles to clear PVC
piping. (Figure 7) All of these experiments
were attempts to add constant tension on the
line, so that momentary lapses of tension
wouldn't create snarls. While some of these
methods were somewhat efficient, all of them
suffered from being bulky, cumbersome, and
they had a tendency to fail at odd times. Most
successful of our snarl reduction experiments
was the practice of enlarging the winching
cylinders. By extending the base of the cylin-
der to the Plexiglas divider separating it from
the drill motor, we dramatically reduced the possibility of the fishing line slipping
over the (now much expanded) edge of the winch and onto the shaft. Minimizing the
shaft length above the cylinder reduced the amount of shaft that the line could
become caught on.
The manta redesign was a virtue made of necessity. The manta, while light, was
extremely large and couldn't collapse for transport. Therefore, when we traveled to
London we took advantage of the shipping constraints to streamline the manta's
wing-shape and spinal connectors, replacing the previously bulky 8 piece hot-glued
monstrosity with a much more robust 3 piece connector.
Figure 7. Side view of the Winched Manta’s case:
shows a PVC tube and expanded cylinders for
the winches. The PVC tube was an experiment in
which we tried to create a system to maintain a
constant tension for, what we hoped, was a criti-
cal moment. More successful, however, were the
PVC pipes ended by CDs. In contrast to our ear-
lier attempts, these larger winching platforms
reduced tangles by allowing the slack line to
retighten over the spooling cylinder instead of
the shaft.

THE MANTA PROJECT28
The test of our carabiner based line routing system came when we tried to string
the manta in a four story octagon. While we had strung the manta in the extremely
accommodating space of the GCCIS atrium, we were faced with a octagonal space
filled with statuary and hanging chandeliers. This, unlike our prior adventures,
required the creation of an artificial web of support lines to provide a triangular
prism that wouldn't be obstructed by any of the chandeliers, statuary, lights, or other
performers. As seen in Figure 8 we constructed a synthetic triangle from a network
of fishing-lines hung inside the smaller octagon defined by the chandeliers. As our
setup was in area four, we found it best to run lines up from all three motors, around
the edges of the octagon until it hit the point
nearest the corner of the triangle it was
intended for. In this fashion, we were able to
mostly ignore the obstacles that the hanging
chandeliers presented. An important note in
this instance is to prepare the entire web of
lines before trying to raise it into place. This
allows dimensions to be set before effort is
expended in hanging the contraption. Also,
because the triangular prism exists in mid-
air, it is essential to also run all the
important control lines for the cable-array
robot itself before raising the web. However,
once raised and with the interface properly adjusted, the system proved its worth:
the manta was able to interact with a number of dancers and respond in a manner
suggestive of a living creature.
Figure 8. Illustrated diagram of the Octagon at
Queen Mary's University in London. The large
black bordered circles are the hanging chandeliers.
The thin lines between them are the internal
boundaries of our web which created a smaller, but
usable, synthetic triangular prism within the chan-
deliers. In order to maintain the triangle’s position,
each corner of the triangle was anchored to the sur-
rounding walls with two lines.

TECHNICAL DISCUSSION OF THE MANTA PROJECT 29
Winched Manta Hardware and Software Details
The true innovations of this iteration of the manta, however, were in our soft-
ware controls. We had three specific innovations here: a client/server framework, a
transfer to a robust and known controller, and a transfer from a machine-oriented
interface to a user-oriented interface. Our client/server framework allowed us to
divorce the controlling computer from the operator's computer. Specifically, by allow-
ing laptop-to-laptop wireless communication, the laptop serving the joystick could be
on a separate floor or room from the laptop serving the phidgets. This increase in
operator freedom, while not realized in the London trip due to laptop constraints,
both enabled the manta operator to function more as a performer and allowed the
bundle which consisted of the robotics machinery to be increasingly hidden.
The Xbox 360 controller had a number of virtues: its measurements were reliable
from all of its buttons and analog sensors, it sported a USB interface, allowing for
easy computer operability, and it had dual joysticks. By enabling the expression of a
three dimensional vector by manipulating the dual joysticks, we allowed the human
operator to express an intended direction as a direction and leave the translating to
the computer.
The translating algorithm broke the three dimensional vector formed by the
three observed axes on the joysticks into three separate vectors: X, Y, and Z. The code
of this program is available in Appendix A. The algorithm began by setting aside the
Z-axis input for later manipulation. Then, by reading the position of the X/Y stick,
the algorithm could plot the position of said stick. From that position, we then found
the angle the stick was pointing. By adding this angle to the calculated angles of each
of the lines, we changed the angle's frame of reference from the Xbox 360 controller
to each motor. By then taking the cosine of that angle in context to the motor in ques-
tion, we were able to determine what "percentage of Y" the calculated angle had. This
percentage of Y translated directly, as a percentage modifying the maximum speed

THE MANTA PROJECT30
of the motor. The Z axis was then added to these instructions, as each motor would
have to operate in the same direction for vertical movement. While this transforma-
tion was not perfect as the system did not reliably know where the Manta was at any
given point in time, and therefore could not compensate for its location and since
each motor had variable amounts of pull at a constant voltage, the system could not
fly itself. However, by including human feedback in the loop, a credible imitation of
straight flight was achieved.
FUTURE RESEARCH AND CONCLUSIONS
While this second iteration of the manta's design proved that a much more reli-
able ultra-lightweight cable-array robot could be achieved, the next version has three
major challenges: the interface, the movement space, and reliability. While the Xbox
360 controller offers a credible interface scheme, some prior experience with gaming
controllers was required. Furthermore, since the system required translating of a 3-
dimensional vector into two two-dimensional vectors, the interface was not
completely natural. Therefore, an exploration of the Nintendo Wii's interface is indi-
cated, to provide for a controller that can be used by any audience member who
happens to pick it up. The third version also will use a four-motor, winch-based sys-
tem, as the most common performance venue is a square. This four-motor system
would also require extensive effort to make stringing possible and easy in most arbi-
trary venues, as well as exploring an outdoor installation which would use a far
larger "zone." Furthermore, by continuing the interface explorations in novel devices,
the theoretical framework will allow us to compare and contrast those interface
explorations with prior attempts, both helping to prove the validity of the framework
and allowing us to assess the relative virtues of each new interface.

THE MANTA PROJECT32
}
//Network initialized, now declaring all kinds of variables.
String inputLine, outputLine, sensor[] ={"0","0","0"};
boolean started=false, secondStickMode=true;
boolean motorStarted[] = {true, true, true};
long commandTime[]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
for (int i=0;i<21;i++)
commandTime[i]=System.currentTimeMillis();
boolean flip=false;
boolean cal=false;
boolean lclick=false, rclick=false,sclick=false;
long curTime=0;
int lockedSpeed[]={0,0,0,0};
int lastSpeed[]={0,0,0,0};
boolean lockedTrigger[]={false,false};
//atrium measurement 617x339 ft 308.5 169.5
/*the motor angle variables are where we input the exact coordinates of the loca-
tions of the *final set of pulleys* before the lines connect at the manta. This allows the magic
to happen with the Xbox controller */
double motorAngle[]={Math.atan2(-308.5,-
169.5),Math.atan2(0,169.5),Math.atan2(308.5,-169.5)};
double rotation=-24.6; //This aligns the controller with where the operator is
//standing.
//angle rotation, add arbitrary degrees * rad conversion to correct for controller
rotation.
/*
for (int i=0;i<motorAngle.length;i++)
motorAngle[i]+=-90*0.0174532925;
*/
for (int i=0;i<3;i++)
motorAngle[i]+=2.0;
//SOHCAHTOA dictates that I take the length first and the height second
// The main instruction loop. It parses the incomin input with a regex, and does various button
//operations.
System.out.println("while reached");
while (((inputLine = in.readLine().replace('+',' ')) !=
null)&&(!inputLine.equals("ByeAll"))) {
curTime=System.currentTimeMillis();
//System.out.println(inputLine+" "+inputLine.matches("([, +-]+[0-9]{4}){5},
Butt.*"));
if (inputLine.startsWith("Sensor"))
sensor = inputLine.substring(7).split(",");
if (!inputLine.matches("([, +-]+[0-9]{4}){5}, Butt.*")) continue;
String mungedInputLine[] = inputLine.split("(Buttons pressed: )|( Hat: )");
String inArray[]={"","","","","", "","","","","", "","","","","",
"","","","","", "",""};
String part1IL[]=mungedInputLine[0].split(", *");
String part2IL = mungedInputLine[1];
String part3IL[] = mungedInputLine[2].split(", *");
inArray[21] = part2IL;
inArray[0]=part1IL[0];

APPENDIX A: MANTACLIENT.JAVA 33
inArray[1]=part1IL[1];
inArray[2]=part1IL[3];
inArray[3]=part1IL[4];
inArray[4]=Integer.toString(Math.abs(Integer.parseInt(part1IL[2])));
inArray[5]=part1IL[2];
/*
On the *PC* these are the inputs that correspond with the Xbox controller.
This changes on a mac.
Left-Analog X = 0
Left-Analog Y = 1
Right-Analog X = 2
Right-Analog Y = 3
Left-Trigger Ana = 4
Right-Trigger Ana = 5
DPad Up 6
DPad Dn 7
DPad Lft 8
DPad Rt 9
Start 10
Back 11
Lft Analog Click 12
Rt Analog Click 13
Lft Button 14
Rt Button 15
X(msoft) Button 16
GreenA 17
RedB 18
BlueX 19
YellowY 20
*/
int mapping[] = {17, 18, 19, 20, 14, 15, 11, 10, 12, 13};
for (int i=0;i<11;i++)
inArray[i+10]="0";
for (int i=0;i<=10;i++)
if (part2IL.indexOf(Integer.toString(i)) >= 0)
inArray[mapping[i]]="1";
//D-pad munging.
if (part3IL[0].equals("[1")) {
inArray[8] = "1";
inArray[9] = "0";
}
else if (part3IL[0].equals("[-1"))
{
inArray[8] = "0";
inArray[9] = "1";
}
else {
inArray[8] = "0";
inArray[9] = "0";
}
if (part3IL[1].equals("1]")) {
inArray[6] = "1";
inArray[7] = "0";
}
else if (part3IL[0].equals("-1]"))
{
inArray[6] = "0";
inArray[7] = "1";

THE MANTA PROJECT34
}
else {
inArray[6] = "0";
inArray[7] = "0";
}
/*
for (int i =0; i<inArray.length;i++)
System.out.print(inArray[i]+", ");
*/
//String inArray[] = inputLine.split(", *");
int inIntArray[] = {0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0};
for (int i = 0;i<inIntArray.length;i++)
inIntArray[i] = Integer.parseInt(inArray[i].trim());
//Button Munging. Mostly debugging stuff.
//The Curtime stuff is to insure that the buttons just don’t keep flipping
//state.
if (inIntArray[10] == 1)
if (curTime - 500 > commandTime[0]){
started = !started;
commandTime[0] = curTime;
}
if (inIntArray[11] == 1)
if (curTime - 500 > commandTime[1]){
flip = !flip;
commandTime[1] = curTime;
}
if (inIntArray[17] == 1)
if (curTime - 500 > commandTime[2]){
cal = !cal;
commandTime[2] = curTime;
}
if (inIntArray[19] == 1){
if (inIntArray[12] == 1)
if (curTime - 50 > commandTime[3]){
rotation += 3;
commandTime[3] = curTime;
}
if (inIntArray[13] == 1)
if (curTime - 50 > commandTime[4]){
rotation -= 3;
commandTime[4] = curTime;
}
if (inIntArray[15] == 1)
if (curTime - 50 > commandTime[8]){
rotation -= 0.1;
commandTime[8] = curTime;
}
if (inIntArray[14] == 1)
if (curTime - 50 > commandTime[8]){
rotation += 0.1;
commandTime[8] = curTime;
}

APPENDIX A: MANTACLIENT.JAVA 35
}
else
if (inIntArray[15] == 1 || inIntArray[14] == 1) {
if (curTime - 500 > commandTime[10]){
rclick = !rclick;
lockedSpeed[0] = inIntArray[5];
commandTime[10] = curTime;
}
}
if (inIntArray[16] == 1){
for (int i=0;i<3;i++)
sc.setMotor(i,0);
out.println("ByeAll");
}
if (inIntArray[9] == 1)
if (curTime - 500 > commandTime[5]){
motorStarted[0]=!motorStarted[0];
commandTime[5] = curTime;
}
if (inIntArray[6] == 1)
if (curTime - 500 > commandTime[6]){
motorStarted[1]=!motorStarted[1];
commandTime[6] = curTime;
}
if (inIntArray[8] == 1)
if (curTime - 500 > commandTime[7]){
motorStarted[2]=!motorStarted[2];
commandTime[7] = curTime;
}
if (inIntArray[18] == 1)
if (curTime - 500 > commandTime[9]){
secondStickMode=!secondStickMode;
commandTime[9] = curTime;
}
/* This is the important algorithm. It translates the users intent as expressed on the dual ana-
log joysticks into machine understandable instructions through the methodology described in the
thesis. In short, it converts the XY stick into an angle, adds each “motor” ‘s angle to calcu-
lated angle to change from the joystick’s frame of reference to the motor’s frame of reference,
multiplies that by the distance the XY stick is away from center, to allow for proportional con-
trol, then adds the global deformation in the Z-axis, since each motor pushes and pulls uniformly
on Z axis input, and then takes the cosine of that number, which is a percentage passed to the
motors. */
if (secondStickMode){
double x=inIntArray[2],y=inIntArray[3],z=inIntArray[1],
len=Math.sqrt(x*x+y*y);
double vec=Math.atan2(x,y);
if ( !((x==0)&&(y==0)) )
for (int i=1;i<4;i++)
inIntArray[i]=(int)(Math.cos(vec+motorAngle[i-
1]+rotation*0.0174532925)*len+z*.5);
else
for (int i=1;i<4;i++)
inIntArray[i]=(int)(z);
}

THE MANTA PROJECT36
if (flip)
for (int i=0;i<4;i++)
inIntArray[i]*=-1;
if (cal)
for (int i=0;i<4;i++)
if (Math.abs(inIntArray[i]) > 10)
inIntArray[i]=(int)Math.signum(inIntArray[i])*1000;
if (rclick)
inIntArray[5] = lockedSpeed[0];
if (inIntArray[5] == 0 || !started)
inIntArray[0]=inIntArray[1]=inIntArray[2]=inIntArray[3]=0;
else
if (inIntArray[5] < -750)
for (int i=0;i<4;i++)
inIntArray[i]*=lowMultiplier;
else if (inIntArray[5] < 0)
for (int i=0;i<4;i++)
inIntArray[i]*=minMultiplier;
else if (inIntArray[5] < 750)
for (int i=0;i<4;i++)
inIntArray[i]*=highMultiplier;
else
for (int i=0;i<4;i++)
inIntArray[i]*=maxMultiplier;
/*
for (int i=1;i<4;i++)
if (inIntArray[i] < 0)
inIntArray[i]*=calibrationDown[i-1];
else if (inIntArray[i] > 0)
inIntArray[i]*=calibrationUp[i-1];
*/
if (cal)
for (int i=0;i<3;i++)
if (lastSpeed[i+1] != inIntArray[i+1]){
S y s t e m . e r r . p r i n t ( " M o t o r : \ t " + i + " \ t C u r T i m e : \ t " + c u r T i m e + " \ t S p e e d :
\t"+inIntArray[i+1]+"\tSensor:\t"+sensor[i]);
System.err.println();
System.out.print(beep+beep+beep+beep+beep);
lastSpeed[i+1] = inIntArray[i+1];
}
for (int i=0;i<3;i++)
if (!motorStarted[i]) inIntArray[i+1]=0;
System.out.print("std:"+started+"\tflp:"+flip+"\tcal:"+cal+"\tSsm:"+secondStickMode+"\tRot:"+rota
tion+"\tRclk:"+rclick+lockedSpeed[0]);

APPENDIX A: MANTACLIENT.JAVA 37
for (int i =1;i<4;i++){
System.out.print("\t Motor "+(i-1)+": "+motorStarted[i-1]+"
"+inIntArray[i]);
//Here is where that calculated number (or the raw deformation in
//debugging mode, is passed to the servoController.
sc.setMotor(i-1,inIntArray[i]);
}
System.out.println();
}
out.close();
in.close();
echoSocket.close();
System.exit(1);
}
}