— ITPG-GT 2621 001 CLOUDCOMMUTING

Archive
Author Archive

Aaron, T.K., and I are interested in behavior associated with reward – that is, the reasons why a person does certain things in light of a future payoff. To this end we have devised a game wherein the players compete for a future reward. The playing of the game, however, significantly interferes with their normal behavior, and it is our goal to investigate what makes such a game “worth it” to the dedicated player by implementing Time Wars, a winner-takes-all game to be played on the ITP floor.

In Time Wars, linear time is broken down into units of 10 minutes called intervals. Players can check in during each interval to receive a point for that interval (e.g. a check-in between 9:00am and 9:10am counts as one point). They do so by tapping their NYU student ID card to an RFID reader connected to an Arduino Yún which logs the check-in for that player. Players can only receive one point per interval (players cannot check in multiple times per interval to earn more points). Note that once an interval has passed, the point for that interval can never again be scored by any player, so there is no way to score points faster than the progression of time itself. This is why it is important to check in during as many intervals as possible.

One purposeful game design mechanic is that the gameplay is extremely disruptive, especially at ITP, where the state of being “in the zone” is often an albatross. This means that a dedicated player has to give up certain responsibilities in order to participate. Furthermore, the game cannot be played outside of ITP; its inherent physicality tethers it to the floor. We proved this concept two weeks ago when we created an online-only version of the game and tested it ourselves. T.K. checked in as late as 4:00am, which would near impossible to do in the physical game (not totally impossible, though).

Currently our system consists of a database (MongoDB), front-end (Node.js + Handlebars.js), microcontroller (Arduino Yún), and physical sensor (RFID reader). The database is ready, the front-end is nearly there, the microcontroller is reading and writing the database, and the RFID reader is nearly hooked up. We anticipate Friday we should have the components fully worked out, and will be able to officially launch the game at ITP, using the following days to analyze and fine-tune.

Screen Shot 2014-11-16 at 9.55.02 PM Screen Shot 2014-11-16 at 9.55.25 PM image

Read More

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.

Read More

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. All of the data will come from the RFID system that David Tracy is working on.

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.

Read More

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.

Read More

(Link to original blog post)

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.

Read More

Re: Marketing & Advertising Industrial Complex

I think it’s hard to argue that this Complex does not greatly affect human agency. A predictable consumer is an easy target, and the very nature of seasonal shopping cycles proves that we have become bound to a commerce schedule that really only exists because the Complex defined it in the first place. People would likely still give gifts on Christmas but the mega-sales that now accompany most major holidays have conditioned us to expect such “value” and wait for it. The Complex can bet on it.

Read More

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.

Read More