Preliminary Detailed Design
Team Vision for Preliminary Detailed Design Phase
The goal of the Preliminary Detailed Design phase was to take the chosen design and begin subsystem level design including component selection and purchase to be used for prototyping.
The 2 degree of freedom (DOF) robotic arm was chosen as the best concept to move forward with using the pugh matrix in the Systems Level Design Phase. Using this concept, a detailed mechanical design was created in CAD and electrical schematics were generated using the selected components. The selected components can be found in a prototype Bill of Materials, which provides current part status and vendor information. To aid in the component selection process, a torque analysis and a linearized uncertainty analysis were performed.
The components purchased will be used to ensure system operation using the developed test plans. Trouble shooting plans were also developed in the case of operation error. In addition, project risks were updated and a configuration management plan was created laying out anticipated prototype deliverables.
A gantt chart was created for the detailed design deliverables, as well as laying out member specific assignments to be expected in the upcoming phase.
|Isometric View of Design (GIF)||Top View of Design (GIF)|
|Proof of Concept X-01 Design||Final Prototype A-01 Design||Apparatus Design|
The mechanical drawings for the design can be found here:
- ATLAS Assembly Drawing
- Primary Mount Drawing
- Secondary Mount
- Waterjet Drawing
- NEMA 23 Drawing (Vendor)
- NEMA 17 Drawing (Vendor)
- Apparatus Drawings
|ATLAS X-01 Assembly Drawing|
Feasibility: Prototyping, Analysis, Simulation
Deflection AnalysisUsing the preliminary weight estimates, a deflection analysis was performed.
Comparatively, the deflection associated with a carbon fiber tube is much smaller compared to an aluminum counter part. Therefore, the arm material will be carbon fiber.
|Arm Deflection Analysis|
Torque Required for Main Motor
Our chosen motor has a torque of 3333 oz*in, therefore we have a factor of safety of about 7.
Torque Required for Secondary Motor
Our chosen motor has a torque of 667 oz*in, therefore we have a factor of safety of about 3.
Language SelectionUpon selecting the Teensy 3.6 microcontroller it was decided that Arduino and C++ will be used for the following reasons:
- Experience with C++
- Arduino IDE can easily compile C++ to the Teensy 3.6
- Object-oriented programming will give a modular code structure
- Most Arduino libraries are written in C++ (specifically, Ethernet2)
Question Regarding EthernetWhat TCP/IP protocol is being used for TWIN's servers? Telnet?
Forward KinematicsThe control scheme for software will use arm kinematics in order to determine motion. The forward kinematics for a 2-DOF robotic arm were investigated and MATLAB was used in order to create a dataset of all possible arm states for different values of theta. The MATLAB code for the calculation and dataset generation is here.
Inverse KinematicsThe inverse kinematics for the arm were found using MATLAB and confirmed using forward kinematics. Next, C++ code was written to run the inverse kinematics on the Teensy 3.6 in order to confirm it would run quickly and efficiently. See Arduino code here.
High Level Software Flowchart
|System Schematic||Sensors Wiring Diagram|
|NEMA 23 Wiring Diagram||NEMA 17 Wiring Diagram|
|ATLAS System Schematic||Microcontroller Schematic|
Bill of Materials (BOM)
This Bill of Materials doesn't consider the aluminum stock needed for the face plate and end caps, apparatus materials, wiring, or miscellaneous hardware (nuts/bolts). This is because specific vendors have not been chosen to move forward with yet.
Budget UpdatesNote: Due to dollar rounding, the overall price of the budget overview is slightly higher than that of the Bill of Material.
Detailed PlansThis is a link to Detailed Test Plans. This link provides as a main hub to all of our testing.
Since all testing documents are initially created on google drive, here is a set of links for accessing this information:
Troubleshooting PlansThese procedures will be utilized as a supplement for testing should any requirement fail or not be met. The following document contains all detailed testing troubleshooting procedures. Below is an example troubleshooting flowchart.
Configuration Management PlanThe Configuration Management Plan (CMP) below shows the 2 system configurations and the 3 project baselines for ATLAS. X-01 is the proof-of-concept prototype to demonstrate critical subsystem requirements, A-01 is the final prototype to be delivered to the customer in May 2018. Baseline I is to be met by end of MSD I, with partial system integration and functionalities. Baseline II will be satisfied near the end of MSD II, with all subsystems integrated and operational. Baseline III will be met by the end of MSD II, with all engineering requirements satisfied and no open issues.
Phase III Closeout & Actions
Some tasks from Preliminary Design Phase are carried forward to Detail Design Phase due to longer-than-expected processing time for parts purchasing, these include proof of concept prototype electrical system testing, hardware, and software integration and testing. The chart below shows a comparison between the initial schedule from system design review and the schedule from the end of preliminary design phase.
|Preliminary Design - Planned vs Actual Actions|
Plans for Next Phase
The action plan for Detailed Design Phase is outlined on the Gantt Chart below.
|Phase IV Gantt Chart|
- Make sure the dates in the Gantt Chart are discussed as a team
- Perform unit checks on calculations
- Priority will be placed on using SI units moving forward
- Check the stock status of desired parts to be ordered prior to submitting
Peer Review Feedback from System Design Phase
|Team Member||Peer Review Action||Feedback|
|Harvick Tang||Plan tasks that require collaboration for Sunday meetings.||Sunday meetings are more productive, the Gantt chart helped the team get better idea of what needed to be done by who and when.|
|Sarah Bentzley||Communicate software requirements and workload, delegate tasks.||Discussed delegation of software testing to other team members so that software development can stay on track.|
|Matt Craven||Better communicate my workload and progress on tasks I am working on.||Updated the team more regularly with status updates on work in progress which lead to the rest of the team providing their input on decisions throughout the process.|
|Mark Min||Have more confidence in work that was done and during presentations.||Met with professors/subject matter experts to review work that was done.|
|Mike Kelly||Communicate more when looking for team input. Do not take on more tasks than I can handle.||Communicated more with team when in need of input on testing procedures (ie. the troubleshooting flowcharts). Taking on less tasks helped improving the quality of work rather than the quantity of work.|
|Kyle McAlinn||Take on more analytical tasks to support design development.||Performed more analysis tasks during the phase, and research the correct approaches for the task. Met with subject matter experts when needed.|