Prototyping for design, term 3

R O B O T S

“1) Do not talk about harming humans 2) DO NOT talk about harming humans.” - robotic fight club rules, or PR damage control 101

This session taught me how sensual industrial machinery can be. The robot arm we got to play with had an uncanny, almost organic, but elegantly precise quality of motion. It was also exciting to see how many different tools one could use with such an arm, and all the possibilities that entails. On the other hand the wide range of possibilities also makes it seem like a tool that should be used in a way that reflects its adaptability, rotating tasks instead of making it do the same thing over and over (or things that other machines can do as well). Anything else seems overkill or underwhelming. I need to learn more about it to get over this feeling or to deepen it, and to better understand how it differs from both human hands and other machines.

The practical part of this seminar was creating a file that could be used with the robot arm located on the premises. Here is how that went for me.

talking to the robot

The tool attached to the robot arm had to be a light. So the idea was to draw something with it.

I had a lot of help from Josep, who was very patient. Making the file itself was pretty straightforward, once I understood how to use the template file. However, it took us a long time to make the light work (with Grasshopper). It had to turn off at certain moments so that in the long exposure shot, we wouldn’t have extra lines. Somehow, this was hard, and seemed harder than it needed to be. Grasshopper (which I have little experience with) also didn’t seemed that intuitive. However, in the end it worked, I learned a bit about robots, and I had fun. I would like to try using the robot with different toolheads.

Blender

This was a very interesting and enjoyable class. Victor through the political economy of open source projects (where a lot of money is sometimes generated, but not concentrated in a single copmpany), the existential dread of using closed source (you’re not a designer if you do, just a technical operator selecting among a range of pre-fabbed possibilities).

We also went through some of the features of Blender. I really enjoyed the socio-political discussion. I was also impressed and excited about all the things you can do with Blender, as well as the scripting and modding options. The interface is a bit annoying at first, but I remember it being worse when I first tried to use it 10 years ago (not touching it since). So I’m definitely planning on giving it another shot!

I got excited about the prospect of using Blender for many very different tasks, which would allow me to have more transferable skills (re-using the same scripting patterns, for example). I also got a better grasp of the ideas behind the interface of Blender. Mostly, however, this was a class designed to show us all the various possibilities Blender has, which was impressive. I also dove down the rabbithole of CAD functionality for Blender and got the impression that it’s quite far along, if perhaps not good enough for professional use in certain industries. But for someone like me, it seemed like it might be the better move to just learn Blender, an open source tool, instead of going to deep on Rhino (the interface of which I prefer, but the closed nature of which is limiting - and for example makes it hard for me to work on my chosen linux distribution).

Live coding

This session involved a tour of the various projects Citlali & Xavi were involved in. It was interesting to see the mix of artistic and more practical projects. It’s always interesting to frame such a broad range of different practices as falling under one and the same category.

The framework to make more concrete one’s prototype of an interface (by starting with simple questions) also seemed like something I may very likely end up using.

It was also somewhat nostalgic to hear about Processing, which I remember wanting to use around a decade ago, but never really got around to it. One thing this Master’s had made easier for me, is just stating to use something like that, and believing that some good may come of it (even if maybe nothing earth-shattering).

Towards the end of the session, we learned a lot about live coding. This is also something I had some prior knowledge of, but no real understanding.

I really enjoyed the Hydra website/framework, which makes it very easy to start playing around with visuals in a way that is somewhat analogous to (sound) synthesisers. Much of the barriers I faced as a tech-curious (but somewhat lazy) teenager back in the day was installing the compiler, framework, or whatever it was. Understanding the code tended to be less annoying (and sometimes easier) than installing the thing that makes it work. So something like Hydra is much appreciated (especially as an intro to the space).

The live coding example was so memorable for me that I dragged my partner to a live coding concert in Barcelona very soon after. I was hoping for more dancing. Instead, I got a kind of ‘classical music’ type experience. Well, that is, I had that experience for a few minutes. For the rest, I’m basing this reflection mostly on what my partner reported, because I ended up talking on the phone (outside) with a person I used to have a very difficult relationship with for most of the time.

Overall, however, live coding in particular, and the many different possible interfaces in general inspired me to explore this domain further. One day, perhaps, I will use and/or be part of project that allows me to use digital tools without destroying my neck and back.

I will continue experimenting with Hydra for some of my projects/interests, because it is so accessible/satisfying to use.

Blender interfaces

This lesson opened up my mind even further to the promises of learning Blender properly. It made it clear how the adaptability and scripting capacities of Blender could be leveraged to create interfaces that would otherwise be more costly and annoying to do. More generally, it became obvious that Blender skills could be way more resilient to shock (e.g. by technological ‘disruption’) than some other applications.

The culmination of this class was setting up an LED strip which could be controlled by a virtual on/off strip modeled in Blender. The way to set that up was by copy-pasting some code into the Arduino IDE, uploading that to the ESP32, and also setting up some python code in the Blender scripting interface together with the 3D model of a switch (which we were provided with).

This process involved some Blender-internal command line acrobatics, which I knew how to do by reading some Stack Overflow or similar forums. I was happy to be maybe the first (or at least relatively quick) to make it work in class. Not because I knew anything, but because I managed to search the right way. This distinction between knowing and knowing how to know (the lazier but also - in such cases at least - more satisfying option) is always interesting to me.

I’m looking forward to learning more of Blender as I continue my journey to transitioning to (mmore) open source solutions, and building fabrication and CAD/CAM skills.

The challenge: interfaces

I documented my activities in the following repo: https://github.com/knr-at-iaac/cultivation-furniture-0.0.1/

This fits with work I’ve been collaborating on with Ramiro and Cagsun. They spent the time of the challenge improving a prototype we had been working on together.

Here is the repo detailing what they did during the challenge (and which partly reflects things we did together before the beginning of the formal challenge): https://hackmd.io/yBieMGWVRJuRM7Gw-nh_kA

Both repos will potentially be merged.