The ‘smell box’ has finally arrived! It is based upon the same container as the prototype (so currently a bit large), and uses the same low power PC blower to move the air around. A 4N35 opto-isolator is used to separate the littleBits circuit from the circuit that powers the fan (which is controlled by a BC547), and the whole thing is powered by a 11.1V LIPO RC battery:

Similar to the Sound Box (see below) the Smell Box has littleBits circuitry integrated, and can be activated by any of the littleBits triggers:

The ‘smell’ itself is placed inside a small box embedded in the lid of the Smell Box. There are some ventilation holes drilled in the smell container (the off-white thing in the lid) and also a number of vents scattered around the box itself. It was tested with a piece of goat cheese:

To contain the smell of the cheese, the lid was pressed onto the smell container (which is almost air tight). However, the circulation was quite poor (despite the numerous ventilation holes), and so was tried again with the lid partially off:

This was better, and you could get a good sense of the cheese smell wafting from the box. But the design could be improved significantly in a number of ways:

1. A much more powerful fan is required to get air circulating properly. A PC case blower seems to be a bit too weak for this purpose.
2. The smell container needs to have some form of mechanism to contain the smell when the device is inactive. This could consist of a simple set of spring loaded flaps which isolate the smell, and which open only when the device is triggered and the fan starts.
3. More ventilation holes in the main box, so that a good air volume is produced. Currently the air volume from the device is quite low, and so the smell is rather ‘subtle’.
4. The air vent from which the smell emanates is currently to low down, and would ideally be placed on or near the top of the box.

We will trial this next week (18 Nov 2013) and see what happens with our target group. A report of how well it worked will be posted here soon.

In the meantime, we’ll be developing version 2 of the smell box, and include the improvements. Rather than hack boxes to pieces to make the new version, it would be a good idea to 3D print the next one. We’ll post the design on here when it is ready.

The Sound Box has had another update, and now includes an external speaker socket. this means that it can be plugged into an external amplifier/speaker or some other output device that can handle the analog signal. The image below shows the new jack socket with a device already connected via a jackplug:

In the next image a surface transducer (a surface speaker) is plugged into the Sound Box. The transducer itself is attached to a 1.2mm zinc plate with a strip of BlueTack. The transducer makes the zinc plate vibrate to produce sound.

The final image is a close-up of the transducer. You can buy these for around £5.00 each (or less) from many outlets on the web.

The next experiment will be to connect the Sound Box to an external amplifier, and from this to a much more powerful speaker. The speaker will be attached to a metal plate and we will look at how the sound waves propagate on the surface of the plate to produce patterns (visible using fine sand or powder).

For one of the forthcoming workshop at MERL, we might explore how potatoes can produce energy using a setup similar to this, and demonstrate that you can do more with a potato than boil it, mash it or make chips (french fries, if you are not from UK). The images below show the simple battery setup using a zinc plate and a copper plate with a small gap between them.

A potato (or two in this case for a larger current) is placed across the plates:

The current measured across the plates was about 160uA:

The next stage of development will be to drive a set of LEDs to indicate the current generated.

The (temporary) sound boxes have been updated so that they can be triggered via littleBits circuits. Each box now has two littleBits connectors at one end – one for input, and one for output. They have been tested using a simple toggle button on the input side, with an LED connected to the output:

The pilot workshop at MERL was based upon two main activities, both relating to sound. The first activity involved looking for objects around the museum that could have produced specific sounds that we provided on custom-built sound players (which we informally refer to as the ‘Sound Boxes’):

The sound boxes were designed to be as simple to use as possible: turn the dial to one of the six positions, press the big button and the sound will play. We have used sound recorders/players in previous workshops, but they are often very complicated to operate, and therefore require someone to assist in using them. For this pilot, members of the group were given the sound boxes and asked to try and locate the source of these sounds from around the museum. The activity itself worked very well and engaged the group members. The boxes themselves also performed very well too, and produced good clear sounds. More importantly, everyone could use them.

The sound boxes were also used in the second activity, along with various other sound making objects, to produce a soundtrack to a silent movie clip.

We are planning on extending the capabilities of the sound box to more sounds, and possibly create distinct players for different categories of sound. i.e. one for mechanical noises, one for animal sounds, etc.

Ahead of the Autumn workshops planned with Reading College, Kate, Nick and I have planned a session with a group from Mencap Reading to test out some ideas and Nick and Craigs new sound storing boxes (to be revealed!).

Here is how we have planned the day:

Attendees: 3 researchers (Kate, Nick, Kassie), 6 Mencap co-researchers, 2 support workers.

When: Thursday 5^th September – 10.30am – 2.00pm

10.30am: Welcome Talk: Introductions from everyone, explain the day ahead, short    tour of MERL.

11am: Recognising Sounds: Scavenger hunt where co-researchers hunt to find objects that make the sounds they can hear from the device.

12pm: LUNCH: Picnic lunch inspired by the collection at MERL.

12.40pm: Making Sounds: Sound making workshop where we will create and record sounds using instruments to accompany video clips from the rural past.

1.50pm: Review: Review of the day. Quick questionnaire for co-researchers.

(more…)

The projects examined in previous posts had a lot of interesting concepts and ideas- this is a condensed list of them, with recommendations for future attempts.

===============================================================

Squishy Circuits:

• Non-prescriptive medium. Unlike other ‘modular’ approaches which can only be fitted together in certain ways.
• Similar to, and in some senses more flexible than designing PCBs or electronic circuits.
• Use of familiar materials (clay, playdough).

Tern:

• Modular components.
• Inactive components. The blocks themselves contain no electronics, simplifying their design and allowing them to be more robust and cheaper.
• External processing. Interpretation and running of the program is performed by a device not physically attached to the program.

littleBits:

• Modular components.
• Strictly colour-coded categories of piece – input, output, power, wiring, etc.
• Keyed connectors. Can only be fitted together one way.

Tangible Programming Bricks:

• Modular components- each representing a ‘function’.
• Parametric components. Timing or other aspects of each function can be altered.
• Direction-insensitive connection. Modules can be attached any way round.
• Familiar materials – Lego.

Electronic Blocks:

• Modular components, all inputs and outputs.
• Icons to indicate function, instead of text.
• Familiar materials – Lego.

Reactable:

• Local medium- programs can only be created in a certain space, and only affect that space.
• Multifunctional modules- some modules have different effects depending on their orientation.
• Symbols to indicate function. Function must be determined by experimentation or reasoning.
• Proximity-based connections.
• Virtual tangible user interface. GUI elements are attached to physical elements, and are manipulated as though they were tangible objects.

StoryRooms:

• “Wizard of Oz” interface- all functions are actually performed by a man behind a curtain.
• Programming mode/playback mode- system is taught, then reacts based on this teaching.

Cuboino:

• Track as program- the purpose of the ‘program’ is to direct objects along a path, which set off outputs as they pass by.
• Modular components
• Active components
• Inactive components

GameBlocks:

• Modular components
• External processing

Dr. Wagon:

• Modular components
• Active components

Topobo:

• Modular components
• Active components
• Passive components
• Programming mode/Playback mode

===============================================================

PRINCIPLES COMMON TO PREVIOUS PROJECTS:

MODULARITY:
Nearly all tangible programming interfaces use modular components, where a single block, device, or item represents a function or serves a single purpose. Programs are created by putting these components together.

ACTIVE/PASSIVE COMPONENTS:
Some had the components themselves provide power, processing, or effects, whilst others had a dedicated power supply, or offloaded these functions to an external device. Both approaches work well, though self-powered and processing devices tend to be larger and more complex. This may not be a downside- larger components are more easily manipulated.

FLEXIBILITY:
Schemes involving ‘active’ components tend to be less flexible with regards to their connections. They have to be connected in one or two ways, limiting the physical structure of the programs and thus the possibility of incorporating them into other devices.
Many schemes were created to control a specific device, such as a turtle or microwave. Few were able to interface with a variety of sensors and effectors in the same manner as the Arduino.

IDENTIFICATION OF FUNCTION:
Most modules’ functions are indicated to the user by icons. These mean users do not have to be able to read in order to use them. None of them actively used texture to indicate function, but occasionally had surface details as a side-effect of their design. Colours were often used to group modules into categories.

===============================================================

RECOMMENDATIONS:

Modular components are a useful way of providing flexibility whilst still giving users some pre-defined functions to use. Manipulating several small objects, each with a clear individual function, is easier than a “blank canvas” like a word processor.

Active components, being those which provide their own power or processing, are more complex and therefore more likely to cease functioning or malfunction. This may be due to failure of their power supply, damage to their circuitry or mechanisms, or from poor connection to other necessary modules. Modules should be kept as simple as possible.
Passive components, although more robust and simpler, cannot provide some features that active ones can, like the ability to ‘test’ a module without connecting it to a program. Active sensors or outputs could be constructed with a ‘test’ button to trigger their output, or sensors could be given an indicator to show when they have been triggered.
Both approaches would be suitable, though it should be noted that passive components will require an external processor which may introduce complications.

Connectors should be keyed to prevent damage to the components, and to prevent frustration of the users- if a connection is incorrect but this is not indicated to the user, the device may not function as expected, with the fault being difficult to locate.
Ideally, connectors will be able to accommodate several different orientations to permit the programs/devices to fit into other creations more easily.

It should be made possible to interface with a wide variety of sensors and effectors, rather than limiting control to one device- given that the project’s aim is to simulate sensory experiences, limiting the possible types of experience is counterproductive.

The function of a module should be obvious from its features. This should be accomplished using as many senses as possible, rather than simply writing the function of the module onto its casing. Icons should be preferred over text.

External processing does make individual components simpler, but introduces complications as the interface between the program modules and the external processor must be reliable.
It also allows for software upgrades to be applied to the processor, without having to alter the program modules. As these are likely to be embedded systems, compared to an external processor which has fewer restrictions on size and power, upgrading its software is probably simpler.
It can also more easily accommodate new modules, as only the processor must be updated as opposed to all modules.

Reading University has a 3D printer, which we planned to use for this project. It uses ABS, which is durable and despite only being available in one colour,c an be relatively easily painted if necessary.

The printer is compatible with Solidworks (or anything else that produces .STL files), which allows for precisely-made parts to be produced to scale.

The case, littleBits connectors, and the three ‘top’ designs have been printed (still learning to use the camera!):

This is the hex-top. It has had to be extended upwards to accomodate the internal parts.

 

 

 

 

This is the dome top- it was tall enough already. The shaft of the rotary switch used to select the sound has been cut to fit.

 

 

 

This is the original ‘pie’ top, again, extended to fit.

 

The current design makes them relatively easy to change, but this does mean that the tops could be removed by a user. Future versions will require bayonet lugs or some similar mechanism to hold the top on.

The littleBits connectors are generally the right size, but the small prong and socket is too fragile in 3D-printed ABS. They are also slightly the wrong size and do not fit cleanly. It has already been noted that they will need holes for magnets and electrical connections, so future versions will incorporate these changes.

 

Kate and I are planning to hold a preliminary sensory session with a group from Mencap at MERL in September. Hopefully this will be a good time to test out the audio prototype and some ideas planned for the Autumn sessions.

We visited the museum and the archive at MERL

We considered existing objects that could contain sensor and listened for sounds used in the existing collection.

We found that videos are used in the museum although most of the films have no actual sounds of the activity instead a narrator describes the activity. The videos of crafts pictured below do feature sounds of the process.

Here is a compilation of the range of sensors and outputs we can use, or could make ourselves (to be compatible with LittleBits) to get an idea of how much choice we really have! (the ones marked in bold are already available to purchase in LittleBits)

Sensors: light, sound, bend, roll switch, toggle, motion, pressure, slide dimmer, pulse, time sensor, stretch, tilt, accelerometer, blow, proximity

Output: fan, light, sound, buzzer, motor, vibration, rgb LED, bargraph, smell (based on olly factory/aroma company), video

Also, LittleBits supply AND and OR logic gates which add complexity to the circuits.

Just as a log: In our meeting last week, we also talked about practical ways to introduce and demonstrate the co-researchers to the concept of the different sensors overcoming the problem that the sensors don’t look like what they do (e.g proximity sesnsor looks like a phone). Here is a list of some of the ways we discussed:

light sensor in a box, bend sensor in a foam noodle, pressure sensor in a stress ball or shoe, blow sensor in a windmill, motion sensor in a wand, accelerometer in a bottle with oil and water.

Please feel free to edit this post with other ideas or if I have missed anything out!