purefisher / smart-serve

Our project seeks to create a robot that can assist bartenders by creating cocktails for customers. We seek to create a fully functional 3-D robotic system that is able to upon user request assemble, package and serve a cocktail of their choosing. This embedded system will have a GUI that the user will be able to interact with.

Smart Serve

Developer Names: David Bednar Max Turek Ryan Were Sam Nusselder Peter Minbashian

Date of project start: September 26th, 2022.

Stonecap Solutions aims to solve existing issues in the billion dollar bartending industry relating to the process of fulfilling drink orders. Bars are often busy with many orders being processed through a mental queue by bartenders. This can result in long wait times. Furthermore, many restaurants and bars are susceptible to being understaffed, further exasperating this issue. Cocktails and other drinks are imprecisely made, varying in volume and consistency. When bartenders are rushing around to make these drinks, the risk of spilling them arises. If these issues are severe enough, it could result in unsatisfied customers, decreasing business profits.

The folders and files for this project are as follows:

docs - Documentation for the project refs - Reference material used for the project, including papers src - Source code test - Test cases etc.

smart-serve's Issues

Team 16: Exporting variables instead of constants

Exported constants should be hard-coded literal values, not variables. Many exported constants throughout the MIS (finished, cocktailCreated, etc.) are variables that can have their values changed.

Team 34 Design Doc Review: Detailed Design Doc Uses Subsection

@NickCapstone

Overall, the MIS was well done with good detail.
However, the 'Uses' subsection on the modules should be on what other modules the module uses, not the purpose of the module.

For example, the Drink Completion Module might have the Python Hardware Module under the 'Uses' section.
The purpose of the module is already described within the system architecture document, so there is minimal benefit in restating its use.

Order parts for rotating disk i.e. motor, tubing, wire kit, DC power supply

Team17 Review: How test ST-FR-DMT-01 is performed

In the description about how the test ST-FR-DMT-01 will be performed, the document shows that the test should be done after the completion of the test ST-FR-CPT-01 (testing if "no cup present" notification will be received when there is no cup present for the current order). I think it would make more sense if the test ST-FR-DMT-01 will be performed after both test ST-FR-CPT-01 and test ST-FR-CPT-02 are completed, since it is also important to make sure that the "no cup present" notification is removed after a cup is placed and before the system start dispensing a drink.

@samm82

Build Smart Serve frame and assemble hardware

Buy materials needed to create the frame and body of Smart Serve including wood, clear plexiglass, etc

Order parts for POC

Need to order a few parts for the hardware portion of the system

• raspberry pi or equivalent microcontroller/computer for the system + power supply for the raspberry pi
• power supply to convert ac voltage into dc voltage // this can be added later
• peristaltic pump to test out the dispensing of liquids
• food grade tubing to distribute the liquids
• breadboards and wires

Team 34 Design Doc Review: System Design Doc Timeline

@NickCapstone

Well done with the timeline on the development of the product within the System Design document.
Although all the components and modules are covered, some more detail could be added onto the timeline.

For example, who is responsible for which tasks?
Maybe also split the tasks up further into individual modules, instead of just 'software modules'.

Team17 Review: More tests for Drink Made Test

The Drink Made Test has covered scenarios where the cup presents in the pouring area is empty or full. However, I think it would be better if the tests could also cover the scenario where the cup present in the pouring area is partially filled. For example, if the operator put a half-filled cup in the pouring area (whether by accident or on purpose) and the machine is pouring the same volume of liquid into the cup as when an empty cup presents, the liquid will also eventually poured out of the cup after the cup is filled during the process of making the drink.

@samm82

Team18 Review: Lack of connections in the FMEA table

Each individual error looks great in the FMEA table, great work! However, it's lacking of connections between errors and between each systems. The errors in different systems can be connected and have influence on each other, it's important to document them with references. For example, the effect of a specific error in one system can be the cause of a hazard in another system. In the table, H1-1, H1-4 can be the cause of H2-1, since over-pouring of liquids or misalignment can potentially short circuit the device. And H1-3 can be caused by some authentication error where the users are mismatched with their orders.

Research API requests to integrate raspberry pi with web application

Team 18 HA Review: Contradiction in Container Material

The critical assumption states that "All drinking containers are made of plastic", however in the FMEA table it is using glass when referring to containers. If the containers are made of glass, then your hazard analysis should probably also include hazards related to the handling of glassware. Injuries to the hand are the most frequent occurrence when handling glassware, ranging from minor cuts to more serious injuries, such as puncture wounds. If the container is made of plastic, disposal of used plastic containers might also need to be considered.

Order depth sensor + motion sensor (research)

Team 18 HA Review: Out of Scope Hazards

Maybe it will be helpful to add an explanation about why these hazards are out of scope and how the team will minimize the hazards.

Team 15 Review: Results of NFR system tests

At the beginning of the NFR system tests section you mention that "All test results are qualitative and not measured" and so the results are simply pass or fail, but many of the tests do have quantitative values assigned to them. Some of the tests have this quantitative data mentioned in the Actual Outputs section (ST-NFR-PR-01, ST-NFR-PR-02), but many do not. It would be useful to add this data so that readers of your document can get a better sense of the performance of your project.

@samm82

Team15 Review: No Design Document VNV

Hey guys, it might be more accurate to categorize this as an issue for the VNV Plan and not the VNV Report, but I figure its close enough that it bears mentioning here. I notice there is no mention of any document reviews in your report, only implementation testing. Assuming you are basing your implementation off of your prior design documents, it might not be a bad idea to perform a quick review of things like your SRS or Hazard Analysis to make sure they still align with what you're doing. As a bonus it makes it easier to figure out what you need to change for the Rev1 documentation.
@samm82

Team17 Review: Some test methods not specific for Nonfunctional Requirements

For some non-functional tests, the method of testing is that testers will report their opinions after using the product (e.g. ST-NFR-UR-02, ST-NFR-PR-02). It doesn't specify how the questions for these responses are asked (in person, via survey, etc.), and how responses will be recorded. For example, a usability survey is an appropriate testing method that could have been specified, and documented in Section 7.2.

@samm82

Team 15 Review: Functional and Non-Functional Testing

One of the aspects that are usually tested through unit testing is boundary and unexpected input handling and as there were no unit testing, I wasn't sure if the inputs are submitted in a specific way that would not really allow bad entries. For each of the functional requirements, there are system tests that can be written to verify them. Similarly for the non-functional requirements, quantitative methods should be included such as performance. Small things but hope it helps.

@samm82

Team_19_Review_Introduction #1

One potential issue in the introduction section is that for the stakeholders, can include more details, such as what/how they are going to be involved with the outcome of the project. And another potential issue is that for the constant (i.e. cup size,) more details can be given to give readers a better understanding

Team 17 review: VnV plan

The reflection part can be more understandable by the reader. For example, reflection can be two parts: one listing every knowledge and
skills that team member needs to learn and one is the reflection part written by team members that each team member focus on one point of knowledge and skills.

Team 34 Design Doc Review

@NickCapstone For your MIS Semantics, I believe there can be more detail on how the modules will work. For example, MIS for Python HW Semantics 8.4.1 State Variables
Drink: Ceasar, Mojito, Margarita, etc... all the cocktails the product can mix
cocktailCreated: cocktailCreated
8.4.2 Environment Variables
All the ingredients can hold but written in variables. 8.4.4 Access Routine Semantics
makeCocktail():-->Ceasar()-->Vodka()-->ClamatoJuice()-->Sauce()-->Ready() output:
If Drink order is sent
and If Cup is at machine
and If Appropriate Ingredients are available
exception: If Ingredients are not available or If Cups not available

Great work. Can't wait for this demo.

Team17 Review: Nondynamic Testing Used a Necessary

Would like to see some more non-dynamic testing on top of just dynamic testing, such as static testing, code review, inspections, document review, walkthroughs etc. As per the rubric for the VnV, "detailed and clear plans for evidence beyond dynamic testing are included as appropriate. Nondynamic testing plan is feasible." Right now the testing mostly focuses on dynamic testing and so more nondynamic testing would be good.
@samm82

Update documentation + verify all requirements for system

Team17 Review VnVPlan

Under each area of testing for the requirements, it would be useful to include how each tests relates to a requirement and what part of the requirement it covers

Team 34 Design Doc Review: System Design Doc UI

@NickCapstone

As previously mentioned, the UI was well described within the System Design document.
However, it was focused on only the software UI: how the user interacts with the software components.
Another potential UI could be between the user and the mechanical components of the product, if it exists.

For example, are there any physical buttons that the user presses? How do they retrieve the drink, and do they need to do anything to send the product back?
This section doesn't need to be long, especially if there is minimal interaction, but a short description should be present.

Team 15 Review: Unit testing

Something I found was missing was unit testing. You did say that it isn't applicable, but it would also be helpful to include an explanation as to why they aren't (since it's not immediately obvious).

@samm82

Team17 Review: Test Case Derivation for ST-FR-ICT-01

In the Ingredient Communications Test section, the input for test ST-FR-ICT-01 indicates that ingredient(s) are out of inventory, while the test case derivation says that it is derived from the requirement ODR6 ("User is notified when drink is done"). I was wondering if it should be ODR5 ("User is notified if drink ingredients are out of inventory") in this case.

@samm82

Team 34 Design Doc Review : System Design Doc Event Handling

@NickCapstone

Well done with including the undesired event handling within the System Design doc, section 6.2.
However, perhaps more detail could be added on the exact event being caught.

For example, which events are being caught? How will they be handled? Are they all handled the same way by notifying the operator, or are there some events that the product could handle by itself? And what exactly is the 'safe state' that is mentioned? How does the product behave within this 'safe state'?

Team_19_Review_Issue_References

Please provide references for relevant information and requirements. For example, with the requirement HSR3, where did the value of 2 drinks per hour come from? Also please be more descriptive of detailed in terms of constraints in section 2, explain how those constraints will be issues and again include references on how certain constraints were developed. For example, the law, liquor and sanitary regulations could have been cited.
-Moksha Srinivasan & Smita Singh

Team16 Review: System Design - Inconsistencies in 6.4

Overall, the System Design document looks good! One issue I did notice, however, was that there were some inconsistencies among the requirements listed in 6.4 Connection Between Requirements and Design. In some requirements, the fit criteria were a bit vague; i.e.

UHR1. Smart Serve must serve the drink at a height that is easy to grab for an average
adult
Design consideration: Smart Serve is designed to be set on a table to ensure it is easy
for the users to grab their drinks.

What height range does an 'average adult' fall in? I went looking for a fit criteria in your SRS, but couldn't find a condition to definitively check if this requirement is met or not.

Contrastly,

PR1. The drink must be ready and served within 45 seconds of when the drink began to
be made
Design consideration: The pumps used in Smart Serve have a flow rate that allow
them to complete a drink in under 45 seconds.

has a very clear fit criteria, and very clear conditions for meeting the requirement. I would recommend listing a 'fit criteria' under each of these non-functional requirements to clearly communicate how each requirement will be assessed, which may better inform your future design considerations.

Team 16 Review: Output of Access Routine Sematics

In the system design document, the access routine semantics are supposed to mention the output of the function rather than the the method of how to get this output. For example in 7.4.4 the output is explained but the result is not given.

Finish setting up repository with PR's and SW/HW branches

Team 18 HA Review: Roadmap

In the roadmap, you can specify which safety requirements will be implemented and which ones will be postponed after the course. One suggestion is to break the roadmap into sections and group the requirements that will be implemented in the order of deadlines or priorities. E.g. Requirement A will be implemented by POC.

AutoCAD prototype

Team18 Review: Details of FMEA table

Some components in FMEA table is lacking depth and traceability information. Every component and their hazard analysis is explained elaborately but some details could be improved upon.

For example, in H2-3, the failure mode is "Smart Serve gets bumped into", which is similar as the cause of failure. It should not be that specific, instead, you can write it as "Smart Serve is physically damaged". Then you could analyze what should be possible cause afterwords. Additionally, for H3-2 and H3-3, causes of failure both go to user and operator's side, which leaves out any system causes like server maintenance, internet error, account deleted by administrator, queue is reset at back-end. Finally, you could modify corresponding recommendation, SR, etc.

Team17 Review: Traceability to Requirements

In Section 5.3 Traceability Between Test Cases and Requirements, some of the functional requirements listed in the SRS documents are missing, such as ODR 6-7 & 13-18 and MDR 1 & 11-13. Many of the nonfunctional requirements also seem to be missing from the table. It would be better if the system tests cover all of the requirements.

@samm82

Team 15 Review: Requirement testing

In the tables where you reported the system tests I would use "User Action" instead of "input" as that is a more suitable title for what is described in that column. Also, It might make more sense to explain the scoring system inside expected result rather than input. For example, in expected result you'd have "The average score from the testers in the survey is greater than 3 on a scale from 1 to 5: 1-unusable 2-poor 3-satisfactory ...".

@samm82

Team_19_Review_TraceabilityMatrix

Make sure you add a traceability matrix to map functional and non functional requirements. This is so you have a better understanding of what your functional requirements are trying to accomplish when looking back at your final product.

Team16 Review: Secrets in MG are describing contents rather than purpose

Some secrets found in the MG are describing the contents of the module rather than what the module should do. For example, the Drink Ready Module's secret is "A boolean value corresponding to the completion of a drink sent from the Hardware" which should instead be something along the lines of "Manages the status (finished or not finished) of a drink".

Team_19_Review_Functional_Requirements

Each requirement point should have a description of it's rationale, related business event(s), fit criteria, planned date, and revision history.
It important to include that information for the reader to understand how the requirements are beneficial and verifiable and track changes to the requirements.

Team_19_Review_Non_Functional_Requirements #1

Your NFR are not entirely verifiable. For example, your QR1 states your system must be robust. It is not quite clear what your definition of robustness is. I would suggest adding a rationale so one can understand how to verify robustness for your system. Also, for PR5, why would the ingredients only have an accuracy of 10%. Should the error margin not be 10%. I feel like making the accuracy amount as 10% makes the system seem flawed.

Team 15 VnV Report Review: Initial State, Relevant Docs

Solid report overall. However, I noticed initial states are absent for the tests in the report. Additionally, should the SRS not also be mentioned as a relevant document given Symbols, Abbreviations, Acronyms and requirements are referenced from it?

@samm82

Write python code to create workflow of drink machine

Need to separate into Hardware branch which will include all the drink machines

Design/brainstorm drink rotating disk

Team 34 Design Doc Review

@NickCapstone

Great work overall. One thing I realized is the broken references within your Software Architecture document. In addition, the Traceability Matrix lacks references as a whole. Should be an easy fix.

Team 16 Review: Timeline is not detailed

The timeline makes no mention of the specific modules that will be completed by a specific date. Should go more in depth on the specific hardware and software modules you are implementing. Also, there is no mention on who will do what for the project to be completed on time.

Team 34 Design Doc Review: System Design Doc UI

@NickCapstone

The figures of the UI are very useful in the System Design document, section 8.
However, it could be made clearer with some accompanying text.

A useful piece of information could be which screen follows which screens? For example, which screen does the user get when they finish logging in? Also, who needs to log in? Just administrators or also customers?