Table of Contents
Team Vision for Detailed Design PhaseTeam Goals for Phase 4
- Finalize schematics
- Finish developing UML for app
- App prototyping
- Control serial signal using application microcontroller
- Decide on placement/type of additional stimuli
- Develop software flow diagram for microcontroller
- Finalize BOM based on schematics and part models for electrical casing/assembly features
- Model toys in CAD and modify based on proposed additions
- Refine Test Plans
Team Accomplishments in Phase 4
- Finalized schematics
- Refined UML
- Finalized choices for additional stimuli
- Sun toy
- Frog toy
- Elephant toy
- Make lights on main platform into buttons
- Finalized BOM
- Modeled toys in CAD and showed modifications to accommodate new lights/switches
- Refined test plans
- Developed task lists with estimated time requirements for both app development and microcontroller software development
The team created a progress report to send to our customer and guide before leaving for Thanksgiving break. The document can be found here.
Schematics, Flow Charts, Simulations
MCU Schematic is shown below:
Power Supply Schematic is shown below:
LED Interface Schematic is shown below:
Audio Interface Schematic is shown below:
IO Extender/Button Inputs Schematic is shown below:
Schematics document can be found here.
Micro-Controller Embedded Software Diagram
Flowchart document can be found here.
Detailed Function Descriptions can be found here.
Larger Size can be found here.The application has been designed in a typical manner befitting hardware control. The application is also designed in a loose manner, and will be documented as changes and helper classes are added to the predicted classes.
To simplify development as much as possible, the following software design patterns were used in the design: - Factory - Flyweight - Facade - Observer - Chain of Responsibility - Command - Strategy
Other design patterns may be used as well as development continues.
The Application functions (loosely) as follows:
The single representation of the micro controller state is held by a SQLite database within the application. SQLite was chosen for its light weight and widespread use in Android application programming. The User interacts with the View representation held by the apps MainActivity. The MainActivity then edits the database based on the changes requested by the user/state changes that are going to be logged. The Main Activity, when it edits the changes, also creates a "Command Object" which holds a representation of the command to be carried out by a micro controller. This Command object is parsed into the appropriate communication protocol by MicrocontrollerCommunication(to be dictated by Electrical Hardware design) Once the command has been sent by the Communication program over serial, then it is stored in a contained within a linked list of objects inside a separate thread (instantiated at start). This thread (Named ObserverOfCheckTable) will Observe a hash table (hashed by time command created) contained by a State Data Handler. This thread will iterate over its contained list objects, checking the state data handlers incoming data that concerns a state change for the micro controller and verifying that any change was successful. If any change is unsuccessful, it logs this failure, and sends a signal to the MainActivitiy to recreate the command.
Incoming data from the microcontroller will be deserialized by MicrocontrollerCommunication and then sent to the first in a linked list of handler objects (described by the "Chain of Responsibility" Design Pattern). These will allow incoming data to be quickly handled in an appropriate manner flexibly, and also allow priority of data to be considered. The most important data will be any incoming audio data from the monitor, so it will handle it first. This data is identified and then sent to a separate thread "AudioStream" which will implement with the standard android persistent audio playback interlaces. If the data is not audio data it passes it to the next handler, which handles urgent notifications. The next handler is then to handle data to be synced from the micro controller to the database. The final handler will then be handling state data and any unhanded data, and allow a previously mentioned thread to verify commands have been completed.
This is the flow of information as currently understood. As development continues, this could alter in some way. That being said, the high level functionality of each of the portions of this description should remain true throughout development, with any unanticipated changes being in helper classes and android interfaces that are as of yet unknown.
Drawings and 3D Models
CAD models of jumper components can be found on the Mechanical Drawings page.
Bill of Material (BOM)
Bill of Material document can be found here.
List of Tests to be Conducted
Test Procedures and Information
A description of the tests listed above that are not described by ASTM standards can be found here.
Federal Regulations and Testing Standards
Our product falls within ASTM F2012 - 16: Standard Consumer Safety Performance Specification for Stationary Activity Centers. The document describing theses specifications can be found here.
Updated Risk Assessment document can be found here.
After doing some research, Risk Assessment ID# 15: "Tying Our self to a Single Platform" has reduced. The following data compares Android vs Apple users, which shows Android Users represent majority of the market.
Design Review MaterialsMeeting agenda and notes/action items from the review can be found here.
Plans for next phaseGantt Chart for Phase 4
Individual 3 Week Plans
- 3 week plans for MSD II Phase I can be found here.