Networked Objects

Make a simple activity that involves a back-and-forth volley, like tennis or ping pong. In this case, however, the "object" being volleyed is a packet of information over the net. Your job is to design and implement a physical interface such that two people can participate in your activity over the net, using two Lantronix devices and whatever microcontrollers and hardware you need.

Physical input/output elements you need to include:

• input for a player to start and return the volley
• output to let a player know when the volley's coming to her, going away from her
• output to let a player know when she's successfully returned the volley, or "missed"
• output to let the player know the score, or overall state of the game

Note: your activity does not have to be a game, as long as it involves clear two-way extended communication between two (or more) people over the net, using a physical interface.

Keep this as simple as possible. The goal is to understand the relationship between basic network communication and simple physical interaction.

Midterm Assignment

Make a piece of furniture that can converse in a text chat (for example, AOL IM chats, iChat, etc.). Your furniture should sense physical activity in the space surrounding it, and send messages to a chatroom based on what it senses.

Ideally, the messages and the sensing will be related to the piece of furniture's prime function. For example, a chair might send messages on whether it's occupied, its occupant's shifting, etc. A door might send information on when it's opened or closed, whether someone entered or left, who that person is, a window might say whether the blinds are being opened or closed, and so forth.

Your furniture should be polite in conversation. It shouldn't hog the chat space by sending constant messages. It should only send when there is a significant enough event to comment on. Ideally, it should listen too, and take commands if necessary.

Your furniture may be a remotely controlled device that responds to certain chat commands. For example, you might give it a "silent mode" in which the device stops sending messages if someone sends it a message to "be silent." Another example: might make a window that only tells you the outside temperature if you ask it.

For the midterm, we will use a simple chat server and protocol, detailed below. If you're interested in other protocols for future projects, here's a simple AIM client in java.

The server will be a TCP-based server running on stage.itp.nyu.edu, or another local server which I'll give you.

Your furniture should implement responses to the following commands:

• login username
  When the device connects to a server, it sends its name.
• send username message
  when the device wants to talk to one user, it sends the user's name, followed by the message, separated by spaces.
• send all message
  this message would go to all people in the chat.
• exit or logout
  this message loge out out of the chat.
• get_users
  if your device sends this, the server sends a string of currently logged in user names, separated by spaces (ASCII 32).
• get_info
  if your device is sent this message, it sends a brief (one-sentence) description of itself.
• set_info text string
  when your device sends this, it sets its info on the server.
• get_time
  when your device sends this, the server returns the time, using the Network Time Protocol.
• all client messages should end with linefeed (ASCII 10)
• all server messages, including error messages, are terminated by > and linefeed (ASCII 62, ASCII 10)

The server code is online here. If it's not running on a server I've set up, feel free to download and compile it on a server yourself.

You won't need to write your own server, you'll just need to write your client. You can work alone, in your current pairs, or in groups. You can use the Lantronix devices or another device to connect to the net, but I don't want to see the computer or screen. All I want to see is the furniture.

In week 7, we'll log in and chat with our furniture. All around the floor.

Final Assignment

Design and build a networked system that facilitates communication between humans (or other animals) over a network through means other than the standard keyboard-mouse-screen interaction model. Design and build both the physical input and output devices. What happens across the network should be clear to all parties using the system, so that the whole experience serves their needs or interests.

Your system should involve two-way communication between at least three physical devices over one or more networks. There may be one or multiple servers involved as well, as you need.

You may expand on either of the earlier projects for your final, or you may begin a new project. You can work alone or in groups.

You should start by asking what the intended participant is to do, and how and where she is to do it. Consider all the factors affecting her participation: physical, social, economic, environmental, and other constraints. Think about the actions she'll take and the objects and surfaces that she manipulates. Consider also the connectivity between the elements of your system, and plan the network transactions thoroughly.

There are a number of milestones in your final project which you'll be expected to document and present in class. They are as follows:

System Diagram and interaction scheme - this is a general layout of the components of your system, including the devices and protocols involved. In the early stages it will be fairly general, but at the end, it should specify every major component and the protocols linking the components. The interaction scheme should be either a state diagram describing what happens, or a narrative description of the interaction, or both.

Interface Mock-up - this is a physical mockup of what the devices will look and feel like. You can use fome-core, cardboard, or other simple materials, and the mockups don't have to be functional, but they should give us a clear idea of the physical relationship between our bodies and the system. For large-scale systems, use scale models.

Technical Research report - This is a "how-to" report, particularly on those components of your system that have not been covered in class, or in other classes. For example if you use a sensor or actuator that no one in class has used, or develop a technique that is new ot ITP but beneficial to others, document it and be prepared to explain it to the class.

Final Summary - what worked, what didn't, what surprised you, what you'd do differently in the next iteration.

Note: depending on how many final project groups there are, it's possible that every group may not present every milestone. You are expected to reach and document the milestones, regardless.