The old story of Robert the Bruce seeing a spider fail and fail again while building his web was recalled when this fellow dropped down above my head as I grappled with electronics and code. My problems may well not be as knotty as King Robert, but they are certainly giving me sore shoulders. Always on the lookout in this project for parallels in my own practice, it feels reminiscent of the difficulties in learning to throw. It is admittedly a vague memory, but I see it in students on the wheel. Learning is difficult, challenging and takes time and resolve. Like the spider, who eventually succeeded in building it’s web.
One of the issues I came across was trying to get the male header pins to stay in their socket. Contrary to the instructions, they didn’t just work and needed some modifications to take the plastic shoulder off. This was done with a Stanley knife while being held with a pair of pliers (far too small to hold safely with fingers). The point here is not so much the problem, but the principle that instructions are not always perfect and that careful looking, like a proper craftsperson, is required to engage in additional problem solving. The solved problem then becomes one of those little tricks one gathers when working with materials – it becomes a thing one simply does, rather than a problem.
The building of this circuit, which also included the figuring out of how to press the potentiometer firmly into the breadboard, was successfully done from the diagram rather than the pictogram. Nice.
Code remains largely mysterious. The projects book is a little inconsistent with its terminology and not great at explaining basic principles. However, it is recognised there are multiple ways to explain things and to learn things. Some methods suit some people more than others. My method is to make statements my own by note taking and attempting to organise thoughts in a way that makes sense to me. The act of writing, note taking and reiterating is a way of getting those paths in the neurons established. At least that is the picture I have in my head. This is about learning a new craft and the mixture of doing, writing and reflecting is good. It still makes for sore shoulders, however.
Instead of diving into the next project, I wanted to really dig into the code here and see if I was understanding what was happening. For all the apparent fixedness of the code, it turns out there are some things which are flexible. For example, I wondered if the Servo needed to be named ‘myServo’. So I tested the code by changing the ‘myServo’ to ‘steve’ and it worked fine. It turns out it can be named anything, as long as it is referred to by that name in the later lines of code. The same goes for ‘potPin’, which I changed to ‘thepinforthepotentiometer’. It may also apply to ‘potVal’ and ‘angle’. In other words, anything that is defined by the coder, usually in black text. Names mustn’t have spaces in them, and they are case sensitive. This isn’t to say the conventions of shortening words (potentiometer to pot, for example) aren’t valuable in terms of typing time and potentially even code running time within lengthy code, but it feels somehow good to know you can name things the way you want.
Libraries are akin to the likes of prepared clays, underglaze colours and glazes. Encapsulated in these bags and jars of simple-looking materials is a mass of technology in the form of mining machinery, logistics, processing and scientific knowledge. Captured in that jar of blue underglaze is a trip to Africa…
Here is some of the explanations and little tests I have made for myself.
