Student Projects
Contact Information
University and Department
University of California, Berkeley
Team Members | Faculty Advisor(s) |
Tyler Adams | George Anwar |
Allard Chu |
|
Ross Millenacker |
|
Jared Farr |
|
Primary Email Address: Tylerbadams@gmail.com
Primary Telephone Number (include area and country code): 619.249.2617
Project Information
List all parts (hardware, software, etc.) you used to design and complete your project:
· Eee PC
· Spam mail server
· Wrt54gs router
· 10 valve solenoid array
· Custom PVC bottle fittings
· Luminary micro
· Custom MOSFET gate array
· Labview 8.6
· WAMP server
Describe the challenge your project is trying to solve.
· The goal of our project is to relieve congestion at bars on busy nights.
Describe how you addressed the challenge through your project.
The challenge was addressed by creating an embedded bartending system that uses pneumatics to deliver drinks in a timely and reliable fashion. To make the system more efficient, a wireless access point was created in the bartender allowing computers and mobile phones to connect to the bartender to order drinks. A queuing system is in place to guarantee drink priority and reliability. There is also an optional service that will send you a text message notification when you drink is ready to be built.
S.A.R.A |
Social Alcohol Robotic Attendant |
|
SARA is a networked bartender that is completely enclosed aside from ethernet and power cables. It works by using a simple Client-Server system that sends drink orders from the server to the microcontroller to make the drink for the user. The various liquids are driven with constant pressure provided by a scuba tank and an attached regulator. The actuation of these liquids is accomplished by triggering an array of solenoid valves interfaced with a Luminary microcontroller. The following report outlines the production of SARA from our original conceptual ideas to the final product. It includes how our ideas changed as well as some of the challenges that came along the way. |
|
The Vision
From the beginning, Social Alcoholic Robotic Attendant (SARA) was designed to be marketed to clubs as a means of alleviating swamped bartenders as well as acting as a conversation piece for patrons. At its core, SARA was designed to quickly deliver drinks of consistent quality. The exact design criterion that was put forth is as follows:
· Identify the size of a variety of drink glasses through color recognition
· Deliver an exact volume of liquid based on light sensors
· Mechanically grab and move bottles from a specific location
· Create drinks from a preprogrammed drink library
The original plan (figure 1) was to implement a mechanical arm that will pivot around its base. Various standardized drink containers would then be positioned radially around the arm. Once a drink type is selected from the library using the graphical user interface, an optical sensor at the cup filling station would deduce the serving size. This information would then be used to calculate pour time. When an order was received, the arm will pick up each of the required bottles one at a time from a preprogrammed position. Each bottle would be poured into the cup for a time determined by the cup size and drink type. This would continue until the order is complete.
After much debate, SARA took on a different mechanical approach to bartending. Rather than using a robotic arm, a system that would be costly and slow, a pressurized solenoid valve system (figure 2) was found be more desirable. Other than the robotic arm, all of the other design criteria remained the same.
Vision Realized
The initial scope of the project was limited to the successful mixing of a drink that would be comparable to one ordered from a bar or club. We were confident that this project difficulty level would be enough to fulfill the requirements of the class. As time went on, we found that our scope was too narrow for the amount of time that we were willing to supply to the project. We began talking about the addition of a mobile application that would control the system. Once this was completed, we began to discuss the use of text messaging as a notification system because standing around the machine for 45 minutes waiting for your queue to arrive was considered to be worse than standing at a bar to get the bartender’s attention. Once this system was integrated, the group focused on streamlining everything. Through this process, we found that our initial scope was too narrow to merit an entire semester worth of work.
The only portion of our planning that was not completed in full was the use of a photo resistor array to determine the cup size. There was a significant issue with signal noise. The code is completed and running on the system sans-noise filtering.
After the project’s completion, we were left with a completely embedded system. Any device with network connectivity could order a drink from the bartender. The order would be added to the queue and send a text notification to the next person in line. When the person arrives to retrieve their drink, they are prompted to enter a code that is specific to their order. Once this has been completed, the drink is served.
Technical Challenges
Hardware
Hardware posed intriguing questions about the direction of design. While a pressurized system was decided upon initially, the housing design itself underwent much discussion. Initially, thoughts of an aluminum base, acrylic paneled structure was envisioned for clarity and simplicity. However, after much consideration for environmental sustainability, cost, and appearance, a chassis design based upon full construction from plywood was chosen.
Originally, the primary concerns were proper dispensing of liquids and preventing mixing from different drink orders. Requirement for removing air from the system tubing raised initial concerns with fluid waste and testing for timings to prime the system. Additionally, with only one exit tube for all bottles, focus was placed on ensuring clearing of fluids between each drink made. The issue with this was that the flavor of drinks may be negatively affected if the system did not purge excess fluids from previous orders.
Testing showed that the largest issue was sealing the pressurized containers from leakage. In minimizing costs, thinner walled polymer bottles were purchased for usage. When used in conjunction with thermoset bottle caps, there was noticeable air leakage in the system due to manufacturing tolerances and bottle deformation under pressure. Several methods were attempted to remedy the problem with leakage through epoxies, silicone, and thermoplastic adhesives but proved unsuccessful. Ultimately, custom caps were machined from PVC to ensure a proper seal through o-ring sealed slip fits instead of threading as with the thermoset caps.
Initial concerns of possible issues of timing and drink mixing were ultimately proven to be unfounded. In prototype testing, the amount of liquid wasted in priming the system was minimal and all liquids dispensed at approximately equivalent rates. Additionally, adoption of a blast of pressurized air to clear the exit tubing proved capable of purging the system completely.
Software
Software presented a few difficult obstacles on the way to the finished product. Some of these issues were met while others were considered acceptable. The largest technical challenge to overcome was to find an efficient way for the Luminary Board and the Server to communicate. Several systems were designed on the PC that worked well but when implemented on the Luminary board could not run at all. Understanding the limitations of the Luminary board's network compatibility was the first step to being able to implement embedded actuation of the solenoids.
A simple state machine template was used to implement initialization, standby, and drink making modes. This was found to be the simplest and most bug free way of running the software.
The one obstacle we could not overcome was the lag time between establishing a TCP connection between the server and the board and sending data. Although several techniques to minimize this were tested, we could not find a suitable method that would dramatically change the delay time while maintaining stability in the software.
Future Considerations
If the project were to be redone, further sustainability considerations would be made in terms of hardware selection. The amount of finishing work and products used for the chassis construction would be reevaluated as a large amount of paint, time, and funding was spent on a non-essential components.
For more involved design work, new off-on solenoids could be selected to better fit our purpose. By utilizing solenoids with larger port size, performance rates could be improved without modification to the system. The selection of a new solenoid would also necessitate new manifolds for combination of solenoid outputs. In redesigning the manifolds, sealing could be improved through specific design for higher pressure applications. Though minimal, there were droplets of leaking liquid from the manifolds as they were not designed for prolonged usage under the set pressures.
Appendices
Our journal and code can be found @ http://groups.google.com/group/me135-s09. Access will be granted to this group if requested.
