Showing posts with label Cloudcommuting. Show all posts
Showing posts with label Cloudcommuting. Show all posts

Trying out my own pyramid scheme

To explore an "equilibrium of an ecosystem in which players’ selfish behavior collapses the system," I decided on the classic pyramid scheme, in which a person's success depends on their recruiting of additional people, ad infinitum. The inherent problem is easily illustrated in the image below, which proves that a system of this nature is quite literally unsustainable.



I designed an ambiguous pen-and-paper "game" to see if I could embroil my colleagues in a similar scheme. I told two random people that the goal was to create a team-network and they needed to each recruit two people, and tell them the exact same thing I told them. They would fill out the small papers I provided and continue until the paper ran out. Each recruit was to return their papers to the person who recruited them, in effect creating a depth-first search, since I would not get any papers back until all of the people below me had submitted them to their higher-ups.



I also mentioned that their score would be determined by the number of people they managed to recruit underneath them, so that they should only choose people who they thought were likely to carry out the instructions. The lack of real incentive didn't seem to hinder people's eagerness to participate, but then again, this is ITP.

After my own recruiting, I receded into the shadows to watch the chaos unfold. It was hilarious to watch as people starting asking questions about who the higher-ups were.
"Who do I give this back to?"
"Me."
"Who do you give it back to?"
"The person who gave it to me."
"You mean that guy that was standing over here?"
It only had taken me five minutes to become an anonymous figure of lore, just like the criminals who I read about while researching the basis of this experiment. I'm sure these same questions were asked during the downfall of Bernie Madoff's investment scandal.

The game also evolved on the fly, which is not something I had anticipated. Due to the half-baked nature of the rules I explained, it wasn't clear to the participants what to do if they only had one sheet of paper. I heard at least one person suggest that they should make their own paper in order to keep it going, which was not my original intention, as I wanted to minimize the amount of effort required by each individual participant. However, I did not intervene, as the mark of a good pyramid manager is to stay laissez-faire all the way to the end.

Unfortunately, I did not get back any of the papers yet so I cannot say with any certainty what happened. It appears though that there was not enough of an incentive to encourage their timely return. I will update this when all of the papers are returned to me.

Foosball front-end

Link: Foosion

Partially for class, partially for fun, I created the front-end framework for some of my Cloudcommuting colleagues' foosball-centric RFID projects. The systems are not connected as of yet but by the end of the semester we should have a fully-functional identification system that updates the front-end in real-time.



There are several data points that we are recording:

  • Date of match
  • Winning player names
  • Winning team score
  • Losing player names
  • Losing team score

In future iterations we will be recording the goals scored by each player, as well as the time of the goals with respect to the start time of the game.

For this project I used AngularJS as the framework. Eventually it will be integrated with Node.js and MongoDB so that the front-end and the Yún(s) can communicate with the server and with each other. With this setup it will be feasible to display a foosball game live on the internet (similar to ESPN's Gamecast).

Since seeing the web site is helpful to understanding how the system works, please check it out at the link at the top of this post.

Midterm: Toward a Self-Sizing Mobility-on-Demand System Simulator

For our midterm project involving Citi Bike, my group (Aaron Arntz, T.K. Broderick) was interested in exploring how to simulate a self-sizing network. However, before we could do that, we needed to create a simulation that somewhat accurately depicted the behavior of the real system.

T.K. sculpted our overall message, tone and delivery – what was important about the system we were we aiming to simulate, and how would we connect our simulator to real world data to make it relevant? Aaron mined the Citi Bike System Data for clues about real-world behavior and refined them into data points describing stations and bikes. And I incorporated T.K.'s and Aaron's findings into a system simulator which I wrote from scratch in NetLogo.

In order to have as accurate a simulator as possible, we decided to populate NetLogo with the actual number of stations in their actual geography. The latitude and longitude of stations in the simulator are mapped to Cartesian coordinates so that the shapes of Manhattan and Brooklyn are easily distinguished.



To populate the stations' data, we used two types of information: (1) a snapshot of station capacities at a particular moment in time and (2) aggregate data from all trips in August 2014. Each station has the following fields:

  • Station ID (1)
  • # of available bikes (1)
  • # of available docks (1)
  • Master launch rate (2)
  • Launch table (2)

The last two fields are the most important for achieving realistic behavior. The master launch rate is the percentage of trips from a given station out of all trips. The launch table is a collection of destination station IDs whose frequencies match the percentage of trips from a given station to a given station. Note that the master launch rates and the launch table rates always add up to 1, respectively, as they account for all trips taken in August 2014.

Below is the launch table for station 339 (Avenue D & E 14 St), constructed from the percentage of trips from station 339 to any of the other station IDs in the list. Note that selecting a random item from the list will result in the selection of a given station ID with the same probability as actually occurred from this particular station in August 2014.

[339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 307 307 307 307 307 307 307 307 307 307 307 307 307 307 307 307 332 332 332 332 332 332 332 332 332 332 332 332 332 475 475 475 475 475 475 475 475 475 475 475 475 475 501 501 501 501 501 501 501 501 501 501 501 501 507 507 507 507 507 507 507 507 507 507 306 306 306 306 306 306 306 306 306 306 351 351 351 351 351 351 351 351 351 351 385 385 385 385 385 385 385 385 385 385 412 412 412 412 412 412 412 412 412 412 337 337 337 337 337 337 337 337 337 504 504 504 504 504 504 504 504 504 375 375 375 375 375 375 375 375 375 519 519 519 519 519 519 519 519 519 497 497 497 497 497 497 497 497 326 326 326 326 326 326 326 326 502 502 502 502 502 502 502 502 3002 3002 3002 3002 3002 3002 3002 3002 445 445 445 445 445 445 445 284 284 284 284 284 284 284 415 415 415 415 415 415 415 280 280 280 280 280 280 280 315 315 315 315 315 315 315 285 285 285 285 285 285 401 401 401 401 401 401 293 293 293 293 293 293 511 511 511 511 511 511 2009 2009 2009 2009 2009 455 455 455 455 455 518 518 518 518 518 393 393 393 393 393 341 341 341 341 341 350 350 350 350 350 263 263 263 263 454 454 454 454 428 428 428 428 335 335 335 335 312 312 312 312 363 363 363 363 296 296 296 296 264 264 264 264 347 347 347 347 224 224 224 224 297 297 297 297 433 433 433 161 161 161 266 266 266 250 250 250 342 342 342 2003 2003 2003 265 265 265 394 394 394 150 150 150 531 531 531 505 505 505 331 331 331 438 438 438 311 311 311 490 490 490 382 382 382 260 260 260 2012 2012 2012 410 410 410 317 317 376 376 379 379 302 302 380 380 168 168 528 528 127 127 316 316 2023 2023 304 304 540 540 236 236 174 174 400 400 486 486 404 404 360 360 473 473 432 432 305 305 496 496 2006 2006 237 237 532 532 512 512 153 153 301 301 483 435 2022 494 358 345 521 310 308 491 320 392 487 349 232 294 411 482 444 212 291 459 173 128 303 252 340 79 457 300 461 318 405 116 2017 229 427]

To better represent the stations' states, they are color-coded to match their current usage. Green stations are balanced (i.e. less than 95% full and greater than 95% empty), red stations are too full (i.e. greater than 95% full), and blue stations are too empty (i.e. less than 5% full). Here is the state of the system before any simulation has occurred:



Our focusing on stock rebalancing issues meant defining the concept of station balance, or the potential use of the station compared to its actual use. The goal of a self-sizing system would be the spread the usage evenly (or better yet, optimally) over all stations so as to minimize congestion due to either a shortage of bikes or a shortage of docks.

The final piece of the simulator was to model the basic behavior of a user (bike) arriving at a station that is completely full. We guessed that a realistic radius for seeking out an alternate station is 0.4 miles, or about 8 minutes walking. The bikes in the simulator wait a short amount of time, then proceed to another station within this radius if no docks are available.

After running the simulator many times it was clear that our model highlights one of the basic truths of the system: on average more bikes are launched from Manhattan stations than Brooklyn stations, and this causes an imbalance if no restocking is performed. This can be seen in the progression below (the first image is the same initial system state shown above).


We were pleased to identify some of the same stations that our previous visualization picked out. This gives further proof that their are certain stations that may be candidates for self-sizing and/or elimination.



Having this simulator as a base for our future exploration of the Citi Bike system is an important step, and we are pleased that we were able to make such progress for our midterm project.

Visualization of Citi Bike station node influence

My group's midterm is based on pruning "weak" stations and/or adding supplementary stations to the Citi Bike network in the hope of improving the system overall. The first step in this process is to identify weak stations that might be candidates for pruning, so I decided to make a visualization to get this information.

I used Gephi to create my visualization. Gephi worked best when I gave it separate data tables for nodes and edges. I loaded the Citi Bike station data (nodes) and trip data for February 2014 (edges) to form a graph.

One of the first things I realized was that the nodes could be easily divided into Manhattan stations and Brooklyn stations just by looking at the network's modularity (the strength of division of a network into modules). There are of course thousands of trips that start in Manhattan and end in Brooklyn, and vice versa, but the vast majority of trips start and end in the same borough. In the graphic below, Gephi grouped the nodes in this shape after I ran a modularity analysis (with a resolution of 2.0).


This means that pruning the weakest node overall might not affect the network as much as we had hoped it would. However, focusing on each module specifically is bound to have better results.

To determine the weakest nodes I looked at eigenvector centrality (Google's PageRank is a variant of this metric), which is "a measure of the influence a node." Connections to higher-scoring nodes are valued higher than those to lower-scoring nodes. The results (after 1,000 iterations) can be seen below. Gephi has several layout options to optimally display the network graph based on the chosen measurement (in this case eigenvector centrality). The Brooklyn visualization used a different layout for improved legibility.


Red nodes have higher scores and blue nodes have lower scores. The visualization makes it obvious which nodes are candidates for pruning; Railroad Ave & Kay Ave in Brooklyn and Leonard St & Church St in Manhattan are the lowest-scoring nodes in their respective boroughs.

This is accurate for trips made in February 2014. However to really get a sense of the all-time weakest nodes we would need to use all available data in these algorithms. There are likely seasonal changes in ridership that make certain stations less utilized in the winter.

Class 1 response (Mobility on Demand Systems)

Intelligent urban system


Smart trash receptacles

The BigBelly Solar trash compactor is a "smart" receptacle that makes garbage collection more efficient by 1) increasing the density of the garbage to be picked up and 2) providing the status of its current capacity electronically.


Basic feedback loop

  1. Receptacle accrues garbage
  2. Receptacle capacity monitored by city
  3. If receptacle near maximum capacity, city collects garbage


Form of governance

The receptacles are created by BigBelly Solar and controlled by the city government. The city government expects that the use of these receptacles will reduce inefficiencies and cost of garbage collection. Stakeholders include:
  • BigBelly Solar (desire publicity for its product)
  • City government (desire to recoup their investment and improve eco-friendly image)
  • Citizens (desire improved system of garbage collection)


In practice

These particular receptacles have drawn criticism for the fact that they require the user to touch a handle on the receptacle, as opposed to ordinary garbage receptacles with an open top. This has caused a backlash against the use of the receptacle, even though the handle issue seems at a glance to be extremely superficial. Citizens have voiced concerns that it improves the aggregate garbage collection at the expense of the citizens' health (i.e. touching the surface of the receptacle could lead to illness).

Driverless cars as a mobility on demand solution


While I think driverless cars are important in the development of autonomous/intelligent vehicles in general, I don't think they are a great solution for improving urban mobility. They may seem like a natural choice given the configuration of most cities, but I believe that there are even better options if we were to consider alternative urban architectures.

The fact that urban space is made of roads greatly limits the imagination when dealing with mobility, especially the last-mile problem; that is, how to travel the last mile of your journey to a destination. If we created more urban space in which roads didn't exist, we could develop new locomotive mobility systems (e.g. moving walkways) that allowed us to move our own bodies freely through urban space without needing an external vehicle.

If all taxis in NYC were replaced with driverless analogues, we would still have many of the same problems, like traffic, refueling, pollution, and safety. However, if the number of roads was reduced, and focus was instead turned toward creating space for humans instead of automobiles, we could reduce the need for the latter and provide a more fulfilling environment for the former.

Fall 2014 courses

Building for Learning (Aidan Feldman)

The web has already revolutionized the way that people consume information, but only recently has it been taken seriously as an avenue for teaching. MOOCs, online tutorials, and interactive applications all offer different means of learning, from the highly structured to the exploratory. They raise new questions around evaluation and assessment, while providing new avenues for collaboration and opportunities for students outside of traditional learning environments. In this class, we will examine various educational platforms and tools, and get the opportunity to speak with their creators. What can we offer to teachers to make their lives easier? What features increase and sustain student engagement? The course will be largely project-based, where students will learn frontend web development skills to build new web-based learning experiences and tools.


Cloudcommuting: Rethinking Point-to-point Urban Mobility Systems (Dimitris Papanikolaou)

This course introduces the theory, underlying technologies, and operational challenges of intelligent mobility on demand (MoD) systems, using NYC City Bike sharing program as a living laboratory.

MoD systems utilize networks of parking stations and shared fleets of vehicles (bikes, scooters, automobiles) allowing users to make point-to-point trips on demand. Today, more than 650 bike sharing systems around the world mobilize 3 million trips every day while at least 200 additional systems are planned. Despite their seeming convenience and advanced technology, asymmetric trip patterns cause many stations to temporarily deplete from bikes while others from parking spaces decreasing reliability and level of service in the system. Operators spend their entire usage revenues paying gas, trucks, and workers to manually move bikes from full to empty stations. Yet, level of service is often low. In Paris 48% of users find no bikes and 58% of users find no parking spaces available. In Barcelona, 50% of the stations are either empty or full during 30% of the time.

In this course we will 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 using price incentives. The course will combine lectures, readings, technical skill workshops, and a hands-on experimental project in a collaborative studio environment.


Frugal Innovation (Catherine Muther)

This course gives students conceptual and practical experience in developing ideas, tools, products and processes to augment and improve the lives of the global poor. We will use a variety of resources and methods to explore the emerging field of Frugal Innovation, beginning with an understanding of the context and constraints of living on less than $2.00 a day. Students will learn to identify key principles and challenges of designing for the Bottom of the Pyramid; for example, relentless pursuit of affordability. What are innovative models of using communications technologies to serve an illiterate market?

We will use Case Studies that address real life problems in emerging markets, particularly in healthcare and financial inclusion, where the use and potential of communications technologies is proliferating. Classes will feature cases of actual products or processes developed to solve a problem or meet a perceived need– some successful and others not. Why? How do we know what success looks like? We will look at metrics, methods and markets to explore the question of measuring impact. Entrepreneurs and field leaders will come to ITP as guests to share their knowledge and experience, and engage with students. Student teams will work on a project to create a frugal innovation for a critical challenge in the lives of the global poor.


Maps, Lies and Storytelling (Andrew Hill)

Maps have an incredible potential to do good and evil. Throughout history access to a map has been synonymous with power. In this course we will look at why that has been true, how it has changed through the digital revolution, and how we can harness mapping to gain power. The course will take a critical approach to maps and mapmaking, trying to pick apart all the ways they can be evil and be used to do evil. Through that critical approach, we will learn how to use maps effectively to communicate data, create knowledge, and tell stories. Students will also learn how maps are changing. We will try to find innovative new maps to create, both unassuming and controversial, and share those with a broader mapping community to create a public dialog. Students will learn the fundamentals of mapmaking, using tools from a pencil to Javascript, to create original maps from original data. We will create interactive maps with tools such as Leaflet and CartoDB to make maps from our imagination. We will also look at collecting or creating new geospatial data to make original maps never seen before.


Project Development Studio (Despina Papadopoulos)

This is an environment for students to work on their existing project ideas that may fall outside the topic areas of existing classes. It is basically like an independent study with more structure and the opportunity for peer learning. This particular studio is appropriate for projects in the area of interactive art, programing, physical computing and digital fabrication. There are required weekly meetings to share project development and obtain critique. Students must devise and then complete their own weekly assignments updating the class wiki regularly. They also must present to the class every few weeks. When topics of general interest emerge, a member of the class or the instructor takes class time to cover them in depth. The rest of the meeting time is spent in breakout sessions with students working individually or in groups of students working on related projects.