Final positioning paper for Cloudcommuting

Our conventional transport system utilizes central control system that the operator checks and utilises to control the entire system and Citibike sharing system in NYC is not the exception. Still, there are a couple of serious problems including imbalanced number of bikes in the stations and acceleration of it in the current system. The question is, can it be improved by applying a decentralized system architecture model?


The reasons for the imbalanced number of bikes:

The users do not use the bikes as transport to and from their offices, schools or houses. Looking at the bar graph, there are two peaks in the use of Citibike sharing system[ 1]. It implies that the users ride these bikes to go to work in the morning, just like other modes of public transportation that experience their peaks in the same period of time. The map indicates the number of people who go to and leave from East Village in the morning, and evening in August 2014[ 2]. It is clear that much fewer people go to East Village in the morning whereas more people rode the bikes to leave from the vibrant area for restaurants and bars in the evening. This implies that people do not use the bike in the morning, they use it when they return or to go somewhere else. It could be said that this imbalanced flow occurs everywhere in the sharing system in NYC.


The analysis of the users:

Our team, Dan Melancon, David Tracy and I conducted a research about the user types by analyzing the system data Citibike provides monthly[3-5]. The results of the research show that 75 percent of the users are men and the age range is from 30 to 40 years olds in every neighbor. Our assumption was that each group of the station had different range of users in age and gender yet the outcome was almost the same in all the neighbors.


The problem with the current solution:

Since the imbalanced use of the bikes, users have experienced a burdensome problem of not being able to find a bike to ride or a dock to park in their desired station. The current solution requires the central controlling operator to call truck drivers to move the bikes from fully stocked stations to empty stations. However, this creates another problem in that it accelerates the use of bikes in the popular stations and more people would like to park to the popular area where all the docks are full. Furthermore, if the users cannot find a dock to park their bikes by going to the nearest stations, they have to call the central operating system to report the problem because the rule states that the users have to check-in the bike every 30 mins. Otherwise, the users will be charged an additional fee.


Application of Game Theory:

Our team analyzed the problem in this bike sharing system with the theory of, Tragedy of the commons of Game theory. This economics theory by Garrett Hardin states that the users’ selfish behaviors causes a lack of resources[1], in this case, the bikes and available dock. If every user takes into account a lack of resources, self-organizes and self-balances the system itself, the problems that Citibike sharing system is suffering can be solved. It benefits the entire community. Considering Prisoner’s dilemma[6], even though cooperation will benefit the entire system including the individuals, our rational modern thoughts conflicts with gaining the cooperative advantages. But, if all the users leave the last bike or fill quickly on the empty station, or take the bike from full stations as soon as possible, the system can be balanced. The problem is though how to get rational thinkers of our modern Citibike users to behave in a self-forgetful manner.


Utilizing sense of competition:

Ultimately, our game creation’s main point is to see how/if self-interest agents could behave like self-organized agents which could balance the system by applying rules and incentives without asking them to be altruistic. Our final proposal has two main factors. Firstly, every station will provide points when the riders return their bikes and the points change dynamically according to the number of bikes that remain in the stations. Less bikes there, more points the users can gain. Secondly, when the last bike is taken from any station, everyone’s points are reduced and the points become bonus for the first user who parks a bike in that station. In order to change the behavior of the agents in real-time, we proposed to create a mobile application which visualizes the data of their scores and stocks of the stations.


The play test:

As there was time and physical constrains, our play test simulated the bike sharing system of NYC in a smaller scale on the floor at ITP. We created RFID card readers with LED feedback interface as stations, and a customized website for each player which updates the points, bonus and stock of the stations, and scores and bike stocks of the users in real-time. The players can look at their phones while playing. In the testing, we placed six stations with five docks on the floor randomly and asked fifteen players to participate in this game and provided an RFID card for each. The goal of this game is to gain the highest score possible and the players could simply gain a bike from and return it to any station. They could not return the bike in the same station and the dynamic point system with bonus were applied in all the stations. When they gain a stock, they see the popup window saying ‘Do you want to accept the points? Or cancel?’.


The improvements of the game:

We did the play test five times in total and we slightly changed our system and interface design. The first test had only endogenous conditions as it did not have any mission and increased bonus points every 5 seconds. This caused system problems that some people had a strategy to come and go between only two stations. They did not run to the different stations but they won the game. In order to prevent this, we created ‘mission’. Sometimes the user gains a mission when he/she returned the stock to go to a particular station that the system requires. We believe this happens in real life that we often cannot change our directions as well. In the second test, the exogenous factors were 25% of the mission for each player but with a maximum of 4 missions to simulate a normalized state. The bonus was too high to win although they enjoyed the game itself[7]. The third game, we decreased the bonus down to every 10 seconds and the players’ responses to this time were the best among the five tests[8]. Still, some players went back and forth between the two closest stations. In the fourth and fifth tests, we increased the percentages of missions to 60%[9] and 33%[10] and the system in the fourth balanced best. However, the players told us it was boring that they had a lot missions they could not come and gain the bonus most of the time. We also improved the graphic interface by responding to the users’ experiences to tell the condition more intuitively and clearly.


To conclude, it can be said that the success of this game will depend on how players can flexibly go to other stations to gain higher points and bonus without disturbing their study and job and in order to analyze this, we need another play test. Nevertheless, the system allows to tweak the conditions easily, where the players enjoy the game ultimately. I believe that decentered system architecture in Citibike sharing system will work if the game provide desired incentives and penalties to the players/Citibike users.


Cloudcommuting presentation Class 3[1]diagram the number of bikes used in a day, July 1st, 2013







CloudCommuting Final Presentation (1)

[2] diagram shows asymmetrical flow of Citibike users going to and leaving from East Village in the morning and evening

Exploration of Demographic for City Bike Stations in NYC_1

[3] Citibike users Demographic analysis of all the users

Exploration of Demographic for City Bike Stations in NYC

[4] Citibike users demographic analysys of Manhattan Community District 1 to 4

Exploration of Demographic for City Bike Stations in NYC 2

[5] Citibike users demographic analysys of Manhattan Community District 5 and 6 and Brooklyn Community district 1 and 2


[6]diagram Prisoner’s dilemma

CloudCommuting Final Presentation (22)

[7] bar graph of play test 1 showing stocks of every station by time

CloudCommuting Final Presentation (23)

[8] bar graph of play test 2 showing stocks of every station by time

CloudCommuting Final Presentation (24)

[9] bar graph of play test 4 showing stocks of every station by time

CloudCommuting Final Presentation (25)

[10] bar graph of play test 5 showing stocks of every station by time

[1] “The Tragedy of the Commons”. Science 162 (3859): 1243–1248. 1968

Final paper for Understanding Networks

My topic will be networked objects and its physical constrains

When objects are networked, there are a number of physical constrains to make them happen. My paper will examine all the things required?when the objects surround us.

  1. write a typical day with full of networked objects including alarm clocks and traffic lights
  2. draw diagram of them
  3. add notes what happen if the network fails and what is the backups

Reference: The Works: An anatomy of a city, Enchanted Objects

Traceroute, the findings

Traceroute project

My findings:

  1. Even though IP address is different, the physical address is often the same.
  2. Different ISP uses the same physical address
  3. a couple of possible addresses always show up

Screen Shot 2014-10-18 at 10.09.15 PM

Screen Shot 2014-10-18 at 10.11.39 PM


This is traceroute from ITP to


This is traceroute from ITP to

Surprisingly, my manual findings and ‘visual tracing tool’ showed different information. The company owns the IP address are different. The location they traveled were similar, though.

Screen Shot 2014-10-18 at 10.20.43 PM

Assignment for Maps Lies Storytelling class 4

Assignment 01:
Find three existing maps
1. maps obviously tells a lie about space

all the 2D world map is inaccurate in that on 2D map, it is impossible to make all the elements area, distant and angle accurately.

Cylindrical equal-area projection with oblique orientation





2. Maps the author even does not recognise his or her map lies.

This bizarre map, which appeared in the third volume of Diderot’s Encyclopédie, dates all the way back to 1772.

The land seems extremely distorted.


3. Maps obviously lie

But, in the past, I believe this had real geographical information that I felt if the stations are close to each other, the distance must have been closer as well. Of course, it isn’t. The map maker’s priority is to show the cross connections.


Assignment 02:

This map shows bike lane and historical districts in NYC. It’s for specifically a tourist who want to visit historical district of NYC.

Assignment 03:

Odyssey.js Storytelling map (this is really undone that I have not created a map I want to tell a story).

Cloudcommuting assignment 03

Our team for mid-term project is to analyse users’ profiles of selected areas such as Financial district, SOHO, East Village, Brooklyn Heights.

Firstly, we are looking at the users’ behaviours. This graph shows a number of Citi Bike users by time on 1st of July on 2013. It is clear that they use bikes to go to their offices and schools by looking at the peak period. It is also interesting that the number of bikes used in evening time is higher than that of morning. This implies that

This is our another assignment to show the cause and effect loop.

This is our analysis of Citi Bike stations in Lower Manhattan