Acknowledgements Firstly, I would like to give a huge thank you to my advisor Dr. Weifeng Chen for not only advising this project, but for also advising my college career. His guidance, expertise, patience, and motivation has made both the research and development process of this project much smoother and impactful. Another huge thank you is in order for my teammates: Johnathan Bissontz, Trevor Jamison, and Elizabeth Sterling. Working with each one of them has heightened my passion for software development and teamwork. The knowledge that they brought forth to this project made it a fun and eventful development process. Although absent from my research, my teammates all made their impact on it one way or another. I just want to thank them all for being such wonderful students, leaders, and friends. I would also like to thank the University Honors Program for giving me the opportunity to partake in such research. The Honors Program and its faculty have made me into a better student and researcher. I have learned an immense amount of information as well as gained plenty of skills that will help me in my future career and studies. In particular, I would like to thank Dr. Craig Fox for being such an outstanding professor and mentor. Mason 1 Table of Contents I. Thesis Introduction .................................................................................. 3 1) Advisement and Program Information............................................................. 3 2) Notice .............................................................................................................. 4 3) Abstract............................................................................................................ 4 II. What Is Meant by Robotics in Hospitality? ......................................... 5 1) Definition and Purpose .................................................................................... 5 2) Uses… ............................................................................................................. 6 III. Benefits of Using Robots in the Industry ............................................ 6 1) Company/Business Benefits ............................................................................ 6 2) Employee Benefits ........................................................................................... 8 3) Customer/Guest Benefits ................................................................................. 9 IV. Things to Consider............................................................................... 10 1) Customer/Guest Comfortability ..................................................................... 10 2) Replacement of Human Workers ................................................................... 11 3) Cost ................................................................................................................ 11 V. Meet Jarvis............................................................................................. 12 1) Brief Description ........................................................................................... 12 2) Purpose of Creation ....................................................................................... 12 3) How Jarvis Depicts the Future of the Hospitality Industry............................ 13 VI. Technical Documentation ................................................................... 14 1) Introduction to Technical Documentation ...................................................... 14 2) Specifications ................................................................................................. 15 a) Purpose and Use ...................................................................................... 15 b) Intended Audience ................................................................................... 16 c) End-User Profile ...................................................................................... 16 d) User Interaction….................................................................................... 17 e) Hardware Constraints .............................................................................. 18 f) Software Constraints ................................................................................ 20 g) Time Constraints ...................................................................................... 21 h) Cost Constraints ....................................................................................... 21 i) Other Concerns ........................................................................................ 22 Mason 2 j) Criteria for User Acceptance ................................................................... 22 k) Integration of Separate Parts and Installation .......................................... 23 l) Functional: Use Cases and Scenarios ...................................................... 24 m) Entity: Class Diagrams ............................................................................ 27 n) Dynamic: State Charts ............................................................................. 29 o) Components and Tools Needed ............................................................... 34 3) Design ............................................................................................................ 35 a) Purpose and Use ...................................................................................... 35 b) Ties to Specification Document .............................................................. 36 c) Project Block Diagram ............................................................................ 37 d) Architectural Diagram ............................................................................. 39 e) Module Cohesion ..................................................................................... 40 f) Module Coupling ..................................................................................... 40 g) Data Flow or Transaction Analysis ......................................................... 41 h) Design Organization ................................................................................ 42 i) Modules Used .......................................................................................... 55 j) Files Accessed ......................................................................................... 55 k) Real-time Requirements .......................................................................... 56 l) Messages.................................................................................................. 56 m) Narrative/PDL.......................................................................................... 57 n) Programming Language/Reuse/Portability .............................................. 59 o) Timeline ................................................................................................... 60 p) Design Testing ......................................................................................... 61 4) User Manual .................................................................................................. 61 a) User/Client ............................................................................................... 61 b) Administration ......................................................................................... 65 VII. Conclusion .......................................................................................... 68 VIII. Technical Glossary ........................................................................... 70 IX. References ............................................................................................ 72 Mason 3 Thesis Introduction Advisement and Program Information This thesis project and research has been advised and conducted through the California University of Pennsylvania Honors Program. The University Honors Program is dedicated to providing their students with academic, professional, and social opportunities during their time at CalU. As a result, students are able to participate in multiple research opportunities within a disciplinary of their choice. The research portion of this thesis was supervised by the Honors Program. They provided multiple resources, both on campus and virtually, to help assist with obtaining academic resources, external documentation, and research exposure. This project was also presented at the CalU Strike-A-Spark conference in order to make use of both peer and professional feedback. The Eberly College of Science and Technology has provided advisement for Jarvis through the following departments: Computer Science, Computer Engineering Technology, and Electric Engineering Technology. Dr. Weifeng Chen, a member of the department of Computer Science, Information Systems and Engineering Technology, has been the head advisor and coordinator for the feasible portion of this thesis. Dr. Chen also helped to correct and revise the technical portion of this document to ensure accuracy and integrity. Jarvis was presented to a panel of professors from each department in order to physically test his software and hardware components. The feedback given from both the conference and technical evaluation have been implemented into the final revision of this document. Mason 4 Notice The following information provided is based solely off of individual research and agile development. Each component of this document is meant to provide a deeper understanding of the software engineering process, aspects of electrical engineering and artificial intelligence, and how to relate the project to the real world. All information regarding the physical creation of Jarvis is authentic and based on the development process followed by the team. Also, some research within this document has been based off of the abilities of Jarvis and his potential. This research can be considered hypothetical, as it was made to observe and make conclusions based off of the capabilities of service robots. Abstract With the continuous advancement of technology, changes are bound to occur within every industry in today’s society. From personal AI assistants to autonomous vehicles, technology is reaching new heights each and every day. Jarvis, a selfnavigating service robot, was completed by a group of four Computer Science students at the California University of Pennsylvania in order to research the many uses of robotics. In this research project, the creation of Jarvis aims to provide insight into what the hospitality industry would look like with robots like Jarvis and how they can benefit the industry as a whole. Through the use of artificial intelligence, computer engineering, and electrical engineering, Jarvis has the ability to carry objects on a balance plate and navigate his surroundings simultaneously. Jarvis makes use of a client-server system that allows users to send requests and have them accepted by Mason 5 administration. This type of communication allows for more personalization for the user, a quicker service, and an easier workload for the human staff. For example, by allowing a self-navigating robot to travel back and forth between destinations on a single hotel floor, employees will have more time to focus on their daily tasks, while also keeping their visitors satisfied. Although research has been completed on similar ideas, this project seeks to demonstrate the abilities of an autonomous service robot through physical creation, documentation, and development. The application of robots like Jarvis will allow the hospitality industry to grow in areas such as customer satisfaction, service effectiveness, and productivity. What Is Meant by Robotics in Hospitality? Definition and Purpose Robotics in hospitality is a term used to describe the presence of service robots within hospitality businesses. These include places such as amusement parks, hotels, restaurants, etc. Just as the human staff have tasks, so do these service robots. A service robot is an intelligent machine that will accept and take orders from both the customers and workers. The main reasoning behind their creation is to aid the human staff and speed up production. As a result of this, a company or business will benefit significantly in terms of effective service, customer satisfaction, and overall productivity. Mason 6 Uses There are multiple uses for these types of robots in the hospitality industry. The kind of tasks given to the robot are based upon the type of business that it is being used for. Considering that these robots are based off of a client-server system, they will most likely function based off of user requests and administration commands. Therefore, the abilities of these robots suit the hospitality industry the best. For example, a service robot in a hotel would be able to take user requests through either a user interface or through physical interaction through Artificial Intelligence. After getting user input, the robot would then store this information within a server system to configure its next move. The robot would then move on to receive the information or item(s) needed of the guest from human staff and then find its way back to the user. A great example of this type of interaction is shown by “the Hilton Robot Concierge” named Connie. A production of IBM, Connie is able to interact with guests and respond to their questions. The system of Connie learns and adapts with each interaction by using Artificial Intelligence (8 Examples of Robots Being Used in the Hospitality Industry, 2021). Benefits of Using Robots in the Industry Company/Business Benefits The purpose of these robots is to benefit the industry as a whole. In order to do so, the companies/businesses using them must be confident that they will be worth it. A few things that these organizations must take into account is what type of service Mason 7 they are looking for. If the service that want includes providing information, then they should be looking for an informational service robot that stores its data within a database to refer to. Buying anything other than what is needed would result in a waste of finances. After the company understands the type of technology they need, the implementation process can begin. There are multiple reasons why customer satisfaction is enhanced with the use of robots. Taking into consideration that robots are programmed to complete tasks constantly makes them more likely to achieve this without fault. According to an article titled Robots don’t make mistakes – but data does! robots themselves do not create error, but the data given to them can be incorrect. As a result, as long as their hardware and software systems are up to date and maintained, these robots are more reliable than a human worker. Without human attributes, these robots are quicker and have the ability to work constantly. This would allow for tasks to be completed at a decent pace, ultimately satisfying the need for quicker service. According to Hotel Technology News, although the initial costs of these robots can be expensive, the long-term benefits outweigh the initial costs. As mentioned in the article, the robots “do not get paid every week, so it can be a form of long-term investment” (1). All of this combined has the ability to create more business and improve overall productivity of a company. Over time, this may become a necessity as technology advances and customers become more accustomed to using it. Mason 8 Employee Benefits Employees in the hospitality industry work a significant amount of time, as this industry requires constant service. For example, a hotel staff member typically has multiple duties to fulfill throughout the day. Depending on the type of job the individual has, such as a receptionist, housekeeper, room attendant, etc., these duties may include deep cleaning rooms, assisting guests, setting up lobby services, and much more. Sometimes, these tasks can be daunting for employees, giving them little to no rest. Higher turnover rates “creates labor leakage, meaning that experience and skills are disappearing, and that time and expenses are raised as additional administration issues” (Choi, 322). This means that if employees are not satisfied, this can be bad news for a company. Service robots are programmed to work constantly and consistently. As a result of this constant labor, this can alleviate the need for workers to take on multiple duties at a single given moment. After all, a typical autonomous service robot can “work as fast as three employees and can operate 24 hours a day with 100% accuracy” (Yedavalli, 17). Not only is this beneficial for limiting the amount of work to be done, but this also allows for a happier workspace. Without having to worry about a heavy workload, “employees can devote their time and attention to bringing value to the workplace” (Yedavalli, 17). Another important thing to note is that these employees will not be responsible for the tasks given to the robot. For instance, if the robot were to have a system shutdown, break, or make a mistake, these issues would have to be taken up with administration and the developers of the robot. Therefore, employees can focus more on their specific customer/guest without being responsible for an entire group. Mason 9 Customer/Guest Benefits The purpose of implementing service robots in the first place is to improve customer satisfaction. If the customers are happy with their experience, they will be more likely to return. As mentioned before, service robots have the ability to complete multiple tasks in a short time frame. As stated in an article titled The Top Reasons Why Customers Give Repeat Business, one of the reasons customers will give repeated business is due to service satisfaction. Even if the prices of a service are not what the customer was looking for, good and memorable service can outweigh the price. Also, for some individuals, using technology as a way to provide a better service makes the most sense. For example, in a study conducted by Srikanth Beldona and Cihan Cobanoglunoted on analysis of technologies in the lodging industry, they note that “hotel guests prefer to have technologies and believe that they are an essential part of the lodging industry to meet their expectations” (3). This means that some do find the use of technology in the hospitality industry to be a necessity to overall satisfaction. With the use of service robots, the customers can be sure that their orders or requests will be remembered, the service will be quick, and their experience will be memorable. This is because service robots are made to work constantly. There are no breaks for these robots nor are they relying on physical memory. Also, some service robots, like Jarvis, have an application or web page where the user can track and look for updates on their request. This is done to give the user more personalization when they are staying or visiting somewhere. As a result, this allows the customer to make Mason 10 sure that their requests are being handled. All of this is beneficial because the service will run smoother and more efficiently, making for a better experience. Things to Consider Customer/Guest Comfortability Before implementing these robots into the industry, the comfortability of the customers/guests with them must be taken into account. As technology advances, certain age groups adapt more than others. For example, younger age groups can adapt to technology rather quickly, as children can learn to manipulate a phone by the time they start moving on their own. However, elderly groups tend to shy away from the use of technology. In a study done on how the elderly feel about robots helping them, they personally felt that robots “triggered a feeling both of loss and gain of autonomy and independence” (Pons, 167-174). Also, some elderly individuals have a hard time using technology without the assistance of another person, which may cause some frustration. Therefore, before making the decision to use service robots, a business must first assess the age group and kind of people that they are looking to serve. If they serve younger and middle- aged individuals, then implementing the robots may be an easy process. However, a group of older individuals will need time to adapt and accept the technology around them. Mason 11 Replacement of Human Workers Replacing a few workers will be necessary in order to obtain and implement service robots into a business. The reason for this is because the initial cost of these robots is not cheap and maintenance for them will not be either. This is because technology of this caliber is not an easy process. It takes a group of many software engineers and developers to figure out every component necessary for the robot to perform efficiently. However, human staff will still be needed in order to interact with the robots and provide them with whatever the guests have requested. For example, when someone places an order at a restaurant, the robot will still need a human worker to make and give them the food for the customer. As stated in an article written by the Hospitality Upgrade, “the human touch can never be replaced by a machine. For that reason, the hospitality sector will almost certainly be one of partial automation.” Even so, this will be something that will have to be taken up with the company leaders, as replacing workers will not be easy to do. Cost The cost of any technology is not cheap whatsoever. The average price for just a 64GB Apple iPhone is over $680 (Costello). Therefore, the amount of money needed to implement multiple service robots is going to be pricey. Depending on the type and visual appearance of the robot, prices may vary. Jarvis, who is considered a “shell” of a service robot, was around $500 to create. A full humanoid-like robot will cost around $20,000 to $50,000 to create (Hornyak). This is something to take in consideration before fully committing to using these robots. Some things such as current number of Mason 12 workers, special services, and customer pricing may have to be manipulated to be able to afford such technology. Meet Jarvis Brief Description Jarvis is a self-navigating service robot that makes use of a client-server system in order to take requests from his users. He has the ability to take requests, communicate with administration, navigate his surroundings, find the shortest path to his user, and balance items. From a user point of view, all that is needed as far as input is submission of a request form on Jarvis’s interface. After submission, Jarvis will accept the delivery and administration will place the requested item onto Jarvis. Finally, Jarvis will use Dijkstra’s algorithm, which helps him find the shortest path to the user. Purpose of Creation The creation of Jarvis was done for two main reasons. The first reason was to display the skill set that we have learned during our four years in the Computer Science and Engineering program at CalU. This was done through a Capstone project that lasted for about four months in total. The final reason included our curiosity into how our project could make an impact on society. We wanted to understand how technology directly affects the workforce and the reason behind its constant implementation. This truly became a goal once the COVID-19 pandemic made a huge impact on daily life. For our project, that is separate from my research, we mainly focused on how Jarvis Mason 13 could alleviate the need for hospital staff to interact with items during the pandemic. However, for this thesis in particular, the hospitality industry became a vital point of discussion when I realized that Jarvis could do this for any kind of business. The hospitality industry needs this type of contactless delivery just as much as any other industry does. Considering that Jarvis can move and balance objects, this made sense to implement and research the benefits of doing do in places of hospitality. I saw this as an opportunity to not only continue development of his system to suit the hospitality industry, but to also research this topic further. How Jarvis Depicts the Future of the Hospitality Industry Jarvis was created to help workers, not to replace them. His creation depicts what service robots look like, how they function, and their efficiency. Jarvis, unlike the typical robot, takes orders via a client webpage and stores this information within his system. From there, he will figure out a path to the customer by using a coordinate system set up on the administration page. Jarvis will learn the shortest path to the customer and take the item(s) to them. This type of service is called a client-server system. A client-server structure involves splitting up tasks between the servers and the client. This type of structure is implemented in some of the service robots today. This is also used in multiple computer applications, one of which is email. With this in mind, Jarvis depicts the future of hospitality due to his abilities and purpose. Jarvis was made to take orders and serve the client, which is exactly what a service robot does. For example, personal vacuum cleaning robots such as the iRobot Roomba 780 have similar functionalities to Jarvis. The main difference between the Mason 14 Roomba and Jarvis lies in the purpose of their creation. The Roomba was made to serve as a personal cleaner while Jarvis was made to serve as a personal assistant. In the future of the hospitality industry, there may be personal service robots such as the Roomba and Jarvis working together to make for a better and smoother work environment. Technical Documentation Introduction to Technical Documentation Technical documentation is used in many disciplines such as software development, engineering, information technology, medicine, etc. Within technical documents, many aspects of the development process as well as the product itself is described in every way possible. As the Bit.AI blog states, technical documents are created for the end-user in order to help them understand the entire architecture and functionalities of a product in a simple manner. This is important because not all users are going to understand the technical aspects of a product or technology. These documents also help to outline a realistic approach to what kind of software and hardware are the most useful and necessary as well as the appropriate timeline. By documenting the process, specification, design, etc., it helps to sell a product as well, as everything that the user needs to know about it is explained within the document. Depending on the product or technology, there will be different types of documents created. Considering that Jarvis is meant to serve the end-user, all documentation was written to suit that particular audience. The documents below include the specification and design of Jarvis and are described in complete detail for Mason 15 the user. Everything from appearance, hardware, software, functions, uses, etc. are mentioned in these documents. Jarvis makes use of many hardware pieces and software that are not seen or used frequently in the average workplace. As a result, these documents are important to the creation of Jarvis because without them, explaining these details to a client would be difficult. The technical documents given below were completed through the duration of development. Ideas, materials, and timelines changed with time and error. These documents are provided in this thesis specifically to educate anyone looking into robotics or technical writing. Both the specification and design documents give an indepth look into what the creation of Jarvis was like and how it would work in the realworld. Specifications Purpose and Use The purpose of this document is to define the intent, scope, and outcome of the final product. Also, this document will give an overview of the software and hardware functionalities that this project must perform. Specifications may include, but are not limited to, the product’s parameters and functionality. The client has full right to dispute any details set forth in this document should it not follow the intended business model or client requirements. The development team and client each reserve the right to discuss and make revisions of this document to ensure that implementation is completed in a timely manner. Should the terms and conditions in Mason 16 this document be accepted by both the client and development team, this document becomes a binding contract. Intended Audience The intended audience of this document would be any client wishing to purchase or use our product and the development team. The clients will use this document to ensure that our product is meeting any and all requirements of their business model. Any and all changes that the client wishes to pursue must be discussed with the development team and updated within this document. It is highly encouraged that clients read and acknowledge all parts of this document, seeking clarification when needed as once the specifications are mutually agreed upon this document becomes binding. By ensuring clarity and understanding, this document will provide both the client and development team with a detailed list of features expected to be on the final product. The details laid forth in this document will set a standard for which the development team will follow. This standard and the outlined constraints will allow the development team to provide a unique product tailored specifically to each client. End-User Profile The first end User (The User) of this project is any staff, patient, customer, or visitor of the facility in which Jarvis is located. The User will interact with the physical robot as well as with the Web-Application. This end-user will have the ability to make requests for delivery and pick- up of items through the Web Application and confirm Mason 17 the completion of a transaction. The necessary tools of this specific end Users consist of: • Internet Access. • The ability to read floor plans. The second end User is an Administrator. The Administrator will have permission to access to confirm and deny different request made by other users. The Administrator will also have access to reports from Jarvis. This allows the Administrator to know any obstacles Jarvis may have encountered and was unable to navigate. The Administrator will also have access to Jarvis’ charging station and power banks. The necessary tools of this specific end User consist of: • Administrative sign-in credentials. • The ability to read floor plans. • The ability to understand the technical reports produced by Jarvis. User Interaction The user will interact with Jarvis in two basic ways. The first interaction a user will have with Jarvis is the initial process of requesting a transaction through Jarvis’ website. The user will load a webpage and have access to many different features of Jarvis. From this webpage, the user will have the ability to track Jarvis, make a request for delivery, or make a request for pick- up. Once this request is made, an administrator will have the ability to confirm or deny the requests and deploy Jarvis. The most notable user interaction will be the physical interaction between Jarvis Mason 18 and a user. This interaction will happen directly after a request has been approved and Jarvis is deployed. Jarvis will navigate throughout the facility ultimately reaching the requested destination. At this point the user will have the ability to place or remove any item(s) from Jarvis’ balance plate. The user will then confirm pick-up or delivery and Jarvis will then travel to its next destination. Hardware Constraints • Raspberry Pi 4B: The Raspberry Pi will house the navigation software as well as the sensor software for obstacle avoidance. A separate power supply from the main system will be used to power the raspberry pi and attached sensors. An SD Card will be used to store navigation data. The raspberry pi has multiple GPIO ports for attaching sensors and other devices. The hardware constraints for the raspberry pi will be the memory size. We will work with the data capacity of the SD card. • 2x LC-217 Ultrasonic Sensors: The Ultrasonic Sensors will be used to detect any objects in our robot’s path as well as behind the robot while reversing. The constraints of the sensors will be their range of approximately 0.8” – 137”. • 1x Servo Motor: There will be one servo motor to allow the front facing ultrasonic sensor to sweep back and forth in order to detect any objects in the robot’s path. The constraints of this servo motor are its angular range of motion which when choosing a servo model, we will be looking to be at least 60 degrees. • Arduino Due: The Arduino Due microcontroller is the component that will be Mason 19 used for the balance plate control system and this will remain independent of the other systems. The hardware constraints for the Arduino Due microcontroller will be it’s bootup time. The balance plate cannot be utilized during system bootup and therefore an indication of when bootup is complete will need to occur. • 2x HiTEC HS 5485HB Servo Motors: The two servo motors will control the two rotational degrees of freedom, that being the forward and backward tilt adjustments as well as the left and right tilt adjustments. This will ensure that the object(s) does not get dropped off of the balance plate. The main constraint in concern when choosing these servos is command response time so that we can minimize the amount of delay in balance plate reaction. • 5-Wire Resistive Touchscreen: This will be the balance plate itself. A touchscreen is used to be able to detect where an item is on the plate at any time. The constraints of concern here are the accuracy of the location being reported by the touchscreen and the speed in which changes in the location are sent. Both of which are being considered when choosing this component. • 2x Motors: The motors will be electrical machines that convert electrical energy into mechanical energy and give the robot the power needed to move its four wheels. The motor’s constraints are the provided torque. Depending on which motors are chosen there will be overall system weight limitations to prevent motor burnout. • Power Supply: The power supply will be a power bank that will be rechargeable. The power supply will be running the two motors, the Arduino Mason 20 Due microcontroller as well as the Raspberry Pi. The power supply’s constraints are that they will always need to be charged and ready for use at all times. They will also require standard maintenance protocol and time for recharging. We plan to have a back-up power bank to be charged while the other is in use. Software Constraints • Navigation: The main constraint of the navigation is due to the ability of Jarvis to be able to fully avoid obstacles. In some cases, there may not be a way out for the bot to navigate and find. As a group, we will do our best to make sure that any obstacles in the way can and will be avoided as much as possible. In the case of an unavoidable obstacle Jarvis will send a report to the admin with the estimated obstacle location and then return to the home node. • Balance Plate: The main constraint of the balance plate software is that it must run on the Arduino Due. There will be no user interaction with the software itself, but it must be able to run without a need for constant adjustments or updates. Another constraint we are considering is the speed in which the balance plate reacts to item movement, this reaction will need to be as fast as possible to account for abrupt changes. • User GUI: The user interface will be web browser based so will not require a specific operating system. Although there may be some web browsers that do not support our user interface, interaction available we will attempt to make the to a wide number of browsers. Developing an Mason 21 interface that is easy to understand and use is also a concern. • Admin GUI: As with the user interface the administrator interface will also be web browser based. This results in similar concerns and constraints. • Server: The main constraint of concern with the server is reliability, we need to ensure the server is remaining live without downtime. Scalability would also be a constraint, but given we are only creating a single Jarvis robot this will not be too much of a concern. The development team will do its best to develop a server with a reliable infrastructure that does not require much maintenance. Time Constraints The time constraints of this project are determined by both the client and development team. As this project is being completed for academia, the implementation will be constrained to the length of the Spring 2021 semester. Every aspect of this project will depend on this specific constraint. Our team realizes that this constraint is crucial to the development of the project and will devote many hours toward the completion of this project. Cost Constraints With this project being developed by a team of four college students the cost constraint is of large concern. As a result of this, we will be developing a prototype that is mostly a proof of concept with a rough design. Our team will look to reduce cost throughout the development in order for us to be able to afford the physical product. Mason 22 Other Concerns While we plan to house our server on the Raspberry Pi to communicate data to and from the web application this may prove to be difficult or inefficient. A stable internet connection for the Raspberry Pi with proper protocol permissions is required to allow this to happen as well. In the case of the server not being able to be developed on the Raspberry Pi we plan to explore the option of renting a server during project development and testing. A final concern is security. While Jarvis will not house any information about the items being delivered or information about the users being delivered to, the overall security of the software and physical security of the device itself is a concern. Due to the time constraints of the project, we will not have time to explore security strategies besides following safe networking procedures and ensuring our code is proper. Criteria for User Acceptance Our clients and users depend on the successful travel and delivery of items throughout their facility. In order to best achieve this, the development team has predetermined a list of criteria that must be met in addition to the client parameters. By ensuring that every pre-determined item and client parameter is met, the development team can consider Jarvis a success. Jarvis will be judged on the following criteria: Mason 23 • Jarvis can navigate from the start location, to a delivery destination, and return without crashing into objects. • Obstacles that cannot be navigated around are reported to the admin and Jarvis returns to the start location. • The item(s) on the balance plate does not fall off in transit. • User(s) can request a delivery. • Administrators can confirm a delivery. • User(s) and administrators can track Jarvis while in transit. • User(s) can confirm delivery was received. • User(s) can rate the performance of Jarvis (on a five-star scale). Integration of Separate Parts and Installation There is integration of many parts within Jarvis. The front-end software will be a browser- based GUI for both end users and admin. The navigation software will be located on the Raspberry Pi as well as the sensor software for obstacle avoidance. Separately the Arduino Due will house the balance plate control system, this will remain independent of the other systems. All of these components will be located on a single main chassis of the robot. No installation will be required on the users end since all interaction will be done through a web app. There will be installation of the physical components onto the robot though, this will occur as individual components are tested to be working independently. Mason 24 Functional: Use Cases and Scenarios There are two common use cases for this specific project: The User and the Administrator. The User will use a web application to request pick-ups and deliveries from Jarvis. From this web- application, the User will also be able to track their transaction from start to finish. This will allow for the User to get a good idea of when Jarvis will be arriving to either pick-up or deliver their item(s). After the completion of their transaction, the User will have the ability to rate their experience with Jarvis. The Administrator will use the web application to confirm a pick-up or delivery and then deploy Jarvis. Once Jarvis is deployed the Administrator will be able to watch the transaction and ensure that Jarvis does not run into any obstacles that he is unable to navigate around. The Administrator will do this by reading different reports produced by Jarvis. After the transaction is complete, the Administrator will receive the confirmation from the User and confirm Jarvis’ next transaction. The User: Mason 25 Normal User Scenario: 1. The User signs on to the Web Application 2. The User creates a transaction by requesting a pick-up or delivery 3. The transaction is approved by an Administrator – User is notified 4. Jarvis travels to User’s location 5. Jarvis and User interact – Pick-up received by Jarvis or item(s) delivered to User 6. User will confirm transaction has been completed and rate transaction through Web Application 7. Jarvis travels to next location The Administrator: Mason 26 Normal Administration Scenario: 1. The Administrator will sign onto the web application 2. The Administrator will wait for a request from the User 3. Approve or deny the request 4. Deploy Jarvis 5. Track Jarvis’ progress to and from destinations 6. Confirm delivery or pick-up 7. Read User satisfaction/Review 8. Confirm Jarvis’ next task Alternative Administration Scenario: 1. The Administrator will sign onto the web application 2. The Administrator will wait for a request from the User 3. Approve or deny the request 4. Deploy Jarvis 5. Track Jarvis’ progress to and from destinations 6. Jarvis returns to home state 7. Administrator reads the report as to why Jarvis returned 8. Administrator will resolve issue or remove obstacles 9. Redeploy Jarvis Mason 27 10. Track Jarvis’ progress to and from destinations 11. Confirm delivery or pick-up 12. Read User satisfaction/Review 13. Confirm Jarvis’ next task Entity: Class Diagram All classes will exist in the main system or within the user interfaces. The balance plate system as well as the sensors and motor driver will be developed in an embedded system environment and therefore will not utilize class structures. Mason 28 Class Descriptions Jarvis Class: This is the main class that will house the majority of the robot’s functionality in interactions with both users and admin. Attributes of the Jarvis class are it’s coordinates relative to the floorplan, its last visited node, if it is idle, it’s current delivery, the navigation path it is following, if it is currently navigating around an obstacle, and if it is in a wait state after arriving at a destination. NavigationNode Class: This class is what will be used to allow Jarvis to navigate throughout a floor plan without using imagery and instead using distance traveled relative to the past node. Attributes of the NavigationNode class are it’s coordinates on the floorplan, if it is the home node, and if it is a destination node. DeliveryRequest Class: This class is what will house the information about a delivery request, this is what will be created when a user fills out the Delivery Request Form. Attributes of the DeliveryRequest class are which destination node it is going to, the time it was requested, the time it was completed, if it has been completed, and what item is being requested. ObstacleReport Class: This class is what will house the reports from Jarvis to the admin about an obstacle that could not be navigated around. Attributes of the ObstacleReport class are it’s coordinates relative to the floorplan and the time it was created. FeedbackEntry Class: This class is what will house the entries into the user feedback page that will be sent to the admin. Attributes of the FeedbackEntry class are the time it was created, a score out of 5 stars, and any comments that the user left. Mason 29 Dynamic: State Chart Main Navigation System • States • Initialization: Jarvis is turned on and is initializing the navigation software. • Standby: Jarvis is standing by waiting for delivery requests. • Preparing Delivery: Jarvis is waiting for an admin to confirm the delivery before moving. • Navigation: Jarvis makes its way along a route toward its destination node. • Avoid Obstacle: Jarvis attempts to navigate around the obstacle. • Waiting for Confirmation: Jarvis is waiting for recipient to confirm delivery completion. • Return Home: Jarvis navigates back to home node. • Events • Events are all the scenarios that cause Jarvis to transition into a different state. The events that Jarvis will encounter are user requests, admin Mason 30 confirmations, obstacle encounters, arrival of destinations, confirmation of deliveries and lastly arrival back to the home node. • Transitions • Transitions occur in several different scenarios. The first transition being when Jarvis goes from the “standby” state to the “preparing delivery” state and this occurs when the user requests a delivery. Once the delivery request has been accepted and approved by the admin that is when the next transition occurs, and Jarvis goes into the “navigation state”. From the “navigation state” Jarvis has two possible states that could be transitioned to. If Jarvis encounters an obstacle Jarvis, then transitions into the “avoid obstacle” state and then back into the “navigation state”. If no obstacle is detected and the delivery is made Jarvis transitions into the “waiting for conformation” state. After the user confirms the delivery Jarvis enters the “return home” state and from there finally back into the “standby” state. Balance Plate Mason 31 • States • Initialization: the balance plate is initializing software • • Idle: the balance plate is ready for an item to be placed on it. Balancing: the plate is continuously attempting to keep the object centered. • Events • Events are what causes the transitions to occur. The events of the balance plate are whenever an object gets placed onto the balance plate and when the object gets removed from the balance plate. • Transitions • Transitions occur whenever an item is placed or removed from the balance plate. When placing an item, the balance plate goes from the “idle” state to the “balancing” state. Similarly, when an item is removed from the balance plate, it transitions from the “balancing” state to the “idle” state. Admin UI Mason 32 • States • Main: home state in which Jarvis’ current location will be displayed. • User Feedback: will display a list of submitted user feedback. • Unavoidable Obstacles: will display a list of unavoidable obstacles reported by the robot. • Description of Obstacle Location: an approximate location and time the selected obstacle was reported. • Display Delivery Requests: will display a list of current requested deliveries. • Confirm Item Loaded on Balance Plate: requesting the admin confirm that the item has been loaded on the balance plate. • Initialize Robot Navigation: starting the navigation system. • Receive Floorplan File: allowing the upload of a floorplan file. Accept Nodes: requesting home node, delivery nodes, and intersection nodes • be added to the floor plan. • Confirm Completion: requesting admin to confirm the floorplan and node combination. • Events/Transitions • Events are all the scenarios that cause Jarvis to transition into a different state. For this state chart there are four main branches of states with scenarios. The first set of scenarios being uploading a floor plan, confirming a floor plan, inputting nodes, and then confirming final floor plans and nodes. The second set of events would be viewing delivery requests, selecting which delivery to complete and then confirming and returning. The third set of events pertains to obstacles and they are viewing the unavoidable obstacle, selecting the obstacle Mason 33 and returning. The last event that could occur on the Admin UI would be the view user feedback selection. User UI • States • Main: home state in which Jarvis’ current location will be displayed. • Feedback Form: will display a form to submit feedback to the admin. • Delivery Request Form: will display a form to submit a delivery request to the admin. • Confirm Delivery Information: will request the user confirm their delivery information prior to sending the request. • Events • Events are what causes the transitions to occur. The events of the User UI are whenever a delivery gets requested, they enter the desired delivery items information and then they submit that request. Also, another event that causes transitions to occur in the User UI us when the user is attempting to submit feedback. Mason 34 • Transitions • The user has two different options whenever they are in the initial “main page” state. The first type of transition that can occur is whenever the user requests a delivery, this transitions the user from the “main page” state into the “delivery request form” state. From there the user fills out the information and once submitted that transition into the “confirm delivery information” state and finally from there they submit and that sets them back to the “main page” state. The other type of transition the user as the ability to do is submit feedback from the main page. This transitions them from the “main page” state to the “feedback form” state and once submitted they go back into the “main page” state. Components and Tools Needed Hardware Main System: • Raspberry Pi 4B • Power Cable • SD Card • Pi Case with Heatsink • 2x LC-217 Ultrasonic Sensors • 1x Servo • 4x Wheels • 4x Motors Mason 35 • 2x Powerbanks Balance Plate: • Arduino Due • Power Cable • 2x Servo HiTEC HS 5485HB • 5-Wire Resistive Touchscreen • 2x Servo Arm • 1x Support Arm Development Tools: • Monitor/Display • Keyboard • Mouse Software: • Raspbian OS • Python 3 • Windows 10 • Arduino IDE Design Purpose and Use The purpose of this document is to provide a full description of the design for this project. This will allow the software development team to proceed with a basic understanding of how the project will be built. This document will show a detailed Mason 36 outline of the programming languages and functions utilized in the overall operation of the project. Specifically, this document will include detailed descriptions of each class and object to be used during development. Additionally, it will detail any specific input information needed for the classes and their corresponding outputs. Knowing these specific features will also require our group to establish object types and return parameters. Finally, this document will stand as a place to outline the modules that will be used for each class. This document will also stand as a place to outline the architectural diagram of the project. In addition to the inclusion of the architectural diagram, module cohesion and module coupling will also be included. This document will stand as a place to outline the organization for Jarvis - more specifically, the object-oriented design. In order to do this, the functionality of each class and each object will be outlined. Finally, this document will declare the programming languages set to be used, a timeline describing the development team’s implementation process, and our design testing. Ties to Specification Document The specification document was a basic outline of what our project is capable of and what the client is expecting from the development team. The specification document also served as communication of what is to be expected from both the client and development team. This document is an extension of the specification document and will explain in further detail the technical aspects required to complete the project to the client’s needs. This software design document will serve as a basis Mason 37 for the different levels of functionality this project will require, as well as the classes, architecture, and programming languages being utilized within the project. Project Block Diagram and Description Jarvis will be a self-navigating robot that will travel throughout a building to deliver objects to clients and users. He will be controlled by a website that is connected to a RaspberryPi server. The server will transmit packets to the navigation system and tell Jarvis where to travel. As Jarvis travels, he will continually transmit packets back to the server, updating his location and delivery status. In order to interact with Jarvis, a user will require internet access to connect to the website. Figure 1 shows the Block System Diagram for Jarvis. Jarvis will be made up of five different parts: 1. Front-end code that will reside on a website. 2. Backend code that will reside on a Windows server. 3. A balance plate to hold the items Jarvis will be carrying. 4. A navigation system that will allow Jarvis to travel around his surroundings. 5. A RasberryPi server to connect the information coming from the website to Jarvis. Mason 38 Figure 1: Block Diagram Mason 39 Architectural Diagram Figure 2 is a representation of the architectural diagram. The user will initiate a request via the user interface, it will be approved by the administration team, and the request will be transmitted through the server to Jarvis. From there the navigation request will be completed and the items will be delivered. Finally, Jarvis will transmit information back to the server regarding his location and delivery status which is then sent back to the user via the web application. Mason 40 Module Cohesion Module cohesion refers to the extent of which pieces inside the modules belong together. When looking at figure 2, you will see data is being transmitted between Jarvis and the server and is then returned to the UI for the user to view. This data flow shows the strength and cohesion between methods being used and the data being transmitted. This provides evidence of a strong architectural design and ensures that design implementation will flow smoothly. Module Coupling For our project Jarvis, there are a few different classes that will be utilized together to show the interdependence between modules. Each class relies on one another in a way that demonstrates data coupling to accomplish a goal. They all communicate and pass data so that Jarvis can complete the requested task. The different classes require knowledge of each other because all the modules are being executed while Jarvis is working on a task. Mason 41 Data Flow or Transaction Analysis Figure 3: Data Flow Diagram The data flow diagram in Figure 3 above shows a scenario of operation and the order in which data will flow. Each process is numbered to show the order in which they will occur. In this scenario the admin uploads a floorplan, then adds navigation nodes to the floorplan. Once this is complete a user then can make a delivery request. The delivery request is received by the admin and is selected as the current delivery. Our internal algorithms will calculate a shortest path from the home node to the destination node. The admin will then be prompted to place the item on the balance plate. Once the item is placed and the admin confirms the placement Jarvis will begin navigation. Upon arrival at the destination Jarvis will wait for the user to confirm the item has been retrieved and once it has been retrieved, continue back to the home node. Once a delivery has been completed the user is able to submit a feedback form for the delivery. If during navigation an obstacle is encountered a Mason 42 flag will be raised by Jarvis and it will attempt to navigate around the obstacle. If the obstacle can be avoided Jarvis will continue to its destination. But if the obstacle cannot be navigated around Jarvis will send an obstacle report for that location and return to the home node. Design Organization Classes Figure 4: Class Diagram Name: Jarvis Description: The Jarvis class is the main controller class that handles the core Mason 43 functionality of the robot. Data Members: Integer currentXCoordinate, Integer currentYCoordinate, NavigationNode lastNavNo de, Boolean isIdle, DeliveryRequest currentDelivery, NavigationNode Array navPath, Boolean hasObstacle, Boolean waitForCustomer Member Functions: create_ObstacleReport(), set_Coordinates(), set_LastNavNode(), set_Idle(), set_Delivery(), create_NavPath(), set_Obstacle(), set_Wait(), get_Coordinates(), get_LastNavNode(), get_Idle(), get_Delivery(), get_Obstacle(), get_Wait() Name: NavigationNode Description: The NavigationNode class is an object used to contain the information about each node on the floorplan that Jarvis will navigate to / between. Data Members: Integer xCoordinate, Integer yCoordinate, Boolean isHome, Boolean isDestination Member Functions: set_XCoordinate(), set_YCoordinate(), set_Home(), set_Destination(), get_XCoordi nate(), get_YCoordinate(), check_IfHome(), check_IfDestination() Name: NavigationEdge Description: The NavigationEdge class is an object used to contain two NavigationNodes and the weight representing the distance between them. These will be used solely in the NavigationGraph class to implement the weighted graph. Data Members: NavigationNode edgeStart, NavigationNode edgeEnd, Integer edgeWeight Member Functions: For this, member functions will not be necessary due to it being a struct. Name: NavigationGraph Description: The NavigationGraph class is a structure to facilitate the creation of Mason 44 NavPaths and hold the set of NavigationNodes that Jarvis will navigate to / between. Data Members: Array of NavigationEdges graph Member Functions: add_Edge(), remove_Edge() Name: ObstacleReport Description: The ObstacleReport class is an object used to contain the information about each obstacle that Jarvis cannot navigate around and needs to report back. During creation the variable values will be set. Data Members: Integer xCoordinate, Integer yCoordinate, Time struct timeReported Member Functions: get_Coordinates(), get_Time() Name: DeliveryRequest Description: The DeliveryRequest class is an object used to contain the information about each request submitted by users. When the DeliveryRequest is created, the NavigationNode nearest to the room number entered by the user will be calculated and the itemRequested value will be set. Data Members: NavigationNode destinationNode, Struct_time timeRequested, Time struct timeCompleted, Boolean isCompleted, String itemRequested Member Functions: set_Completed(), set_TimeCompleted(), get_Destination(), get_Item() Name: FeedbackEntry Description: The FeedbackEntry class is an object used to contain the information Mason 45 about each user feedback entry. The variable values will be set from the user entry values during creation. Data Members: Time struct entryTime, Integer feedbackStars, String feedbackComment Member Functions: get_Time(), get_Stars(), get_Comment() Input / Output / Return Parameters / Types Jarvis Class create_ObstacleReport() Input: The current x and y coordinates as well as the current time. Output: The obstacle report will be created. Return Parameters: No parameters are being returned by this function. Types: Integers for the coordinates and a time struct for the current time are the types used in this function. set_Coordinates() Input: The input will be the integer values the x and y coordinates are set to. Output: The internal values of currentXCoordinate and currentYCoordinate will be set to proper input values. Return Parameters: No parameters are being returned by this function. Types: The two integers are the only types used in this function. set_LastNavNode() Mason 46 Input: The last NavigationNode that was successfully reached by Jarvis. Output: The internal value lastNavNode will be updated to the input NavigationNode. Return Parameters: No parameters are being returned by this function. Types: A NavigationNode object class for the input variable is the type used in this function. set_Idle() Input: A true or false value. Output: Raises or removes the idle flag indicating Jarvis is idle or not. Return Parameters: No parameters are being returned by this function. Types: A Boolean for the isIdle value is the type used in this function. set_Delivery() Input: The current DeliveryRequest to be set as active. Output: The internal value of currentDelivery will be updated to the input value. Return Parameters: No parameters are being returned by this function. Types: A DeliveryRequest object class for the input variable is the type used in this function. create_NavPath() Mason 47 Input: The current NavigationNode that Jarvis is located at and the destination NavigationNode to be navigated to. Output: The navigation path will be created using a shortest path algorithm. Return Parameters: An array in ascending order representing the path of NavigationNodes to take from start to destination. Types: The full set of NavigationNodes, the NavigationGraph, and the NavigationEdges as well as any types that are contained in those classes will be utilized in this function. set_Obstacle() Input: A true or false value Output: Raises or removes the obstacle flag indicating that there is or is not an obstruction Return Parameters: No parameters are being returned by this function. Types: A Boolean for the hasObstacle value is the type used in this function. set_Wait() Input: A true or false value. Output: Raises or removes the wait flag indicating that Jarvis is waiting for the user to confirm removal of delivery item from the balance plate. Return Parameters: No parameters are being returned by this function. Types: A Boolean for the waitForCustomer value is the type used in this function. Mason 48 get_Coordinates() Input: This function has no input. Output: The output will be two integers representing the coordinates. Return Parameters: The current x and y coordinates relative to the floorplan will be returned. Types: The two integers are the only types used in this function. get_LastNavNode() Input: This function has no input. Output: The output will be the last visited node. Return Parameters: The NavigationNode that was last visited will be returned. Types: A NavigationNode object class is the only type used in this function. get_Idle() Input: This function has no input. Output: The output will be whether or not Jarvis is currently idle or not. Return Parameters: The Boolean value of the isIdle flag will be returned. Types: A Boolean value is the only type used in this function. get_Delivery() Input: This function has no input. Mason 49 Output: The output will be the current delivery that Jarvis is tasked with. Return Parameters: The DeliveryRequest value of the currentDelivery variable will be returned. Types: A DeliveryRequest object class is the only type used in this function. get_Obstacle() Input: This function has no input. Output: The output will be if there is currently an obstacle detected or not. Return Parameters: The Boolean value of the hasObstacle flag is returned. Types: A Boolean value is the only type used in this function. get_Wait() Input: This function has no input. Output: The output will be if Jarvis is currently waiting for a user to confirm removal of the delivered item or not. Return Parameters: The Boolean value of the waitForCustomer flag is returned. Types: A Boolean value is the only type used in this function. NavigationNode Class set_XCoordinate() Input: The input of this function will be the integer value the coordinate is set to. Mason 50 Output: The value of the xCoordinate variable will be set to the input value. Return Parameters: No parameters are being returned by this function. Types: The integer value is the only type used in this function. set_YCoordinate() Input: The input of this function will be the integer value the coordinate is set to. Output: The value of the yCoordinate variable will be set to the input value. Return Parameters: No parameters are being returned by this function. Types: The integer value is the only type used in this function. set_Home() Input: A true or false value. Output: The isHome flag will be set to true or false. Return Parameters: No parameters are being returned by this function. Types: A Boolean value is the only type used in this function. set_Destination() Input: A true or false value. Output: The isDestination flag will be set to true or false. Return Parameters: No parameters are being returned by this function. Types: A Boolean value is the only type used in this function. get_XCoordinate() Mason 51 Input: This function has no input. Output: The output will be the x coordinate currently stored in the node. Return Parameters: The integer value of xCoordinate is returned. Types: The integer value is the only type used in this function. get_YCoordinate() Input: This function has no input. Output: The output will be the y coordinate currently stored in the node. Return Parameters: The integer value of yCoordinate is returned. Types: The integer value is the only type used in this function. check_IfHome() Input: This function has no input. Output: The output will be if the node is flagged as the home node. Return Parameters: The Boolean value of isHome is returned. Types: A Boolean value is the only type used in this function. check_IfDestination() Input: This function has no input. Output: The output will be if the node is flagged as a destination node. Return Parameters: The Boolean value of isDestination is returned. Types: A Boolean value is the only type used in this function. NavigationGraph Class Mason 52 add_Edge() Input: The input of this function will be two NavigationNodes and the weight representing the distance of the edge. Output: The output will be the creation of the NavigationEdge within the NavigationGraph Return Parameters: No parameters are being returned by this function. Types: The NavigationEdge and NavigationNode object classes as well as integer will be the types used in this function. remove_Edge() Input: The input of this function will be the NavigationEdge that will be removed. Output: The output will be the updated NavigationGraph with the edge removed. Return Parameters: No parameters are being returned by this function. Types: The NavigationEdge object class will be the only type used in this function. ObstacleReport Class get_Coordinates() Input: This function has no input. Output: The output will be the x and y coordinates of the reported obstacle. Return Parameters: The integer values of xCoordinate and yCoordinate will be returned. Mason 53 Types: The two integers will be the only types used in this function. get_Time() Input: This function has no input. Output: The output will be the time the obstacle was reported. Return Parameters: The time struct value of timeReported will be returned. Types: The time struct will be the only type used in this function. DeliveryRequest Class set_Completed() Input: The input of this function will be a true or false value. Output: The isCompleted flag will be set to the input value. Return Parameters: No parameters are being returned by this function. Types: A Boolean value is the only type used in this function. set_TimeCompleted() Input: The input of this function will be a time struct. Output: The timeCompleted variable will be set to the input time struct value. Return Parameters: No parameters are being returned by this function. Types: The time struct will be the only type used in this function. get_Destination() Input: This function has no input. Output: The output will be the node that is the destination of the delivery. Return Parameters: The NavigationNode value that is Mason 54 stored in the destinationNode variable will be returned. Types: The NavigationNode object class will be the only type used in this function. get_Item() Input: This function has no input. Output: The output will be the item that is being requested. Return Parameters: The String value that is stored in the itemRequested variable will be returned. Types: The String struct will be the only type used in this function. FeedbackEntry Class get_Time() Input: This function has no input. Output: The output will be the time that the feedback entry was created. Return Parameters: The time struct value that is stored in the entryTime variable will be returned. Types: The time struct will be the only type used in this function. get_Stars() Input: This function has no input. Output: The output will be the number of stars out of 5 that was given as a rating for the feedback entry. Return Parameters: The integer value that is stored in the feedbackStars Mason 55 variable will be returned. Types: The integer will be the only type used in this function. get_Comment() Input: This function has no input. Output: The output will be the comment that was left with the feedback entry. Return Parameters: The String value that is stored in the feedbackComment variable will be returned. Types: The String struct will be the only type used in this function. Modules Used Figure 4 shows a graphical representation of the modules we will be utilizing to implement Jarvis. We will also have modules associated with our server interaction; for example, a module to send data to the server and a module for the server to send data back to Jarvis. There will also be modules that drive the front-end UI, such as a website control module and a module to handle commands sent to Jarvis from the admin UI. Files Accessed Due to most of the processing occurring on the onboard Raspberry Pi and the remaining processing being web based, the only files stored will be the floorplan, feedback entries, obstacle reports, and the code itself. The floorplan will be accessed to display Jarvis’ location to users and to create the navigation nodes. The feedback entries will be created by users and accessed by admin. The obstacle reports will be Mason 56 generated by Jarvis when it cannot navigate around an obstacle and will be accessed through the admin UI. Real-time Requirements The program behind the user interface needs to run relatively quickly to greater increase the user enjoyment of the service. This encompasses all aspects of the UI including interactions between the users requests and the acceptance or denial of the request, response times between the input and output statements, Jarvis’s ability to navigate to the destination or, if unable, send a report specifying the reason and any other updates necessary to keep the system running efficiently. Jarvis will also need to accept and navigate to the requested delivery location in a quick and efficient manner to ease the frustration of the user. They may need the item requested as quickly as possible. The real-time response of the balance plate must have minimum delay to reduce the chance of the object falling off during abrupt movements. Messages The following are the messages that will be sent within the Jarvis system. Message Type Systems Involved Data Hardware Interrupt Ultrasonic Sensor -> Navigation System Interrupt Signal Control Command Arduino Due -> Balance Plate Servos Servo Position Object Location Balance Plate Sensor -> Arduino Due Plate Coordinates Mason 57 Motor Control Navigation System -> Motor Driver Voltage Level Delivery User -> Server -> File System DeliveryRequest Delivery File System -> Server -> Admin DeliveryRequest Destination Admin -> Server -> Navigation System NavigationNode Wait Signal User -> Server -> Navigation System Boolean Obstacle Navigation System -> File System ObstacleReport Obstacle File System -> Server -> Admin ObstacleReport Feedback User -> Server -> File System FeedbackEntry Feedback File System -> Server -> Admin FeedbackEntry Floorplan Admin -> Server -> File System Image file for the floorplan and the NavigationGraph created Floorplan File System -> System -> Location View UI Narrative / PDL User: 1. Request Delivery 2. Submit Feedback Request Delivery: Delivery Form: 1. Room Number 2. Item Requested Image file for the floorplan Mason 58 Wait for Jarvis Admin: 1. Upload Floorplan 2. View Delivery Requests 3. View User Feedback 4. View Obstacles View Delivery Requests 1. Select Delivery Request 2. Back Select Delivery Request 3. Place Object on Balance Plate 4. Cancel Place Object on Balance Plate 1. Confirm Object Placed Jarvis: 1. Calculates Navigation Path 2. Departs to next node in NavPath array 3. Arrive at Destination Mason 59 Jarvis waits for User User: 1. Retrieve Item from Balance Plate 2. Confirm Delivery Complete Jarvis: 1. Reverse Navigation Path 2. Depart to next node in NavPath array 3. Arrive at home Jarvis returns to Idle Programming Language /Reuse/Portability The majority of the code on the Raspberry Pi will be written in Python, including the onboard server. Python’s abundance of libraries, writability, error reduction, and readability will allow us to easily develop parts independently and integrate them once ready. The balance plate will be implemented completely on the Arduino Due using Arduino’s version of C++. The Arduino board allows for a cheap solution for the dedicated system of the balance plate. For the web application we will most likely be using CSS, HTML, and JavaScript to implement most of its functionalities. Our development team is still open minded about using better fitting programming languages if found. We feel that using Python, CSS, HTML, and JavaScript as our core languages Mason 60 will prove beneficial for reuse and portability as well. Since Python is one of the most popular introductory languages and very readable it provides the benefit of other developers being able to understand our code without extensive effort. The front-end application being a web application provides portability to any device that can access the website. Timeline The following is a prospective timeline for Jarvis to be finished (completed December 4th, 2020): *subject to change over duration of development*. Jan Component Design Software Design Balance Plate Implementation Navigation Implementation UI Implementation Subsystem Testing System Integration Device Testing Validation Manuals and Maintenance Upgrades and Retirement Feb March April May Mason 61 Design Testing Design testing will be done continuously throughout the project’s development. The balance plate, navigation system, and user interfaces will be tested individually while being developed prior to integrating them into the system. The balance plate must pass tests of keeping a ball centered on it regardless of outer interference. The navigation system must allow Jarvis to properly navigate from one node to another. The navigation system also must properly report Jarvis’ current location on the floor plan as well as report obstacles that can’t be navigated around. The user interfaces will be tested for ease of use and proper functionality. Once each of the individual systems have been confirmed working properly, they will be integrated, and Jarvis will be tested as a whole. User Manual User/Client A client or user of Jarvis will log onto Jarvis’ website domain www. JarvisTheButler.com. Users will then come to the Home Page of the website. Mason 62 From the home page users and clients will be able to request deliveries, provide feedback, track Jarvis, read FAQs, or login as an admin through the navigation bar. If the user wishes to request a delivery, they may select the “Request A Delivery” button in the navigation bar. If this is selected, they will be brought to the request delivery form. Upon completing this form, the user will click the submit button in the bottom left hand corner and be brought to a thank you page. This page confirms your request has been received and is being processed by administrators. Mason 63 After order confirmation, users can track Jarvis by selecting the “Track Jarvis” button and be brought to the track Jarvis map. This will allow users to view Jarvis’ current location and estimate their delivery’s arrival. Once the transaction has completed, users may submit feedback to administration detailing their experience. Mason 64 A confirmation of feedback will be provided upon clicking the “Submit” button. Lastly, if a user has any questions or needs help, a Frequently Asked Questions page is available for users to reference. Mason 65 Administration An administrator will log onto Jarvis’ website domain www. JarvisTheButler.com. The administrators will then come to the Home Page of the website. From the home page, administrators can select the “Admin Login” button via the right-hand side of the navigation bar. Mason 66 Upon clicking this button, the administrator will be prompted to log in using their administration credentials. Once logged in, the administrator will be brought to the admin home page. On this main page, administrators have the ability to see Jarvis’ current location and can also navigate to many different pages via the navigation bar. Mason 67 If the administrator would like to view a list of the most current deliveries as well as the delivery uueue, they can select “Current Deliveries” button in the navigation bar and be brought to the following page. If the administrator would like to view a file of all the feedback that has been provided, they can click the “User Feedback” button in the navigation bar and be brought to a page containing all of the most recent feedback. Lastly, if for any reason the administrator would like to update the floorplan that Jarvis is using, they may select “Build Floorplan” from the navigation bar. Mason 68 From this page, the administrator is able to upload a floorplan image, drag and drop the yellow dot to the preferred node location on their floor plan and input the Node name and Edge name. Once submit is clicked, the floorplan image will need reuploaded. Conclusion This project exists to educate, observe, and provide insight on the usefulness of robotics in the hospitality industry. The idea to ponder on was exactly why robots are important and what they can specifically do to enhance the human experience. This idea was explored by taking a look at the benefits of the company, employees, guests, and physical development of a robot. Jarvis and his many capabilities proved that implementing robots into the industry is very much possible and effective. A simple Mason 69 service robot like Jarvis can reduce the amount of time taken to worry about human error and instead, provide security within the tasks being completed. As shown, robots as such are not easy to come by, but are in fact easy to put into production. With robots like Jarvis, services are bound to be quick, easy, and more fulfilling. Although efficient, human staff is vital to make sure these robots get what they need in order to serve the customer/guest. Technology is not always reliable, as systems do fail once in a while. However, if programmed and maintained accurately, service robots have the ability to become assistants to humans and make for a more enjoyable lifestyle and workplace. Mason 70 Technical Glossary Administrator (Admin) – in the context of Jarvis, an admin is anyone who has access to the admin UI and can approve, deny, and view delivery requests, as well as view user feedback and obstacle reports. Architecture – the structure of a software system. Arduino – an open-source electronics platform based on easy-to-use hardware and software Arduino board – a microcontroller capable of reading inputs and sending outputs along GPIO Boot – To start a program on a computer. Class - creates and defines properties of an object, such as variables and methods associated with the object. Data Coupling – when modules are since they communicate by passing only data. The components are independent to each other. GB – or “gigabyte”, which is a digital unit of measurement used to refer to the amount of storage capacity. GPIO (General Purpose Input Output) – a pin or port on a board used for interfacing with peripheral devices. GUI (Graphical User Interface) – a user interface that includes graphical elements and allows users to interact with an application or electronic device. Parameter – a value that is passed into a function. PID (Proportional Integral Derivative) control – a control system that utilizes Mason 71 system feedback for constant correction and control Raspberry Pi – a low cost, credit-card sized computer that is capable of doing nearly everything a desktop computer can do. Also has multiple GPIO ports for attaching sensors and other devices. Resistive Touchscreen – a touchscreen that uses two flexible sheets coated with a resistive material and separated by a small air gap. When the touchscreen is pressed the two sheets touch together altering the voltage read and this voltage difference can be translated into a position on the screen. SD Card – a small non-volatile memory card format commonly used in digital cameras, phones, and other portable devices. Server – a computer equipped with software and/or hardware that allows it to provide functionalities to other computers over a network. Servo – a small device similar to a motor with an output shaft that can have the angle of the shaft adjusted with control signals. Torque – the rotational force applied to a shaft. Ultrasonic Sensor – a sensor that measures distance using ultrasonic wave “chirps” by measuring the time it takes for the waves to bounce back to the sensor. User – in the context of Jarvis, anyone who is receiving a delivery is referred to as a user. Web Application – Also known as a “web app”, a software program that uses web browsers to complete tasks. Mason 72 References Beldona, Srikanth, and Cihan Cobanoglu. “Importance-Performance Analysis of Guest Technologies in the Lodging Industry.” Cornell Hotel and Restaurant Administration Quarterly, vol. 48, no. 3, Aug. 2007, pp. 299–312, doi:10.1177/0010880407304023. Britton, Steve. “Robots Don’t Make Mistakes - But Data Does! | CloudTrade.” CloudTrade, 29 May 2020, www.cloud-trade.com/blogs/2020/05/29/robotsdont-make-mistakes-but-datadoes. Choi, Kyuhwan. “A Structural Relationship Analysis of Hotel Employees’ Turnover Intention.” Asia Pacific Journal of Tourism Research, vol. 11, no. 4, Dec. 2006, pp. 321– 337. Costello, Sam. “What You Need to Know About the True Cost of an IPhone.” Lifewire, Dotdash, 2 Dec. 2020, www.lifewire.com/cost-of-iphone-1999299. Durant, Kim. “The Top Reasons Why Customers Give Repeat Business.” Small Business - Chron.Com, 21 Nov. 2017, smallbusiness.chron.com/top-reasonscustomers-give-repeat- business-21116.html. Granger, Brendon. “Hotel Technology Blog | Tech Talk On.” Hospitality Upgrade, 29 Nov. 2017, www.hospitalityupgrade.com/techTalk/November-2017/Will-MachinesReplace- Mason 73 Humans-in-the-HospitalityIn/#:%7E:text=Tasks%20may%20be%20shared%20and,be%20one%20of%20par tial%20 automation. Hornyak, Tim. “Insanely Humanlike Androids Have Entered the Workplace and Soon May Take Your Job.” CNBC, 1 Nov. 2019, www.cnbc.com/2019/10/31/human-like-androids-have- entered-theworkplace-and-may-take-yourjob.html#:%7E:text=The%20price%20of%20the%20robot,on%20options%20a nd%20cus tomized%20appearance. HTN Editors. “Robotic Technology in the Hospitality Industry Set to Shift.” Hotel Technology News, 30 Nov. 2018, hoteltechnologynews.com/2018/11/robotictechnology-hospitality- industry-set-shift. Lee, Yejin, et al. “Exploring Hotel Guests’ Perceptions of Using Robot Assistants.” Tourism Management Perspectives, vol. 37, 2021, p. 100781. Pons, José. Inclusive Robotics for a Better Society. New York-United States, United States, Springer Publishing, 2019. Revfine.com. “8 Examples of Robots Being Used in the Hospitality Industry.” Revfine.Com, 17 Mar. 2021, www.revfine.com/robots-hospitalityindustry/#:%7E:text=Meet%20Connie%2C%20the%20Hilton%20Robot,to%20it s%20sp eech%20recognition%20capabilities Mason 74 “Technical Documentation: What Is It & How to Create It? (Steps Included).” Bit Blog, 10 Feb. 2021, blog.bit.ai/technical-documentation. Yedavalli, Vasu. “Are Robots Helping or Hurting the Future Workforce?” CPA Journal, vol. 88, no. 3, Mar. 2018, pp. 16–17.