Categories
Uncategorized

Reflect-O-Scope

The Reflect-O-Scope was an interactive museum exhibit I worked on a few years ago. It was a fantastical machine that allows users (typically children) to slide materials under a microscope and examine them. The materials were from the sponsor of the exhibit and consisted of specialty tape materials adhered to plastic boards.

One of the original ideas was to allow for focusing, but that got scrapped. We figured kids would put almost anything under a microscope, their hand, their little sister, etc. Focusing meant a moving mechanism, and it was deemed to complex at the time.

The sculptural build was done by John McGeen and Austin Boechler. My focus was on the hardware and software. There’s a USB microscope connected to a computer and then a small HDMI display in the “goggle” shaped piece that the user looks into. It’s all a bit “periscope” like in design.

The original design also had a secondary monitor (a large TV) that would be mounted further away, so people could see weird things on the TV and it would draw them over. Lots of features got killed due to lack of time or other reasons. Most of what you see on a museum floor probably started out a lot more complex when originally designed, and then simplified as time goes on.

I wrote the software, which is just an application written in Processing that automagically launches at boot up, runs full screen, and shows the output from the USB microscope. There’s also a companion application called “List Cameras” that can display all the connected USB cameras and all of the possible resolutions they support. This is there in case the USB microscope ever needs to get replace. The exhibit tech just needs to run the application and then edit a config file. No recompiling of the application is necessary.

One more fun addition was a white plastic tube running along the outside with some NeoPixels in it featuring some funky color runs to add to the fantastical nature of the piece.

One of the nice things about this component was that the software was created in-house, so the component could be replicated easily without additional license fees. (We had an amazing software partner we used for the complex things, but simple stuff was done, when possible, in-house by the tech team, which was basically me.)

Categories
Uncategorized

Velocity Exhibit

Velocity_Loop_5507

You may have already seen John’s post about our Velocity exhibit, and I must say, he did an amazing job with all of the CAD and CNC work to build it.

Velocity_CK_5503

For my part, I handled the technology that went into the exhibit. (Which sadly, you can’t see much of in these photos because some were shot after things were powered down.) For three of the five components, I spec’d the hardware and worked with a software developer to upgrade the old version of the software to something more modern, stable, and easier to calibrate and support.

Velocity_CK_5525

I can’t even tell you how many golf balls I rolled down all of those ramps. At one point we had an issue with a projector overheating and I set up a time lapse camera to run all day and overnight to give us some idea how long it was staying on before shutting off. We eventually fixed it by adding a duct to the projector housing to draw the heat out and away. We’ve used earlier models of this projector with no issue, but this is why we do extensive testing… you never know what problems are going to pop up.

Velocity_Dish_5527

If this exhibit looks familiar (!?) it might be because there are now three copies/versions of it. Besides this one which was a “for sale” item, we’ve got two on the road, one of which will be returning to the Betty Brinn Museum this summer.

Velocity_CK_5518

By the way, if you occasionally have a bunch of old golf balls you want to get rid of, let me know… There’s a non-profit in Milwaukee who would love to take them off your hands. ;)

Velocity_Roller_Coaster_Lazy_River_5517

Velocity_Jump_5499

Categories
Uncategorized

Durability… for the children!

Durability

On the durability scale it goes from “Consumer” to “Commercial” to “Industrial” and then finally to “Children’s Museum”.

While most adults can figured out how things work, and most will actually use things the way they are designed to work, children will use things every way possible, not (usually) maliciously, but because the are still figuring things out. Install a lever that goes up and down, and they’ll move it up and down with all the force their small bodies can muster, so you might want to add some hard stops on the inside.

Controls

Kids also can’t read/don’t read (to be fair, many adults don’t read either) so add some arrows showing direction of movement. Also if those arrows are just vinyl you applied to the surface, they’ll get peeled off. Every interaction needs to be thought about in great detail, and sometimes you need to think like an angry vandal hell-bent on destroying things.

Plan for things to break, because they will, but make them easy to maintain and repair. Use off-the-shelf parts when you can, so replacements are easy, or if you fabricate the parts yourself, make spares, and document how to make more spares in the future. Use Loctite. Use set screws. Use Loctite on set screws. Use hot glue. Use lots of hot glue. Use screws and bolts, not nails and staples. Make sure you can take it apart and repair it.

Stay Durable, Friends!

Categories
Uncategorized

Traffic Lights

Traffic Lights

I recently repaired the traffic and walk signals at BBCM. The system had been running on a PLC (Programmable Logic Controller) which failed, and rather than find the proprietary programming cable and find and install the PLC Windows software, I decided to just put an Arduino and relay control board in place.

Arduino and Relay Board

I had a Teensy++ 2.0 I had pulled from another exhibit during an upgrade, and an 8 channel relay board on hand. These relay boards come in different configurations from 1, 2, 4, 8, and even 16 relays. Since I really only needed 5 relays (and 5 pins) I could have used an ATtiny85, but I had the Teensy++ 2.0 readily available. The wiring is all done using female to female jumper wires.

Traffic Controller

I mounted everything to a piece of scrap MDF and added mounting holes to that, with the idea that we’d screw the whole thing directly into the wall. The relay board has mounting holes, but the Teensy does not. That’s probably my one complaint about the Teensy boards, is that mounting them isn’t always easy. My Teensy BOB has mounting holes, but for mounting this Teensy++ 2.0 I just used some 3M™ VHB™ tape. (The “VHB” stands for “Very High Bond”). And yes, there are a few 3D printed parts on there. At some point I should make a 3D printed holder/mount for a Teensy++ 2.0

Labels

I try to label things clearly. If I look at this thing in 6 months, or 2 years, or someone else has to look at it, I want it to be somewhat apparent what is what, so there’s not a lot of guesswork as to what is going on. I included a label with the name of the Arduino sketch, and I always like to label power supplies. Sometimes we use 5 volts, and sometimes 12 volts, and they typically have tiny hard to read type printed on the side of the power supply that you can’t see when it’s plugged in.

The one thing I should start to add to the labels is the URL of the wiki page where the thing is documented. (Next time I’ll do this.)

Controller Mounted

Here’s the controller mounted. It’s not pretty. We ended up re-using the mount that the PLC was in, rather than screwing it right into the wall. In my defense, we did this repair on the floor during open hours, and it’s mounted high on a wall behind a TV. Does it work? Yes… Is it awesome, no… but again, it totally works.

The wiring for the lights was all 12 VDC, not 110 VAC, so those thin gauge wires are fine. Also, they were labeled, which was handy. (Thanks previous person who worked on this and labeled things!)

Wiring Diagram

I try to create wiring diagrams for everything. I use Fritzing because it’s simple and awesome and open and free. I often don’t find the components I need, but you can always just use a note and some text.

Here’s the script/sequence for the lights:

  1. Green Light is ON
  2. Walk Light is ON
  3. Waiting 4 seconds…
  4. Walk Light is OFF
  5. Don’t Walk Light is BLINKING (for 5 seconds)
  6. Green Light is OFF
  7. Don’t Walk Light is ON
  8. Yellow Light is ON
  9. Waiting 4 seconds…
  10. Yellow Light is OFF
  11. Red Light is ON
  12. Waiting 6 seconds…
  13. Red Light is OFF
  14. Don’t Walk Light is OFF
  15. (Repeat sequence)

I wrote this up to figure out how to program things. I find it helpful to plan things out before I start writing the code.

At first I just talked through the light sequence with someone and we made some assumptions about how it worked. We were slightly wrong, which I discovered when I dug a bit deeper into traffic lights and walk signals. I read at least some of the (very long) Wikipedia page on Traffic Lights. I also hunted for other info, and found some on the Signals FAQ page on the Minnesota Department of Transportation web site. (As I mentioned with the 911 Phone I really do aim for an accurate and realistic experience with these things.)

It’s been a few weeks and the lights have been working fine. Hopefully that will continue to be the case. If something does stop working we’ll open a ticket for it so we have a record. And yes, we do use an issue tracker for our museum exhibits… doesn’t everyone?