In order to gather these requirements, we have been holding weekly meetings with Dr. Leverington. During these meetings we discuss what he is looking for in the final product, and brainstorm potential requirements with him. This has come as a huge help as it has allowed us to gain a feel for which areas we should be focusing on throughout the project. We have also been doing plenty of research in our own time and reporting back to Dr. Leverington during these meetings. Along with this, we have also met with the electrical engineering team who is working on R.A.T. concurrently to ensure that the work we are doing is compatible with theirs.

Our four main functional requirements that we have identified through our acquisition process are as follows:

• R.A.T. needs to be able to navigate throughout the engineering building on its own. This is the highest functional requirement for navigation and represents the overall goal for this project
• R.A.T. needs a map of the Engineering building. An accurate and map is absolutely necessary for the navigation module.
• R.A.T. needs to be able to self localize itself within the engineering building. This is the most important aspect of the WiFi localization module, as it will allow R.A.T. to find its location regardless of where the robot boots in the engineering building.
• R.A.T. needs a GUI to display status and take inputs. Having a GUI will help the operator / user track R.A.T.’s progress and status, as well as offer a convenient place for a user to feed it a room number as input.

The above only represents four of our highest level functional requirements for the project. In order to accurately defined these requirements, they can be broken down into many different sub-requirements. To view a detailed outline of all functional requirements, please refer to our Requirements Specification document.

In order to better define how we seek to achieve these requirements, we have outlined the following performance requirements:

• 1.P.1 = R.A.T. needs to determine which floor it is on within 60 seconds
• 1.P.2 = R.A.T. needs to stop within a 50 cm2 area in front of a doorway
• 2.P.3 = R.A.T. must build a map that is accurate to the real world with errors no larger than 10 cm
• 2.P.4 = R.A.T. needs to generate a map of the Engineering Building in under one hour
• 3.P.5 = R.A.T. GUI should update the operator approximately every twenty seconds regarding the data it is retrieving
• 3.P.6 = GUI should start moving within twenty seconds of receiving a command about where to go
• 3.P.7 = R.A.T. should report to the GUI every twenty seconds its current condition (stretch goal)
• 4.P.8 = R.A.T. needs to obtain router information within 60 seconds
• 4.P.9 = R.A.T. should be able to match its estimated location on a map within 20 seconds
• 4.P.10 = R.A.T. should orient itself accordingly within 10 seconds, meaning R.A.T. will know how it currently sits during the boot phase

Some of the environmental constraints we have identified in the project include:

• Programming environments. Since we are in the second year project, last year’s team has set a few standards which we will be following in the interest of saving time. These include things such as:
• Robot Operating System (ROS).
• Requires Linux Operating System
• Python and C++.
• Hardware. Once again, last year’s team had chosen certain hardware elements that we will be working with. We choose not to change these pieces in the interest of saving time and our client’s money. Hardwares that are relevant to us include:
• Kinect Sensor.
• Arduino.
• RaspBerry PI.
• Wheel counters.

If you are seeking more detail in either our requirements or acquisition process, please refer to our Requirements Specificationdocument.