Simply put: the best workshop of the year, hands down.
Brain Osborne led a fantastic workshop over the weekend that challenged us to apply new technologies and tools to design. How new? We were making them as we went. The workshop had us using Arduino Uno boards, something most of us were totally unfamiliar with, and a wide variety of sensors to monitor site conditions. Where the workshop built on existing landscape architecture practice was with its evolving definitions for the concept of ‘surveying vs surveillance.’ We were tasked with thinking about what it meant to survey a site vs implement surveillance techniques across the site. Ultimately we settled on the framework that the two differed in depth of investigation and length of implementation. Surveying, as it is used in landscape architecture (and even I suppose in architecture) today, is more of a one off approach to site analysis for the sake of developing informed design solutions or suggestions. It is often the first thing you learn in a basic design fundamentals course – analyzing grade changes, their impacts on drainage, the way the sun hits the site and existing structures, boundaries, no go zones, barriers and screens, circulation patterns, and so on. You jot down some notes and then move on with the design process, everything you do being informed by the one hour or so on the site. This has been considered informed and thoughtful design for ages, but the idea of surveillance in the place of surveying attempts to change the fundamental approaches of site analysis and their lasting impacts on the design process.
Site surveillance suggests, in the place of one or two site visits, a long term approach to collecting site data that utilizes new technologies to actively measure and record data for later or direct use. In our case we were investigating the potential of Arduino based systems to be deployed as on-site surveillance for the Home Maker sites in Knoxville, TN that we were using as the basis for our studio work. Brain walked us through the basics of developing a device from identifying the variables of interest and diagramming the device to actually writing the sketches (programs for Arduino) that would be needed to run the devices and collect data. My partner and I focused our efforts on developing a sensor capable of detecting minor changes in humidity and temperature across a site. The device would move across the site in a zig-zagging grid pattern collecting measurements every 2 seconds which it would store on an on-board SD card. The data could then be collected and fed into Grasshopper using Firefly to create a ‘data curtain’ visualization showing the the humidity and temperature across the site as floating sheets undulating above the site. We managed to develop the device and the sketch needed to power it, and even got it ‘remote’ by attaching an Arduino Boost module and cellphone battery. The major issue that we were running into with the setup was the visualization of the data in Rhino. It was difficult to recreate the path of the device on the model of the site creating a level of inaccuracy in the representations. Ultimately, if time and budget allowed, the next step would be to add a GPS component to the device capable of tracking its position and geolocating each set of data.
After the workshop I continued to toy around with the idea of data surveillance for site analysis and “hatched” a little idea about how it could be implemented into an existing site that has already been designed as a form of management. Behold the DataEgg, a small scale surveillance station that could be used by botanical gardens, facilities crews, or even homeowners to monitor the health and progress of their property. The applications would be mostly horticultural in nature with it being used to measure available moisture, sun exposure, and nutrients for plants. The part that would set DataEgg apart from other systems was its ability to talk to its neighbors. Multiple DataEggs could be dispatched across a small site, say 1/4 acre and networked together to share data and store it in one location, a Clutch computer. The Clutch would then share its live data with a Nest visualization system that would allow visitors or owners to see the data and interact or respond accordingly. Because of the pace of studio this semester I haven’t had the opportunity to push this idea to the point of prototyping yet – though this is my goal for the summer and possibly fall semester. I have modeled the shell in Rhino and am ready to 3D print prototype components to test their weather proofing capabilities. Once that is stable I plan to begin attaching the data collecting components and the main Arduino Uno board (there are still a few program bugs to work out, but nothing catastrophic). With any luck a single prototype DataEgg will be ready for deployment by August and, pending those results, more will follow to test their communication capabilities. Fingers crossed!
Dual MLA | MARCH student at The University of Tennessee. Travels abroad, creative explorations, and design investigations.