Lights To Play With
A physical programming interface to explore and create with lights
The inspiration for this project comes from the challenge of adding programmability to the LightPlay activity developed at the Tinkering Studio.
I would like to build a physical (block-based?) programming interface that allows people to change the intensity/color of the lights and control the speed/direction of the turntable, without using any device/screen.
The interface should be:
The goal is not to learn about coding, but to enhance the tinkering experience, allowing kids to program more complex behaviors.
One interesting interface is the one of cubetto, arranging the colored blocks on the board seems a very intuitive way to control the movement of the robot.
There are a few challenges that occurs if I want to use the same paradigm for Lightplay:
With Kibo, instructions are represented by cubes. The grammar is more expressive (for example allowing if-else and loops), but the way in which the code is loaded into the device is laborious and time consuming, as every block needs to be scanned by the device. Therefore, the experience is far from allowing tinkering.
The chibitronics microcontroller allows a very interesting behavior: it is possible to set a pattern just executing it. The controller memorize it and playback it on a loop. The principle is the same of the curlybot, a toy robot that can memorize and playback physical motion.
The idea of the record/playback is very powerful, still the design of such an interface to control more complex behaviors still poses many challenges.
As a first attempt I sketched a sequencer dashboard, where every line drives one light and there are controls like sliders to chose color and brightness, switches to select if fading in/out and a big led to preview the selected color.
I'm not satisfied with this model for at least a couple of reasons. First, the controls seem too complicated for a kid, I should make it way simpler. Also, the sequencer mode may be not very intuitive or suitable for the experience. This also leads me to more fundamental questions: what do I want the kid to learn? Is the programming interface meant to facilitate and enhance the tinkering experience or is it a way to teach a kid about loops?
As the current version of LightPlay is programmable using Scratch, I participated to a test play session in order to develop a better understanding on how computability can enhance the experience and what paradigms work best. I tried to observe and annotate the type of interactions that we used the most and that we felt needed, and I also tested the sequencer mode directly via Scratch, forcing myself to use loops and playing around with fading and change-color blocks.
The vast majority of interaction were extremely simple: while tinkering with the materials (which is the core of the activity) sometimes we needed to change the color of a light, just to see what happen, and we rarely decided to create a repetitive and stable behavior. The goal of the activity is the process itself of discovering and trying different things, instead of finding the "perfect" combination of objects and lights. This means that it might be more useful to have a simple physical interface that can directly control the color of light and speed of the turntable, rather than complex dashboards.
A simple interface could be realized using colored buttons (like in a color palette) or a simple color slider connected to every lamp. Another interesting option could be using a webcam to capture the color of surrounding objects, or any sensor that could translate into a color a physical property of the objects kids are tinkering with.
Finally, in our test play, we often found ourself trying to interact with the installation using sound, for example clapping our hand to make the turntable reverse its direction, or changing the light colors according to the music we were playing. A simple microphone to detect loudness could be an interesting addition to the lightplay tangible interface.
After the first test play I decided to move from a "programming" to a "controlling" interface, that I believe is more in line with a tinkering experience because of the ultra-tight feedback loop. Instead of programming a sequencer, the idea is to create a system that you can "play" live as you do with a musical instrument like a piano.
For the color-control interface I decided to use an artist color palette that responds to touch. The problem is how to select the lamp to which the selected color applies: there could be a switch on the palette or, even better, a sort of "brush" that you can use to select the color from the palette and apply to the lamp touching it. But I need to think more about it.
To select the light intensity, a dimmer module could be put between the palette and the lamp to control the brightness. Another module could be an oscillator that makes the light fade in and in a loop, with a dimmer to control the speed. Both these modules could be insert or removed as needed as you do with little-bits.
Finally, a knob could be used to control the speed and direction of the turntable.
As there is a Scratch extension already available for the LightPlay, I decided to create prototypes of the color palette and the motor knob using Makey Makey, cardboard, play-doh and legos.
The idea is to use Scratch and MM to build a prototype, even though in the final project there will be no computer involved.
I created a color palette simply using a cardboard as a base and play-doh connected to a Makey Makey. With the current prototype you can't control a single lamp independently, so all of them will light up with the same color, the black will put them off, while the multicolored play-doh in the middle will make them change to a random color.
I created a simple knob out of legos, and connected to a Makey Makey to control the speed and direction of the turntable.
The original idea was to have 5 different positions, with the central one corresponding to motor off and left and right corresponding to two different speeds in the two directions. Actually, the Scratch extension doesn't allow to explicitly select the direction of the turntable, so I needed to change the logic of the knob.
Anyway, the motor didn't work, so I didn't have the time to test the knob. I'll do it in the next iteration, hopefully implementing the Scratch instruction that I need.
I'm thinking about using a "paint brush" to pick a color from the real world and set it to the lamps. The I/O brush is an inspiration, but it can be implemented in a easy way using an rgb color sensor.
Although the color/motor control interface prototype seems pretty promising and opens up to whole range of different interactions, I decided to keep exploring different ways to interact with lights and colors. One inspiration came for the I/O brush and a "one pixel camera" that folks in Social Computing group are working on.
The idea is to create a small device that can pick colors for objects and transfer them to the lamp. Color sensors are available to pick the color from objects, the challenge is more on finding an intuitive (and cheap) way to manage the communication within the color picker and the lamps.
In order to analyze issues around inclusion and accessibility I choose to analyze the presentation and packages of two computationally enhanced construction kits for kids: PicoBoard and Hummingbird. Although they may look pretty different, they both consist of a set of sensors and actuators that can be connected to a computer through a programmable device.
The PicoBoard website and package show a boy and a girl of different ethnicity playing with the kit, highlighting how the kit's audience is supposed to be as wide as possible, regardless from gender, race. Also the device itself and the sensors are wrapped in plastic containers to increase accessibility, hiding the electronic components who might intimidate a non technical audience.
On the other side, the Hummingbird website and package don't highlight the kids' play experience but are much more focused on the technology, for example through images of the bare electronic boards. The package background recalls the electronic symbols and the main prompt quotes: "build your own robots", addressing a very specific audience.
These two examples easily show the tension between having "wide walls" vs "high ceiling" in terms of audience. It is pretty clear how the PicoCricket kit is designed and marketed with the clear intent of making technology accessible and inclusive, trying to involve a wide and diverse range of kids. On the contrary, the Hummingbird kit is focused on a very specific target who might be already very interested in the appealing but still narrow domain of robots.
I finally managed to make a working prototype of the color picker using arduino 101, a color sensor and a rgb pixel matrix.
I had hard time figuring out why the color sensor couldn't be found by arduino, it turned out that the connections between the sensor and the pin header were lose, I solved soldering them.
There are some issues with colors, as some of them (i.e. yellow) are hard to detect and reproduce on the led matrix. I can try tweaking with some values of the gamma map, but for now I'm pretty satisfied.
The next step is making arduino communicate with the lightplay. It turnes out that both arduino 101 and the lightplay board's BLE work in peripheral (i.e. client) mode, so they can't communicate directly without a computer or smartphone that act as a server. Also this time, I'm going to use Scratch as a middleware, as there are extensions available both for lightplay and arduino 101 (that requires some work).
Another thing to figure out is the design of the box for the camera and the user experience.
I've found a vacuum cleaner sweeper that could work as support for the second prototype. It is pretty ugly but the size and shape works pretty well, I'll make it more beautiful in next iterations. Also the metaphor of the vacuum cleaner works pretty well, and has been used for a similar project (Suck my Rainbow) that Mike pointed out.
I managed to get rid of the breadboard and to connect the LED matrix, button and RGB sensor directly to the Arduino 101, with no additional PCB. The only thing I had to do was creating the connectors (which practice made me much better in soldering) and finding a box for the Arduino (the Media Lab business card box turned out to be perfect!)
Also for this prototype, we decided to use a Scratch extension as a middleware, using a laptop as a central BLE server.
Ben integrated the bluetooth communication on the Arduino code and created two new block on the LightPlay Scratch extension to receive RGB color values: "when color changed" hat block and "set light to red - green - blue".
If you want to take a look, the code for the Arduino is on github.
Mike showed me a very similar project called Suck My Rainbow.
The metaphor of the vacuum cleaner is very nice, and the idea of using the rgb led on the cable to simulate the color "sucking" is very powerful!
For tomorrow's presentation I created a document draft that helped me think about the 5 guiding questions that I will address.
Who did you design this for?
The LightPlay experience is designed for kids of all ages, and so is the color picker. That said, I tried to concentrate more on the lower and of the age range, particularly focusing on pre-school children, between 4 and 6 years old.
My first goal was to create a physical programming interface but I soon landed to a physical controlling interface.
One of the reason is that the essence of a tinkering experience is having a very tight feedback loop, but also focusing on young kids was the reason why I chose to focus more on an immediate response to simple actions rather than providing the infrastructure to create complex patterns.
Also, keeping this age range in mind, the color picker interface is really simple, consisting in only one button that activates the sensor when is pressed, immediately transferring the picked color to the LightPlay lamps.
Why did you design this for them?
Because they are sooo cute! :)
The early infancy is the time of our life in which we start noticing and discovering concepts like shadows, reflections and colors, so the LightPlay experience itself is particularly suited for that age range.
Specifically, the color picker enables an unexpected interaction between the physical and digital dimensions, transferring something intangible as a color from an object to a lamp. The experience of exploring an environment to pick a color they like binds to the sensory-motor skills that develop at this stage.
What / how are they learning through play?
- creativity: using the world as their color palette (digital / physical interaction)
- exploration: be more aware about the colors around them
Future development / directions?
- make it more robust, small, nice)
- control specific lamps
- games without LightPlay
- find a specific (prompted) color
- create your palette
Ben and Andrew - tech support
Kim, Yonatan, Mike, Tiff, crit group - ideas and inspirations
Mina - video
The Tinkering Studio, Scratch Team
Here is a short video to show some examples of the play experience.
Also the video is a "prototype", but it will be very useful during the presentation.