Some photos from Shakti Lamba who is currently testing Symbai in the Chhattisgarh state in north eastern India.
The whole system is solar powered, and provides it’s own networking via the Raspberry Pi synchronisation node shown here. The android tablets also recharge from the same power source. The Raspberry Pi networking is a direct descendant of the experiments we carried out in London during the Sonic Bike workshop.
Here are three of the tablets syncing their data – photographs for people to identify each other (names are used differently to western culture), audio recordings of verbal agreements (a requirement in preliterate societies), and information of who knows who.
More on this free software project, links to source etc over at foam kernow.
Following on from the last in this mini series, the giant 16 byte multiplexer is finished and tested – lots of head scratching due to shorts and wonky solder joints (it’s amazing how sensitive CMOS logic is, interference on accidental free pins causes strange effects) and I’ve replaced the breadboard with a new interface board between the Pi and the multiplexer.
Now it’s time to think more about the ‘front end’ – here are some prototype programming blocks made from the ‘holes’ from a hole saw (I’m chopping up bits of driftwood). These include a central drill hole, which we can use for an indicator LED.
This is the minimal circuitry needed for each programming block – it’s just a 4 bit identification code (reconfigurable via jumpers) and the LED, mounted around the 7 pin VGA style plug.
Here it’s mounted in the block after a bit of hollowing out. To be fully kid-proof I’ll probably eventually set the internals in epoxy glue.
Testing the plug/socket wiring on the breadboard. The plan is to paint the top surface of the programming block in blackboard paint so different instructions and languages can be tested and built with the same blocks. It also intriguingly makes abstraction possible, which is usually a problem with non-text based approaches, but this needs more thinking about.
Here it is with another unenclosed block attached to the main board, and via the new interface to the Raspberry Pi. The interface will need a bit more circuitry to drive the LEDs – which will be able to be lit in different ways depending on the needs of the language, perhaps sequential in some cases, more dependant on logic in others. Also, different shaped blocks or different coloured LEDs may have different meanings in a language too.
A couple of screenshots of the hindi version of Symbai – our solar powered Raspberry Pi/Android anthropological research tool. As is usual we’re still having a few issues with the unicode but it’s nearly there. We’ve been working on this software for the last few months, making sure the data (including photos and audio recordings of verbal agreements) synchronise properly across multiple devices.
Update after the last post. After many hours soldering 75% of the board is complete! The Pi can now address a whopping 12 bytes of data.
After thinking about it for a while, and checking with the languages I’m planning to use – I’ve decided to double the number of instruction ‘slots’ by halving the bits to 4. This doesn’t actually change the core hardware at all – I’ll just scan two at a time and split them in software (part of this project has been to see how much easier it is to change software than hardware). Some of the instructions can span two addresses if needed, but this makes more efficient use of the resources. The ports on the left of the board are where the plugs for the programming ‘interface’ will come in – each one will now split to two locations.
Here’s my test GPIO software running on the Pi, constant testing has been the only way to stay sane on this project. Eventually I could replace the Pi with a microcontroller for some applications, but the Pi has been a great way to ease the prototype process.
Since the last update I’ve connected the Raspberry Pi to the board, and after a bit of debugging I have a python script that polls bytes (more accurately 4 bit ‘nibbles’) via the GPIO ports from 16 addresses. I didn’t blow up the Pi, although I did cause hard resets a couple of times with wandering connections. Now comes the mega wiring phase.
I’m starting a new exploratory project to build a screen-less programming language based on two needs:
A difficulty with teaching kids programming in my CodeClub where they become lost ‘in the screen’. It’s a challenge (for any of us really but for children particularly) to disengage and think differently – e.g. to draw a diagram to work something out or work as part of a team.
A problem with performing livecoding where a screen represents a spectacle, or even worse – a ‘school blackboard’ that as an audience we expect ourselves to have to understand.
I’ve mentioned this recently to a few people and it seems to resonate, particularly in regard to a certain mismatch of children’s ability to manipulate physical objects against their fluid touchscreen usage. So, with my mind on the ‘pictures under glass’ rant and taking betablocker as a starting point (and weaving code as one additional project this might link with), I’m building some prototype hardware to provide the Raspberry Pi with a kind of external physical memory that could comprise symbols made from carved wood or 3D printed shapes – while still describing the behaviour of real software. I also want to avoid computer vision for a more understandable ‘pluggable’ approach with less slightly faulty ‘magic’ going on.
Before getting too theoretical I wanted to build some stuff – a flexible prototype for figuring out what this sort of programming could be. The Raspberry Pi has 17 configurable I/O pins on it’s GPIO interface, so I can use 5 of them as an address lookup (for 32 memory locations to start with, expandable later) and 8 bits as input for code or data values at these locations.
The smart thing would be to use objects that identify themselves with a signal, using serial communication down a single wire with a standard protocol. The problem with this is that it would make potential ‘symbol objects’ themselves fairly complicated and costly – and I’d like to make it easy and cheap to make loads of them. For this reason I’m starting with a parallel approach where I can just solder across pins on a plug to form a simple 8 bit ID, and restrict the complexity to the reading hardware.
I’ve got hold of a bunch of 74HC4067 multiplexers which allow you to select one signal from 16 inputs (or the other way around), using 4 bits – and stacking them up, one for each 8 bits X 16 memory locations. This was the furthest I could go without surface mount ICs (well out of my wonky soldering abilities).
Now 4 bits are working it’s harder to test with an LED – so next up is getting the Raspberry Pi attached.
At the end of July I helped out with the dbscode summer school. The idea of this two week course was to encourage algorithmic literacy, with focus on employment – agile methods and test driven development (TDD), and aiming at people about to enter, or re-enter employment rather than the teenagers we focused on in Easter. We were interested in teaching the culture the participants will encounter in modern software development, and this was driven by Cornish embedded technology company Bluefruit and John Jagger – consultant and creator of Cyber-Dojo. We had 9 participants from a mix of backgrounds, some recently graduated students and some experienced programmers wanting to catch up with software engineering practice.
We mixed this group challenge with Cyber-Dojo, which meant we could do little 45 minute programming exercises each day. My observations, based on sporadic visits throughout the two weeks – were that one of the biggest surprises, particularly at the start, was that the level of improvisation and experimentation (rather than already ‘having all the answers’) was a key part of professional practice, rather than something they should avoid or feel embarrassed about. The focus on TDD helped very much with this as well as doing a project that we as teachers hadn’t tried before – this I feel is key to providing learning about how to learn rather than an overly didactic (and not terribly realistic) experience.
I’ve recently been building the Mongoose 2000 “group composition” tool that the researchers will use for recording information about a whole pack of mongooses (and synchronise data via a Raspberry Pi providing a local wifi node) in their field site in Uganda. As I wrote a bit about before, one of the interesting things about this project is that the interface design has to focus on long term speed and flexibility over immediate ease of use. In this way it seems appropriate that it’s moving in the direction of a musical interface rather than a normal touch screen interface. The different colours in the mongoose selectors show which individuals are present and which have data recorded from them already, the screenshot below is the section where they record relationships between the adult females (at the top) and adult males that may be guarding – or pestering them (below). At the same time, they need to be able to record events that may be occurring with the pack as a whole – in this case an interaction with another pack of mongeese.
On Saturday I teamed up with Falmouth University’sMakernow team to do a kids coding event at the Royal Cornwall Show with a new Raspberry Pi cube (based on the one used at the DeerShed Festival last year). We had a constant stream of families and kids wanting to try Scratch coding, and we had a 50/50 gender balance in terms of helpers which I think with these sorts of events is critical.
The part I like best about public events like this are talking with the parents and teachers. The best questions are the fundamental ones: “why should we be teaching them how to program?” which was a great opportunity to get my thoughts straight – the official economic reason is not one I’m so motivated by: “to encourage more talent in the tech sector”. The actual reason I do all this (mostly on a voluntary basis) is the feeling that as we find ourselves living in a computational society, where everything we do is algorithmically processed, the future for people who only know how to consume technology is very different from those who are not afraid to question it, who know it’s possible to take it to bits and rebuild it in new ways.
This is also the reason that I can’t get very excited when teachers tell me they are buying iPads for use in their school – there are some interesting programming environments on them, but the kind of creativity they support cannot, due to Apple’s core business model, encompass this kind of questioning – they can’t escape the sandbox. For example, when I last checked, you can program iPads, but not share the code or work collaboratively as it would bypass the AppStore distribution model to do this.
This relates to the answer I gave to “why should we get a Raspberry Pi” – as it provides a platform that encourages a fearless relationship with technology, it doesn’t have the family email account on it, it’s cheap and nobody cares if you manage to delete the entire operating system, just copy a new sdcard. This stuff has to be possible, and encouraged – if we are to eventually have a society that can have any meaningful debate on increasingly thorny computational/network/society issues such as those related to GCHQ mass spying.
Back to the kids – it was interesting that the majority of the older ones had already used Scratch, either as part of their normal school lessons, or an after school activity (anecdotally, this is sharp improvement over the last year or so). Some of them were keen to show off their skills, which was a great way to demonstrate to the younger ones what was possible.
For the older ones I’m continuing work on the Minecraft API coding project – making simple 3D primitives to demonstrate functional programming in Python. You can explore the results of your programs by walking around and digging into structures generated in a familiar world. More on new versions of that soon.
Saturday saw the first dBsCode taster workshop, for budding programmers between 11 and 16. We set up 20 Raspberry Pi’s, which we networked together and used our new procedural Minecraft 3D shape primitives to build a number of projects in Python involving castles, spiders and an infinite house generator.
Networking was very important – it enabled them to jump into each other’s games which started as a major distraction, but ended up being useful – as people could see what each other were doing and work together.
As part of this, some level of ‘griefing’ was present (where other players interfere in your world), but asking them about this during the breaks, the consensus was that this is part of the culture of Minecraft – I even instructed victims to pull their network cables out, but they saw that as completely unnecessary. Most of them took turns in both constructive/collaborative and programming activity and destructive/graffiti like activities associated with griefing, and this was acceptable to them. The use of code to easily rebuild structure after damage (or being able to remove people with liberal procedural application of lava) was therefore quite an attractive feature of the code approach.
It was common to adapt the programming to fit their understanding of Minecraft, so it seemed natural to take on a hybrid approach to building – using Python to do the heavy lifting (building, or extracting large areas) or repetitive tasks, after which they did the fiddly or more creative bits manually as normal. For example one student used the sphere primitive to extract huge caves underground, and then filled them with little hand made shrines and sculptures.
What was interesting was that to some extent the ‘experts’ at Minecraft (many of whom already document their creations on Youtube channels) found this more challenging in many ways than those less attached to the Minecraft culture – who were more accepting of new ways of doing things.
The manner of programming we used here – running Geany (a lightweight Python IDE) at the same time as Minecraft, was completely in line with livecoding practice, as programs interacted with the Minecraft world in realtime with network messages. The great thing about the rather slow network bottleneck is that you can walk around a structure while the program is creating it, which allows a much better understanding of how the process is working than if it instantly popped into existence.