— ITPG-GT 2621 001 CLOUDCOMMUTING

Archive
Author Archive

David Tracy, Dan Melancon, Saki Hayashi

For this week’s assignment, our team built a realtime online reporting tool as a proof of concept. This is important for our final game because it provides the framework to keep all players updated on the state of the system.

In abstract, here’s how it works:

LocationDiagram-03

In practice, here’s how it works:

1. Users connect to server via phone browser.
2. A websocket connection (via socket.io) is established between the client (phone) and the server
3. The client broadcasts their geolocation, lat/long to the server. NOTE: In our final game, this will be a running point total instead of location, this is simply for Proof of Concept.
4. The server receives the coordinates and broadcasts them to any other connected clients.
5. When the client receives the location of a player it hasn’t seen before, it creates a new player entry and adds its coordinates to the DOM.
6. When the client receives updated coordinates from a player it has seen, it updates that player’s coordinates in the DOM.

The code respository can be found here:

https://github.com/davidptracy/locationGame

Read More

Final Project Proposal > David Tracy, Dan Melancon, Saki Hayashi

We propose a game that will deal with the balance of personal goals, stock, incentives, and penalties to stabilize a dynamic system. See image below for a description of game modes.

The game will utilize RFID card readers, and wireless networking to create the game environment. As users check resources in and out of stations, they either gain survival time or points based on station stock. DT_DM_SH_ccFinalProposal-01

Read More

 Screen Shot 2014-09-16 at 9.50.19 PM Screen Shot 2014-09-16 at 9.51.25 PMComposite

The above images show a snap shots of dock availability and bike availability throughout the CitiBike system. The image in magenta shows bike availability at 9:30pm on Tuesday. The image below it, in cyan, shows Dock Availability at 9:30pm on Tuesday. Finally, I composited the two images to show their relationship.

The image was generated with Processing, this is how it works:

I based my code on Dimitris Papanikolaou’s example sketch [insert gitHub link]. The Processing sketch took in JSON (from CitiBike’s website) and then parsed each JSON field into variables that Processing could work with. The variables (such as latitude, longitude and dock availability)  were then passed to a Voronoi class (from Toxiclibs) to generate the cells. In the end, I overlaid an SVG that I made in Illustrator to give the data a little context. Below is the image without the SVG overlay.

Original Post:

http://www.blog.davidptracy.com/?p=448

Read More

In ME++ Mitchell talks about “electronic nervous systems” of intelligent urban environments. Discuss an example of an intelligent urban system you are familiar with and discuss the elements of the feedback loop, how its form of governance works, and who are its stakeholders (goals, decision makers, evaluators, etc.).

The concept of an intelligent urban system is quite broad, varied, and encompasses many types of systems; cctv, mass transit, emergency response, private security systems, community websites, delivery and couriers, government, infrastructure, waste, roadways, etc. With such a variety of typologies intelligence quickly becomes a highly relative term. Of these systems, one in which I’m fairly familiar with is a private vehicle sharing program called ZipCar.

I have been using ZipCar for about six years now. It’s a relatively intelligent urban transportation system that provides a variety of vehicles for on-demand use. As a user, I reserve a car via a web or mobile interface. My account is linked to a credit card, and I am charged an annual membership fee as well as a per-hour usage fee for my time in the car. I do not pay for gas or insurance. I retrieve the car from one of many set locations, drive it, and return it to the same location within my allotted reservation window. The system is governed electronically through a combination of human-computer interfaces (me and my phone or web browser) and an RFID card reader that is mounted to the windshield of the car that will either grant or deny access to the vehicle. The intelligence largely lives in a database of users, reservations, vehicles, and locations. Gas is paid for by credit card that lives in the vehicle. When there are issues, a human is available via telephone to resolve the issues. I list these systems to highlight the conglomerate of systems that are tied into ZipCar’s operation; web enabled databases, radio frequencies, humans, global financial institutions providing credit, roadways, and architecture (in some cases).

The stakeholders in the systems are both private and public, but mostly private. Its primary goal, as a company is to make tons of money, and it has continually been heading in that direction as it aggressively expands to new markets. The public can be seen as a stakeholder in ZipCar’s system as well, if only in a minor way; there is an incentive to reducing the amount of cars in urban environments. A reduction means less space dedicated to idle vehicles and more room for public space.

Compare different models of sharing that exist (or you can think of) in MoD systems (e.g. vehicle sharing, parking sharing, ride sharing, etc.) What operation/control problems do they have? What would the ideal form of sharing be for you and how would its resources be controlled?

The single largest operation and control problem that MoD systems have is resource management and system balancing. I believe that in a large part this is due to the fact that their systems exists in much larger ecosystem of systems as well as human demands influenced by environmental constraints.

For instance, with a car sharing system like ZipCar, the reliability of the system is variable and based on factors such as traffic, human error, mechanical failure, and maintenance. One advantage that a system like ZipCar has over other systems is that the resource (the car) is always returned to it’s origin which means relatively little rebalancing of the system. The system also has variable rates; weekends are more expensive to drive due to high demand, and more spacious or luxurious vehicles carry a higher hourly rate.

Bike share systems are faced with much larger problems due the way the resources are used. Bikes are generally used asymmetrically, meaning they aren’t always returned to their point of origin. There is also a flat fee for use (with the exception of overtime penalties) which means that incentivizing the system for self-balancing becomes a difficult feat. There have been countless times when I’ve used a bike off-peak and spent up to a half hour trying to find an available (or functional) bike or an empty dock, which dissuades me from using the system all together.

The ideal system for me is a bike share that takes a few lessons from ZipCar. ZipCar doesn’t share quite the same system stress as a bike share, but it’s still there; there are peak usage times when it is maddeningly difficult to find a vehicle within a reasonable distance. However, I believe having a variable pricing structure opens up zipcar to incentivizing itself to regulate its system. If a bike share like CitiBike could adjust itself and its pricing structure or form an alliance with local businesses to incentivize use, I think some of its operational stress would be reduced. For instance, if riders are prompted with a discount at a coffee shop or grocery store that is closer to a more balanced station, perhaps they will help regulate the system.

Read More