Motivation
The motivation for this project was to compete in Intel's First Arizona Robotics Competition on April 11th, 2008 and the Arizona Robotics Demonstration on December 11th, 2008.
Approach
Design considerations were focused on low cost, efficiency, modular and low profile components. Hardware/software upgrades and maintenance are easier to implement with modularity and publicly available materials, and were therefore considered as a major design quality.
Schedule
The tasks completed were divided by design, implementation, testing, and paperwork. Each member of the group specialized on a certain aspect of the robot: the body design, AI, software/hardware development, and hardware/software sensors. Following the design completion, each of the units were tested before complete system testing. The project constraints were defined by the competition and demonstration dates.
Quality Assurance Plan
Quality assurance ensures that acceptable measures were taken to achieve a requisite level of safety and efficacy with adequate documentation under design practices. Using a specific set of standards, practices, conventions, and metrics we were able to measure the adherence to the original requirements. Several documents were created to facilitate this process and address the all aspects of the requirements.
When quality issues were detected, special testing procedures were taken and problem reporting procedures were followed. These reporting procedures were useful in diagnosing and tracking problems.
Standards
It is important to adhere to standards to make
a project more relevant to other potential users.
Using standard hardware and software also makes results
easily reproducible by the experimenters and an interested industry
partner. The following standards were used for our project:
Utilized Standard Java Coding Practices in
accordance with Java API
Utilized Javadocs Commenting Standard to
yield a custom API for our implementation
Utilized standard hardware, including a
standard over the counter computer system.
Utilized Standard SVN structure with Trunk,
Branch, and Tags
Utilized the ASU Capstone Format for
Reports
Utilized the ASU standard for Meeting
Minutes and Biweekly reports.
Reviews
Weekly Advisor Meetings
Weekly Work Reviews
Final Review Session
Major
Milestones
Robot Assembly
The robot
will be assembled with the new body by this date.
This is not the date the robot will be completely autonomous,
but having an assembled robot as early as possible will allow sensor
calibration and testing to move forward.
Mapping/AI Completion
A rough
implementation of the mapping and AI code will be finished by this
date. This will facilitate
completion of the AI and mapping testing phases.
Sensors Completion
Preliminary
firmware and controller classes will be completed for the new
sensors (sonar and compass) by this date.
This will allow sensor testing to commence and is a necessary
milestone before complete robot testing can begin.
Midterm Report Submission
The midterm
report will be submitted on this date.
The midterm report will document the project planning phase
with focus on the requirements of the project, the schedule, and the
budget.
GUI Completion
The
graphical user interface should be completed by this date.
There will not be extensive additions to the GUI after this
date, only bug fixes and minor additions.
Testing Completion
This
milestone marks the end of the robot testing phase.
There will be few changes to the code after this point.
Fine-tuning is permissible, but all aspects of the robot
should be working per the requirements documentation.
Final Report Submission
The final report will be submitted on this date. The final report will document the project implementation phase with focus on design, quality assurance, validation planning, and business planning.
Robot Demonstration
The robot
demonstration will occur on this date.
The primary function of the robot will be to map and patrol a
room additional robot features
will be shown.
Recurring Milestones
Meeting Minutes
The meeting
minutes document the progress of the project on a weekly basis.
These meeting minutes also outline agendas for each week.
Individual Biweekly Reports
The
biweekly reports document an individual member's progress of the
project on a biweekly basis. These reports outline what the team
member has completed, and what issues were encountered.
Problem Reporting Procedures
SVN Bug Tracking
Email Reports
Team Meeting Reports
Tools
SVN Version Control
Google Code Bug Tracking
Dynamic DNS Hosting
Email
RXTX Java API
Methodologies
Waterfall Method
Pair Programming
Documentation
Requirements Document
Detailed Design & Implementation Plan
Business Plan
Test Plan & Test Results
Users Guide & other User Documentation