MSD I: Readiness to move to Build & Test
Key elements for this Gate Review are listed here.
Meeting Notes
Throughout MSD-I, all meeting notes and Communication & Minutes were recorded during team meetings and design reviews. These helped the team track action items and discussions.
Self Critique
The team completed a Self Critique prior to the gate review. All other peer reviews from the semester that were done for each phase can also be found in the teamwork folder.
The summarized results of the self-critique are reported below. Items that we scored low on and plan to address in our team for MSD-II are specifically:
- Project planning needs to be done actively, not only just when MSD requires it. The team could benefit from detailed plans in advance and goals of adhere to dates.
- Engineering requirements have issues with traceability. Many of the requirements the team listed do not fit nicely with one test or metric.
- Team meetings need to happen more frequently, with all members present. We experimented with discipline specific meetings in MSD-I only to realize that this led to miscommunication between team members on what was being done.
- Team dynamics are lower, despite high cooperation and a great sense of unity, because of lack of accountability and failure to recognize issues soon enough with a team member.
- The team needs to address the issue of deliverable changes. Our circumstances allow us greater flexibility to redefine deliverables to what fits our status best, there needs to be accountability for this.
Expectations
- All team members present and prepared to report on team and individual status.
- All team MSD deliverables are complete and uploaded, and ready to be graded.
- Guide is present and prepared to evaluate all items included in the review.
- Review should take about an hour.
Status Review
Current State and Comparison of Requirements
The requirements of this project are quite flexible, which is one of the main topics the team would like to discuss entering this design review. From the customer, we have two of the more concrete requirements: adhering to CubeSat standards, and getting the solar sail to deployment to 100% and monitoring and reporting this deployment. Our next inferred requirement is for the diffractive experiment, in which we expect to measure the diffractive torque.
The remainder of performance metrics are inferred from the team's knowledge in prototyping. They have been set to cover the scope of the demonstration model, not a entire flight ready CubeSat, and thus have emphasis on function over space hardiness.
A live and updated version on EDGE of the Requirements document can be found here.
DDR Action Items Green/Yellow/Red
| Issue from DDR | Red/Yellow/Green Status | How was it addressed, or will be addressed? |
|---|---|---|
| Reflectance Sensor tape could present clearance issue on booms | Yellow | Although it has not been tested yet, there is a clear path forward for the team in MSD-II to test out the deployment sensor and tape method once parts are received to determine if this is an issue. In the case that the friction does present problems, there are methods for removing and mitigating it that the team has suggested. |
| Battery holder on electronics presents vibration risk | Green | Additional cut-outs were added to connect battery straps commonly used on 18650 style batteries. |
| Redistribution of software work due to loss of team member | Green | An MSD-II plan with the software work redistributed was made. All team members had multiple discussions with guide on this subject, and each provided ways that they can individually aid the software prototyping. |
| Free samples in BOM should be accounted for | Green | In the notes line item, Digi-key price points were added to account for a full cost with the free samples. |
| BOM should account for shipping and contingencies | Green | A 25% contingency cost was added to the BOM, as well as an estimated 12% shipping cost. |
| Budget increase required to make BOM purchase | Green | A budget increase for an extension to $1500 in MSD was made and justified. The NY Space Grant Consortium was also applied for. Both results pending. |
| Boom stiffness issues | Green | At our current budget, we do not have enough money to purchase and/or fabricate new booms. If we receive additional funding, we can revisit this. |
| ADACS | Yellow | The equations of motion have been derived and are currently being verified. |
| Re-assessing Software Goals | Yellow | We have scoped down the software, and also determined how other teammates who are not software orientated can still aid Charles in software development on the Raspberry Pi. |
| Look into carpenter tapes for cheap, stiffer booms | Red | Very little besides a quick google search has been done. |
- Address any issues raised during your Detailed Design
Review. These will generally fall into one of three
categories
- Issues that have been addressed and the team is closing them out. (GREEN, team is ready to proceed to build and test)
- Issues that have not been addressed yet, but the team has a clear path to a solution. (YELLOW, team expects to be ready for build and test, and a Critical Design Review may be held in MSD II Week 2)
- Issues where the team has not been able to identify a solution or a clear path to a solution. (RED, team is not ready for build and test, and a Critical Design Review will be held in MSD II Week 2)
Current State and Comparison of Project Plan
Comparing the team's current project plan to our original plan there is a noticeable difference in the amount of planning we had done into the future at the beginning. Planning into far off phases was underestimated at the beginning, but also difficult, due to the shifting nature of the project and flexible description which had to be defined within the first few weeks of MSD-I.
- Has the scope of your project changed?
- Initially the team had a very loose scope which included a vague idea of making a fully functional flight-like model of the CubeSat.
- A major shift in scope occurred once the team met with RIT grad, and space expert, Bryce Salmi. We realized from this meeting that the original scope was not only too ambitious for the amount of time allotted in MSD, but would also far exceed any budget restrictions.
- The new scope, which has since the end of the 2nd phase been the core focus of the team, includes creating a mission plan and functional demonstration model of the CubeSat.
- Instead of a fully functional CubeSat ready to be converted to flight, the team now focuses on proving out new designs in the demonstration model. These include the sail deployment, a single reaction wheel for flight control, and complete electronics compatibility with standard CubeSat components.
- How and why did your schedule change?
- The change of scope slightly impacted our schedule, but not so much so as individual components and subsystems of the full project.
- By the end of MSD-I, the schedule for design items remains the same, and the team did an excellent job at adhering to mechanical and electrical detailed design plans.
- ADACS calculations took far longer than originally planned, but was adjusted for as soon as this realization was made, and now a new plan aims to have the ADACS calculations demonstrated with the demonstration model.
- Software planning experienced the most major and unplanned setbacks due to the team poorly managing the risk of failure to complete work by a team member. Crucial parts of the communications that needed to be tested for feasibility were not investigated. Architecture for the software GUI was also not realized when expected.
- A portion of the project plan that occurred much further ahead of time than expected was testing. After flaws in the original design were discovered that were not originally known to us, testing the sail deployment became imperative to the design work being done in parallel.
- What have you learned from these changes?
- Debugging time should be doubled for contingencies.
- Testing should be expected to introduce new unplanned tests.
- Risk management for design work should be accounted for by the team and planned for in the schedule.
- Purchasing and requisition of prototyping parts must be included in the MSD-II schedule to ensure that prototyping stays on schedule.
- Above all, the team needs to take on more active day-by-day planning, opposed to the current "plan at the end of each phase only."
The original project plan only looked up into the 3rd phase, and failed to plan expected dates for deliverables in the far future.
Individual Team Member Status
This table summarizes individual team members analysis of their status as of completion of MSD-I. The key questions asked were:
- Did you deliver on your personal responsibilities?
- Did you use your MSD I plan effectively? Was it realistic?
- What did you learn from this and how have you applied this toward a meaningful and realistic MSD II plan?
| Team Member | Did you deliver on your personal responsibilities? | Did you use your MSD I plan effectively and was it realistic? | What did you learn that can be applied to MSD-II? |
|---|---|---|---|
| Amber Dubill | I believe that I delivered most of my responsibilities and personal deliverables. The sail deployments are further along than we originally expected. Where I dropped the ball was documentation. I still plan to finish that documentation in MSD II, but need to put a greater emphasis on it. The my part of the orbital calculations and ADACS were delivered, and I am still working on improving them and advancing them further. I upheld a lot of outside communications to the team, though I feel that I could have communicated more effectively and faster to everyone which I would like to improve on in the future. | While I may not be very good at keeping to a particular schedule, overall I am on track and where I need to be in the general scope of the project. The orbital calculations and adacs calculations are not as far along as we expected. I underestimated the complexity and time required, but this is okay because neither are time critical tasks for our project. | time management, descoping unnecessary items, assessing tasks based off the capabilities of the team, task time estimation, better communication methods |
| James Emerson Parkus | I did not deliver the ADACS model in the state I would have liked too. It was more complicated than I thought initially and it took a month or two to get comfortable with the material. However, I have nearly completed it and will be able to push it through over the winter break, since I need only verify the model. | My MSD I plan was a bit too ambitious and I was unable to finish the ADACS model and implement the reaction wheel control model. So while I did accomplish part of my goals, I should have been more realistic with my goals. | For MSD II I will limit my scope to only what is necessary. This will be correctly modelling the ADACS response for a given perturbation and then implementing this model into a single reaction wheel system. |
| Sarah Wittenauer | I have delivered on my personal responsibilities this semester, even though I do the work very closet to our deadlines sometimes. The CAD model is completed and some initial drawings will be made before the end of finals. We have done several deployment tests and noted several areas to improve next semester. As a facilitator, I have taken notes at most of our team meetings and kept the team on track during discussions for the most part. | I think that my MSD-I time was used effectively and I am currently on track with my deliverables. The plan that we had at the start of the semester changed with the decrease of our scope, but I think that I am currently in a good place and ready for next semester. | I learned that it's important to keep the team updated on your progress to make sure that you aren't going off track. It's also helpful to have at least a broad of understanding of each subsystem and keep it in mind while you are working on your part of the project in order to make integration easier. |
| Charles Nystrom | I effectively communicated with my team about what tasks I was completing and what things were holding me up. Due to some issues with the other team member working on software, I kept putting off trying to go further with my work, giving them a chance to get their side done. This resulted in me not sufficiently completing the communication of the main board to the flight computer, which was the goal this semester. Personally I tried to get work done but my lack of assetrtiveness held my work back. | The plan that was decided upon to have board to board communication working was a realistic one, but I did not follow my MSD I plan effectively and got very little done. This next phase, I hope to put more focus onto completing and delivering my work on time and up to the standards that my team expect. | I learned that I need to take charge and just work on things if they aren't getting done. I need to not wait for a task to be assinged to me in order to start working on something. |
| Jarrett Wehle | Of my personal responsibilities there was, being an active team member, being the team Purchasing manager, and electronics and interface design. I believed that I entirely fulfilled be an active team member, often engaging in activities to move the team forward and schedule the completing of tasks. For purchasing, I feel that I did a good job maintaining an active Bill of Materials and budget estimate, but was not proactive enough to anticipate purchases that could have been made to aid in prototyping. In the realm of electronic design I believe that I gave my best and worked to integrate my designs with the mechanical systems as much as possible. My electrical designs are well documented, and designed with manufacturability, assembly, cost, and ease of hand-off in mind. | I believe that I used my MSD-I effectively because I completed all desired work on time and delivered all items to the EDGE well before reviews. I found my schedule to be realistic, specifically in terms of the design and purchasing. | Going into MSD-II, my main lessons learned are related to being more proactive in budget management. This also includes recognizing the need for prototyping materials and stepping forward to set up their acquisition. This will be crucial in the build and test phase and I expect that my efforts from here on out will result in a successful delivery of a working CubeSat prototype. |
Current State and Comparison of Risk Assessment
The live and continuously updated document for Risk Management is located on EDGE.
Several risks have been closed out and combined with another risk due to redundancy. After the loss of a team member, those risks have been assigned to other members of the team. At the end of MSD-I each assignee updated the status of each risk and how it had been addressed in the detailed design of the CubeSat.
The main risk that manifested as a problem was Risk 22, a social risk for accountability of deliverables. The team was late to recognize that progress was not being made in the software realm because of lack of communications.
The sail folding risk has been the most heavily influencial on the project so far. Numerous tests have been performed to mitigate the risk after it was found that the previous team's deployment mechanism had not eliminated this risk as much as originally expected.
New ADACS risks had been added as well to encompass discoveries about the reaction wheels that the team had not previously anticipated before the research and calculations had been done.
MSD-II Schedule
Our team's MSD-II schedule demonstrates that there will be a functional prototype of the CubeSat delivered by the final phase. From the self-evaluation, and issues the team has noticed throughout MSD-I with scheduling, we have incorporated new plans for more proactive planning into this schedule.
Imagine RIT
We plan to have our booth in GFH like previous years. Our customer has requested that our booth be next to SPEX’s as it has in the past. Our main attraction will be our CubeSat hanging on a game hanger (provided by SPEX) where people can come and impart a slight spin and the reaction wheel inside will stabilize it. A quadrant of the sail will be hanging behind us to show the size of it, along with our poster for more information. A monitor will have the deployment tests playing. Samples of the booms and diffractive elements will be around to show people those aspects of the project.- Amber will handle this request along with submitting it for SPEX to gauruntee our spot.
- Already meeting with safety committee for SPEX to make sure that our plans adhere to safety, specifically the hanging components.
Deliverables Checklist and Website Status
All of these documents can also be found on the P20101 EDGE Home page. This includes specific MSD related deliverables, design items and documents, and customer related deliverables.
- Phase 1 - Problem Definition Phase
- Phase 2 - Systems Level Design Phase
- Phase 3 - Preliminary Detailed Design Phase
- Phase 4 - Detailed Design Phase
An updated live view of this document can be found here.
Questions for the Gate Review
- How can we better manage the fluidity of our deliverables?
- New strategies for team accountability without being invasive?
- MSD-II team meetings and the actual class time?
- NanoAvionics NDA signing?
MSD II: Project close-out
- Use this space to organize information for your review. Key elements are listed here
Expectations
- All team members present and prepared to report on team and individual status.
- All team MSD deliverables are complete and uploaded, and ready to be graded.
- Guide is present and prepared to evaluate all items included in the review.
- Review should take about an hour.
Status Review
Current state of the project- Summarize actual performance vs. requirements
(include snapshot of current requirements document here,
along with a link to the live document.).
- Which requirements were unmet, and why?
- How robust is your final design?
- Did you meet your project budget?
- What was your customer's assessment of the work you delivered to them? Were they satisfied?
- Compare your current project plan/schedule to your
original plan/schedule.
- Did the scope of your project change during MSD II?
- How and why did your schedule change during MSD II?
- What have you learned from these changes that you can apply to future projects?
- Review individual team member status.
- Did you deliver on your personal responsibilities?
- 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?
- Review your current risk assessment and problem
solving status.
- Have you closed out your most important risks?
- Were there risks that you did not anticipate? If so, what do you think the reason is?
- Did any anticipated risks manifest themselves as problems?
- How did you use your problem solving process during the semester?
Deliverables Checklist and Website Status
- All documents must be uploaded to your website in advance of the Gate Review.
- 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.
- Is prototype hand-off complete, is the team's workspace cleaned up, and have all tools been returned?
Lessons learned, etc.
- Does the team have any other lessons learned that were not addressed above?
- What advice would you give to future teams?
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
- Viewing the latest revision
- Node updated 2019-12-12 10:02 by jep7631