The Chairs
Kevin Thies, Nick Richardson, Marisa Lu

The goal for our project was to take a mundane object and give it a slice of humanity. Love is a powerful feeling, so much so that two objects used day to day can try to come together despite how daft the prospect sounds. While we’re used to chairs moving, it’s often by and for humans’ sake, and those chairs have finally taken charge of their abilities.

The second video is reminiscent of two dogs meeting each other while their owners talk. Eventually their wonky, awkwardly eager interactions butt into the people’s conversation.

[Could someone add a reflection on the course and its themes as it relates to the project here?]

The project was very involved on both the hardware and software sides. It’s very different taking an existing object and thinking about how that could be augmented to hold specific parts while remaining as streamlined as possible. It’s something that designing a system from scratch gets around because we aren’t carpenters. It’s not in our skill set or even aligned with the goals of the project to construct chairs. As a result we had to be considerate of the way the chair was constructed so that as we added to it the essence and abilities of the chair remained intact.

There were also a lot of choices that we made that we had to go back on. On the hardware side, our connectors for the nodding hinge at the backrest of the chair kept breaking. The metal wire would wear out as it bent in the same place, and fishing line would come untied. Given another chance, we’d definitely try using zip ties for that, as they’re more rugged and less likely to snap. We also would have used epoxy more to glue the wooden motor box to the plastic undercarriage of the chair instead of gorilla glue, as the one chair that was glued that way held up well. We also leaned to be considerate of where we glued the arduinos to the chair, as if they were touching one of the metal screws, it could short-circuit. If we could have made the chairs battery-powered, that would have solved some issues and we wouldn’t have had to make wheel bumpers, which should have been epoxied on. The hardware lesson to be learned is to build with more extensive use in mind — testing moving parts tends to degrade them.

On the software side, we started off with a system that would better enable parallel work flows. We thought that would be important because we didn’t want to leave the software until after the hardware was done. Ideally it would develop at the same time so that as soon as the hardware was the software could be connected and the rest of the semester would’ve been finessing the interaction. The system we initially developed was two javascript sites running each robot, and communicating both to each other and the hardware (communication to the physical prototype wasn’t achieved). With the javascript, it visualized the robot with simple graphics so that we didn’t need to have the working hardware to test different behaviors. The problem with our visualized system  was that it had it’s own estimates of hard coordinates for the chair, which, given the drift that we know would happen no matter how much we try to calibrate meant the system ultimately needed some rethinking. Of course, the fact that we couldn’t get the wifi module to work was also a huge motivator. In hindsight, designing a system that lynch-pinned on a module no one had experience with before was not the best decision (though it’s a good lesson to learn for the future!). As soon as we transitioned away from the javascript/shiftr system we needed a new way for the chairs to be aware of each other. That’s where the cardinal IR sensor setup on each of the chairs came in. The receptors and beacons would be able to pick up and tell each chair an angle estimate of where the other was. For the most part that orientation to each other was what drove the chairs’ respective behaviors. For example, the servo motor script that nodded the ‘head’ (the back of the chairs could bob) triggered every time the amorous chair was looking straight at the other, as if trying to converse. (connecting wire broke day of show). The coy chair would often try to spin away from the amorous one.  Without distance sensing there was some degree of surprise built into the behavior — in some instances the chairs would bounce off each other or ‘nudge’ the other because the scripted behavior didn’t stop just because of a ‘collision’.

On a more specific note towards how the final software was structured, it had a series of basic fundamental moves that took parameters, and a live global variable taking in sensor info — all other more complicated moves called on those and were generated according to the orientation global.

Some other aspects of the original javascript system were harder than others to carry over — for example, to keep general movement qualities like speed and acceleration, smooth while still variable, all the function moves had numbers that  referenced a global ‘mood’ int that fluctuated smoothly according to perlin noise. Choosing different moves was also dependent on the ‘mood’ variable. Higher the ‘mood’ the was supposed to enable the program to choose what moves we deemed as more ‘eager’ . An implementation of perlin noise was commented out to be dealt with after MVP was achieved, but then after reaching an MVP with switch case statements, it didn’t seem like the perlin noise would change much of the noticeable experience.

 

The code:

https://drive.google.com/open?id=1u2O42gcCeZU0H-b6jabw-6z3_A3YqOO0