admin
Fri, 02/09/2024 - 19:53
Edited Text
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.
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.
Media of