final project proposal(s)

Data mining hinges upon a programmer's ability to interact with databases. Writing SQL queries can be tedious and syntax-focused. Say you have a database that stores restaurant check-ins for lots of users and restaurants. You might end up with a couple of tables:

I might want to ask where has Jeremy eaten lately? In order to do this, I would have to write an overly complicated SQL query shown below.

            SELECT restaurant, location FROM checkins, restaurants
            WHERE person='Jeremy'
            AND time<='2 WEEKS'
            AND checkins.restaurant = restaurants.restaurant;
          

First, the syntax has to be correct - quotation marks need to match, the user has to type in field names exactly right. Also, in order to get restaurant locations, the two tables have to merged by matching the restaurant field. Finally, even once I get all the restaurant locations, I would rather visualize my query on a map than read a list of latitude-longitude coordinates.

Enter tangible programming. I want to make a kit of interactive blocks that allows users to literally build a query, without having to worry about syntax or missing steps (e.g. merging tables).

There will be four types of blocks: data, merge, filter and viz. Data blocks represent a table in an SQL database, or any similar dataset with fields and items. Merge blocks take two data blocks and join them based on a common field. Filter blocks allow the user to narrow down the query based on a field's values. Lastly, viz blocks translate the query results into an appropriate visualization: lists, tables, maps, charts, graphs, etc. In the end, a laptop is used to process the query and produce the visualization.

Each of the blocks will have a small display and an input device (keyboard, knobs, buttons), which can be used to configure the block - for example, which field should be filtered and with what values. While I initially imagined that the blocks should be shaped to fit together like a puzzle only when queries are correctly-formed, I realized this would limit the flexibility of the query builder. For example, if data blocks only fit into merge blocks, then the user could not merge data after it had been filtered. Similarly, only allowing filter blocks to fit into viz blocks would mean that unfiltered queries could not be visualized.

Instead, I will use the UNIX metaphor of "piping" information from one block to another. All blocks will have one input port, except for data blocks (no inputs) and merge blocks (two inputs). All blocks will have multiple output ports, except for the viz block (no outputs), so that queries can be built in parallel. Using wires, the output of any block can be piped to the input of another.

Another potential project is building a small, low-cost telepresence robot that uses a smartphone for video calling and remote driving. Above are three examples of existing telepresence robots. They vary in price, robustness, and the method used to send control commands from the smartphone to the robot.

Robot	Price	Communication
Xybot 1 (left)	$111	Made for Apple
Romo (middle)	$150	Audio jack
Helios (right)	$120	Video overlay

I'd like to build a telepresence robot that (1) costs less than $100, (2) is cute and (3) is fairly robust to crashing (both physical and network). In terms of being cute, I want the robot to have more personality than a Roomba, while letting the remote user's face dominate the experience when on-camera. The crashing consideration means you don't have to worry about breaking an iPhone in reasonably benign situations (e.g. driving off a desk onto a carpeted floor). How to do all of this? I'm not sure...