posts tagged with the keyword ‘museum’

2016.01.25

Video Installation

Last summer Ray Chi got in touch with me about an installation he was doing for the Milwaukee Art Museum. He wanted a video screen that could be activated to play a video by touching a metal plate. Well, actually six videos and six video screens and six metal plates.

I told him I’d figure out how to get it all to work the way he wanted. I came up with a few ideas, one of which was using Processing, which I did get working, but at the time Processing wasn’t really running on the Raspberry Pi, at least not officially (or very well) and since the Pi was what we ended up choosing, I needed another solution.

For an installation that’s going to be running for years, simplicity and reliability are key. I had used Pis in the past many times for video players using omxplayer. Typically I’d just launch omxplayer on boot and have it play a video, looping, forever. For this application we wanted the video to play only when the metal plate was touched by a human hand (and then stop playing when someone stopped touching it) which meant capacitive touch.

Rather than spend a lot of time coming up with something that might work, I went with something that I was 98% sure would work. I used Adafruit’s Standalone Momentary Capacitive Touch Sensor Breakout attached to a Teensy LC. Why a Teensy LC? Because it’s a low-cost (LC!) Arduino-compatible microcontroller and it can emulate a keyboard.

Yes, a keyboard! If you have a USB keyboard connected to a Raspberry Pi computer while omxplayer is playing a video, you can just hit the space bar to play the video, and then hit it again to pause the video. Those are the two things we needed to do.

Video Player Controls

So, Raspberry Pi, running omxplayer to play the video, with a Teensy LC attached programmed to work as a USB keyboard, and triggered by a capacitive touch sensor, which was then connected to the metal plate. Simple!

There was this issue of……. timing.

So in theory, the Teensy would just need to send a space character to play the video, and it would do this when you touched the metal plate. But! (And it’s a Big But) the issue was that we wanted the video to start playing at boot and then pause at the beginning and sit there waiting… for someone to touch the metal to start the video playing. Rather than fire up the video via the typical Linux methods, we ended up just starting up the Pis, auto-logging in, and having them wait at the command line… yes, just sit their waiting, doing nothing… Sort of.

When the Pi booted up, it provided power to the Teensy, which then started running its sketch. The sketch would start at boot, wait 45 seconds to ensure the Pi was booted up and sitting there waiting at the command line, and then it would type:

/bin/bash /boot/video.sh

So we actually used the Teensy to send the text to the Pi (just as if a human typed it) which then fired up the script and started the video playing. The sketch would then wait 2.4 seconds and type a space character, which would pause the video. This set the state of things exactly where we wanted them. The video way paused, just waiting for the next command from the Teensy, which was… space, of course!

Now, there’s the concept of “rising edge” and “falling edge” when it comes to pressing buttons. A rising edge is the transition from low to high, and a falling edge is the transition from high to low. That’s a fancy way of saying we can tell when the button is being pressed, and when it’s being released. It’s best to use debouncing for this, and there’s a library for that.

Video Players Mounted

So with everything mounted in place we still had to deal with one issue. The HDMI displays worked find as long as they were turned on before the Raspberry Pi computers. If they were turned on at the same time the resolution wouldn’t set right, and the video would be letter-boxed. There were two options, one would be using two different power strips to get power to everything, with instructions for museum staff to follow a specific order. This wasn’t ideal, so we went with option two. I used a time delay relay so that one single power strip could be turned on, which would turn on the HDMI displays, and then a few seconds later turn on the computers. It worked. (And yes, I found out later I probably could have fixed the issue in software. Duly noted.)

Are there things we could have done better? Yes. Did we get the project done on time, and within (or under) budget? Yes. Was it fun and challenging? Yes and Yes. You may read this and think “Hey, you totally could have solved problem X by doing Y!” and you’d probably be right. I’ve found a number of things I’d do slightly differently if I were to do something like this again. That’s all part of experience, and learning, and sharing… right?

Video Player

When the installation was all done and tested, I got photos of everything, and then set to work on documenting it all. I delivered a 14 page manual on the construction and operation of the video players, along with the code and instructions on how to use one of the backup SD cards that was prepared in case of failure.

Besides, now I can (sort of) say that my work is in the Milwaukee Art Museum. ;)

2015.12.11

Because when you’ve got a 3D printer… You might as well print things…

3D Printing

3D Printing

3D Printing

3D Printing

3D Printing

3D Printing

3D Printing

3D Printing

3D Printing

3D Printing

Also… OpenSCAD.

2015.12.09

Teensy

I’m working on a new exhibit that will be using an Arduino (actually, a Teensy++ 2.0) to talk to an application running on a PC via serial data. The Teensy will be sending one byte to control the application’s behavior. This is an upgrade from an older version where the Teensy just sent keystrokes to the application. The nice thing about sending keystrokes is that it was very easy for anyone to troubleshoot because they could just open Notepad and press some buttons to see if they were sending any output. The bad part was that if a normally closed switch was open, it would just stream characters to the computer, which could make things hard to troubleshoot for some people.

ATMTester

To deal with the troubleshooting issue (which will eventually come up, as it always does) and make it easy for non-technical people to view a serial data stream, I wrote a simple application in Processing that reads the byte and displays the value, along with the status of each physical control of the exhibit.

ATMTester

The exhibit should always have the Teensy plugged into COM3 on the PC, but again, once something leaves the shop we never know what strange things might happen. When the application starts up it will present a dialog showing the COM ports, and asking you to select the correct one. If you select the wrong one it will just display nothing. This should be enough to help troubleshoot things via phone or email.

The trickiest part was the code to choose the COM port. (I know, we don’t call them “COM ports” on Mac OS X, and yes, the application works fine on Mac OS X, that’s another thing I love about Processing.) The code for choosing the COM port came from this forum thread How to let the user select COM (serial) port within a sketch?.

I did have to install Java to get the application to run, but it looks and functions like any other Windows application. Here’s hoping this all works and never has to be used, but is there just in case…

2015.10.19

Learning

I attended a session at ASTC 2015 titled Are Maker Spaces Killing the Traditional Science Center? Is That a Bad Thing? and while I’m new to the museum world, I’m not new to the makerspace world, but this whole idea of “makerspace in another space” is what the session was about. This post is really just going to be a stream of my own thoughts after the session.

Hooley McLaughlin from the Ontario Science Centre was the moderator and he was anti-makerspace in the context of a science center, where (he believes) the real spark of science can be ignited in young minds. I don’t know much about science centers or the people who work there, but Hooley seems to place “science” (or perhaps just the teaching of science) in this ivory tower, and separate “Science” from other forms of exploration and discovery. The things than happen in a “tinkering” space or a “maker” space are not real science, and there isn’t true learning.

I’ve been involved with Milwaukee Makerspace for nearly five years, and before that I was part of Bucketworks, which is/was a quasi-hackerspace, and I’ve had this idea that BAMspace at Betty Brinn Children’s Museum) Makerspaces tend to be open 24 hours a day, 7 days a week, with everything available to members at any time. 6am on Sunday morning? 3pm on a weekday? Saturday night from 10pm to 4am? Those are all valid times to be at a makerspace working on things. Spaces in an institution are typically limited by staffing, just having people available to be in charge of things. And people like to go home and sleep every now and then, and not work 24 hours a day… also, when people do work, they like to get paid. So the first big disconnect is “makerspace open all the time to members who are self-serving” versus “makerspace that is available during only specific times with staff to guide things.” I’m not saying the second option can’t work, it can, but for people who know what a makerspace is as it exists outside of an institution, reconciling how they operate inside an institution may difficult.

Perhaps it’s just a matter of managing expectations. If the first exposure to a makerspace is within an institution, that can set the stage for what one is, and how it works. (There’s the issue of the term “makerspace” being co-opted or misunderstood, but I won’t get into that now.) Limited access due to hours, staffing, etc. can definitely affect the reach of a space/program, but as most of the institutional makerspaces seem to focus on kids (or families) maybe it’s a non-issue.

Ultimately, my favorite comment during the session pretty much summed things up. “We shouldn’t care how kids get interested in science, as long as they get interested.” My own take on that is, I try things, and make things, and fail, and learn, and in the end, I share those things. I share them with others, and if they get inspired, even just a small bit, than it’s a success. If someone gets interested in robotics, or looks up what an Arduino is, or asks a question about 3D printers, then that’s good enough for me. It’s a spark, and a spark is the start of something. It may not be the spark that (certain) people at science centers are hoping for, but it’s a success in my book.

2015.10.14

ASTC 2015

I’ll be attending the 2015 ASTC (Association of Science-Technology Centers) Conference, and learning a lot more about how museums work, at least how they work in relation to technology, which is good, since I’ve been involved in the technology at Betty Brinn for the past six months.

It’s been quite a while since I’ve traveled for any work-related conferences, and the fact that it’s in Montreal, Canada is extra-exciting! I’m hoping that besides all the conference things I may also get a chance to stop by Helios Makerspace and Foulab. (I’m always looking to add to the list of spaces I’ve visited.)

I’ll also attempt to find out more about the Museduino project, which is an open source Arduino-based development kit for museum exhibits. I traded a few emails with Miriam about it last year.

(And since I’ll be traveling with some electronics it’s worth mentioning a conversation I had with others a while back on the subject.)

« Older Entries | Newer Entries »


buy the button:

Buy The Button