The Jetson Kitchen Project is associated with the Domisilica Project. It's primary purpose was to serve as the first real world interface into the virutal world of Domisilica. Our idea was to provide a number of physical devicces that would facilitate kitchen inventory management. Our goal was to create a tool to evaluate future possibilities, and to begin evaluating methods of communication between components.
Our prototype consisted of 4 primary pieces. The central driving module was a server. The server was located on a public machine with a well known port. It accepted connections from the various devices and was responsible for opening and maintaining a connection with Domisilica. The server was capable of parsing incoming data streams from the device modules and communicating information to and from Domisilica. There are two device modules, a bar code scanner and a simple vision recognition package. The bar code scanner was picked because of its ease of use for recognizing general food items. As the device of choice for supermarkets, we felt that it would be appropriate for the kitchen also. To be able to recognize those objects which would not have barcodes, such as fruit and vegetables, the vision system would be used. As a final method of input, and to provide additional information from the user, we developed an interface that can be used to add or remove items, update information on items, or query for information regarding the contents of the system.
Communication between various devices and a text based MUD posed an interesting problem with several possibilities for implementation. For our project we decided to use a TCP based connection with tag delimited text streams. Using TCP sockets was chosen because of the diverse collection of sytems that our modules ran on. We were looking at running the devices on Win95 or WinNT PC's, a user interface written in Java, and a mud that was most easily accessed through a socket connection. The one common denominator was sockets. A text stream seemed the most uniform choice for the different architectures that we would be running on, and would also facilitate debugging. With a text stream it was possible for one of our developers to telnet into an appropriate port and act as any of the various components. Since each component was being developed independently, this also allowed us to setup "black box" prototypes that would later be replace by working components. The method we chose to implement transfer of information was using tag delimited bits of data. By using tags we would be able to extend the communication as needed without having to completely change the data format.
The two devices used for the project were a bar code reader and a vision recognition system. The bar code scanner is accessed through the serial port of the PC and will recognize most standard codes. The module driving this component exists in a certain state at any time, ad will transmit pakcets that have information regarding the item scanned and the state. The state is used to indicate the destination or origin of an item, and whether it is being added or removed from the system. We set aside several bar code cards that toggle this information. Our long term plan would be to have a scanner fulfilling each possible function, but for now having one scanner that can represent each one of them seemed best. The vision system uses a color QuickCam to recognize fruits and vegetables. The algorithm used takes the long diagonal and RGB intensities to discriminate between objects. We restricted ourselves to approximately 8 different fruit or vegetables at any given time. The system would be trained on these objects, and had a resonable success rate given the crudity of the image supplied by the QuickCam. To indicate whether an item was being removed or added, we designated two areas in the scanning region that would be for either entry or removal. At this time we have not established a method for indicating location using the vision component. The information from the vision system would indicate a food item and action, which would then be transmitted on to the central server.
The server in this sytem was primarily a data redistributor. When the server is first started, it opens a connection to the MUD, andd then sits and waits for devices. When a device or component signs on, the connection is logged and the server then listens for data. When data is received, it would be parsed and then sent out to the proper recipient. Communication intended for the MUD would be parsed and changed into the proper command format, which would generate a response. Responses of the appropriate type are filtered out and sent on to listening devices. At this point, the only device paying attention to information sent out by the MUD is the user interface.
The user interface was created to serve as a method of input and inquiry. It is event driven and will react to any information that comes in. In its basic mode, it listens for information coming in as well as presenting a menu to the user. On action by the user, the interface will query the MUD for information regarding its contents and present that information to the user. In reaction to removal or addition of food items, the interface will provide a form to the user, allowing him or her to update the default properties associated with food items.