Archive for September, 2011

Biofeedback with Arduino [maker faire session]

Wednesday, September 21st, 2011

At the New York Maker Faire this past weekend Mustafa Bagdatli [http://mustafabagdatli.com/] and I led a hands-on educational session at the ITP pavilion. Our focus was to teach people how to use the Arduino to sense a person’s level of arousal. We want to create an intro to physical computing session that focused on using sensors to capture data about our internal state, rather than the external world.

Here are some pictures from the session, followed by an overview of how the sensor works, and a description of the circuit schematic and the Arduino code.

To sense a person’s level of arousal we take a measurement of their sweat level in order to gauge a their Galvanic Skin Response (GSR). GSR refers to the changes in our level of sweat that happen throughout the day in response to stress, anxiety and excitement. Most often, these changes are so small that we are not even conscious that they are taking place.

We had originally billed the event as build your own lie detector. The reason being, since most people become anxious or stressed when they lie about something that is important to them this technology can be help detect a lie – at least in an unscientific setting. However, after the session we realized that this is a much better embarrassment detector.

We are able to measure GSR with an Arduino because our skin is able to conduct electricity more effectively when it becomes moist due to sweat, the Arduino can detect our sweat level by monitoring these changes to our skin’s resistance. We can accomplish this by attaching two electrodes to our skin, the first providing a small current of electricity (30 to 50 mA), the second reading the amount of electricity that is able to make it through our skin.

Note that the GSR sensors needs to be placed near each other in an area of our body that is prone to sweat. Our fingers, arm pits or feet are all good locations. The sensor we used for this workshop were attached a finger strap. Another important consideration is making sure that the sensors are attached snuggly so that they stay in constant contact to a person’s skin.

Here is an image of the circuit for this project:

The electrode that is used to capture the electricity must be connected to an analog input pin on the Arduino and to ground via a pull-down resistor with a value of 10k Ohm or greater. You may need to test a few different resistors value to find the best appropriate one for you set-up.

The code for this project is quite simple, we take a reading from the GSR sensor and use this value to determine how many leds should light up – one to four, depending on how sweaty you are. Here is the full sketch


ITP Cafe [success at maker faire]

Tuesday, September 20th, 2011

I spent this weekend at the Maker Faire helping to coordinate the activities at the ITP Pavilion. I worked on planning this event with Tom Igoe over the past 6 weeks. By all accounts it was a success. Here is a slide show from the weekend’s events:

We held ten different hands-on sessions that covered a wide range of topics including: cardboard prototyping, sensors and arduino, programming with processing, creating soft circuits, hacking the kinect, screen printing, organic circuits, and wind power generation. 

I am very thankful to all of the session leaders and volunteers who helped make the event a success. Here is the official roll call/shout outs.

  • Session leaders in order of presentation: Chika IIjima, Jer Thorpe, Catarina Mota, Greg Borestein, Emily Webster, Rune Madsen, Patricia Adler, Nelson Ramon, Michella Johanna Cardona.
  • Volunteers in order of shifts: Martin Bravo, Molly Schwartz, Morgen Fleisig, Robert Carlsen, Eric Rosenthal, Adi Maron.

Over the past six weeks I worked closely with Tom Igoe to organize the events at the ITP pavilion. This was a great opportunity for me, as Tom is one of my favorite professors from ITP. Tom introduced me to physical computing two years ago when I was a first year student in this awesome program. He is also one of the founders of the Arduino project. Now I am officially hooked on both physical computing and Arduinos.

This was also an chance for me to stay connect to and contribute to the ITP community. During my time at ITP I sometimes felt that I took from the community more than I gave back. Also, now that I have graduate I realize that I need to make more of a concerted effort to remain connected to the community.

Aside from helping to coordinate the event, I also had the opportunity to teach an intro to Arduino session with Mustafa Bagdatli. A link to more information about our session will be added here soon. I look forward to other opportunities to share my knowledge and passion for physical computing and the Arduino platform with other “13-year old boys of all ages and gender”.


More Eagle [design rules, cam, and script files]

Monday, September 5th, 2011

I have started to work with Eagle again to create a few new prototype PCBs. Before getting started I have decided to delve a bit deeper into how Eagle works. More specifically, I wanted to understand the various different configuration, rule, cam, and script files that are used by Eagle. Here are my notes from this little bit of research.

Design Rules (.dru files)
Eagle enables you to define design rules that can used to check your design. Design rules help ensure that your creations meet the specifications associated to the prototyping or manufacturing process that you plan to use for your project. Once you got your design rules set up right, you can save them so that they can be applied to multiple different projects.

Here is a short list of the types of design rules supported by Eagle:
- information about the number and types of layers featured in your design
- clearance between different objects in the signal layer of your boards
- minimum distance from holes and the edges of your board
- width of the tracks that connect different components
- size vias that connect tracks on different layers of your board
- shapes of the pads, which are the exposed copper where your components are soldered

I personally have a two different design rules files that I use frequently. The first holds the design specifications for creating prototypes on a Rolland Modella CNC; The second holds the rules for manufacturing boards using Advanced Circuits. I did not create either of these files; the former was developed at the Center for Bits and Atoms at MIT, the latter was created by Sparkfun. Below is a screenshot of the design rule check (DRC) window.

Eagle: Design Check Window

CAM Jobs (.cam files)
In Eagle, CAM jobs refer to scripts that are used to generate Gerber [http://en.wikipedia.org/wiki/Gerber_file] or other types of files that can be used to control CNC machines. Do not confuse a CAM job file with a CAM file. The Gerber files that are generated by Eagle are CAM files, as well as a wide range of other file formats used to drive CNC machines.

More about CAM: CAM stands for Computer Aided Manufacturing. Wikipedia defines Computer-aided manufacturing (CAM) as “the use of computer software to control machine tools and related machinery in manufacturing”.

CAM is a process that is used to manufacture objects created with Computer Aided Design (CAD), or Engineering (CAE) tools such as Eagle. CAM files are used to drive computer numerically controlled (CNC) machines and tools, like the ones used by PCB manufacturers.

Script Files (.src files)
Every Eagle operation can be carried out using script commands written in the Eagle command language. These script commands can be input individually, in the command line at the top of the a project window, or joined together into a script file. These files can be created with a simple text editor, and they can also be generated and exported from Eagle based on work that you created in the any of the Eagle modules.

The configuration for any given installation of Eagle is saved in a script file called Eagle.src. Several sample Eagle scripts are provided in src folder as well. Scripting is a very powerful feature in Eagle. On a personal level, I have never created a script file; my use of Eagle scripts has been limited to single script commands used on the command line.

User Language Programs (.ulp files)
User Language Program enables the use of C-like programs to access the functionality available through Eagle command scripts, and to import and export data into Eagle. This is definitely way above my current level of expertise in Eagle.

The Eagle.def File
The Eagle.def file holds the specifications that Eagle uses to create output (including files) for various different devices. The devices and files that are specified here range from printers and plotters to computer aided manufacturing formats such as Gerber files.

Eagle: Eagle.def File

Adding and Removing Libraries to your Project
To remove libraries from a project you can do this using the context menu in the tree view window. Just right-click on the appropriate project folder and select “use none” from the context menu. Once that is done you can create a schematic file, then add the libraries you want for your project by clicking on the library icon, which looks like two books and is located next to the script (SCP) icon.

Eagle: Context Menu (Removing Libraries)

Here is a link to an older Eagle tutorial that I posted a few months back. This tutorial features links to a bunch of useful resources, ranging from Eagle libraries to in-depth how to guides from Sparkfun.


PCB Prototyping [getting the fablab machines up and running]

Saturday, September 3rd, 2011

Since the beginning of the summer I have been wanting to prototype PCBs using the FabLab at the Sustainable South Bronx (SSX) studio. Over the past weeks I have been working to get their Roland MDX-20 3D plotter (a.k.a. Modella), and the Roland GX-24 vinyl cutter (a.k.a. Camm) up and running again. The first two weeks were rather frustrating – I floundered trying to find and then install the required software on my MacBook running OSX. Here I will provide a brief overview of the issues I encountered.

I am happy to report that I have finally started to make some real progress over the past few days – though it only happened once I switched to Linux. Next week I will create my first PCB prototype on the Modella. I will write a tutorial about getting stuff up and running after I have this initial prototype done. For now here is the story of my failures.

Choosing the Software
The first step was to find and install the right software to run the Modella and Camm from my laptop. Both of these machines come packaged a software suite from Rolland. Unfortunately, these applications are not designed for creating PCB prototypes, which is my main focus. Another issue is that they only run on Windows; and I was also not able to install them on the Windows virtual machine running on my computer.

MIT Media Lab to the rescue. Luckily, the Center for Bits & Atoms has released software that is specifically designed to work with FabLab machines such as the Modella and Camm (and many others). Their software is more flexible than the standard applications that come prepackaged with these devices. Best of all, they provide really good support for creating PCB prototypes with these machines.

The first of these is Cad.py. As the name implies, Cad.py is a set of python scripts that can convert, process, and run CAD files of various different formats on FabLab machines. Most of these machines are only able to run one or two different types of file; and these files formats are not usually supported by CAD applications.

The second MIT app is called Fab Modules, it is also known as Kokompe. This app is just a more recent version of Cad.py. It features a lot of the same functionality with a more user friendly interface. Here is a link to the Kokompe website. Its tag line reads “software for machines, that make themselves, other machines, 3D objects.” Pretty cool.

Both of the MIT applications are developed to run on POSIX-compliant Unix and Linux systems. As with any Linux or Unix applications, they can only run on systems that support the full stack of required libraries and utilities. For an unexperienced Linux/Unix user like myself, the process of figuring out if you have the software stack, and the process of finding, downloading, and installing the missing items from the stack, can be rather hellish.

My First Attempt
Initially I wanted to run both of these machines directly from my MacBook, using OSX Darwin. In retrospect this was a stupid idea – my stubbornness caused me a lot of frustration, and led me to waste a lot of time.

I should have changed course when I came across the MacFab website from RWTH Aachen University. They have been working on making it possible to run FabLab machines using Macs for a while now. Their website provides valuable information, such as details about all the FabLab tools that they have tested (successfully, or not). Here is link to the MacFab page from the Media Computing Group at RWTH Aachen University.

I spent a lot of time learning how to use Fink and MacPorts to download the Mac-compatible versions of all the libraries and packages required for the Fab Module and Cad.py stacks. This process was rather frustrating, as each stack requires very specific versions of each package. I wasted a lot of time trying to get these apps running on a stack with Python 2.7; now I know that Python 2.6 is the only version supported.

The Final Verdict
After many days of work I was finally able to get Fab Modules to load on my MacBook running OSX. Unfortunately, I quickly realized that only some of the functionality was working. I was able to view load files but I couldn’t convert, process or run those files.

That’s when I decided it was time to switch gears and give Linux a try. I am glad I did because in a few short hours I was able to get things up and running. More on that on my next post.