Coffee Baron 0
Coffee Baron
Innovative Coffee Dispensing and Data Acquisition System
By: The Coffee Posse
Anthony Agresta
Corey Bloodstein
Osman Celimli
Date
May 9, 2012
[pic]Table of Contents
Overview 2
Requirements Specification 3
Concept Selection 4
Design 5
The Baron 6
PotSticker 8
TankMan 10
LuMos 12
TeaBag 12
Interface 13
Considerations 15
Bill of Materials 16
Coffee User Experience 16
PotSticker Coprocessor Board 16
PotSticker Coffee Data Acquisition Arm 17
TankMan Coprocessor Board 17
TankMan Water Flow Control 17
LuMos Coprocessor Board 18
TeaBag Coprocessor Board 18
Testing Strategy 19
Risks 22
Milestone Chart 23
[pic]Overview
[pic]
In today’s hustle and bustle society, time has more value than ever before. Day-to-day errands such as food shopping or getting dressed simply detract from the natural goal of accumulating as much money as possible. A goal which requires greater energy reserves than the human body can provide on its own. Since man first crawled out of the primordial ooze, he has craved a morning coffee: a bitter tar containing the necessary spark for a productive day.
While many advances have been made over the last century in facilitating the creation of this substance, challenges still remain: filling a tank of water, getting stuck with cold coffee, and impatiently watching the machine. Such barbaric activities have no place in this modern land of instant gratification, and need to be remedied post-haste.
The Coffee Baron Project aims to advance the field of coffee automation by allowing the user control of a commercial coffeemaker from anywhere in the world. Coffee can be brewed from a neighboring room, or even from across countries. Thus, the only remaining challenge is the journey to collect the brew.
The Coffee Baron Integrated Coffee System utilizes various sensors and apparatuses to ensure optimal coffee performance. The sensors include ultrasonic rangefinders and infrared temperature sensors for detecting decanter presence, fill, and temperature. The apparatuses include servos and electronic valves for controlling the coffee sensor placement and coffee water fill rate. This collection of devices is managed by a group of four microcontrollers, with a fifth microcontroller coordinating system operation and interfacing.
[pic]Requirements Specification
• Customer Brewing Requirements
1. Support for automated local and remote brewing through multiple media.
2. Logging of vital coffee statistics.
3. Dynamic coffee operational status.
4. Comparable safety to a standard commercial coffee preparation device.
• Engineering Brewing Requirements
1. Dynamic Manual/Automatic Mode Switching (Related to Customer Requirement 1)
▪ Brewer may function in either automatic or manual mode.
▪ Automatic mode enables local pot and remote brew functionality, and disables the manual switch panel.
▪ Manual mode disables the local pot and remote brew functionality, and re-enables the manual switch panel. However, the remote monitor functions remain operational.
2. Local Pot Brew (Related to Customer Requirement 1)
▪ Sense presence of decanter and current level of fill.
▪ Automated refilling of water tank based upon level of fill desired (discrete control available in Remote Brew mode).
▪ Safe Brew start, requiring presence of decanter.
3. Remote Brew (Related to Customer Requirements 1, 2, and 3)
▪ Control of brew functionality through multiple well-established interfaces
▪ Ability to monitor the following:
• Presence of decanter
• Level of current pot fill
• Current brewer activity (if busy)
• Logged statistics of cups/gallons brewed, uptime, etc.
▪ Ability to request the following:
• Pot fill either in discrete cups or a complete fill of the decanter.
• Recheck of fill levels.
4. Power Failure Protection (Related to Customer Requirement 4)
▪ All power sensitive components must enter a “safe state” in the case of a power loss, primarily:
▪ Pot fill level reading mechanism.
▪ Water tank refill mechanism.
• Engineering Justification
1. Dynamic Manual/Automatic Mode Switching
▪ In the event of a visit by the coffee maintenance technical assistance department (CMTAD) the machine must be operable in its original factory state.
2. Local Pot Brew
▪ In the event of a catastrophic network outage and the Hazeltine 1500’s imminent self-destruction, the coffee machine must be able to brew a full pot via a local interface.
3. Remote Brew
▪ In addition to satisfying the basic customer requirements, the mediums listed below offer the following benefits:
• HTTP/WebClient
o Coffee machine is accessible from any local workstation or web-enabled mobile device.
• HTCPCP (RFC 2324)
o Has been the leading coffee pot control standard since it was first proposed on April 1st, 1998.
o We hold out hope that in the future HTCPCP will be supported by a multitude of clients.
• Hazeltine 1500
o Provides a friendly and familiar coffee interface to the DEC PDP-11 or VAX programmer.
• VT-Compatible
o An alternative terminal interface if the Hazeltine is nonexistent or nonfunctional.
4. Power Failure Protection
▪ Prevents the creation of a sizeable mess, possible homicide of other engineering projects, and upsetting Rick.
[pic]Concept Selection
As the field of coffee automation is fairly popular, many existing systems were surveyed for the Coffee Baron’s design. The project was originally inspired by Christian Finger’s automated coffee brewer () which removed nearly all brewing challenges from the user, and even ground fresh beans. However, its remote monitoring and control features were limited. Other devices, such as the K-Cup and Starbucks in-office brewer systems were also observed. Both of these offered improved coffee fidelity in brew variety and speed respectively, yet they still lacked any sort of remote monitoring. Therefore, the Coffee Baron project was designed to correct this glaring omission from previous designs.
As the Coffee Baron is intended to resemble a machine native to most offices, a BUNN VP17-1 SST commercial coffeemaker was chosen as the basis for the design. This choice was also based upon its brewing capacity and durability, with the Baron’s additional features being implemented by expanding the base coffeemaker. This design allows the Coffee Baron Integrated Coffee System to be easily adapted to other commercial coffeemakers.
The automated features of decanter monitoring and tank filling were chosen based upon field research of employee coffee habits at the General Electric and Microsoft Corporations. The research concluded that most office residents were concerned with the state of the decanter, and most common spills would occur when trying to fill a water tank. Automated changing of multiple grounds was also a candidate feature, but was reconsidered as a good target for future coffee research due to its complexity. Stability under power loss was also a prime concern, so it was required that all devices have the ability to default to a safe state in the case of a power failure.
When investigating media for communicating with the Coffee Baron remotely, the team was primarily concerned with availability. As the web browser is a ubiquitous member of an office environment, being able to communicate with the Coffee Baron through such a well distributed method was essential. However, the up and coming HTCPCP protocol offered a second well standardized method of communicating with coffee devices, and was also selected. Since legacy users may feel more comfortable using legacy devices, the Hazeltine 1500 dumb terminal was also added to the supported interface list. This device allows a friendly and familiar way for the DEC PDP-11 or VAX programmer to converse with the Coffee Baron. The Hazeltine 1500 variety of terminal was chosen based on its immediate availability and low cost of procurement. As it may be preferable to use alternative terminals, VT-Compatible support was added.
Based on the above requirements, brewing capability, reliability, and safety were the most important parts of the design. Dynamic monitoring was determined to be of moderate importance, and statistic logging was determined to be of lesser importance. Regardless of priorities, each of these components is vital to the Coffee Baron Integrated Coffee System.
[pic]Design
The Coffee Baron Integrated Coffee System is composed of five major subsystems, each managing a different aspect of the brewing feature set. This distributed coffee computing architecture allows for asynchronous processing of all necessary brewing calculations.
It should be noted that at this time of writing only PotSticker and TankMan are necessary for the operation of the CBICS. LuMos and TeaBag, while present in the device and communicating with The Baron, are currently for future expansion.
[pic]
Coffee Baron Integrated Coffee System Architecture
[pic]The Baron
The Baron is the central control component of the Coffee Baron system. It is responsible for collecting data from and sending commands to the coprocessor units. It also computes brewer usage and statistical information. Finally, and most importantly, it is the Coffee Baron’s connection to the outside world, being responsible for managing the numerous interface components.
[pic]
Baron CoffeeTalk Interface
The Baron consists of only one hardware component, a Coldfire TWR-MCF5225X microcontroller board that communicates with PotSticker, TankMan, LuMos, and TeaBag over the CoffeeTalk protocol. This protocol is a simple host to slave communications method allowing the coprocessor units to exchange information with the Baron at its request. Information is transmitted to the coprocessor units over a parallel bus in a command type and command data format. The coprocessor unit then returns the results of the Baron’s request, again over a parallel bus. Only one device may communicate with the Baron at any given time, and each requires its own 14-pin connector as shown to the right. It should be noted that the pull-up resistors used on the return data and acknowledge lines are all 2.0KΩ.
Ethernet and serial connections are also present on the Baron for use with its various interfaces. The remaining components are software, divided into two main categories: “control” and “interface.” The “control” aspect refers to modules for communication with the coprocessors. The “interface” refers to the HTTP, HTCPCP, and serial terminal interface modules.
[pic]
Baron Aux Switches Schematic
The Baron also handles the switches and button present on the front of the enclosure. The first switch is the auto/manual mode switch. In manual mode, all requests that affect state, such as read or brew requests, are ignored so that an operator can safely use the standard features of the Bunn coffeemaker. In auto mode, all of the advanced Coffee Baron features are enabled. The second switch is the terminal mode switch. The operator can choose between VT-compatible and Hazeltine-compatible modes for the serial terminal output. This way, legacy users have a choice of ancient interface hardware. Finally, the automatic brew request button serves the same functionality as requesting a full pot from the web or HTCPCP interfaces. A full brew cycle is run in response to a press of the automatic brew request button.
[pic]PotSticker
[pic]
Integration of PotSticker Sensors
PotSticker is primarily responsible for obtaining information about the current decanter and its contents. It performs these tasks through the manipulation of the Coffee Data Acquisition Arm (CDAA). This sensor arm contains both an infrared temperature sensor and ultrasonic rangefinder, which are used to measure the temperature and level of the coffee in the decanter respectively. The arm is positioned between the filter cup and decanter, and moved towards and away from its sensing position above the decanter using a single servo.
An additional ultrasonic rangefinder is positioned behind the decanter, and used to detect its presence. Thus, coffee brewing may be performed only in “safe” situations where the decanter is present at the start.
[pic]
PotSticker Coprocessor Board Schematics
PotSticker is powered by a single Motorola 68EVB912B32 evaluation board as shown above. This board has been expanded with protection circuitry for the analog inputs, a piezo beeper, a CoffeeTalk port for communication with the Baron, and sensor port for sending and receiving data to the CDAA.
[pic][pic]
Coffee Data Acquisition Arm Design
The Coffee Data Acquisition Arm’s structure is shown above, indicating the locations of the infrared temperature sensor, ultrasonic rangefinder, and servo pivot point. As the sensors must be positioned between the decanter and filter drip in order to obtain the current state of the coffee in the decanter, this read operation is only performed when coffee is not brewing. The arm is docked along the coffee machine by default and remains there until a measurement request is performed. During these measurement requests, the servo will temporarily move the arm to its sensing position and then return it safely to docking after completing its measurements. It should be noted that a power loss may occur while the arm is currently in the sensing position. Thus on power-up, the arm will always relocate itself to its safe docking position.
[pic]
Coffee Data Acquisition Arm Sensor Board Schematics
The CDAA’s assembly is modular, allowing for facilitated component replacement and therefore seamless brewing operation. It should be noted that in addition to the components listed in the schematic above, a .1uF coupling capacitor was placed between the soft VCC and ground of the MLX90164 temperature sensor in order to reduce noise.
[pic]TankMan
TankMan’s responsibility is the monitoring and control of the intermediary water tank. It performs these tasks through the use of two electronic water valves and a sensor array.
[pic]
TankMan Water Flow Control System
Before being dispensed into the coffee brewer, water is stored in an intermediary tank in order to simplify flow measurement and control. A dual electronic valve system is used to control water flow through the gravity feed system. The inlet valve is opened during tank filling, and closed during tank draining and holding. The drain valve empties the tank into the brewer. A third valve is placed at the water source, acting as a manual shutoff.
[pic]
TankMan Water Measurement System
The intermediary tank is kept full at all times, and water is released only when the Baron requests a dispense operation. A breadless waterfowl-based micropond fill indicator attached to a pivoting arm is used to sense that the tank is full or has completed a fill cycle by tripping the fill microswitch above. As water is dispensed from the tank purely through gravity feed, the flow rate is constant. Thus, the amount of water dispensed from the intermediary tank into the brewer is measured solely by the amount of time the drain valve is open.
[pic]
TankMan Valve Control Schematic
The TankMan valve control is implemented in an external module connected using a 10-pin header as shown to the right. Therefore the Power-FETs in the schematic above are completely separate from the low voltage TankMan board, and the valve controls are kept in a closed state when TankMan is inactive. Each valve is given two control lines which must be pulled low in order to allow the valve to open.
It is possible for a power failure to occur during a tank fill operation. Thus, the electronic flow valves default to their closed positions under a power loss in order to protect from unintentional flooding.
[pic]LuMos
Is just taking up pins and beeping over CoffeeTalk for now. Maybe he’ll manage mood lighting one day in the future…
[pic]TeaBag
Is just copying what LuMos is doing.
[pic]Interface
As discussed previously, the Baron is responsible for tracking, preparing, and presenting information for the user. To this end, the Baron includes a custom web server supporting both the HTTP (hyper-text transfer protocol) version 1.0 and HTCPCP (hyper-text coffeepot control protocol) version 1.0 standards, defined in IETF RFCs 1945 and 2324 respectively. A status and control page is available and viewable in any standard web browser, as seen below:
[pic]
Coffee Baron Web Interface
The web interface also features a help and information page and a log page, which can be found linked from the Baron’s homepage.
[pic] [pic]
Coffee Baron Legacy Interfaces, Hazeltine 1500 (left) and DEC VT220 (right)
In addition to the web interface and desktop/mobile client, the Baron also has an available advanced serial interface for local control, featuring a dynamic visual status display and an interactive command interpreter. The serial interface is available in VT-compatible and Hazeltine-compatible modes using the terminal mode switch on the front of the enclosure. All of the features available to the other interfaces are also available from the serial shell.
[pic] [pic]
Coffee Baron JavaKnight (left) and CoffeeDroid (right) Interfaces
To encourage further adoption of HTCPCP, the Coffee Baron project includes HTCPCP clients for many popular platforms. The JavaKnight client, pictured below, adds support for HTCPCP to any Windows, Linux, or Mac environment capable of running Java applications. It also provides a lightweight solution for checking the status of your coffee without opening a web browser. Along with the desktop version of the application, an Android version of the client has been developed. The Android client, CoffeeDroid, brings HTCPCP support to one of the world’s most popular mobile computing platforms, and allows users to check the status of their coffee and order a fresh pot without access to a computer. Both clients are capable of communicating with any HTCPCP-compatible device, and also include HTTP support for the Coffee Baron’s web interface.
[pic]Considerations
Due to the primal appeal of automated coffee technology, conservative estimations project world changing impact and will revolutionize the office of the future. The automated nature of the Coffee Baron permits for reductions in deviations from the anticipated optimum brewing procedure. Resources such as water, coffee grounds, and misplaced interns will be better protected against accidental use by the obstinate brewer. Through its feature-rich design the Coffee Baron accommodates not only the coffee operator, but also provides a cost effective solution for a quality coffee experience.
It should be noted that many engineers currently employed under the role of coffee preparation specialist will face stiff competition from a machine which can perform their menial task quickly and without unnecessary vocalizations. Subsequently, many brewing engineers will need to find either other responsibilities at their place of work or new employment elsewhere. Additionally, the overhead required to obtain a cup of coffee would be negligible, thus increasing the potential for coffee-related hazards in the workplace. Excessive interruptions during meetings to use the restrooms or even ulcers may occur. Thus it is advisable to train all present and prospective employees on proper coffeepot etiquette in order to reduce pessimum behavior.
Forefront in the Coffee Baron design and execution is a focus on long-term sustainability efforts. The Coffee Baron utilizes state of the art recycling techniques allowing the repurpose of discarded electronic devices. Constituent components of the Coffee Baron are meticulously screened and selected from deprecated assets. These environmentally conscious efforts ensure the Coffee Baron’s place as the authoritative brewing device in the emerging green automated coffee market.
Because of the Coffee Baron’s novel approach to coffee automation, the prospects for patentability are probable. There exists no prior knowledge of any parties’ investment and investigation of this type of green coffeemaker. The system and method for repurposing depreciated assets as an environmentally sustainable automated coffee brewing device meet the basic requirements for patent filing.
[pic]Bill of Materials
Listed below is the collective bill of materials categorized by coffee subsystem. The SubscriptT indicates the column is the actual cost to the team. Any field marked with a ”0” indicates that the item was obtained through the coffee sustainability program by pulling it out of a wastebasket, and thus had a negligible cost. Any legacy items which are no longer available are listed with their value at last time of manufacturing. Certain items obtained through the coffee sustainability program which are non-replicable (such as the GameBoy Color cartridge mold used for PotSticker’s CDAA) or scavenged parts such as nuts and bolts may not be listed.
Coffee User Experience
|Quantity |
|Fields of Verification |Test Cases |
|The Baron properly communicates with PotSticker, TankMan, |Send unique values to coprocessors with “HALLO” command, ensure correct |
|LuMos, and TeaBag. |responses |
| |Verify audio feedback when system is powered on, as well as through the “TALK” |
| |command |
| |Request decanter presence, temperature, and fill level information from |
| |PotSticker and verify responses |
|Feature: Operation Mode |
|Fields of Verification |Test Cases |
|The Coffee Baron may be switched between automatic and |Select automatic mode |
|manual mode properly. |Brew coffee and verify coffee operation |
| |Select manual mode |
| |Brew coffee and verify coffee operation |
|Feature: User Interface |
|Fields of Verification |Test Cases |
|The Coffee Baron may be controlled from the on-machine |Press “auto-brew” button/switch and verify coffee operation |
|brew button. | |
|The Coffee Baron may be controlled from the HTTP |Direct web browser to |
|Webclient. |Verify accurate measurements |
| |Choose to brew coffee and verify coffee operation |
| |Verify accurate measurements |
| |(If DNS is available, the coffee server’s DNS name may be substituted for the |
| |internet protocol address in the URI) |
|The Coffee Baron may be controlled through HTCPCP. |Direct HTCPCP client to coffee:///pot-1 |
| |Verify accurate measurements |
| |Choose to brew coffee and verify coffee operation |
| |Verify accurate measurements |
| |(If DNS is available, the coffee server’s DNS name may be substituted for the |
| |internet protocol address in the URI) |
|The Coffee Baron may be controlled through the Hazeltine |Cautiously engage the Hazeltine 1500 (or similar serial terminal) |
|1500 (or similar serial terminal). |Verify accurate measurements |
| |Choose to brew coffee and verify coffee operation |
| |Verify accurate measurements |
|The Coffee Baron HTTP and HTCPCP interfaces are secure, |Run the Coffee Baron Network Interface Functionality Test Instrument (CB-NIFTI)|
|stable, and performant |•Open single HTTP/HTCPCP connection |
| |•Test HTTP/HTCPCP methods (GET, POST, BREW, etc.) with various data, valid and |
| |invalid |
| |•Ensure HTTP/HTCPCP service does not crash or misbehave |
| |Run the Coffee Baron Network And Stability Test Instrument (CB-NASTI) |
| |•Open multiple simultaneous HTTP/HTCPCP connections |
| |•Simulate resource contention |
| |•Ensure reasonable “first come, first serve” behavior for brew operations |
| |•Ensure performance under load of multiple connections (amount TBD) and |
| |graceful failure modes when too many clients connect |
| |Run the Coffee Baron Protocol Operation Overwhelming Fuzzer (CB-POOF) |
| |•Send many (valid and invalid) request headers and resource requests via HTTP |
| |and HTCPCP |
| |•Ensure HTTP/HTCPCP service does not crash or misbehave |
PotSticker Testing Paradigm
|Feature: Decanter Presence |
|Fields of Verification |Test Cases |
|The presence of the decanter must be detected properly. |Verify decanter presence results with and without decanter via serial |
| |debug interface |
| |Verify presence results via external interfaces |
|Feature: Decanter Fill Level |
|Fields of Verification |Test Cases |
|The current fill level of the decanter must be detected properly. |Verify depth reading of empty decanter |
| |Verify depth reading of partially filled decanter |
| |Verify depth reading of filled decanter |
|Feature: Coffee Temperature |
|Fields of Verification |Test Cases |
|The temperature of the coffee in the decanter must be detected |Verify temperature of water or coffee left out at room temperature |
|properly. |Heat water with burner |
| |Verify temperature of heated water or coffee |
|Feature: Arm Movement |
|Fields of Verification |Test Cases |
|The CDAA must be movable under processor control. |Move CDAA between docked and measuring positions via both PotSticker |
| |serial debug and CoffeeTalk |
|The arm must move safely and not collide with any obstacles. |Move CDAA between docked and measuring positions and verify that there|
| |is no collision with the decanter or other apparatus |
|The arm must move into sensing mode only when necessary. |Request sensor data from PotSticker |
| |Verify arm extends, measures, and retracts |
| |Begin brewing operation |
| |Request sensor data from PotSticker |
| |Verify arm does not extend |
|The arm must move back to docking mode when not in use. |Verify that CDAA moves to docking position on power-on |
|Feature: Power Safety |
|Fields of Verification |Test Cases |
|In the case of a power failure, the CDAA will dock immediately when |Verify that CDAA retracts when power is cut and restored |
|power is restored to the unit. | |
TankMan Testing Paradigm
|Feature: Water Valve |
|Fields of Verification |Test Cases |
|The water valve may be opened and closed under processor control. |Verify TankMan valve control functionality via serial debug |
|The tank may be filled in discrete amounts. |Fill decanter by one cup via web, HTCPCP, or serial terminal interface|
|Feature: Power Safety |
|Fields of Verification |Test Cases |
|The water valve will default to its closed position under power |Cut power, verify valve remains closed |
|loss. |Restore power, verify valve remains closed |
| |Begin dispensing water |
| |Cut power, verify valve closes |
|Feature: Cleanliness |
|Fields of Verification |Test Cases |
|No overflowing of the tank or spillage will occur. |Brew and drink or otherwise dispose of many pots of coffee |
| |Ensure no tank overflow or spillage occurs |
LuMos Testing Paradigm
|Feature: Bup |
|Fields of Verification |Test Cases |
|None |None |
TeaBag Testing Paradigm
|Feature: Bup |
|Fields of Verification |Test Cases |
|None |None |
Integration Testing Paradigm
|Feature: Distributed Coffee Processing |
|Fields of Verification |Test Cases |
|All above components properly coexist and operate harmoniously to |Brew proper and harmonious coffee |
|deliver properly brewed coffee. | |
[pic]Risks
As with any project, there will be a number of difficulties to overcome in the planning and execution phases. At this stage, additional research is required before designs can be finalized for some of the components. For example, the method of interfacing with the existing electronics in the coffee machine base has not been decided because there is not yet a coffee machine available to design an interface for. Research and experimentation will also be needed to verify that the choices of sensors outlined in the PotSticker and TankMan designs above are appropriate for their respective tasks. In addition, a final method has not been selected for TankMan’s measuring of the fill level of the water tank. All measurement systems will have to be tested thoroughly to verify the accuracy and usefulness of data, and alternative designs should be considered if necessary. In summary, at this juncture, much of the design should be considered tentative, leaving plenty of room for possible complications.
There are also risks and dangerous failure conditions that could arise in the operation of the Coffee Baron once it is constructed if special considerations are not taken during design. Some notable concerns include behavior when power is lost and restored with respect to the valve and arm positions. TankMan’s tank fill valve should default to its closed position when power is lost and stay closed when power is turned on. PotSticker’s Coffee Data Acquisition Arm should return to a safe place away from the pot when power is turned on. Care must also be taken to prevent damage to the arm, surrounding area, or users by freshly brewed coffee. The arm should be retracted when a new brewing task begins, and should not be extended for the duration of the operation. Coffee should not be brewed unless the pot is present and the arm is retracted. It is also important to have local overrides in the event that the remote interfaces are unavailable, such as due to a network outage. Such overrides will be available in the form of a local control of the automated process, as well as a cutover to manual operation.
Despite the precautions listed above, it is possible that a catastrophic failure could lead to damage, injury, or loss of coffee-making materials. However, this is the case for even an unmodified coffee machine. It is the intention of the Coffee Baron design team to make the risk of operating the Coffee Baron system comparable to the risk of using an unmodified device.
The risks outlined above are summarized in the following two tables:
Design Risks and Difficulties
|Risk |Likelihood |Severity |
|Difficulties may arise in developing the interface with the coffeepot |Medium |High |
|Difficulties may arise in developing the method for measuring tank fill level |Low |Medium |
|Planned sensory apparatuses may not provide accurate results |Low |Low |
Operational Risks:
|Risk |Likelihood (without |Severity |Mitigation |
| |mitigation) | | |
|Loss of power during tank fill causes |Medium |High |Implement failsafe to ensure that loss of power |
|flooding of apparatus | | |closes valve |
|Loss of power during pot survey leaves |Medium |Low |Implement failsafe to ensure sane startup conditions |
|PotSticker’s Coffee Data Acquisition Arm | | |when power is restored |
|over pot | | | |
|Hot coffee is dispensed with no pot |Medium |High |Develop sensor system to ensure that coffee is not |
|present | | |prepared if pot is missing, and brewing is |
| | | |interrupted if pot is removed |
|Hot coffee is dispensed over PotSticker’s|Medium |Medium |A request to brew coffee should ensure that the arm |
|arm | | |is moved away; queries for information should not |
| | | |cause the arm to move into position if brewing is in |
| | | |progress |
|Network outage prevents access to Baron, |Medium |Medium |Two forms of local override should appear on the |
|making it impossible to start and stop | | |device: a local control of the automatic system, as |
|brewing procedures | | |well as a means of returning the device to full |
| | | |manual mode |
[pic]Milestone Chart
The current project milestones and their respective owners are listed below:
|Task |Deadline |Owner |
|Baron: Platform Investigation |1/25/2012 |Corey |
|TankMan: Flow Control Hardware Draft |1/25/2012 |Osman |
|PotSticker: Arm Hardware Draft |1/25/2012 |Osman |
|Client: HTCPCP Investigation |1/25/2012 |Anthony |
| | | |
|Baron: TCP Operational |2/1/2012 |Corey |
|PotSticker: Arm Positioning Operational |2/8/2012 |Osman |
|PotSticker: Arm Coffee Sensors Operational |2/15/2012 |Osman |
|PotSticker & TankMan: Coprocessor Protocol Draft |2/15/2012 |Osman |
|Client: Java Desktop HTCPCP Client Draft |2/15/2012 |Anthony |
|Baron: HTTP Operational |2/22/2012 |Corey |
|Client: Android Platform Feasibility Investigation |2/22/2012 |Anthony |
| | | |
|Baron: HTCPCP Operational |3/21/2012 |Corey |
|PotSticker: Decanter Presence Detection Operational |3/21/2012 |Osman |
|PotSticker & TankMan: Coprocessor Protocol Final |3/28/2012 |Osman |
| | | |
|Baron: Serial Hazeltine Interface Operational |4/4/2012 |Corey |
|TankMan: Valve Control Operational |4/4/2012 |Osman |
|Baron: Integration with PotSticker |4/11/2012 |Corey |
|TankMan: Tank Level Reading Operational |4/11/2012 |Osman |
| | | |
|Client: Java Desktop HTCPCP Client Stable |4/11/2012 |Anthony |
|Baron: Integration with TankMan |4/18/2012 |Corey |
|Baron: Addition of Local Automatic Brew Request |4/18/2012 |Corey |
|Client: Android Platform HTCPCP Client Draft |4/25/2012 |Anthony |
| | | |
|All: Project Demoable for Imagine RIT |4/27/2012 |All |
| | | |
|Client: Android Platform HTCPCP Client Stable |5/9/2012 |Anthony |
[pic][pic]
-----------------------
[pic]
BUNN VP17-1 SST Brewer
[pic]
Hazeltine 1500
ColdFire Processor Module
The Baron
Integrated Coffee System Management Unit
External Interfaces
CoffeeTalk Bus Master
M68ECV912B32 Coprocessor
CoffeeTalk Device Interface
CDAA Sensors and Motors
Decanter Presence and Contents Monitoring Unit
PotSticker
M68ECV912B32 Coprocessor
CoffeeTalk Device Interface
Tank Sensors and Motors
Water Tank Fill and Level Management Unit
TankMan
CoffeeTalk Bus
Manual Mode Switch
Ethernet
Hazeltine 1500
M68ECV912B32 Coprocessor
CoffeeTalk Device Interface
Light Sensors and LEDs
Environment and Brewer Lighting Management Unit
LuMos
M68ECV912B32 Coprocessor
CoffeeTalk Device Interface
Packet Dispenser Module
Flat and Rectangular Container Dispensing Unit
TeaBag
[pic]
CoffeeTalk Port Details
[pic]
Tank Sense Header Details
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.