Wireless video transmission and motor control for professional grade DSLR cameras

MISSING IMAGE

Material Information

Title:
Wireless video transmission and motor control for professional grade DSLR cameras
Physical Description:
Project in lieu of thesis
Creator:
Tietz, Jonathan
Publisher:
College of Fine Arts, University of Florida
Place of Publication:
Gainesville, Fla.
Publication Date:

Notes

Abstract:
The purpose of the Canon 7D Wireless Transceiver (henceforth referred to as mar-IO) project is to utilize a stock Canon 7D (as a proxy for any Canon camera product) and its included LiveView capabilities to produce an image on an accompanying wirelessenabled digital device (PC, Android/iOS Smartphone, Tablet) in real time at a "useable" (24 fps) frame rate and latency. This will enable users to have an after-market option for high quality third-party viewing of the camera's input from a distance. This would allow, for instance, a director to view a camera's output from a comfortable distance. This operation will communicate using WiFi rather than radio or infrared technologies to allow for the greatest compatibility and range options for the end user. Another added benefit to WiFi is that it gives users the option to access the device remotely over the internet. In addition to the remote video functionality, this device will also feature a standard camera mount which will turn the camera into an advanced multiple axis motion device. This device, the Canon 7D Motion Rig (henceforth referred to as Lue-G), is controlled by open-source software and therefore significantly reduces the production costs. The Lue-G was built by hand and uses only readily available components. When combined with the mar-IO the motion rig will allow for fully automated operation of thecamera. This is extremely useful during time-lapse shoots and for adjustment during recording. These two products also aim to significantly reduce the cost of wireless transmission and remote automation to amateur filmmakers since all components are readily available on the consumer market. With this proof of concept design, it is hoped that future technologies may be expanded into many different types of applications. Shared Operating Systems between mobile and traditional devices will hopefully eliminate the need for additional software to use mobile devices. The motion rig and the video rig complement each others' design since the Lue-G's Arduino controller can function through the wireless transmission device which makes both systems standalone and wireless.
General Note:
Digital Arts and Sciences terminal project
General Note:
Additional files being processed; video

Record Information

Source Institution:
University of Florida Institutional Repository
Holding Location:
University of Florida
Rights Management:
All rights reserved by the source institution and holding location.
System ID:
AA00011383:00001


This item is only available as the following downloads:


Full Text

PAGE 1

1 WIRELESS VIDEO TRANSMISSION AND MOTOR CONTROL FOR PROFESSIONAL GRADE DSLR CAMERAS By JONATHAN TIETZ SUPERVISORY COMMITEE: BENJAMIN DEVANE CHAIR ANGELOS BARMPOUTIS MEMBER JAMES BABANIKOS MEMBER A PROJECT IN LIEU OF THESIS PRE SENTED TO THE COLLEGE OF FINE ARTS OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF ARTS UNIVERSITY OF FLORIDA 2012

PAGE 2

2 2012 Jonathan Tietz

PAGE 3

3 To my Dad for his pushing me to pursue my ed ucation in my own way. I think of you every day! And to my Mom for reasons beyond words.

PAGE 4

4 ACKNOWLEDGMENTS Thank you to the members of my supervisory committee for their support of this project since its conception Thank you also to my brother, David, for h is helpful expertise and ideas (and his soldering gun and various components I've broken in this process!), as well as a big thank you to Matthew Carroll for the never ending discussions and conversations for the last eight months about this and other insa ne projects. Friendship is a treasure best discovered early. Also a huge thank you to my editing team consisting of my sister Anna and friend Nicole. I couldn't have done this without all of you

PAGE 5

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................ ................................ ................................ ... 4 LIST OF TERMS ................................ ................................ ................................ .............. 7 INTRODUCTION ................................ ................................ ................................ ............ 10 1.1 Professional Video Workflows ................................ ................................ ............ 10 1.2 Project Significance ................................ ................................ ............................ 13 1.3 Literature Review ................................ ................................ ............................... 15 METHODS ................................ ................................ ................................ ...................... 17 2.1 Overview ................................ ................................ ................................ ............ 17 2.2 Equipment Wireless Transmission ................................ ................................ ... 18 2.2.1 Features ................................ ................................ ............................. 19 2.2.2 Hardware ................................ ................................ ............................ 19 2.3 Troubleshooting and Device Specifications ................................ ....................... 22 2.3.1 Wireless N Protocol ................................ ................................ ............ 22 2.3.2 Edimax Router Software Flash ................................ .......................... 23 2.3.3 GUWIP204 Driver ................................ ................................ .............. 24 2.4 Equipment Camera Motion ................................ ................................ .............. 25 2.5 Troubleshooting and Device Specifications Lue G ................................ .......... 29 2.5.1 Arduino Duemilanove ................................ ................................ ......... 33 2.5.2 GRBL.hex Control ................................ ................................ .............. 34 RESULTS ................................ ................................ ................................ ....................... 37 4.1 Successful Function ................................ ................................ .............. 37 4.1.1 Mar IO Function ................................ ................................ ................. 37 4.1.2 Transfer Speed Tests ................................ ................................ ......... 38 4.1.3 Lue G Function ................................ ................................ .................. 38 4.2 Complications and Limitations ................................ .............................. 39 4.3 Effectiveness of the mar IO ................................ ................................ ... 40 Conclusion ................................ ................................ ................................ ...................... 41 6.1 Summary ................................ ................................ ................................ ............ 41 6.2 Project Evaluation ................................ ................................ .............................. 41 6.2.1 Industry Impact ................................ ................................ ................... 41 6.3 Future Direction ................................ ................................ ................................ .. 42 LIST OF REFERENCES ................................ ................................ ................................ 45 BIOGRAPHICAL SKETCH ................................ ................................ ............................. 48

PAGE 6

6 LIST OF FIGURES Figure page Figure 2 1 ................................ ................................ ................................ ....................... 17 Figure 2 2 ................................ ................................ ................................ ....................... 18 Figure 2 3 ................................ ................................ ................................ ....................... 19 Figure 2 4 ................................ ................................ ................................ ....................... 19 Figure 2 5 ................................ ................................ ................................ ....................... 24 Figure 2 6 ................................ ................................ ................................ ....................... 25 Figure 2 7 ................................ ................................ ................................ ....................... 26 Figure 2 8 ................................ ................................ ................................ ....................... 26 Figure 2 9 ................................ ................................ ................................ ....................... 27 Figure 2 10 ................................ ................................ ................................ ..................... 27 Figure 2 11 ................................ ................................ ................................ ..................... 29 Figure 2 12 ................................ ................................ ................................ ..................... 30 Figure 2 13 ................................ ................................ ................................ ..................... 30 Figure 2 14 ................................ ................................ ................................ ..................... 31 Figure 2 15 ................................ ................................ ................................ ..................... 32 Figure 4 1 ................................ ................................ ................................ ....................... 35 Figure 4 2 ................................ ................................ ................................ ....................... 36

PAGE 7

7 LIST OF TERMS MAR IO Name for the Canon 7D wireless transceiver (Monitor Automated Review IOgear) LUE G Name for the Canon 7D motion rig (L ow cost Unencumbered Engineering Gadget G RBL HE X Control system BIOS fo r Android -specifically designed for 3 dimensional CNC motor control (open source). G UWIP 204 Refers to the Iogear GUWIP204 4 port WiFi USB Hub L ATENCY Delay between communications, caused by either distance in the case of the internet or hardware delay. Me asured in a "response time": typically in milliseconds (ms). O PEN SOURCE Hardware or software which is entirely available for public use and modification including source code. Typically has no end user encryption. P CB D ESIGN Electrical engineering term us ed for describing the process of designing the functions of a piece of hardware. Placement of components and electrical power, as well as specifications of processors and cases that the manufacturer uses to build the hardware. F RAMERATE Video term describi ng the number of frames per second. 20 frames per second is the slowest the human eye will see as a continuous image. Industry standards are 23.93, 24, 29.97, and 30 frames per second for digital video.

PAGE 8

8 Abstract of Project in Lieu of Thesis Presented to the College of Fine Arts of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Arts WIRELESS VIDEO TRANSMISSION AND AUTOMATED MOTION RIG FOR THE CANON 7D PROFESSIONAL USE By Jonathan Tie tz May 2012 Chair: Benjamin DeVane Major: Digital Arts and Sciences The purpose of the Canon 7D Wireless Transceiver (henceforth referred to as mar IO ) project is to utilize a stock Canon 7D (as a proxy for any Canon camera product) and its included Liv eView capabilities to produce an image on an accompanying wireless enabled digital device (PC, Android/iOS Smartphone, Tablet) in real time at a "useable" (2 4 fps) frame rate and latency. This will enable users to have an after market option for high quali ty third party viewing of the camera's input from a distance. This would allow, for instance, a director to view a camera's output from a comfortable distance. This operation will communicate using WiFi rather than radio or infrared technologies to allow f or the greatest compatibility and range options for the end user Another added benefit to WiFi is that it gives users the option to access the device remotely over the in t ernet In addition to the remote video functionality, this device will also feature a standard camera mount which will turn the camera into an advanced multiple axis motion device. This device, the Canon 7D Motion Rig (henceforth referred to as L ue G ) is controlled by open source software and therefore significantly reduces the productio n costs. The L ue G was built by hand and uses only readily available components. When combined with the mar IO the motion rig will allow for fully automated operation of the

PAGE 9

9 camera. This is extremely useful during time lapse shoots and for adjustment durin g recording. These two products also aim to significantly reduce the cost of wireless transmission and remote automation to amateur filmmakers since all components are readily available on the consumer market With this proof of concept design, i t is hope d that future technologies may be expand ed into many different types of applications Shared Operating Systems between mobile and traditional devices will hopefully eliminate the need for additional software to use mobile devices. The motion rig and the v ideo rig complement each others' design since the Lue G 's Arduino controller can function through the wireless t ransmission device which makes both s ystems standalone and wireless.

PAGE 10

10 CHAPTER 1 INTRODUCTION 1.1 Professional Video Workflows Technology is const antly shifting in the field of digital technology. Video production is no di fferent from any other form of digital media in today's technological age. Over the last thirty years, there has been an increasing pace of transition between te chnologies From th e switch from analog formats such as 35mm film and 64mm, to the massive transition into digital storage, to the progression into high definition formats, technology has changed practices in photography and film. Both the switch to digital and the switch to ever smaller devices while maintaining ease of distribution and control poses a major challenge for filmmakers at all levels of expertise. Consumer level cameras such as the Panasonic base model HVX200 and Sony EX 1 are quickly being replaced by much chea per and more efficient DSLR technology. Canon will shortly launch a line of DSLRs that will support 4,000 lines of resolution 1 -nearly reaching the maximum analog quality of 64mm film of 6,000 lines. Continual paradigm shifts result in astronomically high development costs for mastering the use and techniques of these technologies in the field. For inst ance, a basic jib rig (a counter weighted arm mount similar to a construction crane for a camera) used on a low budget professional shoot may cost as much a s $ 2,500 2 In addition to these high costs, extensive training and experience are needed on each individual proprietary system. There is an in tangible benefit to the development of this build, and that is better collaboration between proprietary hardware d esigners and the film industry. By clearly dictating a method to reduce the cost of the implementation of DSLR technology in the field through the use of open source solutions, I hope to inspire

PAGE 11

11 device makers such as Canon, Sony, and Panasonic to allow mor e open interpretation of their devices rather than closing them off to development. The purpose and motiv ation behind the mar IO (Monitor Automation Review IOgear) was to demonstrate that the best way to the meet needs of a filmmaker in the studio or in the field is to investigate existing consumer hardware platforms and expand upon them instead of purchasing expensive industry equipment The underlying idea of this project is that if enough filmmakers are sharing equipment and establishing workflows tha t are universal and unilateral, techniques and costs would be more similar across the board. This would solve a fundamental issue in the industry: the fragmentation of information available for niche hardware solutions. Videographers, photographers and ot her technophiles would greet greater cooperation between companies with proprietary hardware and open source hackers with open arms. More cooperation between the open source community and manufacturers could provide more reliable and robust field equipment based on the very specific requirements of the professional industry. Devices like Sony's PSP or the ASUS Transformer for instance are popular hacking platforms. They are used as portable monitors, as media streaming devices, as homebrew game development platforms, among other things. Cooperating with this hacking movement rather than fighting independent developers with cumbersome and obstructive measures such as digital rights management practices and unnecessary encryption layers would be much more pro ductive. There are two separate areas of this project and each is distinct from the other although they complement each other in use. The first is the mar IO, which is a device

PAGE 12

12 consisting of a USB hub and wireless router, whose software has been modified t o create a wireless transmission platform. This wireless platform can stream video to a laptop running LiveView, the proprietary software necessary to control the Canon 7D. The second is the Lue G; a custom built motion rig designed specifically for camer as under ten lbs. in weight. They interact well as the mar IO supports transmission of a USB signal over WiFi, enabling the Lue G to also be wireless, while the Lue G provides motion control for the Canon 7D making the entire system capable of remote opera tion. Projects similar to mar IO and Lue G are popular topics of discussion on hundreds of different technology related forums for applications in the video industry including field monitors and home built motion systems And it's not just curiosity; ther e is a clear and present need for these technologies that are used by real photographers and videographers. Gone are the days of waiting for market research on products and s ignificant development times so that a company can develop a completely new device for each function Research and development costs on these projects are immensely expensive. What we truly need are tried and true foundational technologie s to act as base configurations for further customization These platforms would only need to provi de minimal firmware to communities of user designers, who could then further develop and share these homebrew solutions that could be more robust and useful than the original. In such a scenario, development costs would go down, product costs would go down sales would go up, and technology thrives in an open source market. The mar IO and Lue G project exists to provide an example of how manufacturers can easily provide popular and robust platforms for experimentation among industry experts and help to impr ove -rather than hinder -innovation in the industry.

PAGE 13

13 1.2 Project Significance The original concept for the mar IO was the development of an all inclusive mobile device with the ability to control and capture information from the Canon 7D using a wireless t ransmission protocol commonly known as WiFi A number of developers 3 using Android platforms have demonstrated that the Canon Software Development Kit ( SDK ) can be utilized to extend the camera's viewfinder This is done using the Android device and Canon' s proprietary LiveView software 4 U nfortunately communication between the Canon 7D and external devices is currently only possible through a wired USB connection. Because USB has a wired physical limit of three meters (10 feet), there will always be signi ficant restrictions upon any system that utilizes this as a methods of video transmission. 5 A number of existing documented devices including the Canon EFT W5A file transmitter and a server product from OnOneSoftware, have attempted to solve the challeng e of creating an external monitor for the Canon 7D, but all of the se solutions involve a wired USB connection between a traditional computer and the camera. 6 T his is obviously inconvenient for any camera operator. It means for still photography that a heav y laptop must be in a backpack worn by the operator, or held by second party in close proximity. Let us look specifically at the issues a wired connection can cause: S ay a photographer is working on a high end shoot and is limited on time. He has an edito r on site that can review and touch up his photos as he goes, but in order to receive the photos real time, the editor must follow the photographer around the room. There is no way to effectively edit and view photos while moving. While a laptop can be con nected USB to the camera of a moving videographer it is almost impossible to use Canon's LiveView software at the same time that the laptop is connected More specifically,

PAGE 14

14 because of the prior mentioned 10 foot physical limitation of USB cables, a videog rapher's range of motion and freedom of movement would be severely restricted within that radius. The only way to solve this mobility issue is to utilize a laptop in a backpack which makes the use of the LiveView software extremely unlikely if not impossib le. With the m ar IO protocol, I aim to produce a wireless connection between camera and computer that is fast and reliab le enough to perform similarly to a wired connection The end goal of the m ar IO would be to place a computing device in the hands of an on site (or possibly remot e) d irector in charge of an on location photo or video shoot. All photographers or camera technicians would be outfitted with a m ar IO transmitter on their camera from which the d irector would control and view what the cameras se e. The tablet screen would be much more suitable for the director's task of ascertain ing the quality of the image and any corrections deemed necessary. This would solve a current need on location shoots. Often the Director is stuck viewing footage after t he fact or with clumsy cables. Additionally the m ar IO is capable of removing files (still images and video) from the camera when recording is stopped. This is immensely useful for post production teams and file storage concerns since files are immediatel y transferred to another device with no need for shooting to stop. A third team member can easily sort and edit these files while shooting continues This would create a workflow system that would lend well to actual production shoots because it enables the director to have greater control over the file management and productivity of his team. Because the mar IO transmitter is able to transmit files from the camera immediately, editors could begin processing and editing footage on the spot.

PAGE 15

15 Furthermore, the director will control the quality of all footage captured and can make split second decisions on which footage is worth saving, eliminating the need for unnecessary storage of "waste" shots. 1.3 Literature Review In the broader landscape of academic and fi eld related research there are a number of projects similar in nature to the mar IO and Lue G These avenues of research very often involve cameras (although certainly not anything on the level of the production camera required in this application), and ge nerally involve some form of automation. Unfortunately, a review of the available materials also reveals that while the field is developing there is almost no supporting documentation that would be nefit the mar IO and Lue G directly. One of the most inter esting projects published that pertained to this project was an automated photography robot named Lewis. Its exploits are detailed in an academic paper published in the American Association for Artificial Intelligence. 7 Lewis was built on an iRobot B21 pla tform which is still used in AI research today. However, being published originally in 2004 the project is too far outdated to serve as anything but interesting reference for this specific project. However, there are some possibly useful guidelines in the ability of the robot to automatically compose images without user input. This perhaps outlines a useful feature for future pursuit with the mar IO and Lue G. Another notable related paper concerns the management of bandwidth over a TCP/IP network using mu ltiple cameras. This is significant because it relates to the management of multiple data streams while maintaining acceptable quality, althou gh in this instance the "acceptable quality" is standard definition video at a less than optimal 18 frames per sec ond. 8 This is perhaps acceptable for streaming multiple webcams but

PAGE 16

16 certainly not for a production setting. However, it is useful academically as a possible method for liberating separate cameras on the same network by using compression and channeling met hods (preferring a specific camera stream over others by user selection) rather than a separate network node for each instance of the camera streaming device. Aside from these two specifically mentioned papers th ere is an assortment of projects that range from novelty to interesting in relation to the mar IO and Lue G project. One relevant article is a breakdown of the PTP/IP protocol (which is coincidentally used by the Canon 7D ) as a control mechanism -again, this document has limited usefulness because i t is dated to 2005, long before the Canon SDK that is utilized for mar IO was released. 9 There is also a project called FlySPEC which uses a motion camera rig similar to the Lue G to provide remote operation of a camera stand, but does not include any meth ods of video transmission or control beyond cabled connections. 10 Lastly, there is a low bandwidth alternative networking platform called CITRIC which utilizes a very dated processor module (Pentium III at 600 MHz) to provide a user interface for facial re cognition. 11 There is some value in the CITRIC system in that it explores methods of low power, long range data transmission using Xbee controllers, although it is likely that this implementation would be impossible for high quality video transmission as t he bandwidth provided is just too low If anything, the existence of this external research reinforces the need for further interdisciplinary research into the interaction of photography and both hardware and software deployments which might benefit filmma kers. There are hundreds of potential avenues for development similar to the paths taken on the mar IO and Lue G that through collaborative efforts could yield a truly useful platform.

PAGE 17

17 CHAPTER 2 METHODS 2. 1 Overview The development of these systems was ac hieved in large part through extensive research of existing product specifications on the market. The design of both of these devices will exemplify ingenuity and cost effectiveness with deployment in real world production settings in mind. They will aim t o achieve wireless video transmission from the Canon 7D as well as motion control for the camera, all utilizing a wireless network. To achieve this goal m any operating systems and hardware platforms were considered, eventually settling upon the IOGear syst em which formed the basis for the mar IO. A good portion of the research invested was also spent looking at using either the USB 2.0 function of the Canon 7D or rather opting for a pure video output from the HDMI port available on the camera. Eventually it became clear that utilizing the USB port would be a better option since it would also provide control of the camera itself, though it sacrificed some visual quality. This decision may need to be revisited in later versions. There is also significant inves tment in the Lue G device in researching the proper mechanical design for the build. Because of the large torque forces involved in tilting a seven pound camera that is off axis is no small feat. In addition to these considerations it was necessary to inve stigate both the potential cost of any design and the final weight of the entire assembly. Thankfully, additional methods and creative solutions to these problems continue to surface through more exhaustive internet research and collaboration. This suggest s a bright future for both the mar IO and Lue G for future progress.

PAGE 18

18 2. 2 Equipment Wireless Transmission In order to provide an open source product research was necessary to provide an open source protocol which would allow for future expansion of the d evice's capabilities if features needed to be expanded Ideally so mething akin to the USB/IP 12 project would have been used : an open source, Linux based system which uses no encryption and does not use proprietary software All users understand the need fo r quality control in devices to ensure product support but there also is a need for opting out of closely controlled software in favor of open development. Wireless Ethernet is an excellent choice given the context that this workflow would allow an unlimi ted distance with a low latency response. This is exactly the intended use of WiFi. Furthermore, wireless Ethernet for the application of multiple technologies including some currently under development. For example, Wi Fi Direct is currently in beta testi ng by the WiFi Alliance and would allow a direct point to point access between two equipped devices. 13 A user could connect a phone with an e Reader and transfer a file without the need for a router. Wireless Ethernet, through the use of staging devices s uch as repeaters or routers would theoretically provide unlimited range on site for the m ar IO It would also allow for remote internet access, again providing an unlimited range for projects on this platform There is currently a 3G access version of the Edimax rou ter used here which would allow cellular internet access. A user could potentially access this video stream and file management system from anywhere in the world.

PAGE 19

19 2. 2 .1 Features The intended features of the m ar IO are as follows: Wireless vid eo monitoring via Canon LiveView at 24 frames per second at a minimum resolution of 1280x720 Wireless control of camera functions (Iris, ISO, Shutter) Transmission of video and still image files between shooting 2. 2 .2 Hardware T he following consumer hardwa re was used in the mar IO and Lue G projects : Figure 2 1. Equipment Interaction

PAGE 20

20 Iogear 4 port WiFi USB Hub (GUWIP204) o This device includes an 802.11n ready wireless networking card and uses an ARM 9 processor. It is remarkable similar to the Chumby Ha cker Board but runs encrypted proprietary software. Figure 2 2 Iogear GUWIP204 Edimax BR 6258n Wireless router o This router is extremely lightweight and tiny. It requires only three volts and can be powered via mini USB while allowing an effective range of 45 feet (See Chapter 4 for speed tests). It is also easily rooted (flashed with customized software) which allowed installation of Demilitarized router software. It is the ideal candidate for a small, mobile, open source project. There is a 3G version which would allow for remote internet access.

PAGE 21

21 Figure 2 3 Edimax BR 6258n Figure 2 4 Router Mounted on Hub with Velcro The Wireless Ethernet hub is a perfectly suited device for this project because it f eatures four powered USB ports with USB 3.0 cap ability. The powered USB ports provide integration with the Edimax mini router as the pow er supply for both devices can be condensed into one single outlet (or battery pack) for the 5V required by the Iogear hub. Power is then distributed via USB power to the Edimax router or any other attached peripheral. Because of this convenience t he Edimax router is by far the smallest, most elegant solution to the needs of the m ar IO and stays well within manageable constraints for mounting onto a Canon 7D.

PAGE 22

22 2. 3 Troubl eshooting and Device Specifications In order to reach a "watchable" image in any format, the GUWIP204 device must be capable of transmitting enough bandwidth to stream at minimum a 1280x720 image at 24 frames per second. Based on test file transfers -50 me gabyte compressed text files transferred while being timed (see Chapter 4 for results) -the determination was that a minimum of 45 MB/s (megabytes per second -also 450 Mbit/s [megabits per second]) would be needed to achieve the aforementioned standard fra me rate The Canon 7D currently has only a USB 2.0 capable port. This means that the Canon 7D is operating at close to the maximum theoretical speed of the USB protocol it is utilizing for 1280x720 video transmission. 14 Therefore, the goal was for the GUW IP204 hub to reach a speed of above 500 Mbit/s (50 MB/s) in order to avoid any possible bottleneck when utilizing more than one device. Thus the need for another, faster wireless Ethernet protocol arose to avoid a bandwidth bottleneck "Wireless G" known t echnically as 802.11g has a theoretical maximum bandwidth of 54 MB/s (540 Mbi t/s). In practical field tests file transfer results were only averaging 42 MB/s. This was just over a 22% practical loss in speed, a full 16% short of the target threshold There fore, it was necessary to upgrade the wireless network protocol at additional cost 2. 3 .1 Wireless N Protocol The solution was "Wireless N" known as 802.11n. 15 Unfortunately this protocol upgrade means that the project must be contained on its own network to avoid interference with any 802.11g or 802.11b network points. Because Wireless N and Wireless G are both backwards compatible, it is necessary for all connected network points to be of the highest protocol in order to perform at the highest possible t heoretical speed. If any device connected on the network utilizes a 802.11b or 802.11g -as is a

PAGE 23

23 common occurrence with current devices -the router will automatically revert to that protocol rather than 802.11n, thereby reducing the network's bandwidth pote ntial. This was another reason for using the Edimax mini router as it provided an ideally isolated network service. Devices connecting to the router could each be separated without relying on traditional network. Speed tests on the 802.11n protocol network yielded an average transfer rate of 94.8 MB/ s; s ignificantly higher than the target goal and virtually guarant eeing that no bottleneck would occur in the networking hardware. 2. 3 .2 Edimax Router Software Flash The Edimax standard software was not sufficie nt for testing purposes because it presented far too many variables, including possible open port issues and firewall software which may have slowed or blocked the transmission of the IOGear device. To avoid these possible issues other software was needed with a built0in demilitarization function as the standard Edimax software did not contain this feature Demilitarization of a router means all possible firewalls are disabled and all ports specific to a device's IP (internet protocol) address can be opened This completely eliminates any possibility of interference from within the router or network. It also prevents errors such as IP assignment duplication, a common issue with static IP devices such as the GUWIP204. To add demilitarization functionality to the Edimax router it was necessary to flash the device with custom networking software called DD WRT. 1 6 This software does include a demilitarization function which was then applied to all devices on the network. Lastly, the network was configured using MA C address exclusion -only devices matching a certain MAC address (a type of unique network identifier) may gain access to the network. This eliminates possible erroneous (or unauthorized) connections to the network.

PAGE 24

24 2. 3 .3 GUWIP204 Driver The next major hur dle was the GUWIP204's driver firmware. I found d uring transfer tests that an additional 15% data transfer speed could be added if two files were simul taneously transferring Something in the driver was holding back the transfer speed. This 15% was incredi bly important because speed tests indicated a borde rline acceptable speed of approximately 70 MB/s while the expected result had been closer to 90 MB/s. This suggested there was a driver imposed bandwidth limit imposed on each port. When reviewing the driv er software this was clearly the case: urb >dev = dev; urb >context = uvd; urb >pipe = usb_rcvisocpipe(dev, uvd >video_endp 1); urb >interval = 1 ; urb >interval_port_id=0; urb >transfer_flags = URB_ISO_ASAP; urb >transfer_buffer = cam >sts_buf[i]; urb >c omplete = konicawc_isoc_irq; urb >number_of_packets = FRAMES_PER_DESC; urb >transfer_buffer_length = FRAMES_PER_DESC; for (j=0; j < FRAMES_PER_DESC; j++) { urb >iso_frame_desc[j].offset = j; urb >iso_frame_desc[j].length = 1; According to a tutorial on USB protocols for Linux based devices the interval needed to be opened using a base PURB command so that the interval no longer applied to each port ID. It was a very simple one line command: urb >dev = dev; urb >context = uvd; urb >pipe = usb_rcvisocpipe(dev, uvd >video_endp 1); urb >interval = 1; urb >interval_port_id=0; purb_t usb_alloc_urb(int iso_packets) =alloc_non_limit ; urb >transfer_flags = URB_ISO_ASAP; urb >transfer_buffer = cam >sts_buf[i];

PAGE 25

25 urb >complete = konicawc_isoc_irq; urb > number_of_packets = FRAMES_PER_DESC; urb >transfer_buffer_length = FRAMES_PER_DESC; for (j=0; j < FRAMES_PER_DESC; j++) { urb >iso_frame_desc[j].offset = j; urb >iso_frame_desc[j].length = 1; This s olution is not the most technically advan ced method but has worked well without causing any stability issues in the GUWIP204 device. [Section Reference See Reference 17 ] 2.4 Equipment Camera Motion At the beginning of the design phase of the Lue G camera mount my specifications aimed to repli cate th e more expensive mounts already used in the film industry The intent was also to meet the medium range weight requirements of DSLRs with large, high quality lenses. Priority was also given to minimization of the overall weight of the rig Thus alum inum was used wherever possible Obviously this was not an option for every component without ordering parts from specialty vendors Specifically the corner braces and motor mounts were only available in steel. However, the finished rig weighed less than 9 lbs. which is impressive fo r a home built rig of its size. Each of the mounting arms was pilot drilled and mounted with 1/4" #4 60 type machine screws, matching bolts and washers. The process of attaching each bolt to the interior was an arduous, manual p rocess. Similarly, the plexi board was difficult to work with in that the most effective method of cutting the material is by etching and breaking it. Better equipment (ironically a CNC machine -which is what this component's design is based on ) would have m ade this process more delicate and accurate.

PAGE 26

26 Figure 2 5 Completed LUE G Frame (Aluminum) All components of the build are readily available on local or online retailers. Most of the materials were purchased from Home Depot including the fiberglass plexib oard used as sheet stabilizers (instead of using sheet steel to save weight) mounts as well as all of the aluminum. A number of specialty screws (#4 40 and #6 10) were needed from Ace Hardware The following are the main components making up the working p arts of the Lue G : SparkF un Stepper Motor (SKU ROB 09238) 3 required o These motors are cheap and effective. They require only 12V of external power while providing 58 kg/cm torque. They are also minimal in dimension (1.5" square) and weight (7 ounces). Th ey are also cheap at fifteen dollars each which is extremely helpful when two of them break as happened during this build.

PAGE 27

27 Figure 2 6 Stepper Motor Arduino D uemilanove (Amazon.com) o An outdated but well documented Arduino platform. It generally sells f or just under $30 SparkFun EasyDriver Stepper Control Boards (SKU ROB 10267) o These boards are the only viable choice for powering and controlling the above stepper motors. They are extremely testy and can easily be destroyed with the careless flick of a p ower switch. However, they also have a robust set of features including adjustable voltages which are helpful in troubleshooting.

PAGE 28

28 Figure 2 7 Arduino Due mi la nove (Top Left) and EasyDriver Boards 250W PC Power Supply Figure 2 8 250W PC Power Supply Alu minum piping was used to keep the weight of the rig down and to provide a pathway for the motor wiring. The motors were mounted in a cross position formation to provide ample torque for the 7.8 lbs. camera needed on the mount. The weight of the rig is brac ed onto the shaft of a third motor using a shaft pin. #4 40 type machine screws

PAGE 29

29 were used to mount the motors, and #2 35 bolts were used to mount the cameras themselves to match the standard mount screws. Figure 2 9 Wiring Channel Figure 2 10 Horiz ontal Motor Mount 2. 5 Troubleshooting and Device Specifications Lue G The intended purpose of the motion camera rig is automated remote access to the direction (pan and tilt) of the camera in a manner that is both reliable and applicable in a production sense -that is, contributing to "production value." It was to be hoped that the

PAGE 30

30 significant power of the stepper motors would be enough to ensure a smooth movement. Being stepper motors, motion control relies solely on the execution of the control software This requires significant expertise outside of my own field, and so I relied heavily upon tutorials and designs from existing CNC (computer numerical control) devices. These motors and the software used to control them -an Arduino chip running a GRBL.hex command file -are available as open source projects. [See 2.4.1] The main purpose of GRBL.hex is to take user commanded "g code" coordinates and convert them into pulse streams that command the stepper motors on each axis. Admittedly a CNC machine is not designed for camera motion This is evident in the difficulty with adjusting movement to a suitably "smooth" tracking that could be used for camera stabilization which generally has a much slower acceleration and deceleration. With this in mind a modified version of GRBL.hex 20 was pursued which include d a sensitivity adjustment function and acceleration control. This addition to GRBL .hex was a modification branch called "edge." It contained an additional nine setting parameters. Th ese parameter functions si gnificantly improved the performance of the motors by adding deceleration in addition to acceleration control and an increase in smoothing between step rotations [See 2. 5 .1] Weight rating was also an issue for this portion of the project. The stepper moto rs have a torque rating of 58 kg/cm (31 oz./inch) 18 which is far under th e required weight of the camera, which led to the need for two motors mounted on the same axis (Y) The combined power of the two motors amounts to almost four total pounds of torque on the camera's axis which is enough to hold the Canon 7D with a medium lens. Larger cameras (over 10 lbs.) would require larger motors and therefore a larger rig

PAGE 31

31 The stepper motors themselves require ten to twelve volts of external power in addition to d irectional and step control -t his is provided using the SparkF un EasyStepper drivers. The power is provided by t he 250W PC power supply, which was attached with a wooden board and applied grounding and power wires as a single unit. Figure 2 1 1 Directi on and Step Control Wires Each EasyDriver commands and powers a single motor, but I included four with one serving as a backup. Each motor contains two coils, A and B, which in turn correspond to a pair of wires each (blue yellow, red green). Also as an alternative to unreliable software solutions, I opted for a hardware solution to syncing the two motors on the same axis (they would need to spin opposite each other in order to have complementary motion). I spliced one of the EasyDriver board connections into two and reversed the input wires ( Coil A and B) so t hat the direction was reversed. Normally the motor control would be paired blue yellow and then green red left to right on the control board. By reversing this order and using red green then yellow b lue the direction which

PAGE 32

32 the motor spins can be reversed. The pin output does not need to be changed to accomplish this. Figure 2 12 C A (Coil A) and C B (Coil B) [Reference 1 8 ] This configuration allows the two motors to spin complementary with each ot her and eliminates the need for additional code to reverse commands for each motor. Consequently only one command is necessary to perform two functions, rather than two commands for one function. Figure 2 1 3 Direction Control Splice

PAGE 33

33 Splicing the motor control and reversing the direction using hardware is a much more elegant solution than using code. It also eliminates any potential problems with latency -delay between the terminal's command the motors action -which could cause motor da maging commands t o run early or late while the other motor is resisting. Because the Android Due mila nove also runs on a USB connection th e Motion Camera Rig can successfully be ported through the GUWIP204, making this entire rig wireless as well. It c a n receive commands wh ile running the video transmission software (LiveView) making this rig fully automated. Camera control is also possible remotely via this software so the rig would not need to be manned as long as power is available for the camera (within battery life cons traints). Figure 2 1 4 Interchangeable Camera Mount 2. 5 .1 Arduino Duemilanove This standard Arduino microcontroller was chosen because of its widespread use in technical tutorials for many projects on the internet. No modifications were made to the dev ice other than the utilization of GRBL.hex as control software. A program called

PAGE 34

34 gcodesender allows for the rapid upload of a specified .hex file. This was extremely helpful for rapid prototyping of versions of the GRBL.hex when adjusting the pin outputs. This board interfaces directly with the Termite terminal over USB emulated serial protocol (COM3 port). 2. 5 .2 GRBL.hex Control The Arduino Duemilanove board receives direct USB input from the laptop control using a terminal program called Termite. 1 9 The te rminal uses COM output (COM3 in this instance) and emulates a serial connection which is the protocol used by the GRBL.hex. GRBL.hex is an open source stepper motor control system that provides step an d direction control in three axe s (X, Y, and Z). Termi te iss ues a "0 reference" command (G91 G28 X0 Y0 Z0) which declares the current position of the motors as "0." I can then issue a command based on numerical steps, X1 for one step clockwise on the X axis, or X 1 for one step counterclockwise on the X axis. I can make multiple simultaneous commands such as "X 5 (5 steps counterclockwise on the X axis) Y20 (20 steps clockwise on the Y axis)." This code format is known informally as "g code." Figure 2 1 5 Termite Terminal Parameters Because of the earlier mentioned hardware solution to the reversed rotation of

PAGE 35

35 the two motors on a shared axis, the Z axis is not currently being utilized. But it could possibly be utilized as a fourth dimension of movement -possibly as a "dolly" movement left and right. To cont rol these ax e s it is necessary to pin the EasyDriver control boards to the Arduino using GRBL's specified pin readouts. 15 The pinout definitions are as follows: #define STEPPING_DDR DDRD #define STEPPING_PORT PORTD #define X_STEP_BIT 2 #define Y_STEP_B IT 3 #define Z_STEP_BIT 4 #define X_DIRECTION_BIT 5 #define Y_DIRECTION_BIT 6 #define Z_DIRECTION_BIT 7 Bits refer to the output ports on the Arduino board. Bits 2 and 5 are reserved for direction and step control respectively on the X axis. Bits 3 an d 5 perform the same function for the Y axis, and similarly bits 4 and 7 apply to the Z axis. Next is the application of the customized GRBL settings. 20 Since Y_Direction_Bit must move in synchronous motion (because two motors are powering the same axis) it was necessary to invert mask direction on this axis. The microseconds per step pulse were adjusted as well as acceleration Changing the instant cornering speed of the motors did not seem to adjust for anything and significant change to the cornering sp eed created issues with the stopping power of the motors once the required movement was completed. Here are the customized GRBL.hex readout settings for this rig: $0 = 53.333 (steps/mm x) $1 = 53.333 (steps/mm y) $2 = 53.333 (steps/mm z)

PAGE 36

36 $3 = 1 (microse conds step pulse) $4 = 200.0 (mm/sec default feed rate) $5 = 200.0 (mm/sec default seek rate) $6 = 10.0 (mm/arc segment) $7 = 8 (step port invert mask. binary = 100 0) $8 = 10.0 (acceleration in mm/sec^2) $9 = 1.0 (max instant cornering speed change in delta mm/min) [Section Reference 20 ]

PAGE 37

37 CHAPTER 4 RESULTS 4.1 Successful Function 4.1.1 Mar IO Function The m ar IO proved capable of transmitting 1280x720 resolution video at 24 frames per second reliably at a distance of up to 45 feet to a Windows 7 lapto p. It also functions well in a field setting with file management. When images are snapped using the photo function of the camera, images are automatically and instantly transferred after each shot to the laptop. Video works spectacularly as well. Movement with the camera registers well with no frame rate drops and no significant real time delay. While many have reported issues with a latency response time of higher than 75ms (and the mar IO device often averages a latency of 84ms), camera control using mar IO from the laptop is flawless White balance, focus, and capture functions perform as well on the wireless version at 45 feet as they do with a direction connection via USB of less than 10 feet. Figure 4 1. Canon 7D LiveView and Termite Terminal

PAGE 38

38 Surpri singly, the mars IO device shows no detectable buffering issues, even when the camera is recording. This can be attributed to the decision to use an 802.11n networking system which provided bandwidth bottleneck prevention for this specific device. Since th e 802.11n reaches speeds far in excess of the requirements of the video transmission, the likelihood of the speed falling below acceptable ranges is low. It also allows for significant future bandwidth expansion, possibly with higher video resolutions. The only major limitation is the current inability of the system to work on a mobile platform. 4.1 .2 Transfer Speed Tests Distance from Router Speed 1 (MB/s) Speed 2 (MB/s) Speed 3 (MB/s) 5 ft. 98.5 96.1 102.4 30 ft. 67.8 72.4 74.8 45 ft. 62.4 63.1 63.3 6 0 ft. 22.5 22.1 21.7 Figure 4 2. Edimax Router Distance Speed Test As indicated by the above speed tests, the effective range of this Edimax wireless mini router is approximately 45 ft. There is a sharp drop off in performance beyond this distance. The r ecommended range of this system without the use of additional 802.11n repeaters is 40 feet. 4.1.3 L ue G Function The Lue G performs well as an automated control device. The Lue G is able to reliably pan in both directions up to 180 degrees (it is constrain ed only by wiring becoming tangled) and can pan safely 360 degrees (though this is not recommended

PAGE 39

39 with an expensive camera). It supports the necessary weight of 7.3 lbs. needed for mounting a Canon 7D with a medium lens. The system is also relatively easy to use and suffers from only mild system bugs. However, at this stage of development it would be unsuitable for actual videography work due to its jagged movements T hus f urther development on smoothing its motion is needed to produce acceptable results 4. 2 Complications and Limitations In any large scale design project, the end goal of the project changes as development progresses At the beginning of this project, I i ntended to develop the mar IO to support mobile deployment but in the end this goal wa s not feasible because of the proprietary LiveView software limited my ability to support tablet operating systems The obstacles involved in circumventing these issues were simply too large for the scope of this project. One stark indicator of the difficu lty of mobile deployment is the incompatibility of proprietary I O gear router software with OSX Lion, an operating system for which IOGear claims full support. This is not to say that implementation of this system is not possible on Android (and therefore m obil e) systems. One of two problems would need to be solved to make this feature possible One would be the limitations of the Linux based GNU ARM processors on the current "hackable" devices such as the Chumby Hacker Board. 2 1 There is currently an open so urce project called USB IP 12 which would serve this project well. Another similar open source project is called Tomato USB. 2 2 Unfortunately it was outside my scope to provide a functioning mobile plat form using the ARM processor -successfully compiling the project on the ARM processor used by the Chumby board was not possible The other possibility might be a cross platform operating system, likely Windows 8. A Windows 8 powered tablet with an ARM processor would be able to run the

PAGE 40

40 proprietary software curr ently in use with this build Similarly it is possible that with the release of WiFi Direct a tablet could be directly connected without the use of a router to the GUWIP204 device and connects directly via USB. This would still require the decryption of th e Iogear software or the release of an open source version of the hardware 4. 3 Effectiveness of the mar IO For now, the GUWIP204 device works flawlessly on any Windows based operating syste m at a high frame rate and with excellent reliability. Unfortunate ly this means users will currently be confined to a laptop, but the system is still wireless and robust At minimum the project represents a viable platform for further expansion and is applicable across a broad range of devices, not just the Canon 7D or o ther came ras, but for other devices such as medical devices or weather instrumentation (or even security sensors). Beyond a device that allows the Canon 7D to be operating wirelessly, this is a device that frees a videographer from the bonds of cables. It is a platform for wireless development. Because of its base functions offered off the shelf -and supported by Iogear -this device can be used in multiple ways. As a hub for multiple storage devices in a cramped office, as a place to plug in a USB keyboard to control the laptop mounted as a monitor. The m ar IO is more a platform for additional creative uses than something designed for a specific box. Th is is the future of development: u sing existing technology and exp anding upon its traditional use.

PAGE 41

41 CHAPTER 6 CONCLUSI ON 6.1 Summary The mar IO and Lue G are two complementary devices that function well within the limitations inherent in the system. Mar IO is a prime example that a well defined goal combined with creative tinkering can attain functions previousl y thought impossible by many in the film industry. The Lue G is similar in that it provides simplicity in design. Solutions in the field of film are often far too contrived and overbearing. Sometimes the simple, cheap, home grown solution is the best optio n rather than spending endless budgets to solve a problem. 6.2 Project Evaluation In hindsight there are a number of changes to the development that likely could have resulted in different outcomes; specifically referring to even more exhaustive research a nd industry recommendations on what platform to have used in place of the GUWIP204 It is also likely that the Lue G could have been a much more robust system if it had been designed with different specifications. If development on the Lue G continues it a lmost certainly will be completely reconstructed from the ground up using a different mounting platform to provide more than one point of access with the base as well as a wire management system which would allow for 360 degrees of rotation. 6.2.1 Industry Impact A wireless project of this caliber has not been attempted with the Canon 7D As mentioned earlier, a number of projects have managed to get a device working using a wired miniUSB to USB connection with a smartphone and tablet. None of these under takings has involved wireless networking

PAGE 42

42 Even within the limitations of this device -such as its incompatibility with mobile platforms -it is undoubtedly a useful and powerful tool that industry specialists will appreciate. There are hundreds upon hundr eds of specialists out there asking "Can I use my iPad as a monitor?" And while there are options for them to do so, none are wireless or convenient. The m ar IO at least eliminates one step in the chain being used by current software Secondarily, t his p roject also casts a shadow on proprietary equipment from Canon which performs sub par tasks (still photography only) at a market excluding price of $1,500. This is an almost unacceptable solution for every photographer. Considering that this device could b e made available -even though it is bulkier and less customized -for approximately $200 in total user cost. As an added benefit, the components are available on the consumer market. 6.3 Future Direction Beyond a device that allows the Canon 7D to be operat ing wirelessly, this is a device that frees a videographer from the bonds of cables. It is a platform for wireless development. Because of its base functions offered off the shelf -and supported by Iogear -this device can be used in multiple ways. As a hub for multiple storage devices in a cramped office, as a place to plug in a USB keyboard to control the laptop mounted as a monitor. The m ar IO is more a platform for additional creative uses than something designed for a spec ific box. Th is is the future of development: u sing existing technology and expanding upon its traditional use. There is a good possibility that with the release of Windows 8 tablets and the operating system itself that there will be a cross platform solution to the current limitation o f the GUWIP204 software support to Android. Such functionality would

PAGE 43

43 enable the mar IO device to be used just as if it were on a laptop except utilizing a mobile tablet. In this case it would be preferable to also develop a custom user interface for the Ca non SDK to allow for more user control over features and functions of the camera. Additionally, it could be beneficial to the project to explore web implementatio n using web servers and a web interface rather than independent software. This would certainl y solve the cross platform issues currently being experienced. Websites can be designed to function on all platforms. Using a web platform would also simplify the command structure and programming needs for the Lue G as it would make possible screen space for a customized UI rather than a limited controller such as a joystick. There are endless possibilities for continued development with the mar IO and Lue G which, after all, was the original intention of the project. It is to be hoped that something great will come out of this base platform that has cut the cord on the Canon 7D's LiveView system

PAGE 44

44

PAGE 45

45 L IST OF REFERENCES 1. Sebastian Anthony, Canon unveils 4K Cinema EOS cameras and lenses [cited April 4, 2012]. Available from http://www.extremetech.com/electronics/103507 canon unveils 4k cinema eos cameras and lenses 2. Kessler & Crane REVOLUTION Pan and Tilt Head System [cited on April 4, 2012]. Avai lable from http://www.kesslercrane.com/product p/100117.htm 3. Max Lee. DSLR Controller App for Android Tablet -DSLR App of the Year! [updated March 22, 2012; cited April 4, 2012]. Availabl e from http://highonandroid.com/android apps/dslr controller app for android tablet dslr app of the year/ 4. Canon, Inc. Canon Digital Camer a Software Developers Kit [cited April 4, 2012]. Available from http://www.usa.canon.com/cusa/consumer/standard_display/sdk_homepage 5 Jennifer Luec. USB Extender Ove rcome USB Distance Limitations with USB Extension [cited April 4, 2012]. Available from http://ezinearticles.com/?USB Extender -Overco me USB Distance Limitations With USB Extension&id=2717864 6 OnOneSoftware, Inc. DSLR Camera Remote [cited April 4, 2012]. Available from http://www.ononesoftware.com/products/dslr camera remote/ 7 Zachary Byers Michael Dixon Cindy M. Grimm and William D. Smart, Say Cheese! Experi ences with a Robot Photographer," AI Magazine 25(3), 37. Fall 2004, accessed April 4, 2012. 8 Zhenyu Yang and Klara Nahrstedt, A bandwidth managem ent fram ework for wireless camera array," NOSSDAV '05 2005, accessed April 4, 2012.

PAGE 46

46 9. P. Bigioi, G. Susanu and E. Steinberg (2005, February). PTP/IP A new transport specification for wireless photography. Consumer Electronics 51(1), 240 244, Februar y, 2005, accessed April 4, 2012. 10 Qiong Liu, Don Kimber, Jonathan Foote Lynn Wilcox, and John Boreczky, FlySPEC: A multi user video camera system with hyb rid human and automatic control," Multimedia '02 2002, accessed April 4, 2012. 11 P. Chen, (200 8, September 7). CITRIC: A low bandwidth w ireless camera network platform," Distributed Smart Cameras 2008 1 10, 2008, accessed April 4, 2012. 12 USBIP. USB/IP Project [updated February 23, 2011; accessed April 4, 2012]. Available from http://usbip.sourceforge.net/ 13 WiFi Alliance. Wi Fi Direct: Personal, portable Wi Fi that goes with you anywhere, any time [cited April 4, 2012]. Available from http://www.wi fi.org/discover and learn/wi fi direct%E2%84%A2 14 Dong Ngo. Seagate FreeAgent GoFlex Ultra portable [cited April 4, 2012]. Available from http://reviews.cnet.com/external hard drives/seagate freeagent goflex ultra/4505 3190_7 34183942 2.html 15 Bradley Mitchell. Wireless Standards The 802.11 family explained [cited April 4, 2012]. Available from http://compnetworking.about.com/cs/wireless80211/a/aa80211standard.htm 16 Bradley Mitchell. Broadcom Detection [updated August 10, 2010; cited April 4, 2012]. Available from http://www.dd wrt.com/wiki/index.php/Broadcom_detection

PAGE 47

47 1 7 Detlef Fliegl Programming G uide for Linux USB Device Drivers [updated December 25, 2000; cited April 4, 2012]. Avail able from http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/ 1 8 Samertufail DIY Surveillance System Using a Webcam Part 3. [updated December 5, 2009; cited April 4, 2012]. Available from http://garagedeveloper.wordpress.com/2009/12/05/the diy surveillance system using a webcam %E2%80%93 part 3/ 1 9 Termite. Termite: a simp le RS232 terminal [updated April 2, 2012; cited April 4, 2012]. Available from http://www.compuphase.com/software_termite.htm 20 Simen GRBL Tree Edge [cited April 4, 2012]. Available from https://github.com/grbl/grbl/tree/edge 21 Adafruit, Inc. Chumby Hacker Board v1.0 [cited April 4, 2012]. Available from http://www.adafruit.com/p roducts/278 2 2 Tomato USB. Tomato USB: Alternative Linux firmware for Ethernet routers [cited April 4, 2012]. Available from http://tomatousb.org/

PAGE 48

48 BIOGRAPHICAL SKETCH Jonathan Tietz was born July 24, 1988 in Du nedin, Florida. He is the youngest of three siblings and graduated from River Ridge High School in 2006. After graduating from the University of Florida with a Bachelors of Art in Telecommunications Production with a concentration in Music Theory and Perfo rmance, he applied and gained admittance to the Digital Worlds Institute graduate program for Master of Arts in Digital Arts and Sciences. Jonathan's passions include film photography, technology and especially entrepreneurship. While the last five years have been focused on pursuing educational goals, any extra time he can find is spent working in his field launching his own production business in 2010, creating content and readership for multiple highly visible websites and working to develop lasting rel ationship with major video game developers including Blizzard Entertainment, Valve Inc. and Riot Games while staying active in the professional gaming communities. Upon completion of his M.A., Jonathan will seek employment as a freelance videographer and p roject manager.