Matt, HeeJin and Jose had decided to continue their project from midterms, the block-based sequencer. I decided to join the team, as it seemed like they had some really good ideas that mainly needed a bit of rounding out and engineering work, and I needed a really good idea to persue.
A little later we found that Dave wasn't going to be working with the team he'd expected, and gladly welcomed him into the project.
We quickly started coming up with features and ideas and new things to add. There were several things that complicated issues; a number of us had pretty big deliverables in other classes, meeting times were difficult to work out with so many people, and backgrounds were diverse enough that it was hard to find common ground without leaving out things that were really important to team members. When we agreed on implementation details, they were generally technically advanced and (as it turned out) would require greater degrees of coordination or had to be serialized. We met week after week, trying to eliminate things which were superfluous or too difficult to implement and trying to find ideas which would bring the team together and allow us to focus on an actual build, and every week we had a new design which would end up knocking us back to... well, if not square one then square two. We started with a design based on a grid of magnetic sensors which would allow both triggering and adjustment of parameters based on rotation of blocks (deemed not quite the right interface), then moved to RFID and modular scanning arrays (decided that we needed an immersive visual element) then moved to a circular setup with a display in the middle (the RFID element turned out to be too complicated, plus as it turns out the technology wasn't there to do many of the things we wanted to do reasonably cheaply). We switched to iPod-style scroll wheels (required team to wait for scroll wheels to be done to develop most of interface, which it was decided was not a good idea), and finally ended up with the current proximity sensor design, as this made the system easy to prototype & test with normal switches, and the whole team could be working on different aspects of the design concurrently.
While the roles were mostly not completely vertical, we mostly ended up in the following:
Jose and Dave decided to tackle Midi code and the state machine, and work on sounds for the final piece.
HeeJin took up the visual development, including designs for the pads and Processing code to give visual feedback to users & for performance.
Matt took on fabrication & testing.
I took on building out the hardware & interface code.
It ended up being an intense time for all of us. I'll let the others speak for their parts, but I'll give a rundown of the hardware build.
I had a board I'd put together years ago using qprox qt140 touch sensors, and I had a few random qt140's lying about. When we decided to move away from the touch wheel interface, I decided to pull them out as a simple-to-interface alternative. They have some configuration to set up, but for the most part they have 4 touch inputs & 4 digital outputs. Easy.
I brought the board to Matt & we played with it a bit with copper clad circles we were planning to use for touch sensors; while it seemed to work somewhat, the sensitivity was way too high. We decided that using switches for prototyping would be the best for Jose and Dave until we had this all a bit more worked out. I knew the range could be altered by adjusting capacitors on the board, and was able to test this to some degree with the initial board (enough to tell that we should be able to reach the range we wanted, but also enough to know that mounting was so important to the sensitivity that we shouldn't depend too much on results from the test board).
I spent a few hours & was able to create a PCB layout (using Eagle) that would work as a shield, holding two qt140's (with a careful groundplane layout) and support circuitry. Since the case wasn't quite ready I kept this board to work on code, and began to work on the LED control circuitry. TLC5490's had been talked about on some of the ITP lists before, so I decided to give some a shot (having played with, and been disappointed by, some Maxim i2c-based LED controllers in the past -- though that was likely largely due to my selection of LEDs at the time). They turned out to be a total pain in the ass, though in the end I think worth it.
I was getting low on time, so I decided to skip doing a full PCB layout for the 5940's (besides I had DIPs and for PCB layouts I generally prefer to do SMD). I just used wirewrap wire, sockets and pin headers and soldered a board to plug into the top of the qt140 board. It took a while, and soldering the LED's to little boards & attaching wires to plug into the 5940 board took another while.
I ended up needing to steal pins from the Arduino analog port, since the touch controllers took 8 pins for switches + 2 pins for control; the serial connection took another 2, and with only 2 remaining digital pins I couldn't handle all the 5940 connections necessary. So the TLC5940 board plugs into the Analog 0-4 (PORTC 0-4) pins, with two lines going to pins 10 and 11 (luckily I'd managed to leave two pins which can be timer-controlled available when doing the earlier layout).
Code was the biggest pain. There's an example on the Arduino site, but it didn't have quite the right interface and the clocking options weren't in the range I was looking for, so I ended up putting together my own code. I used some code I'd had lying around for a while (evolved from my first AVR-based design, years ago!) to do a color fade test, and when I got my first color cycled output I knew it was all worthwhile.
The team pulled together for a big build night; lots of cutting (Matt did a great job at putting together a hatbox-cutting jig & getting our case trimmed down to size and cutting holes for the LED's to shine through), hot gluing, tweaking and testing. I think we were all amazed, after everything we'd been through on building miXem, at just how great it looked in operation. The code required only minor tweaking to get the LED bits working along with the Midi code (initially the two parts weren't integrated; the LED code did its own sensing of what buttons were pushed, etc... but this turned out to be a pretty lousy interface). A few more changes of just a couple of lines brought us to the interface we showed in class.
Our biggest problem since the build has been occasional glitches; they seem to be due to the touch controllers getting confused (especially when items are placed on the table next to miXem, or when the case is opened & then re-closed). For the ITP show, we opened it and cleaned up the wiring a bit, and hot glued the Arduino in place in the center. This seems to have fixed most of these problems (though opening the case sometimes still causes it to become confused for a few moments). I learned here to pay close attention with the prox sensors to how they scan; it's covered in a short section in the datasheet, but especially when using multiple prox sensors in conjunction -- it's important to synchronize the chips (qt140's have a sync line; sync lines from all of them should be connected together) and to make sure that multiple pads aren't being scanned at the same time in close proximity to each other (which is a wiring layout issue). We were seeing (almost) rhythmic self-triggering in some of our initial tests where care wasn't given to wiring layout.
In the end, I think the project turned out well. I think most of the problems we ran into we were aware of and actively working to minimize (mainly with regards to trying to come to agreement on what & how to build, plus running into parts of the build that couldn't be parallelized), though I still hope to learn more about How to Quickly Develop Good Ideas With a Group.
0 comments:
Post a Comment