The biggest difficulties we faced as a team were twofold: (1) our goal of implementing all functionalities suggested in the design phase was too ambitious given the limited time we had, and (2) even though three of us collaborated leveraging our interdisciplinary expertises, the project was more code-intensive and time-consuming than we had imagined.
However, as our project was time-consuming and code-intensive, we needed more time to work.
Thus, we would have been much better off had we had another member with a strong JAVA background or software engineering knowledge.
Nonetheless, I believe that we did a very good job at developing and integrating some of the key initial ideas in terms of building user-friendly tangible user interface and creating a dynamic, robust system. However, we could not implement some of the key concepts of the system(i.e. velocity and interaction between cars). Thus, we needed to eliminate some key features such as traffic jam and speed change to dispense with complex algorithm involving velocity and car interaction.
Saturday, May 3, 2008
(Video) Working Demo
This video demonstrates how the traffic simulator works in real time.
The two Traffic Starter feed one car at a time into the system. A red rectangle representing a car on a track keeps moving, following the track of each block. Once a car encounters a tri-split or di-split track, it will make a choice (i.e. go straight, turn right, or turn left).
Unfortunately, this system is missing some of the key features suggested in the initial design such as constant feeding of multiple cars or speed change of cars depending on traffic condition. Nonetheless, this demonstration shows a potential to which extent this project can be further improved to simulate a complete, real-time traffic condition which can be studied and manipulated in an attempt to minimize the traffic jam.
(Photo) Final Design and Implementation
The implementation of 2D JAVA graphics was especially difficult and time-consuming because we had to hard-code 20 to 90 different coordinates for each track token depending on the type of track. In addition, the integration of three main modules(i.e. webcam, 2D graphics, and topcodes) were also problematic and difficult due to problems such as the glare from projector and light bulbs as well as the low resolution of 1.3M pixel camera. Aside from the software integration, the hardware(system) configuration involving the projector, board, and webcam was a challenge as well.
Monday, March 24, 2008
Design Process Documentation
Traffic System(temp.) Design Process
The key word for our project was "flow." That is, the ultimate goal that users are expected to achieve from this interface is to make a traffic system flow smoothly. The traffic system is composed of tracks of multiple shapes, two types of intersections, and traffic starters.
So far, we have come up with five different shapes of track: (1) Straight, (2) Curve, (3) Hill, (4) Fork, and (5) Exit. These tracks can be physically connected to either Stop Intersection, Traffic Light Intersection, Traffic Starter, or other tracks to build a traffic system.
The rational behind the control of the whole traffic system is to keep track of "speed." The Straight track increases the speed in both directions whereas the Curve track decreases the speed in both directions. In addition, the Traffic Light Intersection and Stop Intersection decrease the speed in all four directions. Although the real-life stop sign and traffic light work in a much more complicated fashion, we tried to simply the algorithm for the scope of our project.
To create a flow into the traffic system, the Traffic Starter can be connected to the end of a certain track. Depending on the level of traffic set forth by each Traffic Starter - little, usual, huge - each track will be accounted for increasing or decreasing the speed of the flow.
To put simply, the more the Straight Track is connected to the traffic system, the faster the cars can be driven, which therefore reduces traffic and eventually induces a smooth flow of the traffic system.
Although our project has a potential to be further developed to be utilized at the industry level, it would be somewhat difficult to incorporate some ideas and technologies due to limited time and technical difficulties. Therefore, we decided to focus more on the "speed," which is our core measure to determine the flow of the traffic system.
Thanks to Brio blocks and Mike's prior experience with the computer vision, we haven't had many conceptual problems; however, I believe the challenges we have faced so far are minimal compared to what will be faced at the implementation level. The two biggest challenges would be implementing I/O and devising a traffic algorithm. The traffic algorithm will be simple enough to imitate and simulate a real traffic environment. For example, each type of track will be assigned a unique speed parameter; i.e. -20 for decrease in speed and +20 for increase in speed. Then, these tracks will be connected and the speed parameters will be summed up to calculate the total "speed" of the whole traffic system. As Mike suggested, we will use Java 2D and computer vision for the I/O process.
Finally, we realized during the presentation in class that it would be much easier to set up a camera below the board to read in the track information such as direction and connection instead of set up above the board. This made sense because parts of human body such as hands may block the computer vision and confuse the system to realize that what's hidden by hands is missing from the board. In addition, from today's class(Mar. 24), I thought about the difficulty to show the flow of the traffic on the surface of the tracks. We're now considering the idea of projecting beams onto the surface to represent traffic. However, I pondered upon the idea of using three colors(green, yellow, and red) to project directly onto the entire surface of each track to show the level of "congestion" at that specific road. Further discussion will be made at the next class meeting.
Sunday, February 24, 2008
PhidgetRFID and PhidgetLED Demo
The goal of my project was twofold: (1) to become familiarized with Phidgets technology, and (2) to
I made a separate
The basic function of the RFID Phidget is to detect and read the value of a RFID tag to which a unique value is assigned. A tag can be detected within about 5 inch of distance.
If the RFID Phidget plays a role of input reader, the LED Phidget is in charge of displaying the output by means of LEDs. The LED Phidget contains 64 LED slots to which LEDs can be attached by double-sided cable. Even though the LED Phidget has a capability to vary the brightness level of LEDs, I did not incorporate that functionality due to the small quantity of RFIDs.
My program demonstrates a simple check-in and out program where a tag works as a key and the LED board works as a monitor.
If a certain tag is detected by the RFID reader for the first time, then the LED light that matches the value of the tag gets turned on. However, if the same key is detected for the second time, the LED light that has been previously on gets turned off. Even though this simple program does not fully demonstrate an effective hotel check-in and out system, one can easily and quickly check the current occupancy rate of a hotel in real time.
What went well:
Two Phidget devices' functions were incorporated to create a simple system.
What went wrong:
This project was challenging in two ways. First of all, from a software perspective, it was difficult to learn Java from scratch. Secondly, debugging without much knowledge in Java was challenging. As shown in the following snapshot, I am still struggling with a minor error even though it is not directly affecting the outcome of my program.
Sunday, January 27, 2008
What is a Tangible User Interface?
Although the concrete definition of Tangible User Interface(TUI) has not yet been formalized, it is safe to conclude that TUI is a physical tool that plays the role of a tangible medium to interact with digital information. The utmost important characteristic that is expected of any TUI is that it should be 'intuitive.' People in nature do not like to be forced into learning something new, especially involuntarily. Therefore, TUI must be designed to be intuitive and easy-to-use so that no user, in ideal, will not feel the necessity of reading a manual before starting the experience.
In that sense, I like the idea behind the Designers' Outpost. The Designers' Outpost is an extremely intuitive tool which can provide a fun brainstorming experience as well as create an efficient and effective output of the digital format. Like the Designers' Outpost, when designing a new TUI, I think that the balance between creativity and user-friendliness should be carefully made. In other words, a certain TUI must be creative enough to make users appreciate its unique and useful functionality. However, at the same time, TUI must be intuitive and user-friendly enough to ensure that the general users with no background knowledge will be able to feel comfortable using it and not suffer from learning how to use it.
In that sense, I like the idea behind the Designers' Outpost. The Designers' Outpost is an extremely intuitive tool which can provide a fun brainstorming experience as well as create an efficient and effective output of the digital format. Like the Designers' Outpost, when designing a new TUI, I think that the balance between creativity and user-friendliness should be carefully made. In other words, a certain TUI must be creative enough to make users appreciate its unique and useful functionality. However, at the same time, TUI must be intuitive and user-friendly enough to ensure that the general users with no background knowledge will be able to feel comfortable using it and not suffer from learning how to use it.
Subscribe to:
Posts (Atom)





