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 ]