Thank you to jkeith247 for posting up your great work in the forums! This sounds like an amazing and moving exhibit. Check out more info on the build here.
My hand has certainly had it’s place in a fair share of exhibits. Some were awesome, some not so much. When a concept for an exhibit is delivered to us, we often speculate on what kind of impact the interactive will have on visitors. Being in the field of technology, it is often deduced that if an exhibit doesn’t include some video, flashing lights and a touchscreen it is going to be a flop. When I heard about The Lunch Counter Interactive at the Center for Civil and Human Rights, I couldn’t help but be a little skeptical of the impact the exhibit would have. I was soon proven to be very wrong. After the engineering was complete, the code was written and the audio content was added, I can say that I have never before worked on such a moving and emotionally impacting exhibit.
The overall idea of the exhibit was to try to recreate the tribulations of the “sit-ins” during the civil rights movement. At the counter the visitor is instructed to sit down, put on a pair of headphones and place their hands on the counter. When the patron places their hands down on the counter, a pair of 2″ aluminum disks embedded underneath the counter and attached to Adafruit CAP1188 capacitive sensors trigger the beginning of the experience. A “count-up” timer in front of the visitor starts timing the users ability to “endure the abuse”. Through the headphones, the patron hears a couple individuals telling them how “welcome” they are there.
What starts out as slight verbal abuse quickly escalates to a crowd of angry men yelling in your ears through the stereo headphones. You can hear the men switching sides and yelling at you from different positions. Dishes and silverware clatter and every detail of each dish breaking can be heard. It can only be assumed that they are throwing these objects at you. Even the breath of the abusers can be heard switching sides, and you can almost feel these breaths on the back of your neck. It is chilling to say the least.
Just when you feel like you have had enough, BAM! Someone kicks your stool. The tactile kick is felt through the bar-stool you are sitting on via a “ButtKicker” audio transducer that is attached to the base of the stool. This is likely the most moving component of the experience. Everyone nearly jumps out of their seat after the first “kick”. It puts a very real feel on what exists at the time, only as theater of the mind. Some make it through the entire experience, many do not. If the guest at any time lifts their hands from the counter the interactive immediately halts and the duration of abuse is reported on the “count-up” timer. It is highly emotional and very tough for many to endure. The exhibit is so moving in fact, that the center was compelled to place signs near the exhibit warning of it’s impact and that it is definitely not for children.
While the creation of this exhibit was wrought with emotion, the most moving moment was when I saw one of the actual “sit-ins” at the counter just before the grand opening of the center. I will not name the individual as it was arguably a private moment for them. As a tear streamed down their face, it couldn’t be helped but to have one stream down mine. What the sit-ins went through, I will never know or understand. They were martyrs for freedom and have a permanent seat on the collective list of histories heroes. Truly proud I am to be a part of depicting such an important piece of history.
I would be a liar if I said that all of my automation ideas worked perfectly from the beginning. The fact of the matter is that they don’t and almost never do. Often, ideas must be refined time and time again until they work perfectly. Perfectly is the key word. There is no substitute for the abuse that the general public can put an exhibit through, and if there is any fault within the exhibit, the visitors will certainly find it. Any fault found is unsatisfactory in museums as a inoperative exhibit for any amount of time is totally unacceptable.
The most challenging part of this exhibit was working with the capacitive sensors. I have worked with many capacitive sensing technologies in the past, and have always ended up using the “Phidgets” capacitive sensors. When we made the mock-up of the exhibit at D-and-P I used some of the “Phidgets” capacitive sensors that I had used with great success in previous interactives. They worked perfect. During the mock-up Robin, of Batwin and Robin (the media producers for the exhibit) and George C. Wolfe (the Chief Creative Officer for the Center) decided that adding a “Buttkicker” to the experience would be a great addition. While they were most certainly correct about the impact the addition would have, I had no idea of the world of pain these “ButtKickers” would inflict on me.
Often, the time from which the concept for an exhibit is drawn and the actual exhibit is created, can span a year or more. With technology evolving as quickly as it does and availability of parts used changing every day, unique challenges are created by the lengthy duration of these projects. Often, parts used in concept are no longer available at the final installation of the exhibit. One such example is the Phidget capacitive sensors used at the mock-up. After writing the P.O. for the materials, I was shipped to site. I never realized that the P.O. I wrote for the sensors was replaced with the new model by the manufacturer.
Flash forward to two weeks before opening, I finished installation of the exhibit, uploaded code/content, and tested the exhibit with confidence that the counter would be complete within the hour. The experience started and then abruptly ended 1:00 into the experience despite not removing my hands from the counter. After checking code and connections, I was stumped. A lengthy troubleshooting session lead me nowhere. Finally, I started reading data sheets. I checked the datasheet of the capacitive sensor I had used before and found nothing remarkable. I checked the numbers on all parts ordered and finally had my “Ah-hah!” moment. The part number on the Phidget was different than what I had ordered. After checking the datasheet for the new Phidget sensor, I found the problem. The sensor resets itself after one minute of contact to “re-calibrate” itself. The obvious solution would have been to try to find the Phidgets I originally used during the mock-up. The unfortunate truth was that these particular sensors were no longer available. After a frenetic field “re-engineering” session I decided that the Adafruit CAP1188 sensors would fit the bill. I ordered multiple different sensors for testing just in-case, but after many bench test sessions, these had the best results.
I had a project to run and a deadline to meet. The entire project, not just that exhibit, was my responsibility. I still had a four projector blended theater to finish, a 36 screen synchronized video show and multiple projector warps to worry about. After getting my crew in a good place to carry on with all of the other parts of the project, I returned my focus to the lunch counter.
After receiving the new sensors I installed and tested them in the counter. They worked great. Problem solved… or not. All of the sudden, the sensors started receiving erroneous “touches” which of course disrupted the experience. I always feel somewhat silly when I explain what difficulties I suffered through my engineering saga’s. It’s so much easier to say what the problem is than it was to actually find the problem. Cue the troubleshooting. I knew that I was getting noise interference but from what?
After a session of checking shielding of all cables including headphone wires, wrapping the CAP1188’s in grounded copper foil, and doing everything I could to shield the noise I still couldn’t find the source of the electronic disturbance. I hate, hate, hate coding around physical problems. Devices SHOULD just work perfectly (not always a reality though). Using code to correct these problems is ALWAYS an absolute last resort only after doing everything possible to eliminate the physical problem. Even then, you are just masking the issue.
The undeniable fact of the matter was that the museum was opening in a week now and the client was understandably growing increasingly nervous about the experience. This was the flagship experience of the center and it HAD to be working. I coded around the problem, making it less sensitive to touches and adding a delay to the end of the event. The code workaround worked, or did it? I tested all of the interactives thoroughly and they worked fine. I reported to the client that the exhibit was ready for mass testing and left site for the day. I was so relieved to have that exhibit up. I went back to my hotel room and went to bed. At 9:00PM I got the last text message I wanted to get that day. Two of the lunch counter stations stopped working. The next day, three had stopped working. Resetting the exhibit fixed the problem, but of course, any failure was unacceptable and the cause must be found.
I started up five terminals on my PC and left them running to debug the interactives. It turned out that there were so many erroneous touches occurring that it caused a stack overflow in my code effectively disabling the exhibit. Sometimes you just have to walk away, and walk away I did.
I went to my place of sanctuary. Outside to enjoy a Dr. Pepper. Many a great thought has been had while enjoying Dr. Pepper or his equally awesome counterpart Mr. Pibb (debatable to many I am sure). The day of opening was nearing and drastic action was necessary. I decided to rewrite the entire program limiting my use of variables as python seems to handle the storage and deletion of variables slightly different than other languages I am familiar with. I still however, had this noise problem to deal with and after my last experience, refused to try correcting it with code again. The experience with the program crashing only reaffirmed my stance that correcting physical issues with code, was a poor technique. On my way out the door, I decided to stop one last time to test the interactive. Much to my astonishment, it worked flawlessly. Then, I got kicked in the butt. All of the sudden, everything went haywire again and I received a couple thousand touches on the capacitive sensors. Finally having a direction to point towards I disconnected the power to the “ButtKicker” amplifiers and the exhibit went back to normal operation. There was my problem. It was the “ButtKickers” the whole time. After a period of inactivity, the “ButtKicker” amplifiers automatically turn off. This is why it worked perfectly at the beginning of the last experience. The amplifer was off until the first kick was triggered. Hanging my head in disbelief, I went back to my hotel for the night and rewrote the program there.
I walked into the control room the next morning and out of the corner of my eye I saw a big pack of ferrite cores. I recollected all of the times in my career that I had used ferrite cores to correct issues. They never worked, period. I thought to myself though, “What have I got to lose? I am desperate.” I took a couple of cores and placed them on some of the wires in the exhibit. Much to my astonishment, they actually helped eliminate some of the anomalous touches. So, I did the next logical thing and put them on each and every cable in the exhibit itself. I put them on power cables, Ethernet cables, USB cables and sometimes I used three or more on the same cable. Problem solved. With the newly written code and the ferrite cores, the exhibit worked flawlessly. Talk about relief. With two days left until opening day I could focus my efforts on the rest of the center and knock this experience out of the park. With a new found sense of pride, I walked up to the client and was finally able to give them the words they were hoping for, “All is well.”
The exhibit was heralded by many as an incredible experience and even won a “Communication Arts” award on which my name was listed alongside that of George C. Wolfe’s and Dale Panning’s (our Sr. Engineer and my mentor from whom I’ve learned much) names. Epic win.
Featured Adafruit Product!
CAP1188 – 8-Key Capacitive Touch Sensor Breakout – I2C or SPI: Add lots of touch sensors to your next microcontroller project with this easy-to-use 8-channel capacitive touch sensor breakout board, starring the CAP1188. This chip can handle up to 8 individual touch pads, and has a very nice feature that makes it stand out for us: it will light up the 8 onboard LEDs when the matching touch sensor fires to help you debug your sensor setup. Read more.
