There are some people at ITP who make beautiful, artistically fulfilling projects, and write deep and introspective blog posts to match. Their blog posts are gossiped about on the floor, “they make me want to cry. She’ll get a job through these.”
I am not one of those people. I prefer candid and ugly posts. This will be one of them.
Apologies for the blocks of words. I failed to take many photos.
The Sorting Hat is working, and will be presented today for Physical Computing. It is not nearly in the state I would like it to be, but it is interactive and interesting for people. It fulfills people’s fantasies, even if it doesn’t fulfill my vision.
I had many setbacks in the course of its creation. Last week, we did another round of playtesting during class. I didn’t get my hat functional in time for the class– after fabricating the hat per my previous blog post, I wired it closely to the fritzing diagram in my previous blog posts, with the concession that I didn’t buy complex wire connectors and used a small breadboard instead. After doing so, I discovered a number of problems that prevented me from a working prototype. Consequentially, the playtesting was less helpful than it should’ve been– a mishmash of advice I’d heard last time and suggestions I wouldn’t have time to implement (with a few exceptions.) I did enjoy playtesting for other people though, and I hope I gave them helpful feedback.
Some people react with incredulity at how many problems I’ve encountered in a deliberately simple project– no serial communication is used whatsoever. But I had to put out many fires related to each of my electrical components:
This was the chief problem that prevented me from playtesting, but I’ve gotten it to a good state now. The problem with the MPU6050 I bought was that it only worked reliably when it could read very often, but I only wanted intermittent reads. It consequentially would overflow its FIFO readings or occasionally trap itself in an infinite loop. If an overflow occurred, the stored values of pitch and yaw were never updated, and then no longer valid previous readings would be used.
I solved this by making my read function return a boolean, and asking for a reading until the boolean was true and the values were updated. Consequentially, the common FIFO overflows would be less debilitating. I also made infinite while loops time out, so the program would never be stuck.
Keeping the flow of the system going is very important, and I also added timeouts to responses in general, with a random assignment. Since the system doesn’t tell you the answer it recorded nor what houses it corresponds to, it seemed unlikely that anybody would care.
The accelerometer, despite consistently overflowing, is now one of the more reliable parts of the hat– to my great surprise.
On the other hand, the Adafruit MP3 Shield had a lot of problems, despite initially looking like a solid solution. Some of it was user error– at one point, I snapped off a capacitor on it and had to scramble to find someone to solder it back on for me– I couldn’t trust myself to do so with my shaky hands. But some of that was the product. When trying to get the capacitor back on, I discovered the paucity of serious documentation for Adafruit products. Where is there a data sheet on it? How do I find a replacement capacitor, if necessary, if I can’t find any information on what capacitor it is?
The bulk of my problems, though, were audio out related. ITP is usually very loud, so my previous estimations on speakers needed were too optimistic. The mp3 shield either outputs to speaker pins or a regular headphone jack. The speaker pins had a woefully low maximum wattage, so they couldn’t announce a house loudly like I had hoped. I thought I could wire up two sets of speakers– one for private questions near the ear and one in the mouth for announcements. The MP3 shield has a function to control volume per ear, but no function to switch between the headphone jack and speaker pins. I tried to use right and left as different sets of speakers, but that turned out staticky and sad.
I think two sets of audio outs is a pipe dream if I want to keep the hat lightweight. Right now, I’ve decided to use the headphone jack and connect to speakers with an external power source. It’s the best solution I have for now.
Making the hat’s mouth move was always a stretch goal, and not one I terribly addressed this week. I did have to adjust some expectations, though– running everything with two servos meant a serious power draw. I had to settle for one planned servo motor, if I get around to it. It’s one of the most frequently requested features, so I hope I do get around.
The hat is currently far from finished, and there are a few things I will work on over the weekend. I’d like to accomplish the following:
- Cover the hat with fabric. Hide the carrboard! A lot of people complained about it
- consider privacy and broadcasting questions and answers. Wire speakers accordingly.
- try to make the mouth move!!
- Print stickers for takeaways
Subscribe via RSS