Terrain Machine

 
Project Description
Current Status
 
 

Terrain Machine
John Klima
January, 2002

Project Description

Terrain Machine is an analogue mechanical device interfaced to a digital computer, creating a physical representation of a section of the Earth's surface.  This device functions in real-time, so that any portion of the Earth can be made physical and the entire surface can be traversed seamlessly.

Terrain Machine is part of my ongoing investigations into material representations of meaningful sets of digital data. It is also an evolution of the EARTH project (to be exhibited in the 2002 Whitney Biennial)--a unique geo-spatial visualization system that culls real-time data from the Internet, accurately positions them onto a three-dimensional model of the Earth and allows viewers to zoom in on the various data levels (from GOES-10 and Landsat 7 images  all the way down to a terrain level). Terrain Machine is an aesthetic investigation of the world as it currently exists "in data" and of the fluid transition between manifestations of information enabled by digital technologies. Relying on accurate, scientific data sources, Terrain Machine addresses issues surrounding the representation and construction of our “reality” in its various forms. 

In my previous installations "go," "fish," "guestbook," and "stock-cups" (see past work support document), I created digital software and display, with a parallel or adjoining analogue output device. Whether straightforward in "guestbook," metaphorical in "go," consequential in "fish," or informational in "stock-cups," each system has a strong virtual component, based on a three-dimensional data set, directly connected to, and often displayed directly upon, a sculpturo-mechanical device.  Part of my urge to invent unconventional output devices stems from a desire to feel and experience the "virtual" in a physical and unencumbered way. Terrain Machine dovetails perfectly with this impulse as it renders completely physically the digitized surface of the EARTH data set. 

The device is, in mechanics, quite simple. A large latex skin is stretched over a frame, positioned horizontally. Below the frame is an array of linear actuators, extending and retracting to conform the latex surface to a digital array of elevation points. A 64 x 64 unit array provides more than adequate vertex detail to represent a 5 degree by 5 degree patch of the Earth's surface. A high resolution digital terrain image is simultaneously projected on to the latex, filling out all the details of the surface. This analogue methodology is particularly compelling to me because it exactly reproduces the algorithmic methodology of 3d rendering software. In the EARTH project, I compiled a complete set of ASCII elevation grids, then used these grids to transform the vertices of a 3d mesh into a terrain model. A high-resolution 2d terrain image is then texture-mapped to the mesh. As you can see, the analogue and algorithmic methodologies are largely the same.  In code, I move the points of a mesh up and down to create a surface,  in reality the mesh is a skin of latex that pushed and pulled up and down to create a surface.  In code, a 2d texture is mapped to the terrain mesh.  In reality, a 2d texture is projected onto the latex surface. 

The complexities of the project can be divided into two significant tasks. The first task, largely complete at this point, will be the "serving up" of the data to the device. All my data is compiled, organized and easily accessible in source code.  However, I intend to expand the data sources to serve up not only generated terrain imagery, but real Landsat-7 satellite imagery, projected onto the analogue latex surface, as well as a variety of constantly fluctuating realtime Earth-related data sources, such as weather, vegetation levels, rainfall, etc.  For the Landsat-7 imagery, this requires the authoring of software to transform from its native reference, known as path-row, to the seamless latitude/longitude of terrain data.  I am looking forward to this task as it has many implications beyond just the scope of this project.

The second task is the physical construction of the device.  The latex frame is simple, and final presentation of the computer projection and completed terrain box presents little challenge, however, the electrical engineering of a device for linear actuation does. Though controlling a 64 x 64 array of actuators is no mean task, it is not outside existing processing capabilities. Employing  a 128-bit PC digital output card to drive PIC modules and/or BASIC stamps, multiplexing an array of L297 stepper-motor controller ICs should accomplish the task.   However, 4,096 such controllers and stepper motors presents an astronomical expense.  There is a low tech, inexpensive, and more visceral solution to the problem.

Rather than stepper motors and micro controllers, a 12 channel (12 bit) relay card triggers a matrix of latching relays, powering individual low voltage motors for specific periods of time (change in height) and voltage polarity (up or down). The algorithmic solution is here again made physical as the transference of data is exposed by the presence of the relays, the movement of the motors, and even the sound created by the relays opening and closing. It is again a physical reiteration of the abstract logical process.

Because the very nature of an array is its expandability, the system is constructed from a matrix of discreet functional units, allowing the final dimensions of the work to be determined by the number of units that can fit into a given space, and how many units can be affordably manufactured. The relative cost of each execution solution mentioned above will be critical to the final outcome. Cost assessment is based on "cost per vertex of actuation." A 64 by 64 matrix consists of 4096 vertices. A cost per vertex goal of $10 will place the overall material cost at $40,960. If the cost per vertex proves higher, the array is reduced in resolution to accommodate. Once again, a direct analogy exists between the material and the algorithmic. When constructing a terrain in source code, the greater the vertex count, the higher the processing requirement. This exchange is often referred to by programmers as "computational expense" and the solution to high computational expense is to reduce the vertex count. 

Continuing the cost per vertex analysis, it is quite reasonable to expect that the distribution of processing across a matrix of discreet computers could considerably reduce the final cost, while at the same time the distribution of processing overhead will result in a very fast and responsive system.  A computer equipped with two 12-channel relay cards (to produce a 12x12 matrix) can be built for $400. This is the equivalent of 144 vertices for a control cost of $2.70 per vertex (leaving $6.30 per vertex for motor and actuator costs).  I have designed and prototyped an ultra-affordable linear actuator (see project support document) whose material cost comes to less than $6.  Using a cheap 3 volt hobby motor ($1.50), an L293 analogue motor controller IC ($2.89), a 555 timer chip ($.99), a section of pvc pipe, and a threaded rod,  an easy to assemble actuating device is constructed that will adequately perform its intended task. 

The key to the software implementation is to create flowing traversal of the dataset based on viewer input. A trackball or similar input device navigates the viewer across the dataset. The combined xy delta sends the new corresponding row/column origin in the dataset to the analogue processor, which then shifts previous values accordingly. The trick will be the ability in hardware and software to shift registers. Rather than attempting to set the entire 64x64 mechanical array at once, the new data going to the processor consists of just the new 128 bits of the directional row/column, triggering a cascading of data in the hardware, as one row takes the value of its neighbor and passes its previous values to the next row. I expect an extremely fluid feeling of motion, greatly enhanced by the trivial traversal of the digital terrain image being projection from above.  With processing distribution across multiple machines each responsible for only 144 vertices, the action will appear simultaneous across the matrix and will occur within a short time period.  Keep in mind that it is not desirable to "instantly" transform the latex surface.  Rather, the transformation over a few seconds will enhance the feeling of motion, and will define the the speed at which a viewer can "fly."  When approaching areas of significant elevation difference, it will take longer to climb up and down these heights as the actuators need to be engaged for longer time periods.  The viewer will zip over Florida but will have to exert some effort to cross the Appalachians, reiterating the physicality of the represented data.

 


 
 
 

Current Status
 
 



workbench breadboard prototype
 


finished single actuator prototype