Project PROBE
Last week I wrote that I’d started a new little vanity project. I find myself very happy learning new technical stuff and this project gives me the chance to combine some of the things I learnt about servos from Charismatic Megapigment with some of the other projects that have used geolocation maths like Augury. I'm not going to give much away on what it's about, just show process as I go.
I’m trying to get all the inputs to talk to each other this week. Without giving away spoilers; it needs to know exactly where it is in relationship to where something else is. So I need a WiFi module and IMU (inertia measurement unit), ideally with a magnetometer so it can figure out where north is. This way it can use WiFi beacons and the magnetometer to figure it's exact position on the Earth and it's orientation to the poles. Rather than plugging in a bunch of different components, the Rev2 pictured has a WiFi module and IMU built in so that’ll save on space and complexity (although I'm not sure the IMU has a magnetometer built-in.) However, the first challenge was getting it to talk. It wouldn’t talk to any Macs but when I hook it in to a Window’s PC; no problem.
The solution was a creeping reinstall (there's probably a technical name): I had to do a complete manual reinstall of Arduino IDE and all the drivers, starting with oldest to newest until I got one that worked. This meant going through the preferences menu to find Arduino’s cache and wiping it. This is risky if you’re dependent on Arduino projects but I don’t use it everyday so I think I’ll survive.
The second issue was getting it to connect to a WiFi network. Luckily there is a secret one at work that has only WPA encryption (no username, just a password) so I managed to sneak it on. Currently the standard Arduino wifi library – WiFiNINA – has no support for WPA Enterprise without a lot of jiggery-pokery.
The next step is finding a way to get its location in longitude and latitude. Google now charges for its geolocation API which is a pain on a vanity project and not something I wanted to go through the hassle of setting up. Unwired Labs LocationAPI which I found through this helpful tutorial allows you to track up to five devices free for 100 calls every twenty-four hours. I only need to track one device and since it should only need to call the API when it's first turned on this would easily suit my purposes.
The idea here is to ask the Arduino to compile a list of nearby WiFi routers and their signal strength, send them to Unwired Labs and then receive a longitude and latitude, same as the Google Geolocation API. The code in the tutorial is pretty useful but there’s always a bunch of problems to be un-kinked when building a system from different components. The version of the Arduino WiFi scanner library being used in the tutorial had a handy ‘BSSIDstr’ function that converts the byte arrays of BSSID (the mac addresses of nearby routers) to strings so you can feed them into a JSON string. Essentially, the format that the mac addresses are scraped in are in the wrong format to send to the API and you get mangled gobbledy gook if you try. However, BSSIDstr no longer exists so I had to mangle in a ‘sprintf’ bit to do that for me. Sprintf is one of those things I've never properly understood so it was useful to learn how it and byte arrays work. FYI, just for fun, the order of the bytes is backwards so you need to lace the string backwards to get the BSSID in the right order. Then there just some tweaking around with the URL for the API request since it’s all changed since and it was good to go. Et Voila, my Arduino knows exactly where it is on the surface of the world as pictured to a remarkable degree of accuracy.
I already have a magnetometer working from an earlier test so I'm not hugely bothered by the amount of work there so once that's integrated the Arduino will be able to know it's position and orientation when it turns on easily. Most of the stuff that seems to happen in the early stages of these projects is versioning; tutorials use out of date firmware, terms have changed or been removed etc. etc. So most of what you end up doing is chasing around dates and versions to get everything to talk to each other.
If I get any more time I will be looking in to what turns out to be some exceptionally complicated geometry problems which I hitherto had considered child's play. Who knew there are different versions of time?
The easiest answer to me is in design’s aesthetic history of tackling human problems on Maslow’s hierarchy; where to live, how to eat and sleep, how to communicate and share information etc. All of these things can be interfaced or encountered within the human sensorium and consequently design’s aesthetic sensibility is drawn from the human body and it’s scale. It’s only in recent years that design has attempted to address ‘systems’ and even these are human-oriented with solutions and products largely being aimed at the interface of the human and the system; different information flows and architectures, levels of access or responsiveness. This is as opposed to the approach of an activist or artist who might address the system in total as an artefact rather than as an inevitability.
Take for example, Suzanne Triester’s work; Hexen 2.0 (left) which examines the history of computation through a quasi-occult, quasi-conspiratorial lens. The goal here is not to improve the system or design it in a different way but to give us a pan-historical reading of it that challenges our comprehensive model and presents alternate narratives.
This is opposed to any number of brilliant design projects on computation that address the way we interface with the very notion of computation through the interface. For example, the amazing work of IF and their catalogue of data patterns almost all of which feature a hand, a phone, a laptop. They address the system at the point of interface where design is most appropriate and comfortable. This is how cognitive understanding is built between the audience of the design and the idea of the design. We all have hands, phones and laptops, we can project ourselves into the alternatives that IF propose for data patterns. To a degree, Triester exploits the same sympathies by drawing on an aesthetic sensibility of diagrams and visualisations with which we might be familiar and so are equipped to interpret the work and put it in a certain frame of reference.
If I was to think about Augury as a project about computation then I’d say it is further abstract than Triester’s work. It draws on some familiar aesthetics; the audience having to look up indicates it’s about something above us, there are flight numbers and names of airline companies to conclude it has something to do with planes. Though it draws on a popular ancient practice of divination, this was less familiar to the audience which was perhaps a failing. Connecting this ancient divination technique with a contemporary technological equivalent – planes’ instead of birds’ flight patterns used to predict the future – was a knowing cognitive leap rather than one meant to create cognitive sympathy. The project exploited the idea that the audience might question why these things are together as way of teasing them towards the absurdity of computational prediction without having to reduce it to human terms (phones, laptops hands) that would make it more comfortable. From the perspective of my practice I find the only way to deal with things maybe beyond the human scale is to exploit cognitive dissonance as it's impossible to make these things sympathetic to human understanding in their entirety.
While a design project might draw on a more familiar aesthetic sensibility to provoke the idea of the absurdity of computational prediction by exploring alternative device interfaces or human interactions, in Augury Wes and I were keen to highlight the supra-human qualities of computation by placing it in the world of the supernatural. It’s hard to then draw on design aesthetics and logics for this kind of framing, there aren’t really (arguably) tenants, principles or methodologies for designing the supernatural. There are certainly designed aesthetics; colours, shapes, styles but not many functional models.
Let’s put this back into the question; ‘Why did Formafantasma design a chair about e-waste?’ which seems to have become the locus for this thinking. Ore Streams draws entirely on a comfortable and sympathetic design aesthetic – the chair – to engage with a bigger-than-human (I’ve been trying out various words here, you may have noticed) idea/issue. But, they draw on elements of sympathy and dissonance; it’s a chair with which we can all connect experientially but it is also provoking a discussion about e-waste with a particular audience. Consequently the audience might ask ‘why is the chair made that way?’ I am going to stop banging on Formafantasma now, I really do love their work and I’m sorry they’ve become a lynch pin that seems to be unduly criticised here. I do think Ore Streams is great, I’m just using it as an exemplar project for design projects that don’t give me a good sense of why did they do it that way? The follow on from which is what is the best way of doing this? Which is basically a PhD right.
I've already started notes for next week's blog and it's currently Tuesday so I guess it's going well. I hope you enjoy something and it's not too tiresome.
I’m trying to get all the inputs to talk to each other this week. Without giving away spoilers; it needs to know exactly where it is in relationship to where something else is. So I need a WiFi module and IMU (inertia measurement unit), ideally with a magnetometer so it can figure out where north is. This way it can use WiFi beacons and the magnetometer to figure it's exact position on the Earth and it's orientation to the poles. Rather than plugging in a bunch of different components, the Rev2 pictured has a WiFi module and IMU built in so that’ll save on space and complexity (although I'm not sure the IMU has a magnetometer built-in.) However, the first challenge was getting it to talk. It wouldn’t talk to any Macs but when I hook it in to a Window’s PC; no problem.
The solution was a creeping reinstall (there's probably a technical name): I had to do a complete manual reinstall of Arduino IDE and all the drivers, starting with oldest to newest until I got one that worked. This meant going through the preferences menu to find Arduino’s cache and wiping it. This is risky if you’re dependent on Arduino projects but I don’t use it everyday so I think I’ll survive.
The second issue was getting it to connect to a WiFi network. Luckily there is a secret one at work that has only WPA encryption (no username, just a password) so I managed to sneak it on. Currently the standard Arduino wifi library – WiFiNINA – has no support for WPA Enterprise without a lot of jiggery-pokery.
The next step is finding a way to get its location in longitude and latitude. Google now charges for its geolocation API which is a pain on a vanity project and not something I wanted to go through the hassle of setting up. Unwired Labs LocationAPI which I found through this helpful tutorial allows you to track up to five devices free for 100 calls every twenty-four hours. I only need to track one device and since it should only need to call the API when it's first turned on this would easily suit my purposes.
The idea here is to ask the Arduino to compile a list of nearby WiFi routers and their signal strength, send them to Unwired Labs and then receive a longitude and latitude, same as the Google Geolocation API. The code in the tutorial is pretty useful but there’s always a bunch of problems to be un-kinked when building a system from different components. The version of the Arduino WiFi scanner library being used in the tutorial had a handy ‘BSSIDstr’ function that converts the byte arrays of BSSID (the mac addresses of nearby routers) to strings so you can feed them into a JSON string. Essentially, the format that the mac addresses are scraped in are in the wrong format to send to the API and you get mangled gobbledy gook if you try. However, BSSIDstr no longer exists so I had to mangle in a ‘sprintf’ bit to do that for me. Sprintf is one of those things I've never properly understood so it was useful to learn how it and byte arrays work. FYI, just for fun, the order of the bytes is backwards so you need to lace the string backwards to get the BSSID in the right order. Then there just some tweaking around with the URL for the API request since it’s all changed since and it was good to go. Et Voila, my Arduino knows exactly where it is on the surface of the world as pictured to a remarkable degree of accuracy.
I already have a magnetometer working from an earlier test so I'm not hugely bothered by the amount of work there so once that's integrated the Arduino will be able to know it's position and orientation when it turns on easily. Most of the stuff that seems to happen in the early stages of these projects is versioning; tutorials use out of date firmware, terms have changed or been removed etc. etc. So most of what you end up doing is chasing around dates and versions to get everything to talk to each other.
If I get any more time I will be looking in to what turns out to be some exceptionally complicated geometry problems which I hitherto had considered child's play. Who knew there are different versions of time?
Knowledge in design part 3; cognitive dissonance and sympathy,
This is more of a short addendum than an entire new line of thinking. A lot of activities last week kept me from reading as much as I’d like but I met up with Yosuke Ushigome of Takram fame on Monday night and we discussed some of this stuff since he at least apparently reads this. We were reflecting briefly on the history and state of speculative and/or critical design with regard to our peers from MA Design Interactions: Why did the canon there struggle to respond to issues that were beyond a limited temporal window and individual scale?The easiest answer to me is in design’s aesthetic history of tackling human problems on Maslow’s hierarchy; where to live, how to eat and sleep, how to communicate and share information etc. All of these things can be interfaced or encountered within the human sensorium and consequently design’s aesthetic sensibility is drawn from the human body and it’s scale. It’s only in recent years that design has attempted to address ‘systems’ and even these are human-oriented with solutions and products largely being aimed at the interface of the human and the system; different information flows and architectures, levels of access or responsiveness. This is as opposed to the approach of an activist or artist who might address the system in total as an artefact rather than as an inevitability.
Take for example, Suzanne Triester’s work; Hexen 2.0 (left) which examines the history of computation through a quasi-occult, quasi-conspiratorial lens. The goal here is not to improve the system or design it in a different way but to give us a pan-historical reading of it that challenges our comprehensive model and presents alternate narratives.This is opposed to any number of brilliant design projects on computation that address the way we interface with the very notion of computation through the interface. For example, the amazing work of IF and their catalogue of data patterns almost all of which feature a hand, a phone, a laptop. They address the system at the point of interface where design is most appropriate and comfortable. This is how cognitive understanding is built between the audience of the design and the idea of the design. We all have hands, phones and laptops, we can project ourselves into the alternatives that IF propose for data patterns. To a degree, Triester exploits the same sympathies by drawing on an aesthetic sensibility of diagrams and visualisations with which we might be familiar and so are equipped to interpret the work and put it in a certain frame of reference.
If I was to think about Augury as a project about computation then I’d say it is further abstract than Triester’s work. It draws on some familiar aesthetics; the audience having to look up indicates it’s about something above us, there are flight numbers and names of airline companies to conclude it has something to do with planes. Though it draws on a popular ancient practice of divination, this was less familiar to the audience which was perhaps a failing. Connecting this ancient divination technique with a contemporary technological equivalent – planes’ instead of birds’ flight patterns used to predict the future – was a knowing cognitive leap rather than one meant to create cognitive sympathy. The project exploited the idea that the audience might question why these things are together as way of teasing them towards the absurdity of computational prediction without having to reduce it to human terms (phones, laptops hands) that would make it more comfortable. From the perspective of my practice I find the only way to deal with things maybe beyond the human scale is to exploit cognitive dissonance as it's impossible to make these things sympathetic to human understanding in their entirety.
While a design project might draw on a more familiar aesthetic sensibility to provoke the idea of the absurdity of computational prediction by exploring alternative device interfaces or human interactions, in Augury Wes and I were keen to highlight the supra-human qualities of computation by placing it in the world of the supernatural. It’s hard to then draw on design aesthetics and logics for this kind of framing, there aren’t really (arguably) tenants, principles or methodologies for designing the supernatural. There are certainly designed aesthetics; colours, shapes, styles but not many functional models.
Let’s put this back into the question; ‘Why did Formafantasma design a chair about e-waste?’ which seems to have become the locus for this thinking. Ore Streams draws entirely on a comfortable and sympathetic design aesthetic – the chair – to engage with a bigger-than-human (I’ve been trying out various words here, you may have noticed) idea/issue. But, they draw on elements of sympathy and dissonance; it’s a chair with which we can all connect experientially but it is also provoking a discussion about e-waste with a particular audience. Consequently the audience might ask ‘why is the chair made that way?’ I am going to stop banging on Formafantasma now, I really do love their work and I’m sorry they’ve become a lynch pin that seems to be unduly criticised here. I do think Ore Streams is great, I’m just using it as an exemplar project for design projects that don’t give me a good sense of why did they do it that way? The follow on from which is what is the best way of doing this? Which is basically a PhD right.
Restoring some regular features - things I learned this week.
A while back I said I liked reflecting on what I've learnt. Obviously it's a bit of a cheat this week because:- I learnt a lot more Arduino stuff, particularly what is and how exactly 'sprintf' works and loads of other stuff about using Arduino with online stuff.
- I've been listening intently to my Arabic philosophy podcast and have learnt a lot about Al-Razi who spent a lot of time refuting Galen and was mostly known as a heretic so most of his writings are only known by how they're refuted by later Islamic scholars. He dared to suggest that four things preceded God - soul, matter, the universe and time.
- The folks at Wikimedia are super cool and have a lot of really interesting stuff going on. (Bit of a cop-out this one, I'll own it.)
And – Channel recommendation
I've loved Girlfriend Reviews since they first started. Witty and irreverent reviews of games which are becoming increasingly more critically engaged in discussion of the industry. The latest one on the new Star Wars game which received lavish praise is brilliant as a piece of media criticism on how games reuse and reconstruct tropes but also now hilarious for my new catch phrase; 'Have y'all lost your minds cos I'll help ya find 'em!'I've already started notes for next week's blog and it's currently Tuesday so I guess it's going well. I hope you enjoy something and it's not too tiresome.