Connections & Contacts (final process)

Posted on Dec 3, 2013 in Physical Computing

success

We’ve got some working, minimum structures: (or we did last monday)

Admittedly, we were still working on the third physical prototype build on Wednesday and only really began debugging Thursday, Friday, and Sunday, in stops and starts. Saki had, in different pieces, constructed both the php and the processing sketch as part of her other finals, so I anticipated merely working through the arduino together. . . which we did in stops and starts. I was, of course, also working up my php/api project at the same time so that stop-start-stop may have fragmented the pieces a bit.

debugging process

I won’t re-post Saki’s arduino code… there were a few sections where she’d oddly nested if statements, so nothing was reading. We did some bracket re-organization to separate out those tests. Then, unfortunately, I pulled my hair out for a while before she mentioned that all the existing mapped values were placeholders. So, I re-mapped the sensors for actual reading. I can’t quite recall how much of my C++ made it into the final version Sunday pm. I’d consolidated things into a series of looped sensor readings, but we ended up pulling things apart every time we tried to troubleshoot strings within processing.  I’m not sure whether anything is legible in the following success shots.

 

Basically, we’re just cheering for the successful analog read of different piece sensors and then, on the shots discussing the corners, the correctly mapped values.

Little triumphs.

Saki had posted the code at http://www.sakihayashi.net/?p=635

What’s a little odd is that she posted a version of the arduino without any of the actual sensor mapped loops, actually posted here. I’ll admit I find the processes of working on code together so much more confusing that co-building or co-brainstorming. Part of it is the language barrier, but I also guess I’m a perhaps-too-logical person. Brackets, conditionals, doubles, longs…. almost everything but switch functions make sense to me. I’m not a wiz, but I like the flow of decisions and checking/updating variables. Both working with Saki and debugging with Michelle, there were times where I didn’t quite see why they didn’t automatically place brackets. This is clearly why my landscape student had such trouble with brackets; I wasn’t explaining their conceptual structure, because, well, I guess I think via such simple and finite statement. I’m kinda at that place where I want to compact massive code samples into tiny, Shiffman-esque functions, but we’re not all there and we, especially Saki and I, are still working through how to talk, ask each other questions. Maybe we’ve defaulted to precisely the level github/stackoverflow has… passing swatches and samples back and forth.

Anyways, I’ll get a few more process shots up soon.

moving forward

Unfortunately the 4 for 33 deal takes 5 days to process, so we decided to experiment a bit more with the conductive paint. A really thick layer will give us ambient readings, but (and this sucks) i did two and left Saki working on another two tonight. It’s such a temporary re-build, but it’s going to take 20+ hours. Plus, I want to really, really work together to clean up Saki’s code or, at the very least, work with her to get some legible, serial, punctuated communication and get rid of the hand-shaking, perhaps even limit the interfering minim issues and errors.

The social side of feedback in class was excellent. I’d been trying to explain pen-pals (and the 1964 world’s fair) to Saki as we brainstormed product registration, but Sharon’s second-life notion makes more sense. We’ll only have greyscale graphics, showing saved combos and other’s entries for Sunday (web documentation to be posted Sunday/Monday) but it’s a first step toward having both physical and screen registration in a recognizable form.