Your team will hold a gate review with your guide at the end of each semester. This page should document any information needed for the review, as well as outcomes.

MSD I: Reflection and Readiness for MSD II Work

Status Review

Outstanding Items

  • We have not purchased any hardware of materials yet.  Hopefully we will start that over the summer term.
  • A controls simulator has been envisioned, but no code is written yet.
  • Debug probes and test harnesses have not been constructed.  Some test plans will require the entire aircraft to be complete.
  • Machining files have not been created for our wings and airframe yet.
  • Electronics board placement has not been completed yet.

Current state of the project

  • 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)

Issues Raised During Design Review

Area DiscussedIssue RaisedMitigation Plan
Flight ControlsNo condition in which the drone acknowledges it is going to crashAdd crash state to the flight control state diagram
CommunicationsCommunicating between multiple board is difficultAware of issues the challenge presents
I/O pinsMake sure there are enough input and output pins for the designDouble check the specs for the chosen boards and make sure that more I/O pins are available than we initially need


Project Plan, Scope, Schedule

  • Project scope has been significantly reduced from where it started.
    • Focus has shifted to making an efficient fixed-wing aircraft with VTOL capabilities to enable launching and landing without a runway.
    • On-board video processing has been made an "extra"
    • On-board thermal imaging has been cut due to budget constraints.
  • Project schedule has not significantly changed.
    • The design is mostly complete and manufacturing would be feasible with some small tweaks.
    • Software requirements are mapped as well as controller responsibilities and tasks
    • Development environments are being set up

Team Critique

Loading

Risk Analysis

Original Risk Assessment

RiskDescriptionRisk Type

Likelihood

(0-5)

Severity

(0-5)

Importance

(L x S)

Suggested Action
OverbudgetBudget is limited - no funding outside of team members and RITResource3515Seek funding ASAP.  Keep costs low, prototype before deciding on a solution.
FabricationMachine shop/Construct tools could be busy, or available building resources could be limitedTime339As soon as a preliminary design is settled upon, start to source materials and fabricate parts as they become finalized, not once all parts are finalized
Software (telemetry)Telemetry is difficult, and difficult to debug.  Significant technical challenge.Technical339Start early, plan ahead for this challenge, since it will be necessary during testing.
InjurySomeone could be hit by the drone, or cut by the spinning propSafety2510Have a designated drone spotter when testing, mark dangerous area on drone with labels, have a testing plan with steps clearly outlined to ensure personnel safety, only test drone in areas away from residential areas
Drone ProtectionEffective crash mitigation tech may be expensive or technically difficult to implement, affect CR's and putting drone safety at riskResource4312
Efficient WiringSmall problems in wiring and electrical design can become troublesome quickly.Technical339Consider current flows, do initial testing.  Overbuild subsystems likely to cause problems (engine power, for example).
TestingA quick, accurate, and safe way to test drones is critical given that we cannot test on campusTechnical/Time5420Find a test site off campus, or several.  Build as much ground testing as possible.
Flight TimeThe drone should be able to maintain flight long enough to test fully and not worry about sudden loss of power mid-flightTechnical248Consider a power management subsystem, and possible emergency backup for critical subsystems.
Limited Number of DronesOnly so many testing drones can be constructed with budget constraintsResource339Train pilots (our team) on burner craft that are cheap, or in simulators.
Loss of Team MemberReduced work capacity due to missing/absent team members.Resource5

1

5Keep our options open.  Consider fallbacks and expect loss of development capacity.  Do as much ahead of time as possible.  Document everything.
Customer RedirectionA new customer is added, thus changing CRsTime144
Customer AbsenceNo official outside customer is identified, leaving us with speculated CRs and little expert knowledgeInformation5210Speculate.  Hold frequent design and progress reviews.  Validate development efforts.
Extended WinterInclement conditions make flight testing difficultTime248Find resources where we can reserve indoor flying space, even if small.
Unexpected RoadblockUnforeseen technical hurdle, miscommunication or serious bug not found in testingTechnical5315Plan project.  Break large tasks into smaller ones until they can not be broken down further. Ensure communications are clear and quick.
Team CommunicationWealth of information spread across platforms and people could create discrepancies in planningPersonal515Communicate in advance of personnel absences, after every meeting post in group chat what assignments were and the expected due dates so there is accountability

** Differences between original and final risk assessment charts are highlighted

Final Risk Assessment

Risk

Description

Risk Type

Likelihood

(0-5)

Severity

(0-5)

Importance

(L x S)

Action(s) Taken

Motor OverheatThe motors are designed to be cooled by air passing through the motor in flight.Technical224Takeoff and landing are when this risk is greatest. Because these modes are a small portion of the operation of the craft, no actions will be taken unless it becomes more severe.
VibrationsFlight and motors will cause vibrations over the craft.Technical5315It is likely the craft will vibrate, but functionality is expected to remain unharmed. No actions will be taken unless it becomes more severe.
Motor Magnetic FieldsMotors will generate and collapse magnetic fields that may interfere with positional sensors.Technical428

The sensor package should be placed as far away from the motors as possible.

IMU DriftThe IMU is expected to lose accuracy because of noise and other factors.Technical326This will be handled via filtering and calibration.
Prop WashThe propellers cause air to approach the wings in waves.Technical5110Prop wash is expected to have minimal impact. No actions will be taken unless it becomes severe.

COVID-19

We are currently facing a pandemic that has everyone social distancing.

Safety

5

5

25

Zoom meetings instead of class meetings. Team members must rely on online communications to get work done.

Overbudget

Budget is limited - no funding outside of team members and RIT

Resource

3

5

15

Avoid

Fabrication

Machine shop/Construct tools could be busy, or available building resources could be limited

Time

3

3

9

As soon as a preliminary design is settled upon, start to source materials and fabricate parts as they become finalized, not once all parts are finalized

Software (telemetry)

Telemetry is difficult, and difficult to debug.  Significant technical challenge.

Technical

3

3

9

Start early, plan ahead for this challenge, since it will be necessary during testing.

Injury

Someone could be hit by the drone, or cut by the spinning prop

Safety

2

5

10

Have a designated drone spotter when testing, mark dangerous area on drone with labels, have a testing plan with steps clearly outlined to ensure personnel safety, only test drone in areas away from residential areas

Drone Protection

Effective crash mitigation tech may be expensive or technically difficult to implement, affect CR's and putting drone safety at risk

Resource

4

3

12

Choose a concept which has crash protection built in.  Ensure pilots are trained before flying the real aircraft.

Efficient Wiring

Small problems in wiring and electrical design can become troublesome quickly.

Technical

3

3

9

Consider current flows, do initial testing.  Overbuild subsystems likely to cause problems (engine power subsystem, for example).

Testing

A quick, accurate, and safe way to test drones is critical given that we cannot test on campus

Technical/Time

5

4

20

Choose a concept which we are capable of testing.

Flight Time

The drone should be able to maintain flight long enough to test fully and not worry about sudden loss of power mid-flight

Technical

2

4

8

Choose a concept for which we can optimize power consumption and therefore flight time.

Limited Number of Drones

Only so many testing drones can be constructed with budget constraints

Resource

3

3

9

We will only be able to build one drone, but we have two indoor aircraft that may be used as trainers.

Loss of Team Member

Reduced work capacity due to missing/absent team members.

Resource

5

1

5

Mitigation plan is to reduce our dependency on custom mechanical parts. (Ben is leaving)

Customer Redirection

A new customer is added, thus changing CRs

Time

1

4

4

Mitigated.  At this point it is not feasible for the team to take on a new customer.

Customer Absence

No official outside customer is identified, leaving us with speculated CRs and little expert knowledge

Information

5

2

10

We have been continuing our design validation  and analysis techniques.

Extended Winter

Inclement conditions make flight testing difficult

Time

2

4

8

Find resources where we can reserve indoor flying space, even if small.

Unexpected Roadblock

Unforeseen technical hurdle, miscommunication or serious bug not found in testing

Technical

5

3

15

Plan project.  Break large tasks into smaller ones until they can not be broken down further. Ensure communications are clear and quick.

Team Communication

Wealth of information spread across platforms and people could create discrepancies in planning

Personal

5

1

5

Communicate in advance of personnel absences, after every meeting post in group chat what assignments were and the expected due dates so there is accountability


Highlights:

  • Our major risks are mitigated.
    • Testing: The current design is designed to be testable. We plan on making a simulation for the control systems.
    • Budgeting: Our current costs are within our maximum budget of $1500
    • COVID19: We managed to complete MSD1 without the ability to prototype.
  • Our remaining risks are mostly technical. We are aware of these issues and plan to tackle them if they pose a threat. We expect these risks to be negligible.
  • COVID19 was a surprise risk. It prevented us from prototyping physically.
  • Our risks only grew as the design continued to mature. It is wise to consider all the possibilities of something going wrong.


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

Computer Breakdown (Coarse)

TaskDescriptionCompletion (Expected)
Controls simulator with Flight GearA simulator in which we can test all of the logic of our flight controllerBefore start of MSD-II
Message Queue/RouterTinyXPC message router and queue logic, written with generic input and a static dispatch tableBefore start of MSD-II
Cruising Mode StabilizationFirmware + Models  + Sensor I/O necessary for stable flight with the wings parallel to the ground.Week 3 of MSD-II
VTOL Mode StabilizationFirmware + Models + Sensor I/O necessary for stable flight with the wings perpendicular to the groundWeek 5 of MSD-II
Flight Mode TransitionsFirmware + Controls required to smoothly and automatically transition flight modesWeek 8 of MSD-II

Mechanical Breakdown (Coarse)

TaskDescriptionCompletion (Expected)
Iterate Wing DesignRevisit wing design and re-CAD any necessary improvementsBefore start of MSD-II
Iterate Fuselage DesignRevisit fuselage design and re-CAD and necessary improvementsBefore start of MSD-II
Iterate Emergency ReleaseRevisit Emergency Release and re-CAD and necessary improvementsBefore start of MSD-II
Iterate Full CAD assemblyUpdate assembly with any revamped CAD filesWeek 2 of MSD-II (this is more useful to get an idea of what's going on, not necessary for manufacturing, so if this happens later, that's fine)
Engineering DrawingsMake drawings (or other necessary means of export) of all manufactured partsWeek 1 of MSD-II
Fabrication PlanFinalize how and where parts will be fabricated (3D printed or Machined)Week 1 and 2 of MSD-II

Electrical Breakdown (Coarse)

TaskDescriptionCompletion (Expected)
Review Power SchematicsReview the power schematics developed in the detailed design and make changes if necessaryBefore start of MSD-II
Power Distribution BoardGet familiar and understand the connections required between the PDB and other electronicsWeek 2 of MSD II
Develop test plans to test the mission capacity.Develop test plans to test the flight time and range of the droneWeek 3 of MSD-II
Integrate the power system and sensor subsystemsCombine the power and sensor / micro-controller subsystems to form a larger electrical/computer subsystem that can be tested.Week 5 of MSD-II
Test the larger subsystemTest the integrated subsystemWeek 8 of MSD-II

Deliverables Checklist and Website Status

  • All deliverable documents have been uploaded to the team's knowledge.


MSD II: Project close-out

Status Review

Current state of the project

Current performance-vs-requirements is shown in the table below.  The live version of this document is available at the embedded link, also below.


Compare your current project plan/schedule to your original plan/schedule.

Did the scope of your project change during MSD II?
The scope of the project did not change during MSD II. However, we decided to create a test platform (VersaWing) that allowed the neighboring subsystems to be developed without being blocked. This prototype ended up consuming the entire semester due to technical difficulties in solidifying the electrical subsystems.

How and why did your schedule change during MSD II?
Development time for each subsystem took more time than we anticipated. As a result, the schedule started to slip after the second review.

What have you learned from these changes that you can apply to future projects?
Design is significantly easier than implementation. Development time is difficult to estimate without thorough prototyping. Prototyping is not easily done without any budget to spend on it.

Individual Team Member Status


Did you deliver on your personal responsibilities?Did you use your MSD II plan effectively? Was it realistic?
Andrew MeyerNo - A lot of the work that was planned was not completed. A lot of technical changes and misunderstandings arose that, despite fixing most of them, indefinitely delayed the progress on the deliverables stated in MSD-I.Yes - I did my best to do work on schedule and according to where it was most important.  Unfortunately, the plan was misguided.  A number of unforeseen technical and managerial difficulties came up that made it impossible to finish the plan set out at the end of MSD-I.
Piers KwanNo - More work remains. Some things could have been designed or implemented better.The MSD II plan was far from realistic, though at the time I thought it was. Unexpected problems delayed a lot of the development. As a result, the plan was in no way effective.
Sabrina LyNo - Many things took much longer than planned and there were several unforeseen road blocks that drastically slowed progress. While a lot of work was completed, it wasn't enough to get the project to an acceptable finished state.The plan seemed realistic, but so many constraints such as time and a tight budget limited much of the development. That being said, the plan was implemented as effectively as possible within these constraints.
Ben Palmer

No - the conceptual drone remains unfinished and the Versa Wing testbed - while much further along in development - is not airworthy yet. Much work remains.

We ran into multiple roadblocks. In dealing with said roadblocks, I believe we did a commendable job in adapting our personal work schedules (and overall team schedule, when necessary) to keep some forward momentum at all times. That being said, many roadblocks could have been mitigated with better planning and a better understanding of task dependencies.

The plan was not realistic and blatantly ambitious. However, with no legitimate customer investing money and resources into our project expecting a reasonable return, I think creating an ambitious plan was a better learning experience. This forced myself (and others) to become well-versed in exceptionally unfamiliar areas of study, and it gave us valuable experience in planning a project with just the right amount of ambition.

Atulya JohnNo - Even though the work to be done was completed at the end of MSD 2, it was definitely delayed, which did not allow time for fixing problems that arose.The plan for MSD 2 seemed realistic when it was initially conceived. However, we had to make changes to the plan based on some roadblocks that we encountered. Looking back now, I think we bit off more than we could chew. However, that being said, it also allowed us to learn new things and deal with problems that arose in real time which I think is valuable experience.
Mutahir MustahasanNo- Unforeseen problems occurred late and slowed down progress. More work was required and plans could have been changed and implemented faster.The plan seemed doable but as the semester wore on it became less realistic. Budgeting issues and not having a customer funding us really hindered what we could do in terms of fixing mishaps in the plan. I think the project did provide learning opportunities as to how to plan certain parts of the project especially in the need to have contingencies if something were to go wrong.

Review your current risk assessment and problem solving status.

Risk

Description

Resolution
COVID-19School closes again before the end of the semester.School never closed.
InjurySomeone could be hit by the drone or cut by the propeller.No one was injured.
Loss of DroneWith the current budget, only one drone can be manufactured. Losing this drone could prove fatal to the project.No drone was completed, so there wasn't a drone to lose.
OverspendingBudget is limited with no funding outside of team members and RIT.Prototypes funded by team member donations.
Motor OverheatThe motors are designed to be cooled by air passing through the motor in flight. This could potentially overheat in VTOL mode as less air is passing through the motors.Motors were only run for brief and sparse intervals during testing, so no perceptible heating occurred. Since no final drone was completed, this was not a concern.
VibrationsFlight and motors will cause vibrations over the craft.No drone was completed, so there were no flights.
Magnetic FieldsMotors and power circuits will generate and collapse magnetic fields that may interfere with positional sensors.Magnetic fields turned out to be insignificant with the placement of the components.
Sensor VarianceNoise on the sensors could prove fatal to our application.Filtering algorithms removed noise from the sensors.
Software BugUnexpected bugs could prove fatal mid flight.There were plenty of bugs, but the drone was never at risk because there were no test flights.
Manufacturing AccessManufacturing tools could be busy, or available building resources could be limited.Due to lower on-campus student population, maker-spaces such as the Construct and the FabLab were usually readily available with minimal waiting. Some fabrication, such as 3D printing, was outsourced to Construct and FabLab employees. the turnaround for this was always prompt, though communication of completed prints was nonexistent.
Early WinterInclement conditions could make flight testing difficult.Winter did not come early, though we did not have any way to take advantage of that.

Customer Redirection

A new customer is added, thus changing CRs.

No external customers or sponsors were interested in our project.
Customer Absence

No official outside customer is identified, leaving us with speculated CRs and little expert knowledge.

We still have an absence of a customer, but that turned out to not really be an issue.

Loss of Team Member

Reduced work capacity due to missing/absent team members.

Luckily, no team members were physically lost.

Were there risks that you did not anticipate? If so, what do you think the reason is?

There were plenty of software bugs that could be considered "risks" which could not have been anticipated in MSD-I. Additionally, lack of access to materials and prototyping budget aside from the cost of the final product became a risk that we had no way of overcoming.

Did any anticipated risks manifest themselves as problems?

"Unexpected roadblock" - admittedly, this was a catch-all risk, to cover all of the things that cannot be learned in the design phase without either significant experience, which none of the team members have, or prototyping, which could not be completed ahead of the MSD-II development time due to both the pandemic and lack of resources.

Many unexpected roadblocks were hit. In the final phase, it was determined that something was wrong with the communication subsystem, which caused us to not be able to fly the prototype. It was determined in early MSD-II that a custom PCB would be required to make a prototype that would be reliable enough to test on, and producing that custom design took much longer than anticipated.

Lessons learned

  • Don't trust that you know what you are doing.  You will likely find out that your initial view of a problem, design, or solution space was very narrow. This is more specific to actual implementation in MSD-II than design in MSD-I.  MSD-I prompts so much time spent in the design selection phase that it makes prototyping a reasonable design difficult.
  • The first PCB will always fry something.
  • Passing tests (especially in software) does not mean that an implementation works correctly.  It only means that it works in the testing environment. If the testing environment and the final working environment are not the same, trouble abounds.

Advice to future teams

  • Prototyping is essential. There is no way to gauge complexity without experimentation. Prototypes will help with more realistic timelines. Spend some money in MSD 1! Prioritize prototyping over having enough budget left to finish your final design.  Your graded deliverables are based on your work, and completed tests in the Requirements and Testing document.
  • Take the opportunity to learn something new! MSD is what you make of it. It is far more valuable to not finish and learn something by trying to do things the right way, than to not finish and have learned nothing.





  • No labels