Team Vision for System-Level Design Phase (Kyle)
The goal of the System Level Design phase was to establish a functional decomposition which was used to generate different potential concepts. Using a Pugh Matrix, each concept will be compared using important criteria derived from the Engineering Requirements of the project.
The team was able to generate three different concepts and used generated criteria to make a final system selection. In this case, the 2 degree of freedom (DOF) robotic arm was chosen as the best concept to move forward with. Using this concept, a system architecture was made. Risks were updated with specific system design issues the team anticipates.
Motor and microcontroller benchmarking began, and high level software and electrical schematics were generated. Preliminary test plans, and a failure mode effect analysis were also created. Using the selected design and component benchmarking, a preliminary budget was made.
Following the onsite customer visit the following changes were made to the system requirements.
- Ethernet TCP/IP is no longer a requirement, but will remain first choice of communication interface for current design.
- Requirement for a GUI to operate ATLAS is no longer a requirement. It is replaced by requirement to send and receive input/output signals from a remote computer.
|Functional Decomposition Diagram|
Morphological Chart and Concept Selection
Morphological Chart (Mark)
Communication Options (Sarah)
|Option 1||*Option 2*||Option 3|
Concept Development (Kyle)
The following potential system designs were developed using a combination of benchmarking and engineering and customer requirements, as well as other tools developed during the first two phases.
|2 Degrees of Freedom Robotic Arm||Rotating Rail||Linear XYZ|
Feasibility: Prototyping, Analysis, Simulation
Material Selection for Weight (Harvick)
6 different materials were analyzed comparing the weight to strength ratio, as well as weight estimates of various other components such as a microcontroller and stepper motors. This will be used to determine the feasibility of the 10 lb customer requirement.
As shown above, carbon fiber has the best weight to strength ratio, and its total material weight is about 3.5 lbs. 6063-T6 Al is the second choice of material. Cost will be the final step in determining material selection.
Feasibility of Polar Coordinates (Kyle)
Traditional cartesian coordinate systems dominate the 3D printer market. However, with weight considerations, a system that uses polar coordinates would be more likely to be under the 10 lb limit.
Assuming we can accurately use a rotary encoder as well as a linear transducer to measure distance, the following is how you convert cartesian coordinates on an MFD to polar coordinates:
Converting from the cartesian coordinates above, to polar coordinates, r and theta, is done using the following equations:
X = r*cos(theta)
Y = r*sin(theta)
Knowing desired X and Y location, and using the rotary encoder to measure theta, The use of polar coordinates is relatively easy, and could be implemented in the software.
TCP/IP Interface Microcontroller (Sarah)
Even though the Ethernet requirement (TCR/TER 4.1) was removed after the visit with the Lockheed Martin team, it still might be possible to have TCP/IP functionality to communicate with TWIN directly. Below are two options for implementing an Ethernet connection, an adapter and a microcontroller board which has Ethernet ability built in. Feasibility of either would be best tested using prototyping.
Selection criteria is as follows:
- Ease of implementation
- Microcontroller's compatibility with other ATLAS functions
- Reliability and robustness of communication
|Ethernet Adapter (ENC28J60) with Teensy 3.6||FRDM-K64F|
Memory Considerations for MicrocontrollerConfirmation that the microcontroller will be able to read in the entire configuration file and run in a loop for a consecutive 12 hours will be accomplished by prototyping on a Teensy 3.6.
- Upload a configuration file and see how much memory it takes up
- Run a loop for 12 hours where pins are written high and low the entire time (this can be accomplished in final prototype)
- Confirm that microcontroller can run for that duration
Concept Selection (Matt)
To evaluate system and subsystem concepts, Pugh matrices were generated using important criteria from the systems requirements.
As shown in the Pugh matrix above (detailed chart in the link), the robotic 2-DOF robotic arm was chosen as the best concept based on the criteria laid out above. Ten criteria were developed and weighted based on importance. Scalability, weight, and software complexity were weighted most heavily.
Scalability and weight were the most critical customer requirements, so they were given the most consideration. Software complexity was also extremely important to the group because we have only one team member fluent in software development. Other team members will gain needed knowledge to support system development, but only one member with extensive prior knowledge.
Considering all the criteria, the 2-DOF robotic arm, relative to the traditional Cartesian design baseline, had a net score of one. The Helo concept had a net score of negative eight. Therefore, the robotic arm is the best design to fulfill most of the weighted criteria derived from the engineering and customer requirements.
Final Design Concept (Matt)
Following the decision to move forward with the robotic arm concept, a model of the MFD provided my Lockheed Martin was created in SolidWorks. A final model of the robotic arm was also created in SolidWorks.
|Animated GIF||Expanded Analysis|
Benchmarking (Matt)The following motors and micro-controllers are under consideration leading into a detailed design analysis.
Systems Architecture (Sarah)
Designs and Flowcharts
Top Level Software Flowchart (Sarah)
System Schematics (Mark)
See the Schematics Package for ATLAS.
|ATLAS System Schematic||Microcontroller Schematic|
Risk Assessment & Test Plans
Risk Management (Mike)
Failure Mode Effect Analysis (FMEA) (Mark)
Test Plan (Mike)A preliminary Test Plan was developed to test system requirements.
Budget Breakdown (Mike)
Plans for Next Phase
The action plan for Preliminary Design Phase is outlined on the Gantt Chart below.
|Preliminary Design Phase Action Plan|
Lessons Learned (Kyle)
- Prior to a feasibility analysis, risks of the specific system concept should be generated. Some technical risks for the system concept should be done to ensure feasibility.
- Explicitly layout how purchasing in this phase should be done. For instance, can we only purchase from the Vendors listed on the MSD Purchasing site? Who can we purchase from this early in the design?
- Layout specific deliverables RIT and the guides are looking for at the beginning of each phase. This is especially important for guide specific tasks, like when it comes to generating a Gantt Chart.
Peer Review Feedback from Problem Definition Phase (All)
|Team Member||Peer Review Action||Feedback|
|Harvick Tang||Generate meeting agendas to keep the team on task prior to meetings||Consistently made agendas prior to all group meetings|
|Sarah Bentzley||Ask for help when needed, and don’t take on too much work comparatively to the team.||Ask for help and delegated tasks to the team when needed|
|Matt Craven||Speak up more during meetings||Consistently spoke up with opinions during meetings|
|Mark Min||Arrive earlier to meetings||Arrived on time, and in some cases early to group meetings|
|Mike Kelly||Don’t stress yourself out so much||Controlled stress level during concept development, which resulted in a better final product|
|Kyle McAlinn||Resist being pessimistic coming into systems design||Was more open to ideas and thinking outside the box|