Historique de la page

MSD I: Reflection and Readiness for MSD II Work

Status Review

Current state of the project

• • Unmet Requirements:

    • Securely attach to spacecraft, Interpreting terrain characteristics, supporting long distance communication, and recording mission data have been excluded from the project scope for the initial design.
    • These topics were excluded to maintain focus on developing the critical components necessary for the lander and may be reincluded once an initial design has been completed.
    • The additional requirements are being focused on and incorporated into the design development.

    Robustness of the Final Design:

    • Since the final deliverable of this project is a completed design, the final design has not been completed yet. However the ability to handle various hypothesized terrain conditions and landing situations will require constant consideration of durability into all design choices.

    Project Budget:

    • This project was given no hypothetical budgetary constraint from the customer.
    • No additional purchases have been necessary at this time leaving the full amount granted from MSD available for prototyping in future phases.

    Customers Assessment:

    • An initial design was presented to the customer as well as plans for future models and simulations. The customer was satisfied with the current progress and direction of the project while raising some design concerns that we will be resolving and testing in the next phase.

Live Document: Customer Requirements.xlsx

• • Issues that have been addressed and the team is closing them out. (GREEN)
    • Will the lander legs stay outwards at the angles we have them drawn at? 
      • With the fixed joint to hold the secondary struts to the lander body, those will be able to hold out the main leg at the desired angle.
    • Will crushable bottom leave debris behind?
      • No because the material that we are using for the crushable bottom will just form to the surface, and won't crack or break.  It will stay connected to the lander at all times.
  • Issues that have not been addressed yet, but the team has a clear path to a solution. (YELLOW)
    
    • Can the aluminum honeycomb damper spring back to allow for more shock absorption if the lander bounces? Or, will the feet have sticky material on the bottom of the feet that will hold it down on its initial impact?
      • We did not design for the damper to spring back, but believe that we will just need it for the initial impact.  If the lander bounces more, it will not have as great an impact as the first one.  Additionally, we are planning to have a sticky material on the bottom of the lander feet so the lander holds to the asteroid surface, hopefully on the initial impact.
  • Issues where the team has not been able to identify a solution or a clear path to a solution. (RED)
    
    • Should design be a circle instead of a square so that corners won't change direction or course of lander if it hits debris once it is on the surface?
      • We have initially designed the lander as a square, but are still deciding on whether or not to have the lander have sharp edges or not.

• Compare your current project plan/schedule to your original plan/schedule.
  • Has the scope of your project changed?
    
    The original scope of the project included developing an entire landing system for the Psyche mission. However, after carrying out additional research and diving deeper into the requirements we have narrowed down the scope to designing the lander legs and the breakable bottom. Usage of slurry was even considered within the scope however, it was disregarded after carrying out further research on its feasibility. 
    
    
  • How and why did your schedule change?
    
    The main reason for the change of the scope was the complexity of landing systems. Landing systems consists of several complex sub-systems making it too big of a scope for our senior design project. Furthermore, due to the ambiguity of Psyche's surface and lack of resources for testing & prototyping it was necessary to reduce the scope of the project. We narrowed down the scope to lander legs and breakable bottom as we can run simulations for these systems which would allow us to support our design decisions.  
    
    
  • What have you learned from these changes?
    
    It is very important to understand the scope of the project at the start of any project in order to ensure we meet our customer expectations. As a team we quickly realized that our scope was too big and carried out detailed research on different systems in order to narrow down our scope. This has helped us to get to a stage where our project goals and requirements are realistic and we feel confident in achieving them in MSD 2. 

• Review individual team member status.
  • Personal Responsibilities
    • Each team member did an excellent job in fulfilling their responsibilities and taking on tasks this semester:
      • Vishvam organized meetings, facilitated with the customer, ensured adherence to the established project schedule, and adapted the schedule as the project scope evolved.
      • Kate provided technical insight, took charge in researching past landers and functional design feasibility, as well as reached out to faculty about design ideas. 
      • Brandon provided excellent research, fielded technical questions well at Design Reviews, and will serve as a ANSYS SME for the upcoming analysis portion of the project.
      • August expanded his knowledge of space systems, brought himself up to speed on mechanical designs, and adapted to become an asset during the mechanical design process.  August will be applying his electrical knowledge in designing a landing sensor system for the next portion of the project.
      • Sam provided technical insight into system design and served as a facilitator for project design and deliverable organization.  Sam applied dynamics knowledge to provide a base for the dynamic lander model.
  • Did you use your MSD I plan effectively? Was it realistic? If not already addressed above, what did you learn from this and how have you applied this toward a meaningful and realistic MSD II plan?
    • The time was spent in an effective manner. However the complexity of the mission goal called for a longer design and proofing phase than some other MSD projects might have.  Much time was needed up front to perform research on space systems and landing systems.
  • Individual Peer Evaluations
    
    Peer Evaluation: Samuel Shelmidine

Peer Evaluation: August Koehler

Peer Evaluation: Vishvam Pipaliya

Peer evaluation: Kate Weidmann

Peer Evaluation: Brandon Vosbury

• Compare your current risk assessment to your original.
  • Have you closed out your most important risks?
    Our most important risks included project delay due to the Covid pandemic, product design not able to meet customer requirements due to lack of PRP, and incapable design due to the uncertainty associated with the Psyche surface. 
    • Delay due to Covid pandemic: Our team has been working very efficiently remotely throughout the fall semester hence, we are not concerned about any future closures. We have established google drive, slack, and basecamp as our mediums of communication along with regular zoom meetings. 
    • Product design not able to meet customer requirements: We have confirmed with Dr. Bowman about the change in scope of the project before moving forward with our narrowed scope. 
    • Incapable design due to the uncertainty associated with the Psyche surface: We have narrowed down the scope to lander legs and breakable bottom which we believe can be tested using Matlab and Simulation softwares. This will allow to make sure our design is feasible to land on Psyche surface.
      
      
  • Do you have remediation plans for remaining risks? 
    • All the risks have been assigned a owner and actions to remediate the risks. Please find the link to the document below: 
      
      Document Owner: Vishvam Pipaliya 
      Link: Risk Register (Phase 4)
      
      
  • Have any of these risks manifested themselves as problems?
    
    None of the risks have been a major problem for the team. 
    
    
  • How did your risk assessment change? What can you learn from this?
    
    The risk assessment document is a live document that evolves as the project progresses. Some of the risks had reduced risk scores as the project progressed. For example, initially we estimated that covid pandemic might cause problems for the team. However, we worked well remotely and this risk was reduced. Narrowing down the scope of the project also had impact on the risk assessment. Some of the sub-systems were removed and hence risk associated with those sub-system were transferred. Lastly, as we carried out additional research we also discovered new risks. 
    
    

Review your team's MSD II schedule (if not done during DDR)

MSD II: Project close-out

Status Review

Current state of the project

• Summarize actual performance vs. requirements 
  
  
  • Which requirements were unmet, and why?
    • Able to sustain through uncertain terrain of psyche
      • Complications with design not performing as expected during prototype testing.
      • The honeycomb crushable bottom did not perform as expected,  Unfortunately the Strengths lab tensile tester was broken all semester.  Our team planned on testing and obtaining the honeycomb material properties to update the simulation result prior to testing.  Due to this, the only option left was to leave the simulation as it was and test with the prototype honeycomb.  This did not result in the best comparison between the prototype testing and the simulation.
  • How robust is your final design?
    • Lander was able to withstand drops from 6ft at its weight of 9lbs on both surfaces tested. However, a set of the legs snapped off when we added weight to total the lander's weight to 16lbs and dropped it from the same 6ft height. We added more weight to try to get the honeycomb to crush more in its vertical orientation.
  • Did you meet your project budget?
    • Our team was able to complete the project within the given budget from ASU and MSD. 
    • Budget limitations had limited our ability to test different honeycomb structure. If we had more budget we would have been able to buy more honeycomb structure and test the lander several more times. 
  • What was your customer's assessment of the work you delivered to them? Were they satisfied?
    • ASU seemed to be satisfied with our work and results.  Although we did not fulfill the original requirements of the mission, our customer wanted the focus to be on learning and experimenting with different landing methods.  Even though our project was not wildly successful, we learned a great deal about the behavior of crushable bottom honeycomb.

• Compare your current project plan/schedule to your original plan/schedule.
  • Did the scope of your project change during MSD II?
    • Major change occurred by implementing a physical prototype and moving away from a simulation and MATLAB code only final deliverable.
  • How and why did your schedule change during MSD II?
    • The schedule changed because after meeting with Dr. Gomes about our dynamic analysis we determined that the MATLAB code would not be complete by the end of MSD. Therefore, we decided to design and build an actual prototype instead of simulating it.
  • What have you learned from these changes that you can apply to future projects?
    • Up-front research was important in choosing the final landing design.  
    • Consulting with SME's prior to the completion of the design phase is important in the future.

• Review individual team member status.
  • Did you deliver on your personal responsibilities?
    • Each team member completed the assignments given to them.  Everyone met several times a week for a majority of this semester to work in test frame design, prototype manufacturing, and testing.
  • Did you use your MSD II plan effectively? Was it realistic? If not already addressed above, what did you learn from this and how can you apply it to future projects?
    • Yes we used our plan effectively. We did overestimate how quickly we would get machining and assembly time complete, but since our plan had extra time at the end of the semester, we were still able to assemble and test before the semester closed out. Some of this had to do with trouble with getting in touch with one of the machinists to weld our frame together, which took longer than expected.  For the future we know to get in touch with outside people early and to plan for hiccups in the machine phase.

• Review your current risk assessment and problem solving status.
  • Have you closed out your most important risks?
    • Majority of risks were closed except for two. 
  • Were there risks that you did not anticipate? If so, what do you think the reason is?
    • Simulation results did not align with prototype results. 
    • Lander components did not function as expected. 
  • Did any anticipated risks manifest themselves as problems?
    • Lander components had mechanical issues which resulted in not able to test the lander legs. Furthermore, we were not able to honeycomb structure simulation match with prototype results. This again resulted in not able to verify our planned design. 
  • How did you use your problem solving process during the semester?
    • We used the problem solving process several times during the semester. Major problem solving was when we realized our initial project scope with MATLAB code might not be feasible. We used the problem solving document to quickly brainstorm alternative options and selected the best option to move forward. 

Deliverables Checklist and Website Status

• All documents must be uploaded to your website in advance of the Gate Review - Complete 
• The team should not use gate review time to conduct a detailed examination of specific deliverables unless related to discussion items in the status review - Complete 
• Is prototype hand-off complete, is the team's workspace cleaned up, and have all tools been returned? - Complete (Prototype handed to MSD team) 

Lessons learned, etc.

• What advice would you give to future teams?
  • Vishvam: Obtain concrete customer requirements early saves a great deal of time early.  Having a data sheet is greatly important.
  • Kate: Simpler designs are preferred.  Once designs become complicated, greater risks follow.  Meeting with subject matter experts helps guide the design process.  Environments that we were not well acquainted with needed to be considered - such as a vacuum.
  • August: Use your simulation results to plan for physical tests. Double check for shorts and other easy to miss but very troublesome issues. Think carefully about what components you might need to replace.
  • Sam: Begin the prototyping process and design process early.  Rapid prototyping is extremely important in design iteration.  A team would likely learn more with having several iterative prototypes than they would with one prototype where the design is frozen prior to testing.  
  • Brandon: Have a more realistic scope for the project to begin with.  Our scope narrowed significantly between the beginning of the first semester and what we ended up doing.  We initially started with researching communications, thrusters, and other components which we did not have the time to do.  We should have been more conservative when considering the number of employees on a team for NASA or SpaceX.