P19319: Lockheed ATLAS II
/public/

Systems Design

Table of Contents

Team Vision for System-Level Design Phase

During the System-Level Design Phase, our team planned to choose a design concept that is able to meet the needs of our project. We planned to do this by analyzing the functions and subfunctions of our project and what design concepts could serve those functions. Methods of analysis included creating a functional decomposition chart with function and subfunctions, a morphological table, and a benchmarking table for important features.

The team also visited the Lockheed Owego facility to talk to the customer, learn more about the project, and see how/where the device will be used. A list of important topics was created to discuss with the customer, and clarification on these issues provided crucial information for design generation. These topics and overall notes from the trip can be viewed here.

After visiting the Lockheed facility and going through concept generation exercises, the team decided on two design concepts to analyze further. These included a 2-Degree of Freedom (2DOF) robotic arm design and a linear Cartesian-based design. To choose a final design, feasibility analysis was done and a Pugh chart was created to compare the designs. Ultimately, the team decided that the Cartesian design would be the best option to pursue.

Functional Decomposition

Purpose

After the lists of customer and engineering requirements were updated, a functional decomposition chart was created. To do this, the broadest function of the device, to test MFD's, was broken into the largest subfunctions, and each of those were broken down into more specific subfunctions, and so on. This provided an overall list of specific subfunctions that needed to be considered for concept generation.
Functional Decomposition Chart

Functional Decomposition Chart

Benchmarking

Purpose

In order to avoid unnecessary work and ensure that all concept solutions were considered, the team performed benchmarking of multiple system functions. In a broad view of the overall project, benchmarking was done on devices that seem to serve somewhat similar functions to the one we aim to create.
Device Benchmarking Table

Device Benchmarking Table

This exercise was also done for smaller functions required for the device. Doing research on other devices helped the team consider all options in order to choose the best one. Additionally, it helped ensure that unnecessary work was not done to create a subsystem that could be purchased instead.

To help the team select an appropriate camera for the design, benchmarking was done on some popular cameras that are used in both robotics and drones. Camera benchmarking was done based on the needs of the team. We seek to choose a camera with a minimum resolution of 4k and that is not bulky in size or weight. The team also considered which camera would most easily interface with a micro-controller to send and receive images on behalf of the ATLAS design.

Camera Benchmarking Table

Camera Benchmarking Table

To find a micro-controller that best suits this project, a variety of micro-controllers were analyzed and compared based on operating speed, capabilities, and the programming language involved. These micro-controllers were selected for comparison due to their popularity, support base, and functionality.

Micro-Controller Benchmarking Table

Micro-Controller Benchmarking Table

Morphological Chart & Concept Development

Use Case Scenario (Updated)

Following our visit to Lockheed Martin Owego, we gained a deeper understanding of the projected usage of the ATLAS system and generated an updated use case scenario to reflect this.

Updated Use Case Scenario

Updated Use Case Scenario

Morphological Chart

The team created a morphological chart to assist us with generating design concepts. On the far left side of the chart are some of the independent functions that will need to be incorporated into the device. To the right of each function are some possible solutions to address the required function. By picking and choosing different combinations of features to incorporate in the design, we were able to develop multiple design concepts and then consider which ones seemed best.
Morphological Chart

Morphological Chart

Concept Selection Table

From the morphological table shown above, five design concepts were created based on Accuracy, a Cartesian 3-D Printer Design, Speed, Robotic Arm, and Weight. The Cartesian 3-D printer design was chosen as the best to use for further analysis, as well as the 2 Degree of Freedom design used in last year's project.
Concept Development Table

Concept Development Table

Design Concepts

The concept designs below were adapted from the previous year’s prototype 2DOF design and their 3-D printer/Cartesian coordinate design in conjunction with this year’s engineering and customer requirements, benchmarking, and morphological chart. They represent what we believe to be the top two approaches for designing the ATLAS 2.

Original ATLAS Design

Original ATLAS Design

Cartesian Coordinate Design

Cartesian Coordinate Design

Feasibility Analysis

To decide on which design to pursue, we needed to analyze each one further and ensure that the one we pick should be able to actually operate as desired.

Stability of 2DOF Arm

One major concern with the 2DOF Robotic Arm design is that the weight of the robotic head causes instability and consequently a lack of speed in the system. To analyze this, an analysis was done on the strain that the weight of the head would put on the arm. For analysis, the system can be modeled as shown below.
System Model

System Model

By neglecting the effects of the coupling between the two arms, the system can be simplified to the following, with the two arms of length l being modeled as one arm of length 2l.

System Model

System Model

Replacing the head with equivalent forces yields the following system model.

System Model

System Model

At point A, the base of the arm, there is a shear force equal to the weight of the head and a moment force equal to W*2l. These cause a normal stress equal to:

and a shear stress equal to:

where M is the moment force, V is the shear force, c is the radius of the arm, I is the moment of inertia of the arm, Q is the moment of area of the arm, and t is the thickness of the arm. By using the ATLAS I device as a benchmark, the following values were found for these variables and the approximate stress values were calculated.

Measured and Calculated Values

Measured and Calculated Values

As shown in the table above, the 2DOF design would involve a normal strain of approximately 6 psi to the base of the arm. This is the lower limit of an estimate, as the arm would need to be extended further in order to reach the corner of a large MFD, and this would cause a greater applied moment force.

This analysis shows a clear advantage that the Cartesian design has over the 2DOF design. Since the head of the Cartesian design will be attached directly to a beam that will be supported on both sides, there will be no moment force, which contributed to the majority of the stress.

Weight Analysis & Considerations

Weight played a large role in the effectiveness of the 2DOF Robotic Arm design that was chosen by the previous MSD team. The material weight analysis table below is an updated version of the one created by the previous MSD team. The values listed are approximations based on the initial concept selection and benchmarking. The Cartesian concept has a higher total weight; However, the consequences of weight should be smaller than with the 2DOF design due to the inherently better stability. We also believe that we can mitigate a portion of this weight through supporting structures. As shown in the table, The 2DOF concept has a lower expected weight, but the previous iteration experienced issues with weight at the end of the 2DOF arm. This could be mitigated through a redesign by choosing lighter materials and creating a stiffer arm structure.

Material Weight Analysis

Material Weight Analysis

Concept Selection

Pugh Matrix

To further analyze the two design concepts, a Pugh matrix was developed with last year's prototype as the Datum. Eight criteria were chosen based upon the engineering and customer requirements, and the components of each design concept were compared to the datum to determine if they could realistically be expected to perform the same, better, or worse than the Datum in each area.

Software and Weight are two of the most important criteria because no single team member is very familiar with the programming language required, so team members will need to gain more knowledge of the programming language, and the weight will be slightly heavier for the 3-D design, so lighter materials and components will have to be considered.

Summing up the total positives and negatives for each concept, the 3-D printer design had the best overall net sum of 1, with more positives offered than the 2DOF concept. With this information, and the rest of the analysis done on the designs, the Cartesian 3-D printer design has been selected as the best design to realize the engineering and customer requirements.

ATLAS 2 Pugh Matrix

ATLAS 2 Pugh Matrix

Systems Architecture

The system architecture shows a general overview of the basic subsystems of this design. This also illustrates the number of peripherals for the micro-controller as well as the varying interfaces that accompany this design.
Systems Architecture

Systems Architecture

Designs and Flowcharts

Top Level Software Flowchart

Top Level Software Flowchart

Risk Assessment

We generated a table of risks that are relevant to the scope of the project, their potential effect on the progress of the project and how we plan to mitigate them. Risks with an importance of 10 or higher are highlighted as critical risks that we would like to mitigate due to a combination of the likelihood and severity of their occurrence.We generated 16 risks in total and the full table can be found here.

The following is a table of the risks with a high importance for which we've generated a mitigation plan and will be monitoring their status closely.

 Risk Management Table

Risk Management Table

Test Plan

In order to ensure that our project is on-track and that the device will be able to meet the requirements, periodic testing of multiple components needs to be done over the course of the project. An initial list of tests that will need to be performed was created, which will be expanded upon to include additional testing as well as results after testing is done.

The initial Test Plan can be found here.

Budget Breakdown

The following is a high-level budget breakdown for the project. The estimated costs are very conservative to compensate for potential disparaties between the estimated and actual costs.

 Budget Breakdown

Budget Breakdown

Plans for next phase

Plans for next phase are shown below. Each task has a due date and owner, as well as a supporting team member and progress updates.

Phase III Plan

Phase III Plan

Microsoft Project Document

Peer Review Feedback

After the Problem Definition phase, the team participated in a peer review so that each member could learn how they can improve to best help the team. The main point that each member learned from that review and what they did to address it is summarized in the table below. An additional peer review will be done following the Systems Design phase.
Peer Review Feedback

Peer Review Feedback


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation