What is this

It aims to analyze NYC Citi Bike as a P2P urban resource allocation system working with both data visualization and computer simulation models. 

Also, we designed an experimental game called cloud-candy as the design research, prototyping and govern our own bottom-up MoD system. 

Summary

This course introduces the theory, underlying technologies, and operational complexities of intelligent mobility on demand (MoD) systems, we were focusing on NYC Citi Bike sharing program as a living laboratory. During this course we've studied the limits of efficiency of existing operation models and explore how information technology, social mechanism design, and game theory can be used to design the next generation of intelligent self-organizing MoD systems that motivate their own users to rebalance the fleet instead of trucks and employees. 

Midterm

For midterm project, we were suppose to create a simulation model to explain or replicate a pattern you observed in the data. 

About the Concept

I am come from China. Almost every family live in city has at least one bike (please note that it is not one bike per person). We have bike sharing system like citibike in many developed cities in China too, however, the picture is totally different. Usually, bike sharing system is build for tourists instead of citizens, because for most of them they've already got bike in home. In terms of that, basically, there is no such severe balancing problem in bike sharing systems in China. The point is "the user type is different". 

So I put some questions forward: "What are the different user types in citibike system?" "Any different user behaviors behind them?" "How the different user behaviors affect the balance and imbalance of the system?" I thought we could get close to our solution when we get a better understanding about the relationship between routing pattern and user types. We keep developing this concern and concept until our final project. 

Details

As we know that there are two main different user types in citibike system, annual subscribers and casual users (non-subscribers). We decided to analyze these two user types separately to see if there's any difference behind their behavior. We got data set from citibike API and visualizing the dataset in Processing. 

We were chasing the movement of bikes took by annual users and visualizing all the their biking behavior pattern happened in one day. As you can see from the following pic and videos, causal users' pattern (purple) is more scattered and annual subscribers' (red) seems like having more straightforward goal in using this system-- for work (mid town focused). For causal users, more dropping and taking activities happened around lower Manhattan and Central park, which shows the difference on the goal and need of two user types. 

So, we came up with some assumptions as the potential ways to rebalance the system. "If we could add more randomness (this is what I assumed based on my experience in China, tourists' behavior are more causal and random) into the system, it will be helpful for rebalancing the system." "So many tourists are visiting NYC everyday, why wouldn't we use tourists as a resource to balance the system (social innovation thinking), because we thought tourists would be a perfect and sustainable 'randomness' for the current citibike system."

Test and Verify

In order to verify our assumption, as a part of the requirement in class, we test our model in NetLogo. This was the first time for us using NetLogo. Frankly, we have not got really useful info from trying it... Of course we knew that it requires a much deeper and wider test for figuring out our proposal-- how different user types affect the balance within this system.

Basically what we did here is checking how the simulation system works by changing the proportion between annual subscribers and casual users. Also, we could custom it by coding it, however, we could not fully manipulate it to cater to our simulation requirements as time was limited. 

RFID Game Design (Gamification exploring)

Before final, we made a interactive gaming system by using Arduino Ethernet and RFID card to simulate the balance system. We ended up with making a Mario-theme, Simon-like game to simulate the situation that users could balance the system with taking, moving and parking bikes(cards in game) within a specific pattern, which will affect the operation and the end of the system.

The game mechanic is the same as Simon. Players have to follow the pattern randomly generated by tapping different RFID cards(has coin, flower, mushroom and star pattern on them) to the reader. Also, one more pattern will be added in the end of the sequence based on the former patterns. The difficulties increases as the process goes. 

Final Project

For the final project we have to design, prototype, and play an experimental game that integrates physical, digital, and social domains to explore how incentive mechanisms and opportunistic behavior create a bottom-up approach to govern MoD systems.

About the Concept

Eventually, we've designed and prototyped a low tech-related interactive strategic installation, Cloudycandy, which keeps tracking users' moving patterns on the floor with minimum user behavior changing. Some key concerns behind our design could be covered as follows:

  1. As the saying goes: the best interface is no interface. We want to doing our test within minimum disruption as the prerequisite. The only behavior changing force and motivation in our project is users' empathy and personal affection, which is key to our concept. 
  2. In our project, the active and positive role has been highlighted by treating users as beneficiary as well as benefactor
  3. Instead of being totally competitor (for limited resources) in the current citibike system, users are collaborator in our system . The users' goal in our project is enjoying and spreading the sweetness of candy and building mutual trust
  4. Collecting and observing users' behavior under this ideal condition (testing it in ITP community)

We put several bags of candy in different areas on the floor, waiting for the first player picking it up... As the system map on the left corner shows, student 1 is taking candy from candy bag and bringing the bag from Front Area, walking through J. Area to the shop and giving the bag to student 2. The arrow signs stand for material flow as candy in our case, dash lines stand for information flow as the info signed on candy bag here. 

Rules

  1. Player could pick one candy (SNICKERS, JOLLY or LOLLIPOP) from the candy bag
  2. Write down some info which include player's name; which kind of candy choice; where he/she got the candy bag
  3. Hand the candy bag to someone else you want to share (Player may or may not move to some other area) 
  4. The new receiver repeats step 1.2.3

Details and Takeaways

  1. As the routine activity on the floor, students going for classes starting in different classrooms, like the daily moving patterns happening in citibike system. 
  2. Ideally, we assume that different candy choices reflect the players' preferences (user types). We wanted to get some hint about the relationship between the user's candy picking and place staying, for example user who likes staying at lounge area (a noisier open area) may have a more extrovert personality. 
  3. We collected all the data from candy bags, and edited and classified it in csv file. Later, we visualized this data set in Processing and made a heat map
  4. Most isolated area is the shop, even though it is the most isolated from the rest floor, it had the second highest level of sharing.
  5. Most connected area is the lounge area and it had the highest levels of sharing.
  6. The layout of the middle of the floor is especially conducive to sharing. 

Designers: Ran Mo, Adarsh Kosuru, Neil Solomon, Eozin Che.

Design Research, Concept Generating, Illustration, User Testing, Part of the Coding Work.