Final Work/Prototype Improvement [ Physical Computing #6 ]



In the 1st prototype crit, I received a lot of suggestions. I realised that most of my audience can not understand what I am trying to do from the presentation I gave them during minutes. I think it is a complex system indeed, but I believe that in this system the complex logic is hidden behind the simple interface – which is just several buttons. It come up with me that the most important improvement for me before the assessment is the presentation – I have to clearly tell the audience what this project is. So I took follow steps.


  • Logic

I improved the logic in this system. In the old version, all of the lights that present bus station will be off by default. If anyone needs the bus to stop, he will push the button and the light will thus on. However, in my following research, most situation is that the station needs to be stop at. So I set all of the lights on by default, which means the bus will go to every station by default. And I changed my 3 clients to 2. Because the driver and passenger on the same bus need more communication and the information they have should be the same. I set 2 kinds of buttons in the NEW BUS PANEL. One is for the driver, which will turn off the light once be pushed. The other is for the passenger, which will turn on the light again once be pushed. That means if the driver recognise the heavy road and unnecessity of a station, he will turn off the light [which means skip that station] by productiveness. On the other hand, if someone [including the passengers at stations/on the bus] needs the bus to stop, he will turn on the light so that the driver will know in advance that the station he can  not skip. The other client, apart from the NEW BUS PANEL, is STATION PANEL, which is exactly the same as before.


  • Code

Because I set 2 kinds of buttons on the NEW BUS PANEL, there will be a number of buttons on that panel. It is unwise to control each panel using the original arduino code. I referenced a library of arduino named ‘Keypad’



const byte rows = 4; //four rows
const byte cols = 3; //three columns
char keys[rows][cols] = {
byte rowPins[rows] = {5, 4, 3, 2}; //connect to the row pinouts of the keypad
byte colPins[cols] = {8, 7, 6}; //connect to the column pinouts of the keypad
Keypad keypad = Keypad( makeKeymap(keys), rowPins, colPins, rows, cols );

Instantiates a Keypad object that uses pins 5, 4, 3, 2 as row pins, and 8, 7, 6 as column pins.
This keypad has 4 rows and 3 columns, resulting in 12 keys


Besides, in the previous version, I get the current location of the bus from the BUS DRIVER board, and transfer this message via MQTT to BUS PASSENGER board. This actually brought unstableness and unnecessary information transportation to my arduino board. In the new version, I get the location from the centre board, which is the raspberry Pi. The location message will transfer along with the station message, it is more stable and controllable now.


From all above, this is my new code of the NEW BUS PANEL.



Moreover, I tried to add the mobile function for passenger, which I designed in the original idea but did not achieve in the 1st prototype. This panel is for the passenger on the way to the station, there will be the same button on the mobile App with the bus station. Once the user push the button, the light for the bus driver will be turned on. And for avoiding trick, one user can only push the button once in 30 mins.

In order to do this, I set a server in my raspberry Pi, which will monitor the content in my email, which is sent from Google Voice automatically, which is forwarded from the SMS received by Google Voice Number.

All right I know it sounds a little bit complex. But the result is once someone send the same command[with the MQTT I used before] to my Google Voice number, the message will be transferred to my raspberry Pi. The MQTT server will thus publish it to all of the arduino panel. That is to say we can control the system via SMS now.

Github Resource:

Google Voice Resource:


Unfortunately, Google Voice is now only available for US users. I need a US mobile number to active this function. But I asked my friend in US to test it and it works.


  • Front End

In order to tell my audience more clearly in shorter time. I designed a box to pack my system. I choose a real bus route running in London now to load my system and prove it is really workable. It is route 23, running between northwest and northeast in London, mainly operating between Oxford Circus, Piccadilly Circus and Bank. And I choose 7 typical stations on route 23 bus, numbering them.

Physical Computing_print02


I redesigned the route map, just like the tube route map – this is the suggestion from Gareth, it is actually not necessary to draw the accurate map, the audience could understand even if there is no accurate map on tube.

And I engraved the map on the front face of my box using laser cut.



Problem comes again. Because I choose 6mm plank to laser cut, it is too thick to stick my button module – I can not reach my button with wire from the other side. I designed my box again, to dived the front face into to layers. The graphic will be engraved on the upper layer, and the location for button and light on the upper layer will be cut out – to make the button and light module stick to the lower layer, so that they can impale the plank.




Instead of soldering them all, I used conductive tape to link the button and GND end, leaving the control pin soldering them and stick into arduino.


For the reason of transferring the message to MQTT server, I put a raspberry Pi in each box. However, the raspberry Pi needs power cable, I can not make my box wireless. But I think there will be power cable on bus in the end!

Final Work/Prototype Improvement [ Physical Computing #6 ]

Social Thing Prototype [ Physical Computing #5 ]



Based on the idea I got in my research, I designed a new stop-calling system for bus. It is basically a system that help to communicate between bus drivers and passengers. So maybe I can say my tribe is bus user.


  • The system

Similar with the button we use in lift, the system include three parts.

  1. A series of buttons(and light) for BUS PASSENGER. Each of the button presents a station on the route. The passenger could press the button of their destination once he get on the bus. Meanwhile, they can know which station the bus will stop – just like we do in lift.
  2. A series of lights for BUS DRIVER. Each of the light presents a station on the route. Once the relative button is activated, the counterpart light will be turned on. That is to say, the driver will always know which stations he have to go and stop.
  3. A series of button(and light) for STATION PASSENGER. Each of the button presents a bus route that is mapped at that station. If there is any passenger wants to catch a bus, he can push the counterpart button. Then the light in the bus for driver will be turned on.

In this case, because all of the drivers and passengers have a clear mind that where he will go and where the bus need to stop, the route map will be considerable for the bus driver. For example, if the main road is extremely heavy during peak time, the driver could choice another road – because it is not necessary for all of the bus to stick on every road.

Or if there is no one getting on or getting off at some small station during night, the bus driver can choose the shortest route – for saving energy and time.

I made my first prototype according to my idea, using 3 arduino board. Each board presents a client part in my system. For the controlling of Button and light, I used arduino. The original code is as follow:


After I built basic code. I set a flashing light to present the current position of the bus. And after the buss passed that station, the light will be no available any more.



In order to build connection between these arduino board, I used MQTT broadcasting server. It is a light protocol to publish message via a centre server. I set a raspberry Pi as my MQTT server.


And I used node-red to transfer message, which is running on computer/raspberry Pi as well.


information flow.png

Social Thing Prototype [ Physical Computing #5 ]

Social Thing Research [ Physical Computing #4 ]



This week I interviewed some bus drivers and passengers [at station].


  • The problem we have now
  1. The route maps of some buses are curve or even ring shape, especially on the outside part of main route. That means every bus in every operation round will take a lot of time to stop at every station, while there will be very few passengers going on or off.

屏幕快照 2016-06-23 15.54.07.png

Physical Computing_print02


  • Solutions for now

In order to tell the bus driver that there will be no one getting off, we set a ring bell on bus. The problem is, however, the bus driver can only know if there will be passengers getting on or off at the next station. They still have to go to every road according to route map.


  • My Idea

Inspired by the button in lift, which will appear every floor the lift will stop. I am thinking if we can set a similar system for the bus. Because most of us know which station we are going to once we get on a bus. Maybe we can push the button that presents the station of our destination once we get on the bus. So that the driver will know which stations they have to go on the whole route map. Similarly, if someone want to take a bus from a station, there will be a same system at the station. Once anyone push the button at the station, the driver will know that he have to stop at that station.

Social Thing Research [ Physical Computing #4 ]

All Watched Over by Machines of Loving Grace[ FMP Practice Proposal ]

All Watched Over by Machines of Loving Grace




All Watched Over by Machines of Loving Grace: View from the heavens


Field of Study

Speculative Design; Video Art; Narrative Design; Installation Art;



    “The more tremendous the divinity is represented, the more tame and submissive do men become to his ministers; and the more unaccountable the measures of acceptance required by him, the more necessary does it become to abandon our natural reason, and yield to their ghostly guidance and direction.”

-David Hume, The Natural History of Religion

The great philosopher David Hume believed that our own weaknesses and vulnerabilities gave rise to our belief in ‘invisible, intelligent powers’, and further guided their evolution from ancient ‘vulgar’ polytheistic idolatry to the dominant monotheistic religions of today. Karl Marx saw religion as ‘the opiate of the people’, that numbed our pain, and gave us moments of relief, in the harsh soullessness of reality. Friedrich Nietzsche believed we invented Gods as a means of justifying our evil intent. Geneticist Dean Hamer goes as far as speculating that our affinity for religious belief is linked to a specific ‘God Gene’ in our DNA.

Philosopher and cognitive scientist Daniel Dennett looks at the evolution of religion through the lens of ‘memetic’ Darwinian evolution — a term coined by Richard Dawkins to describe a cultural unit of inheritance analogous to a ‘gene’. He suggests, similar to wild species of plants or animals, ‘wild ideas and beliefs’ are born naturally ‘in the wild’. These wild ideas adapt, they evolve traits, to co-exist with the society they’re in. Some traits help ideas spread — those ideas and traits survive. Other traits cause ideas to die and become obsolete. Those ideas with traits most suited to the requirements of the local culture are eventually assimilated, domesticated and ‘farmed’ — mass reproduced — by stewards, guardians of those ideas. In a feedback loop, as both society and beliefs develop, they symbiotically co-evolve.

There is no universally accepted theory on the emergence of deities and religion. However, there are strong correlations between traits of society vs traits of deity & religion. e.g. Land-owner based agricultural societies which require non-egalitarian structure tend to have more wrathful, ‘moral’ deities. Subsistence farming or pastoral societies which do not require hierarchy or massive cooperation tend to have inactive or absent deities. [Peoples, H. C., & Marlowe, F. W. (2012). Subsistence and the evolution of religion. Human Nature, 23(3), 253–269.;

For millennia, religions have evolved, responding to their host culture’s traits and needs. Thousands of beliefs have come and gone. Some have disappeared completely, some are localized to small groups, and others grow to dominate across countries and continents. As societies grow and change, so do the deities and religions along with them. Those beliefs and values which are most culturally fit survive.

We are living in times of increasing technological surveillance. In this post-Snowden era we are more aware of the extent of this invasion of privacy than ever. But did the Snowden Revelations have the impact we might have hoped for? Did they provoke a public outcry from the masses? A unanimous demand for privacy? Not quite. The masses are apathetic — perhaps even sympathetic, finding safety and comfort in knowing that a Higher Force is watching; protecting those who are virtuous, the law-abiding. He who is innocent has nothing to fear. He who does wrong will be found and punished.


Man invented god to inflict fear, control and power. It was ancient religions that imposed omnipotent, omniscient and omnipresent powers watching over us, judging us, protecting us — a myth fabricated to control the masses. Today, as our societies lose spiritual sensibilities, we are drowning ourselves in a break-neck race of materialism and technological submission. So The Overseer too is adapting, co-evolving. As its metaphysical traits crumble and become obsolete, the gaps are filled and substituted with new traits — physical, material, digital traits. The Old Gods cannot protect us anymore, so we need new ones. We have killed God, as Nietzsche says. But we are rebuilding Him, with Technology. The myth is becoming real. We’re edging closer and closer to an authentic man-made deity. Living up in The Cloud, watching over us, listening to our thoughts and dreams in ones and zeros.

A Digital God for a Digital culture.

Through a meditative, trance-like hypnotic state, we can be one with Him, create a personal connection, and hear His comforting voice, preaching to us the truth that we crave.

Dim your lights, turn up the sound, lean back, relax and let yourself go.



The script will contain modified quotes by pioneers of quantum mechanics Werner Heisenberg, Erwin Schrödinger, Wolfgang Pauli, Paul Dirac, specifically regarding the Observer effect in Quantum mechanics. The quotes are modified as to not sound specifically about quantum mechanics, but more ambiguous, relevant to both the observer effect of quantum mechanics, but also relevant to the surveillance situation we’re in. The results highlighting the similarities between the two: there is no such thing as a passive observer, the act of observation influences the observed and affects how he/she will behave, the observer and the observed end up inextricably linked, the observers observation is not an objective truth but a biased response to the information received based on the mode of observation etc.



The work will be a video installation consisting of a meditative video with a synthesized voice-over. The resemblance of the GCHQ building to a giant robotic eye – such as Kubrick’s HAL in 2001 – is uncanny. The little cars, roads, buildings etc. the electronic circuitry feeding this giant robotic eye. It’s not humans watching over us, logging our emails, our phone records; but it’s algorithms, software designed by humans, housed in machines built by humans.



All Watched Over by Machines of Loving Grace from Memo Akten on Vimeo.



Background meditative bowl sounds from

used under Creative Commons license.

Aerial photos from Google Maps.

Title “All watched over by machines of loving grace” from Richard Brautigan’s 1967 Poem and Adam Curtis’s 2011 BBC documentary series.

All Watched Over by Machines of Loving Grace[ FMP Practice Proposal ]

Social Thing Tribe [ Physical Computing #3 ]

The Bus Drivers.001

This is the main brief of the Unit Physical Computing. We were asked to design a thing for a specific tribe, focus on the communication among them. And my tribe is the bus drivers.


The public transportation has been one of the most important topic for every government. In UK, according to my research in another project [Collaborate ! Project], the power used on public transportation accounted for over 10 percentage of whole generated energy. That means, if we can save even a little bit in public transportation, it will be a lot that it actually did.


On the other hand, it is obvious that our transportation is not fully functioning yet. For example, some buses are always delayed during peak time, while some are over-running between the small stations which has few passengers. Every bus have to be operated sticking to route map, although sometimes they may don’t have to do so.

屏幕快照 2016-06-01 01.00.24.png


It caused tiredness among bus drivers, inconvenience among passengers, and most important, inefficiency of such a huge system.

Social Thing Tribe [ Physical Computing #3 ]

Arduino Take OffIntro Arduino [ Physical Computing #2 ]


The stage 1 of physical computing [workshop of Tom] has been finished. This week we had a small brief named ‘Arduino Taking off !’ . We were divided into 6 groups and received a same task:

Transfer a message from the previous group to the next one, but in another way. That means we can not say it directly but have to make sure that the next group could understand this signal. The only rule is make it as creative as possible using arduino.

After discussing, my group decided to use light to transfer message. Precisely, we mapped a specific meaning to each colour of light. Because the colour of light could be change according to the code we wrote in arduino, we can theoretically get a number of combination if we use properly the colour and orders.

JJ and I were in charge of coding, while Nidhi and Eva work on the craft. It is not hard for us since we had already learned similar code from Tom. Just solder the module together, wire them and input code.

Unfortunately, both of the message we received were totally wrong, due to the noisy environment I think.

Other groups were brilliant as well. Some of them use flag, while other use sound and Morse code.

Arduino Take OffIntro Arduino [ Physical Computing #2 ]