Pictor
An interactive installation in a form of a drawing machine, exploring the relationship between human and machine, but also how technology might become an extension of humanity. As we create technologies, these technologies become carriers of our intentions, and hence extensions of them.
produced by: Darja Peterca
In continuation to last year’s degree show, where I exhibited an on-screen interactive installation in a form of a drawing machine, my main focus for this year has been to explore different ways of building drawing machines that are not only screen based, incorporating physical computing and developing my programming knowledge.
The Concept
I’m inspired by the relationship between man and machine, and how humans get affected by it, but also the interaction between the two. Rather than creating a viewer that is expected to observe artworks, I am interested in producing artwork that is engaging and that people can interact with. The viewer is prompted to provide an ‘active’ input in order to influence the artwork’s outcome. He/she can therefore develop or extend it through her/his interaction with it, perhaps rendering the work as a catalyst for a dialogue with other viewers, eliciting some form of social change. Furthermore, the machine becomes an extension of a human, expanding capabilities of the human intellect and vision to innovate. Humans are deeply connected with the emerging interactive personal technologies. As time goes by, people are increasingly becoming reliant on this technology in such a way that it is becoming natural behavior. On one hand, personal interactive technology can be said to empower the user by extending physical (through virtual reality) and cognitive abilities. On the other side of the spectrum, critics ring the alarms of the effects of dependency on electronic devices. It seems that human fascination for progress and improvement often triumphs over awareness of how such technological extensions change the way humans relate to the world.
The Background
The initial idea was to utilize a 'marbling' technique or so called 'Ebru', which is a traditional painting technique that involves painting on water and uses a type of paint that doesn't dry fast or mix the colours together. After experimenting with it I realised that it sticks to surfaces, which soon resulted in a smudge. The drawing machine would create constant transformation of patterns and the whole process would be filmed in real time and projected on the wall. In 'Ebru' the artist constantly cleans the paint of the nozzle, but it would take a lot of engineering to build a self-cleaning system for a drawing machine, which is why that idea was ruled out. What followed was a series of sketches that explored different structures and drawing techniques. In one of my previous projects I explored accidental/automatic drawings, derived from “Drip painting” or “Action Painting”, that was used predominantly by artists such as Jackson Pollock and Max Ernst. But rather than using bare hands to drip the paint onto the surface, I thought of a way to summon people to interact with a machine creating those marks, that renders machine as an extension of a human hand.
The Interaction
After an extensive research into sensors and different types of inputs that encourage hand interaction, what caught my attention was Leap motion, a sensor device that supports hand and finger motion as input, but requires no hand contact. When thinking of different hand movements, what came to mind is the actual shape of the hand. If every finger triggered a bottle, it would generate five marks on paper. After searching for different ways to trigger the bottles, I delved into a world of robotic hands and claws, and managed to find one already manufactured that can be attached to a servo motor. The claws are made out of aluminium and are fairly sturdy. Because of their design, the joints have to be loose to be flexible, so they appear slightly limp, which is not the case. However, the claw did not come with any instructions, and soon after mounting them onto the servos, two of them suddenly ceased to function. My theory is that those two servos were mounted out of their operating angle which slowly wore them out. However, mounting them within their range has proved to be challenging.
The Design
The initial designs of the base weren’t as effective; for instance, the paint dropping on a sheet of paper at an angle to drain off the paper would require a lot of maintenance. Thus, I re-designed the base plinth so that it does not need as much care.
On one side of the plinth there is a dowel axle with a roll of paper attached. The paper is then attached to another roll on the other side of the plinth, where a stepper motor turns every time a Piezo sensor senses the paint drop onto the paper surface. There is also a manual button to spin the motor. Both of the rolls are detachable so that the paper can be replaced when necessary.
Both 2D and 3D CAD software was utilized to make the delivery of the project more efficient. Concept designs were built in Sketchup, which allowed to explore and compare more options than building physical mock-ups. Cutting layouts and junction details were worked out in 2D drawings to make sure everything fits together as intended. A bespoke stepper motor mounting bracket was designed and 3D printed to fit the rolling mechanism as required.
The dropper bottles are fixed inside a bespoke pendant box. There is a hidden service hatch for all the electronics at the rear of the box, which can be accessed by lifting the top if any maintenance is necessary. The nature of the project demands the presence of a computer to run the software as it is sending data through the Serial port. Raspberry Pi was considered but had to be ruled out for its incompatibility with Leap Motion.
The Technical Process
As mentioned above, hardware and software choices were dictated by different factors. Firstly, I had to choose the right motors. I had previously used Hitec-HS311 Standard servos, but they proved to have insufficient torque to squeeze the bottles.
They are relatively quick (0.19 / 0.15 sec @ 60 deg.), but have a torque of 3.0 / 3.7 kg/cm. (4.8V/6.0V). Unfortunately, they weren’t able to put enough pressure on soft PET (polyethylene terephthalate) bottles. Evidently, what I needed were stronger motors. After searching for a right one for weeks, Savox SC-0251 seemed like a good choice as it has a high torque (16.0 kg/cm), meaning that the motor has enough power.
Secondly, one of the main issues I encountered was creating a circuit that wouldn’t damage Arduino or the power supply. Servos are typically used in battery-powered applications, but since this is a static installation, a wall power supply proved to be a more reliable option. In the beginning, servos were powered with a 6V/3A power supply, but I did not realise that standard servos usually have a stall current of around 1A, which meant that they were drawing more current than the power supply allowed, resulting in its failure. I then decided to use three 6V/3A power supplies, powering the motors in pairs and the odd one on its own. However, once the motors were powered, there was a constant jitter present without any kind of hand interaction, which would possibly cause the paint being squeezed from the bottles involuntarily. My initial theory was that the jitter was caused by excessive variations in voltage and perhaps a voltage regulator that generates a fixed output voltage of a preset magnitude would fix the issue. However, professor Phoenix Perry, suggested to use a relay circuit. This enveloped using any Relay above 6V (I used a Goodsky GS-SH-212T Subminiature Relay 12V DPDT), a NPN transistor, a diode and a 2.2Ohm resistor.
Furthermore, just as with Raspberry Pi, Arduino is not capable of running Leap motion software, so I had to search for a different way to control servo motors with Leap motion. After researching for the most efficient way to do that, I realised that Node.js has a library called Johnny-Five, which consists of JavaScript components that know how to talk to an Arduino through the “Firmata” protocol – a standard protocol for computers to communicate with microcontrollers from software on a host computer.
Source code:
https://github.com/DariaDee/Pictor
References:
http://oomlout.com/a/products/ardx/circ-11/
Perch, Kassandra, Learning Javascript Robotics (Birmingham, UK: Packt Publishing Ltd., 2015)
Sanders, Brandon, Mastering Leap motion (Birmingham, UK: Packt Publishing Ltd., 2014)
Waldron, Rick et al., Make: JavaScript Robotics: Building NodeBots with Johnny-Five, Raspberry Pi, Arduino, and BeagleBone (San Francisco, CA: Backstop Media, LLC., 2015)
http://www.schmalzhaus.com/EasyDriver/Examples/EasyDriverExamples.html
http://johnny-five.io/examples/led/
https://www.youtube.com/watch?v=LMab6ZH3YCg&list=FLHMWxRvjNmJRU7-btciwXaw&index=2
https://github.com/rwaldron/johnny-five
https://bocoup.com/weblog/javascript-relay-with-johnny-five